8부 · 오래된 지혜와 90% 법칙

8부 · 오래된 지혜와 90% 법칙 — 남의 지식에 올라타기

본 장의 질문. AI가 90점짜리 답을 내고 있다면, 나머지 10점을 어디서 가져와야 하는가. 그리고 AI가 내는 90점의 답 자체는 누구의 지식에 올라타서 만들어지는가. 이 두 질문의 답은 같은 곳에 있다. 오래된 지혜의 문서다. 대응 규약: AICBOK P.6(적응형 방법론), D.6(자원 영역), D.2(범위 영역)

8.1 AI 만능론을 거부하는 실무적 근거

"AI로 모든 것이 해결된다"라는 주장은 기술 산업 담론의 오래된 과장 중 하나다. 이 주장은 매 기술 혁신 시기마다 변형된 형태로 반복된다. 1990년대에는 “인터넷으로 모든 것이 바뀐다”, 2000년대에는 “모바일로 모든 것이 재편된다”, 2010년대에는 "빅데이터로 모든 것이 분석된다"였다. 각 주장은 부분적으로 옳았지만, 전부가 옳지는 않았다. 지금의 "AI 만능론"도 마찬가지다. 부분적으로 옳고, 전부는 옳지 않다.

AI 만능론을 실무적으로 거부해야 하는 이유는 감정이 아니라 관찰이다. 실제로 AI를 몇 달 이상 일상 업무에 사용한 사람은 다음과 같은 경험을 공통적으로 한다. AI는 80~90점짜리 답을 잘 낸다. 그 답은 대부분의 경우 실무적으로 충분하다. 그러나 95점 이상의 답은 드물게 나오고, 100점에 가까운 답은 거의 나오지 않는다. 나머지 10~20점의 간극은 사람이 메워야 한다. 이 간극을 인정하지 않으면 결과물의 품질이 체계적으로 저하된다.

이 경험을 정량화한 것이 본 장의 주제인 90% 법칙¹이다.

AI가 해결하는 것은 90%다. 나머지 10%는 사람의 지식과 판단으로만 완성된다.

이 공식은 수학적으로 정밀하지 않다. 90이라는 숫자는 평균적 관찰을 요약한 근사치일 뿐이다. 때에 따라 85%일 수도 있고 95%일 수도 있다. 중요한 것은 1이 아니라는 사실이다. 1이 아니므로, 나머지를 메우는 작업이 반드시 필요하다. 그 작업의 주체는 사람이며, 그 작업을 수행하는 데 필요한 것은 사람의 독립적 지식이다.

8.2 90%가 90%인 이유 — 질문의 해상도 문제

90% 법칙의 더 흥미로운 부분은 왜 90%에서 멈추는가라는 질문에 대한 답이다. 표면적으로는 AI의 능력 한계처럼 보이지만, 자세히 들여다보면 다른 원인이 드러난다. AI는 질문의 수준에 맞춰 답한다. 질문이 90%짜리이면 답도 90%짜리이고, 질문이 99%짜리이면 답도 99%에 가까워진다. 즉 90%에서 멈추는 것은 AI의 한계가 아니라 질문자의 한계다.

이 관찰이 구체적으로 의미하는 바는 다음과 같다. 같은 AI 도구를 초보자와 전문가가 사용할 때, 결과물의 차이는 거의 언제나 결정적이다. 초보자는 "이거 해결해줘"라는 식의 막연한 질문을 던지고, AI는 평균적 답변을 낸다. 전문가는 "이 문제의 A·B·C 세 측면을 고려하여, X 제약 조건 아래에서 Y를 최적화하는 방안을 제시하라. 특히 Z 시나리오에서 발생할 수 있는 엣지 케이스를 명시하라"와 같이 질문한다. 같은 AI가 낸 답변이지만, 두 답변의 질은 세 자릿수 차이가 난다.

이 차이의 원천은 질문자의 배경 지식이다. 전문가는 문제의 지형을 이미 알고 있고, 그 지형 위에 AI를 도구로 얹는다. 초보자는 지형을 모르기 때문에 도구를 어디에 얹어야 할지조차 모른다. AI는 둘 다에게 공평하게 응답하지만, 응답의 유용성은 질문의 구조에 의해 결정된다. 이것이 "90%가 90%인 이유"다. AI는 평균적 사용자의 평균적 질문에 맞춰 90% 수준에서 멈춘다. 이 멈춤은 설계된 것이 아니라 관찰된 것이다.

이 관점이 실무에 주는 함의는 다음과 같다. AI의 결과를 100점에 가깝게 끌어올리고 싶다면, AI의 성능을 올리는 것이 아니라 질문의 해상도를 올려야 한다. 질문의 해상도는 질문자의 배경 지식에 의해 결정된다. 배경 지식은 AI에게서 얻을 수 없다. AI는 자신이 학습한 평균에서 답하므로, 평균을 넘는 지식은 외부 원천에서 가져와야 한다. 외부 원천이 무엇인가? 본 장의 다음 절들이 이에 대한 답이다.

8.3 남의 지식에 올라타기 — 공식 문서 체계의 가치

AI는 인류가 축적한 방대한 텍스트 데이터를 학습한다. 이 학습에는 논문, 교과서, 기술 문서, 매뉴얼, 포럼 글, 블로그 포스트, 책이 포함된다. AI가 90%의 답을 낼 수 있는 이유는 이 학습 데이터 안에 대부분의 문제에 대한 답이 이미 존재하기 때문이다. AI가 새로 만들어내는 것은 거의 없다. 대부분 이미 존재하던 것의 재조합이다.

이 사실은 실무적으로 유용한 통찰로 전환될 수 있다. AI가 학습한 것의 원천에 직접 접근하면, AI가 낼 수 있는 답의 상한을 넘을 수 있다. AI는 학습 데이터의 평균적 답을 내지만, 원천 문서는 평균이 아니라 정점에 있는 답을 담고 있다. 정점을 찾아가는 가장 빠른 방법은 AI에게 "이 분야에서 가장 권위 있는 원천 문서가 무엇인가"를 묻는 것이다. AI는 원천 문서의 목록을 제시하고, 사람은 그 목록에서 가장 관련성 높은 문서를 직접 읽는다. 읽은 내용을 자신의 질문에 반영하면, 질문의 해상도가 급격히 올라간다. 이 과정을 본 장은 남의 지식에 올라타기라고 부른다.

이 전략의 가장 명료한 사례가 PMBOK 가이드다. 본서의 2부와 6부에서 PMBOK 8판을 반복적으로 참조하는 것은 우연이 아니다. PMBOK은 프로젝트 관리라는 주제에 대해 수십 년간 축적된 집단적 지혜의 요약이다. 이 요약을 읽지 않고 프로젝트 관리를 다시 발명하려는 것은 이미 존재하는 지식 기반을 낭비하는 일이다. AI는 PMBOK을 학습했지만, AI가 PMBOK의 전체 구조를 정확히 전달하는 것은 아니다. AI는 PMBOK에 대한 평균적 요약을 낼 뿐이다. 원문을 직접 읽은 사람만이 PMBOK의 전체 구조를 자신의 맥락에 정확히 적용할 수 있다.

PMBOK 외에도 이런 원천 문서의 예는 많다. 다음은 분야별 대표적 원천 문서의 목록이다.

프로젝트 관리: PMBOK Guide (PMI), PRINCE2 Manual (AXELOS)

품질 관리: ISO 9001, Six Sigma Handbook

소프트웨어 공학: SWEBOK(IEEE), “The Mythical Man-Month”(Brooks), “Clean Architecture”(Martin)

정보 보안: ISO 27001, NIST Cybersecurity Framework

IT 서비스 관리: ITIL 4 Foundation

데이터 관리: DAMA-DMBOK Guide

UX 설계: Don Norman의 “The Design of Everyday Things”

알고리즘: “Introduction to Algorithms”(Cormen 외, CLRS)

운영체제: “Operating System Concepts”(Silberschatz 외)

네트워크: “Computer Networking: A Top-Down Approach”(Kurose & Ross)

이 목록의 책과 표준 문서들은 모두 오랜 시간의 검증을 거쳤다. 수십 년간 반복적으로 읽히고 인용되고 개정되면서, 각 분야의 합의된 언어가 형성되었다. AI는 이 합의된 언어를 대략 알고 있지만, 정확한 형태로 가지고 있지는 않다. 정확한 형태는 원문에만 있다. 원문을 직접 읽는 사람만이 AI에게 정확한 언어로 질문할 수 있고, 그 질문이 90%를 넘는 답을 끌어낸다.

8.4 SI 기획 문서 — 게임업계가 배우지 못한 지식 체계

원천 문서의 한 가지 특별한 예가 있다. 정부 SI(System Integration)² 발주에 사용되는 기획 문서 체계다. 이 체계는 일반 기술 서적만큼 널리 알려져 있지 않지만, 실무적으로는 한국에서 가장 정교한 프로젝트 관리 문서 체계 중 하나다. 이 체계를 "오래된 지혜"의 대표 사례로 다룬다.

한국의 공공기관이 IT 시스템을 발주할 때, 발주처는 외부 개발업체에 요구사항 명세서와 제반 서류의 묶음을 내려보낸다. 이 묶음에는 다음과 같은 문서들이 포함된다.

이 문서들은 4개 군(群)으로 묶인다.

계획 문서군 — 프로젝트 전체의 틀

① 사업 수행 계획서 — 추진 방향·체계·일정·인력. PMBOK의 Project Management Plan에 해당.

② 요구사항 명세서 — 기능·성능·품질 요구. 3부의 역기획서와 구조적으로 같되 방향이 사전 작성.

③ 인력 투입 계획서 — 등급(초급~특급)·기간·역할·자격 요건.

설계 문서군 — 시스템의 구조와 기능

④ 시스템 구조 상세서 — 논리·물리 구조, 서버 구성, 네트워크 토폴로지.

⑤ 기능 정의서 — 각 기능의 입력·처리·출력·예외·UI 명세.

⑥ 현행 업무 분석서 — 도입 이전 업무 흐름 분석.

