Mapping Your Workflows: 업무 흐름 전체를 그린 회사가 AI로 매출 1.9배를 낸 실험

AI 성과는 도구보다 어디에 쓸지 찾는 데서 갈립니다. 업무 흐름을 처음부터 끝까지 그려 병목을 찾고 그 단계와 앞뒤 단계를 함께 다시 짠 뒤 옮겨 간 병목을 다시 재는 순서를 갖춰야 성과가 회사 숫자로 이어집니다.

요약

HBR은 INSEAD의 Hyunjin Kim, Dahyeon Kim, Rembrand Koning이 진행한 현장 실험을 소개합니다. 연구진은 INSEAD의 3개월 액셀러레이터에 참여한 초기 고성장 스타트업 515곳을 무작위로 두 그룹에 나눴습니다. 두 그룹 모두 약 2만 5,000달러어치 API 크레딧과 협력사 도구, 매주 3시간의 기술 교육을 똑같이 받았습니다. 다른 것은 매주 60분짜리 워크숍 하나였습니다. 처리군 255곳은 AI 네이티브 회사가 업무를 어떻게 다시 짰는지 사례를 공부했고 대조군 260곳은 고객 정의와 린 검증 같은 일반 창업 교육을 들었습니다. 연구진은 이 차이가 풀려고 한 문제를 mapping problem(AI가 회사의 어느 공정에서 어떻게 가치를 내는지 찾는 문제)이라고 부릅니다.

10주 동안 처리군은 AI 활용 사례를 평균 2.7개(44%) 더 찾았고 과업을 12% 더 끝냈습니다. 제품을 출시할 확률이 4.7%p, 유료 고객을 확보할 확률이 11%p(18%) 높았고 매출은 대조군의 1.9배였습니다. 그런데도 외부에 요청한 자본은 39.5%(약 22만 달러) 적었고 기술 인력 수요는 그대로였습니다. 연구진은 이유를 이렇게 정리합니다. “AI search is local, but value is systemic.” 한 단계만 빠르게 하면 병목이 다음 단계로 옮겨 갈 뿐이라, 생산 과정 전체에 AI를 대응시켜야 성과가 납니다. 아래에서는 이 결과를 다섯 가지 메커니즘으로 풀고 업무 흐름 지도를 실제로 만드는 기술 디테일과 10주 실행 계획을 덧붙입니다.

핵심 메커니즘

Mapping Problem: 도구가 아니라 쓸 곳 찾기가 병목

Mapping problem은 AI 모델이 있어도 회사의 어느 단계에서 가치를 내는지 몰라 성과로 이어지지 않는 문제입니다. 이 실험에서 두 그룹은 같은 모델, 같은 크레딧, 같은 기술 교육을 받았습니다. 그래서 성과 차이는 기술 접근성이 아니라 활용 사례를 얼마나 넓게 찾았느냐로 설명됩니다. 연구진의 도구변수 추정으로는 활용 사례가 하나 늘 때 완료 과업이 0.85개, 매출이 26% 늘었습니다. 모델 도입은 끝났는데 숫자가 움직이지 않는 회사라면 먼저 이 단계를 점검합니다. 반대로 아직 쓸 만한 도구가 없는 회사라면 이 메커니즘보다 도입이 먼저입니다.

Local Search와 Systemic Value: 한 단계만 빠르면 병목은 옮겨 간다

사람은 AI를 쓸 곳을 찾을 때 자기 손에 닿는 일부터 봅니다. 연구진은 이를 local search(가까운 과업 위주로만 찾는 탐색)라고 부릅니다. 업무가 순서대로 이어지는 공정에서는 한 단계만 빨라져도 전체 산출은 늘지 않습니다. 느린 다음 단계가 그대로 남기 때문입니다. 연구진은 코드를 빨리 쓰게 되면 그다음 제약이 고객 피드백이 된다는 예를 듭니다. 그래서 흐름 전체를 그려 병목을 찾고 그 단계와 앞뒤를 함께 바꾼 다음, 바꾼 뒤에는 새로 생긴 병목을 다시 찾는 순서가 필요합니다. 가상 예시로 설비 회사의 견적 작성만 AI로 줄이면 설계 검토 대기열만 길어집니다. 설계 검토까지 함께 바꾸면 이번에는 승인 단계가 다음 병목으로 드러납니다.

Peer Case Exposure: 남이 재설계한 사례가 탐색 범위를 넓힌다

