방향만 주고 떠나지 마라

회의실에서 가장 비싼 한 문장

“방향은 줬으니, 디테일은 현업이 채워 오세요.”

AX를 시작하는 자리에서 가장 점잖게 들리고, 가장 비싼 말이다. 이 말을 하는 리더는 대개 유능하고 빠르며 큰 그림을 본다. 방향을 빠르게 던지는 것은 미덕이다. 문제는 그 미덕이 **“방향과 실행 사이를 잇는 번역은 누군가 알아서 한다”**고 전제할 때 생긴다.

그 누군가는 없다. 방향과 실행 사이에는 항상 번역 단계가 있다. 추상적 미션(“비용을 자산화하라”)을 실행 단위 — 누가(owner), 무엇이 끝인가(완료정의), 무엇으로 성공을 재나(기준선) — 로 바꾸는 단계다. 리더가 이를 자기 일로 보지 않으면 방향은 실행이 아니라 기대치로만 내려가고, 그 빈칸을 메우는 노동은 빠짐없이 실무로 전이된다.

AI를 도입하는 조직에서 거의 예외 없이 반복되는 장면이 이것이다. 리더는 “나는 방향만 줬는데 왜 망가졌나”라 묻고, 실무는 “방향만 받았지 정해진 게 없었다”고 답한다. 둘 다 거짓말이 아니다. 번역 단계가 비어 있었을 뿐이다. 2026년의 여러 연구·업계 데이터가 한목소리로 가리키는 결론도 같다 — AX 실패의 대부분은 모델·도구의 한계가 아니라 전략·거버넌스·변화관리, 즉 ‘방향을 실행으로 번역하는 단계’의 공백에서 온다. 한 회사의 문제가 아니라 AI를 도입하는 조직이 공통으로 겪는 현상이라는 뜻이다. 그 공백의 비용은 회의록에 적히지 않는다. 그래서 **‘보이지 않는 청구서’**라 부른다.

이 책의 단일 명제 — AX는 도구를 더 쓰는 일이 아니라 같은 인원이 만든 검증된 산출로 업무를 재설계·증명·정착시키는 일 — 는 첫 단추부터 무너진다. 재설계할 대상도, 증명할 기준도, 정착시킬 주인도 없이 “일단 방향”만 내려가면 그다음의 모든 도구가 토대를 잃는다. 그래서 이 장은 1장(사용량 ≠ AI leverage) 위에서 방향을 내리는 그 순간의 결정 위생을 다룬다.

이 장은 임원을 비난하지 않는다. 추상적 방향을 빠르게 주는 것은 잘못이 아니라 역할이다. 문제는 거기에 ‘번역의 한 줄’을 붙이지 않을 때다. 구조는 **“세 함정 → 전이 비용 → 안 빠지는 법”**이고, 의사결정 트리와 체크리스트로 끝난다.

핵심 프레임: 방향과 실행 사이, 비어 있는 번역 단계

업계 전반에서 관찰되는 AX 초기 실패는 단일 뿌리에서 갈라진다. 디테일(문제·타겟·가치·전제) 없이 방향이 내려오고, 그것을 실행 단위(owner·완료정의·기준선·권한 구간)로 번역하는 단계가 비어 있다는 것이다. 이는 특정 조직의 문제가 아니라 AI를 도입하는 거의 모든 조직이 통과하는 보편 패턴이다. 이 뿌리에서 세 함정이 자란다.

방향만 내려옴 (디테일·번역 없음)
        │
   ┌────┼────────────────┐
   ▼    ▼                ▼
함정1   함정2            함정3
일화의  주인 없는        임원 뷰
유혹    미션            충돌
   │    │                │
   └────┴────────────────┘
        ▼
  전이 비용 누적
 (재작업·정렬 노동·측정 불가 숙제·사기 저하)
        ▼
  리더가 원한 속도와 가치를 동시에 잃음

세 함정은 따로 오지 않는다. 일화로 시작된 방향은 대개 주인이 없고, 주인이 없으니 임원마다 다른 그림으로 흘러간다. 셋이 합쳐지면 측정 부재·속도 압박·AI 쓰레기로 번진다. 이 장은 셋을 분해한 뒤 ‘착수 전 5문’ 트리로 묶어 돌려준다.

함정 1 — 일화의 유혹: ‘who did what’으로 결정하기

증상

