10부 · AICBOK I

The Standard for AI Collective Coding

본 장의 성격과 용도.

AICBOK(AI Collective Coding Body of Knowledge) 은 PMBOK 같은 전통 개발 방법론의 귀환에 대한 오마주이자, 그 방법론을 AI 집합코딩 맥락으로 번역한 약식 규약집이다. PMBOK을 대체하는 완전한 표준이 아니며, 1~9부의 논의를 팀이 즉시 참조할 수 있는 조항으로 압축한 것이다.

핵심 용도: AI에게 공급하는 표본. 9부 9.4에서 제안한 "팀 매뉴얼 북"을 작성할 때, 이 규약집을 AI에게 컨텍스트로 공급하면 팀의 상황에 맞는 매뉴얼 초안이 생성된다. AICBOK은 사람이 외우는 규정이 아니라 AI가 읽고 팀 매뉴얼로 재단(tailoring)하는 표본이다.

구성:

AICBOK I (10부): 원칙 6개 + 포커스 영역 5개

AICBOK II (11부): 수행 영역 7개 + 재단(Tailoring)

기호 규약:

P.n — 원칙 (Principle)

F.n — 포커스 영역 (Focus Area)

D.n — 수행 영역 (Performance Domain)

→ [N부] — 본문 상호 참조

10부 서문 · AICBOK의 구조와 사용법

왜 AICBOK인가

2부에서 다룬 대로, PMBOK·폭포수·애자일 같은 전통 방법론은 AI 시대에 사라진 것이 아니라 비로소 실행 가능해졌다. AICBOK은 이 귀환에 대한 오마주다. "Body of Knowledge"라는 이름을 빌린 것은 프로젝트 관리의 집단적 지혜가 AI 시대에도 유효하다는 사실을 상징적으로 나타내기 위함이다.

그러나 AICBOK은 PMBOK의 축소판이 아니다. PMBOK이 모든 산업의 프로젝트 관리를 다루는 범용 표준이라면, AICBOK은 AI 에이전트와 사람이 함께 코드를 만드는 상황에만 초점을 맞춘 약식 규약집이다. 범위가 좁은 만큼 조항이 구체적이다.

AICBOK의 실무적 용도

AICBOK의 조항은 외우기 위한 것이 아니다. 두 가지 실무적 용도로 설계됐다.

첫째, 팀 매뉴얼의 표본. 9부 9.4에서 제안한 "팀 매뉴얼 북"을 작성할 때, 이 규약집을 AI에게 컨텍스트로 공급한다. AI는 AICBOK의 조항을 읽고, 팀의 규모·성격·도구 스택에 맞게 재단(tailoring)한 매뉴얼 초안을 생성한다. AICBOK은 AI가 팀 매뉴얼을 생산하기 위한 원재료다.

둘째, 위원회의 판정 기준. 4부의 AI 위원회가 스킬 문서와 역기획서를 검수할 때, AICBOK의 조항이 판정의 근거가 된다. "이 산출물이 P.2(재현 가능성)를 만족하는가?"라는 질문이 위원회의 검수 항목이 된다.

셋째, 다른 방법론과의 조합. AICBOK은 AI 집합코딩의 최소 핵심만 담고 있다. 팀의 방침에 따라, 아래 문헌 중 하나 이상을 참조해 AICBOK을 확장할 수 있다. AI에게 AICBOK과 선택한 방법론을 함께 공급하면, 두 원천이 결합된 팀 매뉴얼이 산출된다.

어느 방법론을 선택하든, AICBOK의 6원칙(P.1~P.6)은 변하지 않는다. 원칙은 고정이고, 수행 영역의 세부 프로세스가 선택한 방법론에 따라 달라진다. 또한 '내 팀만의 매뉴얼/규약'을 만드는 팀장은 실제 이 방법론을 검토하고 선택하기보다는 지난 1장부터 9장을 읽으며 구축한 자신이 무엇을 원하는지 리스트를 AI에게 전달해주면 될 것이다.

조항의 원천

AICBOK의 조항은 다음 세 원천의 교차점에서 도출됐다.

전통 개발 방법론의 원리 — PMBOK, 폭포수(SAGE/Benington), 애자일의 수십 년간 검증된 지혜를 AI 맥락으로 번역.

