SpotOn: 혼자 AI 팀을 굴리는 법

다들 파는 꿈이 있다. 에이전트 쉰 개를 띄워두고 텔레그램에 명령 한 줄을 던지면, 그중 몇 개가 반응해서 자기들끼리 얘기하고, 코드까지 알아서 나온다. 나는 그걸 만들 수 있다. 하지만 만들지 않는다.

그런 건 팀 근처에도 못 간다. slop을 찍어내는 기계일 뿐이다.

오해는 말자. AI는 나를 훨씬 빠르게 만들었다. 혼자서는 시작할 엄두도 못 냈을 일을 시작하게 해줬다. 펌웨어와 앱과 ML과 PCB를 한 사람이 동시에 미는 건 원래 불가능했는데, 지금은 초안을 대부분 AI 팀이 쓴다. 여기까지는 전부 사실이다.

내가 넘기지 않는 건 딱 하나다. 내가 반드시 알아야 하는 부분, 그리고 내가 결정하는 부분. 그건 끝까지 내가 이해한 채로 쥔다. 그래서 팀-오브-원의 모양을 정하는 건 자율성이 아니라 두 가지다. 각 작업이 틀렸을 때 치르는 값, 그리고 내가 그 결과를 이해한 채로 넘기고 있느냐.

실패의 값이 팀을 정한다

에이전트를 어떻게 나눌지, 처음엔 “무슨 일이냐”로 갈랐다. 리서치, 코딩, 리뷰. 그런데 그 축은 금방 어긋났다. 진짜로 갈리는 기준은 따로 있었다. 이 작업이 틀리면 얼마나 비싼가.

시장 조사나 경쟁 감사, 문서 초안은 틀려도 싸다. 서브에이전트 하나가 헛소리를 해도 열다섯 개 중 하나일 뿐이고, 마지막 synthesis에서 걸러지니까. 그래서 이런 일은 넓게 편다. orchestrator 하나가 subagent 여럿에게 일을 뿌리고, 결과를 다시 모으는 식이다.

코딩은 반대쪽 끝에 있다. 상호의존적인 코어를 두 에이전트가 동시에 건드리면 서로의 가정을 밟는다. ABI가 어긋나고 공유 상태가 깨지면서, 머지가 지옥이 된다. 오류가 걸러지기는커녕 서로 합쳐져 버린다. 그래서 코딩 에이전트는 언제나 한 개만 쓴다. 단일 저자 원칙이다.

저자가 하나여야 나중에 내가 그 코드를 따라갈 수 있다는 이유도 크다. 둘이 붙으면 나부터 뭐가 벌어졌는지 놓친다.

읽기는 넓게, 쓰기는 한 줄로

나만 이렇게 하는 건 아니다. Anthropic도 Cognition도 같은 데 도달했다. 읽기는 병렬로 흩뿌리고, 쓰기는 한 스레드로 좁히라는 것.

다만 솔로한테는 그 이유가 더 독하다. 팀이 있으면 병렬 코딩이 깨져도 누군가 수습하지만, 나는 수습할 사람이 나뿐이다. 되돌릴 여력이 없으니 애초에 오류가 합쳐질 자리를 만들지 않는 쪽을 택한다.

비용 구조도 이 배치를 뒷받침한다. 리서치 한 라운드는 코딩 세션의 열 배 넘는 토큰을 태운다. fan-out이 열대여섯 개 에이전트를 동시에 굴리니 당연하다. 낭비가 크지만, 그 낭비는 전부 싼 자리에 몰려 있다. 틀려도 걸러지는 자리 말이다. 대신 비싼 코딩은 얇게 유지한다. 낭비를 어디에 쌓을지 고르는 것, 그게 설계다.

green인데 틀렸다

값으로 자리를 나눠도 일이 끝나진 않는다. 싸든 비싸든, 에이전트가 뱉은 코드는 여전히 틀릴 수 있다. 그래서 검증이 온다. 여기서는 타협하지 않는다. 값싼 검증부터 순서대로 쌓는다. 컴파일, 테스트, 그다음 적대적 리뷰.

