4부 · AI 위원회 — 문서가 문서를 검수하는 조직

Apr 19. 2026 brunch_membership's

본 장의 질문. 두 장의 문서가 작성되었다. 이제 누가 그것을 검수하는가. 사람은 읽는 속도에서 이미 추월당했고, 같은 AI가 자기 작업을 검수하면 같은 오류를 반복한다. 남는 길은 독립된 AI 에이전트의 집합이 상호 검수하는 구조뿐이다. 이 구조를 본서는 AI 위원회라 부른다. 대응 규약: AICBOK P.3(이중 문서), P.4(위원회 이중 검토), F.4(감시·통제), F.5(종료), D.1(거버넌스)

4.1 위원회라는 오래된 이름

위원회(Committee)¹라는 단어는 현대 조직 이론에서 자주 부정적 뉘앙스로 쓰인다. “위원회에 맡기면 결정이 나지 않는다”, “위원회는 의사결정을 회피하기 위한 장치다”, "위원회는 책임을 분산시켜 아무도 책임지지 않게 만든다"는 식의 비판이 오래전부터 반복되어 왔다. 이 비판에는 근거가 있다. 실제로 많은 조직의 위원회는 의사결정 지연의 대명사였다. 그러나 위원회라는 제도 자체가 결함이었던 것은 아니다. 결함이었던 것은 위원회의 작동 조건을 잘못 설계한 운영 방식이다.

위원회가 제대로 작동하려면 세 가지 조건이 필요하다.

첫째, 명확한 판정 기준. 위원회 구성원이 무엇을 기준으로 찬반을 판정할지가 사전에 정의되어 있지 않으면, 회의는 각자의 주관적 선호가 충돌하는 자리가 된다.

둘째, 구성원의 독립성. 위원회 구성원이 서로의 눈치를 보거나 상급자의 결정에 끌려가는 구조라면, 위원회의 결정은 사실상 한 사람의 결정과 다르지 않다.

셋째, 절차의 속도. 위원회가 한 건의 안건을 처리하는 데 주 단위 이상의 시간이 걸리면, 위원회는 병목이 된다. 빠른 의사결정이 필요한 시스템에서는 기능을 상실한다.

전통적 조직에서 이 세 조건을 동시에 만족시키는 위원회는 매우 드물었다. 명확한 판정 기준을 세워도 사람의 주관이 개입해 흔들렸고, 구성원의 독립성은 조직 정치 앞에서 쉽게 무너졌으며, 절차의 속도는 인간의 회의 시간이라는 물리적 제약에 묶였다. 그래서 위원회라는 제도는 이상론으로 남고, 실제로는 형식적 의례로 전락했다.

AI 시대는 이 세 조건을 기술적으로 만족시킬 수 있게 한다. 판정 기준은 스킬 문서와 역기획서가 제공한다. 구성원의 독립성은 서로 다른 에이전트 인스턴스로 확보된다. 절차의 속도는 분 단위, 때로는 초 단위로 떨어진다. 이 세 조건이 동시에 만족되는 순간, 위원회는 이상에서 현실로 내려온다. 본서가 "위원회"라는 오래된 이름을 AI 맥락에 재사용하는 이유가 여기에 있다. 이름을 바꾸지 않는 것은 조직 이론의 전통과 연속성을 유지하기 위함이다.

위원회의 정의를 한 문장으로 압축하면 다음과 같다.

AI 위원회는 스킬 문서와 역기획서를 입력으로 받아, 두 문서 사이의 모순·불일치·권리 침해·용어 충돌·안전성 위반을 판정하고, 그 결과를 사람이 읽을 수 있는 보고서로 내보내는 독립된 AI 에이전트의 집합이다.

이 정의가 본 장 전체의 골격이다. 이하에서 이 골격을 조금씩 살을 붙여 설명한다.

4.2 위원회의 본질 — 포괄적 도큐먼팅의 담당자

위원회가 하는 일을 한 단어로 요약하면 포괄적 도큐먼팅(comprehensive documenting) 이다. 포괄적이라는 수식어가 중요하다. 위원회는 단순히 문서를 작성하는 사람이 아니라, 모든 문서를 묶어 일관된 전체로 유지하는 기능을 수행한다.

예를 들어 설명한다. 한 팀이 5개의 서로 다른 기능(A, B, C, D, E)을 동시에 개발하고 있다고 가정한다. 각 기능마다 스킬 문서와 역기획서가 한 쌍씩 만들어진다. 5개 기능에서 총 10개의 문서가 생성된다. 개별 기능을 각각 검수하는 것은 어렵지 않다. 그러나 이 5개 기능이 서로 어떻게 얽히는가는 별도의 문제다. 기능 A가 공유 자원을 읽는 방식이 기능 C의 쓰기 방식과 충돌할 수 있다. 기능 B의 인터페이스가 기능 D의 기대와 어긋날 수 있다. 이 충돌은 개별 문서를 따로 읽어서는 발견되지 않는다. 10개의 문서를 모두 가지고 있고, 그 사이의 관계를 읽어낼 수 있는 주체만이 이 충돌을 탐지할 수 있다.