외부 성공담이 검증 없이 “우리도 하자”가 된다. 전형은 이렇다. “어디선 비전문가가 짧은 기간에 내부 도구를 뚝딱 만들더라.” 이 한 문장이 일정과 난이도의 기준선이 된다.

왜 빠지나

일화는 데이터보다 생생하고, 숫자는 잊혀도 이야기는 남는다. 문제는 이야기가 옮겨질 때 전제와 실패조건이 함께 옮겨지지 않는다는 점이다. 결과만 남고 데이터 상태, 레거시 복잡도, 숨은 역량, 조직 규모, 여러 번 실패 끝의 한 번이었다는 맥락은 탈락한다. 인용된 것은 결과의 전제 없는 껍데기다.

전이 비용

일화가 “표준 난이도”로 둔갑하는 순간 청구서가 발행된다.

일화가 이미 “되는 일”로 전제돼 실무는 검증할 시간을 못 받는다.
문제 정의·타겟·데이터 상태를 건너뛰고 산출물부터 만든 뒤, 거꾸로 “이걸 누가 왜 쓰지?”를 찾는다. 공수가 두 배다 — 만들고, 사후에 정당화하느라.
실패하면 “남들은 됐는데 왜 너희는 안 되냐”며 책임이 내려온다.

한 갈래가 더 있다. 일화에 근거해 고가 도구를 대량 도입했는데 현업이 안 쓰는 경우다. 셋업·교육 공수를 쓰고 “왜 안 쓰냐” 압박이 따라온다. 일화는 ‘도입’까지만 책임지고 ‘실사용’의 빈칸은 실무가 메운다.

안 빠지는 법

일화를 결론이 아니라 가설로 강등한다. 외부 일화는 “우리도 하자”의 근거가 아니라 “우리 조건에서 성립하나”를 묻는 질문의 출발점이다. 한 줄 게이트를 의사결정 앞단에 둔다.

일화 강등 게이트: “이 일화의 핵심 전제(레거시 상태·역량·데이터·규모)가 우리 조건에서 성립하는가? 누가 언제까지 확인하는가?”

통과하지 못한 일화는 회의록에 ‘결정’이 아니라 ‘가설’로 적고, 검증 책임자 한 명을 붙인다. 가설로 적는 순간 그것은 압박하는 표준이 아니라 함께 검증할 대상이 된다. 검증 결과가 증거 등급으로 올라오면(10장 참조) 그때 결정으로 승격한다. 일화가 말해주는 것은 “가능성이 보인다”까지다. 그 이상을 일정·난이도의 근거로 삼지 않는다.

함정 2 — 주인 없는 미션: 방향만 주고 owner를 안 박기

증상

추상 미션이 책임자·완료기준 없이 내려온다. “비용을 자산화하라” 같은 구호다. 실무가 착수한 뒤 발의자가 입장을 뒤집는다. “나는 그거 요청한 적 없다.” 미션이 회수되는 순간 그 위에 쌓인 공수는 통째로 매몰된다.

쌍둥이 증상도 있다. 미션은 내려왔는데 운영·핸드오프의 주인이 공석인 경우다. 각 팀이 조각을 모으지만 완료기준·검증·운영 주체가 미정이라 핸드오프가 막힌다. 산출물은 운영자가 없어 유지되지 못한다.

왜 빠지나

미션을 주는 사람과 실행 단위로 번역하는 사람이 분리돼 있고, 리더는 후자를 자기 일로 보지 않는다. “owner를 정하고 완료정의를 박는 것”이 실무의 디테일이라고 보는 것 — 바로 이게 함정이다. 번역은 방향을 내리는 사람의 마지막 한 줄이다.

전이 비용

잘못된 방향에 큰 공수를 투입한 뒤 갈아엎는다.
“내가 시킨 적 없다”가 만드는 신뢰 붕괴. 한 번 겪은 실무는 다음 미션에 착수를 미루고 방어부터 한다. 속도가 느려지는 진짜 원인이다.
직함만 받고 권한 없는 리더는 절차 돌파에 에너지를 다 쓴다. 타 조직에 요청할 ‘명분’조차 스스로 만들어 와야 한다.

안 빠지는 법

미션 하달과 동시에, 같은 자리에서 세 가지를 박는다.

부착물	한 문장으로	없으면
owner 1명	“이 미션의 단일 책임자는 ○○○이다”	착수 보류. owner부터 지정
완료정의(DoD)	“무엇이 끝나면 이 미션이 끝난 것인가” 한 줄	끝을 몰라 영원히 안 끝남
권한·자원·에스컬레이션	“owner는 무엇을 결정하고, 막히면 누구에게 가나”	직함만 주는 함정. 책임만 전가