싼 것부터 거는 데는 이유가 있다. 테스트는 통과하는데 실제로는 틀린 코드가 나오기 때문이다. green인데 틀렸다. 2편에서 얘기한 그 계약 버그가 딱 그랬다. 두 모듈이 주고받기로 한 약속이 깨진 버그다. 이번엔 다른 각도로 본다. 테스트는 그 버그를 그냥 통과시켰고, 잡아낸 건 테스트를 못 믿어서 뒤에 붙여둔 적대적 리뷰어였다. 검증을 실패 모드에 맞춰 배치했더니 걸린 것이다.

green이지만 틀린 코드도, 리뷰어가 스스로를 속이는 것도 이미 문서로 남은 실패 모드다. 그래서 검증은 값싼 것부터, 적대적으로 짠다.

리뷰는 승인이 아니라 아는 것

여기가 이 글의 심장이다.

내가 넘기지 않는다고 한 게 바로 이 부분이다. 인간 체크포인트는 세 곳이다. 계획을 승인할 때, 검증 게이트, 그리고 머지 직전. 이 세 곳에서 나는 도장만 찍고 넘어가지 않는다. 이해될 때까지 붙든다.

큰 설계 결정은 내가 아키텍처를 아는 채로만 통과시킨다. 이해가 안 되면 넘기지 않고, 다시 묻고 읽고 쪼갠다. 시간이 걸려도 그렇게 한다.

쉰 개가 자기들끼리 떠들어 완성하면 어떻게 되나. 속도는 얻지만, 아무도 무엇이 만들어졌는지 모르게 된다. 나는 그 거래를 거부한다. 초안은 AI 팀이 대부분 쓰더라도, 결정적인 부분과 큰 설계만큼은 반드시 내가 안다. 사람이 아는 걸 멈추는 순간, 팀은 slop 머신으로 바뀐다.

이 배치가 깨지는 곳

정직하게 말하면 이 모델도 몇 군데서 샌다.

먼저 앎에는 비용이 든다. 그래서 진짜 병목은 나다. 에이전트를 백 개 붙여도 이해하고 승인하는 큐는 나 하나로 남는다. 이 병목을 없애고 싶은 유혹, 그게 곧 slop 머신으로 가는 문이다.

내가 무너지는 지점도 있다. 사소해 보이는 건 나도 이해 없이 넘긴다. 문제는 “사소”와 “결정적”의 경계를 내가 잘못 그을 때다. 사소한 줄 알고 넘긴 게 나중에 아키텍처였던 적이 있다.

단일 저자 세션이 길어지면 앞의 결정을 잊는 context rot도 온다. 적대적 리뷰가 형식만 남으면 green인데 틀린 게 그냥 통과하고, 그러면 검증이 준 확신마저 가짜가 된다.

발주나 계약처럼 되돌릴 수 없는 물리 결정은 아예 이 모델 밖이다. 그건 지난 글에서 다룬 자리다.

roster보다 spine 먼저

누구를 띄울지 고민하기 전에, 어떻게 틀림을 잡을지부터 세워야 한다. roster보다 verify spine이 먼저다.

그래서 에이전트를 늘리고 싶을 때마다 두 가지를 스스로 묻는다. 이 작업은 틀리면 얼마나 비싼가. 싸면 흩뿌리고, 비싸면 한 줄로 좁힌다. 그리고 내가 이걸 이해한 채로 넘기고 있나. 결정적인 부분이라면 이해 없는 승인은 없다.

여섯 번째 에이전트를 붙이는 건 쉽다. 그 여섯 번째가 뭘 했는지 사인할 만큼 이해하는 것, 그게 안 늘어난다. 진짜 천장은 거기 있고, 나는 머지 큐에서 리뷰 하나씩 그 천장에 부딪힌다.