2부 · 잊힌 방법론의 귀환

2부 · 잊힌 방법론의 귀환 — PMP, 폭포수, 애자일의 원점

본 장의 질문. 인류는 AI가 없을 때 달에 로켓을 쏘았다. 그 프로젝트를 성공시킨 방법론은 어디서 태어났고, 어디에 숨어 있다가, 왜 지금 다시 꺼내야 하는가. AI 시대의 새 방법론처럼 보이는 것들 대부분은 사실 20세기 중반에 완성된 체계의 재조립이다. 대응 규약: AICBOK P.6(적응형 방법론 원칙), F.1(착수), F.2(계획), D.1(거버넌스)

2.1 1945년의 유산 — 로켓을 올린 사람들은 AI가 없었다

달에 발을 디딘 인류의 발자국은 1969년에 찍혔다. 그 발자국을 가능하게 한 공학·관리·보급·품질 체계는 그보다 20년 앞선 1940년대 후반에 거의 완성되어 있었다. 아폴로 계획이 시작된 1961년 이전부터, 미국과 유럽의 방위·건설·조선 산업은 수만 명이 동시에 움직여야 하는 거대 프로젝트를 반복해서 경험하고 있었다. 제2차 세계대전이 남긴 가장 큰 유산은 전장의 전리품이 아니라 인력과 자원을 대규모로 조직하는 지식이었다. 이 지식이 1950년대를 거쳐 공식화되고, 1960년대에 우주 계획으로 확장됐다.

AI 시대의 담론은 "지금 처음으로 복잡도를 다룰 수 있게 됐다"라는 태도를 자주 보인다. 착각이다. 복잡도를 다루는 기술은 이미 존재한다. 단지 개별 개발자의 일상 속으로 내려오지 못했을 뿐이다. 거대 프로젝트의 관리 도구가 한 명의 팀장이 쓰는 도구로 내려오려면 비용이 한 자릿수 이상 떨어져야 한다. 그 하강을 가능하게 한 것이 AI다. AI는 새로운 방법론을 발명한 것이 아니라, 기존 방법론을 개인 스케일에서 실행 가능하게 만든 엔진이다.

도구가 바뀐 것과 원리가 바뀐 것은 구분되어야 한다. AI 시대에 바뀐 것은 도구이고, 원리는 대부분 그대로다. 이 두 층위를 혼동하면 이미 검증된 방법론을 다시 발명하는 데 몇 년을 낭비한다.

[배경] 제2차 세계대전이 남긴 조직 이론의 두께 운영 연구(Operations Research)¹, 품질 관리(Quality Control)², 임계경로법(CPM)³, PERT⁴, 크리티컬 체인 기법, 시스템 엔지니어링. 이 이름들은 대부분 1940년대 중반에서 1950년대 중반 사이에 정식화됐다. 영국 공군이 레이더 운용 최적화를 위해 통계학자를 동원하던 시기가 운영 연구의 기원이고, 미국 해군이 폴라리스 잠수함 미사일 개발 일정을 관리하기 위해 고안한 PERT가 1958년에 공식 발표됐다. 이 방법론들은 그 뒤 기업 경영과 건설 산업으로 넘어갔고, 1969년 아폴로 11호의 관리 체계에 그대로 흡수됐다. 오늘날 프로젝트 관리 교육과정에서 다루는 도구 대부분의 출생증명서는 이 시기에 발급됐다.

2.2 애자일이 먼저였다 — 폭포수보다 오래된 방법론의 아이러니

프로젝트 관리 입문서를 처음 펼친 사람은 보통 이 순서로 설명을 듣는다. 먼저 폭포수(Waterfall) 가 있었고, 그것이 너무 경직되어 실패를 반복했기 때문에, 더 유연한 애자일(Agile) 이 나타나 대체하고 있다. 이 서사는 널리 퍼져 있고, 대부분의 강연과 기업 교재에서 그대로 사용된다. 그리고 이 서사는 부분적으로 틀렸다.

사실 관계를 바로잡으면 이렇다. 애자일적 작업 방식은 폭포수보다 먼저 존재했다. 사람들이 모여서 이야기를 주고받으며 소규모 단위로 작업을 반복하고, 그 결과를 서로 확인하면서 다음 작업을 결정하는 방식은 인류가 집단 노동을 시작한 이래 기본이었다. 이 방식에 "애자일"이라는 이름이 붙은 것은 2001년 애자일 선언(Agile Manifesto)⁵ 이후이지만, 실천으로서의 애자일은 그 이름이 붙기 훨씬 전부터 실무 현장에서 쓰이고 있었다. 소규모 개발팀이 고객과 매주 만나서 진척을 확인하고 다음 주 할 일을 결정하는 방식은 1960년대 상업용 소프트웨어 개발 초기부터 일상이었다.

폭포수라는 단어는 1970년 윈스턴 로이스(Winston Royce)⁶의 논문에서 유래했다. 이 논문의 원제목은 "대규모 소프트웨어 시스템 개발의 관리"였고, 로이스가 실제로 주장한 것은 순수한 폭포수 모델이 아니라 반복과 피드백이 포함된 모델이었다. 논문은 순차적 단계의 그림을 먼저 보여준 뒤, "이 접근은 위험하고 실패를 부른다"라고 명시적으로 경고했다. 그런데 후대의 독자들은 앞쪽의 그림만 기억하고 뒤쪽의 경고를 잊었다. 이 왜곡된 형태의 "폭포수"가 수십 년 동안 소프트웨어 공학 교과서에 박제되어 애자일의 반면교사로 기능했다.

더 정확한 역사가 있다. "폭포수"라는 단어 자체는 로이스 이전에 쓰이지 않았지만, 로이스가 비판적으로 묘사한 “흔한 관행” 은 구체적 역사적 실체를 가지고 있다. 그 실체의 이름은 SAGE⁶ᵃ다.

1956년, MIT 링컨 연구소의 허버트 베닝턴(Herbert Benington) 이 "대형 컴퓨터 프로그램의 생산"이라는 논문을 발표했다. 이 논문은 SAGE(Semi-Automatic Ground Environment) 방공 시스템 개발 과정을 기술하면서, 소프트웨어 개발을 다음의 순차적 단계로 명시했다.

운영 계획 → 기능 명세 → 설계 명세 → 코딩 → 테스트 → 운용

각 단계가 완료되고 문서화된 이후에만 다음 단계로 진행하는 구조. 로이스가 1970년에 "기존 관행"으로 그린 다이어그램의 실질적 원형이 바로 이것이다. SAGE 프로젝트 자체는 역사상 최초의 대형 소프트웨어 프로젝트로 기록된다. MIT 링컨 연구소, IBM, Bell Labs가 협력한 당시 세계 최대 규모의 실시간 컴퓨팅 시스템이었다.