본서 1~9부의 실무 논의 — 에이전트 운영, 두 장의 문서, 위원회, MAD/간신배 방어 등 AI 집합코딩 특유의 경험.

학술 연구 — MAD², sycophancy³, 자동화의 아이러니⁴ 등 최근 연구.

조항 구성의 4단 형식

각 원칙은 다음 4단 구조로 서술된다.

정의(Definition): 조항이 무엇을 말하는지 한두 문장으로 압축.

원칙 작동 방식(Principle in Action): 실무에서 이 원칙이 어떻게 구현되는지의 구체적 지침.

연결된 영역(Connected Domains): 이 원칙이 영향을 미치는 수행 영역(11부) 및 본문 장.

반례(Anti-pattern): 이 원칙이 무시됐을 때 실제로 나타나는 실패 패턴.

각 포커스 영역은 다음 4단 구조로 서술된다.

목적(Purpose): 이 영역이 전체 생애주기에서 담당하는 역할.

핵심 활동(Key Activities): 영역 안에서 수행되어야 할 구체적 작업 목록.

산출물(Deliverables): 영역을 통과하면 생성되는 문서와 결과물.

체크리스트(Check Results): 영역이 올바르게 수행되었는지를 판정하는 진단 항목.

이 4단 구조는 PMBOK 8판의 “Principle in Action / Connected Performance Domains / Project Impact” 형식⁵을 변형한 것이다.

읽는 법

이 규약집의 1차 독자는 AI다. 팀 매뉴얼을 생성할 때 컨텍스트로 공급되는 표본이기 때문이다. 2차 독자는 사람(팀장·팀원)이다. AI가 생성한 매뉴얼 초안을 검토하고, 조항의 의도를 이해하고, 자기 팀에 맞게 판단을 내리는 주체다.

따라서 각 조항은 명료하게 쓰여 있다. AI가 파싱하기 좋은 구조(정의→작동 방식→연결→반례)를 따르되, 사람이 읽어도 "왜 이 조항이 필요한가"가 즉시 파악되는 수준을 유지한다. 조항이 이해되지 않으면 본문 해당 장을 읽는다. 조항은 본문의 압축이지, 본문의 대체가 아니다.

개발 방법론으로서의 위치

모든 개발 방법론은 한 가지 질문에 답한다. “여러 사람이 동시에 하나의 산출물을 만들 때, 어떻게 해야 품질을 유지하면서 완성할 수 있는가.” 폭포수는 "순서를 지켜라"로, 애자일은 "짧게 반복하라"로, PMBOK은 "10가지를 동시에 관리하라"로 답했다. AICBOK은 이렇게 답한다. “두 장의 문서를 쓰고, 독립된 AI가 검수하고, 사람이 서명하라.” 도구만 다르고 질문은 같다.

다른 방법론이 사람 사이의 조율을 다뤘다면, AICBOK은 사람과 AI 사이의 조율을 다룬다. 이것이 유일한 차이이자 존재 이유다.

제1부 · 원칙(Principles) 6개

개발 방법론의 원칙은 적을수록 강하다. 49개의 프로세스를 외우는 관리자는 환경이 바뀌면 쓸모없어지고, 6개의 원칙을 이해하는 관리자는 환경이 바뀌어도 원칙에서 새 규칙을 도출한다. AICBOK은 AI 집합코딩의 원칙을 6개로 고정한다. 각 원칙은 1~9부 본문의 핵심 논증을 한 조항으로 압축한 것이다.

P.1 · 자연어 우선 원칙 (Natural Language First)

→ 본문 3부 3.7, 3.9 · 본문 4부 4.7

정의

모든 작업 산출물의 1차 형식은 자연어이며, 자연어의 구조적 구현체인 마크다운을 기본 포맷으로 삼는다. 코드·JSON·YAML 등 정형 포맷은 자연어 산출물에서 파생된 2차 산출물로 간주한다.

원칙 작동 방식

스킬 문서, 요구사항 명세, 회의록, 백본 문서는 모두 마크다운(.md)으로 작성한다.

AI 에이전트에게 작업을 지시할 때, 코드 수정의 경우에도 먼저 자연어로 의도를 설명한 뒤 코드 변경을 요청한다.

프로젝트 저장소의 주요 문서는 옵시디안 볼트 형식을 따른다. [[wiki-link]] 문법으로 문서 간 관계를 드러낸다.

