파일럿 하나에 서버가 붙던 날
한 파일럿 회고에서 운영비 항목을 읽다 멈췄다. 제안서에 적힌 일은 “반복 보고서 초안을 자동으로 만든다”였다. 그런데 청구 항목에는 보고서가 아니라 인프라가 줄지어 있었다. 전용 서버, 배포 파이프라인, 로그인 인증, 모니터링, 그것들을 돌보는 담당자의 시간. 정작 보고서 초안은 기존 협업 도구에 프롬프트 한 묶음을 붙였어도 나올 일이었다.
직접 여러 과제를 폐기해보며 확인했다. AX 비용이 새는 가장 흔한 구멍은 모델도 토큰도 아니라 **“가볍게 끝낼 일을 무겁게 키운 결정”**이다. Skill·MCP·기존 도구로 충분한 일을 풀스택 앱으로 올리는 순간, 비용 절감 과제는 운영 고정비로 바뀐다. 한 번 붙은 서버·인증·모니터링은 효과가 없어도 청구서에 남는다.
그래서 AX는 “누구나 AI 도구를 만들 수 있게 하는 일”이 아니라 쓰지 않을 도구, 중복된 자동화, 검증되지 않은 업무 흐름이 늘지 않게 막는 운영 체계다(1장 참조). 속도를 내려면 오히려 만들기 전에 멈출 기준이 필요하다.
5장은 6분류 트리로 “무엇을 재설계할지”를 판정했다(5장 참조). 6장은 “자동화한다”가 정해졌을 때 **“어떤 무게로 만들 것인가, 아예 만들지 말 것인가”**를 묻는다. 5장이 일감의 정체를, 6장이 구현의 무게를 정한다. 이 장은 세 가지를 다룬다. 만들기 전 통과할 9개 질문, 효과 없는 것을 멈추는 30일 폐기 기준, 무거운 것부터 잡지 않는 4단계 구현 선택이다.
핵심 관점: 슬롭(slop)은 문장이 허술한 게 아니라 쓰임이 없는 것이다
조직 관점의 슬롭은 “AI가 만든 문장이 어설프다”보다 넓다. 만들기는 쉬워졌지만 쓰임·책임·비용·폐기 기준이 없는 AI 산출물 전체가 슬롭이다. 잘 쓴 문장으로 채운 대시보드라도 아무도 안 쓰고 비용만 발생하면 슬롭이다.
위험한 이유는 품질이 낮아서가 아니라 비용이 조용히 누적되기 때문이다. 만든 직후엔 데모도 돌고 화면도 멀끔하다. 비용은 그다음부터 쌓인다. 비용을 만드는 경로는 여섯 가지다.
| 현상 | 겉으로 보이는 모습 | 실제 비용 |
|---|---|---|
| 중복 도구 | 팀마다 비슷한 요약봇·검색봇·스크립트를 만든다 | 구독·API·유지보수·보안 검토가 중복된다 |
| 사용률 없는 자동화 | 데모는 되지만 실제 업무에서 안 쓴다 | 만든 사람의 시간과 운영 인프라가 남는다 |
| 평가 없는 업무 흐름 | 맞는지 틀린지 확인할 기준이 없다 | 재작업·검토 시간·업무 오류가 늘어난다 |
| 권한 없는 연결 | API·DB·문서 연결이 임의로 늘어난다 | 보안 사고·감사 대응·권한 정리 비용이 커진다 |
| 풀스택 과잉 구현 | Skill·MCP·기존 도구로 될 일을 별도 앱으로 만든다 | 서버·배포·인증·모니터링·보안 검토·운영 담당이 새로 필요해진다 |
| 폐기 없는 파일럿 | 중단 결정 없이 계속 유지된다 | 기술부채와 고정비가 누적된다 |
왼쪽은 회의에서 칭찬받기 쉽고, 오른쪽은 회고에서야 드러난다. 거버넌스가 추진보다 늦으면 각 조직이 룰 없이 같은 인프라를 중복 개발하고, 동료가 만든 것을 모른 채 재발명한다.
핵심은 활용량은 착수 조건이 아니다(1장 참조). “수요 검증을 통과했고 중복이 없는가”가 착수 조건이어야 한다. 이 장의 게이트는 그 조건을 회의에서 강제한다.
구현 방식 선택: 가벼운 것부터 4단계
재설계 분류가 끝났다면 구현은 처음부터 무겁게 잡지 않는다. 아래 순서로, 위에서부터 막힐 때만 한 단계씩 내려가고 풀리면 멈춘다. 곧장 4단계로 가는 것이 풀스택 과잉의 시작점이다.
[자동화하기로 정해진 일]
│
▼
1단계. 이미 쓰는 협업 도구·기존 DB·BI 화면으로 해결되는가?
├─ 예 ──────────────────────────▶ 여기서 끝낸다(신규 구축 0)
└─ 아니오
│
▼
2단계. Skill·MCP·스크립트·프롬프트 기반 흐름으로 충분한가?
├─ 예 ──────────────────────────▶ Skill/MCP로 붙인다(재사용 자산화)
└─ 아니오
│
▼
3단계. 기존 서비스 관리 화면·승인 흐름에 얇게 붙일 수 있는가?
├─ 예 ──────────────────────────▶ 기존 화면에 얇게 붙인다
└─ 아니오
│
▼
4단계. 별도 풀스택 앱·대시보드가 정말 필요한가?
└─ 예 ──────────────────────────▶ 비로소 신규 구축 검토(9개 질문 전부 통과 시)각 단계의 무게와 비용 성격은 다음과 같다.
| 단계 | 구현 방식 | 새 운영 고정비 | 전형적 적합 업무 |
|---|---|---|---|
| 1 | 기존 협업 도구·DB·BI 화면 | 없음(이미 운영 중) | 정보 조회, 양식 입력, 상태 표시 |
| 2 | Skill·MCP·스크립트·프롬프트 | 거의 없음, 재사용 가능 | 작성 보조, 판단 기준 적용, 시스템 읽기 연결 |
| 3 | 기존 서비스에 얇게 붙이기 | 작음(기존 인증·운영 재사용) | 승인 전 보조, 관리 화면 내 자동화 |
| 4 | 별도 풀스택 앱·대시보드 | 큼(서버·배포·인증·모니터링·담당) | 외부 사용자 대면, 고빈도 전용 UX |
별도 화면을 만드는 것이 곧 AX가 아니다. 2단계가 특히 중요하다. Skill·MCP로 만들면 작성 기준·DB 질의 기준·검토 체크리스트가 화면에 갇히지 않고 다른 팀이 재사용한다. 풀스택 앱은 지식을 그 안에 가둔다. 판단·작성 기준은 Skill로, 시스템 접근·실행은 MCP/Tool로 분리하면 한 과제의 산출이 다음 과제의 자산이 된다(15장 참조).
사람의 협업 절차를 그대로 에이전트에 복제하지 않는다(5장 참조). 사람이 나눠 하던 “취합 → 전달 → 재확인”을 그대로 옮기면 한 번에 끝낼 일을 여러 단계로 쪼개 비용만 배수로 쓴다. 옮기기 전에 생략 가능한 단계를 먼저 제거한다.
만들기 전에 물어야 할 9개 질문
신규 구축(특히 4단계)을 제안할 때는 다음 9개 질문에 전부 답해야 한다. 하나라도 못 답하면 공식 확산 대상으로 올리지 않는다. 답이 없는 항목은 “안 된다”가 아니라 “아직 준비가 안 됐다”는 뜻이다. 문제 정의·담당·기준 문서·비용 태깅·구현 방식 판단을 정리한 뒤 다시 가져온다.
| # | 질문 | 막는 슬롭 | 답이 없으면 |
|---|---|---|---|
| 1 | 이 도구가 AX 4개 적용 영역 중 어디에 속하는가? | 모든 AI 활동을 같은 방식으로 보는 문제 | 영역 분류부터(4장) |
| 2 | 같은 문제를 이미 해결하는 도구·업무 흐름이 있는가? | 중복 도구·중복 투자 | 자산 카탈로그 점검 후 재제출 |
| 3 | Skill·MCP로 충분한 일을 풀스택으로 올리고 있지 않은가? | 풀스택 과잉 구현 | 구현 4단계 재판정 |
| 4 | 기존 협업 도구·DB·BI 화면으로 안 되는 이유가 명확한가? | 운영 중 리소스 무시 | “왜 안 되나”를 글로 적어 온다 |
| 5 | 사람 협업 절차를 그대로 복제하지 않고, 줄일 단계를 제거했는가? | 절차 복제(pave the cowpath) | 단계 제거 설계 선행 |
| 6 | 누가 결과를 검토하고, 누가 운영 책임을 지는가? | 주인 없는 미션·검증 공백 | 운영 owner 없으면 착수 보류 |
| 7 | 비용은 앱·팀·업무 단위로 분리 측정되는가? | 가치 추적 불가 | 비용 태깅 설계 선행(11장) |
| 8 | 성공 기준과 중단 기준이 모두 있는가? | 측정 없는 파일럿 | 두 기준 정의 전 파일럿 금지(8장) |
| 9 | 30일 뒤에도 쓰이지 않으면 폐기할 수 있는가? | 폐기 없는 파일럿 | 폐기 일몰 합의 선행 |
9문항은 한 줄로 꿰인다. 1~5번은 “그 무게로 만들 필요가 정말 있는가”(중복·과잉·복제), 6~7번은 “만든 뒤 누가 책임지고 비용을 추적하는가”(주인 없는 미션·가치 불명), 8~9번은 “효과가 없을 때 어떻게 멈추는가”(영생 파일럿)를 거른다.
가장 흔한 함정은 6번이다. 각 팀이 조각을 만들어 모으지만 완료 기준·검증·운영 주체가 미정이라 핸드오프가 막히고 산출물이 유지되지 못한다. 그래서 만들기 전에 “누가 운영하나”를 먼저 정하고, 운영 주인이 없으면 착수를 보류한다. 8번을 파일럿 단위로 작게 여는 법은 8장에, 9번의 날짜 박기는 다음 절에 있다.
30일 폐기 기준: 멈추는 것도 설계다
만드는 결정만큼 중요한 것이 멈추는 결정이다. 폐기는 실패가 아니다. 쓰이지 않는 도구를 빨리 멈추는 것도 비용 절감이자 신뢰 회복이고, 거듭된 실패로 스폰서가 떠나는 파일럿 피로를 막는다.
“안 쓰이는 것 같다”는 체감으로는 멈출 수 없다. 멈추려면 착수 때 미리 합의한 폐기 조건과 날짜가 있어야 한다. 그래서 9번을 운영 규칙으로 바꾼다. 신규 구축은 30일 일몰과 함께 승인한다 — 30일 내 효과 신호가 없으면 자동으로 폐기 검토에 들어간다.
아래 조건 중 하나라도 해당하면 유지가 아니라 정리를 먼저 검토한다.
| # | 폐기 트리거 | 무엇을 확인하나 |
|---|---|---|
| 1 | 30일 동안 실제 사용 기록이 없다 | 사용 로그(데모 아닌 실업무) |
| 2 | 담당자·승인자·비용 담당이 없다 | 운영 owner 부재 |
| 3 | 결과 품질을 검증할 샘플·기준이 없다 | 검증 기준 부재 |
| 4 | 같은 기능을 하는 도구가 이미 있다 | 중복 |
| 5 | Skill·MCP·기존 도구·기존 DB/BI로 대체 가능하다 | 과잉 구현 |
| 6 | 비용은 발생하지만 업무 성과와 연결되지 않는다 | 가치 미연결 |
| 7 | 운영 기준을 우회해야만 동작한다 | 통제 우회 |
이 폐기와 12장 통과 게이트는 다른 시점, 다른 질문이다.
| 구분 | 6장 30일 폐기 기준 | 12장 통과 게이트(확대·유지·보류·폐기) |
|---|---|---|
| 시점 | 착수 직후~초기 30일 | 파일럿 종료, 효과 측정 후 |
| 묻는 것 | “쓰이긴 하나, 살아 있나” | “증거 등급으로 확대할 가치가 있나” |
| 기준 | 사용 기록·owner·중복·우회 | L0~L5 증거 등급, 단위 비용, 재사용성 |
| 폐기 사유 | 안 쓰임·주인 없음·중복·우회 | 품질 악화·비용 역전·증거 부족 |
6장 폐기는 “태어났지만 숨을 안 쉬는” 도구를, 12장 폐기는 “측정까지 됐지만 확대할 가치가 없는” 도구를 정리한다. 30일 폐기는 증거 등급(12장 참조) 적용 전 명백히 죽은 것을 먼저 치우는 거친 필터다.
단계별 적용: 제안서 한 건을 게이트에 통과시키는 법
신규 구축 제안 한 건을 회의에서 다음 순서로 통과시킨다.
- 분류 확인 — 5장 6분류 판정 결과가 있는가? 없으면 5장으로 돌려보낸다. 게이트는 재설계가 끝난 후보만 받는다.
- 구현 무게 판정 — 4단계 트리를 위에서부터 적용한다. 1~3단계에서 멈출 수 있으면 멈춘다. 4단계까지 내려갔을 때만 9개 질문 전체를 요구한다.
- 9개 질문 답변 — 빈칸이 있으면 “빈칸을 채워 다시 오라”로 돌려보낸다.
- owner·비용 태깅·중단 기준 확정 — 6·7·8·9번이 문서에 박혔는지 본다. 특히 운영 owner와 30일 일몰은 승인 조건이다.
- 일몰 합의 — 30일 폐기 트리거를 양쪽이 같이 읽고 “효과 없으면 자동 폐기”에 동의한 상태로 착수한다.
핵심은 3단계까지는 게이트가 가볍다는 것이다. 기존 도구·Skill·MCP·얇게 붙이기로 끝나는 일에 9문항을 다 요구하면 게이트 자체가 또 다른 슬롭(거버넌스를 위한 거버넌스)이 된다. 저비용 구현은 빠르게 통과시키고, 신규 풀스택만 9문항·일몰로 강하게 거른다. 이 무게 비례 원칙은 17장 패스트트랙·강화 심의 분리와 같은 결이다(17장 참조).
흔한 실패모드
멈추지 못한 결정이 어떻게 비용으로 돌아오는지 회의 신호로 정리한다. 각 모드의 레드플래그는 “이 말이 나오면 의심하라”는 판별구다.
1 — 풀스택 직행. 1~3단계를 건너뛰고 곧장 별도 앱을 만들어 보고서 한 장에 서버·인증·모니터링이 붙는다. 레드플래그: “전용 대시보드부터 만들겠습니다.” 차단: 4단계 트리 강제 + 질문 3·4번.
2 — 활용량을 착수 조건으로 착각. 수요 검증 없이 도구가 양산된다. 레드플래그: 성과 보고가 “N개 도구 제작”으로 채워진다. 차단: “수요 검증 통과 + 중복 없음” 착수 조건 + 질문 1·2번.
3 — 중복 재발명. 카탈로그가 늦어 옆 팀이 만든 걸 모른 채 다시 만든다. 레드플래그: “우리 팀용으로 따로 하나 만들겠습니다.” 차단: 질문 2번 + 자산 카탈로그.
4 — 절차 복제. 사람이 나눠 하던 취합·전달·재확인을 그대로 옮긴다. 레드플래그: “기존 프로세스 그대로 AI가 각 단계를 대신합니다.” 차단: 질문 5번 + 트리 진입 전 단계 제거.
5 — 운영 주인 공석. 만들 사람은 있는데 운영할 사람이 없는 채 착수한다. 레드플래그: “일단 만들고 운영은 나중에.” 차단: 질문 6번 — owner 없으면 착수 보류.
6 — 폐기 기준 없는 영생 파일럿. 성공 기준만 있고 중단 기준·일몰이 없다. 레드플래그: 제안서에 “언제 멈추나”가 없다. 차단: 질문 8·9번 + 30일 일몰.
7 — 전제 미정비 자동화. 데이터 표준화·권한·시크릿 관리가 안 된 채 자동화부터 얹는다. 레드플래그: 기반 정비 없이 “일단 돌아가니 됐다”. 차단: 자동화 착수 조건에 데이터·권한·시크릿 정비 명시(7장 참조).
Before/After: 같은 보고서 자동화, 두 갈래의 무게
예를 들어 한 B2B SaaS 운영팀이 같은 형식의 현황 보고서를 손으로 만든다. 데이터는 이미 사내 DB·BI에 있고 보고서는 정해진 템플릿을 채우는 일이다. 리더가 “AI로 자동화하자”고 제안한다.
갈래 A — 게이트 건너뛴 풀스택 직행. 전용 보고서 생성 앱을 만든다. 데이터 재적재 백엔드, 프런트, 인증, 모니터링까지 붙는다. 30일 뒤: BI에 이미 있던 데이터를 앱이 다시 적재해 두 숫자가 어긋나고, 운영팀은 원본과 대조·수정하느라 한 단계가 늘었다. 새 고정비가 발생했고 운영 담당은 미정이다. 리더 보고는 “앱을 만들었습니다”에 그쳐 무엇이 줄었는지 말할 수 없다.
갈래 B — 게이트 거친 구현. 4단계를 위에서부터 적용한다. 1단계: 데이터는 이미 BI에 있다. 2단계: 템플릿 채우기는 보고서 작성 Skill + DB 읽기 MCP로 충분하다. → 2단계에서 멈춘다. 4단계까지 안 내려가므로 가볍게 통과시키되 6·8·9번만 확인 — owner를 정하고 성공 기준(작성 시간 단축·재작업 감소)과 30일 일몰을 합의한다. 30일 뒤: Skill이 BI 원본을 그대로 읽어 숫자가 어긋날 출처가 없고, 신규 고정비는 0, 같은 Skill을 옆 팀이 재사용한다. 리더 보고는 “신규 구축 없이 작성 시간을 기준선 대비 줄였고 옆 팀이 재사용 중”으로 비교로 말할 수 있다.
| 구분 | 갈래 A (직행) | 갈래 B (게이트) |
|---|---|---|
| 구현 무게 | 4단계(풀스택) | 2단계(Skill·MCP) |
| 신규 운영 고정비 | 서버·인증·모니터링 | 0 |
| 데이터 일관성 | 재적재로 어긋남 | 원본 직접 읽기 |
| 재사용 | 앱에 갇힘 | 옆 팀이 재사용 |
| 운영 owner | 미정 | 착수 전 확정 |
| 30일 후 | 폐기 근거 불명 | 일몰 합의로 판정 가능 |
| 경영 보고 | “앱을 만들었다” | “안 만들고 줄였다”(기준선 대비) |
두 갈래는 같은 업무, 같은 AI 역량에서 출발했다. 갈린 지점은 하나 — 4단계 트리를 위에서부터 탔는가, 곧장 바닥으로 갔는가다.
리더가 승인·요구할 신호
제안서를 사이에 둔 양쪽이 같이 쓰는 게이트다. 승인자에게는 통과·반려 기준, 실무자에게는 미리 증명할 체크리스트다. 거버넌스 세부(위험 등급·자율성·RACI·런타임 통제)는 16~18장에 있다.
요구할 것 (없으면 검토 테이블에 올리지 않는다)
- 신규 구축이면 “왜 Skill·MCP·기존 도구로 안 되는가”에 대한 9문항 답변. 특히 2번(중복)·3번(과잉)·4번(기존 리소스 불가 사유)에 답이 없으면 반려.
- 운영 owner가 한 명 박혀 있는가(질문 6번). 없으면 착수 보류 — “일단 만들고 나중에”는 안 받는다.
- 성공 기준과 중단 기준이 모두 있는가(질문 8번). 성공 기준만 있으면 영생 파일럿이 된다.
반려할 것
- 1~3단계 검토 없이 곧장 별도 풀스택 앱으로 가는 제안(구현 무게 판정 누락).
- 활용량(제작 도구 수)을 성과로 내세우며 수요 검증·중복 점검이 없는 제안.
- 사람의 협업 절차를 그대로 복제한 설계(“취합 → 전달 → 재확인”을 그대로 옮긴 것).
- 데이터·권한·시크릿 정비 없이 자동화부터 얹는 제안(전제 미정비, 7장).
승인할 것
- 30일 내 효과 신호가 없으면 자동 폐기하는 일몰 조건과 함께 올라온 신규 구축. 일몰을 받아들인 제안만 승인.
- Skill·MCP로 만들어 다른 팀이 재사용 가능한 자산화 설계(앱에 가두지 않은 것, 15장).
- 때로는 “만들지 않는 결정” — 기존 도구·BI로 끝내고 신규 구축을 0으로 둔 제안이 최선의 AX다.
이 장의 요약
- 슬롭은 문장이 허술한 게 아니라 쓰임·책임·비용·폐기 기준이 없는 산출물 전체다. 비용은 만든 직후가 아니라 그다음부터 쌓인다.
- 활용량은 착수 조건이 아니다. “수요 검증 통과 + 중복 없음”이 착수 조건이다.
- 구현은 가벼운 것부터 4단계로: ① 기존 도구·BI → ② Skill·MCP → ③ 기존 화면에 얇게 → ④ 별도 풀스택. 위에서 막힐 때만 내려가고 풀리면 멈춘다. 풀스택 직행이 과잉의 시작이다.
- 신규 구축은 9개 질문에 전부 답해야 한다. 1–5번은 무게의 필요성, 6–7번은 책임·비용 추적, 8–9번은 멈추는 법이다. 무거운 심의는 4단계에만 건다.
- 30일 폐기 기준으로 명백히 죽은 도구를 먼저 치운다. 착수 직후의 거친 필터이고, 12장 게이트는 측정 후의 정교한 판정이다.
- 폐기는 실패가 아니다. 그래서 신규 구축은 30일 일몰과 함께 승인한다. 5장이 “무엇을 재설계할지”, 6장은 “어떤 무게로 만들지, 아예 만들지 말지”를 정한다. 별도 화면을 만드는 것이 곧 AX가 아니다.
구현 4단계·9개 질문·30일 폐기 기준·실패모드는 도구·모델이 바뀌어도 유지되는 방법론 골격이다. 본문의 구현 수단(협업 도구·BI·Skill·MCP·풀스택)은 일반 범주이니 당신 환경의 구체 도구로 치환해 읽는다. 무게 비례 원칙(저비용은 빠르게, 신규 풀스택만 강하게)은 그대로 유지한다.