이 순차 방법론은 허공에서 나온 것이 아니다. 제2차 세계대전 이후 미 국방부가 확립한 MIL 규격(Military Standards)⁶ᵇ 의 하드웨어 조달 체계가 원천이다. 개념 단계(Concept Phase) → 개발 단계(Development Phase) → 생산 단계(Production Phase), 각 단계 전환 시 공식 검토위원회의 승인이 필수. 이 하드웨어 조달 논리가 1950년대 소프트웨어 개발에 그대로 이식됐다. 소프트웨어는 “또 다른 종류의 공학 산출물” 로 취급되었기 때문에, 건설·제조업의 “설계도 → 시공 → 검수” 논리가 자연스럽게 유입된 것이다.

여기서 중요한 것은, 이 체계가 조잡하거나 원시적인 것이 아니었다는 사실이다. 대항해시대의 복식부기가 당시의 기술과 소통 수준에서 달성 가능한 최고 수준의 정밀성이었듯이, SAGE 시대의 단계별 순차 방법론은 1950년대의 기술과 조직 역량으로 달성할 수 있었던 최고 수준의 엄격한 개발 관리 체계였다. 수천 명의 엔지니어가 대륙 규모의 방공 시스템을 구축하면서도 품질을 유지한 것은, 이 방법론이 단순하고 원시적이었기 때문이 아니라 정교하고 엄밀했기 때문이다.

이 역사의 순서를 바로잡으면 다음과 같은 결론이 나온다. "폭포수"라는 한 단어로 묶어서 치부하는 것은 70년간 축적된 정교한 공학 체계를 과소평가하는 일이다. 로이스의 1970년 비판은 이 체계의 개선을 위한 것이었지, 이 체계가 무가치하다는 선언이 아니었다. 그런데 이후 업계는 비판 대상이었던 다이어그램만 떼어내 "폭포수 모델"이라고 표준화해 버렸고, 2001년 애자일 선언은 이 왜곡된 폭포수를 밑도 끝도 없이 공격 대상으로 삼았다. 결과적으로, 1950년대의 정교한 공학 관행은 "구식"이라는 딱지를 붙인 채 방치됐고, 그 자리에 들어온 것은 선언문에 가까운 것을 개발 방법론이라고 무작정 적용하는 관행이었다.

애자일 자체를 부정하는 것이 아니다. 애자일은 작은 팀, 낮은 비용, 높은 변경 허용치를 가진 환경에서 탁월하게 작동한다. 문제는 단일 방법론을 만능처럼 적용하는 태도다. 폭포수가 최적인 환경(큰 팀, 높은 비용, 낮은 변경 허용치)은 여전히 존재하고, AI 시대에 오히려 더 자주 등장한다. 하네스도 그 일부라고 할 수 있다. 수백 개의 에이전트가 동시에 움직이는 상황에서 변경 한 번이 연쇄적으로 퍼져 수백 개의 출력을 동시에 오염시키기 때문이다. 두 방법론은 경쟁 관계가 아니라 적용 조건이 다른 두 개의 도구다.

무엇보다, AI 시대에 길을 잃었다면 — 그리고 실제로 많은 팀이 길을 잃었다 — 되돌아볼 곳이 있다는 사실이 중요하다. 1950년대에 수천 명의 엔지니어가 문서와 절차만으로 대륙 규모의 시스템을 구축했던 방법론은, 지금은 AI 에이전트 수십 개를 운영하는 한 명의 팀장에게 적용될 수 있다. 당시의 문서 체계와 검수 절차는 사람의 실수를 전제하고 설계되었다. AI의 실수도 사람의 실수와 구조적으로 같다. 장님을 위해 만들어진 개발 방법론은, 다른 종류의 장님이 된 AI 시대에 다시 읽을 가치가 있다.

AI 개발 환경에 이 구분을 대입하면 흥미로운 결론이 나온다. AI 에이전트는 작업 한 건의 비용이 토큰 가격으로 환산되어 매우 낮고, 변경 허용치는 거의 무한하다(망친 생성물은 그냥 버리면 된다). 이 조건은 애자일 쪽에 가깝다. 그런데 동시에, AI 에이전트 수백 개가 동시에 움직이는 상황에서는 변경 한 번이 연쇄적으로 퍼져 수백 개의 출력을 동시에 오염시킨다. 이 조건은 폭포수 쪽에 가깝다. 즉 AI 시대의 개발은 양쪽 조건이 동시에 존재한다. 이것이 단일 방법론으로 해결되지 않는 이유이고, 본서가 스킬 문서·요구사항 명세·위원회라는 혼합 구조를 제안하는 이유이기도 하다.

[배경] 로이스 논문의 진짜 주장 Winston Royce의 1970년 논문 "Managing the Development of Large Software Systems"는 소프트웨어 공학 역사에서 가장 많이 오독된 문헌 중 하나다. 논문은 9페이지 분량이고, 1페이지부터 3페이지까지 단순 순차 모델을 그림으로 제시한 뒤, 나머지 6페이지에 걸쳐 이 모델의 위험을 경고하면서 반복·피드백·선행 프로토타이핑·고객 참여를 포함한 보완된 모델을 제안한다. 논문의 결론은 "단순 폭포수는 실패하며, 실제 프로젝트는 다음과 같이 해야 한다"라는 문장에 가깝다. 그런데 후대의 교재들은 1~3페이지의 그림만 인용해 "로이스가 폭포수를 제안했다"라고 요약했고, 이 요약이 애자일 진영의 공격 대상으로 굳어졌다. 원문을 직접 읽은 사람은 드물고, 읽은 사람 대부분은 이 왜곡에 불편을 느낀다.

2.3 PMP와 PMBOK — 한 권의 책이 만든 직업군

프로젝트 관리의 이름을 하나의 직업으로 못 박은 것은 미국의 비영리 단체 PMI(Project Management Institute) 가 1987년에 백서(White Paper)로 처음 내놓고, 1996년에 단행본 형태의 정식 1판으로 확정한 PMBOK(Project Management Body of Knowledge) 이다. PMBOK은 이후 수 년마다 개정되며 프로젝트 관리의 사실상 국제 표준으로 자리 잡았고, 이 표준을 기반으로 한 자격증이 PMP(Project Management Professional)⁷다. PMP는 2020년대 기준으로 전 세계 100만 명 이상이 보유한 대표적 관리자 자격증이다.

PMBOK의 판본 역사를 짧게 요약하면 이렇다⁸.

1판 (1996): 최초 공식 출간. 프로젝트 관리의 지식 영역을 정의한 틀을 세움.

3판 (2004): 프로그램·포트폴리오 관리와의 관계 정리.

6판 (2017): 49개 프로세스, 10개 지식 영역, 5개 프로세스 그룹이라는 체계가 완성된 형태로 자리 잡음. 이 판본이 오랫동안 PMP 시험의 기준이었다.

7판 (2021): 구조를 전면 개편. 프로세스 중심에서 원칙(Principles) 12개 + 성과 영역(Performance Domains) 8개 중심으로 이동. "프로세스를 외우는 공부"에서 "원칙을 이해하는 공부"로 전환.

