개발 팀에서 AI 코딩 에이전트를 확장하는 방법

코딩 에이전트를 사용하는 한 명의 개발자는 생산성 이야기를 만들어냅니다. 이는 쉽게 설명할 수 있고, 데모도 잘 되며, 실제로도 그렇습니다.

하지만 다섯 명의 개발자가 스무 개의 에이전트를 사용하는 것은 전혀 다른 문제입니다. 이는 조정 문제이며, 조정 문제는 그것을 만든 도구로 해결되지 않습니다. 이것이 아무도 쓰지 않는 부분입니다. 왜냐하면 이는 열정 단계가 지나고 나서야 나타나기 때문입니다: 개인적인 이득은 실제로 존재하고 즉시 도착하지만, 세 번째 또는 네 번째 개발자쯤 되면 팀은 새로운 속도를 자기 정리하는 데 소비하기 시작합니다.

다음은 실패 순서입니다. 추상적인 최선의 관행 목록이 아니라, 실제로 문제가 발생하는 순서입니다. 잘못된 순서로 이를 수정하면 25%의 낭비가 발생합니다.

무엇이 먼저 깨지는가: 공유된 컨텍스트

에이전트를 실행하는 모든 개발자는 조용히 자신만의 코드베이스 버전을 가르치고 있습니다.

한 사람은 자신의 에이전트에게 프로젝트가 서버 액션을 사용하고 API 라우트를 사용하지 않는다고 말합니다. 다른 사람은 그것에 대해 언급하지 않아서 그들의 에이전트는 API 라우트를 작성합니다. 세 번째 사람은 세션이 종료된 지 삼일 된 상태에서 한 번 언급합니다. 아무도 틀리지 않았고, 아무도 거짓말을 하지 않았으며, 이제 저장소에는 동일한 규칙에 대한 세 가지 해석이 포함되어 있습니다. 이는 코드가 존재하는 잘못된 장소인 리뷰 대기열에서 눈에 띌 것입니다.

수정 방법은 지루하지만 이 페이지에서 가장 높은 레버리지입니다. 규칙을 파일에 넣고, 파일을 커밋하세요.

CLAUDE.md는 Claude Code용, AGENTS.md는 Codex 및 대부분의 다른 CLI 에이전트용이며, 실제로 많은 팀은 두 개의 파일을 유지하는 대신 하나의 휴대 가능한 컨텍스트 파일을 유지합니다. 메커니즘이 파일 이름보다 더 중요합니다: 지침은 저장소에 존재하므로, 누가 방에 있었는지에 관계없이 git pull로 도착합니다.

여기에 포함되어야 할 내용:

• 에이전트가 코드 읽기를 통해 추론할 수 없는 규칙, 특히 현재 코드베이스에서 위반되는 부분
• 명령어: 테스트, 빌드, 린터를 실행하는 방법 및 자동으로 실행할 수 있는 것
• 건드리기 위험이 있는 저장소의 부분과 그 이유
• 팀이 원하지 않는 것: 아무도 요청하지 않은 리팩토링, 추가해서는 안 되는 의존성, 벗어나고 있는 패턴

여기에 포함되어서는 안 되는 것, 그리고 이것이 팀이 화를 내는 부분입니다: 한 기계에 특정한 모든 것. 절대 경로, 개인 API 토큰, 로컬 포트, 누군가의 선호하는 편집기. 기계 특정 값이 커밋된 컨텍스트 파일에 들어가는 순간, 다른 모든 개발자는 자신에게 잘못된 설정을 상속받게 되며, 에이전트는 더 이상 적용되지 않는 지침을 충실히 따르는 데 매우 능숙합니다.

한 줄을 추가하기 전에 유용한 테스트: 팀원이 이를 가져가면 도움이 될까요, 아니면 그들을 망칠까요?

무엇이 두 번째로 깨지는가: 두 개의 에이전트, 하나의 파일

에이전트는 협상하지 않습니다. 그들은 누군가가 편집 중인지 확인하지 않습니다. 동일한 모듈을 가리키는 두 개의 에이전트는 서로를 덮어쓰게 되며, 각각은 자신의 관점에서 작업이 성공적으로 완료되었다고 생각하므로 이를 언급하지 않습니다.

