Towards self-driving codebases

Cursor가 수천 개의 에이전트를 일주일 동안 무중단으로 돌려 웹 브라우저를 만들면서 얻은 멀티 에이전트 하네스 설계 기록이다. 자기 조율 방식의 실패에서 시작해 재귀적 플래너와 워커 구조에 도달하기까지의 시행착오, 처리량을 위해 감수한 트레이드오프, 그리고 의도를 명세하는 일의 중요성을 다룬다.

Sourcecursor.com/blog/self-driving-codebases

Towards self-driving codebases

Towards self-driving codebases

장시간 실행되는 자율 코딩의 확장에 관한 저희 연구에 보내주신 반응에 저희는 무척 고무되었습니다.

이 작업은 현재 모델의 한계를 시험하려는 내부 연구로 시작되었습니다. 연구의 일환으로 저희는 수천 개의 에이전트를 오케스트레이션하고 그 행동을 관찰하기 위한 새로운 에이전트 하네스를 만들었습니다. 지난달에 이르러 저희 시스템은 일주일 동안 연속으로 실행될 만큼 안정화되었고, 연구 프로젝트(웹 브라우저)의 커밋 중 압도적인 다수를 이 시스템이 작성했습니다. 이 브라우저는 외부에서 사용될 목적으로 만들어지지 않았고, 저희도 코드에 불완전한 부분이 있으리라고 예상했습니다.

그러나 몇 가지 결함이 있음에도 불구하고, 수천 개의 에이전트가 협력하여 사람의 개입이 거의 없이도 실행 가능한 결과물을 만들어냈다는 사실은 공유할 만한 이정표라고 느껴졌습니다. 그 이후로도 저희는 연구를 계속해왔고, 이 하네스가 어떻게 구축되었는지를 더 깊이 다루고자 합니다.

또한 저희는 이 연구의 일부를 일부 사용자가 직접 사용해볼 수 있도록 공개하고 있습니다.

배경

저희 연구 프로젝트는 제 개인적인 사이드 프로젝트로 출발했습니다.

브라우저는 흥미로운 벤치마크로 느껴졌습니다. 프런티어 모델의 한계를 드러낼 만큼 복잡했고, 서로 맞물려 동작해야 하는 하위 시스템이 여럿 있었습니다.

저의 초기 계획은 JavaScript를 지원하지 않는 상태로 웹 페이지를 렌더링하는 수준까지 만드는 것이었습니다. 저는 Opus 4.5에 브라우저 엔진을 구축하기 위한 상세한 계획을 작성하라고 프롬프트를 주는 것으로 시작했습니다. 그리고 계획을 어디까지 진행하는지 보려고 "계속하라"고 반복해서 재촉했습니다.

이 시도는 금방 실패했습니다. 모델은 자기가 무엇을 하고 있었는지 놓쳤고, 목표에 한참 못 미치는 상태인데도 성공을 선언하며 자주 멈췄으며, 복잡한 구현 세부 사항에서 막혔습니다. 하지만 깊은 지식과 지능의 징후도 보였습니다. 작은 단위의 코드는 잘 작성할 수 있었습니다.

핵심 문제는 브라우저라는 과제가 너무 압도적이어서 하위 작업으로 쪼개져야 했다는 점이었습니다. 다음으로 저는 에이전트에게 병렬로 가져갈 수 있는 주요 작업의 의존성 그래프를 계획하게 했습니다. 에이전트는 작업별로 수동으로 생성되었고, 멈추면 다시 재촉했습니다. 이렇게 하니 처리량은 늘었지만 결과물의 품질은 크게 나아지지 않았습니다. 에이전트들은 서로 소통할 수 없었고, 프로젝트 전체에 대한 피드백을 줄 수도 없었습니다. 시스템은 더 동적일 필요가 있었습니다.

한편 GPT-5.1(이후 GPT-5.2)이 지시를 정확하게 따르는 능력에서 더 나은 결과를 보이기 시작했습니다. 이는 장시간 실행되는 에이전트에 잘 맞아 보였고, 그래서 저희는 이 실험들을 근거로 하네스가 OpenAI 모델을 사용하도록 변경했습니다.

이 시점에서 하네스는 JavaScript 없는 단순한 버전의 웹 브라우저를 만들 수 있었지만, 하나의 에이전트로 완전한 브라우저 엔진을 구축하는 일은 감당하기 어려울 만큼 느렸을 것입니다.

여기서 저희의 다음 연구가 시작되었습니다. 컴퓨트를 10배 더 쓰면 의미 있는 처리량도 10배로 얻을 수 있을까요?

단일 에이전트에서 멀티 에이전트로

저희는 단순한 Rust 기반 하네스로 새로운 저장소를 시작했습니다.

분산 시스템의 복잡성을 감당하는 대신, 저희는 자원이 넉넉한 하나의 대형 Linux VM(가상 머신) 위에서 하네스를 실행했습니다. 하네스를 제어할 때는 VM에 SSH로 접속하여 단순한 터미널 인터페이스를 사용했습니다.

저희는 시스템에 대한 적절한 관측 가능성을 확보하는 데 초기에 더 많은 시간을 들였습니다. 모든 에이전트 메시지, 시스템 동작, 명령어 출력을 타임스탬프와 함께 기록해서 세션을 분석하고 재생할 수 있게 했습니다. 이는 저희가 직접 검토할 때에도 도움이 되었지만, 방대한 데이터를 Cursor에 다시 넣어 훑어보면서 패턴을 빠르게 찾는 데에도 유용했습니다.

자기 조율

저희의 첫 번째 멀티 에이전트 아이디어는 가장 단순했습니다. 동등한 역할을 가진 에이전트들이 공유 상태 파일을 통해 다른 에이전트가 무엇을 작업 중인지 확인하고, 자신이 무엇을 할지 결정하고, 그 파일을 갱신하게 하는 방식이었습니다.

Self-coordination diagram showing agents connecting to a shared coordination file

공유 조율 파일에 에이전트들이 연결되는 모습을 보여주는 자기 조율 다이어그램

저희는 무엇을 해야 하는지에 대해 가장 덜 규정하고, 대신 에이전트들이 스스로 조율하는 방법을 알아내도록 두려 했습니다. 이 방식은 금방 실패했습니다.

조율 파일은 곧 더 많은 문제를 만들어냈습니다. 에이전트들은 락을 너무 오래 붙들고 있었고, 해제하는 것을 잊었으며, 허용되지 않는 상황에서 락을 걸거나 풀려고 시도했고, 전반적으로 조율 파일에 락을 거는 일의 의미를 이해하지 못했습니다. 락은 잘못되기 쉽고 좁은 범위에서만 정확하게 동작하는 메커니즘이며, 프롬프트를 더 준다고 해서 나아지지 않았습니다.