원칙은 단순하다. 운영 주인이 없으면 만들지 않는다. 만들기 전에 “누가 운영하나”를 먼저 정하고, 없으면 착수를 보류한다. 책임을 줄 때는 권한·자원·에스컬레이션 경로를 같은 문서에 명시한다. 책임과 권한이 다른 문서에 있으면 그 간극이 실무의 절차 돌파 노동이 된다.

함정 3 — 임원 뷰 충돌: 정렬을 실무에 떠넘기기

증상

같은 사안을 임원마다 다르게 본다. 재무는 비용절감, 사업은 업무전환, 또 다른 리더는 리스크로 본다. 조정 메커니즘이 없으니 실무는 같은 재료로 임원 수만큼 다른 모양의 문서를 만들고, “재료는 다 있는데 표현이 안 됐다”며 자기 탓을 한다.

왜 빠지나

각 임원은 자기 프레임에서 합리적이다. 문제는 임원끼리 정렬할 자리가 없어 정렬 부담이 아래로 흐른다는 것이다. 여기에 보고라인 왜곡이 겹친다. 경유 임원이 산출물을 자기 언어로 바꿔 올리면 올라가는 팩과 내려오는 팩이 달라져, “아무도 전체를 모르는” 상태가 된다.

전이 비용

정렬 비용이 실제 작업보다 커진다. 만드는 시간보다 프레임마다 재포장하는 시간이 더 든다.
공들인 문서가 해석 필터를 거치며 변질돼 잘못된 정보 위에서 결정이 내려진다. 핵심 메시지는 위로 전달되지 않는다.

안 빠지는 법

실무 착수 전에 임원끼리 짧은 정렬 자리를 연다. 합의할 것은 둘이다.

이건 목적인가, 결과인가? (워크플로 완성도 자체가 목적인가, 그것으로 달성할 비용·매출이 목적인가)
투자 우선순위는? (모든 것이 P0면 아무것도 P0가 아니다)

핵심 결정은 원작성자가 직접 설명하는 자리를 1회 보장한다. 해석 필터를 우회하는 경로다. 정렬은 위에서 끝낼 일이지 아래로 내려보낼 숙제가 아니다 — 이 한 줄이 함정 3을 막는다. 여기에 한 가지를 더 붙인다. 경유 임원이 “에이전트로 다 됐다”고 능력 경계 없이 올리면 같은 산출물이 위로 갈수록 “거의 완성”으로 부풀고, 임원별 기대가 정반대로 벌어진다. 그래서 무엇까지 되고 무엇은 안 되는지를 산출물과 함께 올리게 한다. 이것이 해석 필터를 막는 또 하나의 장치다(능력 경계 명세는 10장 참조).

전이 효과 총정리 — ‘보이지 않는 청구서’

세 함정이 합쳐지면 어떻게 번지는지, 인과 사슬로 본다.

일화 기반 결정(디테일 없음)
        │
        ▼
주인 없는 미션 ──► 임원별 상이한 뷰(정렬 불능)
        │                    │
        ▼                    ▼
목표·볼륨 부재         속도·일정 압박
        │                    │
        ▼                    ▼
측정 부재 ◄──────── AI 쓰레기·중복 투자

가장 아픈 결론은 이것이다. 디테일을 아끼면 속도가 빨라지는 게 아니다. 재작업·정렬 노동으로 더 느려지고, 끝에는 가치 증명까지 불가능해진다. 방향을 내릴 때 아낀 5분이 실무의 거대한 청구서로 돌아온다.

청구서는 회계 장부에 잡히지 않아 ‘보이지 않는다’. 합산하면 다음과 같다.

청구 항목	어디서 발생하나	누가 결제하나
재작업 비용	일화 검증 생략 → 만들고 사후 정당화	실무 (두 배 공수)
정렬 노동	임원 뷰 충돌 → 프레임마다 재포장	실무 (작업보다 큰 비용)
측정 불가 숙제	기준선 없는 ROI 요구 → 반복 소환	실무 (회의마다 미해결)
신뢰 붕괴	“시킨 적 없다” → 착수 방어	조직 전체 (다음 미션이 느려짐)
사기 저하	권한 없는 책임, 자책	유능한 실무자의 이탈

