AI 코딩 에이전트를 팀에 도입하고 나서 가장 먼저 무너지는 것은 코드 품질이 아니다. 팀의 암묵적 합의다. 누가 어디를 건드리고 있는지, 어떤 결정이 이미 내려졌는지, 지금 진행 중인 작업이 어디까지 왔는지—이 정보들이 개인 세션 안에 갇히기 시작한다. 에이전트가 대신 코드를 짜는 속도는 빨라졌는데, 팀이 공유하던 맥락은 오히려 더 빠르게 증발한다.
이 글은 그 문제를 구조적으로 다루는 세 가지 설계 축을 정리한다. 에이전트 자율화(Claude Code 자동 모드), 사전 명세 설계(Spec Driven Development), 팀 협업 규약(AI 코딩팀 워킹 어그리먼트)—이 세 축은 각각 독립적인 주제처럼 보이지만, 실제로는 하나의 운용 프레임워크를 구성한다. 하나만 설계하면 나머지 두 개가 빈 곳을 만들어낸다.
축 1. 에이전트 자율화: 자동 모드를 '켤 것인가'가 아니라 '어떻게 운용할 것인가'
Anthropic이 8월 14일부터 Claude Code의 자동 모드를 Pro·Max·팀 플랜 기본값으로 전환한다고 발표했다. 표면적으로는 UX 개선이지만, 그 배경에 있는 데이터가 더 중요하다. 사용자는 권한 요청 프롬프트의 97%를 승인하고 있었다. 반사적 승인이 99%에 가까운 상황에서 '사람이 검토한다'는 전제는 이미 허구였던 셈이다.
더 결정적인 수치가 있다. Anthropic이 유료 테스터 1,053명을 대상으로 실험했을 때, 위험한 명령이 포함된 승인 프롬프트를 사람이 잡아낸 비율은 13.6%였다. 자동 모드는 89%를 탐지해 차단했다. Trajectory Labs 테스트에서는 72종의 프롬프트 인젝션 공격에 대해 Claude Code 자동 모드가 공격 성공률 0%를 기록했다. GPT-5.6 솔을 자동 승인 모드로 실행한 경우는 5.83%가 뚫렸다.
이 수치가 의미하는 바는 하나다. 수동 승인이 보안을 담보하지 않는다. 오히려 '확인했다'는 착각이 위험을 키운다. 자동 모드 전환은 그래서 에이전트에게 자율권을 주는 결정이 아니라, 사람의 검토를 형식이 아닌 실질로 되돌리는 설계다. 수백 건의 반사적 클릭을 제거하고, 사람의 주의를 진짜 판단이 필요한 지점에 집중시키는 구조로 바꾸는 것이다.
팀 운용 관점에서 자동 모드 전환이 요구하는 것은 하나다. 에이전트가 자율적으로 실행하는 범위와, 반드시 사람이 판단해야 하는 경계를 사전에 명시하는 것. 이 경계 설계 없이 자동 모드를 켜면 속도는 오르고 통제 감각은 사라진다. 엔터프라이즈·API 플랜은 9월 이후 전환 예정이라 아직 시간이 있다. 그 시간을 경계 설계에 써야 한다.
축 2. 사전 명세 설계: 에이전트가 표류하지 않으려면 '프롬프트'가 아닌 '스펙'이 있어야 한다
AI 코딩 에이전트에게 "로그인 너무 자주 하면 막아줘"라고 하면 에이전트는 뭔가를 만들어낸다. 그런데 그게 팀이 원한 것인지는 코드가 나온 뒤에야 알게 된다. Spec Driven Development는 이 문제를 정면으로 겨냥한다. 소스 기사의 표현을 빌리면, 에이전트의 표류(drift)—모호한 프롬프트를 재해석하고, 조용히 스코프를 확장하고, 기술적으로 동작하지만 아무도 요청하지 않은 코드를 내놓는 패턴—를 막는 유일한 방법은 프롬프트가 아닌 명세를 진실의 원천(source of truth)으로 만드는 것이다.
7단계 파이프라인(constitution → specify → clarify → plan → tasks → implement → analyze)은 그 메커니즘이다. 각 단계 사이에 사람의 검토 게이트가 있고, 그 게이트가 에이전트가 잘못된 해석을 3시간 동안 달리기 전에 멈추게 하는 장치다. 핵심은 clarify 단계다. 여기서 모호한 요구사항을 EARS 표기법으로 전환한다.
Given a user has attempted to log in 5 times within 1 minute
When the user attempts to log in again
Then the system shall block the login attempt and return a rate limit error
이 문장을 에이전트는 재해석할 수 없다. "어느 정도 rate limiting을 넣어줘"는 에이전트의 판단 영역이지만, 위 문장은 에이전트의 실행 명령이다. 이것이 Spec Driven Development가 실제로 바꾸는 것이다.
도구 선택지는 세 가지다. GitHub Spec Kit은 오픈소스 CLI 기반으로 워크플로우를 직접 구성하고 싶은 팀에 맞는다. AWS Kiro는 IDE 자체가 Spec Driven Development 중심으로 설계된 풀 솔루션으로, 2026년 5월 GA 이후 이미 25만 명 이상의 개발자가 사용 중이다. 세 번째 옵션은 도구 없이 AGENTS.md를 잘 쓰고 수동 리뷰 규율을 유지하는 것—소규모 프로젝트에서는 실제로 작동한다.
단, Thoughtworks Technology Radar가 Spec Driven Development를 Adopt가 아닌 Assess 링에 놓은 이유를 직시해야 한다. 모든 티켓에 7단계를 동일하게 적용하면 문서 오버헤드가 두 배가 되고, 팀은 한 달 안에 이 워크플로우를 혐오하게 된다. CSS 한 줄 수정에 전체 게이트를 돌리는 건 Spec Driven Development가 아니라 AI 에이전트를 붙인 워터폴이다. 규칙은 단순하다: 리스크와 모호함에 비례해서 단계를 조정할 것. 고위험·고모호 작업에 풀 게이트를, 단순 변경에는 한 줄 스펙과 바로 implement를.
축 3. 팀 협업 규약: 암묵적 합의를 기계가 읽을 수 있는 문서로
모든 팀에는 불문율이 있다. "auth 건드리기 전에 먼저 물어봐