이 글은 수천 개의 AI 에이전트가 협력하여 복잡한 소프트웨어 프로젝트를 autonomously(자율적으로) 개발하는 방법에 대한 Cursor의 연구 내용을 다룹니다. 특히, 에이전트 오케스트레이션(orchestration) 시스템의 발전 과정과 그 과정에서 얻은 주요 교훈들을 상세히 설명하며, 자기 주도적인 코드베이스를 구축하기 위한 다양한 실험과 최종 시스템 설계에 대해 이야기합니다.

1. 연구의 배경과 초기 시도

Cursor는 장기적인 자율 코딩 프로젝트의 가능성을 탐색하기 위해 내부 연구를 시작했어요. 🧑‍💻 이 연구의 목표는 수천 개의 에이전트를 조율하는 시스템(하네스)을 만들고 그들의 행동을 관찰하는 것이었습니다. 지난달(2026년 5월)에는 시스템이 일주일 동안 계속 작동하며 연구 프로젝트(웹 브라우저)에 필요한 대부분의 커밋을 생성하는 안정성을 보여주었죠. 물론 외부 사용을 위한 브라우저는 아니었고, 코드에 약간의 버그가 있었지만, 인간의 개입 없이 수천 개의 에이전트가 협력하여 작동하는 결과물을 만들어냈다는 점은 정말 중요한 이정표였습니다! 🎉

이 연구는 제 개인적인 사이드 프로젝트에서 시작되었어요. 웹 브라우저는 프론티어 모델의 한계를 드러내기에 충분히 복잡했고, 서로 협력해야 하는 다양한 서브 시스템을 포함하고 있었죠. 처음에는 Opus 4.5에게 자바스크립트(JavaScript) 지원 없이 웹 페이지를 렌더링하는 브라우저 엔진 구축 계획을 요청했습니다. 하지만 모델은 금방 길을 잃고, 제대로 완성되지 않았는데도 성공했다고 주장하거나, 복잡한 구현 세부 사항에서 막히는 모습을 보였어요. 그래도 작은 코드 조각들을 잘 작성하는 깊은 지식과 지능의 징후는 보였죠.

핵심 문제는 브라우저 구축이라는 task가 너무 압도적이라서 하위 작업으로 분해해야 한다는 것이었습니다. 다음으로, 에이전트가 병렬로 수행할 수 있는 주요 작업의 의존성 그래프를 계획하도록 했어요. 에이전트들은 수동으로 생성되었고, 작업이 멈추면 계속 진행하도록 nudge(재촉)했죠. 이는 처리량은 늘렸지만, 결과는 크게 나아지지 않았어요. 에이전트들이 서로 소통하거나 프로젝트 전체에 대한 피드백을 제공할 수 없었기 때문입니다. 시스템은 더 동적이어야 했어요.

한편, GPT-5.1과 GPT-5.2가 지시를 정확하게 따르는 능력이 향상되면서 더 나은 결과를 보여주기 시작했습니다. 이것이 장기 실행 에이전트에게 적합하다고 판단했고, 우리는 이 실험을 바탕으로 하네스를 OpenAI 모델을 사용하도록 업데이트했습니다. 이때 하네스는 자바스크립트 없는 웹 브라우저의 간단한 버전을 만들 수 있었지만, 하나의 에이전트만으로는 완전한 브라우저 엔진을 구축하는 것이 너무 느릴 것이라는 결론에 도달했어요.

이것이 우리의 다음 연구의 시작이었습니다. 🤔 "계산 비용을 10배 더 투자해서 10배 더 의미 있는 처리량을 얻을 수 있을까?" 하는 질문이었죠.

2. 단일 에이전트에서 다중 에이전트로의 전환

우리는 간단한 Rust 기반의 하네스로 새로운 저장소를 시작했어요. 분산 시스템의 복잡성을 다루는 대신, 많은 리소스를 가진 단일 대형 리눅스 VM(가상 머신)에서 하네스를 실행했습니다. 하네스를 제어하기 위해 VM에 SSH로 접속하여 간단한 터미널 인터페이스를 사용했죠.