8판 (2025): 한 번 더 간소화. 원칙 6개 + 포커스 영역 5개 + 수행 영역 7개 체제. 48,000건의 실무 데이터 포인트와 두 차례 공개 피드백을 바탕으로 작성됨. ANSI/PMI 99-001-2025 표준으로 승인.

주목할 점은 PMBOK이 판본을 거듭할수록 간결해지고 있다는 사실이다. 6판의 49개 프로세스는 7판에서 8개의 수행 영역으로 압축됐고, 8판에서는 다시 원칙 6개와 포커스 영역 5개로 추가 간소화됐다. 이 방향은 우연이 아니다. 프로세스를 외우는 관리자는 프로세스가 바뀌면 쓸모없어지고, 원칙을 이해하는 관리자는 환경이 바뀌어도 다시 적응한다. 2020년대를 지나면서 PMI 자신이 이 사실을 명시적으로 받아들였고, PMBOK을 체크리스트에서 원칙서로 바꾸는 개정을 수행해 왔다.

이 변화는 AI 시대와 무관하지 않다. PMBOK 8판의 서문은 "프로젝트의 산출(output)이 아니라 가치 전달(value delivery)에 초점을 맞추라"라는 문장을 반복한다. 이 문장은 프로세스 공정을 기계적으로 수행하기보다, 그 공정이 무엇을 위해 존재하는지를 먼저 질문하라는 요구다. AI가 실행을 떠맡기 시작한 이상, 사람은 실행 자체가 아니라 실행의 목적을 관리하는 자리로 이동해야 한다. PMBOK 8판이 제시하는 원칙 6개는 바로 이 이동을 반영한다. 이 원칙들은 다음과 같다.

총체적 관점 채택 (Adopt a Holistic View)

가치에 초점 맞춤 (Focus on Value)

프로세스와 산출물에 품질 내재화 (Embed Quality Into Processes and Deliverables)

책임 있는 리더가 될 것 (Be an Accountable Leader)

모든 프로젝트 영역에 지속 가능성 통합 (Integrate Sustainability Within All Project Areas)

권한 부여 문화 구축 (Build an Empowered Culture)

여섯 문장 모두 프로세스 지시가 아니라 태도 지시다. 어떻게 해야 하는지가 아니라 무엇을 바라보아야 하는지를 규정한다. 이 전환은 AI 시대의 관리자가 서야 할 자리를 정확하게 겨냥한다. AI가 실행 일체를 맡는 순간, 사람은 태도·가치·책임의 층위에서만 의미를 가질 수 있다. PMI는 이 지점을 미리 보고 2021년과 2025년에 걸쳐 연속 개정을 단행한 것이다.

이 책(본서)이 AICBOK의 원칙을 6개로 설정한 이유도 여기에 있다. PMBOK 8판의 6원칙 구조를 그대로 차용함으로써, AI 집합코딩의 원칙이 PMBOK 8판과 나란히 놓여 상호 참조 가능한 언어를 얻는다. 두 규약집은 같은 형식으로 쓰여, 한쪽을 읽은 독자가 다른 쪽을 낯설지 않게 읽을 수 있다. AICBOK은 PMBOK을 대체하지 않고 AI 맥락으로 번역한다.

[배경] PMBOK 8판의 핵심 구조 변화 PMBOK 8판의 가장 큰 변화는 프로세스 그룹 개념의 완전 폐기와 포커스 영역(Focus Areas) 으로의 재개념화다. 6판에서는 착수·계획·실행·감시통제·종료라는 5개 프로세스 그룹이 관리의 중심이었다. 8판은 이 다섯 그룹을 포커스 영역으로 이름만 바꾼 것이 아니라, 영역 간 경계를 유연하게 재정의하고 각 영역 안에서 반복·피드백을 허용하는 구조로 바꿨다. 프로젝트는 한 번의 순차적 흐름이 아니라, 5개 포커스 영역 사이를 오가며 가치를 축적하는 과정으로 서술된다. 이 재개념화는 애자일과 폭포수의 오래된 대립을 해체한다. 두 방법론 모두 동일한 5개 포커스 영역 위에서 작동하되, 영역 사이의 이동 빈도와 방향만 다를 뿐이다.

2.4 PMBOK 6판의 10가지 지식 영역 — “한 사람이 할 수 없는 일”

PMBOK 6판 시점까지 PMP를 공부한 사람들이 공통으로 하던 말이 있다. “이 책에 적힌 일은 한 사람이 할 수 있는 일이 아니다.” 49개의 프로세스, 10개의 지식 영역(범위·일정·원가·품질·자원·의사소통·리스크·조달·이해관계자·통합), 5개의 프로세스 그룹. 이것들을 한 사람의 머릿속에 모두 담고 동시에 관리하려 들면, 그 사람은 어느 한 항목을 대충 처리하거나 다른 항목을 놓치거나 결국 소진된다. 책의 구조 자체가 팀과 조직 단위로 분업되지 않으면 작동하지 않는 체계였다.

이것이 PMO(Project Management Office)⁹가 태어난 이유다. PMO는 프로젝트 하나를 위한 조직이 아니라, 여러 프로젝트의 관리 기능을 표준화해 제공하는 상시 조직이다. 일정 관리, 리스크 모니터링, 리포팅, 의사소통 템플릿, 자원 할당 추적. 이 모든 기능이 개별 PM의 어깨에서 PMO로 옮겨지면, PM은 비로소 프로젝트의 고유한 문제에 집중할 수 있게 된다. PMO는 대기업 구조의 전형적 산물이고, 중소 규모 팀에서는 유지 비용이 너무 높아 도입되지 못했다. 그래서 PMBOK의 지식은 대기업의 기호로 남았다. 개별 개발자에게는 책에서만 본 이야기였다.

PMBOK 6판의 10개 지식 영역을 게임업계 현장 언어로 번역해 보면 이렇게 된다.

통합 관리 — 프로젝트의 모든 요소를 조율.

범위 관리 — 무엇을 만들고 무엇을 만들지 않을 것인가의 결정.

일정 관리 — 언제 무엇이 완료되어야 하는가.

원가 관리 — 예산 안에서 움직이는 기술.

품질 관리 — 결함률과 인수 기준.

자원 관리 — 사람과 장비의 배치.

의사소통 관리 — 보고 체계와 정보 흐름.

리스크 관리 — 아직 일어나지 않은 문제를 다루는 기술.

조달 관리 — 외부 업체·하청·라이선스.

이해관계자 관리 — 투자자·고객·내부 리더의 기대 조율.