팀 내 지식 공유는 데이터베이스·위키 소프트웨어가 아닌 파일 단위 마크다운을 기본으로 한다.

번역 작업 시 원문과 번역문 모두 마크다운으로 유지해, 글로서리 추출과 용어 일관성 검증이 가능하도록 한다.

연결된 영역

수행 영역: D.2 Scope (범위), D.6 Resources (자원)

포커스 영역: F.2 Planning, F.3 Executing

본문: 3부(두 장의 문서), 4부(AI 위원회)

반례 (Anti-pattern)

❌ JSON·YAML로 스킬 문서를 저장해 AI의 토큰 효율과 가독성이 동시에 떨어진다.

❌ 자연어 설명 없이 코드만 AI에게 입력해 AI가 맥락을 추측한다.

❌ 컨플루언스 같은 HTML 기반 위키에 문서를 저장해 AI가 태그를 함께 처리하게 만든다.

❌ 마크다운을 사용하되 헤더 구조를 무시해 문서 간 링크가 깨진다.

P.2 · 재현 가능성 원칙 (Reproducibility Through Skill Docs)

→ 본문 3부 3.2, 3.3

정의

완성된 작업은 반드시 스킬 문서로 역산 기록되어야 한다. 스킬 문서가 없는 작업은 완료되지 않은 것으로 간주된다. 스킬 문서의 유일한 판정 기준은 다른 AI 에이전트가 해당 문서만으로 동일한 결과를 재현할 수 있는가이다.

원칙 작동 방식

작업이 완료된 직후, 작업을 수행한 AI 또는 사람이 스킬 문서를 작성한다. 작업 시작 시점에 작성하지 않는다.

스킬 문서는 6개 구성 요소를 모두 포함한다: ① 작업 개요와 목적, ② 전제 조건, ③ 단계별 절차, ④ 금지 사항(시행착오), ⑤ 판정 기준, ⑥ 변경 이력.

시행착오는 명시적으로 제외되지만, 제외 사유는 금지 사항 섹션에 기록된다.

단계별 절차는 논리적 의존 순서로 재배열된다. 실제 수행 순서가 병렬이었더라도 문서 상에서는 직렬로 정리된다.

스킬 문서는 다른 AI에게 직접 입력 가능한 형태여야 하며, 사람의 개입 없이 재현이 이루어져야 한다.

연결된 영역

수행 영역: D.2 Scope, D.1 Governance

포커스 영역: F.2 Planning, F.5 Closing

본문: 3부, 5부(비숙련자·숙련자·맹신자)

반례

❌ 스킬 문서를 작업 시작 전에 작성해, 실제 시행착오를 예측하지 못한 추상적 문서가 남는다.

❌ 시행착오를 그대로 포함시켜 재현성을 떨어뜨린다.

❌ 금지 사항 섹션을 생략해 다른 팀원이 같은 실수를 반복한다.

❌ 변경 이력이 없어 스킬 문서가 어느 시점의 AI 환경을 전제했는지 알 수 없다.

P.3 · 이중 문서 원칙 (Dual Documentation)

→ 본문 3부 3.4, 3.5, 3.6

정의

모든 작업 산출물은 스킬 문서와 요구사항 명세(역기획서)를 한 쌍으로 갖추어야 한다. 한 문서만 있는 산출물은 검수 대상이 아니며, 위원회에 제출될 수 없다.

원칙 작동 방식

스킬 문서와 역기획서는 동시에 제출된다. 한쪽만 먼저 제출하는 것은 허용되지 않는다.

두 문서는 서로를 검증하는 도구로 작동한다. 스킬 문서의 단계와 역기획서의 요구사항이 1:1로 대응되어야 한다.

역기획서는 구체성 기준을 만족해야 한다. 추상 표현(예: “외부 API와 통신한다”)이 아닌 구체 표현(예: “requests 2.31 라이브러리로 HTTPS GET 요청을 전송한다”)을 사용한다.

역기획서는 결과물에서 역산되며, 사전 작성이 아니다. 이 역산성이 SI 기획의 전통적 사전 명세와 AICBOK 역기획서의 결정적 차이다.

두 문서는 위원회의 이중 검토(P.4)로 교차 검증된다.

연결된 영역

수행 영역: D.2 Scope, D.1 Governance

포커스 영역: F.2 Planning, F.4 Monitoring & Controlling

본문: 3부 전체, 4부 4.3