이 주체가 위원회다. 위원회는 특정 기능의 상세한 구현을 들여다보지 않는다. 위원회는 기능들 사이의 경계선을 들여다본다. 경계선이 깨끗하게 유지되고 있는가, 한 기능이 다른 기능의 영역을 침범하지 않는가, 공유 자원의 사용 규약이 일관되게 지켜지는가. 이 질문들에 답하는 것이 위원회의 일이다.

왜 개별 개발자나 개별 AI가 이 일을 할 수 없는가? 이유는 간단하다. 개별 개발자는 자신의 기능에만 집중하고 있어 전체 그림을 보지 않는다. 개별 AI도 마찬가지다. 기능 A를 구현하는 AI는 기능 A의 맥락만 컨텍스트에 가지고 있고, 기능 C의 존재 자체를 모를 수 있다. 전체 그림을 보는 주체를 명시적으로 배치하지 않으면 아무도 전체 그림을 보지 않는다. 이 원칙이 위원회의 존재 이유다.

PMBOK 8판의 거버넌스 수행 영역(Governance Performance Domain)²은 이 원칙을 다른 언어로 표현한다. 거버넌스는 "프로젝트 가치 창출이 조직의 목적에 부합하도록 보장하는 기준과 메커니즘"으로 정의되며, 구체적으로는 의사결정 권한의 명확한 배치와 경계 간 조율을 포함한다. AICBOK의 위원회는 PMBOK 8판의 거버넌스 개념을 AI 스케일로 구현한 형태다. 이름은 다르지만 기능은 일치한다.

[배경] 위원회와 거버넌스의 어원적 일치 "Committee"와 "Governance"는 현대 조직 이론에서 종종 구분되어 쓰이지만, 라틴어와 프랑스어 어원을 추적하면 둘의 거리는 가깝다. "Committee"는 라틴어 committere(맡기다, 위임하다)에서 왔고, "Governance"는 라틴어 gubernare(조종하다, 방향을 잡다)에서 왔다. 전자는 "맡겨진 일을 수행하는 집단"을, 후자는 "방향을 결정하는 집단"을 가리킨다. 본서의 AI 위원회는 두 의미를 모두 담는다. 스킬 문서와 역기획서의 검수를 위임받고(committee), 동시에 프로젝트의 경계 조율을 통해 방향을 유지한다(governance).

4.2.1 위원회가 없을 때 — 실제 관찰되는 사고

위원회의 필요성을 설명하기 전에 위원회가 없으면 실제로 무슨 일이 벌어지는지를 한 건만 든다.

한 팀에서 모듈 A(인증)와 모듈 C(결제)가 동시에 개발되고 있었다. A는 사용자 세션을 Redis에 저장하고, C는 결제 상태를 같은 Redis 인스턴스에 저장했다. 두 모듈의 키 네이밍 규칙이 달랐다. A는 session:{userId}, C는{userId}:payment. 키가 겹치지는 않았지만, C가 FLUSHDB를 주기적으로 호출하는 캐시 정리 스크립트를 돌리고 있었다. 결과: 결제 캐시 정리 시 인증 세션이 함께 날아갔다. 사용자 수백 명이 동시에 로그아웃됐다.

두 달간 아무도 원인을 몰랐을 수 있다. 각 모듈의 스킬 문서와 역기획서를 교차 비교하는 위원회가 있었다면, "두 모듈이 동일 Redis 인스턴스를 사용한다"는 사실이 자원 접근 침해로 첫 제출에서 탐지됐을 것이다. 이 한 건의 사고가 위원회의 존재 이유를 설명한다.

4.3 유일한 검수 기준 — 다른 모듈의 권리 침해

위원회의 검수 기준은 단 하나로 압축될 수 있다. 다른 모듈의 권리를 침해하지 않는가. 이 한 줄이 위원회의 모든 판정을 관통한다. 이 기준이 한 줄로 압축된다는 사실이 왜 중요한지를 설명한다.

복잡한 시스템에서 검수 기준이 여러 개가 되면 두 가지 문제가 발생한다. 첫째, 기준들 사이에 충돌이 생긴다. "안전성을 최대화하라"와 "성능을 최대화하라"는 많은 경우 동시에 만족될 수 없다. 이 충돌을 해결하려면 우선순위를 설정해야 하는데, 우선순위는 상황마다 달라질 수 있어 일반화하기 어렵다. 둘째, 기준이 여러 개면 판정의 일관성이 흔들린다. 같은 입력에 대해 서로 다른 기준이 서로 다른 답을 내면, 위원회의 결정은 어느 기준을 먼저 적용했느냐에 따라 달라진다. 이 변동성은 신뢰할 수 없는 시스템의 표식이다.

본서의 AI 위원회는 이 문제를 한 줄의 검수 기준으로 해결한다. "다른 모듈의 권리를 침해하지 않는가"라는 질문은 기능적 정합성에 초점을 맞춘다. 성능, 안전성, 가독성, 유지보수성 같은 다른 품질 지표는 각 모듈의 내부 기준으로 관리되고, 위원회는 경계만 본다. 이 분리는 매우 중요하다. 위원회가 모든 품질 지표를 한꺼번에 판정하려 들면 판정의 속도와 일관성을 모두 잃는다. 경계만 본다는 단순한 원칙이 위원회를 실제로 작동 가능하게 만든다.

"권리 침해"라는 표현이 추상적이므로 구체적으로 풀어본다. 다음 네 가지가 권리 침해의 대표적 사례다.

① 네임스페이스 침해 기능 A가 생성한 함수·클래스·변수의 이름이 기능 B의 이름과 충돌하는 경우. 전역 네임스페이스를 공유하는 언어(Python의 모듈 수준 변수, JavaScript의 window 객체)에서 자주 발생한다. 스킬 문서와 역기획서에 명시된 이름 규칙을 위원회가 대조해 충돌을 탐지한다.

② 자원 접근 침해 기능 A가 기능 B의 전용 자원(파일, 데이터베이스 테이블, API 엔드포인트)에 직접 접근하는 경우. 권한 경계가 명시되어 있다면 위원회는 이 경계를 검사할 수 있다. 스킬 문서에 "이 작업은 X 디렉터리만 수정한다"라고 명시되어 있고, 역기획서에 "기능은 Y 디렉터리의 파일을 생성한다"라고 적혀 있다면, 이 불일치가 자원 접근 침해의 신호다.

③ 책임 영역 침해 기능 A가 기능 B가 담당하는 로직을 중복 구현하는 경우. 같은 기능이 두 곳에 존재하면 둘 중 하나가 갱신될 때 다른 하나가 뒤처지고, 결과적으로 시스템에 유령 버그가 생긴다. 위원회는 스킬 문서와 역기획서의 기능 목록을 교차 비교해 중복 구현을 탐지한다.

④ 약속된 계약의 위반 기능 A가 외부에 노출한 인터페이스(함수 시그니처, API 엔드포인트, 이벤트 포맷)가 이전 버전과 호환되지 않는 경우. 인터페이스의 계약이 깨지면 그것을 사용하던 다른 기능이 모두 깨진다. 위원회는 버전 간 인터페이스 비교를 수행해 호환성 위반을 탐지한다.

이 네 가지 유형은 PMBOK 8판의 통합 변경 통제(Perform Integrated Change Control) 프로세스가 다루는 변경 영향 분석의 하위 항목과 거의 일치한다. 전통적으로 이 분석은 변경 자문 위원회(CAB, Change Advisory Board)³의 인간 구성원이 수행했고, 한 건의 변경을 분석하는 데 며칠이 걸렸다. AI 위원회는 같은 분석을 분 단위로 수행한다. 이것이 AI 시대에 형상 관리와 변경 통제가 처음으로 교과서대로 작동하는 이유다.

4.4 구성과 역할 분담 — 위원장, 검수자, 서기

AI 위원회는 단일 에이전트가 아니다. 여러 에이전트가 역할을 분담하는 조직이다. 최소 구성은 세 가지 역할을 포함한다. 이 구성은 전통적 위원회 운영의 기본 형태(위원장·위원·서기)를 차용한 것이다.

① 위원장 에이전트 (Chair Agent) 위원회의 전체 절차를 조율하는 역할. 안건을 접수하고, 검수자에게 분배하고, 검수 결과를 종합하고, 최종 보고서를 작성한다. 위원장은 스킬 문서와 역기획서의 전체 구조를 먼저 스캔해 검수의 우선순위를 결정한다. 우선순위가 높은 영역부터 검수자에게 배분되며, 시간이 제한적일 경우 낮은 우선순위는 다음 순회로 미뤄진다. 위원장은 또한 검수자 사이의 의견 충돌이 발생했을 때 최종 판정을 내리는 권한을 가진다. 이 권한은 위원장이 가장 고성능 모델로 운영되어야 하는 이유다.