병목은 애초에 타이핑이 아니었다

AI는 단지 타이핑을 더 빠르게 만든 게 아니다 — 병목 자체를 완전히 옮겨버렸다. 에이전트를 병렬로 돌리는 법을 배운 팀은, 여전히 한 번에 하나의 diff를 기다리고 있는 팀과는 알아볼 수 없을 만큼 달라 보일 것이다.

AI와 함께한 나의 개발 루프의 첫 번째 버전은 단순했다. 어시스턴트에게 A라는 작업을 시킨다. 기다린다. diff를 리뷰한다. B로 넘어간다. 어시스턴트는 더 빠른 페어 프로그래밍 파트너였다. 여전히 페어였다. 여전히 한 번에 하나씩이었다.

그 모델은 약 세 달 지속됐다. 지금 내가 일하는 방식은 그게 아니다.

지금 내가 하는 일은 같은 코드베이스를 상대로 여러 개의 AI 코딩 어시스턴트를 병렬로 돌리는 것이다. 각각 자신만의 git worktree에서, 각각 자신만의 브랜치에서, 각각 동시에 다른 문제를 작업한다. 어느 순간이든 여러 저장소에 걸쳐 다섯에서 열 개의 활성 브랜치가 있다. 서로 다른 에이전트들이 엔진의 서로 다른 부분을 동시에 밀어붙이고 있다. 나는 작성하고 기다리는 대신 리뷰하고 머지한다.

내 일의 이 변화가 이 글의 주제다.

실제 주말은 이런 모습이다

3월 중순의 어느 주말. 다섯 개의 저장소에 걸쳐 토요일 아침식사와 일요일 저녁식사 사이에 112개의 커밋이 들어왔다. 66개는 AI가 기록상의 작성자였다. 47개는 나였다. 나머지는 머지와 리뷰 주도 정리 작업이었다.

이 작업은 하나의 프로젝트가 아니었다. 다섯 개였다. 아홉 개 장르를 위한 WASM 포팅. iOS Metal 렌더러 통합. 일곱 단계 파이프라인을 거치는 스물한 개 에셋의 콘텐츠 팩 러너. 카드 배틀 장르의 5~7단계. 웹 빌드를 위한 성능 최적화. 이 모든 일이 같은 이틀 동안 병렬 브랜치들에서 일어났고, 매일 오후와 저녁마다 들어왔다.

어떤 한 사람도 주방 식탁 책상에서 주말 동안 112개의 커밋을 타이핑하지 못한다. 어떤 한 사람도 다섯 개의 병렬 워크스트림을 한 머릿속에 담고 각각을 위한 코드를 쓸 수 없다. 세 달 전의 나였다면 이번 주말 같은 결과를 만들어내지 못했을 것이다.

지금의 나는 만들어낸다.

병목이 이동한다

작업이 순차적일 때 병목은 타이핑이다. 다음 줄의 코드는 누군가 그것을 쓰기 전까지 존재하지 않는다. AI는 그 줄을 더 빠르게 만들었다. 어느 단계가 느린지를 바꾸지는 못했다.

작업이 병렬일 때 병목은 선택이다. 네 개의 에이전트가 네 개의 diff를 가지고 돌아온다. 그중 둘은 좋다. 하나는 방향은 맞지만 손을 봐야 한다. 하나는 애초에 쓰이지 말았어야 했다. 느린 단계는 어느 것이 어느 것인지 판단하고 살아남은 둘을 머지하는 것이다.

이것은 내가 훈련받은 것과는 완전히 다른 일이다. 타이핑은 줄고, 트리아지는 늘었다. 종합은 줄고, 선택은 늘었다.

주말의 형태는 이랬다.

• 토요일 아침: 문제 설정. 어떤 네 개의 문제가 네 번의 병렬 시도를 할 가치가 있는가. 각각의 성공 기준은 무엇인가. 받아들일 만한 답의 대략적인 형태는 무엇인가.
• 이틀 내내: 스팟 체크. 에이전트들이 궤도를 지키고 있는가? 첫 30분 안에 자신만만하게 틀린 것을 만들어낸 에이전트가 있는가? 막힌 사람이 있는가?
• 양일 늦은 오후: 리뷰와 머지. diff들이 들어온다. 성공 기준을 염두에 두고 하나씩 읽는다. 맞아떨어지는 것을 머지한다. 그렇지 않은 것은 다시 굴리거나 닫는다. 실패한 시도가 그 문제에 대해 내게 무엇을 가르쳐줬는지 기록한다.
• 일요일 끝: 이번 주말이 무엇을 배포했고 다음 네 개의 문제가 무엇인지 적어둔다.

이것은 코파일럿을 둔 시니어 IC라기보다는 네 명으로 이루어진 팀을 둔 테크 리드에 가깝다. 다른 근육을 쓴다. 그 근육들은 여러 영역에 걸쳐 유독 잘 통한다.

이것이 .raku 파일과 결합되는 지점

우리 엔진이 실행하는 경험 파일은 .raku 파일이다. JSON이고, 스키마 버전이 있고, 검증 가능하고, 코드처럼 리뷰할 수 있다. 이 포맷은 애초에 이 병렬 에이전트 워크플로우를 염두에 두고 설계됐다.