반례

❌ 스킬 문서만 작성하고 역기획서를 생략해, 숨어 있는 이상한 요구를 발견하지 못한다.

❌ 역기획서를 추상적으로 작성해 검수 불가능한 상태로 둔다.

❌ 사전에 작성한 기획서를 역기획서로 제출해, 실제 결과물과의 괴리가 숨겨진다.

❌ 두 문서 사이의 대응 관계를 검증하지 않아 드리프트가 누적된다.

P.4 · 위원회 이중 검토 원칙 (Committee Dual Review)

→ 본문 4부 전체

정의

모든 산출물은 작성자 AI 외의 독립된 AI 에이전트 집합(위원회) 이 검수한다. 위원회의 유일한 검수 기준은 다른 모듈의 권리를 침해하지 않는가이며, 태도·성과·인격 평가는 금지된다.

원칙 작동 방식

위원회는 최소 세 역할로 구성된다: 위원장(Chair), 검수자(Reviewer), 서기(Secretary). 각 역할은 서로 다른 모델 인스턴스로 운영된다.

검수자는 서로 다른 모델 패밀리(Claude, GPT, Gemini 등)에서 가져와 교차 검증 효과를 얻는다. 같은 모델의 다른 버전은 위험하다.

검수 기준은 네 가지 권리 침해 유형으로 한정된다: 네임스페이스 침해, 자원 접근 침해, 책임 영역 침해, 약속된 계약 위반.

판정은 세 가지 중 하나다: 승인(Approved), 조건부 승인(Approved with Conditions), 반려(Rejected).

서기 에이전트는 모든 검수 과정을 마크다운 회의록으로 기록해 옵시디안 볼트의 03-committee/ 디렉터리에 저장한다. 이 기록이 감사 가능성을 제공한다.

위원회는 태도·성과·인격·예술성·법률·의학 판단을 수행하지 않는다. 이 경계를 넘는 검수는 무효로 간주된다.

연결된 영역

수행 영역: D.1 Governance, D.2 Scope, D.7 Risk

포커스 영역: F.4 Monitoring & Controlling

본문: 4부 전체, 7부(MAD와 간신배)

반례

❌ 단일 모델 인스턴스가 위원장과 검수자를 겸해 교차 검증 효과가 사라진다.

❌ 위원회가 작성자의 태도를 평가해 권력으로 변질된다.

❌ 검수 기준이 여러 개로 늘어 일관성이 무너진다.

❌ 회의록 아카이브가 없어 과거 판정을 재구성할 수 없다.

P.5 · 자기참조 금지 원칙 (Autophagy Prevention, MAD Guard)

→ 본문 7부 7.2, 7.3, 7.4

정의

AI의 출력을 같은 AI의 입력(학습 데이터 또는 평가 입력)으로 되먹이지 않는다. MAD(Model Autophagy Disorder)² — 모델 자가포식 장애 — 를 방지하기 위한 구조적 원칙이다.

원칙 작동 방식

세션 격리: AI 작업의 컨텍스트는 새 세션으로 시작하며, 이전 세션의 출력을 자동 연결하지 않는다. 이전 결과는 사람이 명시적으로 선택한 부분만 다음 세션에 포함된다.

평가 주체 분리: 생성 AI와 평가 AI는 서로 다른 모델 패밀리에서 가져온다. 같은 벤더의 다른 버전도 학습 데이터가 겹치므로 회피한다.

사용자 반응 비학습: AI가 생성한 결과물에 대한 사용자 반응을 학습 데이터로 자동 사용하지 않는다. 사용자 반응은 사람이 해석해 결정으로 전환한 후, 그 결정이 스킬 문서나 백본에 반영된다.

평가의 결과물화 금지: AI가 수행한 평가 결과는 프로젝트 공식 산출물에 포함되지 않는다. 평가는 내부 참고용으로만 유지되고 참고 후 폐기된다.

사람의 필터 강제: AI 출력 → 사람 필터 → 다음 AI 입력의 순서를 반드시 유지한다. 사람 필터가 생략되면 그 경로는 MAD의 씨앗이 된다.

연결된 영역

수행 영역: D.7 Risk, D.1 Governance

포커스 영역: F.4 Monitoring & Controlling

본문: 7부 전체, 특히 7.3(미니 MAD 네 패턴), 7.4(MAD 가드)