이 10가지가 동시에 돌아가야 프로젝트가 진행된다. 그리고 이 10가지 중 어느 하나라도 방치되면 다른 9가지가 연쇄적으로 무너진다. 게임 프로젝트에서 실제로 관찰되는 실패 패턴의 대부분은 이 10가지 중 하나가 암묵적으로 누락된 경우다. 일정만 관리하고 의사소통을 방치한 팀, 범위 관리는 했지만 리스크 관리를 하지 않은 팀, 품질 기준을 세웠지만 자원 배분을 맞추지 못한 팀. 어느 경우에도 결과는 같다. 특정 시점 이후 프로젝트 전체가 통제 불능에 빠진다.

AI 시대가 이 10가지 지식 영역을 어떻게 바꾸는가? 정답은 "바꾸지 않는다"이다. AI는 이 영역들을 새로 만들지 않는다. 다만 각 영역을 수행하는 작업 단위를 개인 스케일로 떨어뜨린다. 예를 들어 일정 관리는 과거에 PMO의 스케줄러가 간트 차트 소프트웨어로 수행하던 작업이었다. AI 시대에는 한 명의 팀장이 자연어로 "이번 주까지 끝내야 할 태스크를 우선순위와 예상 소요 시간과 함께 정리해 줘"라고 에이전트에게 지시하면, 과거의 PMO가 하루 종일 하던 일이 분 단위로 완료된다. 리스크 관리도 같다. 과거에는 리스크 레지스터를 주간 회의에서 업데이트하던 것이, AI 시대에는 코드와 문서의 변경 이력을 매일 자동 분석해 위험 신호를 제시하는 작업으로 바뀐다.

이 하강이 의미하는 바는 이것이다. PMBOK이 대기업의 기호로 남은 이유는 수행 비용이 너무 높았기 때문이다. 그 비용이 AI로 극적으로 떨어지면, PMBOK의 10가지 지식 영역은 처음으로 한 사람의 팀장이 실제로 실행할 수 있는 체계가 된다. 책에서만 본 이야기가 일상 업무로 내려온다. 이것이 "잊힌 방법론의 귀환"이라는 본 장 제목의 구체적 의미다.

여기서 한 번 더 분명히 해두는 것이 있다. AI는 PMBOK을 대체하지 않는다. AI는 PMBOK을 실행한다. 이 구분이 흐려지면 "AI가 프로젝트 관리를 대신해 준다"라는 과장이 발생한다. AI가 하는 일은 실행의 비용을 낮추는 것이지, 무엇을 실행할지 결정하는 것이 아니다. 무엇을 실행할지는 여전히 사람이 결정해야 하고, 그 결정의 언어는 PMBOK이다. PMBOK을 모르는 사람이 AI에게 프로젝트 관리를 시키면, AI는 자신이 학습 데이터에서 본 평균적 프로젝트 관리를 수행한다. 그 평균은 특정 조직에 맞지 않으며, 평균이 수행된 결과는 곧 무너진다. 사람이 PMBOK을 이해하고 있어야 AI에게 의미 있는 지시를 내릴 수 있다.

2.5 대헌장 — 프로젝트 착수의 계약성

PMBOK의 모든 판본에서 공통으로 맨 앞에 등장하는 개념이 프로젝트 헌장(Project Charter)¹⁰이다. 한국어로는 대헌장이라는 표현이 쓰이는데, 이 번역은 역사적 문서인 마그나 카르타(Magna Carta, 1215년 영국 대헌장)와의 어감 때문에 무게감이 부여된 선택이다. 실제로 프로젝트 헌장은 계약에 가까운 무게를 지닌다.

프로젝트 헌장은 다음 세 가지를 명시한다.

프로젝트의 목적과 범위 — 무엇을 달성할 것인가, 어디까지가 이 프로젝트의 책임인가.

권한의 소재 — 누가 결정권을 가지며, 누구의 승인이 있어야 범위를 변경할 수 있는가.

성공의 정의 — 어떤 조건이 충족될 때 이 프로젝트는 성공한 것으로 간주되는가.

이 세 가지가 서면으로 확정되고 이해관계자 양측이 서명한 뒤에야 프로젝트는 정식으로 착수된다. 이 단계를 건너뛰고 착수한 프로젝트는 중반 이후 거의 반드시 “목적이 뭐였느냐”, “이것도 우리가 해야 하는 일이냐”, “이 결과는 성공이냐 실패냐” 같은 질문에 부딪히며 통제력을 잃는다. 이 질문들의 공통점은 애초에 명시되어 있었다면 질문이 되지 않았을 것들이라는 점이다. 대헌장은 이 질문들이 나중에 분쟁으로 번지지 않도록, 프로젝트 착수 시점에 못 박아 두는 장치다.

PMP 교재는 이 원칙에 대해 한 가지 강한 조항을 붙여 둔다. 대헌장에서 어긋나는 요구가 들어오면, 프로젝트 관리자는 계약 위반으로 간주하고 작업을 중단할 수 있다. 극단적인 경우 위약금을 요구하며 퇴장할 수도 있다. 이 조항은 현장에서 거의 행사되지 않지만, 존재한다는 사실만으로도 프로젝트 관리자의 권위를 지탱한다. 대헌장이 없는 프로젝트에서 관리자는 조직 내 정치의 부속품이 된다. 대헌장이 있는 프로젝트에서 관리자는 계약의 수행자가 된다. 이 차이가 관리자의 일상적 의사결정의 질을 결정한다.

AI 집합코딩에서 대헌장은 스킬 문서 작성을 시작하기 전에 만들어진다. 팀이 AI에게 어떤 작업을 맡길 것이며, 그 작업의 성공을 어떻게 판정할 것이며, AI의 출력 중 어떤 범위가 자동 승인되고 어떤 범위가 사람의 검수를 거쳐야 하는지를 먼저 서면으로 확정한다. 이 서면이 없으면, AI가 만들어낸 출력물 하나하나에 대해 팀원 전원이 매번 다시 판단해야 한다. 매번 다시 판단하는 팀은 한 주 안에 지친다. 그리고 지친 팀은 기준을 잃는다. 대헌장은 AI 시대에 들어와서도, 아니 오히려 AI 시대에 들어와서 더욱, 필수적인 초기 문서다.

본서의 AICBOK에서는 이 대헌장이 포커스 영역 F.1 (착수, Initiating) 의 산출물로 규정된다. F.1은 착수 단계에서 다음 네 가지를 생산한다.

작업 헌장 (대헌장) — 목적·범위·권한·성공 조건

에이전트 역할 정의서 — AI 에이전트 각각이 담당할 기능의 JD 명세

초기 스킬 문서 스켈레톤 — 이후 작업이 참조할 규정의 틀

승인 기준표 — 위원회가 검수 시 사용할 판정 기준

이 네 가지 없이 착수된 AI 프로젝트는 중반 이후 거의 예외 없이 통제 불능에 빠진다. 이 예외 없음이 경험적으로 반복 관찰되는 사실이기 때문에, 본서는 F.1을 다른 모든 영역의 선행 조건으로 못 박는다.