우리는 시스템의 적절한 관찰 가능성(observability)에 더 많은 시간을 투자했어요. 모든 에이전트 메시지, 시스템 작업, 명령어 출력을 타임스탬프와 함께 기록하여 세션을 분석하고 재생할 수 있도록 했습니다. 이는 수동으로 검토하는 데 유용했을 뿐만 아니라, Cursor로 다시 파이프라인하여 대량의 데이터를 sift through(자세히 조사하여 선별)하고 패턴을 빠르게 찾는 데도 도움이 되었어요.

2.1. 자체 조정(Self-coordination)의 실패

우리의 첫 번째 다중 에이전트 아이디어는 가장 단순했습니다. 👇

• 동등한 역할을 가진 에이전트들이 공유 상태 파일을 사용하여 다른 에이전트가 무엇을 하고 있는지 확인하고, 무엇을 작업할지 결정하고, 파일을 업데이트하는 방식이었죠.

우리는 에이전트들이 스스로 조정하는 방법을 찾도록 가장 덜 규정적으로 접근했지만, 이것은 빨리 실패했습니다. 😱

조정 파일은 오히려 더 많은 문제를 야기했어요. 에이전트들은 락(lock)을 너무 오래 점유하고, 락 해제를 잊어버리거나, 락을 걸거나 해제하는 것이 불법인 상황에서 시도하는 등, 전반적으로 조정 파일에 락을 거는 것의 중요성을 이해하지 못했습니다. 락킹은 잘못하기 쉽고 정확하게 사용하기 어려웠으며, 추가 프롬프트도 도움이 되지 않았어요.

락킹은 또한 너무 많은 경합(contention)을 발생시켰습니다. 20개의 에이전트가 락을 기다리는 데 대부분의 시간을 보내면서 1~3개의 에이전트 처리량으로 느려졌죠. 우리는 에이전트들에게 다른 에이전트의 작업을 명시적으로 기다리는 도구를 주었지만, 거의 사용하지 않았습니다. 락 없는 낙관적 동시성 제어(optimistic concurrency control) 접근법도 시도했지만, 오버헤드를 줄였을 뿐 혼란을 없애지는 못했어요.

에이전트들 간의 구조 부족은 어떤 에이전트도 크고 복잡한 작업을 맡지 않게 만들었습니다. 그들은 경합과 충돌을 피하고, 프로젝트 전체에 대한 책임을 지기보다는 작고 안전한 변경 사항을 선택하는 경향이 있었죠.

3. 구조와 역할 추가

다음으로, 우리는 에이전트들에게 소유권과 책임감을 주기 위해 역할을 분리했습니다. 👥

• 플래너 (Planner): 사용자의 지시에 따라 진행할 정확한 접근 방식과 결과물을 먼저 계획합니다.
• 실행자 (Executor): 플래너의 계획이 완전히 달성되도록 보장하는 유일한 리드 에이전트입니다. 실행자는 워커(Worker)를 위해 task를 생성할 수 있으며, 이는 선형적인 확장성과 처리량을 제공합니다.
• 판사 (Judge): 실행자가 작업을 마친 후 독립적으로 실행되어 작업이 완료되었는지, 다음 반복을 실행해야 하는지 여부를 판단합니다.

이러한 구조는 많은 조정 문제를 해결했습니다. 실행을 소유하고 감독하는 단일 역할을 둠으로써 워커들은 자신의 task에만 집중할 수 있었고, 전체 시스템은 여전히 결과물을 만들어낼 수 있었죠.

3.1. 관찰과 개선

이러한 설계를 성공시키기 위해서는 시스템을 면밀히 관찰해야 했습니다. 🔎

만약 큰 문제가 발생하면, 그것은 반복적으로, 그리고 많은 에이전트와 도구 호출에 걸쳐 발생했어요. 예를 들어, 많은 에이전트가 동시에 git restore를 실행하여 너무 많은 경합이 발생한다는 것을 발견했죠. 우리는 Cursor를 사용하여 로그를 분석하고 프롬프트와 비교하여 왜 행동이 기대와 일치하지 않는지 이해하려고 노력했습니다.

