▲

장시간 실행되는 자율 코딩의 확장

 (cursor.com)
10P by GN⁺ 24시간전 | ★ favorite | 댓글 2개
  • 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의 에이전트 기능에 반영될 예정임
▲
kdman98 21시간전  [-]

integrator 역할이 오히려 병목을 유발한다는 말에 시선이 가네요. 실제로 그게 정답일지, 더 나은 방법이 있었을지도 조금 궁금하고요.

답변달기
▲
GN⁺ 24시간전  [-]
Hacker News 의견들

  • Steve Yegge의 글 Welcome to Gas Town과 관련된 작업을 하고 있어서 흥미롭게 봤음

  • 최근 내가 공유한 LLM 예측 글에서 2029년쯤엔 AI 보조 코딩으로 브라우저를 만드는 게 놀랍지 않을 것이라 했는데, Cursor의 이번 프로젝트가 두 번째 시도임
    다른 예시는 이 Reddit 글에서 볼 수 있음

    • 똑똑한 구현이라면 그냥 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를 만들었음. 세계에서 가장 빠르고 정확한 JSON Schema Validator인데, git subtree를 활용한 planner/delegate 패턴이 효과적이었음. 표준과 테스트가 잘 정의된 소프트웨어는 AI 에이전트가 빠르게 재작성하고 최적화할 수 있음
    관련 명령은 spawn-perf-agents.md에서 볼 수 있음

  • 브라우저를 처음부터 만든다는 건 매우 어렵지만, 글에서 제시한 내용은 세부 분석이 부족했음. 단순히 “컴파일된다”는 수준이라면 의미가 약함. 진짜 검증은 다음 변경을 안정적으로 병합할 수 있느냐임

    • 에이전트 코딩의 최소 기준은 “컴파일 성공” → “정상 실행” → “엣지 케이스 처리” 순임. 인간보다 버그가 적은 시스템이 1년 이상 안정적으로 돌아가야 신뢰할 수 있음
    • 실제로는 CI도 실패 중이라 “컴파일된다”는 주장조차 의심스러움

  • 블로그에 따르면 수조 개의 토큰을 사용했다는데, OpenAI API 단가로 계산하면 수천만 달러 규모임. 이 정도면 그냥 브라우저 팀에 기부하는 게 나았을지도 모름

  • 직접 빌드해봤는데 100개 이상의 컴파일 에러가 발생했음. 대부분의 커밋이 CI 실패 상태였고, 실제로는 여러 오픈소스 라이브러리를 조합한 것이었음.
    quickjs, wgpu, winit, egui, html parser 등 기존 구성요소를 그대로 가져왔는데, CEO는 “커스텀 JS VM”이라 주장해서 오해를 불러일으킴
    그래도 이런 통합을 AI가 자율적으로 해냈다는 건 인상적임

    • 사용된 구성요소들이 Rust 기반 브라우저 blitz와 매우 유사해서, 훈련 데이터에 포함됐을 가능성이 있음
    • “작동 여부는 중요치 않다, 스크린샷 찍고 투자자에게 보여라”는 식의 스타트업식 농담도 나왔음
    • 6만여 번의 워크플로 중 1천여 번만 성공했다는 통계가 있음. 사실상 검증되지 않은 코드 덩어리로 보임
    • “모두 각자 자신만의 커스텀 Cursor를 만들자”는 유머로 마무리됨

  • 코드가 매우 취약하고 불안정해 보였음. 예를 들어 render_placeholder 함수는 단순히 프레임 버퍼를 채우는 임시 코드처럼 보임.
    이런 코드가 실제로 어떤 역할을 하는지, 그리고 테스트별 토큰/시간 비용이 얼마나 되는지 궁금함

    • 태그 속성을 추출하는 방식도 이 부분처럼 다소 이상했음
    • 하지만 Cursor가 자동으로 수정해줄 수 있다면 이런 취약성도 장기적으로는 의존성을 높이는 전략일 수 있음
답변달기