[배경] PMP의 윤리 규정과 퇴장 조항 PMP 자격증 보유자는 PMI 윤리 강령(Code of Ethics and Professional Conduct)에 서명해야 한다. 이 강령은 책임·존중·공정·정직의 네 가치를 규정하고, 각 가치마다 위반 시 징계 기준을 제시한다. 강령에는 한 가지 특이 조항이 있다. 프로젝트가 윤리적으로 유지 불가능하다고 판단되면 관리자는 사퇴할 수 있으며, 경우에 따라 사퇴해야 한다. 이 조항은 관리자의 권위가 단순히 조직의 명령이 아니라 직업 윤리에 의해 뒷받침된다는 사실을 상징한다. 한국 게임업계에서 PMP 자격이 드물게 쓰이는 이유 중 하나는 이 권위 구조가 한국의 수직적 조직 문화와 잘 맞지 않기 때문이다. 그러나 AI 시대에 PM의 권위가 다시 질문대에 오르면서, 이 오래된 조항이 재평가될 여지가 생긴다.

2.6 형상 관리와 변경 통제 — AI 시대에 비로소 실행되는 것들

PMBOK의 여러 지식 영역 중 소프트웨어 개발과 가장 직접적으로 맞닿는 것은 형상 관리(Configuration Management)¹¹와 변경 통제(Change Control)¹²다. 이 두 개념은 하드웨어 엔지니어링에서 유래했지만, 소프트웨어 공학에 수입된 뒤 형태를 바꾸며 발달해 왔다.

형상 관리는 프로젝트 산출물의 모든 버전을 추적 가능한 상태로 유지하는 기술이다. 어떤 파일이 언제 누구에 의해 어떤 이유로 어떻게 바뀌었는지를 남기고, 과거의 어느 시점으로든 복원 가능하게 한다. 이 기술이 소프트웨어에서 구체화된 결과가 버전 관리 시스템(Git, SVN, Mercurial)이다. 변경 통제는 그 변경이 조직의 승인 절차를 거쳐 이루어지도록 보장하는 기술이다. 풀 리퀘스트와 코드 리뷰는 변경 통제의 작은 구현이고, 변경 자문 위원회(CAB, Change Advisory Board)는 그것의 조직적 구현이다.

이 두 기술은 현대 소프트웨어 개발의 기반이지만, 실제로는 거의 제대로 운영되지 않는다. 이 말은 논쟁적으로 들릴 수 있으므로 조금 풀어서 쓴다. Git 자체는 모든 개발팀이 쓴다. 그러나 Git의 존재와 형상 관리가 제대로 돌아가는 것은 다른 문제다. 코드의 변경 이력은 추적되지만, 그 변경이 왜 일어났는지는 커밋 메시지의 한 줄에 요약되거나 아예 비어 있는 경우가 허다하다. 변경의 이유가 문서화되지 않은 채로 몇 년이 지나면, 코드의 역사는 블랙박스가 된다. 누가 왜 이 코드를 이렇게 썼는지를 아무도 설명할 수 없는 상태가 된다.

변경 통제도 마찬가지다. 풀 리퀘스트는 대부분의 팀이 사용하지만, 풀 리퀘스트의 리뷰는 형식적으로 이루어지는 경우가 많다. 리뷰어는 코드를 정밀하게 읽지 않고 "LGTM(Looks Good To Me)"이라는 짧은 코멘트로 승인한다. 이것은 리뷰어를 비난하기 위한 말이 아니라, 리뷰라는 작업 자체의 비용이 너무 높기 때문에 생기는 불가피한 현상이다. 리뷰어가 한 건의 풀 리퀘스트를 제대로 읽으려면 최소 30분, 복잡한 경우 몇 시간이 필요하다. 하루에 수십 건의 리뷰 요청이 들어오는 환경에서 이 시간은 확보되지 않는다. 결국 리뷰는 의례가 되고, 변경 통제는 이름만 남는다.

AI는 이 두 기술의 비용을 극적으로 낮춘다. 커밋 메시지는 AI가 변경된 코드를 읽고 자연어로 자동 작성한다. 풀 리퀘스트의 리뷰도 AI가 1차로 수행해, 잠재적 버그·스타일 위반·모듈 경계 침해를 빠르게 식별한다. 사람은 AI가 걸러낸 결과를 확인만 하면 된다. 이 구조가 돌아가기 시작하면, 형상 관리와 변경 통제는 처음으로 책에 적힌 대로 작동한다. 교과서가 약속했던 이상적 상태가 비로소 현실이 된다.

이것이 "AI 시대에 비로소 실행 가능해지는 방법론"이라는 본 장의 핵심 주장이다. PMBOK이 말하던 형상 관리와 변경 통제는 이론적으로 옳았지만 운영 비용 때문에 현실에서는 느슨하게 시행됐다. 그 비용을 AI가 부담하면서, 이론과 현실의 간극이 줄어든다. 이 간극이 줄어드는 속도는 앞으로 몇 년간 가파를 것이고, 그 과정에서 잊혔던 다른 방법론들도 차례로 다시 꺼내질 것이다. 본서가 스킬 문서(3부)와 AI 위원회(4부)를 다음 장의 주제로 삼은 이유가 여기에 있다. 그 두 장은 형상 관리와 변경 통제를 AI 스케일로 다시 구현하는 구체적 장치다.

여기서 한 가지 보충 개념을 소개한다. 디지털 트윈(Digital Twin)¹³이라는 말이 최근 기업 담론에서 자주 등장한다. 디지털 트윈은 현실 세계의 시스템을 디지털 공간에 1:1로 복제해 시뮬레이션하는 개념이다. 원래는 제조업에서 공장이나 기계 설비를 모델링하는 데 쓰였다. 소프트웨어 개발에서 이 개념이 흥미로운 이유는, 소프트웨어는 이미 디지털이라서 트윈이 필요 없다는 점이다. 코드는 실물 공장을 시뮬레이션한 모델이 아니라, 그 자체로 디지털이다. 디지털 트윈이 아니라 디지털 그 자체다.

이 사실이 의미하는 것은 이것이다. 제조업이 디지털 트랜스포메이션(Digital Transformation)을 통해 디지털 공간으로 이전하는 동안, 소프트웨어 개발은 그 이전 단계 자체가 필요하지 않다. 이미 디지털 공간에 있기 때문이다. 그래서 AI가 소프트웨어 개발을 자동화할 때, 중간 변환 계층이 없다. AI는 코드를 직접 읽고 직접 수정하고 직접 커밋할 수 있다. 제조업 AI가 먼저 3D 스캐너로 실물을 디지털화해야 하는 단계 없이, 소프트웨어 AI는 첫 날부터 기존 자산을 완전한 형태로 활용할 수 있다. 이 지점이 소프트웨어 개발이 다른 산업보다 훨씬 빠르게 AI의 영향을 받는 구조적 이유다. 그리고 이 사실이 PMBOK의 형상 관리·변경 통제 같은 오래된 개념이 다른 어떤 산업보다 먼저 AI 시대에 부활하는 이유이기도 하다.

