AI 코딩 에이전트 늘리면 빨라질까? 맨먼스 미신·브룩스의 법칙

AI 코딩 에이전트를 더 붙인다고 개발 일정이 그만큼 줄지는 않아요. 에이전트는 코드를 빠르게 쓰지만, 무엇을 만들지 정하고 결과를 검토하고 여러 변경을 하나로 합치는 일은 여전히 사람의 시간이 들기 때문이에요. 1975년 프레드 브룩스가 『맨먼스 미신(The Mythical Man-Month)』에서 말한 브룩스의 법칙, 즉 '늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다'는 관찰이 형태만 바꿔 AI 시대에도 작동하는 셈이에요. 이 글은 2026년 10월 기준으로 공개된 연구와 사례를 바탕으로, 에이전트 병렬 투입이 어디서 효과를 내고 어디서 막히는지, 작업 분할과 리뷰 체계를 어떻게 설계할지 정리해요.

브룩스의 법칙이란? 맨먼스 미신이 말한 세 가지 이유

브룩스의 법칙은 IBM OS/360 프로젝트를 관리한 경험에서 나온 관찰이에요. 위키백과의 정리에 따르면 브룩스 스스로도 이 법칙을 '터무니없는 단순화'라고 불렀지만, 일반적인 경향은 잘 담고 있다고 봤어요. 늦어지는 원인은 크게 세 가지예요.

1. 적응(ramp-up) 비용: 새로 합류한 사람은 기존 코드와 결정을 배우는 동안 생산적이지 않고, 그를 가르치느라 기존 인원의 생산성도 떨어져요. 새 인원이 버그를 넣어 오히려 완료에서 멀어지게 할 수도 있어요.
2. 소통 비용: 사람이 늘면 서로 맞춰야 할 소통 경로가 조합적으로 늘어요. n명이 모두 서로 조율하면 경로는 n(n-1)/2개라서 3명이면 3개, 5명이면 10개, 10명이면 45개가 돼요.
3. 작업 분할의 한계: 호텔 객실 청소처럼 잘게 나눌 수 있는 일은 사람을 늘리면 빨라지지만, 소프트웨어의 많은 일은 그렇게 나뉘지 않아요. 브룩스의 비유대로 '아홉 명의 여성이 한 달 만에 아기를 낳을 수는 없어요'.

예외도 있어요. 이 법칙은 이미 늦어진 프로젝트에 주로 적용되고, 일정 초기에 사람을 넣거나 역할이 분명한 품질 보증·문서화 같은 일을 맡기면 적응 비용이 줄어요. 모듈화가 잘 되어 있으면 작은 팀이 하위 문제를 풀고 상위 팀이 통합만 맡아 소통 비용을 줄일 수 있지만, 실제로는 강하게 얽힌 부분을 억지로 나누면 문제가 더 커진다고 같은 문서는 설명해요. 이 예외 조건이 그대로 AI 에이전트 운용의 설계 기준이 돼요.

AI 코딩 에이전트에도 브룩스의 법칙이 적용될까

얼핏 보면 에이전트는 브룩스의 법칙을 피해 가는 것처럼 보여요. 수주의 온보딩도, 회의도, 휴식도 필요 없으니까요. 하지만 세 가지 원인을 하나씩 대응해 보면 비용이 사라진 게 아니라 자리를 옮겼다는 것을 알 수 있어요. 2026년 10월 27일 해커뉴스 상위에 오른 얀 판 덴 베르흐의 글도 '법칙은 사라지지 않고 변이했다'며, 누군가는 여전히 완료 기준을 정하고 코드를 검토하고 환각을 잡아내고 조각을 이어 붙여야 하며 그게 바로 사용자 자신이라고 정리했어요.

특히 소통 비용의 구조가 달라져요. 에이전트끼리 직접 협업시키면 사람 팀처럼 조율 경로가 늘고, 오케스트레이터 한 명(또는 사람 한 명)을 중심에 두면 경로는 줄지만 그 중심이 병목이 돼요. Anthropic은 멀티 에이전트 리서치 시스템 개발기에서 초기 에이전트가 단순한 질문에 하위 에이전트를 50개나 만들거나, 지시가 모호해 여러 에이전트가 같은 검색을 중복하는 문제를 겪었다고 밝혔어요. 각 하위 에이전트에게 목표·출력 형식·사용할 도구·작업 경계를 명확히 줘야 중복과 공백이 줄었다고 해요. 사람 팀의 업무 분장 문제와 거의 같아요.

