통제면·공통기반·적용을 나눠 위임한다

같은 어댑터를 세 번 만든 분기점

한 B2B SaaS 운영팀의 비용 리뷰에서 같은 비용 항목이 세 줄로 잡혀 있었다. 세 팀이 같은 결재 API 위에 에이전트용 어댑터를 따로 만들어 운영했다. 셋 다 잘 돌았지만 인증을 따로 붙였고, 비용 태그를 제각각 달았고, 감사 로그 포맷이 달랐다. 그래서 “이 결재 흐름에 AI가 몇 번 개입했고 얼마 들었나”라는 한 줄 질문에 누구도 답하지 못했다 — 세 팀의 숫자가 서로 다른 테이블을 참조했기 때문이다.

비싼 건 중복 구현 자체가 아니라 중복이 만든 분산이다. 비용이 흩어지니 단위 비용을 못 잡고, 감사 로그가 세 포맷이니 추적이 끊기고, 개입 지점이 세 군데니 위험을 한 화면에서 못 본다. 리더가 “각 팀이 알아서 만들라”고 위임한 순간 통제면과 공통기반까지 함께 위임됐다 — 위임하면 안 되는 것을 위임한 것이다.

이 장은 통제면·플랫폼·적용을 어떻게 구현하는지는 다루지 않는다. 그건 엔지니어링의 일이고 가장 빨리 낡는 영역이다(프롤로그). 이 장이 다루는 것은 하나다 — 3계층 중 무엇을 위임하고, 무엇을 신호로 쥐어야 중복 구현과 비용 분산을 막는가. 위험·자율성은 16장이, RACI·Policy as Code는 17장이 다룬다.

핵심 프레임: 3계층은 ‘누가 만드나’가 아니라 ‘몇 번 만드나’의 경계다

세 계층으로 나누는 이유는 조직도가 아니라 **무엇을 한 번만 만들고(공통), 무엇을 영역마다 만드는지(적용)**를 가르기 위해서다.

계층	한 줄 정의	리더의 질문	잘못 위임하면
통제면(Control Plane)	모든 운영 AI가 통과하는 정책·승인·감사·비용의 단일 관문	“모든 AI가 이 관문을 통과하는가”	팀마다 다른 통제 → 감사·비용 분산, 우회 발생
공통기반(Platform)	에이전트가 시스템·데이터·도구를 읽게 하는 공통 실행 기반	“이 기반을 팀이 또 만들고 있지 않은가”	같은 어댑터·맥락(연결) 중복 → 운영 고정비 누적
적용(Applications)	실제 업무·제품에 붙는 영역별 산출	“이건 영역마다 다른가, 공통으로 빼야 하나”	공통으로 뺄 것을 영역마다 → 자산 안 쌓임

원칙은 단순하다. 통제면과 공통기반은 한 번만 만든다. 적용만 영역마다 만든다. 어기면 ‘같은 어댑터 세 번’이 반복된다. 그래서 리더가 쥘 신호도 계층마다 다르다 — 통제면은 ‘통과했는가’, 공통기반은 ‘또 만들고 있지 않은가’, 적용은 ‘공통으로 빼야 하는가’다.

이 장 전체는 두 문장으로 압축된다.

모든 운영 AI는 공통 통제면을 통과한다. 예외는 통제면을 우회하는 게 아니라 통제면 안에 ‘예외’로 기록된다.
팀별 중복 구현을 금지한다. 통제면·공통기반을 또 만드는 것은 비용 절감이 아니라 비용 분산이다.

나머지는 이 두 줄을 회의에서 판정 가능하게 만드는 도구다.

의사결정 트리: 새 AI 과제가 올라왔을 때

새 AX 과제가 올라오면 구현 세부를 보기 전에 계층 경계부터 판정한다. “어느 계층의 일인가”를 먼저 가르는 트리다.

[새 AI 과제 / 자동화 제안]
   │
   ▼
Q1. 이 과제는 공통 통제면(정책·승인·감사·비용)을
    통과하도록 설계됐는가?
   ├─ 아니오 ──▶ 반려. "통제면 통과"가 없는 운영 AI는 승인하지 않는다.
   └─ 예
        │
        ▼
