AX 플레이북: 우리 팀 설계하기
책 전체의 내용을 우리 팀의 다음 90일로 바꾸는 장이다. 1장의 자가진단 점수, 팀의 업무와 규모, 지금 가장 아픈 곳, 정보가 사는 곳을 입력하면 첫 유스케이스 캔버스와 주차별 실행 계획, 성공 지표, 리스크 통제, 이해관계자 표가 초안으로 만들어진다. 초안은 출발점일 뿐이다. 팀과 함께 고치고, 스폰서와 합의하는 데 쓰자.
- 진단 → 팀 프로필 → 고통점 → 정보 거주지 → 첫 유스케이스 순서로 우리 팀의 AX 출발점을 정의할 수 있다.
- "가시화 → 표준화 → 데이터 준비 → 구축 → 파일럿 → 측정 → 결정"으로 이어지는 90일 계획의 구조와 각 주차의 산출물을 설명할 수 있다.
- 리더가 착수 전에 던져야 할 질문과 경영진 보고용 한 장 요약의 구성을 안다.
- 거버넌스·실험 조직·로드맵의 영역별 90일 트랙을 같은 틀로 비교하고, 겹치는 작업과 병목을 찾을 수 있다.
- 파일럿 연옥, 기대 과잉, 측정 부재 같은 흔한 실패 패턴을 미리 알아보고 처방을 계획에 넣을 수 있다.
플레이북 사용법
이 장의 플래너는 정답을 주는 도구가 아니라 첫 회의의 초안을 만드는 도구다. 팀장이나 AX 담당자가 혼자 30분 동안 채워 보고, 결과를 출력해 팀원·스폰서와 함께 고치는 방식을 권한다. 입력값은 이 브라우저에 저장되므로 언제든 돌아와 수정할 수 있다.
- 진단 불러오기1장에서 자가진단을 했다면 점수가 자동으로 들어온다. 하지 않았다면 여기서 8개 차원을 1~5점으로 입력하고 저장한다. 가장 낮은 두 차원이 계획의 "기반 작업"으로 들어간다.
- 팀 프로필기능(품질, 생산, 설비 …)에 따라 유스케이스 후보와 인접 부서가 달라진다. 인원은 파일럿 사용자 수와 챔피언 수를 정하는 데 쓰인다.
- 고통점과 정보 거주지체크한 항목마다 해당 주차에 처방 작업이 추가된다. 예를 들어 "메일 속 데이터"를 고르면 3주차에 메일 샘플 구조화 실습이 들어간다.
- 첫 유스케이스기능별 후보 중 하나를 고른다. 진단 평균이 낮으면 난이도가 낮은 후보에 "추천" 표시가 붙는다.
- 생성·검토·공유결과를 텍스트로 복사해 메일·문서에 붙이거나 인쇄한다. 숫자 목표는 일부러 비워 두었다. 기준값을 잰 뒤 팀이 정해야 하기 때문이다.
플래너: 우리 팀의 90일 만들기
90일 계획의 뼈대는 17장의 여섯 단계를 한 업무에 압축한 "얇은 수직 슬라이스"다. 첫 3주는 보고 재고, 다음 3주는 맞추고 모으고, 그다음 4주는 만들고 써 보고, 마지막 3주는 재고 결정한다. 플래너는 이 뼈대 위에 우리 팀의 약점과 고통점에 맞춘 작업을 끼워 넣는다.
AX 플래너 — 진단에서 90일 계획까지
1. 자가진단 점수
1점 = 거의 없음, 3점 = 일부 팀에서 시작, 5점 = 전사적으로 정착. 가장 낮은 두 차원이 계획의 기반 작업이 된다.
2. 팀 프로필
기능에 따라 유스케이스 후보와 인접 이해관계자가 달라진다.
3. 지금 가장 아픈 곳
해당하는 것을 모두 고른다. 각 항목에 맞는 처방 작업이 계획에 추가된다.
4. 우리 팀 정보는 주로 어디에 사는가
2장의 정보 거주지 지도를 떠올리자. 대상 업무의 정보가 많이 사는 곳을 고른다. 인벤토리와 데이터 준비 작업의 대상이 된다.
5. 첫 유스케이스
기능별 후보 중 하나를 고른다.
6. 계획 생성
아래 버튼을 누르면 이 카드 아래에 계획 초안이 만들어진다. 입력을 바꾼 뒤 다시 누르면 갱신된다.
영역별 90일 트랙: 거버넌스·실험 조직·로드맵
플래너가 만드는 것은 한 팀, 한 유스케이스의 90일이다. 그 바깥에서는 조직 단위의 90일 트랙이 함께 돈다. 거버넌스 담당은 사용 기준과 심사 경로를 깔고, 연구·개발 조직은 기준 레지스트리와 실험 카드를 만들고, AX 추진 조직은 등대 프로젝트의 첫 슬라이스를 끌고 간다. 앞 장들에 흩어져 있던 세 트랙을 같은 틀로 나란히 놓았다. 개념과 이유는 각 장에서, 순서와 졸업 기준은 여기서 본다.
| 트랙 | 0~30일 · 보기 | 31~60일 · 맞추기 | 61~90일 · 쓰게 하기 | 90일 졸업 기준 |
|---|---|---|---|---|
| 거버넌스 12장 |
섀도 AI 실태 파악(비난 없이), 승인 AI 도구 1종 개방, 한 장짜리 사용 기준, 유스케이스 등록 양식 배포 | 주요 문서 저장소에 기본 등급 부여, 리스크 등급별 심사 경로 운영, AI 게이트웨이(마스킹·로그) 도입 | 등록된 상위 유스케이스 5개에 평가 세트 구축, 거버넌스 위원회 첫 분기 검토, ISO/IEC 42001·NIST AI RMF 대비 차이 분석 | AI 사용이 등록·로그로 보이고, 분기 검토에서 사용 통계·사고·예외를 보고하며 기준 개정 이력이 남는다 |
| 실험 조직 7장 |
자주 비교되는 핵심 지표 5~10개의 팀별 정의 수집(AI가 메일·회의록에서 정의가 바뀐 흔적을 찾음), 지표별 현재 정의와 오너를 표 하나로 | 기준 레지스트리 v0·실험 카드 양식 v0, 실험 노트에서 카드 초안 자동 추출, 자주 찾는 과거 실험부터 역카드화 착수(기준 버전은 AI 추정 + 사람 확인) | 실험 검색·비교 도우미 운영(기준 버전 불일치 경고), 평가 세트 구축, 정답률과 사용 빈도 공개 | 이번 달 신규 실험 80% 이상이 카드를 가지고, "이건 해 봤나?"에 근거와 함께 답한다. 추천 AI는 그다음 |
| 로드맵·등대 프로젝트 17장 |
등대 업무 선정과 현업 오너 지정, 해당 업무 정보 인벤토리, as-is 흐름과 기준선 KPI 측정, 평가 질문 50개 수집 | 해당 업무 용어·코드 사전, 이슈 카드 표준 양식, 문서 저장소 정리·등급 부여, 첫 프로토타입(근거 표시), 챔피언 3~5명 지정 | 실제 업무에 투입하고 이중 작업 제거, 평가 세트로 주간 측정, 기준선 대비 KPI 비교, 18개월 로드맵 갱신 | 첫 수직 슬라이스가 가시화·표준화·디지털화를 통과하고 지능화의 첫 버전이 현업 손에 있다. 확산·수정·중단을 결정한다 |
세 트랙을 나란히 놓으면 겹치는 일이 보인다. 승인 도구 개방과 문서 등급은 거버넌스 트랙과 로드맵 트랙에 모두 있고, 평가 세트는 세 트랙의 61~90일에 모두 있다. 겹치는 일은 한 번만 하고 오너를 한 명으로 정한다. 예를 들어 등대 프로젝트의 문서 저장소 등급 작업을 거버넌스 트랙의 첫 적용 사례로 삼고, 평가 세트는 같은 양식(질문, 정답, 근거 문서, 판정자)으로 만든다. 반대로 같은 기간에 세 트랙의 "맞추기"가 같은 현업 전문가에게 몰리면 그 사람이 병목이 된다. 트랙별 31~60일 작업에 누가 시간을 내는지 먼저 적어 보자.
플래너가 만든 우리 팀 계획은 로드맵 트랙을 한 팀 크기로 줄인 것이다. 팀 계획의 W2(데이터 등급·허용 도구 확인)는 거버넌스 트랙의 0~60일 산출물에 기대고, 팀이 연구·개발 기능이라면 W4~W6의 표준화·데이터 준비는 실험 조직 트랙의 기준 레지스트리와 같은 작업이다. 조직 트랙이 아직 출발하지 않았다면 팀 계획 안에서 그 일을 좁게 먼저 하고, 결과를 트랙의 v0로 넘긴다.
리더를 위한 질문 리스트
플래너가 만든 초안을 들고 첫 회의에 들어가기 전에, 팀장·파트장이 스스로 답해 봐야 할 질문들이다. 답이 "모르겠다"인 질문이 바로 계획의 첫 작업이다.
왜, 무엇을
- 이 업무가 1년 뒤 어떻게 달라져 있으면 성공인가? 한 문장으로 말할 수 있는가?
- 왜 이 업무부터인가? 빈도·고통·데이터 준비도로 설명할 수 있는가?
- 하지 않을 일(범위 밖)을 정했는가?
무엇으로
- 이 업무의 "1건"은 무엇이고, 그 필드를 적을 수 있는가?
- 최근 50건의 과거 사례를 하루 안에 모을 수 있는가?
- 그 데이터의 오너는 누구이고, 외부 AI 도구에 넣어도 되는 등급인가?
어떻게
- 지금 이 업무를 팀원 세 명이 같은 순서로 처리하는가?
- AI가 끼어들 지점과 사람이 승인할 지점을 그림으로 그릴 수 있는가?
- 예외 상황은 누가, 어떤 기준으로 판단하는가?
누구와
- 현업 주인(프로덕트 오너)이 이름으로 정해져 있고, 시간을 낼 수 있는가?
- 가장 회의적인 팀원은 누구이며, 그 사람의 우려는 무엇인가?
- 절약된 시간을 무엇에 쓸지 팀원과 이야기했는가?
무엇을 조심
- AI가 틀렸을 때 누가 언제 알아채는가? 그 비용은 얼마인가?
- 정보보안·법무와 언제 처음 이야기하는가? (마지막 주가 아니어야 한다)
- 고객·외부로 나가는 산출물이 있는가?
어떻게 알까
- 기준값을 언제, 어떤 정의로 재는가?
- 90일 뒤 "확산 / 수정 / 중단" 결정을 무엇으로 내리는가?
- 사용량(채택)과 성과를 따로 재고 있는가?
- 이 과제의 목표가 팀 MBO에만 있는가, 아니면 실·사업부가 소유한 결과·기반 목표와 연결되어 있는가?(14장)
경영진 보고용 한 장 요약 템플릿
90일이 끝나면 경영진에게 결정을 요청해야 한다. 이때 30쪽짜리 PPT는 2장에서 본 "그림으로 저장된 데이터"를 하나 더 만드는 일이다. 한 장에 다음 일곱 칸만 채우자. 플래너의 결과에도 같은 구조의 초안이 포함된다.
① 문제 클레임 1건당 유사 사례 탐색 평균 [기준값]시간, 담당자 이동 시 단서 소실
② 한 일 이슈 카드 필드 합의(데이터) · 단일 대응 흐름(프로세스) · 과거 8D RAG 검색(AI)
③ 결과 탐색 시간 [기준값] → [현재값](측정 정의: 카드 생성 → 유사 사례 확정), 파일럿 사용자 주간 활성 [n]명 중 [m]명
④ 배운 것 효과의 상당 부분은 카드 표준화에서 나왔다 · 근거 링크가 없으면 엔지니어가 쓰지 않는다
⑤ 리스크 고객 정보 포함 문서의 권한 관리 → 정보보안 검토 완료, 월 1회 접근 로그 점검
⑥ 다음 90일 3개 팀 확산, 8D 초안 기능 파일럿, 불량 코드 정준화 범위 확대
템플릿의 [기준값]·[현재값] 칸을 미리 그럴듯한 숫자로 채우지 않는다. 측정하지 않은 숫자가 한 번 보고서에 들어가면 그 숫자가 목표가 되고, 다음 분기의 기대 과잉으로 돌아온다.
흔한 실패 패턴과 처방
앞 장들에서 흩어져 나온 실패 패턴을 플레이북의 관점에서 다시 모았다. 계획을 검토할 때 이 표를 옆에 두고 "우리 계획에 이 처방이 들어 있는가?"를 확인하자.
| 패턴 | 현장에서 보이는 모습 | 처방(계획에 넣을 것) | 관련 장 |
|---|---|---|---|
| 도구 먼저 | "좋은 AI 도구를 샀는데 쓸 데가 없다" | 업무의 "1건"과 표준 단위부터 정의(W4) | 1장 |
| 파일럿 연옥 | 데모는 성공, 1년째 파일럿 | 시작 전에 졸업 기준·운영 오너·예산을 정의(W1, W12) | 17장 |
| 기대 과잉 | "전사 업무 50% 자동화" 같은 목표가 위에서 내려옴 | 90일 목표는 "증명"으로, 성공 기준을 1쪽으로 합의(W1) | 13장 |
| 측정 부재 | "좋아진 것 같다"만 있고 기준값이 없음 | W2에 측정 정의서와 기준값 측정 시작 | 8장 |
| 현업 소외 | IT·혁신팀이 만들고 현업은 "또 시스템 하나" | 현업 주인 지정, 사용자 인터뷰, 챔피언(W1, W6, W9) | 13장 |
| 보안 막판 차단 | 오픈 직전 정보보안 검토에서 중단 | W2에 데이터 등급·허용 도구 확인 | 12장 |
| 범위 확장 | "이왕 하는 김에 저것도"로 과제가 3배 | 범위 밖 목록을 헌장에 명시, 변경은 W13 결정으로 | 17장 |
| 평가 없는 출시 | 몇 번 시연해 보고 "잘 되네"로 오픈 | 평가 세트 30~50건, 근거 일치율 측정(W8) | 6장, 10장 |
공식적으로 중단된 과제는 교훈이라도 남긴다. 위험한 것은 아무도 쓰지 않는데 아무도 중단을 선언하지 않는 과제다. 그래서 90일 계획의 마지막 주에는 반드시 "중단"도 선택지로 올린다.
90일 이후: 확산·수정·중단을 가르는 기준
13주차의 결정은 감이 아니라 미리 정한 기준으로 내린다. 아래 표는 기준의 예시다. 숫자 문턱값은 팀과 업무에 맞게 W1에 정해 두어야 한다.
| 결정 | 채택(사용량) | 성과(기준값 대비) | 품질·리스크 | 다음 행동 |
|---|---|---|---|---|
| 확산 | 파일럿 사용자 대부분이 업무 흐름 안에서 꾸준히 사용 | 사전에 합의한 목표 달성 | 평가 세트 기준 충족, 중대 사고 없음 | 인접 팀 2~3곳, 운영 오너·예산 확정 |
| 수정 후 계속 | 일부만 사용, 이유가 파악됨 | 개선은 있으나 목표 미달 | 보완 가능한 문제 | 원인 1~2개에 집중한 다음 60일 |
| 중단 | 사용이 거의 없고 이유가 근본적 | 기준값 대비 의미 있는 변화 없음 | 통제 비용이 효과보다 큼 | 배운 것을 기록하고 기반 작업(카드·코드)은 남긴다 |
중단하더라도 앞 6주 동안 만든 표준 단위, 매핑표, 인벤토리, 측정 정의는 다음 과제의 자산으로 남는다. 이것이 "기반 먼저" 계획의 숨은 장점이다. AI 부분이 실패해도 조직은 한 칸 올라가 있다.
핵심 정리
- 플레이북은 진단 → 팀 프로필 → 고통점 → 정보 거주지 → 첫 유스케이스를 입력해 90일 계획 초안을 만드는 도구다. 초안은 팀과 스폰서가 함께 고친다.
- 90일의 절반 가까이는 AI 이전의 기반 작업(정렬, 가시화, 표준화, 데이터 준비)이다. 가장 약한 진단 차원과 고통점에 대한 처방이 이 구간에 들어간다.
- 기준값 측정은 2주차에 시작해야 11주차에 비교할 수 있다. 채택(사용량)과 성과를 따로 잰다.
- 리더는 도구보다 "1건의 정의, 현업 주인, 승인 지점, 데이터 등급, 측정 정의"를 먼저 묻는다.
- 13주차에는 확산·수정·중단 중 하나를 미리 정한 기준으로 결정하고, 한 장 요약으로 보고한다. 중단해도 기반 산출물은 남는다.
- 팀의 90일 바깥에서는 거버넌스·실험 조직·로드맵의 조직 트랙이 함께 돈다. 같은 "보기 → 맞추기 → 쓰게 하기" 틀로 나란히 놓고, 겹치는 일(도구 개방, 문서 등급, 평가 세트)은 한 번만, 한 오너로 한다.
확인 퀴즈
90일 계획에서 기준값(baseline) 측정을 2주차에 시작하는 가장 큰 이유는?
플래너가 자가진단에서 가장 낮은 두 차원을 쓰는 방식으로 옳은 것은?
경영진 보고용 한 장 요약에서 맨 위에 두어야 할 것은?
90일 결과가 기대에 못 미쳐 "중단"을 결정했다. 이 장의 관점에서 옳은 설명은?
거버넌스·실험 조직·로드맵의 90일 트랙을 나란히 놓았더니 세 트랙 모두 61~90일에 "평가 세트 구축"이 있다. 가장 적절한 대응은?