락은 경합도 지나치게 많이 일으켰습니다. 에이전트 20개가 1～3개 수준의 처리량으로 떨어졌고, 대부분의 시간을 락을 기다리는 데 썼습니다. 저희는 다른 에이전트의 작업을 명시적으로 기다리는 도구를 에이전트에게 줘봤지만, 그들은 그 도구를 거의 사용하지 않았습니다. 락이 없는 낙관적 동시성 제어 방식도 시도했는데, 오버헤드는 줄었지만 혼란이 사라지지는 않았습니다.

에이전트들 사이에 구조가 없다는 것은, 어떤 에이전트도 크고 복잡한 작업을 떠맡지 않는다는 뜻이었습니다. 그들은 경합과 충돌을 피했고, 프로젝트 전체에 대한 책임을 지기보다는 더 작고 안전한 변경을 선택했습니다.

구조와 역할 추가하기

다음으로 저희는 에이전트에게 소유권과 책임을 부여하기 위해 역할을 분리했습니다.

Structured roles diagram showing Planner, Executor, Workers, and Judge in a pipeline

플래너, 실행자, 워커, 심판이 파이프라인을 이루는 구조화된 역할 다이어그램

먼저 플래너가 사용자의 지시를 향해 진전을 만들어낼 정확한 접근 방식과 산출물을 제시합니다. 이것이 실행자(executor)에게 넘겨지고, 실행자는 계획이 완전하게 달성되도록 보장할 책임을 지닌 단일 리드 에이전트가 됩니다. 실행자는 워커를 위한 작업을 생성할 수 있었고, 이는 선형적인 확장과 처리량을 제공했습니다.

지속적인 진행과 책임 확보를 위해, 실행자가 끝난 뒤에 독립적인 심판(judge)이 실행되어 작업이 완료되었는지, 그리고 루프를 한 번 더 실행해야 하는지를 판단했습니다. 이 구조는 많은 조율 문제를 해결했습니다. 실행을 소유하고 감독하는 데 전념하는 단일 역할이 있었기에, 워커들은 자신의 작업에 좁게 집중할 수 있었고 그러면서도 전체 시스템은 결과물을 만들어냈습니다.

관찰과 점진적 개선

이 설계에 도달하기까지는 시스템을 면밀히 관찰해야 했습니다.

중대한 문제가 있으면, 그것은 여러 에이전트와 여러 도구 호출에 걸쳐 반복적으로 나타나는 경향이 있었습니다. 예를 들어 저희는 많은 에이전트가 동시에 git restore를 실행하고 있었기 때문에 경합이 과도하다는 점을 발견했습니다. 저희는 Cursor를 사용해 로그를 분석하고 그것을 저희 프롬프트와 대조해서, 왜 행동이 기대와 어긋나는지 이해했습니다.

결국 저희는 가장 느린 워커가 이 시스템의 병목을 만든다는 사실을 발견했습니다. 너무 경직되어 있었습니다.

모든 계획을 앞단에서 세운다는 점 또한 새로운 문제가 발견되었을 때 시스템이 동적으로 재조정하기 어렵게 만들었습니다. 일부 에이전트는 역효과를 내는 방향으로 나아가면서도, 루프의 다음 반복이 오기 전까지는 스스로를 교정하지 못했습니다.

연속 실행자

다음 버전에서는 독립적인 플래너를 제거했습니다.

이제 실행자는 작업을 생성하는 일에 더해 목표를 달성할 방법을 계획하는 일까지 할 수 있었습니다. 단일 에이전트였기 때문에, 계획을 어딘가에 기록할 필요도, 변하지 않는 하나의 정적인 계획을 고수할 필요도, 모든 워커를 경직되게 기다릴 필요도 없었습니다.

신선도 보장하기

모든 역할의 에이전트가 긴 시간 동안 표류하지 않도록, 저희는 신선도(freshness) 메커니즘을 도입했습니다.

  1. scratchpad.md는 내용을 덧붙이는 대신 자주 다시 작성되어야 합니다.
  2. 개별 에이전트는 컨텍스트 한계에 도달하면 자동으로 요약해야 합니다.
  3. 저희는 시스템 프롬프트에 자기 성찰과 정렬 리마인더를 추가했습니다.
  4. 에이전트는 언제든지 방향을 전환하고 가정에 의문을 제기하도록 권장되었습니다.

이제 시스템은 매우 동적이고 유연해졌습니다. 코드를 능동적으로 탐색하고, 결정을 재고하고, 워커를 관리하고, 작업을 교차 수행하고, 최신 정보를 지속적으로 반영할 수 있었습니다. 저희는 에이전트들이 지시를 완수할 때까지 따르는 데 꽤 능하다는 것을 확인했고, 그래서 시스템을 단순하게 유지하기 위해 심판을 제거했습니다.

Continuous executor diagram showing an infinite executor loop with workers

워커와 함께 무한히 도는 실행자 루프를 보여주는 연속 실행자 다이어그램

병리적 행동

이러한 개선에도 불구하고, 연속 실행자는 병리적인 행동을 보이기 시작했습니다. 무작위로 잠들고, 에이전트를 실행하다 멈추고, 작업을 스스로 해버리고, 계획을 세우거나 좁게 집중된 작업을 몇 개 이상 생성하기를 거부하고, 워커의 변경 사항을 제대로 병합하지 않고, 완료되지 않았는데도 완료를 주장했습니다.

저희는 실행자에게 너무 많은 역할과 목표가 동시에 주어지고 있었다는 것을 발견했습니다. 계획 수립, 탐색, 조사, 작업 생성, 워커 점검, 코드 리뷰, 편집 수행, 산출물 병합, 그리고 루프가 끝났는지 판단하는 일까지 모두 포함되어 있었습니다. 돌이켜보면 실행자가 압도당한 것은 당연한 일이었습니다.

최종 시스템 설계

최종 설계는 저희가 얻은 모든 학습을 반영합니다.

  1. 루트 플래너가 사용자 지시의 전체 범위를 소유합니다. 루트 플래너는 현재 상태를 이해하고 목표를 향해 진전을 만들 구체적이고 표적화된 작업들을 전달할 책임을 집니다. 루트 플래너 자신은 코딩을 전혀 하지 않습니다. 자신이 만든 작업을 누가 처리하고 있는지, 처리되고 있기는 한지도 알지 못합니다.
  2. 플래너가 자신의 범위를 세분화할 수 있다고 판단하면, 위임된 좁은 조각을 온전히 소유하는 서브플래너를 생성합니다. 서브플래너도 같은 방식으로 완전한 소유권을 갖되, 그 조각에 대해서만 갖습니다. 이 구조는 재귀적입니다.
  3. 워커는 작업을 가져와서 그것을 완료까지 끌고 갈 책임을 단독으로 집니다. 워커는 더 큰 시스템의 존재를 알지 못합니다. 다른 어떤 플래너나 워커와도 소통하지 않습니다. 워커는 저장소의 자기 사본 위에서 작업하고, 완료되면 하나의 인계 문서(handoff)를 작성하며, 시스템이 이를 작업을 요청한 플래너에게 제출합니다.

흥미롭게도 이 구조는 오늘날 일부 소프트웨어 팀이 실제로 일하는 방식을 나타냅니다.

Final system design showing recursive planners, sub-planners, workers, and git