이 청구서를 막는 비용은 놀랄 만큼 싸다. 방향을 내리기 직전, 다섯 질문을 스스로에게 던지는 것이다.

리더의 의사결정 트리 — 착수 전 5문

이 트리는 실무용이 아니다. 방향을 내리는 리더 본인이, 내리기 직전에 통과시키는 자가 게이트다. 다섯 중 하나라도 막히면 멈추고 빈칸을 메운 뒤 내려보낸다.

방향을 내리기 직전, 스스로 묻는다:

1. 이 결정의 근거는 데이터인가, 일화인가?
   ├─ 일화 → "우리 조건에서 전제가 성립하나?" 미확인이면
   │         → [가설로 강등 + 검증 게이트 + 검증 책임자 1명]
   └─ 데이터 → 2로

2. 이 미션의 owner를 한 명 댈 수 있나?
   ├─ 없다 → [착수 보류. owner부터 지정]
   └─ 있다 → 3으로

3. 그 owner에게 권한·자원·완료정의(DoD)를 같이 줬나?
   ├─ 아니다 → [직함만 주는 함정. 권한을 붙여라]
   └─ 그렇다 → 4로

4. 다른 임원과 '목적 vs 결과'가 정렬됐나?
   ├─ 아니다 → [실무 착수 전 임원 정렬 자리 + 원작성자 직접 설명 1회]
   └─ 그렇다 → 5로

5. 이 결정의 성공을 무엇으로(어떤 단위·기준선) 잴지 정의했나?
   ├─ 아니다 → [측정 단위·기준선 먼저. 없으면 ROI 요구 금지]
   └─ 그렇다 → ✅ 내려보내도 좋다

순서에는 의미가 있다. **근거(1) → 주인(2) → 권한(3) → 정렬(4) → 측정(5)**은 함정 1·2·3과 그 하류(측정 부재)를 차례로 막는다. 건너뛰면 막힌 질문의 빈칸이 그대로 실무의 청구서가 된다. 5번이 마지막인 것도 의도다 — 무엇을 잴지 정하지 않은 채 “증명해 와라”는 측정이 아니라 압박이다(측정 도구의 전모는 9·10장 참조).

리더용 체크리스트 (한 장)

회의 테이블에 펴고 방향을 내리기 전에 여덟 칸을 채운다. 빈칸이 있으면 그 칸이 청구서다.

근거가 일화면, “가설”이라고 명시했고 검증 책임자를 정했다.
미션에 owner 1명과 완료정의(DoD) 1줄을 붙였다.
owner에게 권한·자원·에스컬레이션 경로를 함께 줬다.
“이건 목적인가 결과인가”를 다른 임원과 맞췄다.
산출물 착수 전, 임원 간 우선순위 합의가 끝났다.
성공을 잴 단위·기준선을 (ROI를 요구하기 전에) 내가 정의했다.
“외형 확보일 ≠ 출시 가능일”을 일정에 분리해 적었다.
만든 뒤 누가 운영하는지 지금 댈 수 있다.

흔한 실패모드 — 회의에서 알아채는 신호

레드플래그는 “이 말이 나오면 의심하라”는 회의용 판별구다.

1 — 일화의 표준화. 레드플래그: “어디선 비전문가가 금방 만들었다던데 우리도.” 차단: 5문 1번 + 일화 강등 게이트.

2 — 도입 후 실사용 공백. 도입 결정에 “누가, 어떤 업무에서, 무엇이 나은지”가 없다. 차단: 도입 전 최소 사용 실증을 게이트로.

3 — 회수되는 미션. 레드플래그: “나는 그거 요청한 적 없다.” 차단: 5문 2·3번 + owner·DoD·권한 동시 부착.

4 — 직함만 주기. TF 리더 임명에 인력·예산·결정 권한 명시가 없다. 차단: 5문 3번 + 권한·자원·에스컬레이션을 같은 문서에.

5 — 정렬을 아래로 떠넘기기. 실무가 “뭘 달성하냐”고 물어도 임원마다 답이 다르다. 차단: 5문 4번 + 착수 전 임원 정렬 자리.

6 — 보고 필터 왜곡. 핵심 결정인데 원작성자가 직접 설명한 적 없다. 차단: 원작성자 직접 설명 1회 보장.

7 — 기준선 없는 증명 요구. ROI를 요구하는데 비교 기준선·측정 대상 정의가 없다. 차단: 5문 5번 + “무엇을, 무엇 대비, 어떤 단위로”를 먼저 정의.