실험의 처리는 도구가 아니라 지식이었습니다. 처리군은 다른 회사가 AI를 중심으로 업무를 다시 짠 사례를 매주 봤고 그 결과 더 많은 기능에서 활용 사례를 찾았습니다. 두 그룹의 차이가 가장 컸던 곳은 제품 개발, 제품·전략 설계, 업무 자동화 같은 운영 영역입니다. 조사, 글쓰기, 영업 초안처럼 누구나 먼저 떠올리는 용도에서는 두 그룹이 비슷했습니다. 사례 학습은 사내에서 AI를 이미 쓰는데 용도가 문서 작성에 머물러 있을 때 효과가 큽니다. 업종이 너무 다른 사례만 보면 대입이 어렵기 때문에, 같은 업무 구조(예: 주문에서 청구까지)를 가진 사례를 고릅니다.

Human Glue 제거: 시스템 사이 수작업 인계를 파이프라인으로

Human glue는 시스템과 시스템 사이를 사람이 손으로 잇는 구간입니다. 한 화면에서 내려받아 엑셀로 옮기고 다른 시스템에 다시 입력하는 일이 대표적입니다. 연구진은 개별 입력 작업 하나를 자동화하기보다 이런 구간이 이어진 흐름 전체를 자동 파이프라인으로 바꾸라고 권합니다. 워크숍 사례였던 FazeShift는 매출채권 업무 8단계 전체를 자동화해 단계 사이 수작업 인계를 없앴습니다. 단계 수가 많고 단계마다 사람이 데이터를 옮기는 백오피스 흐름에 잘 맞습니다. 판단이 많이 필요한 예외 처리는 파이프라인 안에 사람 확인 지점으로 남깁니다.

Right-Tail Effect: 효과는 상위 기업에서 가장 컸다

이 연구에서 매출과 투자 관련 효과는 평균보다 분포의 위쪽에서 컸습니다. 90번째와 95번째 백분위에서 효과가 가장 컸습니다. 연구진은 AI가 평균 기업을 조금 낫게 하기보다 잘하는 기업의 성과 상한을 넓힌다고 해석합니다. 동시에 처리군은 더 빨리 성장하면서도 자본과 인력을 그만큼 늘리지 않았습니다. 외부 자본 요청은 39.5% 낮았고 기술 인력 수요는 변하지 않았습니다. 경영진이 AI 과제의 성과를 평균값 하나로만 보면 이 효과를 놓칩니다. 팀이나 사업부별 분포를 함께 봐야 어디서 크게 터졌는지 보입니다.

통념과 다른 주장

저자가 든 사례

사례 1. 515개 스타트업 현장 실험

상황	한 일	결과	연결
같은 AI를 쓰는데 성과가 회사 숫자로 이어지는지 근거가 없음	515곳을 무작위 배정, 처리군 255곳에만 AI 네이티브 회사의 재설계 사례 워크숍	활용 사례 +44%, 과업 +12%, 유료 고객 확보 +18%, 매출 1.9배, 자본 요청 −39.5%	Mapping Problem, Peer Case Exposure

사례 2. 워크숍에서 다룬 AI 네이티브 회사 네 곳

회사	상황·한 일	결과	연결
Gamma	제품 개발 주기를 줄임	PM 한 명이 엔지니어링 팀 없이 기능을 계속 출시	Local Search와 Systemic Value
Ryz Labs	AI로 시제품을 만듦	여러 시제품을 동시에 제작	Peer Case Exposure
FazeShift	매출채권 업무 8단계 전체를 자동화	단계 사이 수작업 인계 제거	Human Glue 제거
Ranger	서비스 제공을 자동화	고마진 소프트웨어처럼 운영, 벤처 투자 유치를 미룸	Right-Tail Effect(자본 절감)

기술 디테일: 업무 흐름 지도를 AI로 만든다면

아래 필드명과 설정값, 숫자는 모두 원문에 없는 가상 예시입니다. 연구가 말하는 흐름 전체 대응을 실제로 돌릴 때 필요한 것을 정리했습니다.

흐름 전체를 그리려면(Local Search와 Systemic Value) 사람 기억에만 기대지 말고 세 가지 자료를 함께 씁니다. 업무 매뉴얼(SOP), 실무자 인터뷰 녹취, 그리고 ERP·CRM·결재 시스템의 이벤트 로그입니다. LLM은 temperature 0으로 SOP와 녹취를 읽어 단계마다 아래 JSON을 채웁니다. 같은 문서로 3회 실행해 단계 목록이 다르게 나오면 그 구간은 실무자 확인 대상으로 표시합니다. 대기 시간과 처리 시간은 LLM이 추정하지 않고 이벤트 로그의 타임스탬프로 계산합니다. 로그가 없는 단계는 wait_hours를 비워 두고 인터뷰 값임을 source 필드에 적습니다.

{
  "flow_id": "quote-to-cash",
  "step_id": "S03",
  "name": "설계 검토",
  "actor": "설계팀",
  "system_in": "CRM",
  "system_out": "PLM",
  "handoff": "human_glue",
  "wait_hours_p50": 46,
  "work_hours_p50": 3,
  "source": "event_log",
  "ai_candidate": "사양 비교 초안",
  "confidence_runs": [1, 1, 1]
}

병목을 고르려면 단계마다 wait_hours_p50과 work_hours_p50을 더한 리드타임, 그리고 handoff가 human_glue인지를 함께 봅니다. 리드타임 상위 3개 단계 가운데 사람 인계가 있는 단계를 1순위로 둡니다. 순위는 규칙으로 계산하고 LLM에는 후보 단계의 개선 아이디어 초안만 맡깁니다. 모델이 병목 자체를 판정하게 두면 문서에 자주 등장하는 단계를 과대평가하기 쉽습니다.

재설계 뒤 병목을 다시 재려면(병목 이동) 바꾸기 전 2주치 리드타임을 기준선으로 고정하고 바꾼 뒤 같은 필드로 2주를 다시 잽니다. 흐름 끝의 처리량(예: 주당 청구 건수)이 늘지 않았다면 병목이 다른 단계로 옮겨 간 것입니다. 이때 새 1위 단계를 다시 지도에 올려 같은 루프를 돌립니다.

활용 사례가 늘었는지 추적하려면(Mapping Problem) 연구처럼 주간 보고를 구조화합니다. 팀마다 use_case_id, function(제품 개발·운영·영업·재무 등), flow_id, step_id, status, tasks_done_internal, tasks_done_external을 매주 한 행씩 남깁니다. 이렇게 두면 활용 사례가 어느 기능에 몰리는지, 사내 과업과 고객 접점 과업 중 어디가 움직였는지 따로 볼 수 있습니다.

실패하는 경우	대응 (가상 예시)
SOP와 실제 작업 순서가 다름	이벤트 로그 순서를 우선하고 차이 나는 구간만 실무자 인터뷰
실행마다 LLM이 뽑은 단계 목록이 다름	3회 실행 결과가 일치하는 단계만 확정, 나머지는 사람 확인
한 단계를 바꿨는데 흐름 끝 처리량이 그대로	리드타임을 다시 재 새 병목을 찾고 앞뒤 단계를 함께 재설계
활용 사례가 문서 작성에만 몰림	같은 업무 구조의 외부 재설계 사례를 골라 다시 학습
사람 인계를 없앤 뒤 예외 건이 쌓임	예외 조건을 파이프라인 안 사람 확인 지점으로 명시

현업 실행 디테일: 누가, 언제, 무엇을

연구의 10주 창과 주 1회 사례 학습을 빌려 사내 실행 계획으로 옮기면 아래와 같습니다. 역할, 일정, 기준은 모두 가상 예시입니다.

역할	맡는 일 (가상 예시)
사업 오너(흐름을 책임지는 본부장·팀장)	대상 흐름 하나 선정, 흐름 끝 지표 확정, 진행 판정
프로세스 담당(PI·혁신팀)	현행 흐름 인터뷰와 지도 초안, 병목 순위 정리
AI 엔지니어	구조화 추출·리드타임 측정 도구, 자동 파이프라인 구축
현업 실무자	실제 작업 방식과 예외 사례 설명, 재설계안 검증
재무	기준선 지표 확인, 재측정 결과 검증

시작 전 준비물은 다섯 가지입니다. 대상 흐름의 SOP, 최근 3개월치 이벤트 로그, 흐름 끝 지표(처리량·리드타임·매출 연결 지표)의 현재 값, 실무자 인터뷰 대상 5~8명, 같은 업무 구조를 가진 외부 재설계 사례 4건입니다.

기간	할 일	산출물
1~2주	주 1회 60분 사례 학습, 대상 흐름 선정, 기준선 측정	사례 요약 4건, 기준선 지표
3~4주	인터뷰·로그로 현행 흐름 지도 작성, 병목 순위	단계별 JSON, 병목 상위 3개
5~7주	1순위 병목과 앞뒤 단계 함께 재설계, human glue 구간 파이프라인화	재설계안, 동작하는 파이프라인
8~10주	같은 지표로 재측정, 다음 병목 확인, 판정 회의	재측정 보고서, 다음 흐름 후보

확인 질문은 이렇게 준비합니다. 이 흐름은 어디서 시작해 어디서 끝납니까? 단계 사이에서 사람이 데이터를 옮기는 곳은 어디입니까? 일이 가장 오래 기다리는 단계는 어디이며 그 이유는 무엇입니까? 지금 AI를 쓰는 곳은 문서 작성 말고 어디가 있습니까? 이 단계가 두 배 빨라지면 바로 다음 단계는 그 물량을 받아낼 수 있습니까?

진행 판정 기준의 출발점은 세 가지입니다. 활용 사례가 기능 3곳 이상에서 나왔는지, 흐름 끝 처리량이 기준선보다 늘었는지, human glue 구간이 절반 이하로 줄었는지입니다. 처리량이 그대로면 실패로 보지 않고 병목 재측정으로 돌아갑니다.

AX 적용 제언. 국내 기업에 이 연구가 주는 메시지는 AI 교육 예산을 프롬프트 강의에서 업무 흐름 지도 작업으로 옮기라는 것입니다. 첫 대상은 주문에서 청구까지, 견적에서 수주까지처럼 단계가 많고 시스템 사이 수작업 인계가 많은 흐름이 좋습니다. 과제의 주인은 IT가 아니라 그 흐름의 끝 지표를 책임지는 사업 오너로 둡니다. 사례 학습은 같은 업무 구조를 가진 외부 사례로 고릅니다. 사내에서 먼저 성공한 흐름도 다음 팀의 사례로 씁니다. 대기업에 옮길 때는 결재 단계와 부서 사이 인계도 지도에 하나의 단계로 그려 둡니다.

원문 사례

항목	내용
원문	Harvard Business Review, 2026년 11월 온라인 게재(2026년 11·12월호 수록)
바탕 연구	Hyunjin Kim, Dahyeon Kim, Rembrand Koning, 「Mapping AI into Production: A Field Experiment on Firm Performance」, INSEAD Working Paper 2026/20/STR (2026.3.30)
대상	INSEAD 3개월 액셀러레이터의 초기 고성장 스타트업 515곳, 처리군 255·대조군 260
공통 지원	API 크레딧 약 2만 5,000달러와 협력사 도구, 주 3시간 기술 교육
처리	주 1회 60분 워크숍에서 AI 네이티브 회사(Gamma, Ryz Labs, FazeShift, Ranger)의 재설계 사례 학습
기간·이탈	10주 추적, 이탈 약 1.6%
활용 사례	평균 2.7개(44%) 증가. 제품 개발, 제품·전략 설계, 운영 자동화에서 차이 큼
과업	완료 과업 12% 증가. 사내 과업 중심, 고객 발굴·투자 피칭 같은 외부 과업은 변화 없음
시장 성과	제품 출시 확률 +4.7%p, 유료 고객 확보 확률 +11%p(18%), 매출 1.9배
도구변수 추정	활용 사례 1개당 완료 과업 +0.85개, 매출 +26%
투입	외부 자본 요청 39.5%(약 22만 달러) 감소, 기술 인력 수요 변화 없음
분포	효과는 90·95번째 백분위에서 가장 큼

핵심 개념

field experiment

실제 사업 현장에서 대상을 무작위로 나눠 처리 효과를 재는 실험입니다.

instrumental variable

무작위 배정을 지렛대로 써서 활용 사례 한 개가 성과에 주는 효과를 따로 떼어 추정하는 방법입니다.

AI-native firm

처음부터 AI를 전제로 업무 흐름을 짠 회사입니다.

accounts receivable

판매 후 아직 받지 못한 대금(매출채권)을 관리하고 회수하는 업무입니다.

event log

시스템이 남기는 작업 기록입니다. 건마다 어떤 단계를 언제 거쳤는지 담겨 있어 프로세스 마이닝의 재료가 됩니다.

percentile

전체를 줄 세웠을 때 아래에서부터의 위치입니다. 90번째 백분위는 상위 10% 경계입니다.

내 메모

TODO: 내 생각 추가

원문은 Harvard Business Review의 「For Real Performance Gains with AI, Start by Mapping Your Workflows」(2026년 11월 게재)입니다. HBR 본문은 이번 작업에서 열 수 없어, 기사가 바탕으로 삼은 INSEAD 연구(Hyunjin Kim, Dahyeon Kim, Rembrand Koning, 「Mapping AI into Production: A Field Experiment on Firm Performance」, INSEAD Working Paper 2026/20/STR)의 INSEAD 공개 초록과 이 논문을 정리한 공개 해설(antoinebuteau.com)로 내용을 확인했습니다. 요약, 핵심 메커니즘의 연구 내용, 통념과 다른 주장, 사례, 원문 사례 표는 이 자료를 AX Review가 다시 정리했습니다. 핵심 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 실패 대응 표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 HBR 원문 페이지에서, 연구 전문은 SSRN 논문 페이지에서 볼 수 있습니다.