[배경] 페어 프로그래밍, 스프린트, 칸반 — 모두 형상 관리였다 애자일 진영에서 자주 언급되는 기법들의 정체를 들여다보면 흥미로운 사실이 드러난다. 페어 프로그래밍¹⁴은 두 개발자가 한 대의 컴퓨터에서 함께 코드를 작성하는 방식인데, 그 핵심 기능은 실시간 코드 리뷰이다. 즉 변경 통제의 한 형태다. 스프린트¹⁵는 2~4주 단위의 고정된 개발 주기인데, 그 핵심 기능은 변경의 범위를 시간 창으로 제한하는 것이다. 형상 관리의 시간 축 구현이다. 칸반¹⁶은 작업의 흐름을 시각화하는 보드인데, 그 핵심 기능은 진행 중인 작업의 수를 제한해 변경의 병렬도를 낮추는 것이다. 역시 변경 통제의 또 다른 형태다. 애자일의 핵심 기법들은 모두 형상 관리와 변경 통제의 변종이다. 다만 이름이 다르고, 문화적 포장이 다르고, 적용 스케일이 다를 뿐이다. 이 통찰이 있으면, 애자일과 폭포수의 오래된 대립이 허구였음이 드러난다. 둘은 같은 원리의 다른 이름이다.

2.7 AI 시대의 JD 분해와 PMO의 부활

PMBOK이 다루는 대기업 구조를 게임업계의 구체적 경험에 대입해 본다. 게임 스튜디오에는 아트 디렉터(Art Director, AD)¹⁷와 그래픽 팀장(Graphics Team Lead) 이라는 두 역할이 이론상 분리되어 있어야 한다. AD는 게임 안에서 그래픽의 퀄리티와 색감, 톤, 비주얼 스타일을 관리한다. 그래픽 팀장은 게임 바깥에서 팀원의 출퇴근, 성과 측정, 모티베이션, 휴가 관리, 외주 조율을 담당한다. 이 둘은 본질적으로 다른 성격의 업무이고, 서로 다른 인격이 수행해야 하는 일이다.

그런데 한국 게임업계의 대부분 스튜디오는 이 두 역할을 한 사람이 동시에 수행한다. 아트 디렉터가 "그래픽 팀장 + 아트 디렉터"의 이중 호칭으로 일하거나, 그래픽 팀장이 "팀장이면서 동시에 아트 디렉터"로 일한다. 결과는 거의 언제나 동일하다. 두 업무 중 하나가 방치된다. 대체로 방치되는 쪽은 사람 관리다. 왜냐하면 사람 관리는 눈에 보이는 결과물을 당장 만들지 않기 때문이다. 눈에 보이는 것은 게임 안의 비주얼이고, 회의실에 가져갈 수 있는 것도 비주얼이다. 팀원의 모티베이션 상태나 번아웃 신호는 회의실에서 보고되지 않는다.

보고되지 않는 문제는 관리되지 않고, 관리되지 않는 문제는 축적되어 어느 순간 팀 전체의 붕괴로 나타난다.

이 구조적 실패의 원인은 JD(Job Description, 직무 기술서) 분해의 부재다. 두 역할을 처음부터 명시적으로 분리해 JD를 따로 쓰면, 두 사람에게 따로 맡기거나 한 사람에게 맡기더라도 시간 배분이 가능해진다. JD 분해가 안 된 상태에서는 "모든 그래픽 관련 일은 AD 책임"이라는 암묵적 기대만 남고, 그 기대는 수행자의 어깨에 실제로 감당할 수 없는 짐을 얹는다.

PMBOK이 제안하는 PMO의 본질은 이 JD 분해의 조직적 구현이다. PMO는 "프로젝트 관리에 필요한 일"을 개별 PM에게 몰아넣지 않고, 기능별로 쪼개 전담 인력을 두는 방식이다. 일정 전담, 리스크 전담, 리포팅 전담, 의사소통 템플릿 전담. 이 분업이 가능해지면 개별 PM은 자신의 프로젝트에 고유한 문제에만 집중할 수 있고, 공통 업무는 PMO가 표준화해 제공한다. 이 구조는 대기업에서만 성립했다. 중소 규모 스튜디오는 PMO를 운영할 수 없었고, 그래서 개별 PM이 모든 역할을 떠안고 소진됐다.

AI 시대에 이 구조는 다시 열린다. 각 기능을 전담하는 AI 에이전트가 배치되면, 인력을 늘리지 않고도 PMO에 해당하는 기능이 조직된다. 일정 에이전트, 리스크 에이전트, 리포팅 에이전트, 의사소통 에이전트. 각 에이전트는 자신의 스킬 문서와 요구사항 명세를 가지고, 자신의 영역 안에서만 작동하며, 다른 에이전트의 권리를 침해하지 않는다. 이 구조가 돌아가기 시작하면 한 사람의 팀장이 PMO 조직을 운영하는 효과를 얻는다. 과거에 수십 명의 인력이 필요했던 관리 기능이, 한 명의 팀장과 수십 개의 에이전트로 재구성된다.

이것이 1부에서 언급한 "지위의 급격한 상승"의 구체적 의미다. 과거의 팀장은 팀원 다섯 명을 관리하는 사람이었다. AI 시대의 팀장은 에이전트 50개를 운영하는 사람이다. 관리 대상이 10배로 늘었지만, 관리의 본질은 같다. JD 분해가 명확하고, 대헌장이 작성되어 있고, 형상 관리와 변경 통제가 돌아가고 있다면, 팀장은 이 모든 것을 한 번에 감당할 수 있다. 이 조건 중 하나라도 누락되면, 팀장은 팀원 다섯 명을 관리할 때보다 더 심각하게 소진된다.

2.8 방법론은 매주 바뀐다 — 그러나 원리는 바뀌지 않는다

본 장의 마지막 문단은 1부의 마지막 문단과 의도적으로 겹쳐지는 지점을 다룬다. 본서가 제시하는 방법론은 주 단위로 바뀔 수 있다라는 전제를 기본값으로 둔다. AICBOK P.6 적응형 방법론 원칙이 이 전제를 명문화한다. 그런데 이 전제는 한 가지 오해를 부를 수 있다. "모든 것이 매주 바뀐다면, 외울 필요가 없다"라는 오해다.

이 오해를 피하기 위해 본 장은 두 층위를 구분해 두었다. 도구 층위는 매주 바뀐다. 클로드 코드 엔터프라이즈의 기능, 토큰 한도, 마크다운 변환기의 지원 포맷, 에이전트 프레임워크의 디렉터리 구조, 이런 것들은 한 달 전과 오늘이 다르다. 이 층위의 변화는 받아들이고, 그때그때 업데이트한다. 원리 층위는 바뀌지 않는다.