8 — ‘먼저 만들고 효과는 나중에’. 레드플래그: “완성도보다 속도, 일단 던지자.” 차단: “외형 확보일 ≠ 출시 가능일”을 일정에 분리.

9 — 경계 없는 ‘다 됐다’ 상향보고. 레드플래그: “다 됐다”가 어디까지 되고 무엇은 안 되는지 없이 위로 단정된다. 차단: 능력 경계 명세 첨부 의무화 + ‘다 됐다’를 “무엇이 되고·무엇은 안 되고·사람 확인 구간”으로 치환(보고 규칙은 10장 참조).

네 가지 사례 — 같은 방향, 갈라지는 청구서

아래 네 사례는 AI를 도입하는 여러 조직에서 반복 관찰되는 전형적 패턴을 보여준다. 어느 한 곳의 이야기가 아니라, 리더라면 누구나 빠지기 쉬운 보편적 함정으로 읽어 달라.

사례 A — “옆 동네는 됐다더라” (함정 1)

한 임원이 외부 모임에서 “어떤 곳은 비전문가가 내부 도구를 뚝딱 만들더라”는 이야기를 듣고 “우리도 그렇게 가자”고 던진다. 문제 정의도 타겟도 데이터 상태도 없다. 실무자는 산출물부터 만들고 한참 뒤에야 거꾸로 타겟을 찾는다. 결과물은 누구의 환영도 받지 못한다.

교훈: 외부 일화는 “우리도 하자”의 근거가 아니라 “우리 조건에서 성립하나”를 묻는 출발점이다. 들으면 결론이 아니라 가설로 적어라.

사례 B — “비용을 자산으로 바꿔라” (함정 2)

상위에서 “투입 비용을 자산화하라”는 미션이 완료기준 없이 내려온다. 한 실무 리더가 장비 구매·회계 처리 준비에 착수한다. 얼마 뒤 재무 임원이 “요청한 적 없다. 실사에서 다 깎이고 위험하다”며 정반대 입장을 낸다. 정작 장비가 필요했던 진짜 이유(민감정보 로컬 처리, 조달 시차)는 자산화 논쟁에 가려 정당화되지 못했다.

교훈: 구호를 내리기 전에 실제 의사결정자의 평가 기준과 먼저 정렬하라. 기술적 필요와 회계 처리를 한 덩어리로 섞지 마라 — 각자의 근거로 따로 세워야 산다.

사례 C — “어느 장단에 맞춰야 하나” (함정 3)

동일 과제를 두고 세 리더가 다른 그림을 그린다. 한 명은 기반 엔지니어링 개선, 한 명은 매출 기여, 또 한 명은 “시중 도구와 뭐가 다르냐”는 회의론. 실무자는 리더 수만큼 다른 문서를 만들고 “재료는 다 있는데 표현이 안 됐다”며 자책한다.

교훈: “맞춰 오라”고 하기 전에 리더끼리 “목적인가 결과인가, 우선순위는 무엇인가”를 먼저 맞춰라. 정렬은 위에서 끝낼 일이지 아래로 내려보낼 숙제가 아니다.

사례 D — “쓴 만큼 값어치를 증명해 봐” (전이의 종착점)

한 운영팀이 고가 도구에 예산을 태운다. 기간 말, 리더는 “증명할 길이 없다”며 ROI를 요구한다. 그러나 측정 대상 행위 정의도 비교 기준선도 없다. 실무자는 코드량·문서량 같은 잘못된 대리지표를 성과로 들고 오고, 같은 난제가 회의마다 반복된다.

교훈: “증명해 와라”는 “무엇을, 무엇 대비, 어떤 단위로 잴지”를 리더가 먼저 정의했을 때만 정당하다. 기준선 없는 ROI 요구는 측정이 아니라 압박이다.

네 사례는 같은 출발점에서 갈라졌다 — 방향은 있었으나 번역이 없었다. A는 근거를, B는 주인을, C는 정렬을, D는 측정을 비웠다. 5문 트리의 다섯 칸이 바로 이 네 사례의 빈칸이다.

Before/After: 같은 방향, 다른 첫 회의