반례

❌ AI가 생성한 단편 100편을 학습 데이터로 넣어 다음 세대 모델을 튜닝한다 → 전형적 MAD.

❌ AI가 작성한 스타일 가이드를 다시 AI에게 강제해 평균으로 수렴시킨다.

❌ 사용자 반응 데이터를 AI에게 직접 입력해 편향을 누적시킨다.

❌ 같은 모델의 다른 인스턴스로 위원회를 구성해 동일 오류 패턴이 반복 누락된다.

P.6 · 적응형 방법론 원칙 (Adaptive Methodology)

→ 본문 1부 1.5, 2부 2.8

정의

본 규약의 모든 조항은 주 단위로 갱신 가능함을 기본 전제로 한다. 조항을 암기하지 말고, 조항의 근거를 이해하라. 근거를 이해한 팀은 환경이 변해도 같은 근거로 새로운 조항을 스스로 도출할 수 있다. 이 원칙은 다른 모든 원칙보다 상위에서 작동하는 메타 원칙이다.

원칙 작동 방식

팀의 매뉴얼 북(9부 9.2)은 매주 검토되며, 최소 월 1회 갱신된다.

AICBOK의 조항을 인용할 때는 판본 번호와 날짜를 함께 표기한다. 예: “AICBOK P.5 (v2026-04)”.

새 AI 도구·모델·기법이 등장하면, 기존 조항과의 정합성을 7일 이내에 검토한다. 충돌이 발견되면 조항을 수정하거나 새 조항을 추가한다.

조항의 변경은 근거와 함께 기록된다. "왜 바꿨는가"의 이유가 변경 이력에 반드시 명시된다.

팀원에게 조항을 교육할 때, 조항 자체보다 조항이 방지하려는 실패 사례를 먼저 설명한다. 실패 사례가 기억되어야 조항이 응용 가능해진다.

연결된 영역

모든 수행 영역: 메타 원칙으로서 전 영역에 적용됨

포커스 영역: 모든 포커스 영역

본문: 1부 1.5, 2부 2.8, 9부 9.2

반례

❌ 조항을 암기 대상으로 삼아 팀원에게 외우게 한다.

❌ 근거 없이 조항만 전파해, 환경 변화 시 팀이 조항을 재해석하지 못한다.

❌ 매뉴얼 북을 1년 전 상태로 방치해 모든 조항이 구식이 된다.

❌ 새 AI 도구 도입을 주저해, 팀이 기존 조항에 갇힌다.

제2부 · 포커스 영역(Focus Areas) 5개

모든 프로젝트는 시작하고, 계획하고, 실행하고, 감시하고, 끝낸다. 이 다섯 단계는 폭포수든 애자일이든 어떤 방법론에서든 동일하다. 차이는 단계의 존재가 아니라 단계 사이를 이동하는 방식이다. 폭포수는 한 방향으로만 흐르고, 애자일은 짧게 순환하며, AICBOK은 모든 단계가 상시 병렬로 돌아간다. AI가 24시간 실행하기 때문에, "지금은 계획 단계"라는 구분이 의미를 잃는다. 대신 팀의 관심이 어디에 있는가를 나타내는 포커스 영역으로 다룬다.

5개의 포커스 영역은 다음과 같다.

F.1 착수 (Initiating)

F.2 계획 (Planning)

F.3 실행 (Executing)

F.4 감시·통제 (Monitoring and Controlling)

F.5 종료 (Closing)

AI 집합코딩에서 이 다섯 영역은 프로젝트의 시작과 끝 사이에 선형적으로 배치되지 않는다. 한 프로젝트는 여러 개의 작업 단위로 구성되며, 각 작업 단위가 개별적으로 다섯 영역을 돈다. 따라서 동시에 여러 작업 단위가 서로 다른 포커스 영역에 있는 상태가 일상이다.

F.1 · 착수 (Initiating)

→ 본문 2부 2.5 (대헌장), 6부 6.1

목적

프로젝트 또는 작업 단위의 존재 자체를 공식 승인하고, 후속 단계에서 참조될 기본 문서와 경계를 확정한다. 착수가 제대로 수행되지 않으면 이후 단계는 기반 없이 진행되며, 중반 이후 통제력을 잃는다.

핵심 활동

대헌장(Project Charter) 작성 — 목적·범위·권한·성공 조건을 서면으로 확정한다. 이해관계자 양측의 서명이 필요하다.

