3개월, 12개 인스턴스, 월 230달러. dev.to에 공개된 한 솔로 개발자의 병렬 에이전트 운영 회고는 숫자만 보면 꽤 매력적이다. Claude Code 10개 + Codex CLI 2개를 동시에 굴려 하루 처리 태스크를 10개에서 60~80개로 끌어올렸다. AI 유니버시티 프로바이더 200→270개, 경쟁사 페이지 22→174개 라우트, GitHub Actions 워크플로우 18→31개. 숫자만 보면 '나도 당장 해봐야겠는데?' 싶다.
그런데 이 회고가 진짜 가치 있는 건 성과 수치가 아니라 실패 기록이다. 가장 치명적인 장애는 마이그레이션 타임스탬프 충돌이었다. PS#3, PS#4, PS#5, Win 인스턴스가 동시에 20260428000000_*.sql을 만들어버린 것. 결과는 프로덕션 배포 실패(SQLSTATE 23505). 수습은 check_migration_timestamps.py를 CI에 박아 넣는 것으로 마무리됐지만, 핵심 교훈은 단순하다. 12개 인스턴스가 공유하는 네임스페이스(타임스탬프, Edge Function 이름, 사이트맵 URL)는 반드시 충돌 감지 레이어가 있어야 한다. 개별 에이전트가 스스로 조율할 거라고 기대하면 안 된다.
이 충돌 문제는 사실 에이전트 설계의 본질적인 한계를 건드린다. 요즘IT가 분석한 Claude Code 소스 유출 사례를 보면, 에이전트 루프의 핵심 구조는 생각보다 단순하다. [입력 → 컨텍스트 결합 → 모델 호출 → tool_use 감지 → 툴 실행 → 결과 재주입 → 반복]. Anthropic이 subagent 문서에서 명시하듯, 각 에이전트는 '자기 context window, 별도 system prompt, specific tool access, independent permissions'를 가진다. 분리는 되어 있다. 하지만 분리된 에이전트들이 공유 자원을 건드리는 순간, 조율 책임은 루프 밖에 있는 설계자에게 돌아온다.
여기서 병렬 에이전트 운영이 단일 에이전트와 근본적으로 다른 설계 문제를 요구한다는 게 명확해진다. 단일 에이전트는 '이 에이전트가 얼마나 잘하나'의 문제다. 병렬 에이전트는 '이 에이전트들이 서로 충돌하지 않게 어떻게 막나'의 문제다. 회고에서 가장 효과적이었던 건 역할 특화였다. PS#3는 AI 유니버시티 프로바이더 추가만, PS#6는 경마 AI 개선만, PS#2는 블로그 발행만—각자의 작업 도메인을 좁게 정의했더니 다른 인스턴스가 '빌딩'에 집중할 수 있었다. Claude Code 소스 유출 분석이 강조하는 '역할 분리는 예쁜 구조도가 아니라 책임 분리'라는 원칙과 정확히 일치한다.
툴 권한 설계도 마찬가지 논리다. read-only, external-read, write, exec, destructive로 위험도별로 등급을 나누고, 등급마다 승인 정책을 다르게 두는 방식. '툴을 붙였다'보다 '어떤 툴을 어떤 조건에서 열었나'가 병렬 환경에서는 훨씬 더 중요해진다. write나 exec 권한을 가진 에이전트가 12개면, 하나가 잘못 실행할 확률도 12배다. 최대 반복 횟수, 실패 시 중단 조건, human review 진입 조건은 시스템 레벨에서 따로 설계해야 한다. 각 에이전트 프롬프트에 묻어두면 운영 중에 추적이 안 된다.
비용 구조도 짚고 넘어가야 한다. 월 230달러로 12명 엔지니어 아웃풋을 낸다는 주장은 매력적이지만, 숨겨진 비용이 있다. 회고 저자 본인이 인정하듯 크로스 인스턴스 조율, 충돌 해결, 메모리 통합에 주당 3~4시간이 든다. PANews가 전하는 실리콘밸리 현실은 더 극단적이다. AI 스타트업 엔지니어 1인당 연간 토큰 예산이 20만 달러, 최고 엔지니어의 AI 비용이 연봉에 육박하는 경우도 있다. Meta는 내부 토큰 소비 순위표까지 만들어 가장 많이 쓴 사람을 상위에 올렸다. 인건비를 토큰 비용으로 대체했을 뿐 총비용은 그대로라는 냉정한 지적이 나오는 이유다. 병렬 에이전트 확장이 선형 비용 절감으로 이어진다는 가정은 검증이 필요하다.
회고에서 아직 해결 안 된 과제들도 솔직하게 나열됐다. 인스턴스 간 핸드오프는 여전히 사람이 중재한다. WBS 완료 보고 누락이 주당 2~3건씩 생긴다. 메모리 파일 자동 아카이빙이 없어 컨텍스트 소실이 발생한다. Codex 인스턴스는 Claude 대비 활용도가 낮다. 이 목록이 시사하는 건 분명하다. 병렬 에이전트를 굴리면 '에이전트를 관리하는 일'이라는 새로운 카테고리의 작업이 생긴다. 이걸 사람이 할지, 별도 오케스트레이터 에이전트가 할지 설계하지 않으면 규모가 커질수록 관리 오버헤드가 생산성 증가분을 잠식한다.
컨텍스트 관리도 병렬 환경에서 다르게 접근해야 한다. Claude Code 소스 분석이 지적하듯, 컨텍스트는 많이 넣는다고 좋아지지 않는다. '지속 규칙 / 작업 상태 / 근거 자료 / 이번 턴 임시 정보'를 분리하고, specialist에게 넘길 때는 전체 대화가 아니라 요약된 작업 카드만 넘겨야 한다. 12개 인스턴스가 각자 방대한 컨텍스트를 들고 있으면 토큰 비용도 폭발하고 품질도 흔들린다. 컨텍스트 운영은 기억력이 아니라 압축력의 문제다.
그렇다면 지금 당장 병렬 에이전트 도입을 고민하는 팀에게 뭘 먼저 설계하라고 말할 수 있을까. 세 가지다. 첫째, 역할과 소유권을 먼저 쪼개라. 같은 도메인을 두 에이전트가 건드리게 두지 말고, 각 에이전트의 입력·출력·툴 권한을 좁게 정의하라. 둘째, 공유 네임스페이스 충돌 감지를 CI에 넣어라. 에이전트가 많아질수록 타임스탬프·파일명·URL 충돌은 반드시 발생한다. 셋째, 에이전트 간 조율 비용을 선 측정하라. 관리 오버헤드가 몇 시간인지 측정하지 않으면 병렬화의 실제 ROI를 계산할 수 없다.
전망은 낙관적이지만 조건부다. METR 측정 기준으로 AI 에이전트의 작업 지속 가능 시간이 7개월마다 두 배씩 늘고 있고, 에이전트 신뢰성이 임계점을 넘는 순간 토큰 소비는 선형이 아닌 지수적으로 증가할 것이다. 병렬 에이전트 운영은 지금도 가능하지만, 그 가능성을 팀 생산성으로 연결하는 건 도구의 성능이 아니라 설계 판단이다. 12개를 굴리고 싶다면 먼저 1개가 실패했을 때 시스템이 어떻게 반응하는지 설계부터 하라.