결과적으로, 이 시스템은 가장 느린 워커에 의해 병목 현상이 발생한다는 것을 알게 되었습니다. 너무 rigid(경직)했죠. 모든 계획을 미리 세우는 것도 새로운 문제가 발견되었을 때 시스템이 동적으로 재조정하기 어렵게 만들었습니다. 일부 에이전트는 비생산적인 방향으로 나아가고, 다음 반복 루프까지 스스로 수정할 수 없었습니다.

4. 연속적인 실행자 (Continuous Executor)

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

이제 실행자는 task를 생성하는 것 외에도 목표를 달성하는 방법을 스스로 계획할 수 있게 되었어요. 유일한 에이전트였기 때문에, 어디에도 계획을 기록하거나, 정적이고 변하지 않는 계획에 얽매이거나, 모든 워커를 융통성 없이 기다릴 필요가 없었습니다.

4.1. 신선도 유지 (Ensuring Freshness)

에이전트들이 장기간에 걸쳐 표류하지 않도록 신선도 유지 메커니즘을 도입했습니다. 🌿

1. scratchpad.md는 추가되는 대신 자주 다시 작성되어야 합니다.
2. 개별 에이전트는 컨텍스트 한계에 도달하면 자동으로 요약해야 합니다.
3. 시스템 프롬프트에 자기 성찰(self-reflection) 및 정렬 알림(alignment reminders)을 추가했습니다.
4. 에이전트들은 언제든지 가정을 변경하고 이의를 제기하도록 권장되었습니다.

이제 시스템은 매우 역동적이고 유연해졌습니다. 코드를 적극적으로 탐색하고, 결정을 재고하며, 워커를 관리하고, task를 interleaving(겹쳐서 실행)하며, 최신 정보를 지속적으로 반영할 수 있었죠. 에이전트들이 지시를 완료하는 데 상당히 능숙하다는 것을 발견했기 때문에, 시스템을 단순하게 유지하기 위해 판사는 제거했습니다.

4.2. 병리학적 행동 (Pathological Behaviors)

이러한 개선에도 불구하고, 연속적인 실행자는 병리학적 행동을 보이기 시작했습니다. 😵‍💫 무작위로 잠들고, 에이전트 실행을 중단하며, 스스로 작업을 수행하고, 몇 개의 좁은 task만 계획하고 생성하기를 거부하며, 워커의 변경 사항을 제대로 병합하지 않고, 시기상조로 완료를 주장했죠.

우리는 실행자에게 너무 많은 역할과 목표가 동시에 주어졌다는 것을 발견했습니다. 계획, 탐색, 연구, task 생성, 워커 확인, 코드 검토, 편집 수행, 결과물 병합, 그리고 루프 완료 여부 판단까지. 돌이켜보면 압도당하는 것이 당연했습니다.

5. 최종 시스템 설계

최종 설계는 우리가 배운 모든 것을 통합합니다. 🧠

1. 루트 플래너 (Root Planner): 사용자 지시의 전체 범위를 소유합니다. 현재 상태를 이해하고 목표를 향해 진행할 구체적이고 특정적인 task를 전달하는 역할을 합니다. 코드 작성은 직접 하지 않으며, 자신의 task가 누구에 의해 수행되는지 알지 못합니다.
2. 서브 플래너 (Subplanners): 플래너가 자신의 범위가 세분화될 수 있다고 판단할 때 생성됩니다. 위임된 좁은 부분을 완전히 소유하며, 비슷한 방식으로 전체 소유권을 가지지만 해당 부분에만 해당됩니다. 이는 재귀적입니다.
3. 워커 (Workers): task를 선택하고 완료까지 이끄는 전적인 책임이 있습니다. 더 큰 시스템에 대해서는 알지 못하며, 다른 플래너나 워커와 소통하지 않습니다. 자신의 저장소 사본에서 작업하고, 완료되면 시스템이 task를 요청한 플래너에게 제출하는 단일 핸드오프(handoff)를 작성합니다.

흥미롭게도, 이 설계는 오늘날 일부 소프트웨어 팀이 운영하는 방식과 유사합니다. 🤝

서브 플래너는 워커들을 빠르게 분산시켜 처리량을 증가시키는 동시에, 전체 시스템이 에이전트에 의해 완전히 소유되고 책임지도록 보장합니다. 이는 단일 플래너가 압도당하고 터널 비전에 빠질 수 있는 대규모 프로젝트와 task에도 도움이 되었습니다.

