전체를 보는 AX: 인터페이스, 인프라 바닥, 가치 실현
팀마다 AX 목표를 세우고 각자 성과를 냈다. 그런데 고객이 체감하는 리드타임은 그대로다. 사내 플랫폼은 API를 열어 주지 않고, 팀과 팀 사이를 오가는 산출물은 정의되어 있지 않은데, 각 팀은 자기 안의 효율만 계산한다. 부품 하나하나를 잘 설계한다고 좋은 시스템이 되지는 않는다. 이 장은 AX를 시스템 설계의 문제로 다시 본다. 팀 사이의 인터페이스는 누가 설계하는지, 아래에서 만든 효율을 돈으로 바꾸는 일은 누구의 몫인지, 그리고 팀에 AX를 요구하기 전에 회사가 먼저 깔아야 할 바닥은 무엇인지를 다룬다.
- 팀 단위 최적화가 전체 리드타임을 바꾸지 못하는 이유를 흐름(처리 시간과 대기 시간)으로 설명할 수 있다.
- 팀 간 산출물 계약과 플랫폼 API를 어느 계층이 책임져야 하는지, API가 없을 때의 과도기 전략을 제시할 수 있다.
- 절감 시간이 실제 금액이 되는 경로와, 그 전환을 결정해야 하는 사람을 구분할 수 있다.
- 팀에 AX를 요구하기 전에 회사가 깔아야 할 최소 공통 바닥과 과제와 함께 자라는 인프라를 구분하고, 요구 수준을 바닥에 맞출 수 있다.
- 전체를 보는 사람이 분기마다 확인할 질문으로 조직의 AX 상태를 점검할 수 있다.
모든 팀이 목표를 달성했는데, 고객은 모른다
E사(산업용 장비 부품) 고객 클레임은 다섯 팀을 지나간다. 영업이 접수하고, 품질이 분석하고, 생산기술이 원인을 확인하고, 구매가 협력사 조치를 받고, 다시 품질이 회신서를 쓴다. 올해 다섯 팀은 모두 AX 목표를 세웠고 모두 달성했다. 영업은 접수 양식을 AI로 자동 분류하게 했고, 품질은 8D 초안을 AI로 쓴다. 생산기술은 설비 이력 검색을 붙였고, 구매는 협력사 회신 메일을 요약한다. 팀별로 보면 처리 시간이 30~60% 줄었다(예시 수치).
그런데 클레임 한 건이 접수부터 회신까지 걸리는 시간은 21일에서 19일로 줄었을 뿐이다. 실 기획이 한 건을 처음부터 끝까지 따라가 보고서야 이유가 보였다. 21일 중 팀 안에서 실제로 일하는 시간은 7일 남짓이었다. 나머지는 팀과 팀 사이에 있었다. 다음 팀이 메일을 확인할 때까지 기다리는 시간, 받은 자료의 양식이 맞지 않아 다시 요청하는 시간, 협력사 시스템과 사내 시스템을 사람이 옮겨 적는 시간. 다섯 팀이 각자 자기 부품을 빠르게 만들었지만, 부품 사이의 연결은 아무도 설계하지 않았다.
팀 단위 AX 목표는 각 팀을 하나의 부품처럼 다룬다. 부품마다 성능을 높이는 것은 필요하지만, 시스템의 성능은 부품 사이의 인터페이스와 흐름에서 결정되는 경우가 많다. 부품만 잘 설계해 본 사람에게 갑자기 시스템 전체를 맡기고 부품 단위 가치만 묻는 것과 같다. 전체를 보는 사람과 전체를 설계하는 권한이 없으면, 팀 목표의 합은 조직의 결과가 되지 않는다(14장의 "합은 전체가 아니다").
시간은 팀 안이 아니라 팀 사이에 있다
일이 여러 팀을 지나가는 흐름에서 전체 리드타임은 세 부분으로 나뉜다. 각 팀이 실제로 일하는 처리 시간, 일이 다음 팀을 기다리는 대기 시간, 받은 산출물이 맞지 않아 되돌아가는 재작업 시간. 처리 시간이 전체에서 차지하는 비율을 흐름 효율(flow efficiency)이라고 한다. 사무·지식 업무에서는 이 비율이 낮은 경우가 많다. 일하는 시간보다 기다리는 시간이 훨씬 길다는 뜻이다.
이것이 팀 단위 AX 목표가 전체 성과로 이어지지 않는 수학적 이유다. 대기 시간과 재작업은 어느 한 팀의 것이 아니다. 앞 팀이 무엇을 어떤 형식으로 넘기는지, 뒤 팀이 언제 받아 가는지, 두 시스템이 연결되어 있는지에 달려 있다. 즉 인터페이스의 문제다.
흐름 시뮬레이터: 팀 안을 줄일까, 팀 사이를 줄일까
인터페이스는 누구의 목표인가: 산출물 계약과 플랫폼 API
소프트웨어 공학에는 "조직이 설계하는 시스템은 그 조직의 의사소통 구조를 닮는다"는 콘웨이의 법칙(Conway's law, 1968)이 있다. 팀 사이에 정의된 인터페이스가 없으면 업무 시스템도 팀마다 따로 놀고, 그 사이를 사람이 메일과 엑셀로 잇는다. 거꾸로 말하면, 팀 사이의 인터페이스를 명시적으로 설계하면 그 위에서 자동화와 AI가 흐름 전체를 이을 수 있다.
산출물 계약: 팀의 API
팀과 팀 사이를 오가는 산출물을 정의한 것을 이 책은 산출물 계약이라고 부른다. 5장의 데이터 계약을 팀 간 인계에 적용한 것이고, 조직 설계 분야에서 "팀 API"라고 부르는 생각과도 통한다(Skelton·Pais, Team Topologies, 2019). 거창할 필요는 없다. 다음 여섯 가지만 합의하면 된다.
| 항목 | 예시: 품질 → 생산기술 원인 확인 요청 |
|---|---|
| 무엇을 | 클레임 이슈 카드(불량 현상, 해당 LOT, 1차 분석 결과) |
| 어떤 형식으로 | 이슈 카드 시스템의 레코드. 표준 불량 코드·설비 ID 필수(4장) |
| 완성 조건 | 재현 조건과 사진, 측정값 기준 버전 포함. 없으면 접수하지 않는다 |
| 언제까지 | 접수 후 1영업일 안에 담당 지정, 3영업일 안에 1차 회신 |
| 받는 방법 | 메일이 아니라 시스템 알림과 API. 담당자 부재 시 대체 담당 자동 지정 |
| 바꾸는 방법 | 계약 변경은 양쪽 팀장 합의 후 버전을 올린다. 실이 계약 목록을 관리한다 |
계층별 책임: 인터페이스는 위로 갈수록 커진다
팀은 자기 팀 안을 설계할 수 있지만, 팀 사이의 계약은 양쪽 팀 위에 있는 사람이 정해야 한다. 이 원칙을 14장의 "각 계층은 그 계층만 할 수 있는 일을 목표로"와 겹쳐 보면 책임이 깔끔하게 나뉜다.
| 계층 | 설계 책임 | AX 목표 예시 |
|---|---|---|
| 파트·팀 | 팀 안의 업무, 계약을 지키는 산출물 | 이슈 카드 완성 조건 충족률 95%, 팀 내 반복 작업 자동화 |
| 실 | 산하 팀 사이의 산출물 계약, 흐름 리드타임 | 클레임 흐름 산출물 계약 5종 확정, 인계 대기 50% 단축 |
| 사업부 | 실 사이의 흐름, 사업부 시스템의 API·데이터 접근 정책 | 품질·생산 시스템의 조회 API 공개, 협력사 회신 시스템 연동 |
| 전사·플랫폼 조직 | 공통 플랫폼의 API 표준, 인증·권한, 커넥터 | 핵심 사내 플랫폼의 API 제공률, AI 에이전트용 표준 커넥터 |
플랫폼이 API를 열어 주지 않는다면
현실에서는 사내 플랫폼이 API를 제공하지 않는 경우가 많다. 화면으로만 조회할 수 있고, 데이터를 꺼내려면 엑셀 다운로드뿐이다. 이런 상태에서 "AX를 하라"고 하면 팀은 사람이 화면을 보고 옮겨 적는 일을 자동화하는 수밖에 없다. 몇 가지 선택지와 주의점을 정리한다.
| 방법 | 장점 | 주의 | 성격 |
|---|---|---|---|
| 화면 자동화(RPA) | 당장 가능 | 화면이 바뀌면 깨진다. 권한·감사 추적이 약하다 | 임시 다리. 폐기 계획과 함께 |
| 정기 내보내기·읽기 전용 복제 | 분석·검색에는 충분 | 최신성 지연, 등급·권한 관리 필요(12장) | 과도기 표준 |
| 플랫폼 조직에 API 요청 | 정식·안정적 | 대기열이 길다. 요청이 쌓여야 우선순위가 오른다 | 목표 상태 |
| AI 에이전트용 표준 커넥터 | 여러 AI 도구가 같은 방식으로 연결(10장의 MCP 같은 표준) | API가 먼저 있어야 한다. 권한 최소화 필수 | API 위의 한 층 |
팀이 플랫폼 API가 없어 화면 자동화로 우회했다면, 그 우회의 비용(만든 시간, 깨질 때마다 고치는 시간, 사람이 옮겨 적는 시간)을 기록해 실과 사업부에 올리자. 여러 팀의 우회 비용이 모이면 그것이 플랫폼 API 투자의 근거가 된다. API 제공은 팀이 아니라 플랫폼을 가진 조직의 AX 목표여야 한다. 팀에게 API 없는 AX를 요구하는 것은, 인터페이스를 주지 않고 부품끼리 알아서 붙으라고 하는 것과 같다.
효율은 언제 돈이 되나: 가치 실현은 누구의 몫인가
회사 차원에서 사업 가치와 돈을 따지는 것은 당연하다. 문제는 현장에서 만든 효율, 예를 들어 "보고서 작성 시간 주 3시간 단축"이 그 자체로는 돈이 아니라는 데 있다. 절감된 시간은 해방된 용량(freed capacity)일 뿐이다. 그 용량이 돈이 되려면 누군가 그것으로 무엇을 할지 결정해야 한다. 결정이 없으면 해방된 시간은 회의와 다른 잡무 사이로 조용히 흩어진다.
그래서 "아래의 효율을 돈으로 바꾸는 것은 누구의 몫인가"에 대한 이 책의 답은 이렇다. 그 돈을 실제로 움직일 수 있는 결정권자의 몫이다. 보통은 인력 계획과 예산을 가진 사업부, 경우에 따라 예산을 가진 실이다. 팀이나 실의 취합 담당자는 절감 시간을 더할 수는 있지만 돈으로 바꿀 수는 없다. 더하기만 한 숫자를 돈으로 표기하면 장부상 가치만 커진다(14장의 증거 사다리).
| 누가 | 무엇을 하나 | 하지 말아야 할 것 |
|---|---|---|
| 실무자·팀 | 무엇이 없어졌는지(시간·단계·오류)와 해방된 시간을 어디에 썼는지 기록 | "내 개선은 연 몇 억 원" 같은 개인 단위 금액 환산 |
| 실 | 여러 팀의 해방 용량을 흐름 단위로 모으고, 재배치 제안을 만든다 | 팀 숫자를 그대로 더해 금액으로 올리기 |
| 사업부 | 분기마다 "가치 실현 결정": 물량 흡수, 외주 축소, 재배치를 실제로 정하고 금액을 기록 | 결정 없이 목표 금액만 아래로 나눠 주기 |
| 재무·경영기획 | 실현 경로별 환산 기준을 하나로 정해 제공 | 팀마다 다른 환산 방식 방치 |
가치 실현 계산기: 장부상 가치와 실현된 가치
중간에서 환산 방법을 모르면 "각자 금액으로 적어 오라"는 요청이 개인에게 내려간다. 개인은 자기 일이 얼마의 돈이 되는지 말하기 어렵고, 그래서 숫자를 지어내거나 의욕을 잃는다. 대안은 간단하다. 개인과 팀은 운영의 언어(없앤 시간·단계·오류, 해방 용량의 사용처)로 기록하고, 금액은 사업부가 분기마다 내리는 가치 실현 결정에서만 기록한다. 이렇게 하면 금액은 줄어 보일 수 있지만, 그 숫자는 재무가 믿는 숫자가 된다.
인프라가 먼저인가: 팀에 AX를 요구하기 전에 깔아야 할 바닥
"각 팀에 AX를 요구하기 전에 회사가 인프라부터 갖춰야 하지 않나?" 이 질문에 대한 이 책의 답은 절반은 그렇다이다. 어느 절반이 맞는지 구분하는 것이 중요하다. 양쪽 극단이 모두 실패하기 때문이다.
바닥 없이 팀에 요구할 때
- 승인된 도구가 없어 개인 계정으로 우회한다(섀도 AI, 12장)
- API가 없어 팀마다 화면 자동화를 만들고, 화면이 바뀔 때마다 깨진다
- 팀마다 다른 도구와 데이터 사본이 생긴다
- 시간 배정이 없어 결국 개인의 야근으로 메운다
인프라를 다 만든 뒤에 시작할 때
- 전사 플랫폼 구축에 수년이 걸리고 그동안 성과가 없다
- 쓸 사람의 요구 없이 만든 플랫폼은 완성되어도 쓰이지 않는다
- 완성 시점에는 기술이 이미 바뀌어 있다
- 현장은 기다리다 지쳐 각자 우회한다(17장의 수평 접근)
해법은 인프라를 두 층으로 나누는 것이다. 아래층은 어느 팀도 혼자 만들 수 없고, 모든 팀이 공통으로 필요한 최소 바닥이다. 이것은 팀에 무엇인가를 요구하기 전에 회사가 먼저 깔아야 한다. 그 위층, 즉 특정 업무에 필요한 데이터 파이프라인, 연동, 전용 모델 같은 인프라는 등대 프로젝트와 함께 자라게 한다. 바닥은 먼저, 나머지는 쓰면서.
최소 공통 바닥의 목록
| 바닥 항목 | 최소 수준(예시) | 없으면 현장에서 생기는 일 |
|---|---|---|
| 승인된 AI 도구 | 전 직원이 업무 계정으로 쓰는 생성형 AI, 데이터 등급별 허용 범위 | 개인 계정·개인 기기로 우회 |
| 계정·권한·데이터 등급 | 통합 인증, 문서·데이터에 등급 표시, 권한이 검색·AI에 그대로 적용 | AI 도입마다 보안 심사가 처음부터 반복 |
| 데이터 접근 경로 | 핵심 업무 시스템의 읽기 전용 조회 경로(복제본·조회 API) | 엑셀 다운로드와 수작업 취합 |
| API·커넥터 표준 | 신규·개편 시스템은 API 제공을 필수로, AI 도구용 표준 커넥터 방식 결정 | 팀마다 화면 자동화, 깨지기 쉬운 연결 |
| 컴퓨트와 사용 예산 | 사내 AI 서비스의 충분한 처리 용량, 팀별 사용량 상한과 증액 절차 | 느려서 안 쓰거나, 쓰다 막힌다 |
| 샌드박스 | 비민감 데이터로 누구나 만들어 볼 수 있는 공간과 졸업 경로(20장) | 시도 자체가 승인 대상이 된다 |
| 지원 창구 | 막혔을 때 물어볼 CoE, 분기마다 상주하는 FDE(13장) | 잘하는 몇 사람에게 질문이 몰린다 |
| 시간 | 참여자 업무 시간의 공식 배정과 그만큼 덜어 준 일 | "본업 + AX"가 야근이 된다 |
목록을 보면 대부분 기술보다 정책과 결정에 가깝다는 것을 알 수 있다. 승인 도구를 정하는 일, 데이터 등급을 붙이는 규칙, "신규 시스템은 API 필수"라는 원칙, 시간 배정은 큰 돈보다 위에서의 결정이 필요하다. 그래서 "인프라가 없어서 못 한다"의 상당 부분은 사실 "결정이 없어서 못 한다"이다. 바닥에 드는 돈을 컴퓨트·플랫폼·사람 사이에 어떻게 나눌지는 17장, 바닥 위에서 일할 사람의 역할이 작동하는 조건(권한·시간·예산·지원·평가)은 13장에서 다룬다.
요구는 바닥만큼만
회사가 팀에 요구하는 AX의 수준과, 회사가 깔아 준 바닥의 수준은 짝이 맞아야 한다. 바닥보다 높은 수준을 요구하면 그 차이는 현장의 우회와 야근으로 채워진다.
| 팀에 요구하는 수준 | 그 전에 회사가 깔아야 할 바닥 |
|---|---|
| ① 개인 업무에 AI 활용 문서 요약, 초안 작성, 검색 | 승인된 AI 도구, 데이터 등급별 사용 기준(한 줄 안내), 기본 교육 |
| ② 팀 업무 자동화 반복 작업 제거, 팀 내 데이터 정리 | ① + 데이터 접근 경로, 샌드박스, 지원 창구, 공식 배정 시간 |
| ③ 팀 간 흐름의 AX 인계 자동화, 흐름 리드타임 단축 | ② + 시스템 API, 산출물 계약 관리 주체(실), 플랫폼 조직의 API 목표 |
| ④ 에이전트에 의한 실행 시스템에 쓰고 행동하는 AI | ③ + 최소 권한 설계, 감사 로그, 평가 세트와 모니터링, 사람의 승인 지점(10장·12장) |
팀의 AX 목표를 세울 때 "이 목표를 달성하려면 회사가 무엇을 먼저 제공해야 하는가"를 함께 적게 하자. 예: "클레임 데이터 조회 API(사업부, 2분기까지)". 전제 조건이 기한까지 제공되지 않으면 목표를 조정한다. 이렇게 하면 바닥의 공백이 현장의 실패로 기록되지 않고, 바닥을 깔 책임이 있는 조직의 과제로 드러난다. 14장의 캐치볼에서 아래가 위에 요구할 수 있는 가장 구체적인 항목이 바로 이것이다.
인프라 조직의 성과를 "구축 완료"로 재면 아무도 쓰지 않는 플랫폼이 완성된다. 바닥을 까는 조직의 성과는 현장이 그 위에서 실제로 만든 것, 즉 사용률, 재사용 건수, 우회 비용의 감소로 재야 한다. 바닥은 첫 등대 프로젝트와 같은 분기에 시작하고, 그 프로젝트가 막히는 곳을 바닥의 다음 우선순위로 삼는다.
전체를 보는 사람이 확인할 것
실장, 사업부장, AX 추진 조직이 분기마다 확인할 질문을 모았다. 흐름, 인터페이스, 가치 실현, 바닥의 순서다. 팀 목표의 달성 여부보다 이 질문들의 답이 조직의 AX 상태를 더 잘 보여 준다.
- 우리 조직의 핵심 흐름 3개를 처음부터 끝까지 따라가 본 적이 있는가? 처리 시간과 대기 시간의 비율을 아는가?
- 팀 사이 산출물 중 계약으로 정의된 것은 몇 개인가? 계약 목록은 누가 관리하는가?
- 팀들이 API가 없어 우회하는 곳은 어디이며, 그 우회 비용은 얼마인가? 플랫폼 조직의 목표에 API 제공이 들어 있는가?
- 지난 분기 해방된 용량 중 어디로 갔는지 결정된 비율은 얼마인가? 가치 실현 결정을 누가 내렸는가?
- AX 참여자의 업무 시간 중 공식 배정된 비율은 얼마이고, 그만큼 덜어 준 일은 무엇인가?
- 팀에 요구한 AX 수준에 맞는 바닥을 회사가 제공했는가? 팀 목표의 전제 조건 중 기한을 넘긴 것은 무엇인가?
- 바닥을 깐 조직의 성과를 "구축 완료"가 아니라 사용률·재사용 건수·우회 비용 감소로 재고 있는가?
- 바닥의 가장 큰 공백(데이터·API·사람·컴퓨트)에 이번 분기 투자가 가는가(17장)? 새 역할마다 덜어 준 일이 있는가(13장)?
핵심 정리
- 여러 팀을 지나는 업무에서 시간의 대부분은 팀 안이 아니라 팀 사이(대기·재작업)에 있다. 흐름 효율이 낮으면 팀 내부 효율화만으로는 전체 리드타임이 크게 줄지 않는다.
- 팀 사이의 산출물 계약(무엇을, 형식, 완성 조건, 기한, 받는 방법, 변경 방법)은 팀의 API다. 계약은 양쪽 팀 위의 계층(실)이, 시스템 API와 데이터 접근은 사업부와 플랫폼 조직이 목표로 가져야 한다.
- API가 없을 때 화면 자동화는 임시 다리일 뿐이다. 우회 비용을 기록해 올리는 것이 플랫폼 투자의 근거가 된다.
- 절감 시간은 해방된 용량이며, 예산·인력·계획을 바꾸는 결정이 있어야 돈이 된다. 금액 환산은 그 결정을 내릴 수 있는 사업부의 몫이고, 개인과 팀은 운영의 언어로 기록한다.
- 팀에 AX를 요구하기 전에 어느 팀도 혼자 못 만드는 최소 공통 바닥(승인 도구, 권한·등급, 데이터 접근, API 표준, 컴퓨트, 샌드박스, 지원, 시간)을 회사가 먼저 깔고, 요구 수준은 바닥만큼만 올린다. 그 위의 인프라는 등대 프로젝트와 함께 자라게 한다.
- "인프라가 없어서 못 한다"의 상당 부분은 "결정이 없어서 못 한다"이다. 바닥을 까는 조직의 성과는 현장이 그 위에서 실제로 만든 것(사용률, 재사용, 우회 비용 감소)으로 잰다.
확인 퀴즈
1. 다섯 팀이 각자 처리 시간을 40% 줄였는데 전체 리드타임은 10%만 줄었다. 가장 그럴듯한 설명은?
2. 품질팀과 생산기술팀 사이의 산출물 계약을 정의하고 관리할 책임은 누구에게 있는가?
3. 사내 플랫폼이 API를 제공하지 않아 팀이 화면 자동화(RPA)로 데이터를 옮기고 있다. 바람직한 대응은?
4. 사업부 전체에서 연 12,000시간의 업무 시간이 절감되었다. 이것이 실제 금액이 되기 위해 꼭 필요한 것은?
5. 회사가 "모든 팀은 팀 간 인계를 AI로 자동화하라"는 목표를 내렸다. 그런데 사내 시스템에 API가 없고 승인된 AI 도구도 정해지지 않았다. 가장 적절한 판단은?
6. 전사 플랫폼 조직이 승인 도구·데이터 접근 경로·API 표준을 깔았다. 이 조직의 성과를 재는 지표로 가장 적절한 것은?