가려움증

스피너와 오르는 토큰 카운트. 방금 코딩 에이전트에게 두 아침을 들여 작성한 명세(spec)를 넘겨주었습니다. 너무 빡빡해서 이미 어떤 diff가 나올지 대략적으로 알고 있습니다. 앞으로 10분, 어쩌면 30분 동안은 작업이 제 손을 떠납니다. 그리고 여기 가려움증이 찾아옵니다: 무언가를 해야 한다, 다른 터미널을 열어야겠다.

이 가려움증을 해소하는 방법은 잘 알려진 두 가지 방식이 있습니다.

첫 번째 진영(Camp one)은 규모를 키우라고 말합니다. 에이전트가 에이전트를 관리하는 방식입니다: Steve Yegge의 Gas Town 오케스트레이터는 한 번에 20~30개의 Claude Code 인스턴스를 실행하도록 구축되었으며, 그는 목적지를 에이전트 플릿(agent fleets) — 즉, 수백 개 이상의 에이전트를 또 다른 에이전트가 감독하는 시스템으로 설명합니다. 두 번째 진영(Camp two)은 이 가려움증 자체가 상처라고 말합니다. 1,488명의 근로자를 대상으로 한 BCG Henderson Institute 연구는 그 피해에

여기에 두 진영 사이의 중간 지점인 세 번째 답이 있습니다. 첫 번째 진영은 엔지니어를 과도하게 몰아붙여 처리량 (Throughput)을 확보하지만, 결국 당신과 제품 모두가 그 대가를 치르게 됩니다. 두 번째 진영은 엔지니어를 보호하지만, 확보된 시간을 활용하기보다는 지켜야 할 대상으로 취급합니다. 즉, 휴식은 되지만 약간은 불만족스러운 상태가 됩니다. 저의 버전은 이렇습니다. 두 번째 진영의 제한 사항을 유지하되, 그로 인해 확보된 시간을 예전에는 업무상 도저히 낼 수 없었던 종류의 사고에 투자하는 것입니다. 에이전트 (Agent)가 작동하는 동안 주어지는 그 10분의 정적은 AI 엔지니어의 하루 중 가장 저평가된 자산입니다.

지연 시간 (Latency)을 소비하라, 채우지 말고

과거의 루프:

생각하기
코딩하기
생각하기
...

새로운 루프:

생각하기
위임하기
더 크게 생각하기
...

변화한 것은 루프의 속도가 아니라, 그 형태입니다.

제 설정은 처방이 아닌 한 실무자의 습관으로서 제안하는 것입니다. 어떤 프로젝트 내에서도: 한 번에 하나의 코딩 작업만 수행하여, 에이전트들이 동일한 작업 복사본(Working copy)에서 충돌하지 않도록 합니다. 전체적으로는: 딱 1개에서 3개의 포그라운드 에이전트 (Foreground agents)만 유지합니다.

만약 당신의 한도가 3개로 제한되어 있고, 그중 하나가 방금 당신의 작업을 가져갔다면, 당신은 스스로 무엇을 할 수 있을까요? 당신은 전환 (Switch)을 해야 합니다. 그리고 여기에는 두 가지 종류의 전환이 있습니다.

프로젝트 전환: 완전히 다른 리포지토리 (Repo)를 집어 듭니다. 현재 저는 다음 세 가지를 번갈아 가며 작업하고 있습니다:

• OR-Tools의 CP-SAT 솔버 (Solver)를 래핑한 저의 프로젝트인 quandary를 오픈 소스로 출시하기 위해 재패키징 및 문서화 작업
• 물리적인 주방 레이아웃에서 직교하지 않는 모서리에 대한 2D 기하학 (Geometry)을 계산하는 새로운 기능 개발
• JavaScript 중심의 스프레드시트 같은 인터페이스를 Datastar 아키텍처로 교체하는 리팩터링 (Refactor)

제약 조건 솔버 (Constraint solvers), 계산 기하학 (Computational geometry), 프론트엔드 아키텍처 (Front-end architecture). 이 작업들의 성격이 매우 다르기 때문에, 이들 사이를 이동하는 것은 작업 전환처럼 느껴지기조차 어렵습니다. 겹치는 것이 없고, 결합된 것도 없으며, 각 작업으로 돌아올 때마다 새로운 시각을 가질 수 있습니다.

또는 기능을 전환합니다: 같은 프로젝트에 머무르되 상위 레벨로 이동하는 것입니다. 에이전트가 이 기능을 구현하거나 테스트하거나 검토하는 동안, 당신은 다음 기능이나 미루어 왔던 수정 사항, 혹은 다음 세 가지 기능을 쉽게 만들 수 있는 리팩터링에 대해 깊이 생각합니다. (위에 언급된 Datastar 작업이 바로 이런 종류입니다: 아직 코드가 없습니다. 저는 여전히 명세(spec)를 정리하고 있습니다.) 에이전트 간에 멀티태스킹을 하지 말고, 추상화 레벨 전반에 걸쳐 멀티태스킹을 하세요.