핸드오프에는 단순히 무엇이 완료되었는지뿐만 아니라, 중요한 메모, 우려 사항, deviation(벗어남), 발견 사항, 생각, 그리고 피드백이 포함됩니다. 플래너는 이를 후속 메시지로 받습니다. 이는 시스템을 지속적으로 움직이게 합니다. 플래너가 "완료"되었더라도 계속 업데이트를 받고, 최신 저장소를 가져와서 계획을 계속하고 후속 결정을 내릴 수 있습니다.

모든 에이전트는 이 메커니즘을 가지고 있어, 시스템이 믿을 수 없을 정도로 동적이고 스스로 수렴하도록 합니다. 전역 동기화나 상호 통신의 오버헤드 없이 정보가 점점 더 전체적인 시야를 가진 소유자에게 전달됩니다.

5.1. 통합자 (Integrator) 제거

우리는 원래 중앙 집중식의 전역적으로 인식하는 품질 관리를 위해, 그리고 너무 많은 워커들이 동시에 푸시, 리베이스, 충돌 해결, 병합을 시도하여 발생하는 경합을 제거하기 위해 통합자를 추가했습니다.

하지만 통합자는 명백한 병목 현상이 되었습니다. 수백 명의 워커와 모든 작업이 통과해야 하는 하나의 문(즉, "관료주의")이 있었던 것이죠. 프롬프트 변경을 시도했지만, 궁극적으로는 불필요하다고 판단하여 시스템을 단순화하기 위해 제거했습니다.

6. 처리량과 트레이드오프

이 시스템은 일주일 동안 약 1천만 건의 도구 호출을 통해 시간당 약 1,000개의 커밋을 기록했습니다. 시스템이 시작된 후에는 우리의 개입이 전혀 필요 없었죠. 🚀 이러한 처리량을 달성하기 위해 의도적인 트레이드오프가 있었습니다.

6.1. 커밋 정확성 (Commit Correctness)

매 커밋 전에 100% 정확성을 요구했을 때, 심각한 직렬화(serialization)와 효율적인 처리량의 저하가 발생했습니다. API 변경이나 오타와 같은 단 하나의 작은 오류라도 전체 시스템을 멈추게 만들었죠. 워커들은 자신의 범위를 벗어나 관련 없는 것을 고치기 시작했고, 많은 에이전트들이 같은 문제를 고치려다 서로 짓밟는 상황이 발생했습니다.

이러한 행동은 도움이 되거나 필요하지 않았습니다. 약간의 여유를 허용함으로써 에이전트들은 다른 문제가 곧 동료 에이전트들에 의해 해결될 것이라고 신뢰할 수 있습니다. 시스템이 코드베이스 전체에 대한 효과적인 소유권과 위임을 가지고 있기 때문에 이것은 사실이죠. 오류는 발생하지만 빠르게 수정됩니다. 오류율은 작고 일정하게 유지되며, 완벽하게 깨끗하지는 않지만 안정적이고 관리 가능한 수준을 유지하며 폭발적으로 증가하거나 악화되지 않습니다.

이는 이상적인 효율적인 시스템은 어느 정도의 오류율을 허용하지만, 최종 "그린" 브랜치(green branch)에서는 에이전트가 정기적으로 스냅샷을 찍고 릴리스 전에 빠르게 수정하는 과정이 필요하다는 것을 시사합니다.

6.2. 동기화 오버헤드 (Synchronization Overhead)

때로는 여러 에이전트가 동일한 파일을 건드리거나 동일한 코드를 리팩토링합니다. 우리는 이러한 상황을 완전히 제거하거나 과도하게 설계하려 노력하기보다는, 어느 정도의 "turbulance(격동)"을 받아들이고 시스템이 짧은 시간 내에 자연스럽게 수렴하고 안정되도록 합니다.

이는 추가적인 토큰을 소비하고 로컬 경합을 유발하지만, 전체 시스템을 더 단순하게 유지합니다. 모델을 정렬하고 압도하지 않기 더 쉽고, 관리하고 관찰하기 더 쉬우며, 마찰이 적고, 전반적인 생산성이 더 좋습니다. 또한 지나치게 복잡한 접근 방식을 피할 수 있게 합니다.