프로젝트 착수의 헌장성, 형상 관리와 변경 통제의 필요성, JD 분해의 원리, 권한의 소재와 성공 조건의 명시성. 이 원리들은 1940년대에 완성되어 80년 동안 형태를 유지했고, 앞으로도 비슷한 속도로만 변할 것이다.

본서가 독자에게 요구하는 것은 두 층위 모두를 아는 것이다. 도구만 아는 사람은 다음 업데이트에서 떨어져 나가고, 원리만 아는 사람은 현장에서 실행할 수단을 갖지 못한다. 두 층위를 함께 쥐고 있어야 AI 시대의 개발 환경에서 안정적으로 일할 수 있다. 이 안정성이 본서의 목표이고, AICBOK이 기여하려는 지점이다.

잊힌 방법론을 꺼내는 작업은 고풍 취미가 아니다. 그것은 현재를 다루는 언어를 확보하는 작업이다. PMP와 PMBOK이 가진 용어가 없으면, AI 시대의 개발 팀은 자신의 상황을 설명할 어휘조차 없이 혼란을 겪는다. 어휘가 없으면 문제는 해결되기는커녕 인식조차 되지 않는다. 본 장이 70년 전의 용어들을 반복해서 호출한 이유가 여기에 있다. 이 용어들이 다음 장부터 본격적으로 사용되기 시작한다. 두 장의 문서, AI 위원회, 비숙련자와 숙련자의 구분, 리더십의 분기, MAD와 간신배, 90% 법칙, 매뉴얼 북과 개인 브랜딩. 이 모든 주제는 PMBOK의 언어 위에서 재조립된다. 본 장은 그 언어의 기초를 깔아두는 장이다.

[소결]

인류는 AI 없이도 달에 로켓을 쏘았다. 그 프로젝트를 성공시킨 방법론은 1940년대에 이미 거의 완성되어 있었고, AI는 그 방법론을 발명한 것이 아니라 실행 비용을 낮췄다.

애자일은 폭포수보다 먼저 존재했다. 폭포수의 실체는 SAGE 프로젝트(1950년대)와 Benington의 1956년 방법론, 그리고 미 국방부 MIL 규격의 단계별 검수 체계다. 이것은 원시적이 아니라 당시 달성 가능한 최고 수준의 정교한 공학 관리 체계였다.

PMBOK은 판본을 거듭하며 간결해졌다. 6판의 49 프로세스 → 7판의 12 원칙 + 8 성과 영역 → 8판의 6 원칙 + 5 포커스 영역 + 7 수행 영역. 이 흐름은 "외우는 관리"에서 "이해하는 관리"로의 전환이다. (→ AICBOK 6 원칙 설계의 근거)

PMBOK의 10개 지식 영역은 여전히 유효하며, AI는 이 영역들을 대체하는 것이 아니라 수행 비용을 개인 스케일로 떨어뜨린다.

대헌장(Project Charter)은 AI 시대에도 여전히 착수의 최초 문서다. 대헌장 없이 시작된 AI 프로젝트는 중반 이후 통제력을 잃는다. (→ AICBOK F.1 착수)

형상 관리와 변경 통제는 이론적으로 이상적이었지만 비용 때문에 느슨하게 시행되어 왔다. AI가 그 비용을 부담하기 시작하면서 두 기술은 처음으로 교과서대로 작동한다. (→ 3부 두 장의 문서, 4부 AI 위원회)

애자일의 페어 프로그래밍·스프린트·칸반은 모두 형상 관리와 변경 통제의 다른 이름이다. 애자일과 폭포수의 대립은 허구였다.

디지털 트윈은 제조업의 문제이고, 소프트웨어는 이미 디지털이다. 이 사실 때문에 소프트웨어 개발이 다른 산업보다 먼저 AI의 영향을 받는다.

JD 분해의 원리는 PMO가 조직된 이유이며, AI 에이전트의 역할 분담이 돌아가는 이유다. JD 분해 없이 착수된 AI 프로젝트는 한 사람의 팀장이 감당하지 못한다.

도구는 매주 바뀌지만 원리는 바뀌지 않는다. 두 층위를 함께 쥐고 있는 것이 AI 시대의 안정성이다. (→ AICBOK P.6)

이번 주의 실행 — PMBOK 10가지 지식 영역 자가 진단: 아래 10개 중 현재 팀에서 명시적으로 돌아가는 것에 체크하라. 체크하지 못한 항목이 가장 먼저 무너질 곳이다.

통합 관리 (전체 조율) · [ ] 범위 관리 (무엇을 안 만들 것인가) · [ ] 일정 관리 · [ ] 원가 관리 · [ ] 품질 관리

자원 관리 · [ ] 의사소통 관리 · [ ] 리스크 관리 · [ ] 조달 관리 · [ ] 이해관계자 관리

각주

¹ 운영 연구(Operations Research, OR). 수학·통계·최적화 기법을 의사결정에 적용하는 응용 학문. 제2차 세계대전 중 영국 공군의 레이더 운용 최적화에서 출발해, 전후 산업계로 확산됐다. 선형 계획법, 대기 행렬 이론, 게임 이론이 대표적 하위 분야다. 한국에서는 경영과학·산업공학의 일부로 다뤄진다.

² 품질 관리(Quality Control, QC). 생산물의 결함률을 통계적으로 관리하는 기법. 1920년대 월터 슈하트(Walter Shewhart)가 통계적 공정 관리(SPC)를 고안했고, 1950년대 W. 에드워즈 데밍(W. Edwards Deming)이 일본에 전파해 토요타 생산 방식의 기반이 됐다. 6시그마(Six Sigma)는 이 계보의 현대적 후손이다.

³ 임계경로법(Critical Path Method, CPM). 프로젝트 내 작업들의 의존 관계를 그래프로 그리고, 가장 긴 경로(임계 경로)를 식별해 일정을 관리하는 기법. 1957년 듀폰과 레밍턴 랜드가 공동 개발했다. 오늘날의 간트 차트 기반 일정 관리 소프트웨어는 모두 CPM의 변형이다.

⁴ PERT(Program Evaluation and Review Technique). 1958년 미 해군 특수 프로젝트국이 폴라리스 잠수함 미사일 개발을 위해 개발한 일정 관리 기법. 작업의 완료 시간을 확률적으로 추정한다는 점에서 CPM과 다르다. CPM과 PERT는 현대 프로젝트 관리 교재에서 종종 함께 다뤄진다.

⁵ 애자일 선언(Manifesto for Agile Software Development). 2001년 2월 미국 유타주 스노버드(Snowbird)에서 17명의 소프트웨어 전문가가 모여 작성한 4개 가치와 12개 원칙의 선언문. 대표 작성자로는 켄트 벡(Kent Beck), 마틴 파울러(Martin Fowler), 워드 커닝햄(Ward Cunningham), 켄 슈웨이버(Ken Schwaber) 등이 있다. 선언문 자체는 매우 짧지만, 이후 애자일 운동의 상징이 됐다.