저는 지난 5년간 자체 스타트업의 CTO로 일하면서 — 명목상 일정 관리를 통제했지만 — 항상 한 기능에서 다음 기능으로 밀어붙이는 압박이 있었습니다. 뒤로 물러서는 것은 결코 항목에 오르지 않았습니다. 에이전트 지연 시간(Agent latency)은 당신이 요청했든 아니든 멈춤을 설치합니다. 아무것도 입력할 것이 없는 여유로운 10분은 사색하기에 좋은 크기입니다: 이 추상화가 여전히 올바른 비유인가? 왜 이 모듈은 계속 예외 처리가 필요한가?

이 밑에는 메커니즘이 존재하며, 많은 엔지니어들이 이미 민간 전승(folklore)을 통해 알고 있습니다. Rich Hickey의 [

이 글을 작성하던 도중 저에게도 그런 일이 일어났습니다. 다음 섹션에서 만나게 될 브루트 포스 (brute-force) 논증을 곱씹으며 하나의 지연 시간 윈도우 (latency window)를 보냈는데, 그것이 모두 주장일 뿐 근거가 없다는 깨달음이 한밤중에 아무런 예고 없이 찾아왔습니다.

피딩 (Feeding)이 윈도우의 유일한 역할은 아닙니다. 많은 윈도우가 단순한 디스패치 (dispatch) — 즉, 현재 실행 중인 그 무엇에도 의존하지 않는 작업을 위한 프롬프트 (prompt)를 작성하는 데 사용됩니다. 하지만 프롬프트는 축소된 형태의 지시 사항이며, 한 단락에 들어가는 명세 (spec)입니다. 그리고 한두 번이 아니라, 빠르게 작성하려던 프롬프트가 계속 커져 결국 다음 명세가 되어버린 적도 있었습니다. 이는 서로 다른 깊이에서 이루어지는 동일한 작업입니다. 에이전트 (agent)를 위한 지시 사항을 작성하는 것이나, 문제 상황을 자신의 머릿속에 로딩 (loading)하는 것이나 마찬가지입니다. 최고의 윈도우는 이 두 가지를 모두 수행합니다.

로딩 (loading)에도 여러 종류가 있습니다. 어떤 윈도우는 문제가 있는 인터페이스나 리팩터링 (refactor)이 필요해 보이는 코드 구간을 읽는 데 사용됩니다. 배경 지식 (background mind)이 이를 포착할 수 있을 만큼 충분히 오랫동안 시야에 두는 것이죠. 어떤 윈도우는 전체 워크플로 (workflow)를 다시 훑으며, 그 형태가 단순히 오래된 결정들의 축적 그 이상인지 자문하는 데 사용됩니다. 그리고 어떤 윈도우는 다음 명세 (spec)로 이어집니다.

마지막 형태는 산업화된 버전인 명세 주도 개발 (Spec Driven Development)으로 나타납니다. 에이전트가 코드를 작성하기 전에 명세, 연구 노트, 계획을 개별적인 아티팩트 (artifact)로 만드는 것입니다. GitHub의 Spec Kit이나 Amazon의 Kiro 같은 도구들은 정확히 이 루프 (loop)를 중심으로 구축되었습니다. 다시 Hickey의 말을 빌리자면, 첫 번째 단계는 문제를 글로 적는 것입니다. 아티팩트는 두 번의 보상을 제공합니다. 그것들을 만들어내는 과정 자체가 사고 과정이며, 명세를 작성하는 것은 종이 위에서 이루어지는 피딩 (feeding) 세션입니다. 그리고 이를 전달하는 과정은 깔끔합니다. 지시 사항이 머릿속의 관념이 아니라 문서가 될 때, 위임 (delegation)은 클로저 이벤트 (closure event)가 됩니다. 주의력의 절반을 뒤에 남겨둔 채로 작업을 완전히 내려놓았다가 나중에 다시 돌아올 수 있게 됩니다.

이것이 치르는 비용

가장 강한 반론부터 말씀드리겠습니다. 작업 전환(Task-switching)은 공짜가 아닙니다. Sophie Leroy의 연구는 그 비용을 '주의력 잔여물(attention residue)'이라고 명명했는데, 이는 이전 작업에 머무르는 정신의 일부를 의미하며, 이 잔여물이 가장 무거운 경우는 해당 작업이 미완성으로 남겨졌을 때였습니다. 멀티태스킹을 추천하는 기사는 이에 대해 답변해야 합니다. 그 답변의 일부는 마지막 섹션에서 깔끔하게 인계되는 부분입니다. 문서화된 결과물로 끝나는 위임(delegation)은 중단이 아니라 완료이며, 잔여물 연구는 중단에 관한 것입니다. 나머지 부분은 대칭성입니다. 에이전트가 당신이 생각하는 도중에 작업을 마칠 경우, 기다리게 하세요. 생각을 완성한 다음 주의를 기울이세요. 캠프 2(camp two)에서는 이를 체크인(check-ins) 배치 처리(batching)라고 부르며, 캠프 2의 주장이 맞습니다.

하지만 모든 것이 완전한 의식을 치러야 하는 것은 아닙니다. Kilo의 엔지니어는 이러한 관행을 구축(building)이라기보다는 정원 가꾸기(gardening)에 비유하며

첫 번째는 리뷰 부채 (review debt)입니다. 에이전트 군단 (the fleet)은 어떤 인간이 정직하게 읽을 수 있는 속도보다 더 빠르게 코드를 생성하며, 그 격차는 복리로 쌓입니다. 즉, 검토되지 않은 결정들이 다음 차례의 생성 단계가 그 위에 구축될 토대가 되어버리는 것입니다.

두 번째는 이것이 무차별 대입 (brute force) 방식이라는 점입니다. 우리는 _The Mythical Man-Month_를 통해 프로젝트가 지연될 때 개발자를 추가하는 것이 프로젝트를 더 지연시킨다는 사실을 알고 있었습니다. 즉, 조정 비용 (coordination costs)이 산출량보다 더 빠르게 증가한다는 것입니다. 에이전트는 인력 (headcount)입니다. 더 저렴하고 지치지 않지만, 결국 인력이며, 빈약한 사양 (spec)에 결합된 에이전트 군단은 '신화적인 에이전트-월 (Mythical Agent-Month)'이 됩니다. 통계적으로 볼 때, 에이전트 군단은 당신의 지시 (direction) 품질을 중심으로 형성된 분포에 대해 best-of-N 샘플링을 수행하고 있는 것입니다. 더 나은 사양은 분포 전체를 이동시키지만, 더 많은 에이전트는 단지 그 분포의 꼬리 부분 (tails)을 탐색할 뿐입니다. 그리고 N은 공짜가 아닙니다. Microsoft의 Experiences and Devices 그룹은 엔지니어당 토큰 비용이 월 500~2,000달러에 달하자 이번 봄에 Claude Code 라이선스 대부분을 취소했습니다. 따라서 제안되는 거래는 다음과 같습니다. 코드에 대한 당신의 이해도가 가장 낮아지는 바로 그 순간에, 빠른 전환 (rapid switching)과 피상적인 검토 (surface-level review)로 당신의 깊은 몰입을 대체하기 위해 실제 돈을 지불하라는 것입니다. 저는 차라리 그만큼의 주의력을 지시 (direction)를 개선하는 데 쓰고 싶습니다.

외부에서 보기에 제 책상도 그들처럼 몇 명의 에이전트와 대화하는 사람처럼 보인다는 점은 인정합니다. 차이점은 그 이면에 있는 것입니다. 검토되지 않은 에이전트 군단이 없으며, 모든 지시 사항은 제가 직접 작성하고, 지연 시간 (latency)은 군단 관리 대신 사고 (thinking)를 위해 사용된다는 점입니다. 만약 당신의 답변이 리뷰 에이전트가 리뷰 부채를 감당할 수 있다는 것이라면, 그것이 무엇인지 주목하십시오. 그것은 빈약한 지시를 보완하기 위한 더 많은 샘플링일 뿐입니다. 에이전트는 서로의 정확성을 확인할 수 있습니다. 하지만 작업이 의도 (intent)와 일치하는지는 오직 그 의도를 가진 사람만이 확인할 수 있습니다.

이제 고백하겠습니다. "더 높은 처리량 (throughput)과 더 높은 품질"은 제가 증명할 수 없는 주장입니다. 집중적인 연습 (focused practice)과 조율된 연습 (orchestrated practice)을 비교하는 연구를 수행한 사람은 아무도 없습니다. 저 또한 반대편의 삶을 살아보지는 못했습니다. 저는 Gas Town과 Conductor를 시도해 보았으나 "과잉 (overkill)" 단계에서 멈췄습니다. 따라서 이것은 생존자의 이야기가 아니라, 메커니즘과 경제성에 대한 비판입니다. 제가 드릴 수 있는 것은 다음과 같습니다: 검토 부채 (review debt)는 관찰 가능한 수준으로 복리로 증가하며, 방향성 품질 — 사실상 판단력 (judgment) — 은 생성된 모든 하위 토큰 (downstream token)에 걸쳐 배가됩니다. 그리고 인접한 증거에 따르면 인지된 속도는 거짓입니다. 우리가 가진 유일한 무작위 대조 시험 (randomized trial)에서, 숙련된 개발자들은 AI가 자신들을 20% 더 빠르게 만들었다고 추정했지만, 실제로는 19% 더 느리게 만들었습니다. 해당 연구의 툴링 (tooling)은 이제 구식이 되었지만, 인지 격차 (perception gap)는 여전히 유효할 것이라고 저는 확신합니다.

한 가지 더 반론이 있을 수 있습니다: 모델들이 계속해서 빨라지고 있으니, 지연 시간 (latency) — 그리고 이 글 — 도 사라지지 않을까요? 저는 그렇지 않다고 생각합니다. 능력 (capability)이 향상되면 우리가 위임하는 범위가 커지며, 작업 (task)은 그저 더 커질 뿐입니다.

월요일 아침

압축된 연습 방법은 다음과 같습니다: