Tuned: 혼자 AI 팀과 일할 때 넘기지 않는 것

요즘 많은 사람이 같은 꿈을 판다. 에이전트 쉰 개를 띄워 두고 텔레그램에 명령 한 줄을 보내면, 그중 몇 개가 알아서 반응해 자기들끼리 이야기를 나누고 코드까지 만들어 낸다는 꿈이다. 나는 그런 것을 만들 수 있다. 그래도 만들지 않는다.

내가 보기에 그건 팀이라고 부르기 어렵다. slop을 찍어 내는 기계에 가깝다.

AI를 깎아내리려는 말은 아니다. 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이 먼저다.

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

여섯 번째 에이전트를 붙이는 일은 쉽다. 어려운 건 그 여섯 번째가 한 일을 사인할 수 있을 만큼 이해하는 일이고, 그건 에이전트 수처럼 늘어나지 않는다. 진짜 천장은 거기 있다. 나는 머지 큐 앞에서 리뷰를 하나씩 하며 그 천장에 닿는다.