⁶ Winston W. Royce (1929–1995). 미국의 컴퓨터 과학자이자 록히드 소프트웨어 기술 센터의 책임자. 1970년 IEEE WESCON 학회에서 발표한 논문 "Managing the Development of Large Software Systems"가 폭포수 모델의 원전으로 잘못 인용되어 왔다. 원문은 반복과 피드백의 중요성을 오히려 강조했다.

⁶ᵃ SAGE(Semi-Automatic Ground Environment)와 Herbert Benington. 1950~1963년 미 공군이 운영한 대륙 방공 시스템. 역사상 최초의 대형 실시간 소프트웨어 프로젝트로 기록된다. MIT 링컨 연구소, IBM, Bell Labs 협력. 1956년 Benington이 발표한 논문 "Production of Large Computer Programs"가 순차적 단계(운영 계획→기능 명세→설계 명세→코딩→테스트→운용) 방법론을 최초로 문서화했다. Royce(1970)가 "기존 관행"으로 그린 다이어그램의 실질적 원형이다.

⁶ᵇ MIL 규격(Military Standards)과 단계별 검토(Phase Review). 제2차 세계대전 이후 미 국방부가 확립한 하드웨어 조달 표준. 개념 단계(Concept Phase) → 개발 단계(Development Phase) → 생산 단계(Production Phase)의 순차 구조로, 각 단계 전환 시 공식 검토위원회 승인이 필수였다. 이 논리가 1950년대 소프트웨어 개발에 이식되면서, 건설·제조업의 “설계도→시공→검수” 모델이 소프트웨어에 정착됐다.

⁷ PMP(Project Management Professional). PMI가 발급하는 국제 프로젝트 관리 자격증. 4,500~7,500시간의 프로젝트 관리 경력과 35시간의 공식 교육을 요구하며, 200문항의 시험을 통과해야 한다. 3년마다 60시간의 지속 교육(PDU)을 쌓아야 자격이 유지된다. 2024년 기준 전 세계 약 120만 명이 보유하고 있다.

⁸ PMBOK 판본 연표. 1판(1996), 2판(2000), 3판(2004), 4판(2008), 5판(2013), 6판(2017), 7판(2021), 8판(2025).

⁹ PMO(Project Management Office). 프로젝트 관리 기능을 조직적으로 표준화·제공하는 상시 부서. 지원형(supportive), 통제형(controlling), 지시형(directive)의 세 가지 유형이 있다. 대기업의 PMO는 수십 명 규모이고, 프로젝트 성공률을 정량적으로 추적한다. 중소 규모 조직에서는 한 명의 PMO 담당자가 여러 기능을 겸임하는 "미니 PMO"의 형태로 존재한다.

¹⁰ 프로젝트 헌장(Project Charter). PMBOK의 통합 관리(Integration Management) 지식 영역에 속하는 첫 번째 문서. 프로젝트의 존재 자체를 승인하는 문서이며, 프로젝트 스폰서(보통 임원급 이상)가 서명한다. 헌장은 프로젝트 관리자에게 자원을 요청할 권한을 공식 부여하고, 프로젝트의 범위·목적·성공 조건·제약을 고정한다. 한국어 번역으로는 “프로젝트 헌장”, “대헌장”, “착수 승인서” 등이 혼용된다.

¹¹ 형상 관리(Configuration Management, CM). 시스템의 구성 요소(configuration item)를 식별하고, 변경을 통제하며, 상태를 기록·보고하는 기술 분야. 원래 미 국방부가 하드웨어 시스템 관리를 위해 고안했고(MIL-STD-973 등), 소프트웨어로 확장되면서 Git과 같은 버전 관리 시스템의 이론적 기반이 됐다. ISO 10007이 형상 관리의 국제 표준이다.

¹² 변경 통제(Change Control). 프로젝트 산출물에 대한 변경을 식별·분석·승인·시행·검증하는 절차. PMBOK에서는 통합 변경 통제 프로세스(Perform Integrated Change Control)로 다루며, 변경 자문 위원회(CAB, Change Advisory Board)가 의사결정 주체가 된다. ITIL 같은 IT 운영 프레임워크에서도 핵심 개념으로 다뤄진다.

¹³ 디지털 트윈(Digital Twin). 물리적 객체, 프로세스, 시스템의 디지털 복제본을 실시간 데이터와 연결해 유지하는 개념. 2002년 미시간대학교의 마이클 그리브스(Michael Grieves)가 처음 제안했고, 2010년대 후반부터 제조업·건설업·도시 계획에 널리 확산됐다. 소프트웨어는 그 자체가 디지털이라 엄밀한 의미의 트윈이 필요하지 않다는 지적이 본서의 논점이다.

¹⁴ 페어 프로그래밍(Pair Programming). 두 개발자가 한 컴퓨터에서 함께 코드를 작성하는 방식. 한 명은 "드라이버"로 키보드를 잡고 코드를 작성하고, 다른 한 명은 "내비게이터"로 전략을 생각하고 실시간으로 리뷰한다. 1990년대 후반 익스트림 프로그래밍(Extreme Programming, XP)의 핵심 기법으로 대중화됐다.

¹⁵ 스프린트(Sprint). 스크럼(Scrum) 방법론에서 정의한 2~4주의 고정된 개발 주기. 스프린트의 시작에 계획 회의, 매일 데일리 스크럼, 끝에 리뷰와 회고가 배치된다. 이 구조는 변경의 범위를 고정된 시간 창으로 제한함으로써 예측 가능성을 확보한다.

¹⁶ 칸반(Kanban). "간판"이라는 일본어에서 유래한 작업 시각화 방법. 원래 1950년대 토요타 생산 시스템에서 오노 다이이치(Taiichi Ohno)가 도입한 부품 공급 신호 방식이었고, 2000년대 후반 데이비드 앤더슨(David J. Anderson)이 소프트웨어 개발에 적용하면서 애자일 진영의 주요 기법이 됐다. WIP(Work In Progress) 제한이 핵심 원리다.

¹⁷ 아트 디렉터(Art Director, AD). 시각 매체의 예술적 품질을 최종 책임지는 역할. 영화·광고·게임 산업 모두에서 공통으로 사용되는 직함이며, 각 산업마다 책임 범위가 약간씩 다르다. 게임 산업에서는 비주얼 톤, 콘셉트 아트, 인게임 그래픽 품질 관리가 주 업무다. 그래픽 팀장과는 이론상 분리되어야 하지만, 현실에서는 자주 겸임된다.

다음 장 예고 — 3부는 잊힌 방법론의 구체적 산물인 두 장의 문서, 즉 스킬 문서(Skill.md) 와 요구사항 명세(역기획서) 를 다룬다. 이 두 장이 형상 관리와 변경 통제를 AI 스케일로 재구현하는 장치임이 드러난다.

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