1인 1작업에서 1인 N작업으로, 병목이 코딩에서 판단으로 옮겨간 시대에 일하는 방식은 어떻게 달라지는가
들어가며
무신사 물류플랫폼팀에서 백엔드를 개발하고 있습니다.
먼저 밝혀두자면, 무언가를 가르치거나 교훈을 전하려는 목적은 없습니다.
AI 코딩 에이전트와 본격적으로 일하기 시작한 뒤 제 일하는 방식이 어떻게 바뀌었고 어디에서 넘어졌는지, 그래서 지금은 어떤 방식으로 일하는지를 돌아보는 글에 가깝습니다.
저도 아직 이 방식이 맞는지 의심하는 중입니다.
요즘 제 모니터에는 터미널 창이 여러 개 떠 있습니다.
각 창에서는 서로 다른 작업을 맡은 에이전트가 돌고 있고, 저는 그 사이를 오가며 결과를 읽고, 승인하고, 다음 지시를 내립니다.
몇 년 전의 저라면 이 화면을 보고 “저렇게 하면 하나도 제대로 못 끝낸다”고 했을 겁니다.
실제로 그때는 그 말이 맞았습니다.
이 글은 세 가지 질문을 따라갑니다.
왜 예전에는 한 번에 하나만 했는가.
무엇이 바뀌어서 지금은 여러 개를 동시에 굴리게 됐는가.
그리고 사람은 어디까지 따라갈 수 있는가.
왜 우리는 한 번에 하나만 했을까
돌이켜보면 1인 1작업은 규칙이라기보다 물리 법칙에 가까웠습니다.
첫째, 코딩 자체가 병목이었습니다.
설계하고, 코드를 작성하고, 테스트를 돌리고, 리뷰를 받는 흐름의 속도는 결국 제가 직접 작업하는 속도에 묶여 있었습니다.
두 작업을 동시에 잡으면 둘 다 눈에 띄게 느려졌습니다.
둘째, 컨텍스트 스위칭 비용이 컸습니다.
브랜치를 옮기면 머릿속도 같이 리셋됐습니다.
어디까지 봤는지, 왜 이렇게 고치려 했는지를 다시 떠올리는 데 시간이 들었습니다.
그래서 IDE 하나, 워킹 트리 하나, 브랜치 하나가 자연스러운 상태였습니다.
스프린트에서도 티켓을 하나 잡아 끝낸 뒤 다음으로 넘어갔습니다.
한 번에 하나에 집중하는 것이 미덕이었던 이유는 간단합니다.
제가 직접 생산해야 했기 때문입니다.
생산자가 한 명이면 생산 라인도 사실상 하나였습니다.
무엇이 바뀌었나: 기다림이 병렬을 불렀다
계기는 거창하지 않았습니다.
에이전트에게 작업을 맡기면 몇 분씩 돌아갑니다.
그동안 저는 화면을 멍하니 보고 있었고, 그 시간이 아까웠습니다.
그래서 다른 터미널을 열고 다른 작업을 시켰습니다.
마침 동시에 처리해야 할 요청이 몰리던 시기였고, 어차피 밀린 일은 많았습니다.
그게 굳어져 지금의 형태가 됐습니다.
요즘 제 아침은 대개 이렇게 시작합니다.
git worktree로 갈라둔 작업 디렉터리마다 tmux 창을 하나씩 열고, 각 창의 Claude Code 세션에 서로 다른 기능을 맡깁니다.
한 세션에서는 조사와 구현을 서브에이전트로 나눠 동시에 돌립니다.
변경이 끝난 세션의 테스트와 자동 코드 리뷰는 백그라운드로 넘기고, 저는 다른 창으로 옮겨갑니다.
코드 창 옆에는 인프라 설정을 만지는 창과 위키나 티켓을 정리하는 창이 나란히 떠 있는 날이 많습니다.
하루의 작업 구조: 판단은 관제탑 하나, 라인은 여럿이 그림에서 제 역할의 중심은 생산 라인 위의 작성자에서 여러 라인을 조율하는 관제사로 옮겨갑니다.
두 방식을 표로 놓고 보면 이렇습니다.
이 표에서 가장 중요한 줄은 “병목”입니다.
코딩 속도가 병목이던 시절에는 손이 하나라서 작업이 하나였습니다.
지금은 코딩 속도가 병목이 아닙니다.
그래서 처음에는 작업 수를 얼마든지 늘릴 수 있을 줄 알았습니다.
실제로는 다른 한계가 금방 나타났습니다.
그런데 사람이 따라가지 못했다
관제사 비유: 레이더에 뜬 열 대 중 교신 중인 것은 세 대항공 관제사를 떠올리게 됐습니다.
관제사는 비행기를 직접 조종하지 않습니다.
대신 여러 대의 움직임을 동시에 살피며 충돌하지 않게 순서를 정하고 착륙을 허가합니다.
비행기가 아무리 좋아져도 관제사가 동시에 교신할 수 있는 비행기 수에는 한계가 있고, 그 한계를 넘기면 비행기 성능과 무관하게 사고가 납니다.
제 경우 그 한계는
대AI시대에 일하는 방식의 변화에 대한 고찰
생성 일시
2026/10/26 23:01
최종 편집 일시
2026/10/26 23:01
태그
무신사
파일과 미디어