에이전트가 .raku 파일을 편집하면 diff는 코드 diff와 똑같은 방식으로 나타난다. 두 번째 에이전트가 첫 번째 에이전트의 작업을 리뷰할 수 있다. 나는 세 번째 에이전트를 돌려서 둘 다 스팟 체크할 수 있다. 머지 판단은 내 몫이다. 이 모든 것이 내가 런타임에 쓰는 것과 같은 풀 리퀘스트 규율 안에 들어맞는다.

만약 .raku가 바이너리 에셋이었다면 이 중 아무것도 작동하지 않았을 것이다. 포맷 선택과 워크플로우 선택은 같은 아키텍처적 결정에서 파생된다. 경험은 코드이고, 개발 작업은 코드 리뷰이며, 에이전트는 그 루프가 코드를 받아들이기 때문에 그 루프에 참여할 수 있다.

파일 포맷은 하중을 지탱하는 구조다. 이것이 바로 팀이 인원수가 아니라 에이전트를 통해 확장할 수 있게 해주는 것이다.

실제로 통하는 것

내가 정착한 세 가지 패턴이 있다.

하나: 문제 하나에 에이전트를 짝지어라. 문제가 사소하지 않을 때, 서로 다른 학습을 받은 두 어시스턴트는 생산적으로 의견이 갈리는 경향이 있다. 나는 같은 프롬프트로 이들을 별도의 브랜치에서 돌리고, 그다음 답을 diff한다. 진짜 리뷰의 주의가 필요한 곳은 그 의견 불일치 지점이다.

둘: 한 에이전트를 리뷰 전담으로 둬라. 나는 그날그날 네 명의 어시스턴트 중 하나를 리뷰 전용 역할로 유지한다. 그것은 절대 초안을 쓰지 않는다. 다른 것들이 만든 diff를 비평만 한다. 전담 리뷰어를 두는 비용은 작다. 버그 포착률은 상당하다.

셋: 에이전트의 컨텍스트를 좁게 유지하라. 하나의 문제에 하나의 브랜치에 있는 하나의 에이전트는 빠르다. 다섯 시간 분량의 컨텍스트를 가진 산만한 문제에 붙어 있는 에이전트는 표류하고 품질이 낮은 결과물을 만든다. 해결책은 문제를 더 작은 조각으로 쪼개고 컨텍스트를 자주 순환시키는 것이다.

무엇이 깨지는가

무엇이 통하지 않는지에 대해서도 정직해지겠다.

조정 오버헤드는 실재한다. 같은 파일을 동시에 건드리는 두 에이전트는 내가 해결해야 하는 머지 충돌을 만들어낸다. 충돌 하나하나의 비용은 작지만 쌓인다. 완화책: 가능한 한 에이전트들을 서로 다른 파일에 두고, 수렴 단계가 워크플로우의 일부라는 것을 받아들인다.

리뷰 피로는 실재한다. 하루의 끝에 네 개의 diff를 리뷰하는 것은 나흘에 걸쳐 순차적으로 네 개의 diff를 리뷰하는 것보다 힘들다. 결정이 더 조밀하다. 나는 작업이 순차적이었을 때보다 병렬 에이전트 날에는 근무일을 더 일찍 끝낸다.

모든 것을 남기고 싶은 유혹은 실재한다. 두 에이전트가 둘 다 그럴듯한 것을 만들어냈을 때, 게으른 선택은 둘 다 머지하는 것이다. 규율 있는 선택은 하나를 고르는 것이다. 둘 다 머지하면 같은 일을 하는 두 가지 방법으로 코드베이스가 오염되는데, 이는 그저 진 쪽을 다시 굴리는 것보다 더 많은 비용이 든다.

장시간 실행되는 병렬 세션에 걸친 컨텍스트 표류는 실재한다. 하루 동안 열려 있던 브랜치는 에이전트가 시작한 순간 코드베이스에 대해 가졌던 가정들을 쌓아간다. 저녁 무렵에는 그 가정들이 낡아 있을 수 있다. 해결책은 가차 없이 짧게 사는 브랜치다.

모든 것이 병렬화되는 것은 아니다. 미묘한 불변식을 가진 크로스커팅 리팩터는 네 번의 병렬 시도가 아니라 한 번의 신중한 패스를 원한다. 기술은 어떤 문제가 깔끔하게 쪼개지고 어떤 문제가 그렇지 않은지 아는 것이다. 어떤 날은 여전히 순차적인 날이다.

엔지니어링 리더에게 이것이 의미하는 바

당신의 팀이 AI를 덧붙인 순차 모델을 돌리고 있다면, 다음 단계는 “더 나은 모델을 쓰는 것”이 아니다. “여러 에이전트를 한 번에 쓰는 것”이다. 역량의 천장이 더 높다. 기술의 천장도 더 높으며, 그것은 시니어의 역할을 생산에서 문제 설정, 검증, 선택으로 옮긴다. 지금 AI를 잘 다루고 있는 다른 모든 분야에서 내가 보는 것과 같은 방향의 이동이다.

앞으로 2년 동안 병렬 에이전트 워크플로우를 알아내는 팀들은, 여전히 순차 모델을 돌리는 팀들과는 알아볼 수 없을 만큼 달라 보일 것이다. 바뀌는 것은 작업의 형태다. 도구가 아니다.

이틀에 걸친 112개의 커밋. 일요일에 대부분이 초록빛인 채로 노트북을 닫는다.