7. 인프라 학습 (Infrastructure Learnings)

각 다중 에이전트 실행은 자체 대형 머신에서 충분한 시스템 리소스와 함께 실행되었고, 분산 시스템에 대한 시기상조의 복잡성을 피했습니다. 이것은 좋은 접근 방식이었는데, 대부분의 실행이 수백 개의 에이전트에서 최고조에 달했으며, 이 머신들을 일반적으로 포화시켰지만 과도하게 사용하지는 않았기 때문입니다. 이 아키텍처는 시스템 메트릭스를 관찰하고, 필요할 때 상태를 공유하고 복사하기 쉽게 만들었습니다.

에이전트의 RAM 사용량을 제한한 후, 디스크가 병목 지점이 되었습니다. 특히 모놀리식 프로젝트에서는 수백 개의 에이전트가 동시에 컴파일하여 빌드 아티팩트(build artifacts)에 대한 초당 수 기가바이트의 읽기/쓰기가 발생했습니다. 이는 하네스의 전체 처리량에 상당한 영향을 미쳤는데, 흥미로운 교훈이었습니다. 프로젝트 구조, 아키텍처 결정, 그리고 개발 경험이 토큰 및 커밋 처리량에 영향을 미칠 수 있다는 것이죠. 이상적으로 생각하고 코딩하는 대신, 코드베이스 작업(예: 컴파일)이 시간을 지배하기 때문입니다.

일반적인 개발 환경에도 제약과 비효율성이 있었습니다. 단일 사용자 작업 공간에서는 의미가 없거나 중요하지 않은 것들이, 수백 개의 에이전트가 하나의 머신에서 동일한 작업을 수행할 때는 두드러질 수 있습니다. 이를 해결하는 간단한 방법 중 하나는 각 에이전트에게 자체 머신을 할당하는 것입니다. 하지만 이러한 기본 도구와 원시적인 부분들을 재고하고 재설계함으로써 큰 효율성 향상을 위한 흥미로운 저위험 기회들이 있습니다.

예를 들어, Git 및 Cargo와 같은 많은 도구는 주로 간단한 동시성 제어 메커니즘으로 공유 락(shared locks)을 사용합니다. 데이터베이스와 같은 동시 시스템에서 잘 확립된 메커니즘을 가져와서 다중 에이전트 시스템에서도 잘 작동하게 할 수 있을까요? 모든 에이전트가 저장소의 자체 사본을 가지고 있지만, 대부분의 파일과 아티팩트는 동일합니다. 더 정교한 생산 저장 시스템에서 발견되는 간단한 copy-on-write 및 중복 제거 기능을 추가하면, 별도의 인프라를 구축하지 않고도 일반적으로 "단일 사용자" 시스템에 유사한 쉬운 이점을 가져올 수 있을까요?

8. 에이전트에게 의도 명시하기 (Specifying Intent to Agents)

이 다중 에이전트 시스템에 주어지는 지시(instructions)는 매우 중요했습니다. 📢

처음에는 지시를 주 목표로 삼지 않고, 안정적이고 효과적인 하네스를 목표로 했습니다. 하지만 지시의 중요성은 빠르게 명확해졌죠. 우리는 기본적으로 일반적인 코딩 에이전트와 상호 작용하고 있었지만, 시간과 계산 측면에서 훨씬 더 큰 규모였습니다. 이는 최적화되지 않거나 불명확한 지시를 포함하여 모든 것을 증폭시킵니다.

초기 지시에 더 많은 시간을 투자하는 것이 합리적입니다. 궁극적으로 에이전트는 여전히 에이전트입니다. 당신의 지시를 엄격하게 따르도록 훈련되었고, 그 길을 따라가며, 지시가 나쁘더라도 변경하거나 무시하지 않습니다.

우리는 연구 프로젝트에서 성공을 보고 싶었기 때문에, 프로젝트와 하네스가 발전함에 따라 초기 지시를 수정했습니다. 새로운 다중 에이전트 시스템을 운영하는 방법을 배우면서 브라우저를 구축하는 방법을 배우고 있었고, 출력 품질에 반영된 좋지 않거나 불충분하게 지정된 사양을 볼 수 있었습니다. 이는 하네스 자체 때문이 아니었죠. 하네스는 단지 우리의 지시를 정확히 따랐을 뿐입니다.