데이터로 본 병목: 코드는 늘고 리뷰는 길어졌어요

Ars Technica가 2026년 10월 9일 소개한 연구는 하버드대 연구진이 엔지니어링 분석 업체 Jellyfish의 집계 데이터로 700개 이상 기업, 70만 명 이상의 2021년~2026년 3월 작업 기록을 분석한 결과예요. AI 코딩 에이전트를 도입한 기업에서 코드 줄 수는 평균 30%, 커밋은 20%, 풀 리퀘스트(PR)는 23% 늘었어요. 그런데 Jira 같은 도구로 추적한 이슈·에픽(기능 단위 작업)의 처리율은 통계적으로 유의미하게 변하지 않았어요.

차이는 리뷰 단계에서 흡수됐어요. PR 제출부터 머지까지의 리뷰 시간이 평균 49% 길어졌고, 수정 요청을 받는 PR 비중은 거의 두 배가 됐으며, PR당 댓글 수는 35% 늘었어요. 코드 리뷰를 하는 인력 비중도 14% 늘었어요. 이 연구는 에이전트 '개수'를 늘린 실험이 아니라 도입 전후를 비교한 관찰 연구라는 점, 2026년 3월 이후 도구 개선은 반영되지 않았다는 점을 함께 고려해야 해요. 그래도 '작성 속도가 늘어도 하류 공정이 그대로면 산출물은 늘지 않는다'는 브룩스식 결론과 맞아떨어져요.

개인 체감과 측정값은 다를 수 있어요

METR의 2025년 무작위 대조 실험에서 숙련 오픈소스 개발자 16명은 246개 실제 이슈를 처리할 때 AI를 쓰면 19% 더 오래 걸렸어요. 참가자들은 시작 전 24% 빨라질 거라 예상했고, 끝난 뒤에도 20% 빨라졌다고 믿었어요. METR은 2026년 2월 업데이트에서 최신 도구로는 속도가 빨라졌을 가능성이 높다고 봤지만, AI 없이 일하기를 원치 않는 개발자가 실험에서 빠지고 여러 에이전트를 동시에 돌리는 개발자의 작업 시간은 신뢰성 있게 재기 어려워 측정이 불안정하다고 밝혔어요. 병렬 에이전트의 효과를 느낌만으로 판단하면 안 되는 이유예요.

멀티 에이전트 개발에 맞는 작업과 맞지 않는 작업

Anthropic은 같은 글에서 멀티 에이전트 구조가 서로 독립적인 방향을 동시에 탐색하는 넓은 조사에 특히 강하다고 했어요. 내부 평가에서 리드 에이전트와 하위 에이전트 조합이 단일 에이전트보다 90.2% 높은 점수를 냈고, 하위 에이전트를 병렬로 띄워 복잡한 질의의 조사 시간을 최대 90% 줄였다고 해요. 반면 대부분의 코딩 작업은 리서치보다 진짜로 병렬화할 수 있는 부분이 적고, 모든 에이전트가 같은 맥락을 공유해야 하거나 의존 관계가 많은 작업은 아직 멀티 에이전트에 잘 맞지 않는다고 분명히 적었어요. 비용도 커서, 에이전트는 일반 채팅보다 약 4배, 멀티 에이전트 시스템은 약 15배의 토큰을 쓴다고 했어요.

병렬 AI 코딩 에이전트 작업 분할·리뷰 설계 단계

1. 1

   분할 가능성부터 확인해요

   작업을 쪼갠 뒤 각 조각이 어떤 파일과 인터페이스를 건드리는지 적어요. 두 조각이 같은 파일이나 공용 타입을 바꾼다면 병렬이 아니라 순서로 처리해요. 쪼갤 수 없는 일은 에이전트 하나와 사람 한 명이 끝까지 맡는 편이 빨라요.