혼자서는 이는 보이지 않습니다. 한 번에 하나의 에이전트를 실행하거나 여러 개를 실행하고 서로 다른 것들을 건드리게 됩니다. 팀에서는 구조적이 되며, 가장 나쁜 종류의 버그를 발생시킵니다: 두 개의 녹색 테스트 실행 사이에 작업이 조용히 사라지는 것입니다.

이를 해결하는 두 가지 메커니즘이 있으며, 두 가지 모두 필요합니다.

격리. Git 작업 트리는 각 작업에 대해 저장소의 자체 체크아웃을 제공하므로 병렬 에이전트가 물리적으로 충돌할 수 없습니다. 이는 해결책의 저렴한 절반이며, 이를 하지 않을 이유가 없습니다.

소유권. 격리는 덮어쓰기를 방지하지만, 두 사람이 동일한 문제를 두 개의 브랜치에서 두 가지 호환되지 않는 방식으로 두 번 해결하는 것을 방지하지는 않습니다. 이는 각 작업을 명시적인 파일 집합으로 범위 지정하고 작업 자체에서 이를 명시함으로써 해결됩니다. "체크아웃 흐름 개선"이 아니라 "이 세 개의 파일에서 결제 단계를 변경하고 장바구니는 건드리지 마세요"라고 말하는 것입니다.

두 번째 절반은 팀이 건너뛰는 부분이며, 이는 병합이 형식적인지 오후의 작업인지 결정합니다.

무엇이 세 번째로 깨지는가: 리뷰

팀 규모에서의 리뷰와 관련된 모든 것은 한 숫자에서 비롯됩니다: 시간당 얼마나 많은 diff가 도착하는가.

한 명의 개발자가 모든 줄을 읽는 것은 괜찮습니다. 네 명의 개발자가 각각 네 개의 에이전트를 실행하면 팀이 읽을 수 있는 것보다 더 많은 diff를 하루에 생성하며, 정직한 결과는 신중한 리뷰가 아니라 승인 극장입니다. 오후 6시에 900줄의 diff를 훑어보는 인간은 지식을 생산하지 않고 서명을 생성하며, 이는 리뷰를 하지 않는 것보다 더 나쁩니다. 왜냐하면 이는 아무것도 없는 곳에서 보장을 만들어내기 때문입니다.

살아남는 정책은 "모든 것을 리뷰하라"도 아니고 "에이전트를 신뢰하라"도 아닙니다. 이는 작업의 두 경계에서 리뷰를 이동하는 것입니다: 에이전트가 시작하기 전에 계획을 읽고, 잘못된 계획이 완벽하게 실행되는 것은 가장 비싼 실패 모드이므로, 변경이 깨뜨릴 수 있는 것에 비례하여 diff를 읽습니다. 마케팅 카피와 CSS는 훑어보는 것으로 충분합니다. 인증, 결제, 권한, 개인 데이터 및 마이그레이션은 매번 인간이 한 줄씩 읽어야 하며, diff가 얼마나 깨끗하게 보이든 상관없이 그렇습니다.

이는 별도의 대화를 받을 자격이 있으며, 우리는 이를 별도로 작성했습니다: AI 에이전트의 코드를 여전히 리뷰해야 할까요는 변경이 잘못되었음을 나타내는 10가지 객관적인 신호와 팀이 그대로 채택할 수 있는 폭발 반경 표를 다룹니다.

팀 특정 추가 사항. 여러 에이전트가 저장소를 공유할 때, 리뷰에는 귀속이 필요합니다: 어떤 에이전트, 어떤 작업, 어떤 개발자. 그렇지 않으면 diff에는 저자가 없고 리뷰는 고고학이 됩니다. 이는 세 개 또는 네 개의 동시 에이전트를 넘어서면 설정에서 수정할 수 있는 가장 유용한 사항입니다.

무엇이 네 번째로 깨지는가: 비용, 그리고 비용에 대한 대화

토큰 지출은 팀 청구서에 나타나는 순간 개인적인 세부 사항이 아닙니다.