AI 에이전트 역할 정의서 작성 — 어떤 에이전트가 어떤 기능을 담당하는지 JD(Job Description) 수준으로 명세한다.

초기 스킬 문서 스켈레톤 작성 — 이후 작업이 참조할 규정의 틀을 미리 배치한다. 세부 내용은 F.2에서 채운다.

승인 기준표 수립 — 위원회가 검수 시 사용할 판정 기준을 미리 합의한다.

도구 스택 확정 — 사용할 AI 도구, 저장소 구조, 옵시디안 볼트 레이아웃을 결정한다.

산출물

00-charter/charter.md — 대헌장

00-charter/roles.md — 에이전트 역할 정의서

01-skills/_skeleton.md — 스킬 문서 스켈레톤

00-charter/acceptance-criteria.md — 승인 기준표

00-charter/toolstack.md — 도구 스택 명세

체크리스트 (Check Results)

F.1.1 대헌장이 목적·범위·권한·성공 조건을 모두 포함하는가

F.1.2 대헌장에 이해관계자의 서명이 있는가

F.1.3 에이전트 역할 정의서가 각 에이전트의 JD를 명확히 기술하는가

F.1.4 승인 기준표가 위원회 검수 시 적용 가능한 구체성을 갖추는가

F.1.5 도구 스택에 P.1(자연어 우선)을 만족하는 마크다운 기반 인프라가 포함되는가

F.1.6 백본 문서(아키텍처 한 페이지)가 초안 형태로 존재하는가

F.2 · 계획 (Planning)

→ 본문 3부 전체, 6부 6.9(팀장의 하루 중 설계 시간)

목적

착수에서 확정된 경계 안에서 작업의 절차와 요구를 구체화한다. 스킬 문서와 역기획서의 초안이 이 영역에서 생성되며, 위원회 검수의 입력이 준비된다.

핵심 활동

스킬 문서 초안 작성 — F.1의 스켈레톤을 구체 내용으로 채운다. 6개 구성 요소(개요·전제·절차·금지·판정·이력)를 모두 포함한다.

요구사항 명세(역기획서) 기획 — 실제 작성은 F.3(실행) 뒤에 이루어지지만, 기획 단계에서 역기획서의 질문 목록을 준비한다.

계획서·목차 선행 작성 — AI에게 작업을 시키기 전, 계획서와 목차를 먼저 작성하도록 요청한다. 즉흥 실행을 방지한다.

리스크 식별 — 작업 수행 중 발생 가능한 실패 지점을 미리 열거한다(→ D.7 Risk).

에이전트 오케스트레이션 계획 — 어떤 에이전트를 어떤 순서로 호출할 것인가의 흐름도.

맥락 구성 기준 확정 — 어떤 문서와 어떤 데이터가 작업 컨텍스트에 포함되어야 하는가의 목록.

산출물

01-skills/skill-*.md — 스킬 문서 초안

02-requirements/req-*-plan.md — 역기획서의 질문 목록

01-skills/_plan-*.md — 작업 계획서 및 목차

00-charter/risk-register.md — 리스크 등록부

01-skills/_orchestration-*.md — 에이전트 호출 흐름

체크리스트

F.2.1 스킬 문서 초안이 6개 구성 요소를 모두 담고 있는가

F.2.2 계획서와 목차가 실행 이전에 작성되었는가

F.2.3 역기획서의 질문 목록이 구체성 기준을 만족하는가

F.2.4 리스크 등록부가 최소 5개 이상의 잠재 위험을 나열하는가

F.2.5 에이전트 호출 순서가 명시되어 있고 병렬성이 표시되어 있는가

F.2.6 맥락 구성 기준이 토큰 한계를 고려한 우선순위를 포함하는가

F.3 · 실행 (Executing)

→ 본문 1부 1.3 (자원이 남아도는 시대), 3부 3.8 (모듈 분리)

목적

F.2에서 수립된 계획에 따라 실제 작업을 수행한다. AI 에이전트가 코드와 문서를 생성하고, 사람은 생성 과정을 조율한다. 이 영역은 전체 생애주기에서 시간과 토큰을 가장 많이 소비한다.

핵심 활동

에이전트 호출과 생성 — 스킬 문서를 맥락으로 제공하며 에이전트에게 작업을 지시한다.