2. 2

   소유 범위와 완료 조건을 문서로 줘요

   에이전트마다 목표, 수정 가능한 디렉터리, 출력 형식, 통과해야 할 테스트를 명시해요. '알아서 개선해 줘' 같은 모호한 지시는 중복 작업과 서로를 덮어쓰는 변경으로 이어지기 쉬워요.

3. 3

   격리된 작업 공간에서 실행해요

   브랜치나 git worktree처럼 서로 분리된 공간에서 돌리면 실행 중 충돌을 막고, 실패한 시도를 버리기도 쉬워요. 공유 자원(DB·포트·빌드 캐시)이 겹치지 않는지도 확인해요.

4. 4

   자동 검증을 리뷰 앞에 둬요

   타입 검사, 린트, 단위 테스트, 통합 테스트를 사람이 보기 전에 통과시키면 리뷰어가 의미와 설계 판단에 집중할 수 있어요. AI 리뷰는 1차 필터로 쓰고 최종 판단은 사람이 해요.

5. 5

   리뷰 용량에 맞춰 동시 실행 수를 정해요

   하루에 꼼꼼히 검토할 수 있는 PR 수와 크기를 먼저 정하고, 그 이상은 에이전트를 늘리지 않아요. 리뷰 대기열이 쌓이기 시작하면 에이전트를 줄이고 PR을 작게 나누는 신호로 봐요.

6. 6

   리드타임으로 효과를 측정해요

   코드 줄 수나 PR 수가 아니라 기능이 요청돼서 배포되기까지의 시간, 리뷰 대기 시간, 되돌림 비율을 도입 전후로 비교해요. 앞의 연구처럼 산출량 지표만 오르고 완료 지표는 그대로일 수 있어요.

위험과 한계: 빠른 코드가 남기는 부채

병렬 에이전트의 숨은 비용은 뒤늦게 나타나요. 각 에이전트는 자기 지시에 맞는 국소적으로 그럴듯한 코드를 쓰지만, 합쳐 놓으면 중복 구현이나 서로 다른 오류 처리 방식, 일관되지 않은 이름 짓기가 쌓일 수 있어요. 아무도 전체 설계를 머릿속에 갖고 있지 않으면 장애가 났을 때 원인 추적이 오래 걸려요. 브룩스가 강조한 개념적 일관성, 즉 '한 사람이 설계한 것처럼 보이는 시스템'을 유지하려면 아키텍처 결정과 최종 머지 권한을 소수의 사람이 쥐는 구조가 여전히 유효해요.

비용 측면도 따져야 해요. 토큰 사용량이 에이전트 수에 비례해 늘고 실패한 시도도 비용에 포함되니, 사람의 리뷰 시간을 아껴 주지 못하는 병렬 실행은 비용만 키울 수 있어요. 또 위에서 인용한 수치는 특정 기간·특정 표본의 결과라서 팀의 언어, 코드베이스 성숙도, 테스트 수준에 따라 달라질 수 있어요. 새 모델과 도구가 나올 때마다 같은 지표로 다시 측정하는 습관이 필요해요.

AI 개발 도구와 에이전트 운용 논의는 빠르게 바뀌어요. 더따리 텔레그램 AI 트렌드에서 개발자 커뮤니티가 주목하는 도구·사례 흐름을, 블로그 트렌드에서 실무 후기와 분석 글을 모아 볼 수 있어요. 화제가 된 주장은 원 연구의 표본과 측정 방법을 함께 확인하세요.

페이지 참고

트렌드theddari.com›트렌드텔레그램 · AIAI 채널 실시간 포스팅 피드

페이지 참고

트렌드theddari.com›트렌드블로그 포스팅요약된 네이버 블로그 글 피드

정리하면, AI 코딩 에이전트는 '사람을 더 넣는 것'과 같은 함정에 빠질 수 있지만 브룩스가 제시한 예외 조건, 즉 잘 나뉜 작업, 분명한 역할, 일찍 투입, 깔끔한 모듈 경계를 갖추면 병렬화의 이득을 얻을 수 있어요. 에이전트 수는 결과가 아니라 설계의 산물이에요. 먼저 나눌 수 있는지, 검증할 수 있는지, 리뷰할 수 있는지를 확인한 뒤 그 범위 안에서 동시 실행 수를 정하세요.