Q2. 이 과제가 쓰는 실행 기반(어댑터·맥락(연결)·도구)을
    다른 팀이 이미 만들었거나 만들고 있는가?
   ├─ 예 ──▶ 신규 구현 금지. 공통기반을 재사용/등록(15장). 중복이면 통합 지시.
   └─ 아니오
        │
        ▼
Q3. 이 기반이 한 영역에만 쓰이는가, 여러 영역이 쓸 것인가?
   ├─ 여러 영역 ──▶ 공통기반으로 빼서 한 번만 만든다(카탈로그 등록).
   └─ 한 영역
        │
        ▼
Q4. 이 적용은 Skill·MCP·기존 도구로 충분한가?
   ├─ 예 ──▶ 가볍게 붙인다(풀스택 금지, 6장 Anti-Slop).
   └─ 아니오 ──▶ 비로소 영역별 별도 구현 검토(통제면 통과는 여전히 필수).

트리의 순서가 곧 우선순위다. 통제면 통과(Q1)가 맨 위인 것은 의도된 설계다. 가치 있는 과제라도 감사·비용·승인이 통제면 밖에 있으면 자산이 아니라 부채다. Q2~Q3는 ‘같은 어댑터 세 번’을 막는 게이트, Q4는 6장 Anti-Slop 판정을 계층 트리 안으로 가져온 것이다.

단계별 적용: 계층별로 리더가 쥘 신호 한 줄

각 계층의 구현은 위임한다. 리더가 쥐는 것은 계층마다 몇 개의 신호다.

통제면 — 쥘 것은 ‘비용·감사·개입’ 세 신호뿐

구현 세부(정책 엔진·게이트웨이·승인 큐의 기술 스택)는 전적으로 위임한다. 리더는 통제면이 세 신호를 만들어 내는지만 본다.

신호	리더가 보는 한 줄	없으면
비용 신호	모델·API·구독 비용이 업무 단위로 태깅되는가	단위 비용 산출 불가 → 11·12장 게이트 작동 안 함
감사 신호	“누가·무엇을·언제·왜” 실행했는지 업무 단위 ID로 추적되는가	사고 시 추적 단절, 외부 감사 대응 불가
개입 신호	위험 실행을 사전 차단·승인 큐·kill switch로 멈출 수 있는가	16장 자율성 레벨이 통제면에 박히지 않음

세 신호를 묶는 핵심은 업무 단위 ID다. 비용·감사·승인·완료 이벤트가 같은 ID로 묶이지 않으면 통제면은 로그만 쌓고 어떤 질문에도 답하지 못한다. 리더가 요구할 한 문장 — “이 AI 실행의 비용·감사·완료가 같은 ID로 연결되는가?” 이 업무 단위는 프롤로그가 채택·비용 사이 공백을 메우려 세운 단위다. 9장 leverage 측정과 11장 총비용이 같은 단위 위에서 작동한다.

게이트웨이·정책 엔진·관측 도구의 제품명은 빠르게 교체되니 본문에 박지 않는다. 오래 남는 자산은 ‘비용·감사·개입 세 신호를 업무 단위 ID로 묶는다’는 골격이다.

공통기반 — 쥘 것은 ‘중복 여부’와 ‘재사용 여부’

공통기반은 에이전트가 기존 시스템·DB·문서·업무 규칙을 안전하게 읽고 실행하게 만드는 계약이다(7·15장). 새 화면을 만드는 일이 아니라, 기존 리소스를 에이전트가 읽을 계약으로 바꾸는 일이 먼저다.

신호	리더가 보는 한 줄	없으면
중복 신호	이 어댑터·맥락(연결)·도구를 다른 팀이 이미 만들었는가	같은 기반 N번 구현 → 운영 고정비 N배
재사용 신호	한 번 만든 기반이 카탈로그에 등록돼 다음 팀이 찾을 수 있는가	자산이 안 쌓이고 매번 재발명

공통기반 위임의 핵심은 ‘최소 카탈로그’를 함께 요구하는 것이다. “무엇이 이미 있는지 한 곳에서 검색 가능하게 하라”를 조건으로 건다. 카탈로그 없는 위임은 동료가 만든 걸 모른 채 재발명한다. 15장의 Skill·MCP 재사용은 이 카탈로그가 전제다.

적용 — 쥘 것은 ‘공통으로 빼야 하는가’