브라우저 프로젝트에서 몇 가지 예시를 들어볼까요?

• 초기에는 지시가 사양 구현과 버그 수정에 초점을 맞췄습니다. "사양 구현"과 같은 지시는 너무 모호하여 에이전트들이 지능적으로 우선순위를 정하기보다는 모호하고 거의 사용되지 않는 기능에 깊이 파고들었습니다.
• 우리는 사용자 친화적인 범위 내에서 성능 기대치가 암묵적으로 있을 것이라고 가정했습니다. 하지만 에이전트들이 성능과 다른 목표 사이의 균형을 맞추도록 강제하기 위해서는 명시적인 지시와 강제된 시간 초과가 필요했습니다.
• 시스템의 복잡한 부분에서는 에이전트가 메모리 누수나 데드락을 유발하는 코드를 작성할 수 있습니다. 인간은 이를 알아차리겠지만, 에이전트에게는 항상 명확하지 않았습니다. 시스템이 gracefully(우아하게) 복구하고 더 방어적으로 작동하려면 명시적인 프로세스 기반 리소스 관리 도구가 필요했습니다.

자바스크립트 없는 간단한 브라우저의 첫 번째 버전은 완전한 브라우저로 발전하기에 부적합한 아키텍처에 수렴했습니다. 이는 초기 사양의 실패였습니다.

마찬가지로, 에이전트들은 프로젝트가 처음부터 브라우저라고 들었음에도 불구하고, 스스로 구현할 수 있었거나 적절한 구현이 진행되는 동안 임시적인 scaffolding(뼈대)으로 사용할 수 있었던 일부 의존성을 가져왔습니다. 이는 지시의 oversight(간과)였습니다. 이후 실행에서는 의존성 철학과 사용해서는 안 되는 라이브러리를 명시적으로 제시하여 이를 수정했습니다.

그 이후 실행에서는 또한 monolith에서 벗어나 많은 자기 포함적인 크레이트(crates)로의 대대적인 재구성을 단행했습니다. 저장소는 심하게 손상된 상태였지만, 다중 에이전트 시스템은 며칠 내에 작동하는 코드로 수렴했습니다. 이는 시스템이 완전히 손상된 상태에서도 더 이상 저하되거나 멈추지 않고, 협력적이고 지능적으로 작동하는 강력한 능력을 가지고 있음을 보여주었습니다. 이 실행에서는 또한 컴파일을 기다리는 시간이 훨씬 적게 들었고, 이전보다 몇 배 더 높은 처리량으로 실행되었습니다.

아키텍처와 지시는 중요합니다. 에이전트는 엄청난 엔지니어링 기술을 가지고 있지만, 좋든 나쁘든 지시를 끝까지 따를 것입니다. 너무 좁은 메트릭과 구조화되지 않은 자유 사이의 균형을 찾는 것은 까다로웠으며, 무엇이 명백하고 무엇이 명시적으로 언급되어야 하는지 아는 것도 마찬가지였습니다. 이 모든 것은 의도를 도출하고, 명시하고, 이해하는 것의 중요성을 나타내며, 이러한 규모에서는 더욱 중요해집니다. Steerability(조종 가능성)와 Observability(관찰 가능성)는 계속 탐구할 흥미로운 연구 영역이 될 것입니다.

9. 프롬프트 최적화 (Optimizing Prompts)

프롬프트 작성은 진화 과정의 중요한 부분이었습니다. 📝

우리는 모델이 할 줄 아는 것들은 지시하지 않고, 모르는 것(예: 다중 에이전트 협업)이나 관련 도메인에 특정한 것(예: 테스트 실행 방법, 배포 파이프라인)만 지시하는 것이 더 좋다는 것을 발견했습니다. 모델을 엔지니어링은 알지만 특정 코드베이스와 프로세스는 모르는 똑똑한 신입사원처럼 대하세요.