재귀적인 플래너, 서브플래너, 워커, Git을 보여주는 최종 시스템 설계

서브플래너는 워커를 빠르게 팬아웃시켜 처리량을 늘리면서도, 시스템 전체를 여전히 어떤 에이전트가 완전히 소유하고 책임지도록 보장합니다. 이는 단일 플래너였다면 압도당해서 시야가 좁아졌을 대규모 프로젝트와 작업에도 도움이 되었습니다.

인계 문서에는 무엇을 했는지만이 아니라, 중요한 메모, 우려 사항, 계획에서 벗어난 부분, 발견한 사실, 생각, 피드백이 함께 담깁니다. 플래너는 이를 후속 메시지로 받습니다. 이 구조는 시스템을 계속 움직이게 합니다. 플래너가 "완료" 상태이더라도 계속해서 업데이트를 받고, 최신 저장소를 가져오고, 이어서 계획을 세우고 후속 결정을 내릴 수 있습니다.

모든 에이전트가 이 메커니즘을 갖추고 있으며, 덕분에 시스템은 대단히 동적이고 스스로 수렴하는 성질을 유지합니다. 전역 동기화나 상호 대화의 오버헤드 없이, 정보가 점점 더 전역적인 시야를 가진 소유자에게로 사슬을 따라 전파됩니다.

통합자 제거

저희는 원래 전역을 인지하는 중앙 품질 관리를 위해, 그리고 너무 많은 워커가 동시에 푸시, 리베이스, 충돌 해결, 병합을 시도하면서 생기는 경합을 없애기 위해 통합자(integrator)를 두었습니다.

통합자는 금세 명백한 병목이 되었습니다. 수백 명의 워커가 있는데 모든 작업이 통과해야 하는 관문(즉 "레드 테이프")이 하나뿐이었습니다. 저희는 프롬프트를 바꿔봤지만, 결국 통합자가 불필요하며 시스템을 단순하게 만들기 위해 제거할 수 있다고 결론지었습니다.

처리량과 트레이드오프

시스템은 일주일 동안 1,000만 회의 도구 호출에 걸쳐 시간당 약 1,000건의 커밋으로 정점을 찍었습니다. 시스템이 시작된 뒤로는 저희의 개입이 전혀 필요하지 않았습니다.

이 처리량을 달성하기 위해 의도적으로 감수한 트레이드오프가 있었습니다.

커밋 정확성

저희가 모든 커밋 이전에 100% 정확성을 요구했을 때, 이는 심각한 직렬화와 실효 처리량의 저하를 일으켰습니다. API 변경이나 오타 같은 작은 오류 하나만으로도 전체 시스템이 멈춰 섰습니다. 워커들은 자기 범위를 벗어나 상관없는 것들을 고치기 시작했습니다. 많은 에이전트가 같은 문제를 고치겠다고 몰려들어 서로의 작업을 방해했습니다.

이런 행동은 도움이 되지도, 필요하지도 않았습니다. 어느 정도 여유를 허용한다는 것은 동료 에이전트가 다른 문제들을 곧 고쳐 주리라고 에이전트가 신뢰할 수 있다는 뜻이며, 시스템이 코드베이스 전체에 대해 실효적인 소유권과 위임 구조를 갖고 있으므로 이는 실제로 참입니다. 오류는 발생하고, 그다음 빠르게 고쳐집니다. 오류율은 작고 일정하게 유지되며, 완전히 깨끗한 상태는 드물지언정 폭발하거나 악화되지 않고 안정적이고 관리 가능한 수준을 유지합니다.

이는 이상적인 효율적 시스템이 일정한 오류율을 받아들이되, 어떤 에이전트가 정기적으로 스냅숏을 찍고 릴리스 전에 간단한 정리 작업을 수행하는 최종 "그린" 브랜치는 필요하다는 점을 시사할 수 있습니다.

동기화 오버헤드

때로는 여러 에이전트가 같은 파일을 건드리거나 같은 코드를 리팩터링합니다. 저희는 이를 완전히 근절하거나 과도하게 설계된 해법을 만들려고 시도하는 대신, 잠깐의 난기류를 받아들이고 시스템이 짧은 시간 안에 자연스럽게 수렴하여 안정되도록 둡니다.

이 방식은 토큰을 조금 더 소모하고 국소적인 경합을 만들지만, 시스템 전체를 더 단순하게 유지합니다. 모델을 정렬시키기가 쉽고 모델을 압도하지 않으며, 관리하고 관찰하기가 쉽고, 마찰이 적으며, 전역적인 생산성이 더 좋습니다. 지나치게 복잡한 접근을 피할 수 있다는 이점도 있습니다.

인프라에서 배운 것

각각의 멀티 에이전트 실행은 시스템 자원이 넉넉한 자체 대형 머신 위에서 이루어졌는데, 이는 분산 시스템에 관한 복잡성이 너무 이르게 들어오는 것을 피하기 위함이었습니다. 대부분의 실행이 수백 개의 에이전트에서 정점을 찍었고 이는 대체로 머신을 포화시키되 초과하지는 않았기 때문에, 이 구성은 잘 맞았습니다. 이 아키텍처는 시스템 지표를 관찰하고, 필요할 때 상태를 공유하고 복사하기도 더 쉽게 만들었습니다.

에이전트의 RAM 사용량을 제한하고 나자 디스크가 병목 지점이 되었습니다. 특히 모놀리스 프로젝트에서는 수백 개의 에이전트가 동시에 컴파일하면서 빌드 산출물을 초당 수 GB씩 읽고 썼습니다. 이는 하네스의 전체 처리량에 상당한 영향을 주었고, 흥미로운 교훈이었습니다. 프로젝트 구조, 아키텍처 결정, 개발자 경험이 토큰과 커밋 처리량에 영향을 줄 수 있다는 것입니다. 이상적으로는 생각하고 코딩하는 데 시간이 쓰여야 하는데, 코드베이스를 다루는 일(예를 들어 컴파일)이 시간을 지배해버리기 때문입니다.

일반적인 개발 환경에도 제약과 비효율이 있었습니다. 단일 사용자 워크스페이스에서는 타당하거나 대수롭지 않은 것들이, 수백 개의 에이전트가 한 머신에서 같은 일을 할 때에는 두드러질 수 있습니다. 이를 해결하는 사소한 방법 한 가지는 각 에이전트에게 자기 머신을 주는 것입니다. 하지만 이런 원시 도구들 중 일부를 다시 생각하고 다시 설계하는 것만으로도 큰 효율 향상을 얻을 수 있는, 흥미로운 저비용 기회들이 있습니다.

예를 들어 Git과 Cargo 같은 많은 도구는 단순한 동시성 제어 메커니즘으로서 공유 락을 사용합니다. 데이터베이스처럼 잘 확립된 동시성 시스템의 메커니즘을 가져오면 이들이 멀티 에이전트 시스템에서도 똑같이 잘 동작하게 만들 수 있을까요? 모든 에이전트가 저장소의 자기 사본을 갖고 있지만 대부분의 파일과 산출물은 동일한데, 더 정교한 프로덕션 스토리지 시스템에서 볼 수 있는 단순한 copy-on-write와 중복 제거 기능을 추가하면, 별도의 인프라를 구축하지 않고도 전형적인 "단일 사용자" 시스템에 비슷한 손쉬운 이득을 가져올 수 있을까요?

