주니어에게 전사 정산 구조를 맡기는 팀, 그게 사일로예요

토스 전사의 결제 흐름이 담긴 정산 구조. 실수 한 번에 영향이 전사로 퍼지는 그 물건을, 올해 합류한 2025 NEXT 출신 주니어 한 명이 지금 직접 드라이빙하고 있어요. 기존 파이프라인 옆에 새 파이프라인을 병렬로 세워서, 비교하면서 단계적으로 갈아끼우는 방식. 설계도 그분이 잡았고요. 이걸 "왜 주니어한테 맡겨?"라고 묻는 회사가 있고, "그 일을 가장 깊이 파고든 사람이 결정하는 건데요"라고 답하는 회사가 있어요.

토스 서버 개발자 우여명·임재웅. 사일로라는 조직 단위에서 일하는 두 사람이 이 문화의 속사정을 풀었어요. 5~7명이 한 제품을 통째로 책임지는 구조. 그 안에서 벌어지는 결정의 속도, 안정성을 지키는 방법, 그리고 주니어한테 전사급 일을 맡기는 배경까지요.

0에서 1을 만드는 팀은 20명을 넘기지 않아요

사일로는 PMF를 찾거나 특정 비즈니스 목표를 빠르게 달성하기 위해 만들어진 소규모 팀이에요. 광고, 커머스, 페이, 대출. 각각의 완결성 있는 사업을 독립적으로 운영해요. 개발자, 디자이너, 데이터 분석가, PO가 한 팀 안에 묶여 하나의 목표를 향해 달립니다.

팀 규모는 보통 5~7명. 제품 생명주기에 따라 한때 20명까지 늘어난 적도 있는데, 그 시점에서 또 비효율이 생기니까 다시 잘게 쪼개요. "작은 스타트업"이라고 여명님은 표현했어요. 아침에 출근하면 지표 확인, 팀원들과 어떤 실험을 할지 논의, 1~2주 안에 개발·배포. 결과 보고 다음 실험 결정. 이 루프가 계속 돌아가는 거죠.

가설이 맞아떨어져서 임팩트가 날 때의 짜릿함. 벽에 부딪혀 팀원들과 함께 좌절하는 순간들. 그 양쪽 다 이 조직의 매력이라고 해요.

장점은 두 가지였어요. 하나는 액티브한 커뮤니케이션. 전혀 다른 직군의 사람이 하나의 목표를 향해 달리는 소속감. (5명짜리 팀에서 안 생기면 그게 이상한 거죠.) 다른 하나는 결정 속도. 개발자 한 명이랑 정책 담당자 한 명이 그냥 마주 앉아 이야기하면 끝나요. 여러 팀의 싱크를 맞추는 긴 과정 없이, 필요한 순간에 바로 실행. 재웅님 말로는 "0에서 1을 만들 때 특히 장점이 있다"고. 처음부터 정답을 만들 수 없다는 전제로 일하니까, 빠르게 시도하고 결과로 방향을 계속 조정하는 방식.

얼라인 전과 후, 완전히 다른 속도예요

토스의 속도는 '빠르게 만드는 것'이 아니에요. '더 나은 방향을 찾았을 때 빠르게 고쳐나가는 것'까지가 속도더라고요.

재웅님이 꺼낸 사례가 흥미로웠어요. 초기에 만들어진 기능이 잘 쓰이다가 시간이 지나면서 레거시로 남은 상황. 여러 곳에 이미 퍼져 있어서 건드리기 어려운 코드를, 3~4년차 팀원 한 명이 "지금 기준에서 맞는 구조가 뭔지"부터 다시 정의했어요. 설계부터 마이그레이션 전략까지 직접 잡고, 사용자 영향 없이 점진적으로 전환. 이걸 보면서 재웅님이 느낀 건, 빠른 실행 = 처음에 빨리 만드는 것이 전부가 아니라는 점이었대요.

여명님 쪽은 반대 사례였어요. 신사업 프로젝트의 방향성 잡는 데 생각보다 오래 걸렸다고. 0to1이다 보니 어떤 선택도 가능했고, 팀원들이 조금씩 다른 그림을 그리고 있었거든요. 그 그림을 하나로 맞추는 데 많은 에너지가 들어갔어요. 근데 얼라인이 되자마자 새 앱을 1주일 만에 만들어냈어요. 1주일.

"빠른 실행"의 정체가 이거예요. 서두르는 게 아니라, 충분히 고민해서 방향을 맞춘 뒤 누구보다 빠르게 달리는 상태. 방향이 정해진 순간, 팀 전체가 한 방향으로 밀어붙이는 힘. 얼라인 전은 느려 보이고, 얼라인 후는 빨라 보이고. 밖에서 보면 같은 회사가 두 속도로 일하는 것처럼 보일 수 있어요.

안정성은 "한 번에 안 바꾸는 것"에서 시작해요

속도와 안정성. 둘 다 가져가려는 방법은 생각보다 단순했어요. 한 번에 크게 바꾸지 않는다.

재웅님은 "예전에는 일단 만들어보고 보자에 가까웠는데, 지금은 리스크를 고려하면서도 속도를 잃지 않으려고 해요"라고 했어요. 기존 구조 옆에 새 구조를 병렬로 두고 비교. 점진적 전환. 같은 얘기가 여명님 입에서도 나와요. 변경이 100% 안전함을 보장하는 건 현실적으로 불가능하니까, 문제 생겼을 때 빠르게 감지·대응할 수 있는 구조에 더 집중한다고.

그 현장 도구가 슬랙 알림이에요. 최근 만드는 전사 계약서 관리 시스템 이야기. 다양한 서비스의 계약을 메타데이터로 관리하는데, 이 데이터가 매출·비용의 근거가 돼요. 그래서 비정상 데이터 형태나 주요 에러 케이스를 미리 정의해두고 주기적으로 점검, 슬랙으로 알림. 중요한 건 한 번 정의하고 끝나는 게 아니라, 운영하면서 새로 발견되는 케이스를 계속 추가한다는 거예요. 감지 기준이 시간에 따라 고도화되는 구조.

의사결정 방식도 비슷해요. 토스도 규모가 커지면서 무조건 빠르게만 가진 않아요. 결정은 더 신중해지고, 결정 이후엔 망설이지 않고. 글로벌 진출용 회원 체계를 설계할 때가 대표적이었대요. 국가마다 다른 개인정보 보호 규제, 보안적으로 안전한 구조, 사용자 경험을 해치지 않는 방법. 이걸 전부 고려하느라 시간을 많이 들였고, 대신 방향이 정해진 뒤엔 빠르게 구현·검증·개선.

여명님이 좋아한다는 말이 있어요. "진짜 잘 만들고 싶으면 세 번 만들어라. 처음엔 무조건 못 만들고, 두 번째엔 그나마 낫고, 세 번째에서야 진짜 좋은 게 나온다." 실패가 끝이 아니라 과정이라는 거. 신중하게 결정한 다음엔 빠르게 시도하고 빠르게 배우는 게 맞다는 거.

스태프 조직이 막는 게 아니라 같이 푸는 회사

불필요한 시간 낭비가 적은 이유로 둘이 꼽은 건 딱 두 가지였어요.

하나. 스태프 조직이 블로커가 아니라 파트너처럼 움직인다. DBA, 보안팀, 법무팀이 제품을 이해하려고 먼저 찾아와요. 재웅님이 꺼낸 예시는 보안이 중요한 기능을 만들던 때. 보안팀이 리뷰만 하는 게 아니라 설계 단계부터 직접 참여해서 구조를 같이 고민해줬대요. 그래서 중간에 막히거나 돌아가는 일 없이 처음부터 올바른 방향으로. '막힌다'가 아니라 '함께 푼다'는 감각. 이게 전체 실행 속도를 높여준다는 거예요.

둘. "프로세스를 위한 프로세스"를 만들지 않으려는 고민. 회사가 커지면 프로세스는 자연스럽게 생겨요. 근데 그 프로세스가 일을 막는 게 아니라 효율적으로 만들어야 한다는 걸 다들 알고 있다고. 완벽하지 않더라도 그 방향으로 계속 개선하는 태도.

최근 사례가 DBA가 만든 DDL MCP. 이전에는 라이브 DB를 변경하려면 DDL 쿼리 따로 정리, 변경 맥락 문서 작성, 리뷰 요청. 이 과정에서 맥락이 누락되거나 다시 설명해야 하는 경우가 종종 있었어요. 지금은 코드 변경 기반으로 DDL과 맥락이 함께 자동 공유되고, 그 흐름대로 리뷰가 이루어지도록 바뀌었어요. 개발자는 코드 수정 후 해당 스킬을 사용하면 한 번에 요청까지. 문서 쓰는 시간, 맥락 정리하는 시간이 줄면서 리뷰 속도도 빨라지고 커뮤니케이션 비용도 많이 줄었다고 해요.

DRI는 연차가 아니라 오너십이 기준

여기서 이야기가 재밌어져요. 주니어한테 전사급 일을 맡기는 문화.

최근 합류한 주니어 공채 2025 NEXT 출신 개발자. 이 분이 드라이빙하는 게 토스 전사의 정산 구조 개선 프로젝트예요. 전사 결제 흐름이 담긴 정산. 실수가 나면 영향 범위가 넓은 바로 그 프로젝트. 기존 파이프라인 옆에 새 파이프라인을 병렬로 만들고, 비교해가며 단계적으로 전환하는 구조를 직접 설계 중.

DRI(Direct Responsible Individual)가 그분이거든요. 여명님 말은 단순했어요. "그 일을 가장 잘 알고, 가장 깊이 파고든 사람이 결정하는 거니까요." 저희 입장에선 너무 당연한 거라고.