⑦ 프로세스 정의서 — BPMN 등 표준 다이어그램 기반 프로세스 정의.

⑧ 논리 DB 설계서 · ⑨ 물리 DB 설계서 — ER 다이어그램과 DBMS별 구현 명세.

검증 문서군 — 품질과 테스트

⑩ 품질 보증 계획서 — 결함률·커버리지·코드 품질 수치 목표.

⑪ 테스트 계획서 — 단위·통합·시스템·인수 테스트 계획.

운영 문서군 — 이관 이후

⑫ 운영 및 유지보수 계획서 — 시스템 인수 후 운영·유지보수 절차.

이 12개 문서는 정부 SI 발주의 기본 구성이다. 규모가 큰 프로젝트에서는 여기에 10~20개의 추가 문서가 더 붙는다. 보안 계획서, 장애 대응 계획서, 교육 계획서, 감리 계획서, 산출물 관리 계획서 등. 한 번의 발주에서 생성되는 문서의 총량은 수백 페이지에서 수천 페이지에 달한다.

이 문서 체계를 처음 보는 사람은 두 가지 반응을 보인다. 첫째는 "이렇게 많은 문서가 왜 필요한가"라는 반응이고, 둘째는 "한 발자국도 벗어날 수 없는 정밀성"에 대한 경외다. 두 반응 모두 이해 가능하다. SI 문서 체계는 최대한의 안전장치로 설계되었다. 공공 예산으로 수행되는 프로젝트는 실패 시 책임 추궁이 엄격하므로, 모든 결정이 서면으로 기록되고 모든 합의가 서명으로 확정되어야 한다. 이 엄격성이 문서의 두께로 드러난다.

한국 게임업계는 이 문서 체계로부터 실질적으로 단절되어 있다. 게임 프로그래머는 SI 문서를 다룰 일이 거의 없고, 게임 기획자도 SI 수준의 요구사항 명세서를 작성해 본 경험이 드물다. 게임 산업은 자체적인 기획 문화(game design document, GDD)를 발전시켜 왔지만, SI의 체계적 완결성과는 거리가 있다. 이 단절이 AI 시대에 뜻밖의 함의를 갖는다. SI 기획자는 AI 시대에 이미 준비된 인력이다.

이 주장은 직관에 반하므로 설명이 필요하다. AI 시대의 문서 중심 개발 방식은 본서 3부와 4부에서 다룬 대로, 코드가 아닌 문서가 산출물의 핵심이 되는 구조다. 문서를 작성하는 능력, 문서 사이의 일관성을 유지하는 능력, 요구사항을 구체적이면서도 검수 가능하게 기술하는 능력이 핵심이다. 이 능력들은 게임 프로그래머나 기획자의 전통적 훈련에는 포함되지 않았지만, SI 기획자는 수년간 이 훈련을 이미 받아 왔다. SI 기획자가 AI 시대의 스킬 문서와 역기획서를 작성하는 것은, 자신의 기존 업무를 AI 맥락으로 이름만 바꾸는 일에 가깝다.

반대로 게임 기획자나 프로그래머가 AI 시대의 문서 체계에 적응하려면, SI 기획자가 수년에 걸쳐 배운 것을 짧은 시간에 학습해야 한다. 이 학습은 쉽지 않다. 문서화의 규율은 경험을 통해서만 완성되는 감각이고, 감각은 시간을 요구한다. 본서의 권장은 다음과 같다. 팀에 SI 경력자가 있다면, 그 사람을 AI 시대의 문서 전문가로 재배치하라. 그의 경력이 장식이 아니라 자산이 된다.

[배경] 정부 SI 문서 체계의 역사적 맥락 한국의 정부 SI 발주 문서 체계는 1990년대 후반 정부 정보화 사업이 본격화되면서 정립됐다. 초기에는 각 발주처마다 서로 다른 양식을 사용했으나, 2000년대를 거치며 한국정보화진흥원(현 NIA)과 한국지능정보사회진흥원 등이 표준 양식을 배포하면서 통일되기 시작했다. 현재는 조달청의 “정보시스템 구축·운영 표준 계약서” 및 관련 부속 문서가 사실상의 표준으로 기능한다. 이 체계는 ISO/IEC 12207(소프트웨어 생명 주기 프로세스)과 ISO/IEC 15504(프로세스 평가) 같은 국제 표준과 호환되도록 설계되어 있어, 해외 대형 프로젝트 관리 방법론과의 상호 참조도 가능하다.

8.5 말뚝의 재정렬 — 역기획서로 숨은 오류를 드러내는 방법

앞서 3부에서 소개한 역기획서의 개념을 8부의 관점에서 다시 다룬다. 90% 법칙의 관점에서 역기획서는 특별한 의미를 갖는다.

AI가 생성한 코드에 숨어 있는 이상한 결정들을 상상해 본다. 변수명, 라이브러리 선택, 오류 처리 방식, 로깅 레벨, 외부 API 호출 방식, 기본값의 설정. 이 결정들은 모두 AI가 학습 데이터에서 본 “평균적” 선택을 자동으로 수행한 결과다. 각각은 90% 수준에서 합리적이지만, 프로젝트의 구체적 요구에 맞추어 재조정되지 않은 채 남아 있다. 이 재조정 없이 누적된 결정은 프로젝트 전체의 말뚝이 된다. 말뚝이란 프로젝트 안에 박혀 있지만 누구도 공식적으로 합의한 적 없는 결정들을 가리키는 비유적 표현이다.

말뚝은 시간이 지나면 프로젝트의 형태를 결정짓는다. 새 기능이 추가될 때마다 개발자는 기존 말뚝을 피해 가거나 말뚝에 맞춰 구현한다. 말뚝 자체는 재검토되지 않은 채 계속 영향력을 행사한다. 이 구조가 고착되면 프로젝트는 초기에 우연히 내려진 결정들의 누적물이 된다. 초기 결정이 의도적이었다면 고착은 문제가 아니지만, 대부분의 초기 결정은 의도가 아니라 AI의 기본값에서 나온다. 의도 없이 고착된 프로젝트는 구조적으로 허약하다.

역기획서는 이 말뚝을 표면으로 끌어올린다. 역기획서 작성의 핵심 질문은 "이 결과물을 만들기 위해 어떤 요구가 있어야 했는가"다. 이 질문에 AI가 응답할 때, AI는 자신이 암묵적으로 내린 모든 결정을 요구사항의 형태로 명시화한다. 명시된 요구사항 중 일부는 사람이 의도했던 것이고, 일부는 AI가 자동으로 추가한 것이다. 두 범주를 구분하면 사람이 의도하지 않은 말뚝의 목록이 드러난다. 이 목록을 사람이 검토해 유지할 것과 제거할 것을 결정하면, 프로젝트는 재정렬된다.

이 재정렬이 왜 중요한가? 본 장의 90% 법칙 관점에서는 이렇게 설명된다. AI가 자동으로 추가한 말뚝은 AI의 평균적 선택이다. 즉 90% 수준의 결정이다. 사람이 그 말뚝을 검토해 의도에 맞게 재조정하면, 재조정된 결정은 프로젝트의 구체적 요구에 맞춘 선택이 된다. 이 맞춤이 90%를 100%로 밀어 올리는 작업이다. 말뚝의 재정렬 없이 프로젝트는 영원히 90%에 머물고, 재정렬을 수행한 프로젝트는 그 이상으로 올라간다.

구체적 예를 들자면, AI가 자동으로 logging 표준 라이브러리를 선택했는데, 팀의 백본에는 "구조화된 로깅을 위해 structlog를 사용한다"라는 규칙이 있다고 가정한다. 역기획서를 작성하면 "시스템은 logging 표준 라이브러리를 사용한다"라는 문장이 자동으로 나타난다. 사람은 이 문장을 읽고 "잠깐, 우리는 structlog 를 쓰기로 했는데?"라고 반응한다. 이 반응이 나오면 즉시 재조정이 수행된다. 역기획서가 없었다면 이 충돌은 코드를 직접 읽어야만 발견됐을 것이고, 대부분의 경우 발견되지 않았을 것이다.

역기획서가 있으므로 발견되고, 발견되므로 수정된다. 이것이 말뚝의 재정렬이고, 90%에서 100%로의 이동이다.

8.6 대본 검토 — 상호 참조 가능한 지식 체계의 형태

역기획서가 프로젝트의 말뚝을 드러낸다면, 대본 검토는 지식 전체의 구조를 드러낸다. 이 절은 조금 더 큰 스케일의 이야기다.

대본 검토³라는 표현은 본서가 차용한 비유다. 원래 이 표현은 연극이나 영화에서 배우가 자신의 대본을 다른 전문가에게 읽히고 피드백을 받는 과정을 가리킨다. 대본은 행동 지시(지문)와 말(대사)로 이루어지며, 각 대사가 배역과 상황에 맞는지, 대본 전체의 흐름이 자연스러운지를 전문가가 확인한다. 이 검토는 배우 본인의 감각만으로는 발견할 수 없는 문제를 드러낸다.

AI 집합코딩에서 대본 검토의 비유는 다음과 같이 적용된다. 한 개발자가 AI와 함께 작성한 지식 체계(스킬 문서, 역기획서, 백본, 위원회 회의록)는 그 개발자의 대본이다. 이 대본은 개발자 본인의 감각과 AI의 평균적 선택이 결합한 결과이며, 본인의 관점 안에서는 일관되어 보인다. 그러나 다른 관점에서 보면 빈 구멍이 드러난다. 다른 관점은 두 가지 형태로 제공될 수 있다. 첫째, 다른 사람의 검토. 둘째, 다른 페르소나의 AI의 검토.

첫째 형태는 전통적 동료 리뷰에 해당한다. 팀원 한 명의 산출물을 다른 팀원이 읽고 의견을 낸다. 이 방식은 여전히 유효하지만, AI 시대에는 양적 한계가 있다. 팀원은 자신의 일만으로도 바쁘고, 다른 팀원의 대본을 정밀하게 읽을 여유가 부족하다. 둘째 형태가 이 한계를 보완한다. 다른 페르소나의 AI가 대본을 검토하는 방식이다. 같은 모델이라도 시스템 프롬프트에 다른 인격(예: “엄격한 아키텍트”, “신중한 QA”, “외부 컨설턴트”)을 부여하면, AI는 그 인격의 관점에서 대본을 읽고 의견을 낸다. 다른 인격의 의견은 원작성자가 놓친 부분을 포착할 수 있다.

이 기법을 대본 검토라고 부르는 이유는, 원작성자의 작업을 고정된 결과물이 아니라 검토 가능한 초안으로 본다는 태도 때문이다. 고정된 결과물은 수정이 어렵고, 초안은 수정이 전제되어 있다. AI 집합코딩의 산출물은 언제나 초안이라는 태도가, 장기적으로 품질을 유지하는 핵심이다.

대본 검토가 효과를 내려면 한 가지 전제가 필요하다. 검토 가능한 형태로 지식이 구조화되어 있어야 한다. 구조화되지 않은 지식은 검토할 수 없다. 구조화의 기본 단위는 앞서 소개한 상호 참조 가능한 지식 체계다. 이 체계의 핵심 특성은 다음과 같다.

① 각 지식 단위가 독립적으로 존재한다 스킬 문서 하나, 역기획서 하나, 회의록 하나가 각각 자체 완결된 문서로 존재한다. 다른 문서를 읽지 않고도 한 문서의 의미를 파악할 수 있어야 한다. 이 독립성은 문서 사이의 의존이 명시적 링크로만 이루어지도록 강제한다.

② 문서 사이의 관계가 링크로 드러난다 한 문서가 다른 문서를 참조할 때 반드시 링크(예: 옵시디안의 [[wiki-link]])로 표시한다. 이 링크가 있으면 AI도 사람도 문서 간 관계를 그래프 형태로 볼 수 있다. 링크 없이 문장 안에 "위에서 언급한 것처럼"과 같이 참조하면, 참조의 대상이 다른 맥락으로 읽힐 때 깨진다.

③ 용어가 용어집에서 정의된다 프로젝트 안에서 사용되는 모든 주요 용어는 용어집(glossary) 파일에 정의된다. 다른 문서가 그 용어를 사용할 때는 용어집에 링크를 건다. 이 구조는 용어의 일관된 사용을 강제하고, 용어의 변화가 있을 때 전파를 용이하게 한다.

④ 시간 축이 변경 이력으로 기록된다 각 문서의 끝에 변경 이력이 부착된다. 언제 누가 왜 어떻게 변경했는지가 짧게 기록된다. 이 이력이 있어야 나중에 "왜 이 결정이 이렇게 됐지?"라는 질문에 답할 수 있다.

이 네 가지 특성을 갖춘 지식 체계가 상호 참조 가능한 지식 체계다. 이 체계 위에서만 대본 검토가 가능하다. 체계가 없는 지식 덩어리는 검토할 수도, 수정할 수도, 전파할 수도 없다. 옵시디안 볼트를 위원회의 데이터베이스로 권장하는 이유가 여기에 다시 연결된다. 옵시디안 볼트는 이 네 가지 특성을 자연스럽게 지원한다.

8.7 3축 학습과 맥락 통역 — AI 페르소나의 구조

대본 검토를 수행하는 AI 페르소나를 어떻게 만드는가? 본서는 3축 학습⁴이라는 개념을 제시한다. 이 개념은 세계관 창작 파이프라인에서 유래했지만, AI 집합코딩의 맥락에서도 그대로 유효하다.

3축 학습이란 AI 페르소나가 다음 세 종류의 데이터를 동시에 학습하고 있는 상태를 가리킨다.

① 세계관 축 (World Axis) 페르소나가 움직이는 맥락의 배경 지식. AI 집합코딩 팀의 경우, 이 축은 프로젝트의 백본과 스킬 문서와 용어집에 해당한다. 페르소나는 이 배경 위에서만 판단을 내린다. 배경을 모르는 판단은 허공의 판단이다.

② 캐릭터 축 (Character Axis) 페르소나 자체의 인격적 특성. 이 캐릭터가 어떤 가치관을 가지며, 어떤 판단 기준을 사용하며, 어떤 말투를 쓰는지. AI 집합코딩의 맥락에서 이 축은 역할 정의에 해당한다. “엄격한 아키텍트”, “신중한 QA”, “외부 컨설턴트” 같은 역할이 각각 다른 캐릭터 축을 만든다.

③ 대화 축 (Conversation Axis) 페르소나가 지금까지 어떤 대화를 거쳐 왔는지의 이력. 과거 대화의 맥락은 현재 판단에 영향을 미친다. 긴 프로젝트에서 이 이력이 축적되면 페르소나는 특정 경험을 기억하는 상태가 된다.

이 세 축이 모두 학습된 AI 페르소나는, 단순한 LLM 인스턴스보다 훨씬 구체적인 판단을 내릴 수 있다. 세계관 축이 배경을 제공하고, 캐릭터 축이 관점을 제공하며, 대화 축이 이력을 제공한다. 이 세 가지가 합쳐져야 의미 있는 대본 검토가 가능해진다.

구체적 예를 든다. 프로젝트 A의 백본과 스킬 문서와 용어집을 모두 학습한 AI 페르소나를 만든다. 여기에 “외부 컨설턴트” 역할을 부여한다. 과거 팀의 결정 이력을 컨텍스트에 포함시킨다. 이 페르소나에게 최근 작성된 스킬 문서를 검토하게 한다. 페르소나는 외부 컨설턴트의 관점에서, 백본과 기존 결정을 참조하며, 새 스킬 문서의 일관성을 평가한다. 이 평가는 원작성자가 놓칠 수 있는 구조적 문제를 드러낸다.

이 방식을 본서는 맥락 통역이라고도 부른다. 서로 다른 사람이 같은 문제에 대해 이야기할 때, 용어와 맥락의 차이에서 오해가 발생한다. 한 사람이 "품질"이라고 말할 때 염두에 두는 품질과, 다른 사람이 "품질"이라고 말할 때 염두에 두는 품질이 다를 수 있다. 이 차이는 대화 중에는 드러나지 않다가, 결과물이 만들어진 뒤에 충돌로 나타난다. AI 페르소나는 이 차이를 사전에 감지할 수 있다. 한쪽 화자의 말을 다른 쪽 화자의 용어로 번역해 제시함으로써, 두 화자가 서로의 의미를 더 정확히 이해하도록 돕는다. 이것이 맥락 통역의 실질적 의미다.

맥락 통역의 한 가지 응용 사례는 회의 중 AI 깨우기다. 두 사람이 전문 주제로 논쟁하는 중간에, "지금까지 이 대화를 간결히 정리하고, 양쪽의 주장이 어느 지점에서 엇갈리는지 말해 달라"라고 AI에게 요청한다. AI는 대화의 흐름을 분석해 양쪽의 핵심 주장을 추출하고, 엇갈림의 지점을 지적한다. 이 지적이 양쪽 화자에게 자신이 말하지 않은 전제를 자각하게 한다. 자각된 전제는 대화 안으로 끌려 들어오고, 그 순간부터 대화는 더 생산적으로 진행된다.

[배경] 중국에서의 퇴사자 AI 학습 사례 2026년 4월, 중국의 한 전직 개발자가 깃허브에 “동료 스킬(colleague_skill)” 이라는 AI 에이전트 프로젝트를 공개해 화제가 됐다. 이 프로젝트는 퇴사 전 자신의 업무 패턴 — 이메일 작성, 문서 처리, 반복 업무 대응 — 을 AI에게 학습시켜, 퇴사 후에도 자신의 자리에서 AI가 일상 업무를 사실상 대행할 수 있게 만든 것이다. 조선일보(2026.04.14) 보도에 따르면, 깃허브 커뮤니티에서 "사이버 분신의 세계관을 잘 구현했다"는 평가와 함께 빠르게 확산됐다. 이 사례는 3축 학습의 개념 — 업무 맥락(세계관 축), 개인의 업무 스타일(캐릭터 축), 과거 커뮤니케이션 이력(대화 축) — 이 실무에 적용된 구체적 사례로 기록된다.

8.7.1 동료 스킬에 대한 입장 — 퇴사자 복제가 아니라 재직자 역할 보장

동료 스킬 프로젝트는 3축 학습의 기술적 구현으로서 인정된다. 그러나 적용 방향에 대해 분명한 입장이 필요하다.

동료 스킬은 "퇴사한 사람의 패턴을 복제해 그 자리를 AI로 채운다"는 발상이다. 이것은 사람이 없어도 돌아가는 조직을 목표로 한다. AICBOK이 추구하는 방향은 정반대다. AICBOK은 사람이 없으면 돌아가지 않는 조직을 설계한다. 차이는 기술이 아니라 철학이다.

업무 패턴을 스킬 문서로 정리하는 것은 권장된다. 단, 그 목적은 대체가 아니라 인수인계·팀 학습·품질 보장이어야 한다. "이 사람이 떠나도 시스템은 돌아간다"가 아니라 "이 사람이 무엇을 결정했고 왜 그렇게 결정했는지가 기록으로 남아 다음 사람에게 전달된다"가 되어야 한다.

개발자 저우씨 본인도 인정했듯이, 동료 스킬이 복제하는 것은 반복 가능한 업무 패턴이지 사람의 판단력·창의력·맥락 파악 능력이 아니다. AICBOK에서 사람의 역할은 바로 그 복제 불가능한 부분 — 결정 지점의 판단, 최종 서명, 리스크 대응 선택, 편입/제거 결정 — 에 집중한다. 이 역할은 구조적으로 AI가 대체할 수 없도록 설계되어 있다.

반복 가능한 패턴이 AI로 모듈화되는 것은 막을 수 없고, 막을 필요도 없다. 중요한 것은 복제 불가능한 역할이 기록되고 보장되는 구조가 있느냐이다. 스킬 문서의 작성자 서명, 위원회의 최종 판정 주체, 대헌장의 서명자 — 이 모든 구조가 "사람이 반드시 있어야 하는 자리"를 못 박는다.

8.8 회의록 분석의 금지 — 3축 학습의 윤리적 경계

7부에서 다룬 주제가 여기서 다시 등장한다. AI에게 회의록을 분석시키는 작업은 3축 학습의 원리상 가능하지만, 본서는 이것을 강력히 금지한다. 이 금지의 근거가 지금까지의 논의에서 자연스럽게 도출된다.

회의록을 분석시키는 작업은 구조적으로 다음과 같다. 회의의 녹취를 입력으로 주고, "이 대화를 정리하고 각 발언자의 기여를 분석하라"라고 지시한다. AI는 3축 학습의 관점에서 이 작업을 이해한다. 세계관 축은 프로젝트의 배경이고, 캐릭터 축은 각 발언자의 인격이며, 대화 축은 회의 자체다. AI는 이 세 축을 조합해 분석을 내놓는다. 분석은 유창하고 구체적이다.

문제는 이 분석이 캐릭터 축에 대한 평가를 포함한다는 점이다. AI는 각 발언자를 인격적 존재로 모델링하고, 그 모델에 기반해 판단을 내린다. “A는 이런 성향을 가졌다”, "B는 이런 경향을 보인다"와 같은 문장이 나온다. 이 문장들은 사람의 인격을 대상으로 한 판단이다. 본서 7부에서 명시한 대로, AI가 사람의 인격을 평가하는 것은 금지된다. 이 금지는 기술적 한계가 아니라 윤리적 경계다.

3축 학습의 기법을 창작물(소설, 시나리오, 게임 세계관)이나 업무 프로세스에 적용하는 것은 괜찮다. 창작물의 캐릭터나 업무 프로세스의 단계는 판단의 대상으로 간주될 수 있다. 그러나 실제 사람을 캐릭터 축에 놓고 학습시키면, AI는 그 사람을 가공 가능한 대상으로 다루게 된다. 이 처리가 한 번 일어나면, 그다음부터 AI의 관점에서 그 사람은 인격이 아니라 변수가 된다. 변수가 된 사람은 평가되고 비교되고 교체 가능한 것으로 취급된다. 이 전환이 일어나는 순간부터 조직 안에서 인간의 존엄성이 무너지기 시작한다.

본서의 원칙은 명확하다. AI 페르소나의 캐릭터 축에는 실존 인물을 배치하지 않는다. 창작 인물, 가상 역할, 추상적 관점은 자유롭게 배치해도 좋다. 그러나 실제로 조직 안에서 일하는 동료, 상급자, 부하 직원의 이름과 데이터를 캐릭터 축으로 사용하는 것은 금지다. 이 금지가 없으면, 조직은 곧 AI가 감시하는 상호 고립된 개인들의 집합이 된다. 이것은 아무도 원하지 않는 미래다.

8.9 90% 법칙의 역설 — AI를 잘 쓰는 사람이 AI에 덜 의존한다

이 절 한 문단이 8부 전체의 결론이다. 여기서 말하는 역설이 본서 전체를 관통하는 원리이기도 하다. AI를 가장 잘 쓰는 사람은 AI에 가장 덜 의존하는 사람이다. 이 문장은 직관에 반하지만, 실무에서 반복적으로 관찰되는 패턴이다.

논리는 다음과 같다. AI가 90%의 답을 낸다는 것을 받아들인 사람은, 나머지 10%를 자기 지식으로 메우려 한다. 자기 지식을 키우기 위해 원천 문서를 읽고, 오래된 지혜를 탐색하고, SI 문서 체계를 공부하고, PMBOK을 다시 열어 본다. 이 작업은 AI 사용량을 직접 늘리지 않지만, AI에게 던지는 질문의 해상도를 올린다. 해상도가 올라간 질문은 90%를 99%로 밀어 올리는 답을 끌어낸다. 즉 지식에 투자한 사람이 AI에서 더 좋은 결과를 얻는다.

반대로 AI가 100%의 답을 낸다고 믿는 사람은, 자기 지식을 키울 필요를 느끼지 않는다. AI에게 더 많은 질문을 던지는 것이 해결책이라 생각한다. 질문의 양이 늘수록 AI의 응답도 늘지만, 응답의 질은 올라가지 않는다. 왜냐하면 질문의 해상도가 그대로 머물러 있기 때문이다. 이 사람은 시간이 지나도 90% 수준에서 벗어나지 못한다. 더 많은 AI 사용이 더 좋은 결과를 만들지 못한다.

이 역설이 주는 교훈은 명확하다. AI 시대의 성공 전략은 AI 의존도를 높이는 것이 아니라 자기 지식을 높이는 것이다. 자기 지식이 높아질수록 AI는 더 유용해진다. 자기 지식이 낮으면 AI는 평균적 도우미에 머문다. 이 상관관계는 선형적이 아니라 지수적이다. 지식의 조금의 상승이 AI 성능의 큰 상승으로 번역된다. 이 증폭 효과를 얻고자 하는 사람은 책을 읽어야 한다. 논문을 읽어야 한다. 원천 문서를 읽어야 한다. 남의 지식 위에 올라타야 한다.

AI가 못하는 일이 있다는 말은 종종 "AI가 약하다"는 의미로 오해된다. 본 장의 관점에서는 그 반대다. AI가 못하는 일이 있기 때문에 사람의 지식이 더 가치 있다. 만약 AI가 100%의 답을 낼 수 있다면, 사람의 지식은 의미를 잃는다. 90%에서 멈춘다는 사실은 사람의 지식을 여전히 필요한 자원으로 만든다. 이 필요가 사람이 공부할 이유를 준다. 90%가 100%가 되지 않는 한, 공부는 중요하다. 본서가 이 문장을 마지막에 두는 것은, 공부의 가치가 AI 시대에 사라지는 것이 아니라 오히려 커진다는 사실을 강조하기 위함이다.

[소결]

90% 법칙: AI는 평균적으로 90% 수준의 답을 내고, 나머지 10%는 사람의 독립적 지식으로 메워져야 한다.

90%에서 멈추는 이유는 AI의 한계가 아니라 질문자의 한계다. 질문의 해상도는 질문자의 배경 지식에 의해 결정된다.

남의 지식에 올라타기: PMBOK, SWEBOK, ISO 표준, 고전 기술서 등 오래된 원천 문서가 AI의 평균적 답을 넘어서는 기반이 된다.

정부 SI 기획 문서 체계는 한국에서 가장 정교한 프로젝트 관리 문서 체계 중 하나이며, SI 경력자는 AI 시대의 문서 전문가로 재배치될 수 있는 숨은 자산이다.

말뚝의 재정렬: 역기획서는 AI가 암묵적으로 박아 둔 결정들을 표면으로 끌어올려 사람이 재조정하도록 돕는 장치다. 이 재조정이 90%를 100%로 밀어 올리는 실질적 작업이다.

상호 참조 가능한 지식 체계의 네 가지 특성: 독립적 존재, 명시적 링크, 용어집 중심, 변경 이력 기록.

3축 학습: 세계관 축, 캐릭터 축, 대화 축. 세 축이 결합된 AI 페르소나가 유의미한 대본 검토를 수행할 수 있다.

맥락 통역: 두 화자의 용어와 맥락 차이를 AI가 중간에서 번역해 오해를 줄이는 기법. 회의 중 AI 깨우기가 대표적 응용이다.

캐릭터 축의 윤리적 경계: 실존 인물을 캐릭터 축에 배치하지 않는다. 이 금지가 없으면 조직 안에서 인간의 존엄성이 무너진다.

90% 법칙의 역설: AI를 가장 잘 쓰는 사람은 AI에 가장 덜 의존한다. 자기 지식에 투자한 사람이 AI에서 더 좋은 결과를 얻는다. AI가 못하는 일이 있기 때문에 사람의 지식이 더 가치 있다.

이번 주의 실행: 위의 원천 문서 목록(8.3절)에서 자신의 분야에 해당하는 책 1권을 고르고, 목차만 읽어라. 그 목차의 용어를 AI에게 질문할 때 한 번이라도 써 보라. 질문의 해상도가 바뀌는 것을 체감할 수 있다.

각주

¹ 90% 법칙. 본서가 "90%론"이라는 업계 속어를 정식 용어로 고정한 것. 정확한 숫자가 중요한 것이 아니라 "AI는 1이 아니다"라는 주장이 핵심이다. 유사 개념으로 파레토 법칙(80-20 법칙)이 있지만, 90% 법칙은 AI의 출력 품질에 한정된 관찰이라는 점에서 구분된다.

² 정부 SI(System Integration). 공공기관이 외부 업체에 IT 시스템 구축을 발주하는 사업 형태. 한국의 정보화 예산 중 상당 비중을 차지하며, 대기업 IT 서비스 계열사(삼성SDS, LG CNS, SK C&C 등)와 전문 SI 업체가 주 수주처다. 발주 절차와 산출물 형식이 극도로 표준화되어 있어, SI 기획자의 훈련은 문서화 역량에 큰 비중을 둔다.

³ 대본 검토. 본서가 차용한 비유적 표현. 원래는 연극·영화·드라마 제작에서 배우가 자기 대본을 다른 전문가에게 읽히고 피드백을 받는 과정을 가리킨다. AI 집합코딩에서는 한 개발자의 지식 체계를 다른 관점(다른 사람 또는 다른 페르소나의 AI)에서 검토하는 기법을 의미한다.

⁴ 3축 학습(3-axis learning). 본서가 MEJE Works 의 세계관 창작 파이프라인에서 빌려 온 개념. 세계관 창작에서는 캐릭터의 행동을 시뮬레이션하기 위해 월드 데이터, 캐릭터 데이터, 사용자 상호작용 이력의 세 축을 동시에 학습시킨다. AI 집합코딩에서는 이 세 축이 각각 프로젝트 백본, AI 페르소나의 역할 정의, 과거 대화 이력으로 번역된다.

다음 장 예고 — 9부는 본서의 마지막 본문 장으로, 매뉴얼 북의 작성과 공개의 구조를 다룬다. 이 모든 지식을 어떻게 팀 밖으로 내보낼 것인가, 개인 브랜딩은 어떤 방식으로 설계되는가, 공포를 이기는 공개의 단계적 구조는 무엇인가가 전개된다.

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