에이전트에게 의도를 명세하기

이 멀티 에이전트 시스템에 주어지는 지시는 매우 중요했습니다.

처음에 저희는 지시를 주된 목표로 삼지 않았고, 대신 안정적이고 효과적인 하네스를 목표로 했습니다. 하지만 지시의 중요성은 금방 분명해졌습니다. 저희는 본질적으로 전형적인 코딩 에이전트와 상호작용하고 있었는데, 다만 시간과 컴퓨트가 몇 자릿수 더 많았습니다. 이는 최적이지 않거나 불명확한 지시를 포함해 모든 것을 증폭시킵니다.

초기 지시에 더 많은 시간을 쓰는 것은 합리적입니다. 결국 에이전트는 여전히 에이전트입니다. 여러분의 지시를 엄격히 따르고, 그 경로를 따라 내려가며, 지시가 나쁘더라도 그것을 바꾸거나 뒤집지 않도록 훈련되어 있습니다.

저희는 연구 프로젝트에서 성공을 보고 싶었기 때문에, 프로젝트와 하네스가 진화하는 동안 초기 지시를 수정했습니다. 저희는 이 새로운 멀티 에이전트 시스템을 운용하는 법을 배우는 것과 나란히 브라우저를 만드는 법을 배우고 있었고, 빈약하거나 충분히 명세되지 않은 사양이 결과물의 품질에 그대로 반영되는 것을 볼 수 있었습니다. 이는 하네스 자체의 문제가 아니었습니다. 하네스는 그저 저희의 지시를 정확히 따랐을 뿐입니다.

브라우저 프로젝트에서 나온 몇 가지 사례입니다.

JavaScript 없는 단순 브라우저의 첫 번째 버전은 완전한 브라우저로 발전시키기에 부적합한 아키텍처로 수렴했습니다. 이는 초기 사양의 실패였습니다.

마찬가지로 에이전트들에게 이 프로젝트가 처음부터 만드는 브라우저라고 말해줬음에도, 그들은 직접 구현할 수 있었을 의존성을 일부 끌어왔거나, 제대로 된 구현이 진행되는 동안 임시 발판으로 사용했습니다. 이는 지시의 누락이었습니다. 이후의 실행에서는 의존성 철학과 사용해서는 안 되는 라이브러리를 명시적으로 규정했고, 그것으로 이 문제가 교정되었습니다.

그 이후의 실행에서는 모놀리스에서 벗어나 여러 개의 자족적인 크레이트로 나누는 대규모 재구조화도 이루어졌습니다. 저장소는 심하게 깨진 상태였지만, 멀티 에이전트 시스템은 며칠 만에 동작하는 코드로 수렴했습니다. 이는 시스템이 협력적이고 지능적으로 작업할 수 있는 강한 역량을 지녔음을, 그리고 완전히 깨진 상태에서 더 나빠지거나 멈춰버리는 대신 그 상태를 버텨낼 수 있음을 보여주었습니다. 이 실행은 컴파일을 기다리는 데 쓰는 시간도 훨씬 적어서, 이전보다 몇 배 높은 처리량으로 돌아갔습니다.

아키텍처와 지시는 중요합니다. 에이전트는 막대한 엔지니어링 역량을 갖고 있지만, 좋든 나쁘든 지시를 끝까지 따라갑니다. 지나치게 좁은 지표와 구조 없는 자유 사이에서 균형을 찾는 일은 까다로웠고, 무엇이 자명하고 무엇을 명시적으로 언급해야 하는지 아는 일도 마찬가지였습니다.

이 모든 것은 의도를 이끌어내고, 명세하고, 이해하는 일이 중요하다는 점을 가리키며, 이 중요성은 이런 규모에서 한층 더 커집니다. 조종 가능성(steerability)과 관측 가능성(observability)은 계속 탐구할 만한 흥미로운 연구 영역이 될 것입니다.

프롬프트 최적화

프롬프팅은 이 진화 과정에서 상당한 비중을 차지했습니다.

저희는 모델이 이미 할 줄 아는 것에 대해서는 지시하지 않고, 모델이 모르는 것(예를 들어 멀티 에이전트 협업)이나 해당 도메인에 특수한 것(예를 들어 테스트를 실행하는 방법, 여러분의 배포 파이프라인)에 대해서만 지시하는 편이 낫다는 것을 발견했습니다. 모델을 엔지니어링은 알지만 여러분의 특정 코드베이스와 절차는 모르는, 뛰어난 신입 직원처럼 대하십시오.

제약이 지시보다 효과적입니다. "TODO 금지, 부분 구현 금지"가 "구현을 마무리하는 것을 잊지 마세요"보다 잘 동작합니다. 모델은 일반적으로 기본적으로 좋은 일을 합니다. 제약은 그 경계를 정의하는 것입니다.

더 상위 수준이거나 더 깊은 작업에서는 체크박스식 사고방식을 피하십시오. 여러분의 의도에 관해서는 상세한 지시를 주되, 구체적으로 할 일을 지정하면 모델이 더 넓은 범위보다 그 지정된 것들을 달성하는 데 집중하는 경향이 있다는 점을 기억하십시오. 또한 목록에 없는 것들의 우선순위를 암묵적으로 낮추게 됩니다. 대체로 모델이 자신의 판단과 주도성을 사용하도록 두는 편이 낫습니다.

다만 범위의 양을 논할 때 구체적인 숫자와 범위를 주는 것은 유용하다는 점을 확인했습니다. "작업을 많이 생성하라" 같은 지시는 적은 양을 만들어내는 경향이 있습니다. 보수적인 기본값이고, 안전하게 가는 것이며, 기술적으로는 여전히 지시를 따른 것입니다. "작업을 20～100개 생성하라"는 의도가 더 큰 범위이고 야심적이어야 한다는 것을 전달하며, 저희는 전반적으로 매우 다른 행동을 관찰했습니다.

시스템 설계에서 배운 것

저희는 연구를 통해 몇 가지 원칙을 세웠습니다.

  1. 시스템은 안티프래질해야 한다. 동시에 실행되는 에이전트의 수를 늘릴수록 실패 확률도 함께 올라갑니다. 저희 시스템은 개별 에이전트가 실패하더라도 견뎌내며, 다른 에이전트가 복구하거나 대안적인 접근을 시도할 수 있어야 합니다.
  2. 가정이 아니라 경험적 데이터를 따른다. 저희는 인간 조직이나 기존 시스템 설계에 기반한 가정을 갖고 들어가는 대신, 데이터와 관찰을 사용해 조정하기를 원했습니다.
  3. 처리량을 명시적으로 설계한다. 이는 코딩의 다른 측면을 트레이드오프한다는 뜻이었습니다. 시스템을 극적으로 느리게 만드는 100% 완벽하게 동작하는 코드 대신, 작지만 안정적인 오류율을 받아들이고 최종 조정 작업을 두는 쪽을 택했습니다.

이런 시스템은 제대로 만들어졌을 때 우아하게 단순해지는 경향이 있지만, 어떤 단순한 접근이 통할지는 여러 다른 접근을 탐색해보기 전까지 분명하지 않았습니다. 현재의 시스템 설계는 최소한의 오버헤드로 실행되어 왔고, 토큰 처리량의 선형적인 확장을 유용한 방식으로 제공합니다. 하네스에 대한 추가적인 대규모 반복은 더 이상 필요하지 않았습니다.

결론

취향과 판단과 방향은 사람에게서 나왔지만, AI는 이 연구를 빠르게 반복하고 탐색하는 데 상당한 힘의 증폭기였습니다.

이는 AI가 AI를 개발하는 데 사용되고, 모델과 에이전트와 하네스가 좋아질수록 그것이 자기 자신에게 되먹여져 점점 더 빠르게 가속되는 "선순환" AI 루프와 어느 정도 닮아 있습니다. 저희는 저희를 빚어내는 도구를 빚어냅니다.

이 연구에는 오늘날 일부 소프트웨어 팀이 일하는 방식과 시적으로 닮은 면이 있습니다. 이 모델들은 그런 방식으로 명시적으로 훈련되지 않았는데, 이는 그것이 창발적 행동임을, 그리고 어쩌면 소프트웨어 프로젝트를 구조화하는 올바른 방식임을 시사합니다.

저희는 극도로 오래 실행되는 에이전트에 관한 연구를 계속할 것이며, 그 결과는 저희 제품의 미래에 반영될 것입니다.

Deep Dive

2026-09-11

회사로 수렴한 것이 아니라, 같은 제약으로 수렴했다

AI를 쓰면 쓸수록 그 발전 과정이 인류가 수백 년간 쌓아온 회사라는 시스템으로 귀결되는 것처럼 보인다는 관찰에서 이 논의가 시작되었다. 이 글의 시스템 설계 원칙 2번을 보면 저자들은 인간 조직에 기반한 가정을 갖고 들어가는 대신 데이터와 관찰로 조정하겠다고 했다. 회사를 흉내 내지 않으려고 의식적으로 노력했는데도 회사와 닮은 것이 나온 것이므로, 이는 수렴 진화다.

수렴 진화가 말해주는 것은 정답이 회사라는 점이 아니라 양쪽이 같은 제약을 받는다는 점이다.

회사는 이 제약에 대한 인류의 답이고 Cursor의 하네스는 같은 제약에 대한 다른 답이다. 닮은 이유는 문제가 닮았기 때문이다.

한 가지 더 좁혀야 한다. Cursor가 도달한 것은 회사 일반이 아니다. 실패한 설계들도 전부 실제로 존재하는 조직 형태다. 공유 파일로 자율 조율하는 방식은 수평 조직이고, 플래너-실행자-심판 파이프라인은 워터폴이며, 모든 역할을 짊어진 연속 실행자는 만능 관리자다. 전부 실제 회사에서도 잘 안 되는 형태다. 최종 설계가 닮은 것은 특정한 한 가지, 임무형 지휘(Auftragstaktik)를 쓰는 군대와 아마존처럼 그 사상을 받아들인 소수의 회사가 쓰는 형태다.

그 형태를 쓰는 조직들의 공통점은 원리 수준에서 꽤 일관된다.

  1. 모든 범위에 단일 소유자가 있다. 애플의 DRI(Directly Responsible Individual), 아마존의 single-threaded owner가 이것이고, Cursor의 재귀적 플래너가 정확히 이 구조다. 수평 조직에서 아무도 큰 일을 맡지 않고 작고 안전한 변경만 고른 것은 책임 분산의 전형적인 증상이다.
  2. 절차가 아니라 의도를 전달한다. 프로이센 군대에서 시작된 임무형 지휘의 핵심은 지휘관의 의도를 전달하고 실행은 현장에 맡기는 것이다. 현장이 지휘관보다 더 많은 국소 정보를 갖기 때문이다. 넷플릭스의 "통제가 아니라 맥락", 이 글의 "제약이 지시보다 효과적이다"와 "똑똑한 신입처럼 대하라"가 같은 사상이다.
  3. 필요한 소통을 설계로 최소화한다. 제이 갈브레이스는 조직을 정보 처리 시스템으로 봤고, 좋은 구조란 의사결정 지점에 흘러야 하는 정보량을 줄이는 구조다. Cursor에서 워커가 서로 대화하지 않고 플래너가 누가 작업을 받았는지조차 모르는 것은 정보 은닉을 의도적으로 설계한 결과다.
  4. 일 자체를 분해 가능하게 만든다. 사이먼의 "거의 분해 가능한 시스템"이다. 조직도를 아무리 잘 그려도 일이 서로 얽혀 있으면 소용이 없다. 크레이트 재구조화가 처리량을 몇 배 올린 것이 이 원리의 실증이며, 콘웨이 법칙의 역방향으로 코드 구조가 조직의 처리량을 결정했다.
  5. 병렬 작업에서는 국소 결함으로 전체를 세우지 않는다. 여기서 도요타와 갈린다. 도요타의 안돈 코드는 결함 하나에 라인 전체를 세우는데, 그것이 통하는 이유 중 하나는 라인이 직렬이라 결함이 하류로 갈수록 비싸지기 때문이다. Cursor의 시스템은 대규모 병렬이라 하나가 멈추면 전부 멈추므로 정반대의 선택을 했다. 어떤 시스템이 최선인지는 일의 위상에 따라 달라진다.
  6. 가정이 아니라 관찰로 조정한다. 현장을 직접 확인한다는 원칙이며, 로그를 전부 남기고 패턴을 찾은 것이 여기에 해당한다.

그런데 회사 시스템의 상당 부분은 위의 제약이 아니라 인간의 본성을 다루기 위해 존재하며, 그 부분은 에이전트에 옮기면 안 된다.

정리하면, 제약에서 나온 원리는 가져오고 인간 본성에서 나온 장치는 버리고 에이전트만의 새 조건을 더한다. 의도 문서에 시간을 쓴다. 모든 작업에 단일 소유자를 둔다. 제도적 기억을 파일로 외부화한다. 코드베이스를 분해 가능하게 만든다. 관측 가능성을 먼저 만든다. 국소 오류를 허용하고 경계에서 정리한다. 야심은 명시적으로 넣는다.

지휘관과 편집자: 사람이 언제 개입하는가

Cursor는 심판도 통합자도 제거했다. 둘 다 품질 관문이고, 인간 회사에서 품질 관문은 대개 시니어의 취향이 들어오는 자리다. 관문을 다 없애면 취향은 어디로 들어가는가. 이 글의 답은 사전과 사후다. 초기 지시에, 그리고 관측 루프에 들어가고, 실행 중에는 아무 데도 없다. "이 라이브러리를 쓰지 마라"는 제약은 취향이 규칙으로 압축된 것이다.

여기서 사람의 역할이 두 가지로 갈린다. 두 역할의 차이는 언제 개입하느냐다.

지휘관은 일이 시작되기 전에 개입한다. 의도와 제약을 잘 써서 넘기고, 그다음에는 결과물을 하나하나 들여다보지 않는다. 부대에 판단력이 있다고 믿기 때문이다. 사람의 시간은 입력에 들어간다.

편집자는 일이 끝난 후에 개입한다. 시스템이 초안을 만들어 오면 읽고, 고치고, 돌려보낸다. 초안이 규칙은 다 지켰는데 어딘가 어색하기 때문이다. 사람의 시간은 출력에 들어간다. 여기서 편집자는 원고를 받아 다듬는 출판 편집자를 뜻한다.

에이전트 100개에게 설정 페이지를 만들라고 시키는 상황으로 보면 이렇다. 지시문은 같다. 디자인 시스템을 따를 것, 새 의존성 금지, 접근성 준수, 기존 앱의 어조와 맞출 것. 취향이 에이전트에 분산될 수 있다면 에이전트들은 규칙에 없는 것도 알아서 판단한다. 여기는 모달보다 인라인 폼이 낫다거나 이 간격은 다른 화면과 어울리지 않는다는 판단을 규칙 없이도 한다. 사람은 지시문에 한 시간을 쓰고 마지막에 전체를 한 번 훑어보면 끝난다. 취향이 분산될 수 없다면 에이전트들은 규칙은 전부 지키지만 규칙이 예상하지 못한 부분은 전부 이상하게 나온다. 사람은 화면을 하나하나 읽고 메모를 달아서 돌려보내야 한다.

이것이 중요한 이유는 지휘관 역할만 규모가 커지기 때문이다. 의도 문서는 한 번 쓰면 에이전트가 100개든 1,000개든 같은 비용이다. 반면 편집은 결과물 수에 비례한다. 에이전트 1,000개가 시간당 커밋 1,000건을 만들어도 사람이 그것을 시간당 1,000건 읽어야 한다면 처리량은 사람의 읽기 속도로 다시 떨어지고, 멀티 에이전트로 얻은 이득이 전부 사라진다.

그래서 "취향을 분산시킬 수 있는가"라는 질문은 사실 "사람이 결과물 하나하나를 보는 루프에서 빠져나올 수 있는가"라는 질문이다. Cursor 팀은 지휘관 쪽에 걸었다. 사람의 개입은 초기 지시와 로그 패턴 분석에만 있었고 커밋을 개별적으로 검토한 적이 없으며, 그 대가로 결함이 있는 브라우저를 받아들였다. 반면 지금 대부분의 사람이 코딩 에이전트를 쓰는 방식은 편집자다. 시키고, diff를 읽고, 고치라고 한다.

취향은 절차로 압축되는 만큼만 분산된다

취향 분산의 답을 회사에서 찾는다면 일론 머스크가 가장 좋은 사례이면서 동시에 가장 좋은 반례다. 여러 회사를 동시에 유지하면서 각 회사에서 성과를 낸다는 전제는 절반만 맞다. 테슬라와 SpaceX는 산업을 바꿨지만 Boring Company는 작고, Neuralink는 초기이고, X(트위터)는 인수 후 기업 가치가 크게 떨어졌다. 이 편차는 우연이 아니며, 편차 자체가 "취향을 분산시킬 수 있는가"에 대한 답이다.

아이작슨의 전기에 정리된 내용을 기준으로 보면 다섯 가지 장치가 보인다.

  1. 취향을 절차로 압축한다. 가장 중요한 장치다. SpaceX와 테슬라의 모든 엔지니어가 아는 "알고리즘"이 있다. 모든 요구사항을 의심하라, 각 요구사항에는 부서가 아니라 사람 이름이 붙어 있어야 한다. 삭제할 수 있는 부품과 절차는 전부 삭제하라, 나중에 10%를 되돌리지 않았다면 충분히 삭제하지 않은 것이다. 삭제한 뒤에야 단순화하고 최적화하라. 그다음 주기를 단축하라. 자동화는 맨 마지막에 하라. 완성 부품 가격을 원자재 가격으로 나눈 idiot index, 비유가 아니라 물리 법칙에서 출발하는 제1원리 사고도 같은 종류다. 이것들의 공통점은 생성적이라는 점이다. "TODO 금지" 같은 제약은 하지 말아야 할 것을 정할 뿐이지만, 이 절차들은 아무도 예상하지 못한 상황에서 어떻게 결정해야 하는지를 알려준다. 머스크가 그 자리에 없어도 엔지니어가 머스크처럼 결정할 수 있다. 취향이 사람에게서 분리되어 절차가 된 것이다.
  2. 취향이 필요한 표면을 줄인다. 삭제 편향은 그 자체로 분산 전략이다. 요구사항이 절반이면 판단이 필요한 자리도 절반이다. Cursor가 심판과 통합자를 없앤 것도 같은 종류의 삭제다.
  3. 사람을 선별하고 흡수시킨다. 극단적으로 강도 높은 문화는 필터로 작동한다. 그 취향을 이미 가졌거나 빠르게 흡수할 수 있는 사람만 남고, 남은 사람들은 사실상 취향의 사본이 된다. 2002년에 합류해 SpaceX를 실질적으로 운영해 온 그윈 숏웰이 대표적이며, 머스크가 트위터에 매달려 있던 기간에도 SpaceX는 계속 발사했다.
  4. 주의를 분산하지 않고 집중한다. 머스크는 다섯 개 회사를 동시에 고르게 보지 않는다. 어느 시점이든 하나에 깊이 들어가 있다. 2017～2018년의 모델 3 생산 지옥, 2022～2023년의 트위터, 최근의 xAI가 그렇다. 그동안 나머지 회사는 1번, 2번, 3번 장치로 돌아간다. 즉 답은 "지휘관 아니면 편집자"가 아니라 기본은 지휘관이고 병목 한 곳에서만 편집자다. 병목에 들어가면 계층을 건너뛰고 공장 바닥에서 엔지니어와 직접 이야기한다. Cursor가 로그를 읽은 것과 같은 관측을 물리적으로 수행하는 것이다.
  5. 사명을 생성적으로 쓴다. "인류를 다행성 종으로 만든다", "지속 가능한 에너지로의 전환을 앞당긴다"는 요구사항 목록이 아니라 판단의 출발점이다. 엔지니어가 두 설계 중 무엇을 고를지 망설일 때 이 문장에서 답을 유도할 수 있다. 임무형 지휘의 "지휘관의 의도"가 가장 압축된 형태다.