세션 격리 유지 — 각 작업 단위는 독립된 세션에서 수행되며, 이전 세션의 출력이 자동 연결되지 않는다(P.5).

청크 분할과 병렬 실행 — 대규모 작업은 청크로 나뉘어 여러 에이전트에 병렬 분배된다.

중간 검토와 재지시 — 에이전트의 초기 응답을 사람이 확인하고 필요한 재지시를 내린다.

산출물 임시 저장 — 생성된 결과물은 옵시디안 볼트의 임시 디렉터리에 저장되며, F.4(감시·통제)로 넘어간다.

산출물

생성된 코드, 문서, 데이터

_staging/ 디렉터리의 임시 파일

에이전트 호출 로그

체크리스트

F.3.1 모든 에이전트 호출이 해당 스킬 문서를 맥락으로 포함했는가

F.3.2 세션 격리가 유지되었는가(P.5 위반 없음)

F.3.3 생성물이 _staging/에 분리 저장되어 메인 브랜치를 오염시키지 않는가

F.3.4 에이전트 호출 로그가 기록되어 재현 가능한가

F.3.5 중간 검토에서 맥락 이탈이 발견되었을 때 재지시가 이루어졌는가

F.3.6 토큰 사용량이 예산 범위 내에 유지되는가(→ D.4 Finance)

F.4 · 감시·통제 (Monitoring and Controlling)

→ 본문 4부 전체, 7부 7.4(MAD 가드), 7.9(재검토 원칙)

목적

실행 중 또는 실행 직후의 산출물을 지속적으로 감시하고, 편차가 발견되면 통제 조치를 취한다. 위원회 검수, 재검토, 드리프트 탐지, MAD·간신배 경보가 이 영역에 속한다.

핵심 활동

위원회 검수 요청 — F.3에서 생성된 산출물(스킬 문서 + 역기획서 쌍)을 위원회에 제출한다.

재검토 수행 — AI의 응답을 받은 직후 "어때?"를 반복한다. 계획 단계, 핵심 결정 지점, 오류 수정 후, 최종 제출 전의 4지점에서 필수 수행.

드리프트 탐지 — 코드와 문서 사이의 괴리를 주기적으로 감지한다. 괴리가 발견되면 문서 갱신 요청을 트리거한다.

MAD·간신배 경보 — 출력이 입력으로 되먹이는 패턴, AI의 아첨성 표현, 스킬 문서에 누적되는 단편 지시를 감시한다.

교차 모델 검증 — 중요 결정은 최소 두 개 이상의 서로 다른 벤더 모델로 검증한다.

캐시 우회 — 재검토가 캐시 때문에 반복 응답에 그치지 않도록, 다른 도구 또는 다른 세션으로 돌린다.

산출물

03-committee/committee-*.md — 위원회 회의록

03-committee/drift-reports/ — 드리프트 감지 보고서

03-committee/audit-log.md — 감시 로그

체크리스트

F.4.1 제출된 모든 산출물이 위원회 검수를 통과했는가(승인 또는 조건부)

F.4.2 재검토의 4지점(계획·핵심결정·오류수정·최종제출)이 모두 수행되었는가

F.4.3 드리프트 감지가 최소 주 1회 실행되는가

F.4.4 MAD·간신배 경보 패턴이 로그로 기록되는가

F.4.5 교차 모델 검증이 적용된 결정과 그 근거가 감사 로그에 남아 있는가

F.4.6 캐시 우회가 필요한 경우 다른 모델·세션으로 재검증이 이루어졌는가

F.5 · 종료 (Closing)

→ 본문 4부 4.5(작성자 서명), 4.6(업데이트 자동 하강)

목적

위원회 검수를 통과한 산출물을 공식 아카이브하고, 작성자의 서명으로 책임을 고정하고, 관련 문서의 자동 갱신을 전파한다. 이 영역이 완료되어야 한 작업 단위가 종결된 것으로 간주된다.

핵심 활동

작성자 서명 부착 — 스킬 문서와 역기획서 말미에 작성자명·날짜·책임 선언 블록을 추가한다.

아카이브 이관 — 승인된 산출물을 _staging/에서 정식 디렉터리로 이관한다. 임시 파일은 삭제된다.

변경 이력 기록 — 각 문서의 변경 이력 섹션에 이번 작업의 변경 사항을 기록한다.

