TL;DR
이 글에서는 팀 레벨의 AI 코딩 표준화 전략(팀 기반의 에이전틱 코딩 전략)을 제안합니다. 핵심은 세 가지입니다. 현재 Pilot으로 구현된 워크플로우는 여기에서 확인하실 수 있습니다.
- 첫째, Grounding Context—에이전트가 참조하는 규칙과 템플릿을 팀 전체가 공유하고 버전 관리하고 개선합니다.
- 둘째, 단계별 Human Checkpoint—Agent Loop를 의도적으로 끊고 사람이 검증합니다.
- 셋째, 표준화된 워크플로우—/task:new, /task:start, /task:review 같은 명령어로 누가 실행하든 동일한 프로세스와 프롬프트를 적용합니다.
실제 워크플로우는 Research(사람이 계획 작성) → Plan(AI가 태스크 생성) → Review(사람이 검토) → Implement(AI가 코드 작성) → Verify(사람/AI가 리뷰)의 흐름을 따릅니다. 각 단계에서 생성된 문서(00-plan.md, 10-task.md, 20-result.md)가 다음 단계의 입력이 되며, 컨텍스트를 새로 열어 멀티 턴 성능 저하를 방지합니다.
에이전틱 코딩
Agentic Coding은 AI가 코드베이스 전체 맥락을 이해하고, 사용자의 고차원적 목표를 자율적으로 달성하는 시스템 또는 그 구현체를 의미합니다. 목표를 제시하면 AI가 계획 수립부터 코드 수정, 테스트, 오류 수정까지 주도적으로 수행합니다. Code Assist는 단순히 자동 완성 수준(Snippet) 기반에서 챗봇 인터페이스를 거쳐 이제 Agent 기반으로 변화하고 있습니다. 이제 스스로 계획하고 실행하는 에이전틱 코딩이 현실화되었다고 생각합니다. 그리고 이 글에서 말하는 팀 기반의 에이전틱 코딩은 에이전틱 코딩 시스템을 활용해 팀으로 일하는 프로세스를 의미합니다.
라쿠텐의 사례
라쿠텐은 Claude Code를 활용해 복잡한 리팩토링과 기능 구현을 최대 7시간 동안 완전 자율로 진행시켰고, 결과적으로 신규 기능 출시 리드타임을 24일에서 5일로 단축(79% 감소)했습니다. 유스케 카지(General Manager of AI for Business)는 “개발자는 하나의 태스크에 집중하고 나머지 네 개를 Claude Code에게 병렬로 맡겨 5개 작업을 동시에 진행할 수 있다”는 식으로, 에이전트가 팀의 병렬 처리 능력을 곱절로 키워주는 구조라고 설명했습니다.
바이브 코딩과의 차이점
Andrej Karpathy가 말한 Vibe Coding은 코드를 신경 쓰지 않고 결과만 보며 진행하는 '태도'를 뜻합니다. 개인 프로젝트에선 가능하지만, 팀 환경에서는 기술 부채와 보안 취약점으로 이어질 가능성이 높습니다. 팀 기반의 AI 활용 코딩은 오히려 Vibe 하지 않아야 합니다. 명확한 명세, 계획 수립, 사람과 Agent의 공동 검토, 구현의 위임과 적극적 개입, 리뷰 및 테스트, 최종 배포까지 Agent Loop에 사람이 개입해야 한다고 생각합니다. Vibe 코딩이 Agent Loop를 방관하는 태도라고 한다면 팀 기반의 Agentic Coding은 Agent Loop에 사람이 적극적으로 개입하고 Agent Loop를 의도적으로 제어, 조작하는 Human in the Loop의 과정을 반복하며 개선해나가는 과정입니다.
Human in the Loop가 필요한 이유
AI의 근본적인 한계
LLM은 본질적으로 비결정적입니다. 동일한 입력에도 다른 출력을 생성하며 결정적 설정을 기반으로 동일한 프롬프트를 제공해도 최대 10%~15% 정도의 출력 정확도 변동이 발생한다는 연구 결과가 있습니다. 그리고 최상과 최악 성능의 격차가 심한경우 70%에 달한다고 합니다.
또한 LLM은 특정 조건(예: 다중 턴 대화, 컨텍스트 길이 증가, 훈련 데이터 오염)에서 성능이 급격히 저하되는 Dumb Zone 영역을 가지고 있습니다. 특히 멀티 턴 대화에서 이러한 현상이 두드러지며 최근 (연구)[https://arxiv.org/abs/2505.06120]에 따르면 모든 주요 LLM이 멀티 턴 대화에서 싱글 턴 대비 평균 39%의 성능 저하를 보입니다. GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro 같은 플래그십 모델도 예외가 아닙니다.
컨텍스트 길이 증가에 따른 성능 저하도 심각합니다. NoLiMa 벤치마크에 따르면 32k 토큰에서 12개 모델 중 11개가 짧은 컨텍스트 대비 50% 이하의 성능으로 떨어집니다. Llama 4 Scout는 물리적으로 10M 토큰을 수용할 수 있지만, 실제 추론 능력은 128k~256k 토큰 이후 급격히 저하되며 복잡한 검색 태스크에서 정확도가 15.6%까지 떨어집니다.
개인화된 사용의 문제: Prompt Drift
AI의 근본적 한계에 더해, 팀 환경에서는 개인화된 사용 방식이 추가적인 문제를 만듭니다. 개발자 A가 "이 함수를 리팩토링해줘"라고 요청하고, 개발자 B가 "클린 코드 원칙에 맞게 개선해줘"라고 요청하면 의도는 같아도 결과물의 구조, 네이밍, 패턴이 달라집니다.
더 큰 문제는 Cascading입니다. 하나의 작업에서 발생한 작은 편차가 다음 단계로 전달되면서 증폭됩니다. 개인마다 다른 프롬프트로 시작한 작업들이 PR로 합쳐질 때, 코드베이스 전체의 일관성이 무너지고 기술 부채가 기하급수적으로 쌓입니다.
개발자의 역할 변화
이러한 한계를 극복하려면 개발자의 역할이 달라져야 합니다. 코드를 직접 타이핑하고 문법을 맞추는 저수준 작업은 AI 에이전트에게 위임하고, 개발자는 목표를 정의하고 결과를 검증하는 고차원적 작업을 수행해야 합니다.
팀 기반 에이전틱 코딩에서 각 팀원은 AI Agent에게 작업을 지시하고 관리하는 '팀장'의 역할을 맡습니다. 기존의 반복적인 '코딩-디버깅' 루프가 '목표 설정-검토-승인'이라는 관리자형 워크플로우로 변경됩니다. AI의 비결정성과 Prompt Drift를 통제하려면, 개발자가 Agent Loop에 적극적으로 개입하고 각 단계의 결과물을 검증하는 Human in the Loop 체계가 필수입니다.
팀 레벨의 표준화 전략
팀 레벨의 표준화 전략이 필요한 이유
팀 단위로 일하는 상황이 불가피하다면 앞서 살펴본 문제들—AI의 비결정성, 멀티 턴 성능 저하, Prompt Drift와 Cascading—은 개인이 해결할 수 없습니다. 개발자 한 명이 아무리 좋은 프롬프트를 작성해도, 옆 동료가 다른 방식으로 에이전트를 사용하면 코드베이스의 일관성은 무너집니다.
에이전틱 코딩 환경에서 개발자의 역할은 코드를 직접 작성하는 것에서 목표를 정의하고 결과를 검증하는 방향으로 이동합니다. 각 개발자가 자신의 AI 에이전트를 관리하는 '팀장'이 되는 셈입니다. 하지만 n명의 개발자가 각자 다른 방식으로 n개의 AI를 관리하면서 라쿠텐 사례처럼 효율성만 강조한다면, Vibe 코딩과 다를 바 없는 혼란을 초래합니다.
AI로 인한 생산성 향상은 곧 효율화 압박으로 이어집니다. "AI 쓰면 5배 빠르다던데?"라는 기대 속에서 검증 없이 결과물을 밀어붙이는 상황이 발생하기 쉽습니다. 속도는 빨라졌지만 코드 품질은 들쭉날쭉하고, 리뷰어는 AI가 생성한 대량의 코드를 감당하지 못하며, 기술 부채는 눈에 보이지 않게 쌓입니다. 이런 상황을 막는 가드레일이 필요합니다.
결국 필요한 것은 '개인의 개입'이 아니라 '팀 차원의 개입 체계'입니다. 개발자들이 AI를 관리하는 방식 자체를 표준화해야 합니다. 에이전트가 참조하는 규칙, 워크플로우의 단계, 검증의 기준이 팀 전체에서 공유되어야 개인의 프롬프트 차이와 무관하게 결과물이 일정한 품질로 수렴합니다. 표준화된 워크플로우, 표준화된 프롬프트, 표준화된 리뷰 프로세스가 그 가드레일입니다.
표준화 전략의 실제 구현(안)
.ai 디렉토리 하위에 팀 단위로 공유해야하는 Grounding Rules, Workflow, Template, AI Agent에게 전달할 표준화된 프롬프트를 넣어놓고, 작업자들은 공통적인 Rule, Prompt, Workflow를 기반으로 작업합니다. .ai의 rules와 commands는 프로젝트 초기화 시, 또는 변경 사항이 생기면 .cursor, .agent, .claude와 동기화되어 Cursor, Claude Code, Antrigravity, Gemini CLI를 지원합니다.
.ai/ # AI 협업 전용 디렉토리
├── rules/ # Grounding 규칙
│ ├── base.md # 매 요청 마다 컨텍스트에 포함되는 기본적인 규칙 (always)
│ ├── react.md # React 관련 규칙 (always)
│ ├── typescript.md # TypeScript 관련 규칙 (always)
│ ├── ... # always/manual 구분해서 rule 추가 필요
│
├── commands/ # Commands 모음
│ ├── task:new.md # 사용자가 작성한 기본적인 계획 00-plan.md를 기반으로 작업 계획 생성
│ ├── task:start.md # task:new 명령어로 생성된 10-task.md를 기반으로 실제 작업 진행
│ └── task:review.md # 작업 변경 사항을 리뷰
│
├── tasks/ # 작업 단위 (Research + Plan + Implement)
│ ├── PILOT-001-작업-설명/ # pnpm task:new 명령어로 생성
│ │ ├── 00-plan.md # pnpm task:new 명령어로 생성 후 사용자가 작업 계획을 세움 (Research)
│ │ ├── 10-task.md # task:new commands로 AI의 리뷰, 보완, 태스크 목록 생성 (Plan)
│ │ └── 20-result.md # task:start commands로 AI의 실제 작업 진행 후 결과 (Implement)
│ └── ...
│
└── templates/ # 스크립트 및 프롬프팅에서 재사용 가능한 템플릿 모음
├── ai:complex.md # 복잡도가 높은 작업
├── ai:medium.md # 중간 복잡도의 작업
├── ai:result.md # 작업 결과 문서
├── ai:simple.md # 복잡도가 낮은 작업
├── bugfix-task.md # 버그 수정 작업
├── chore-task.md # 유지보수 작업
├── feature-task.md # 기능 추가 작업
└── refactor-task.md # 코드 리팩토링 작업Grounding Context
그라운딩 컨텍스트는 팀이 합의하고 버전 관리되는 Agent가 동작할 기반 컨텍스트 입니다. Rule, AI에게 전달할 입력 프롬프트 템플릿, 출력 템플릿이 여기에 해당합니다.
Rules
.ai/rules/ 디렉토리의 규칙 파일들은 에이전트가 모든 작업에서 참조하는 계약서 역할을 합니다. alwaysApply: true 설정으로 모든 요청에 자동 적용됩니다. 개발자가 어떤 프롬프트를 작성하든 에이전트는 이 규칙을 따릅니다. 그리고 프로젝트마다 팀원간의 협의를 통해 필수 Rule을 정해서 강제하고 버전 관리합니다. 예시 프로젝트의 기본적인 Grounding Rules는 아래와 같습니다.
- base.md: 네이밍 컨벤션, Fractal Architecture, 의존성 규칙
- react.md: 컴포넌트 설계 원칙, React Query 아키텍처, 성능 최적화 패턴
- typescript.md: 타입 안전성 규칙, interface vs type 사용 기준
Templates
.ai/templates/ 디렉토리의 템플릿은 Agent가 생성하거나 Agent에게 전달할 문서(프롬프트)의 구조, 포맷을 표준화합니다. 누가 작업하든 해당 구조에 맞게 프롬프팅이 가능합니다.
- 복잡도별 템플릿: ai:simple.md, ai:medium.md, ai:complex.md
- 작업 타입별 템플릿: feature-task.md, bugfix-task.md, refactor-task.md
- 결과 문서 템플릿: ai:result.md
.ai/commands/프롬프팅 템플릿
Workflow
.ai/commands/ 디렉토리의 명령어들은 개인 프롬프트를 대체하는 표준화된 워크플로우입니다. 누가 실행하든 동일한 분석 프로세스, 동일한 출력 형식, 동일한 품질 기준이 적용됩니다. 멀티턴을 수행하거나 코드 베이스 전체를 탐색하며 컨텍스트를 추가할 여지를 줄입니다. 각 태스크 별로 생성된 문서는 다음 프롬프트의 기초 자료가 되며, 각 작업을 수행한 후에는 컨텍스트를 새로 열어서 이전 프롬프트 자료를 기반으로 작업하는 것이 권장됩니다.
/task:new: Plan 문서 분석 → 전문가 관점 개선 → 작업 목록 생성/task:start: 프로젝트 환경 분석 → 복잡도 재판단 → 단계별 실행/task:review: Red Team 관점의 보안/성능/UX/품질 검증
표준화된 워크플로우의 흐름
기본적으로 Research -> Plan -> Implement의 흐름을 가지며, 각 단계마다 사람(팀원, 혹은 팀 전체)의 개입으로 리뷰를 진행합니다.
pnpm task:new → 00-plan.md → /task:new → 10-task.md → /task:start → 20-result.md
(Setup) (Research) (Plan) (Review) (Implement) (Verify)
↓ ↓ ↓ ↓ ↓ ↓
스크립트로 사람이 AI가 사람이 AI가 사람/AI가
템플릿 생성 계획 작성 태스크 생성 검토/승인 코드 작성 리뷰- Setup: pnpm task:new로 작업 디렉토리와 00-plan.md 템플릿 생성
- Research: 사람이 00-plan.md에 작업 목표, 기술 스택, 참조 파일 작성 (생성된 결과물을 Draft PR로 Peer 검토 권장)
- Plan: /task:new 명령어로 AI가 전문가 관점에서 분석, 10-task.md 생성
- Review: 사람이 AI가 생성한 작업 목록 검토 및 승인
- Implement: /task:start 명령어로 AI가 실제 코드 작성, 20-result.md 생성
- Verify: 사람이 결과물 리뷰, /task:review로 Red Team 검증
도입 시 고려사항
- 초기 셋업 비용: Rules, Templates, Commands를 설계하고 합의하는 데 시간이 필요합니다. 처음부터 완벽한 체계를 만들려 하기보다, 공통된 Grounding Context를 만드는 것부터 시작하고 PR Template을 활용해 지속적인 피드백을 받으며 점진적으로 개선해야 합니다.
- 워크플로우 우회 방지: 표준화된 워크플로우가 있어도 개인이 이를 무시하고 직접 프롬프팅하는 상황이 발생할 수 있습니다. 몇 가지 장치를 두거나 명확한 규칙이 필요합니다.
- PR 필수 조건:
.ai/tasks/디렉토리에 해당 작업의 00-plan.md, 10-task.md, 20-result.md가 없으면 PR을 머지할 수 없도록 설정 - 코드 리뷰 체크리스트: "표준 워크플로우를 따랐는가?"를 리뷰 항목에 포함
- 예외 프로세스 명문화: 긴급 핫픽스 등 워크플로우를 생략해야 하는 경우의 기준과 사후 문서화 절차를 미리 정의
- PR 필수 조건:
PR Feedback 예시:
## workflow 이외의 작업 사항이 있었다면 작성해주세요. (워크플로우 개선 목적)
-
-
## 20-result.md에서 제안한 기술 인사이트 외에 제안할 내용이 있으면 작성해주세요.
-
-
## 프로세스별 개선 사항 제안 (Optional)
1. pnpm task:new
2. `/task:new`
3. `/task:start`
4. `/task:review`
5. 기타결론
에이전틱 코딩은 개발 생산성을 획기적으로 높여주지만, 팀 환경에서는 표준화 없이 도입할 경우 오히려 혼란을 가중시킵니다. AI의 비결정성, 멀티 턴 성능 저하, Prompt Drift와 Cascading은 개인이 해결할 수 없는 문제입니다. 라쿠텐처럼 79%의 리드타임 단축을 달성하려면, 효율성만큼이나 일관성을 확보하는 체계가 필요합니다.
이 글에서 제안하는 핵심은 세 가지입니다.
- Grounding Context: 에이전트가 참조하는 규칙과 템플릿을 팀 전체가 공유합니다. 개인의 프롬프트 차이와 무관하게 동일한 컨벤션, 아키텍처 패턴, 품질 기준이 적용됩니다.
- 단계별 Human Checkpoint: Agent Loop를 의도적으로 끊고 사람이 검증합니다. Research → Plan → Implement → Verify의 각 단계에서 컨텍스트를 정리하고 승인해야 다음으로 진행합니다. 멀티 턴 성능 저하와 Cascading을 방지하는 장치입니다.
- 표준화된 워크플로우: /task:new, /task:start, /task:review 같은 명령어로 누가 실행하든 동일한 프로세스가 적용됩니다. 개인 프롬프트를 팀 공유 워크플로우로 대체합니다.