그런데 이 다섯 장치는 전부 취향이 물리나 비용으로 환원될 수 있는 영역에서 작동한다. 로켓 부품의 가격이 원자재 대비 얼마인지는 계산할 수 있고, 배터리 팩에서 부품을 삭제해도 되는지는 물리가 답한다. 반면 소셜 네트워크의 핵심은 사람들이 어떤 느낌을 받느냐, 어떤 커뮤니티가 어떤 규범을 갖느냐다. 제1원리로 환원되지 않고 idiot index를 계산할 수도 없다. 삭제 편향은 여기서 오히려 해가 됐다. 사람과 절차를 대거 삭제했더니 "10%를 되돌린다"로 회복되지 않는 것들이 함께 사라졌다.

대조군으로 잡스가 있다. 잡스는 취향을 절차로 만들지 않고 자기 자신이 편집자로 남았다. 모든 제품의 세부를 직접 봤고, 그래서 애플은 제품 수를 극단적으로 줄였다. 편집자 모델은 깊이를 얻고 폭을 잃으며, 머스크의 절차 모델은 폭을 얻고 깊이를 잃는다. 테슬라의 소프트웨어 UI와 애플의 UI를 나란히 놓으면 그 차이가 보인다. 애플에 취향이 분산되어 있다면 그것은 절차로 분산한 것이 아니라 잡스가 편집자로 수십 년을 버틴 뒤에야 문화와 디자인 리뷰 의식으로 굳어진 것, 즉 시간으로 분산한 것이다.

그러니 머스크 사례가 주는 답은 이것이다. 취향은 절차로 압축될 수 있는 만큼만 분산된다. 물리와 비용에 묶인 취향은 잘 압축되고, 미적이거나 사회적인 취향은 잘 압축되지 않는다.

에이전트에 옮기면 이렇게 된다. 지시문에 제약만 넣지 말고 결정 절차를 넣는다. "새 의존성 금지"는 제약이고, "라이브러리를 추가하기 전에 직접 구현했을 때의 비용을 먼저 계산하고 그 비용이 통합 비용보다 낮으면 직접 구현한다"는 절차다. 후자는 예상 못 한 상황에서도 작동한다. 이 넥서스의 principles.md와 mental-models.md가 바로 이 압축 작업이고, AGENTS.md는 회사의 알고리즘에 해당한다. 판단 지점이 적은 코드베이스를 만든다. 모델 선택이 채용이고 시스템 프롬프트가 문화인데, 숏웰은 20년 동안 흡수했지만 에이전트는 매 세션 백지이므로 에이전트 조직은 흡수 장치에 기댈 수 없고 압축과 삭제가 더 많은 몫을 져야 한다. 사람은 관측 가능성이 가리키는 병목 한 곳에 편집자로 들어가고 나머지는 지휘관 모드로 둔다. 지시문의 첫 줄은 무엇을 만들라가 아니라 왜 만드는가여야 한다.

앱에 적용하면: 두 열로 나누고 경계를 옮긴다

계산 가능한 부분은 절차를 써서 넘기고 규모를 키우고, 계산되지 않는 부분은 의도적으로 작게 유지해서 사람이 직접 본다. 습관 기록 앱을 예로 두 열로 나누면 다음과 같다.

계산 가능한 부분 (절차로 넘김) 계산되지 않는 부분 (사람이 봄)
데이터 모델, 동기화, 오프라인 처리 무엇을 만들 것인가, 누구를 위해서인가
연속 기록(streak) 계산 로직 연속 기록이 끊겼을 때 어떻게 할 것인가
알림 스케줄링 알림 문구의 어조
디자인 시스템 준수 여부 디자인 시스템 자체가 맞는가
접근성 규칙(대비, 레이블, 키보드) 체크인 동작이 손에 붙는 느낌
테스트 통과, 타입 검사, 린트 첫 실행 30초 동안 무엇을 보여줄 것인가
에러 처리 패턴, 로깅 규칙 화면 하나에 습관을 몇 개까지 보여줄 것인가
API 계약, 마이그레이션 v1에서 무엇을 뺄 것인가

오른쪽 열은 전부 가치 판단이다. "연속 기록이 끊기면 0으로 되돌린다"와 "하루는 봐준다"는 둘 다 기술적으로 맞다. 어느 쪽이 옳은지는 물리도 비용도 답해주지 않고, 이 앱이 사용자를 어떻게 대하고 싶은지가 답한다.

핵심은 경계가 고정되어 있지 않다는 점이다. 오른쪽 열의 항목은 한 번 결정하면 왼쪽으로 넘어간다. "연속 기록이 끊기면 하루는 유예한다. 이틀째부터 멈추되 0으로 되돌리지는 않는다"라고 한 번 정해서 PRODUCT.md에 적으면, 그 순간부터 이 결정은 절차다. 에이전트는 유예 로직을 구현하고, 유예 상태의 UI를 그리고, 알림 문구를 유예 상태에 맞게 쓰고, 테스트를 작성한다. 원칙 하나가 수십 개의 국소 결정을 생성하며, 머스크의 알고리즘이 하는 일이 바로 이것이다. 디자인 시스템도 같은 변환 장치다. 디자인 시스템이 없으면 "이 화면이 보기 좋은가"는 화면마다 사람이 봐야 하는 취향이지만, 있으면 "토큰과 컴포넌트를 썼는가"라는 검사 가능한 절차가 된다. 앱을 만들 때 사람의 일은 오른쪽 열을 하나씩 결정해서 왼쪽으로 옮기는 것이며, 결정을 쓰는 만큼 규모가 커진다.

순서로 보면 네 단계다.

  1. 취향을 싼 곳에서 먼저 정한다. 코드가 아니라 문서와 프로토타입 위에서 오른쪽 열을 결정한다. 프로토타입이 중요한 이유는 "체크인 느낌"처럼 글로 못 쓰는 취향을 만져보고 확정할 수 있기 때문이다. 이 단계는 양은 작지만 사람이 직접 하고 시간을 아끼지 않는다.
  2. 결정을 절차로 쓴다. 제품 정의, 용어집, 결정 기록, 코딩 규칙, 디자인 시스템으로 만든다. 글로 안 써지는 취향은 예시로 쓴다. 좋은 알림 문구 열 개를 적어두면 "이 어조에 맞춰라"가 절차가 된다.
  3. 왼쪽 열을 규모로 돌린다. 화면 구현, 로직, 테스트, 마이그레이션은 절차가 있으니 사람이 diff를 읽지 않는다.
  4. 사람은 두 곳만 본다. 하나는 핵심 루프가 돌아가는 실제 제품이다. 모든 화면이 아니라 체크인 동작 하나, 첫 실행 경험 하나다. 다른 하나는 에이전트가 반복적으로 어긋나는 패턴이다. 여러 에이전트가 같은 지점에서 비슷하게 이상한 결정을 하면 개별 실수가 아니라 절차가 빠져 있다는 신호이므로, 그 항목을 오른쪽 열에서 꺼내 결정하고 문서에 추가한다. 관측이 다음 결정을 알려주는 구조다.

오른쪽 열을 작게 유지하는 방법은 화면과 상태를 줄이는 것, 가치 결정을 사례별이 아니라 원칙으로 쓰는 것("복구 가능한 실패는 확인 대신 되돌리기를 제공한다"), 취향을 프로토타입에서 소진하는 것, 규칙으로 못 쓰는 것은 예시를 쌓는 것이다.

