# 장시간 실행되는 자율 코딩의 확장 > Clean Markdown view of GeekNews topic #25859. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25859](https://news.hada.io/topic?id=25859) - GeekNews Markdown: [https://news.hada.io/topic/25859.md](https://news.hada.io/topic/25859.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-01-16T08:59:37+09:00 - Updated: 2026-01-16T08:59:37+09:00 - Original source: [cursor.com](https://cursor.com/blog/scaling-agents) - Points: 18 - Comments: 1 ## Summary **장시간 자율 코딩 확장**은 단일 에이전트의 한계를 넘어서는 핵심 실험으로, Cursor 팀은 수백 개의 **계획자–작업자 구조**를 병렬로 운용해 웹 브라우저를 처음부터 구현했습니다. 초기의 동적 협업 방식은 락 충돌과 중복 작업으로 병목이 발생했지만, 역할을 분리한 단순한 계층 구조와 정교한 **프롬프트 설계**가 장기 자율 코딩의 안정성과 효율을 크게 높였습니다. 이 결과는 대규모 코드베이스에서도 자율 에이전트가 실제 개발 진전을 이룰 수 있음을 보여줍니다. ## Topic Body - Cursor가 수주간 **자율 코딩 에이전트**를 병렬로 실행하며 대규모 프로젝트를 완성할 수 있는지 실험함 - 초기에는 **동적 협업 구조**를 사용했으나, 락(lock) 충돌과 작업 중복으로 병목 현상이 발생 - 이후 **계획자(Planner)** 와 **작업자(Worker)** 로 역할을 분리해 병렬성과 효율성을 크게 향상 - 이 구조로 **웹 브라우저를 처음부터 구현**, 수백 명의 에이전트가 100만 줄 이상의 코드를 작성 - 실험 결과, **단순한 구조와 적절한 프롬프트 설계**가 장기 자율 코딩 확장의 핵심임 --- ### 단일 에이전트의 한계 - 현재의 **단일 코딩 에이전트**는 단순 작업에는 효율적이지만 복잡한 프로젝트에서는 속도가 느림 - 여러 에이전트를 병렬로 실행하는 것이 자연스러운 확장 방향이지만, **작업 조정**이 어려움 - 초기에는 사전 계획 없이 **동적 협업 방식**을 시도 - 각 에이전트가 다른 에이전트의 상태를 보고 스스로 다음 작업을 결정하는 구조 ### 협업 학습 과정 - 모든 에이전트가 **동등한 권한**을 갖고, 공유 파일을 통해 작업을 조정하는 구조를 도입 - 각 에이전트는 다른 에이전트의 상태를 확인하고, 작업을 할당받아 상태를 갱신 - 중복 방지를 위해 **락(lock) 메커니즘**을 사용 - 문제점 1. 에이전트가 락을 오래 점유하거나 해제하지 않아 전체 속도가 20개 중 2~3개 수준으로 저하 2. 락을 보유한 상태에서 실패하거나, 락 없이 파일을 수정하는 등 **시스템 불안정성** 발생 - **낙관적 동시성 제어(optimistic concurrency control)** 로 전환 - 읽기는 자유롭게, 쓰기는 상태 변경 시 실패하도록 설정 - 단순하고 안정적이지만, **위계 없는 구조**에서는 에이전트가 위험 회피적 행동을 보임 - 어려운 문제를 회피하고 작은 수정만 반복, **진전 없는 작업 순환** 발생 ### 계획자와 작업자 구조 - 역할을 분리한 **계층형 파이프라인**으로 전환 - **계획자(Planners)** : 코드베이스를 탐색하며 작업을 생성, 필요 시 하위 계획자 생성 - **작업자(Workers)** : 주어진 작업만 수행하고 완료 후 변경사항을 푸시 - 각 주기마다 **판정 에이전트(judge)** 가 다음 단계 진행 여부를 결정 - 이 구조로 대부분의 협업 문제가 해결되어, **대규모 프로젝트 확장성 확보** ### 장기 실행 실험 - 실험 목표: **웹 브라우저를 처음부터 구현** - 약 1주간 실행, 1,000개 파일에 **100만 줄 이상의 코드** 작성 - 수백 개의 작업자가 동시에 같은 브랜치에 푸시했으나 충돌은 최소화 - 결과 코드는 GitHub에 공개됨 - 추가 실험 - **Solid → React 마이그레이션**: 3주간 +266K/-193K 변경, 병합 가능성 확인 - **비디오 렌더링 개선**: Rust 버전으로 25배 속도 향상, **줌·팬·모션 블러** 기능 추가 - 해당 코드는 곧 프로덕션 반영 예정 ### 주요 학습 결과 - 수십억 토큰을 투입한 결과, 완전 효율적이지는 않지만 **예상보다 높은 성과** 확인 - **모델 선택**이 장기 자율 작업의 핵심 - **GPT-5.2**는 집중력 유지, 지시 이행, 정확한 구현에서 우수 - **Opus 4.5**는 빠른 종료 경향 - **GPT-5.2**는 **GPT-5.1-codex**보다 계획자 역할에 적합 - 역할별로 최적 모델을 선택해 사용 - **복잡성 제거**가 성능 향상에 기여 - 품질 통합자(integrator) 역할은 오히려 병목을 유발 - 작업자들이 자체적으로 충돌 해결 가능 - **단순한 구조**가 가장 효과적 - 분산 시스템 이론이나 조직 설계 모델은 일부만 유효 - 구조가 너무 적으면 충돌·중복 발생, 너무 많으면 취약성 증가 - **프롬프트 설계**가 시스템 행동에 결정적 영향 - 장기 집중 유지, 병리적 행동 방지, 협업 유도에 핵심 역할 ### 향후 과제 - **다중 에이전트 조정**은 여전히 어려운 문제 - 계획자가 작업 완료 시 자동으로 다음 단계를 계획하도록 개선 필요 - 일부 에이전트는 과도하게 오래 실행되어 **주기적 재시작** 필요 - 그러나 핵심 질문, 즉 “에이전트를 늘리면 자율 코딩을 확장할 수 있는가”에 대해 - **수백 개 에이전트가 수주간 협업하며 실제 진전 가능**함을 확인 - 이 기술은 향후 **Cursor의 에이전트 기능**에 반영될 예정임 ## Comments ### Comment 49291 - Author: neo - Created: 2026-01-16T08:59:38+09:00 - Points: 2 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46624541) - Steve Yegge의 글 [Welcome to Gas Town](https://medium.com/@steve-yegge/welcome-to-gas-town-4f25ee16dd04)과 관련된 작업을 하고 있어서 흥미롭게 봤음 - 최근 내가 공유한 [LLM 예측 글](https://simonwillison.net/2026/Jan/8/llm-predictions-for-2026/#3-years-someone-will-build-a-new-browser-using-mainly-ai-assisted-coding-and-it-won-t-even-be-a-surprise)에서 2029년쯤엔 **AI 보조 코딩으로 브라우저를 만드는 게 놀랍지 않을 것**이라 했는데, Cursor의 이번 프로젝트가 두 번째 시도임 다른 예시는 [이 Reddit 글](https://www.reddit.com/r/Anthropic/comments/1q4xfm0/over_christmas_break_i_wrote_a_fully_functional/)에서 볼 수 있음 - 똑똑한 구현이라면 그냥 GitHub의 **Chromium 소스**를 가져와서 불필요한 기능을 제거하고 외형만 바꾸는 식으로 하지 않을까 싶음 - 2029년쯤엔 펠리컨용 브라우저를 AI가 만든다는 농담이 나올 정도로 **기준을 높여야 할 시점**임 - Reddit의 예시 코드를 5분 정도 봤는데, **텍스트 레이아웃 계산과 bidi(양방향 텍스트)** 처리가 엉망이었음. 표준을 고려하지 않은 “브라우저”는 진짜 브라우저라 부르기 어려움 - 인상적이긴 하지만, 오픈소스 브라우저 코드가 모델의 **훈련 데이터**에 포함된 건 아닌지 의문임 - 예측이 빗나갔다고 하더니 일주일 뒤 같은 팟캐스트에 다시 나와서 새 예측을 한 이유가 궁금함 - 저장소의 테스트를 직접 돌려봤는데 **에러와 경고가 가득**했고, CI도 오래전부터 실패 중이었음. 이런 상태에서 “성공적인 예시”라 부르는 게 맞는지 모르겠음. 완전 자율 코딩보다는 **인간 중심 보조형 접근**이 더 현실적이라 생각함 - 코드베이스가 수백, 수천 개의 작은 파일로 쪼개져 있어서 **구조 파악이 거의 불가능**했음. README도 엉성하고 의존성 설명도 없음. AI가 만든 코드지만 유지보수는 악몽 수준임 - 작성자도 완전 자율 코딩을 진지한 제품화보다는 **LLM 한계 실험**으로 본 듯함. 지금은 작은 프로젝트 수준에서만 “혼자서 괜찮은 코드”를 낼 수 있는 단계임 - CI 실패한 PR을 그냥 머지했다니, **인간 수준의 품질**을 달성한 셈이라는 농담이 나올 만함 - “느리다”는 표현이 구체적으로 뭘 의미하는지 불분명함. GPU 속도? 인간보다 느리다는 뜻? 결국 **AI 버블을 부풀리는 글**로 느껴졌음 - 왜 그 PR을 아직 머지하지 않았는지 궁금함. **AI 에이전트 군집이 장기적으로 복잡한 소프트웨어를 완성**하는 미래는 멋지지만, 지금 예시는 너무 빈약함. 인간과의 협업 지점이 더 중요함 - 내 경험상 에이전트들은 수렴하지 않고 **점점 엉망이 되는 코드 괴물**을 만들어냄 - 작동하는 간단한 프로젝트 하나라도 공개하지 않은 건 **투자자 유인용 미끼**처럼 보임. AI 붐이 닷컴 버블과 비슷하지만, 이번엔 돈벌이에 더 집중된 느낌임 - 브라우저나 Excel, Windows 7 같은 예시는 훈련 데이터에 일부 포함됐겠지만, 그걸로 완전 복제는 불가능함 - 코드가 너무 방대하고 문제투성이여서 리뷰 자체가 불가능함. 결국 YOLO식 머지밖에 답이 없음 - 나는 **수렴 조건**에 관심이 있음. 코드가 늘어나든 줄어들든, 최적의 상태로 안정화되는 게 중요함 - 단계적으로 난이도를 높이며 실험하지 않은 게 아쉬움. **React CRUD → Paint 클론 → 파일 관리자 → 브라우저** 순으로 점진적으로 확장했다면 발전 단계를 명확히 볼 수 있었을 것임 - 나도 비슷한 방식으로 [tjs](https://github.com/sberan/tjs)를 만들었음. 세계에서 가장 빠르고 정확한 **JSON Schema Validator**인데, git subtree를 활용한 **planner/delegate 패턴**이 효과적이었음. 표준과 테스트가 잘 정의된 소프트웨어는 AI 에이전트가 빠르게 재작성하고 최적화할 수 있음 관련 명령은 [spawn-perf-agents.md](https://github.com/sberan/tjs/blob/main/.claude/commands/spawn-perf-agents.md)에서 볼 수 있음 - 브라우저를 처음부터 만든다는 건 매우 어렵지만, 글에서 제시한 내용은 **세부 분석이 부족**했음. 단순히 “컴파일된다”는 수준이라면 의미가 약함. 진짜 검증은 **다음 변경을 안정적으로 병합할 수 있느냐**임 - 에이전트 코딩의 최소 기준은 “컴파일 성공” → “정상 실행” → “엣지 케이스 처리” 순임. 인간보다 버그가 적은 시스템이 1년 이상 안정적으로 돌아가야 신뢰할 수 있음 - 실제로는 CI도 실패 중이라 “컴파일된다”는 주장조차 의심스러움 - 블로그에 따르면 **수조 개의 토큰**을 사용했다는데, OpenAI API 단가로 계산하면 수천만 달러 규모임. 이 정도면 그냥 **브라우저 팀에 기부**하는 게 나았을지도 모름 - 직접 빌드해봤는데 **100개 이상의 컴파일 에러**가 발생했음. 대부분의 커밋이 CI 실패 상태였고, 실제로는 여러 오픈소스 라이브러리를 조합한 것이었음. quickjs, wgpu, winit, egui, html parser 등 기존 구성요소를 그대로 가져왔는데, CEO는 “커스텀 JS VM”이라 주장해서 **오해를 불러일으킴** 그래도 이런 통합을 AI가 자율적으로 해냈다는 건 인상적임 - 사용된 구성요소들이 [Rust 기반 브라우저 blitz](https://github.com/dioxuslabs/blitz)와 매우 유사해서, **훈련 데이터에 포함됐을 가능성**이 있음 - “작동 여부는 중요치 않다, 스크린샷 찍고 투자자에게 보여라”는 식의 **스타트업식 농담**도 나왔음 - 6만여 번의 워크플로 중 1천여 번만 성공했다는 통계가 있음. 사실상 **검증되지 않은 코드 덩어리**로 보임 - “모두 각자 자신만의 커스텀 Cursor를 만들자”는 유머로 마무리됨 - 코드가 **매우 취약하고 불안정**해 보였음. 예를 들어 [render_placeholder 함수](https://github.com/wilsonzlin/fastrender/blob/main/crates/fastrender-renderer/src/lib.rs)는 단순히 프레임 버퍼를 채우는 임시 코드처럼 보임. 이런 코드가 실제로 어떤 역할을 하는지, 그리고 테스트별 **토큰/시간 비용**이 얼마나 되는지 궁금함 - 태그 속성을 추출하는 방식도 [이 부분](https://github.com/wilsonzlin/fastrender/blob/main/crates/fastrender-renderer/src/lib.rs#L441)처럼 다소 이상했음 - 하지만 **Cursor가 자동으로 수정해줄 수 있다면** 이런 취약성도 장기적으로는 의존성을 높이는 전략일 수 있음