적용은 영역마다 다르고, 그래서 영역 리더에게 위임한다(13·14장). 리더가 쥘 신호는 하나다 — “이 적용 안에 공통으로 빼야 할 조각이 숨어 있지 않은가.” 적용에서 같은 조각이 두 번 보이면 공통기반으로 올린다 — 이것이 중복을 사후에 잡는 단 하나의 규칙이다.

체크리스트: 새 운영 AI를 승인하기 전에

회의에서 한 장으로 쓰는 게이트다. 승인자에게는 통과·반려 기준, 실무자에게는 미리 채울 칸이다.

통제면 통과 명시 — 이 과제의 정책·승인·감사·비용이 공통 통제면을 통과한다고 제안서에 적혀 있다.
업무 단위 ID — 비용·감사·완료가 같은 ID로 연결된다(업무 단위 ID + 비용 태그를 최소 필드로).
개입 지점 — 위험 실행에 사전 승인·차단·kill switch가 어디 붙는지 명시됐다(16장 자율성 레벨).
중복 점검 — 쓰는 어댑터·맥락(연결)·도구를 다른 팀이 만들었는지 카탈로그에서 확인했다.
공통·적용 판정 — 여러 영역이 쓸 기반이면 공통기반으로 빼기로 했다.
경량 우선 — Skill·MCP·기존 도구로 안 되는 이유가 적혀 있다(풀스택 금지, 6장).
재사용 등록 — 새로 만든 기반은 카탈로그에 등록해 다음 팀이 찾게 한다.

앞의 세 개(통제면·업무 단위 ID·개입 지점)는 없으면 반려 — 통제 항목이다. 나머지 넷은 중복·과잉을 막는 비용 항목이다.

흔한 실패모드

계층 경계가 무너질 때 회의에서 들리는 신호로 정리한다. 각 모드 끝의 레드플래그는 “이 말이 나오면 의심하라”는 판별구다.

1 — 통제면 우회. 게이트웨이를 안 거치고 직접 붙여 비용이 안 잡히고 추적이 끊기고 감사에서 미등록으로 적발된다. 레드플래그: “작은 실험이라 따로 빠르게 붙였습니다.” 차단: Q1 + 체크리스트 1번. 작은 실험도 패스트트랙으로 통과한다 — 우회는 없다(17장).

2 — 통제면 중복 구현. 각 팀이 자기 버전의 승인 큐·비용 태깅·감사 로그를 따로 만들어, 같은 질문에 팀마다 다른 숫자가 나온다. 레드플래그: 팀별 대시보드는 많은데 전사 단위 질문에 아무도 답 못 한다. 차단: “통제면은 한 번만” + Q1.

3 — 공통기반 재발명. 다른 팀의 어댑터·맥락(연결)을 모른 채 똑같이 만들어 운영 고정비가 팀 수만큼 누적되고 유지보수 주체가 불명해진다. 레드플래그: “우리가 직접 만드는 게 빨라요”가 중복 점검 없이 나온다. 차단: Q2 + 카탈로그 + 15장.

4 — 적용을 공통으로 못 올림. 둘째·셋째 팀이 같은 조각을 반복하는데 공통기반으로 승격하지 않아, 영역마다 미묘하게 다른 N개 버전이 생겨 통합 불가가 된다. 레드플래그: 같은 기능이 영역별로 조금씩 다르게 N번 등장한다. 차단: 적용 신호 + Q3.

5 — 위임 없는 통제. 반대 방향의 실패다. 리더가 구현 세부까지 들여다봐 거버넌스가 가속이 아니라 병목이 된다(프롤로그). 레드플래그: 리더 리뷰에서 게이트웨이 기술 스택·스키마 설계가 논의된다. 차단: “구현은 위임, 리더는 비용·감사·개입 신호만”.

6 — 측정 없이 통제면 선언. 선언만 하고 업무 단위 ID·비용 태그가 안 박혀, 로그는 쌓이는데 비용·감사 질문에 못 답하는 이름만 통제면. 레드플래그: 통제면은 있다는데 “이 업무에 AI 비용 얼마 들었나”에 답이 안 나온다. 차단: 체크리스트 2번(업무 단위 ID).

Before/After: 같은 결재 흐름, 두 갈래의 경계 설계