함정은 청구서가 월별이고 집계적이라는 것입니다. 따라서 이로 인해 발생하는 대화도 월별이고 집계적이므로, 이는 수정을 위한 정책을 생성합니다. 누군가 모든 사람을 위한 더 저렴한 모델을 제안합니다. 다른 누군가는 세션을 제한하자고 제안합니다. 두 가지 모두 추측입니다.

실제 분포는 거의 균일하지 않습니다. 이는 한두 개의 프로젝트에서 긴 세션이 소수 존재하며, 하루 종일 커진 컨텍스트가 리셋되지 않은 것입니다. 이는 수정 가능한 행동이며, 월별이 아닌 세션 및 프로젝트별로 지출을 볼 수 있을 때만 수정할 수 있습니다. 우리는 토큰 사용량 확인 방법과 속도를 늦추지 않고 비용을 줄이는 방법에서 이 메커니즘을 다루었습니다.

숫자를 생성하는 사람들에게 가시적으로 만들어야 합니다. 관리 주제가 되기 전에 말이죠. 한 개발자가 한 세션이 자신의 전체 이전 하루보다 더 비쌌다는 것을 알 수 있다면, 그들은 스스로 습관을 바꾸게 되며, 이는 팀에 정치적으로 아무런 비용이 들지 않습니다.

팀의 의식에서 실제로 변화하는 것

우리의 경험과 팀의 보고에 따르면 세 가지입니다.

스탠드업이 상태에서 차단 해소로 전환됩니다. 각 사람이 어제 무엇을 했는지는 브랜치에서 대체로 볼 수 있습니다. 다섯 분이 가치 있는 것은 어떤 에이전트가 막혔고, 무엇에 막혔는지입니다.

프롬프트가 공유 자산이 됩니다. 한 개발자에게 좋은 결과를 가져온 지침은 팀에 더 가치가 있으며, 이는 개인 터미널 기록에서 증발하기 쉬운 것입니다. 저장소에 공유 프롬프트 라이브러리를 유지하는 팀은 매주 동일한 표현을 재발견하는 것을 멈춥니다.

전문화가 사람에서 역할로 이동합니다. 에이전트가 작성을 처리하게 되면, 흥미로운 질문은 누가 무엇을 리뷰하는가입니다. 팀은 자연스럽게 사람에게 역할을 부여하는 것과 같은 방식으로 에이전트에게 역할을 할당하는 쪽으로 이동합니다: 구현에는 하나, 리뷰에는 하나, 테스트에는 하나. 이는 에이전트 팀의 아이디어로, 작업이 Dev 역할에서 QA 역할로 전달되며, diff, 위험 및 테스트 힌트가 첨부되고 품질 게이트는 에이전트의 작업에 대한 의견이 아니라 테스트 스위트에 의해 결정됩니다.

유지되는 설정

중요한 순서로 요약하자면:

첫 네 가지는 동의만으로 비용이 들지 않습니다. 마지막 두 가지는 팀이 결국 터미널 이상의 것을 원하게 만드는 이유입니다: 터미널이 나쁘기 때문이 아니라, 터미널은 한 번에 하나의 에이전트만 보여주고 "누가 무엇을, 어떤 프로젝트에서, 지금 실행하고 있는가"라는 질문에 답할 방법이 없기 때문입니다.

이는 팀을 위한 AgentsRoom이 구축된 문제입니다: 모든 프로젝트에 걸쳐 모든 에이전트를 하나의 보기에서, 그 역할, 상태 및 비용이 첨부되어 있으며, 팀이 책상에 없을 때를 위한 모바일 동반자가 있습니다. 이는 Claude Code와 Codex 모두에서 동일한 방식으로 작동하며, 이는 들리는 것보다 더 중요합니다: 대부분의 팀은 결국 두 가지를 모두 실행하게 되며, 하나의 공급자를 가정하는 설정은 조용히 다음에 깨지는 것이 됩니다.

하지만 컨텍스트 파일부터 시작하세요. 이는 무료이며, 오후를 소요하고, 설치할 수 있는 어떤 도구보다 더 많은 마찰을 제거합니다.