솔직히 말씀드리죠.
저는 'AI 에이전트가 개발자를 대체한다'는 소리를 들으면 코웃음부터 칩니다.
대부분의 데모 영상은 'Hello World' 수준이거나, 잘 짜인 각본일 뿐이니까요.
현업에서 에이전트 돌려보신 분들은 아실 겁니다.
조금만 복잡해지면 에이전트가 멍하니 멈추거나, 같은 코드를 무한 루프로 수정하다가 GPU 비용만 태워먹는다는 것을요.
그런데 최근 입수한 Cursor의 내부 실험 리포트는 조금 충격적이었습니다.
이들이 '장기 실행 자율 코딩(Long-running autonomous coding)' 실험을 통해 밝혀낸 엔지니어링의 실체가 꽤나 적나라했거든요.
단순한 '기능 홍보'가 아니라, 피 튀기는 분산 시스템의 실패 기록에 가까웠습니다.
오늘은 이 리포트에서 우리가 뼈저리게 배워야 할 포인트만 짚어드립니다.
1. 민주적인 에이전트? 개발 지옥의 시작
Cursor 팀의 첫 시도는 순진했습니다.
여러 에이전트에게 동등한 권한을 주고, "자, 너희끼리 파일 잠금(Locking) 걸면서 협업해봐"라고 시켰죠.
결과는 어땠을까요?
대실패였습니다.
어떤 에이전트는 락(Lock)을 걸고 죽어버렸고, 어떤 놈은 락을 푸는 걸 까먹었습니다.
심지어 20개의 에이전트를 투입했는데, 서로 눈치만 보느라 실제 처리량은 2~3명분밖에 안 나왔습니다.
낙관적 동시성 제어(Optimistic Concurrency Control)를 도입해도 마찬가지였습니다.
계층이 없으니 에이전트들이 '위험 회피 성향'을 보이더군요.
어렵고 큰 구조 변경은 아무도 안 건드리고, 만만한 자잘한 수정만 하더라는 겁니다.
마치 책임지기 싫어서 리팩토링 미루는 일부 개발팀 분위기와 소름 돋게 똑같지 않습니까?
2. 결국 답은 '군대식 계층 구조'
실패 끝에 이들이 찾은 해법은 Planner(설계자)와 Worker(작업자)의 철저한 분리였습니다.
Planner는 코드를 짜지 않습니다.
전체 구조를 보고 작업을 잘게 쪼개서 Worker에게 던져줍니다.
Worker는 큰 그림 따위 신경 쓰지 않습니다.
받은 티켓 하나를 처리하는 데만 집중하고, 끝나면 칼같이 PR을 날립니다.
이 구조로 가니 수백 개의 에이전트가 동시에 돌아가도 병목이 사라졌습니다.
결과물이요?
이 시스템으로 웹 브라우저를 바닥부터(Scratch) 구현했습니다.
1주일 동안 100만 줄(Line of Code)을 작성했고, 1,000개 이상의 파일을 생성했습니다.
심지어 윈도우 7 에뮬레이터, 엑셀 클론까지 만들어냈습니다.
단순한 데모 수준이 아니라, 수천 번의 커밋(Commit)이 쌓인 실제 프로젝트였습니다.
3. 모델 선택의 트레이드오프: 멍청하지만 끈기 있는 놈이 이긴다
이 부분이 제일 흥미로웠습니다.
비용 효율화를 고민하는 CTO 입장에서 눈이 번쩍 뜨이더군요.
장기 프로젝트에서는 소위 '똑똑하다'는 모델들이 오히려 독이 됐습니다.
Opus 4.5 같은 모델은 코딩은 잘하지만, '빨리 끝내고 싶어 하는' 경향이 있었습니다.
복잡한 구현 대신 꼼수(Shortcut)를 쓰거나, 제어권을 빨리 넘겨버리는 거죠.
반면 GPT-5.2는 지시를 끈질기게 따르고, 드리프트(주제 이탈)가 적었습니다.
더 재밌는 건, 코딩 특화 모델(Codex)보다 범용 모델이 'Planner' 역할에는 더 적합했다는 겁니다.
결국 "비싼 모델이 무조건 좋다"는 환상은 여기서도 깨집니다.
역할(Role)에 맞는 모델을 섞어 쓰는 '모델 믹스' 전략 없이는 돈만 날린다는 뜻입니다.
결론: 개발자는 사라지지 않는다, 다만 '설계자'가 될 뿐
이 리포트를 보고 "이제 개발자 다 죽었네"라고 생각하신다면 오산입니다.
오히려 그 반대입니다.
에이전트 수백 마리를 풀어놔도, 결국 그들에게 '무엇을 만들지' 정의하고 '구조'를 잡아주는 Planner의 역할은 누군가가 해야 합니다.
Cursor 팀도 "프롬프트 깎는 노하우가 시스템 구조보다 더 중요했다"고 고백했으니까요.
앞으로 우리는 코드를 직접 타이핑하는 시간보다, 에이전트들이 싼 똥(Conflict)을 치우고, 그들이 엇나가지 않게 아키텍처를 강제하는 데 더 많은 시간을 쓰게 될 겁니다.
그러니 주니어 여러분.
AI가 코드 짜준다고 좋아만 하지 마세요.
그 코드가 '왜' 그렇게 동작하는지, '비용'은 얼마나 드는지 계산하지 못하면, 여러분은 그냥 비싼 GPU 난로 관리인으로 전락할 겁니다.
지금 당장 IDE 끄고, 시스템 아키텍처 그림부터 다시 그려보세요.
그게 여러분이 살아남을 유일한 길입니다.