예를 들어 한 채용 플랫폼 기업에서는 여러 운영팀이 각자 사내 결재 시스템에 AI 보조를 붙이려 했다. 같은 결재 API를 세 팀이 동시에 본다.

Before — 경계 없이 각 팀이 알아서. “각 팀이 알아서 빠르게 붙이라”고 위임하면 통제면도 공통기반도 함께 위임된다. 결과는 도입 서사 그대로다.

After — 계층 트리를 거친 경계 설계. 같은 과제를 트리에 넣는다. Q1 통제면 통과? 세 팀 모두 통과하도록 못 박는다. Q2 같은 어댑터? 그렇다 → 신규 구현 금지, 공통기반 한 번만. Q3 여러 영역? 예 → 공통기반으로 빼서 카탈로그 등록. Q4 적용부는 Skill·MCP로 충분 → 가볍게. 두 갈래의 차이는 아래 한 장이다.

구분	Before (경계 없음)	After (계층 트리)
통제면	팀마다 따로	공통 1회, 업무 단위 ID
어댑터(공통기반)	3중 구현	1회 구현 + 카탈로그
비용	세 곳 분산, 합산 불가	단위 비용 한 숫자
감사	3포맷, 추적 단절	단일 추적
리더 보고	“적용했다”	“단위 비용·감사가 한 장부”

두 갈래는 같은 결재 흐름, 같은 AI 역량에서 출발했다. 갈린 지점은 하나 — 위임할 때 통제면·공통기반을 함께 위임했는가, 신호로 쥐었는가다.

리더가 승인·요구할 신호

거버넌스 세부는 16·17장에, 위임의 RACI·3계층 신호는 19장에 있다. 여기서는 회의에서 쓸 신호만 남긴다.

요구할 것 (없으면 검토 테이블에 올리지 않는다)

‘모든 운영 AI는 공통 통제면을 통과한다’ 원칙을 제안서가 따르는가. 통제면 밖 운영 AI는 승인하지 않는다(작은 실험도 패스트트랙으로 통과, 우회는 불가).

비용·감사·완료가 같은 업무 단위 ID로 묶이는가(업무 단위 ID + 비용 태그). 이것이 통제면 통과의 실질 조건이다.

쓰는 어댑터·맥락(연결)·도구가 중복 점검을 거쳤는가. 있으면 재사용, 없으면 카탈로그 등록.

반려할 것

“작고 급해서 통제면 밖에서 빠르게”라는 우회 제안.

통제면(승인 큐·비용 태깅·감사 로그)을 팀별로 또 만드는 제안.

중복 점검 없이 공통기반(어댑터·맥락(연결))을 새로 만들겠다는 제안.

여러 영역이 쓸 기반인데 한 영역 안에 가두는 제안.

위임할 것 (리더는 신호만 쥔다)

통제면 구현 세부 — 정책 엔진·게이트웨이·승인 큐의 기술 스택. 리더는 비용·감사·개입 세 신호만 본다.

공통기반 구현 세부 — 어댑터·맥락(연결)·런타임 구현. 리더는 중복·재사용 두 신호만 본다.

적용 구현 세부 — 영역별 산출. 리더는 “공통으로 뺄 조각이 있는가” 하나만 본다.

이 장의 요약

3계층은 조직도가 아니라 ‘몇 번 만드나’의 경계다 — 통제면·공통기반은 한 번만, 적용만 영역마다. 두 줄로 압축된다: 모든 운영 AI는 공통 통제면을 통과한다 / 팀별 중복 구현을 금지한다.
새 과제는 구현 전에 계층 트리(Q1 통제면 통과 → Q2 중복 → Q3 공통·적용 → Q4 경량)로 판정한다. Q1이 맨 위인 것은 의도된 설계다.
리더가 쥘 신호는 계층마다 다르다 — 통제면: 비용·감사·개입(업무 단위 ID로 묶임) / 공통기반: 중복·재사용 / 적용: 공통으로 뺄 조각. 구현 세부는 전부 위임한다. 통제면 통과의 실질 조건은 선언이 아니라 업무 단위 ID다.
위임할 때 통제면·공통기반을 함께 위임하면 ‘같은 어댑터 세 번’이 반복된다. 위임하되 신호는 쥔다 — 그것이 이 장의 한 줄이다.