재웅님이 이어받아요. 다른 회사에서 보면 "왜 저런 중요한 걸 주니어한테 맡기냐"고 할 수 있는데, 토스에선 그게 당연하대요. 연차가 아니라 그 일에 대한 오너십이 기준. 물론 혼자 하는 건 아니에요. 시니어가 방향을 잡아주고, 잘못되는 방향이 보이면 피드백. 더 큰 역할을 맡아본 사람들이 훨씬 빠르게 성장한다는 관찰도 덧붙였어요. 맡은 만큼 고민의 깊이가 달라지니까.

시니어의 지원 방식도 흥미로워요. 여명님은 의도적으로 큰 덩어리를 배분한대요. 잘할 수 있는 작은 일만 반복하면 성장이 제한되니까, 스스로 고민해야 하는 규모의 일을 주는 거. 대신 아무도 안 보는 건 아니에요. 옆에서 계속 들여다보면서 방향이 어긋나면 피드백. 요즘 AI 코딩에서 나오는 '하네스' 개념과 비슷하대요. 시니어가 안전하게 실험할 수 있는 환경을 만들어주고, 주니어가 그 안에서 마음껏 해볼 수 있게 하는 구조. 권한이 동기부여로, 동기부여가 다시 성장으로 이어지는 선순환이에요.

개발자가 비즈니스까지 짜는 구조

영향력 이야기. 여명님은 "생각보다 훨씬 커요"라고 했어요. 특히 플랫폼 조직에서는 개발자의 기술적 결정이 곧 제품의 방향이 되는 경우가 많대요.

최근 사례는 B2B 고객을 위한 토스 커뮤니티의 비즈앱. 연동된 계열사들도 함께 기능을 추가하는 구조라, 계열사 연동 방식이 여러 조직에 영향을 주는 상황이었어요. 그래서 API 구조나 인증 방식 같은 연동 기준을 설계·가이드하는 과정 자체를 개발자들이 주도. 기존 연동 방식 비교, 보안·컴플라이언스 이슈 함께 검토. 이렇게 정해진 기준이 여러 서비스와 계열사의 구현 방식에 그대로 적용돼요. 개발자의 기술적 결정이 실제 제품의 사용 방식과 확장 방향까지 이어지는 거죠.

재웅님은 관점 이야기로 받았어요. 개발자가 코드만 짜는 게 아니라 "비즈니스를 해결하기 위해 뭔가를 한다"는 관점으로 바뀌면 성장 속도가 달라진다고. 사일로 구조에서는 그 차이가 더 크게 드러나요. 하나의 제품과 목표를 팀이 같이 책임지다 보니 개발자도 자연스럽게 의사결정에 참여. 기술적 선택이 곧 제품의 방향이 되는 경험을 반복하면서 영향력을 체감하게 된대요.

카오스를 정돈하는 과정이 일의 본질

역할이 유연하게 열려 있는 환경. 이게 성장에 어떻게 작용하는지.

여명님은 이렇게 표현했어요. 역할이 정해져 있지 않아서 오히려 더 넓은 영역을 바라보는 게 자연스럽다고. 단순 개발뿐 아니라 제품을 같이 만들어가는 관점을 갖게 되고, 의사결정에도 더 깊게 관여하게 돼요. 시야 자체가 넓어지는 경험.

이게 어느 정도 의도된 환경이라는 해석이 따라와요. '카오스'처럼 보일 수 있는 그 환경 안에서 개발자도 다른 직무 영역까지 확장해서 일하게 되고, 누구나 팀의 빈 곳을 메꾸는 경험을 하게 되거든요. 결국 그 카오스를 하나씩 정돈해나가는 과정 자체가 일이고, 그게 진짜 성장.

재웅님의 마무리가 좋았어요. 그 환경이 개발자의 관점을 바꿔준다고. 단순히 기능을 구현하는 사람이 아니라, 비즈니스 문제를 해결하는 사람으로. 맡은 범위가 넓어지니까 자연스럽게 "왜 이걸 해야 하는지", "어떻게 풀어야 하는지"까지 고민하게 되고, 그 경험이 반복되면서 성장 속도가 달라진다는 관찰.

사일로에서 일한다는 건 코드를 짜는 것 이상이에요. 작은 팀 안에서 제품의 방향을 고민하고, 팀의 빈 곳을 채우고, 때로는 전사에 영향을 주는 구조를 직접 설계하는 일. 결정의 무게는 크고, 역할의 경계는 불분명하고, 정답을 알려주는 사람은 없어요.

근데 바로 그 버거움이 개발자를 바꿔놓는다는 게, 두 사람의 결론이었어요. 2025 NEXT 출신 주니어가 전사 정산을 드라이빙하는 풍경은 그 결론이 지금 이 순간 실제로 돌아가고 있다는 증거이고요.