실패 방식은 두 가지다. 오른쪽 열을 왼쪽 방식으로 다루면, 에이전트 스무 개가 각자 자기 화면의 문구와 배치를 정해서 화면마다 다른 앱이 되고, 연속 기록 정책을 정하지 않은 채 구현시켜서 코드 경로마다 정책이 다른 앱이 된다. 앱 버전의 트위터 인수다. 왼쪽 열을 오른쪽 방식으로 다루면, 절차가 있는데도 diff를 전부 읽어서 사람이 병목이 되고 에이전트를 늘린 의미가 사라진다.

이 넥서스의 파이프라인이 이미 이 구조다. define-product가 제품 취향을 PRODUCT.md로 압축하고, shape-idea가 기능 단위의 취향을 결정으로 압축하고, build-prototype이 글로 못 쓰는 취향을 싼 곳에서 확정하고, implement가 그 절차 아래에서 돌아간다. 비어 있는 것은 4단계다. 사람이 실제 제품의 핵심 루프를 보는 자리와, 에이전트의 반복 편차를 모아서 다음 결정으로 바꾸는 자리가 명시적으로 있는지는 점검할 필요가 있다.

규칙으로 못 쓰는 취향은 예시로 넘긴다

애플의 HIG(Human Interface Guidelines)는 이 문제의 오래된 해법이다. 애플은 자기 직원이 아닌 수백만 명의 외부 개발자가 "iOS 앱답게 느껴지는" 앱을 만들기를 원하지만 그 앱들을 하나하나 디자인 검토할 수는 없다. 취향을 사람에게서 떼어내 문서로 넘겨야 하는데 결과물을 일일이 볼 수는 없는 상황이다.

HIG에는 두 종류의 내용이 섞여 있다. 하나는 규칙이다. 탭 가능한 영역은 최소 44포인트여야 한다, 대비는 얼마 이상이어야 한다, 뒤로 가기는 왼쪽에 둔다. 검사할 수 있는 왼쪽 열이다. 다른 하나는 예시다. 잘 만든 화면의 스크린샷, "이렇게 하세요"와 "이렇게 하지 마세요"의 비교 이미지, 실제 애플 앱의 화면 캡처가 문서 전체에 깔려 있다.

예시가 많은 이유는 규칙으로 쓸 수 없는 것이 있기 때문이다. "좋은 iOS 설정 화면"의 규칙을 써보면 안다. 그룹으로 묶인 목록, 섹션 헤더, 하위 화면 화살표, 토글까지는 쓸 수 있다. 그런데 이 규칙을 전부 지키고도 형편없는 설정 화면을 만들 수 있다. 항목을 어떻게 묶어야 자연스러운지, 한 화면에 몇 개까지 두어야 답답하지 않은지, 어떤 항목은 하위 화면으로 빼고 어떤 항목은 그 자리에서 바꾸게 해야 하는지. 이런 것들이 "iOS답다"는 느낌을 만드는데 규칙으로는 써지지 않고, 써보면 "적절하게", "자연스럽게" 같은 말로 얼버무리게 된다. 하지만 잘 만든 설정 화면 열 개와 잘못 만든 화면 다섯 개를 주석과 함께 보여주면 디자이너는 그 감각을 익힌다.

규칙은 중요한 특징에 이름을 붙여야 쓸 수 있다. 그런데 어떤 취향은 이름 붙일 수 있는 특징 하나가 아니라 작은 것 수십 개의 조합이며, 그럴 때 규칙은 실패한다. 예시는 그 조합을 통째로 보존하고, 읽는 사람의 패턴 인식이 무엇이 중요한지를 알아서 뽑아낸다. 대신 예시는 규칙보다 길고 해석의 여지가 있다. 그래서 HIG는 규칙으로 쓸 수 있는 것은 규칙으로 쓰고 나머지를 예시로 채운다.

LLM은 본질적으로 패턴 인식기라서 이 방식이 특히 잘 통한다. 프롬프트에 예시를 넣는 few-shot 기법이 HIG가 사람에게 하는 일을 에이전트에게 하는 것이다. 습관 앱의 알림 문구를 "친근하되 가볍지 않고, 압박하지 않되 무관심하지 않은 어조"라고 쓰면 에이전트마다 다르게 해석하지만, 실제로 마음에 드는 문구 열 개를 적어두면 에이전트는 그 열 개가 공유하는 것을 뽑아내서 열한 번째를 쓴다. 애플이 규칙으로 못 쓴 것을 스크린샷으로 넘긴 것과 같은 원리다.

회사는 언제 사람을 뽑고 언제 AI를 쓰는가

이 틀을 회사에 그대로 옮기면 채용 질문 자체가 바뀐다. 예전에는 "일손이 더 필요한가"를 물었다면, 이제는 "지금 병목이 왼쪽 열에 있는가, 오른쪽 열에 있는가"를 물어야 한다.

AI를 쓰는 조건은 그 일이 왼쪽 열에 있다는 뜻이다.

사람을 채용하는 조건은 오른쪽 열이 커졌는데 줄어들지 않는다는 신호다.

그래서 뽑는 사람의 기준도 바뀐다. 전통적인 회사는 결정하는 사람 한 명당 실행하는 사람 여럿을 뽑았지만, 이 구조에서는 실행자를 뽑을 이유가 사라진다. 대신 각 사람은 압축되지 않은 판단의 범위를 하나씩 소유하고, 동시에 자기 판단을 절차와 예시로 써서 왼쪽 열로 옮기는 압축 작업을 맡는다. 면접에서 물어야 할 것은 "이 일을 잘 하는가"가 아니라 "자기 판단을 남이 실행할 수 있는 글로 바꿀 수 있는가"다.

흡수 장치가 없다는 점도 채용에 영향을 준다. 인간 회사는 숏웰처럼 20년에 걸쳐 취향을 흡수시킬 수 있었지만, AI 중심 조직은 사람 수가 적어서 그런 여유가 없다. 따라서 훈련시킬 사람이 아니라 이미 취향이 맞는 사람을 뽑는 필터 방식이 더 중요해진다.

이 답에는 앞에서 본 한계가 그대로 적용된다. Cursor의 성공은 브라우저 엔진처럼 정확성이 명세와 테스트로 검증되는 도메인에서 나왔다. 회사의 제품 가치가 느낌이나 관계에 있을수록 오른쪽 열이 크고, 그만큼 사람의 비중이 높아야 한다. 정리하면, 검증 가능하고 결정이 끝난 일은 AI에게 넘기고, 아직 결정되지 않았거나 글로 써지지 않는 판단이 병목이 될 때 그 범위를 소유하고 압축할 사람을 뽑는다.

Key Insight

에이전트 조직은 회사를 흉내 낸 것이 아니라 같은 제약에 대한 또 다른 답이다. 사람의 일은 취향을 절차와 예시로 압축해서 결과물 하나하나를 보는 루프에서 빠져나오는 것이며, 취향은 절차로 압축되는 만큼만 분산된다.

References