팀 기준을 실행 가능한 인프라로 — AI 코딩 어시스턴트 시대의 암묵지 문제
출처: Rahul Garg, “Encoding Team Standards”, martinfowler.com, 2026년 3월 31일
시리즈: Patterns for Reducing Friction in AI-Assisted Development
저자: Rahul Garg — Thoughtworks 수석 엔지니어 (인도 구루가온), DDD·클린 아키텍처 전문가
정리 일자: 2026년 4월 2일
관련글
The quality of what AI coding assistants produce depends on how well the prompter articulates team standards. @techygarg
proposes treating such instructions as infrastructure: versioned, reviewed, and shared artifacts.
들어가며 — 왜 지금 이 문제인가
AI 코딩 어시스턴트가 개발 현장에 본격적으로 침투한 지 2~3년이 지났다. GitHub Copilot, Cursor, Claude Code 같은 도구들은 코드 생성 속도를 극적으로 높였고, 많은 팀이 이 속도를 일상적인 작업 흐름에 통합하기 시작했다. 그러나 초기의 흥분이 가라앉고 나서 공통적으로 나타나는 문제가 하나 있다. 같은 팀, 같은 코드베이스, 같은 AI 도구를 사용하는데도 시니어 개발자가 생성한 코드와 주니어 개발자가 생성한 코드의 품질 차이가 여전히 뚜렷하다는 것이다.
Thoughtworks의 수석 엔지니어 Rahul Garg는 이 문제를 정면으로 다룬 글 “Encoding Team Standards” 를 2026년 3월 31일 Martin Fowler 블로그에 발표했다. 이 글은 단순히 “프롬프트를 잘 쓰는 방법”을 다루지 않는다. 그보다 훨씬 근본적인 질문을 던진다. 팀의 판단력, 즉 수십 년의 코드 리뷰와 장애 대응과 아키텍처 논의를 통해 축적된 그 암묵적 지식을, 어떻게 하면 AI가 모든 개발자를 위해 일관되게 실행할 수 있는 형태로 만들 수 있는가.
이 문서는 해당 아티클의 핵심 논지를 상세히 풀어내고, 한국 개발 조직의 맥락에서 어떤 함의를 갖는지 분석한다.
1. 문제의 출발점 — 암묵지(Tacit Knowledge)의 취약성
시니어 엔지니어의 뇌 속에 있는 것들
Garg는 이 글을 한 장면으로 시작한다. 경험 많은 시니어 엔지니어가 풀 리퀘스트를 거절할 때, 그녀는 체크리스트를 꺼내 보지 않는다. 거의 즉각적으로 “에러 처리가 불완전하다”, “추상화가 지나치게 이르다”, “네이밍이 팀 컨벤션을 따르지 않는다”고 인식한다.
이 인식은 직관이다. 그러나 이 직관은 하늘에서 뚝 떨어진 것이 아니라, 수년간의 코드 리뷰, 프로덕션 장애 대응, 아키텍처 토론을 통해 형성된 고도로 압축된 경험의 결정체다. 그리고 이 직관은 그녀가 AI에게 코드를 생성하도록 지시할 때도 고스란히 작동한다. AI에게 새로운 서비스를 만들어달라고 할 때, 그녀는 본능적으로 이렇게 지정한다.
- “우리의 함수형 스타일을 따를 것”
- “기존 에러 핸들링 미들웨어를 사용할 것”
- “
lib/services/에 배치할 것” - “타입을 명시적으로 선언할 것”
- “
console.log대신 우리 팀의 로깅 유틸리티를 쓸 것”
이런 지시들은 그녀의 머릿속에서 무의식적으로 흘러나온다. 그녀는 그것들이 얼마나 정밀하게 구성되어 있는지조차 의식하지 못한다.
주니어 개발자가 마주하는 현실
반면, 경험이 부족한 개발자는 같은 상황에서 AI에게 이렇게 묻는다.
- “알림 서비스 만들어줘”
- “이 코드 좀 정리해줘”
- “이거 보안 문제 없어?”
동일한 코드베이스, 동일한 AI, 그러나 완전히 다른 품질 기준. AI는 프롬프트가 요청하는 만큼만 반응한다. 맥락이 빠지면 결과도 빠진다. 이것은 주니어 개발자의 잘못이 아니다. 그들은 아직 그 직관을 갖추지 못했을 뿐이다.
문제의 진짜 비용
이 불일치는 조용히, 그러나 지속적으로 팀에 손상을 입힌다.
첫째, AI가 생성한 코드가 팀 컨벤션을 따르는지 여부가 누가 프롬프트를 입력했느냐에 따라 달라진다. 어떤 개발자의 코드는 처음부터 팀 스타일에 맞게 나오고, 다른 개발자의 코드는 대폭 수정이 필요하다. 기술 부채가 불균등하게 쌓인다.
둘째, 리팩토링의 품질이 요청자에 따라 들쭉날쭉해진다. 시니어가 리팩토링을 요청하면 “공개 인터페이스를 보존하고 점진적으로 개선”하는 결과가 나오지만, 주니어가 요청하면 지나치게 추상화되거나 오히려 복잡성이 증가한 코드가 나온다.
셋째, 보안 체크의 범위가 프레이밍에 따라 달라진다. 시니어는 SQL 인젝션, 엔드포인트별 인가 체크, 시크릿 하드코딩 여부를 모두 지정하지만, 주니어는 “보안 문제 없어?”라고만 묻는다. AI는 질문된 것만 확인한다.
2. 이것은 기술 문제가 아니라 시스템 문제다
흔한 오진: 스킬 문제로 프레이밍
이 상황을 접한 많은 팀이 내리는 첫 번째 진단은 “주니어를 교육해야 한다”는 것이다. 더 좋은 문서를 작성하고, 페어 프로그래밍을 늘리고, AI 프롬프팅 워크숍을 열자. 이 접근들이 도움이 되지 않는 것은 아니다. 그러나 느리고 확장되지 않는다.
왜냐하면, 지식은 팀 내에 이미 존재하기 때문이다. 단지 그것이 일관되게 배포될 수 있는 수단이 없을 뿐이다. 문제는 지식의 부재가 아니라, 지식의 배분 메커니즘의 부재다.
Garg의 핵심 테제
Garg는 이것을 시스템 문제라고 명명하고, 시스템적 해법을 요구한다. 그것은 무엇인가. 시니어 엔지니어가 본능적으로 적용하는 것들을, 기억해야 할 조언이 아니라 실행되는 인스트럭션(instruction) 으로 만들어서, 모든 개발자가 AI와 상호작용할 때 자동으로 팀의 판단이 작동하게 하는 것이다.
이 시리즈에서의 위치
Garg는 이 글이 속한 시리즈(Patterns for Reducing Friction in AI-Assisted Development)의 다른 글들과 이 글의 차이를 명확히 구분한다.
- Knowledge Priming (2026년 2월 24일): AI에게 프로젝트 컨벤션을 알려주는 것 — AI가 무엇을 아는지 다룬다.
- Design-First Collaboration (2026년 3월 3일): 구현 전 설계 정렬을 먼저 하는 것 — 어떻게 협업하는지 다룬다.
- Context Anchoring: 정렬된 맥락을 세션 간에 지속시키는 것 — 정렬을 어떻게 유지하는지 다룬다.
- Encoding Team Standards (이 글): AI가 팀의 판단을 일관되게 적용하도록 만드는 것.
앞의 세 글이 “AI가 무엇을 알아야 하는가”를 다룬다면, 이 글은 “AI가 그 지식으로 무엇을 해야 하는가”를 다룬다. AI의 지식이 아니라 AI의 행동 규범이다.
3. 실행 가능한 거버넌스(Executable Governance) — 핵심 개념
문서화의 오랜 딜레마
팀 기준을 문서화하려는 시도는 새로운 것이 아니다. 위키에 체크리스트를 만들고, 컨벤션 문서를 작성하고, 온보딩 가이드를 정비한다. 그런데 Garg가 지적하듯, 이런 노력 대부분은 조용히 실패한다. 시간 압박 속에서 누군가 그것을 읽고, 기억하고, 적용해야 하는데, 그 세 단계 중 하나라도 빠지면 문서는 무용지물이 된다.
AI 인스트럭션이 바꾸는 것
AI 인스트럭션은 이 동학을 근본적으로 바꾼다. 팀 기준이 AI 인스트럭션으로 인코딩되면, 그것을 기억하고 적용하는 주체가 사람이 아니라 인프라가 된다. 개발자가 해당 인스트럭션을 사용해 코드를 생성하거나 보안 체크를 실행하면, 팀 기준은 워크플로우의 부산물로 자동 적용된다. 별도의 규율이 필요하지 않다. 거버넌스가 곧 워크플로우가 된다.
두 개의 이동(Two Moves)
Garg는 이 전환을 두 개의 이동으로 설명한다.
첫 번째 이동: 암묵적인 것을 명시적으로
이것은 익숙한 이동이다. 시니어가 본능적으로 아는 것을 글로 쓰는 것. 그러나 결정적인 차이가 있다. 목표 형식이 위키 페이지나 체크리스트가 아니라, AI가 실행할 수 있는 구조화된 인스트럭션 세트라는 것이다. 이 과정에서 한 번도 명시된 적 없었던 가정들이 수면 위로 떠오른다. “보안 이슈가 크리티컬한 것”과 “단순히 중요한 것”을 구분하는 정확한 기준은 무엇인가? 시니어에게는 직관이지만, AI를 위해서는 정밀하게 정의되어야 한다.
두 번째 이동: 문서화에서 실행으로
이것이 진짜 중요한 이동이다. 린팅 규칙은 버전 관리되는 설정 파일이다. 개인 취향이 아니다. CI/CD 파이프라인은 실행 가능한 정의다. 배포 절차를 설명하는 위키 페이지가 아니다. AI 인스트럭션은 같은 범주에 속한다. 실행되는 설정이지, 참조하는 문서가 아니다. 이 인스트럭션들이 레포지토리 안에 살게 되면, 풀 리퀘스트를 통해 리뷰되고, 기본적으로 모든 사람에게 공유된다. 개발자는 팀의 모든 기준을 머릿속에 담고 있을 필요가 없다. 인스트럭션을 호출하면 된다. 그러면 개발자가 기억했기 때문이 아니라, 인프라가 인코딩했기 때문에 팀의 판단이 일관되게 적용된다.
4. 실행 가능한 인스트럭션의 해부학
4개 요소의 구조
Garg는 잘 설계된 실행 가능한 인스트럭션이 목적에 관계없이 공통된 해부학적 구조를 갖는다고 설명한다.
① 역할 정의 (Role Definition)
AI에게 페르소나를 부여하는 것이 아니다. 역할이 전문성 수준과 관점을 설정한다. “역할: 팀의 아키텍처 패턴을 따르는 새로운 서비스를 구현하는 시니어 엔지니어”는 일반적인 프롬프트와는 전혀 다른 기준선을 만든다. 역할은 이후의 모든 인스트럭션이 적용되는 렌즈다.
② 컨텍스트 요구사항 (Context Requirements)
인스트럭션이 작동하기 전에 필요한 것들을 명시한다. 관련 코드, 프로젝트의 아키텍처 컨텍스트에 대한 접근, 적용 가능한 제약 조건들. 이것은 개발자가 필요한 것을 제공하기를 바라는 것이 아니라, 의존성을 명시적으로 만드는 것이다.
③ 범주화된 기준 (Categorized Standards)
개별 항목보다 범주가 더 중요하다. 왜냐하면 범주가 팀의 단순한 지식이 아니라 판단을 인코딩하기 때문이다. 어떤 것이 가장 중요한지를 AI에게, 그리고 AI를 통해 개발자에게 말한다.
- 생성 인스트럭션의 경우: 아키텍처 준수(반드시 따를 것) / 컨벤션 준수(따라야 함) / 스타일 선호도(있으면 좋음)
- 보안 인스트럭션의 경우: 심각한 취약점(블로커) / 중요한 우려사항(머지 전 처리 필수) / 권고사항(추적 및 평가)
- 리뷰 인스트럭션의 경우: 치명적 문제(breaking issues) / 중요한 발견 / 제안
④ 출력 형식 (Output Format)
요약, 범주화된 발견사항, 명확한 다음 단계가 있는 구조화된 응답. 이 형식은 인스트럭션의 출력이 실행 간, 개발자 간에 비교 가능하게 만든다. 여러 사람이 동일한 인스트럭션을 정기적으로 사용할 때 이 속성이 중요해진다.
적용 영역별 인스트럭션 예시
이 구조는 AI와의 상호작용 전 영역에 걸쳐 적용된다.
| 영역 | 인코딩하는 것 | 핵심 목적 |
|---|---|---|
| 생성(Generation) | 팀이 새로운 코드를 만드는 방식 (아키텍처 패턴, 네이밍, 에러 핸들링, 테스팅 기대치) | 처음부터 팀 컨벤션에 맞는 출력 생성 |
| 리팩토링(Refactoring) | 팀이 기존 코드를 개선하는 방식 (공개 계약 보존, 과도한 추상화 방지, 점진적 변경 제안) | 리팩토링이 팀 규범에서 벗어나지 않도록 유지 |
| 보안(Security) | 팀의 위협 모델 (무엇을 체크하고 어떻게 심각도를 등급화하는지) | 일반적 체크리스트가 아닌 팀 특화 보안 검증 |
| 리뷰(Review) | 팀이 리뷰에서 확인하는 것 (아키텍처 정렬, 에러 핸들링, 타입 안전성, 컨벤션) | 일관된 심각도 구조를 가진 팀 품질 게이트 적용 |
한 가지 중요한 원칙이 있다. 인스트럭션은 작고 단일 목적으로 유지해야 한다. 작은 인스트럭션은 포커스를 유지하고, 유지보수가 용이하며, 유연하게 조합된다. 모든 것을 하나의 거대한 인스트럭션에 넣으려는 유혹을 피해야 한다.
5. 암묵지를 꺼내는 과정 — 인터뷰와 추출
가장 흥미로운 부분
Garg는 이 인스트럭션들을 만드는 가장 흥미로운 부분이 추출 과정 자체라고 말한다. 이것은 팀의 시니어 엔지니어들과의 구조화된 인터뷰다. 개발 워크플로우 전반에 걸쳐 날카로운 질문들을 중심으로 구성된다.
- 어떤 아키텍처 결정은 개인의 판단에 맡겨서는 안 되는가?
- 생성된 코드에서 가장 자주 수정되는 컨벤션은 무엇인가?
- 어떤 보안 체크가 본능적으로 적용되는가?
- 리뷰에서 즉각적인 거절을 유발하는 것은 무엇인가?
- 깔끔한 리팩토링과 과도하게 엔지니어링된 것을 구분하는 것은 무엇인가?
답변에서 인스트럭션으로의 매핑
이 인터뷰의 답변들은 직접 인스트럭션 구조에 매핑된다.
- 협상 불가능한 아키텍처 패턴 → 생성 제약 조건
- 자주 수정되는 컨벤션 → 컨벤션 체크
- 보안 직관 → 위협 모델 항목
- 리뷰 거절 → 크리티컬 체크
- 반복적 실수 → 플래그를 세울 안티패턴
인터뷰가 본질적으로 인스트럭션을 작성하는 것이다. 창작 행위가 곧 암묵적 지식을 명시적이고 우선순위가 부여된 체크의 형태로 조직화하는 행위다.
예상치 못한 부가 가치
Garg는 이 과정에 결과물 인스트럭션을 넘어서는 가치가 있음을 발견했다고 한다. 한 프로젝트에서 추출 대화를 진행하던 중, 두 명의 시니어 엔지니어가 “크리티컬한” 보안 우려와 “중요한” 것의 기준에 대해 조용히 다른 기준을 갖고 있다는 것이 드러났다. 그 불일치는 각자가 다른 풀 리퀘스트를 리뷰했기 때문에 한 번도 표면화된 적이 없었다. 공유 인스트럭션을 작성하는 행위가 그 구분을 명시적으로 만들도록 강제했다.
그리고 경험이 부족한 개발자가 그 결과 인스트럭션을 사용하기 시작하자 효과는 즉각적이었다. 첫 번째 리뷰에서 그는 새로 추가된 엔드포인트에서 누락된 인가 체크를 플래그로 표시했다. 이전에는 시니어가 우연히 그 리뷰어일 경우에만 잡힐 수 있는 문제였다. 인스트럭션이 그 개발자를 더 경험 있게 만들지 않았다. 그의 경험 부족을 덜 비용스럽게 만들었다.
6. 워크플로우와의 통합 지점
여러 지점에서 작동하는 인스트럭션
이 인스트럭션들은 단일 목적 도구가 아니다. 개발 워크플로우의 서로 다른 시점에 적용되며, 적용 시점이 그 가치를 형성한다.
생성 시점 (Generation-time)
개발자가 AI에게 새로운 서비스를 만들거나, 피처를 구현하거나, 테스트를 작성하도록 요청할 때, 생성 인스트럭션은 출력이 처음부터 팀 컨벤션을 따르도록 보장한다. 여기가 인코딩된 기준이 가장 큰 레버리지를 갖는 곳이다. 사후에 잡는 것이 아니라 사전에 불일치를 방지한다.
개발 중 (During Development)
리팩토링 인스트럭션은 개선이 팀 규범에 정렬되도록 유지하고, 보안 인스트럭션은 일반적인 체크리스트가 아닌 팀의 위협 모델을 적용한다. 기준이 개발 과정 전반에 걸쳐 존재하며, 마지막에 덧붙여지는 것이 아니다.
리뷰 시점 (Review-time)
개발자가 작업을 완료하면(AI 생성이든 수동으로 쓴 것이든), 리뷰 인스트럭션이 팀의 품질 게이트를 적용한다. 그러나 리뷰 시점은 불일치를 잡는 마지막 기회다. 워크플로우에서 기준이 더 일찍 적용될수록, 리뷰에 도달하는 문제가 줄어든다.
선택적으로 CI에서 (Optionally in CI)
일부 팀은 이 인스트럭션들을 자동화된 일관성 체크로서 CI 파이프라인으로 확장한다. CI 수준 인스트럭션은 파이프라인을 늦추지 않을 만큼 빠르고, 노이즈가 많은 거짓 양성을 피할 만큼 예측 가능하며, 다른 CI 게이트처럼 동일한 규율로 유지되어야 한다.
7. 공유 인프라로서의 기준
개인 도구와 팀 인프라의 차이
개인 컴퓨터에 있는 프롬프트는 개인 생산성 해킹이다. 팀 레포지토리에 있는 동일한 프롬프트는 인프라다. 이 구분은 개인 선호와 팀 관행의 차이다.
레포지토리에 살게 되면, 그것은 버전 관리된 아티팩트의 속성을 상속한다. 변경 사항이 추적되고, 기준이 집단적으로 소유되며, 모든 개발자가 동일한 버전으로 작업한다. 도구마다 다르게 구현된다(커스텀 명령어, 스킬, 규칙 파일, 프로젝트 인스트럭션). 그러나 기본 속성은 동일하다. AI가 일관되게 실행하는 버전 관리되고 공유된 아티팩트.
팀이 함께 기준을 개선하는 메커니즘
이것이 팀이 함께 기준을 개선하는 방법이다. 생성 인스트럭션이 팀의 새로운 에러 핸들링 패턴을 지정하지 않는다는 것을 발견한 개발자가 그것을 업데이트하기 위한 PR을 제출한다. 보안 인시던트가 보안 인스트럭션의 격차를 드러내면, 수정이 다른 인프라 변경처럼 리뷰되고 머지되는 커밋이 된다.
기준들은 시니어가 내려준 정적 규칙이 아니다. 팀 전체가 유지하고, 실전을 통해 날카로워지며, 코드에 이미 사용하는 것과 같은 풀 리퀘스트 워크플로우를 통해 개선되는 살아있는 아티팩트다.
문서 묘지가 되지 않으려면
이 인스트럭션들이 열정적으로 만들어지고 몇 달 안에 버려지는 또 다른 문서 묘지가 될 실제 위험이 있다. 레포지토리 배치와 풀 리퀘스트 리뷰가 이것을 완화한다. 레포에 있는 인스트럭션은 가시적이다. 차이(diff)에 나타난다. 풀 리퀘스트 템플릿에서 참조될 수 있다. 실제 관행에서 벗어나면, 그 이탈은 낡은 테스트가 가시적인 것처럼 가시화된다. 누군가 감사하기 때문이 아니라, 일반적인 작업 과정에서 만나게 되기 때문에. 아티팩트가 워크플로우에 가까울수록, 유지될 가능성이 높다.
이 원칙은 이 시리즈의 다른 글에서 Garg가 설명한 “컨텍스트를 습관이 아니라 인프라로 다루라”는 핵심 이동의 연장이다. 프라이밍 문서가 AI에게 프로젝트가 어떻게 작동하는지 알려준다면, 실행 가능한 인스트럭션은 AI에게 팀이 어떻게 작동하는지 알려준다.
8. 캘리브레이션 — 언제 시작하고 어디까지 가야 하는가
이 접근이 가장 가치 있는 때
이 접근은 팀이 대화만으로는 일관성을 유지할 수 없을 만큼 커졌을 때 가장 가치 있다. 유용한 경험법칙이 있다. AI 지원 출력의 품질이 누가 프롬프팅하느냐에 따라 가시적으로 다르거나, 효과적으로 프롬프팅하는 방법을 아는 소수의 사람들을 통해 생성 및 리뷰 작업이 라우팅되고 있다면, 그 불일치가 신호다. 5명 팀은 이것이 필요하지 않을 수 있다. 15명 팀은 거의 확실히 필요하다.
비용은 실재한다
좋은 인스트럭션을 만드는 것은 노력이 필요하다. 추출 인터뷰, 초안 작성, 반복. 지나치게 규정적인 인스트럭션은 취약해지며 엣지 케이스에서 거짓 양성을 생성하거나 접근 방식의 정당한 변형에 저항한다. 기준이 진화함에 따른 유지보수 부담이 있다. 그리고 과도한 엔지니어링의 위험이 있다. AI와의 모든 상호작용에 전용 인스트럭션이 필요한 것은 아니다.
시작 지점
Garg의 경험에서 올바른 시작 지점은 하나의 인스트럭션이다. 생성 또는 리뷰 인스트럭션이 보통 가장 높은 가치의 선택이다. 가장 일반적인 워크플로우, 가장 넓은 품질 격차, 가장 가시적인 불일치를 다루기 때문이다. 추가 인스트럭션은 도입이 선행된 후에 따라와야 하며, 도입보다 앞서 가서는 안 된다.
9. 결론 — 사람의 머릿속에서 실행 가능한 인프라로
핵심 이동
이것은 본질적으로 사람의 머릿속에 사는 판단에서 공유 인프라로 실행되는 판단으로의 이동이다. 시니어 엔지니어의 직관(그녀가 체크하는 패턴, 그녀가 강제하는 컨벤션, 그녀가 플래그를 세우는 리스크)은 개인적이고 확장 불가능한 상태로 남아 있을 필요가 없다. 그것들은 추출되어 버전 관리된 인스트럭션으로 인코딩되고, 모든 개발자와 AI와의 모든 상호작용에 걸쳐 일관되게 적용될 수 있다.
메커니즘은 새로운 것이 아니다
이 메커니즘은 새롭지 않다. 팀들은 이미 린팅 규칙, CI 파이프라인, 인프라 코드로 이것을 한다. AI로 변하는 것은 인코딩될 수 있는 것의 범위다. 린팅은 구문과 스타일을 잡는다. 실행 가능한 팀 기준은 아키텍처 판단, 보안 인식, 리팩토링 철학, 리뷰 엄격성을 인코딩할 수 있다. 이전에는 페어링, 멘토링, 수년간의 공유 경험을 통해서만 전달되던 종류의 지식을.
팀 소유권의 의미
이 기준들의 가장 흥미로운 속성은 팀 소유라는 것이다. 레포지토리에 산다. 풀 리퀘스트를 통해 진화한다. 실전이 격차를 드러낼 때 개선된다. 무언가를 놓친 모든 인스트럭션은 업데이트를 기다리는 인스트럭션이며, 그 업데이트는 팀 전체가 리뷰하는 커밋이다. 기준은 팀 지식의 출력일 뿐 아니라, 팀 지식이 성문화되고 공유되며 정제되는 메커니즘이다.
10. 한국 개발 조직에 주는 함의
시니어 병목 현상은 보편적 문제다
Garg가 묘사하는 시니어 병목 현상은 한국 소프트웨어 조직에도 매우 익숙한 패턴이다. 많은 팀에서 코드 리뷰, 아키텍처 결정, 복잡한 AI 프롬프팅이 특정 시니어에게 집중된다. AI 도구 도입이 이 병목을 해소하기보다 오히려 강화하는 역설이 발생할 수 있다. AI를 잘 활용하는 방법을 아는 사람이 소수이기 때문이다.
AI 도입의 두 가지 경로
한국 기업들이 AI 코딩 어시스턴트를 도입하는 방식은 대체로 두 가지로 나뉜다. 첫 번째는 라이선스를 구매하고 개발자들에게 “사용해보라”고 하는 것이다. 두 번째는 AI 도구를 기존 개발 문화와 프로세스에 통합하려는 것이다. Garg의 프레임워크는 두 번째 경로를 체계화하는 구체적인 방법을 제시한다.
암묵지 유출의 한국적 맥락
한국 IT 업계에서는 개발자 이직률이 높은 편이다. Garg가 지적하듯, 암묵지는 사람이 떠날 때 함께 떠난다. AI 인스트럭션을 통한 지식의 코드화는 이직으로 인한 지식 손실을 완화하는 인프라적 접근이기도 하다.
스타트업과 대기업의 차이
Garg의 캘리브레이션 기준(5명 팀은 불필요, 15명 팀은 필요)은 한국 스타트업과 대기업에 다르게 적용된다. 성장 초기 스타트업은 이것보다 민첩성을 우선할 수 있지만, 팀이 일정 규모 이상으로 성장하는 시점을 미리 예측하고 준비하는 것이 현명하다. 대기업의 경우, 여러 팀 간 AI 출력 품질의 불일치가 이미 가시화되어 있다면 즉시 시작하는 것이 적절하다.
11. 실천 로드맵 — 어디서부터 시작할 것인가
1단계: 불일치 신호 포착
먼저 현재 팀에서 AI 지원 출력의 품질이 프롬프터에 따라 달라지는지 확인한다. 코드 리뷰에서 반복적으로 지적되는 패턴이 있는가? 특정 개발자가 AI 생성 코드를 거의 수정 없이 사용하는 반면, 다른 개발자는 대폭 수정하는가? 이것이 시작 신호다.
2단계: 시니어 인터뷰 진행
팀의 시니어 엔지니어들을 대상으로 구조화된 인터뷰를 진행한다. Garg가 제시한 질문들이 좋은 출발점이다. 이 과정에서 서로 다른 시니어들이 동일한 사안에 대해 다른 기준을 가지고 있다는 것을 발견할 수 있다. 이것 자체가 가치 있는 발견이다.
3단계: 첫 번째 인스트럭션 작성
가장 높은 임팩트를 줄 것으로 예상되는 하나의 인스트럭션부터 시작한다. 코드 리뷰 인스트럭션이나 생성 인스트럭션이 일반적으로 좋은 선택이다. 4개 요소(역할 정의, 컨텍스트 요구사항, 범주화된 기준, 출력 형식)를 모두 포함하도록 구성한다.
4단계: 레포지토리에 통합
인스트럭션을 레포지토리에 배치하고, PR 워크플로우를 통해 팀 리뷰를 거친다. 팀이 동의하는 형식으로 버전 관리한다. 다양한 AI 도구(Cursor, Claude Code, GitHub Copilot 등)에서 어떻게 참조할지 팀 차원에서 합의한다.
5단계: 채택 후 확장
첫 번째 인스트럭션이 실제로 사용되고 그 효과가 확인된 후에, 다른 영역(리팩토링, 보안 등)으로 확장한다. 채택이 확장보다 선행되어야 한다.
부록: 관련 시리즈 아티클 목록
| 발행일 | 제목 | 핵심 개념 |
|---|---|---|
| 2026년 2월 24일 | Knowledge Priming | AI에게 프로젝트 컨벤션 사전 제공 |
| 2026년 3월 3일 | Design-First Collaboration | 구현 전 설계 정렬 우선 |
| 2026년 3월 (추정) | Context Anchoring | 세션 간 컨텍스트 지속성 확보 |
| 2026년 3월 31일 | Encoding Team Standards | 팀 기준을 실행 가능한 인프라로 |
핵심 문장 하나로 요약
“AI가 프롬프터에 따라 다르게 행동하는 것은 기술 문제가 아니라 시스템 문제다. 시니어의 판단을 버전 관리되고 리뷰된 AI 인스트럭션으로 인코딩함으로써, 팀은 누가 키보드에 앉아 있든 일관된 품질을 얻을 수 있다.”
정리: AI & 개발 조직 연구, 2026년 4월 2일
원문: https://martinfowler.com/articles/reduce-friction-ai/encoding-team-standards.html