관련 문서 자동 갱신 — 이 작업이 영향을 미친 다른 문서(백본, 용어집, 관련 스킬 문서)의 갱신을 위원회가 요청한다.

학습 자산 축적 — 작업 중 발견된 새 교훈을 매뉴얼 북의 “자주 겪는 문제” 장(9부 9.2 Chapter 7)에 추가한다.

감사 로그 확정 — 서기 에이전트의 기록을 최종 상태로 고정하고 수정 불가 상태로 잠근다.

산출물

서명이 부착된 최종 문서 (정식 디렉터리 위치)

04-changelog/changelog.md — 변경 이력

갱신된 백본 문서와 용어집

매뉴얼 북의 증보 섹션

체크리스트

F.5.1 모든 승인된 문서에 작성자 서명이 부착되었는가

F.5.2 임시 디렉터리가 정리되고 정식 디렉터리로 이관되었는가

F.5.3 변경 이력이 해당 작업을 기록하고 있는가

F.5.4 이 작업으로 영향받는 관련 문서의 갱신이 트리거되었는가

F.5.5 새 교훈이 매뉴얼 북에 추가되었는가

F.5.6 감사 로그가 확정되어 수정 불가 상태인가

10부 맺음 · 포커스 영역의 순환

다섯 영역은 선형적으로 흐르지 않는다. 각 작업 단위가 독립적으로 다섯 영역을 돈다. 한 프로젝트 안에서 동시에 여러 작업이 서로 다른 포커스 영역에 있는 상태가 정상이다.

팀장은 여러 작업 단위의 현재 포커스 영역을 동시에 파악하고 있어야 한다. 작업 A는 F.2에 있고, 작업 B는 F.4에 있고, 작업 C는 F.5로 이관 중이다. 옵시디안 볼트의 디렉터리 구조를 열면 각 작업의 현재 위치가 파일 경로로 드러난다. 이 가시성이 관리 비용을 극적으로 낮춘다.

10부는 무엇을 지켜야 하는가(원칙)와 어느 시점에 지켜야 하는가(포커스 영역)를 다뤘다. 11부는 어디에서 어떤 활동을 수행하는가(수행 영역)를 다룬다.

10부 각주

¹ PMBOK® Guide. Project Management Institute (PMI)가 발행하는 프로젝트 관리의 국제 표준. 1987년 초판 이후 주기적으로 개정되어 왔으며, 2025년 발행된 8판은 ANSI/PMI 99-001-2025 표준으로 승인됐다. 본서는 PMBOK® Guide 8th Edition을 참조했다.

² Alemohammad, S. 외 (2023). “Self-Consuming Generative Models Go MAD.” arXiv:2307.01850. Rice University. 본서 7부 각주 1번 참조.

³ Sharma, M. 외 (2023). “Towards Understanding Sycophancy in Language Models.” arXiv:2310.13548. Anthropic. 본서 7부 각주 5번 참조.

⁴ Bainbridge, L. (1983). “Ironies of Automation.” Automatica, 19(6), 775–779. 본서 5부 각주 5번 참조.

⁵ AICBOK의 4단 형식. 정의(무엇인가) → 작동 방식(어떻게 실행하는가) → 연결(다른 영역과 어떻게 엮이는가) → 반례(무시하면 어떻게 실패하는가). 이 구조는 보편적 학습 순서(개념→적용→맥락→경고)를 따른다. AI가 이 구조를 읽으면 각 원칙을 팀 매뉴얼의 해당 절로 자동 변환할 수 있다.

⁶ 포커스 영역이라는 이름. "포커스 영역"은 "지금 팀의 관심이 어디에 있는가"를 나타낸다. 전통적 “프로세스 그룹”(착수→종료의 순차 흐름)과 달리, 포커스 영역은 동시 병렬을 전제한다. 여러 작업 단위가 서로 다른 포커스 영역에 동시에 있는 것이 정상이다. AI가 24시간 실행하는 환경에서 "지금은 계획 단계"라는 구분은 성립하지 않기 때문이다.

다음 장 예고 — 11부는 AICBOK II로, 7개의 수행 영역과 재단(Tailoring)을 다룬다. 각 영역의 내용은 AI 집합코딩에 특화되어 있다.

© 2026. Kim Dongeun(WhtDrgon) at MEJE Works Corp. All rights reserved.