지시보다 제약(constraints)이 더 효과적입니다. "할 일 목록(TODOs) 없음, 부분 구현 없음"이 "구현을 완료하는 것을 잊지 마세요"보다 더 잘 작동합니다. 모델은 일반적으로 기본적으로 좋은 일을 합니다. 제약은 그들의 경계를 정의하는 것이죠.

더 높은 수준이나 더 깊은 작업에 대해서는 체크박스식 사고방식을 피하세요. 의도에 대한 자세한 지시를 제공하되, 특정 작업을 지시하는 것은 모델이 더 넓은 범위보다는 해당 작업을 달성하는 데 집중하게 만든다는 점을 기억하세요. 또한 나열되지 않은 것들의 우선순위를 암묵적으로 낮추게 됩니다. 일반적으로 모델이 판단력과 자율성을 사용하도록 하는 것이 더 좋습니다.

우리는 범위의 양을 논의할 때 구체적인 숫자와 범위를 제시하는 것이 유용하다는 것을 발견했습니다. "많은 작업을 생성하세요"와 같은 지시는 적은 양을 생성하는 경향이 있습니다. 이는 보수적인 기본값으로, 안전하게 플레이하며 기술적으로는 여전히 지시를 따르는 것이죠. "20-100개의 작업을 생성하세요"는 더 넓은 범위의 의도를 전달하고, 야심적이어야 함을 의미하며, 우리는 매우 다른 더 넓은 행동을 관찰했습니다.

10. 시스템 설계 학습 (System Design Learnings)

우리의 연구를 통해 몇 가지 원칙을 확립했습니다. 💡

1. 시스템은 안티프래질(anti-fragile)해야 합니다. 동시에 실행되는 에이전트 수가 늘어남에 따라 실패 확률도 증가합니다. 우리 시스템은 개별 에이전트의 실패를 견뎌내고, 다른 에이전트들이 복구하거나 대체 접근 방식을 시도할 수 있도록 해야 합니다.
2. 가정 기반이 아닌 경험 기반이어야 합니다. 우리는 인간 조직이나 기존 시스템 설계에 기반한 가정에 따라 어떻게 작동해야 하는지에 대한 가정을 가지고 접근하기보다는, 데이터와 관찰을 사용하여 조정을 하고 싶었습니다.
3. 처리량을 명시적으로 설계해야 합니다. 이는 코딩의 다른 측면을 trade off(거래)한다는 의미입니다. 예를 들어, 시스템 속도를 극적으로 저하시킬 100% 완벽하게 작동하는 코드 대신, 최종 조정 패스가 필요한 작지만 안정적인 오류율을 허용하는 것과 같습니다.

이러한 시스템은 제대로 설계되었을 때 우아하게 단순한 경향이 있지만, 어떤 단순한 접근 방식이 효과적일지는 다양한 접근 방식을 탐구하기 전까지는 명확하지 않았습니다. 현재 시스템 설계는 최소한의 오버헤드로 실행되며, 유용한 방식으로 토큰 처리량의 선형 확장을 제공합니다. 하네스에 대한 주요 추가 반복은 필요하지 않았습니다.

결론

이 연구에서 맛, 판단, 그리고 방향은 인간으로부터 나왔지만, AI는 이러한 연구를 빠르게 반복하고 탐색하는 데 상당한 힘의 배수(force-multiplier) 역할을 했습니다. 💪

이는 AI가 AI를 개발하는 "선순환(virtuous)" AI 루프와 유사합니다. 모델, 에이전트, 하네스가 더 좋아질수록, 이는 스스로에게 피드백되어 점점 더 빠르게 가속됩니다. 우리는 우리를 형성하는 도구를 형성하는 것이죠.

이 연구에는 오늘날 일부 소프트웨어 팀이 운영하는 방식과 시적인 유사성이 있습니다. 이러한 모델들은 명시적으로 이런 방식으로 훈련되지 않았다는 점에서, 이것이 창발적 행동(emergent behavior)이며 어쩌면 소프트웨어 프로젝트를 구조화하는 올바른 방법일 수도 있다는 것을 시사합니다.

우리는 앞으로도 매우 장기적으로 실행되는 에이전트에 대한 연구를 계속할 것이며, 우리의 발견은 제품의 미래를 밝혀줄 것입니다. ✨