구분	Before: 방향만 내림	After: 방향에 번역 한 줄
근거	“옆 동네는 됐다더라” → 결정	일화 → 가설로 강등 + 검증 책임자
미션	“비용을 자산화하라” (구호)	owner 1명 + DoD 1줄 + 권한 동시 부착
정렬	실무가 임원마다 맞춰 옴	착수 전 임원 ‘목적 vs 결과’ 합의
측정	“증명해 와라” (기준선 없음)	단위·기준선을 리더가 먼저 정의
일정	외형 확보일 = 출시일	외형 확보일 ≠ 출시 가능일 분리
결과	재작업·정렬 노동·측정 불가 숙제	같은 인원이 검증된 산출로 직행
경영 보고	“AI를 도입·활용했다”	“무엇이, 무엇 대비, 어떤 단위로 좋아졌다”(증거 등급 L2 이상, 10장 참조)

갈린 지점은 하나 — 방향을 내릴 때 ‘번역의 한 줄’을 함께 줬는가다. 그 한 줄의 비용은 5분, 생략의 비용은 한 분기다.

리더가 승인·요구할 신호

방향을 내리는 리더(의사결정·승인 축)와 그것을 받는 실무가 같이 쓰는 게이트다. 리더에게는 “무엇을 붙여 내려야 하는지”의 체크리스트, 실무에게는 “무엇이 빠진 방향을 되돌려 보내야 하는지”의 근거다.

요구할 것 (없으면 방향을 내리지 않는다)

근거가 일화면 “가설”로 명시 + 검증 게이트 + 검증 책임자 1명. 전제가 우리 조건에서 성립하기 전엔 일정·난이도의 기준으로 삼지 않는다.

미션에 owner 1명 + 완료정의(DoD) 1줄 + 권한·자원·에스컬레이션을 같은 자리에서 동시 부착. 운영 주인이 없으면 착수 보류.

실무 착수 전 임원 간 ‘목적 vs 결과’·투자 우선순위 정렬. 핵심 사안은 원작성자 직접 설명 자리 1회 보장.

ROI를 요구하기 전에 측정 단위·기준선을 리더가 먼저 정의(9·10장 참조). 기준선 없는 증명 요구 금지.

반려할 것

‘먼저 만들고 효과는 나중에’. 외형 확보일을 출시 가능일로 착각하는 일정. 검증 완료 정의 없는 공개.

일화를 검증 없이 표준 난이도로 삼는 결정.

책임은 직함으로 주고 권한은 위임하지 않는 임명.

임원 정렬을 끝내지 않고 실무에 “맞춰 와라”로 떠넘기는 것.

승인할 것

방향에 번역 한 줄(owner·DoD·기준선)을 붙여 올라온 제안.

일화를 가설로 강등하고 검증부터 설계한 제안.

임원 정렬이 위에서 끝난 뒤 단일 채널로 내려온 미션.

경영 보고가 “도입했다”가 아니라 **증거 등급(L2 이상)으로 “무엇이 무엇 대비 좋아졌다”**를 말하는 제안(보고 규칙은 10장 참조).

이 장의 요약

방향과 실행 사이에는 번역 단계가 있다. 리더가 자기 일로 보지 않으면 방향은 실행이 아니라 기대치로만 내려가고, 빈칸은 실무의 청구서가 된다.
함정 1(일화): 결론이 아니라 가설로 강등하라. “우리 조건에서 성립하나” 게이트 + 검증 책임자를 붙인다.
함정 2(주인 없는 미션): 하달과 동시에 owner 1명 + DoD 1줄 + 권한을 같은 자리에서 박는다. 운영 주인이 없으면 만들지 않는다.
함정 3(임원 뷰 충돌): 정렬은 위에서 끝낼 일이다. 착수 전 ‘목적 vs 결과’를 합의하고, 원작성자 직접 설명을 1회 보장한다.
세 함정의 합은 측정 부재·속도 압박·AI 쓰레기로 번진다. 디테일을 아끼면 빨라지는 게 아니라 더 느려지고 증명까지 불가능해진다.
착수 전 5문(근거 → 주인 → 권한 → 정렬 → 측정)을 방향 내리기 직전에 통과시킨다. 한 칸이라도 비면 그 칸이 청구서다.
거부할 단 하나의 문장: ‘먼저 만들고 효과는 나중에’.

디테일은 통제가 아니라 배려다. 디테일을 박는 것은 실무를 옥죄는 게 아니라, 실무가 헛돈을 쓰지 않도록 빈칸을 메워주는 리더의 일이다. 좋은 리더는 방향을 빠르게 주되, ‘번역의 한 줄’을 함께 준다.