"AI한테 시키면 빨라진다는데, 정작 나는 왜 더 정신없어졌을까요?"
지난 글 개발자 집중 환경 만들기 — 산업공학으로 푸는 딥 워크 설계법에서, 집중을 막는 건 의지박약이 아니라 흐름이 막힌 시스템이라고 말씀드렸습니다. 그랬더니 이런 질문을 받았습니다. "그럼 AI로 그 병목을 풀 수 있나요?"
안녕하세요, 자바파커입니다. 결론부터 말씀드리면 — 네, 풀 수 있습니다. 단, "AI한테 일을 더 시키는" 방식으로는 안 됩니다. 산업공학의 렌즈로 보면, AI는 "더 빨리 만드는 도구"가 아니라 "흐름의 모양을 바꾸는 도구" 일 때 진짜 효과가 납니다. 오늘은 1편에서 진단한 병목들을 AI로 공략하는 5가지 전략과, AI가 오히려 새로운 병목이 되는 함정까지 솔직하게 다뤄보겠습니다.
큰 그림 — AI는 "처리율"이 아니라 "흐름"을 바꾼다
1편에서 리틀의 법칙을 기억하시나요?
평균 완료 시간 = 진행 중인 작업 수(WIP) ÷ 처리율(Throughput)많은 사람이 AI를 처리율(Throughput)을 높이는 도구로만 씁니다. "코드를 더 빨리 뽑아줘." 그런데 산업공학이 100년간 배운 교훈은 이겁니다 — 병목이 아닌 곳의 처리율을 높이면, 전체는 1초도 빨라지지 않고 재공품(WIP)만 쌓인다.
그래서 핵심 질문은 "AI로 무엇을 더 빨리 할까"가 아니라 "AI를 내 흐름의 어느 지점에 투입할까" 입니다. 아래 5가지 전략은 모두 이 질문에 대한 답입니다.
| 1편에서 진단한 병목 | AI로 공략하는 방법 |
|---|---|
| 컨텍스트 스위칭 (SMED) | AI가 맥락을 대신 보관 → 복귀 셋업 시간 흡수 |
| 병목 = 리뷰/사람 (제약이론) | AI를 정확히 병목 지점에 투입 |
| 가동률 과부하 (대기행렬) | AI가 변동(인터럽트)을 흡수해 여백 보존 |
| 7대 낭비 (무다) | 대기·과잉가공·불량을 AI가 직접 제거 |
| 측정 부재 (DMAIC) | AI가 흐름 데이터를 분석·가시화 |
1. 컨텍스트를 AI에게 "보관"시켜라 — SMED의 디지털 버전
1편에서 가장 큰 낭비는 컨텍스트 스위칭이었습니다. 방해받은 뒤 원래 작업으로 돌아오는 데 평균 약 23분. 이 셋업 시간을 줄이는 게 SMED의 핵심이었죠.
AI 코딩 에이전트의 진짜 가치는 "코드를 빨리 쓰는 것"이 아니라 "내가 자리를 비운 사이에도 맥락을 붙들고 있는 것" 입니다. 사람의 작업 기억(working memory)은 인터럽트 한 번에 날아가지만, AI는 그렇지 않습니다.
현장 적용
- 복귀 셋업을 AI에게: 회의 다녀온 뒤 "내가 어디까지 했지?" 대신, AI에게 "방금까지 작업 맥락과 다음 할 일을 3줄로 요약해줘" 라고 묻습니다. 23분짜리 복구가 30초로 줄어듭니다.
- 인터럽트를 AI가 1차 흡수: "이 함수 어디서 쓰여?" 같은 잔질문을 동료 대신 AI에게 던지면, 내 몰입과 동료의 몰입을 동시에 지킵니다.
- 세션 메모리 활용: Claude Code 같은 에이전트는 작업 맥락을 세션에 유지합니다. 자리를 떠나기 전 "다음 할 일"을 에이전트에게 남겨두면, 그게 곧 SMED의 "외부 셋업(off-line setup)" 이 됩니다.
2. AI를 "병목 지점"에 정확히 투입하라 — 제약이론
제약이론의 핵심은 "병목이 아닌 곳을 최적화하면 낭비" 였습니다. AI도 똑같습니다. 코드 작성이 병목이 아닌데 AI로 코드만 빨리 뽑으면, 그 코드는 리뷰 대기 줄에 더 빨리, 더 많이 쌓일 뿐입니다.
그래서 먼저 물어야 합니다 — 내 흐름에서 가장 오래 막히는 곳은 어디인가? 거기에 AI를 투입합니다.
| 당신의 병목이… | AI 투입 지점 |
|---|---|
| 리뷰 대기가 길다 | AI 1차 리뷰 — 스타일·버그·테스트 누락을 사람 리뷰 전에 거른다 |
| 보일러플레이트에 시간을 뺏긴다 | 반복 코드·테스트 코드·마이그레이션을 AI에게 위임 |
| 디버깅에서 막힌다 | 스택트레이스·로그를 AI에게 던져 가설 후보를 받는다 |
| 문서·릴리스 노트가 밀린다 | 커밋 히스토리 기반 초안을 AI가 생성 |
현장 적용 — 골드랫의 "제약을 격상(elevate)하라"의 AI 버전입니다. 리뷰어가 병목이면 AI에게 리뷰어를 늘리는 게 아니라, 리뷰어의 부담을 더는 역할을 줍니다. PR이 올라오기 전에 AI가 사소한 지적을 다 끝내두면, 사람 리뷰어는 설계와 의도에만 집중할 수 있습니다.
3. AI로 "변동"을 흡수해 여백을 지켜라 — 대기행렬 이론
1편에서 가장 반직관적인 개념이 가동률 80% 룰 이었습니다. 여백(slack)이 없으면 작은 충격 하나에 모든 일정이 무너진다는 것. 여기서 무너뜨리는 주범은 보통 예측 불가능한 변동 — 갑작스러운 질문, 긴급 버그, 자잘한 요청입니다.
대기행렬 이론에서 시스템을 망치는 건 평균 부하가 아니라 변동성(variability) 입니다. 그리고 AI가 가장 잘 흡수하는 게 바로 이 변동성입니다.
현장 적용
- 변동 수요를 AI 큐로 우회: "이 API 어떻게 쓰지?", "이 에러 뭐지?" 같은 예측 불가 잔업을 AI가 1차로 받아내면, 사람의 캘린더에는 계획된 일만 남습니다.
- AI가 버퍼 역할: 사람을 100%로 채우는 대신, 변동분을 AI에게 흘려보내 인간 가동률을 70~80%로 유지합니다. 그 여백이 곧 시스템 안정성입니다.
- 주의: AI 출력에는 검증이 따라붙습니다. 변동을 AI로 우회했다고 검증까지 사라지진 않습니다(→ 5번 함정 참고).
4. 7대 낭비를 AI로 제거하라 — 무다(Muda)의 자동 소거
1편의 7대 낭비 표를 다시 꺼내, 각 낭비에 AI 대응책을 붙여보겠습니다.
| 7대 낭비 | 개발에서의 모습 | AI 대응책 |
|---|---|---|
| 대기 | 리뷰·답변을 기다린다 | AI 1차 리뷰·즉답으로 대기 큐 단축 |
| 과잉 가공 | 필요 이상 다듬는다 | AI 초안 → 사람은 핵심만 손본다 |
| 동작 | 환경을 매번 세팅한다 | 셋업·스캐폴딩·CI 설정을 AI 자동화 |
| 불량 | 버그 → 재작업 악순환 | AI 정적분석·테스트 생성으로 조기 검출 |
| 재고 | 미완성 브랜치가 쌓인다 | AI가 작은 단위로 쪼개 빠르게 완료 |
| 운반 | 부서 간 정보가 떠돈다 | AI가 맥락·결정을 문서로 즉시 고정 |
| 과잉 생산 | 안 쓰는 기능을 만든다 | (AI가 못 막음 — 이건 사람의 판단 영역) |
마지막 줄이 중요합니다. "무엇을 만들 것인가"는 AI가 대신해줄 수 없습니다. AI는 낭비를 제거하지만, 가장 큰 낭비(잘못된 것을 만드는 것) 는 여전히 사람의 문제 정의에 달려 있습니다.
5. AI로 흐름을 "측정·분석"하라 — DMAIC 가속
산업공학의 마지막 원칙은 "측정하지 않으면 개선할 수 없다"였습니다. 문제는 측정·분석 자체가 시간을 잡아먹는다는 것. 여기서 AI는 DMAIC 루프(정의-측정-분석-개선)를 단축합니다.
현장 적용
- 흐름 데이터 분석: PR 리드 타임, 이슈 체류 시간 같은 로그를 AI에게 주고 "어느 단계가 병목인지, 왜인지" 를 분석하게 합니다. 사람이 스프레드시트와 씨름할 시간을 아낍니다.
- 회고 자동 초안: 한 주의 커밋·PR·이슈를 AI가 요약해 "이번 주 가장 큰 낭비" 후보를 뽑아줍니다. 회고가 감(感)이 아니라 데이터가 됩니다.
- 단, 지표는 사람이 고른다: AI에게 "코드 줄 수를 늘려라"를 시키면 정확히 그 잘못된 목표를 향해 최적화합니다. DORA 지표처럼 흐름 중심 지표를 사람이 정의해줘야 합니다.
⚠️ 함정 — AI가 새로운 병목·낭비가 될 때
여기까지만 보면 AI가 만능 같지만, 산업공학은 그렇게 순진하지 않습니다. AI는 잘못 쓰면 새로운 병목과 낭비를 만듭니다. 솔직히, 현장에서 더 자주 보이는 게 이쪽입니다.
- 검증 큐의 폭증: AI가 코드를 10배 빨리 뽑아도, 그걸 검토·검증하는 사람은 그대로입니다. 처리율을 한쪽만 올리면 검증이 새 병목이 됩니다. (제약이론 그대로)
- WIP 인플레이션: "AI가 빠르니까" 동시에 5개 기능을 벌이면, 리틀의 법칙대로 완료는 더 느려집니다. AI는 시작을 쉽게 만들 뿐, 끝내주는 건 아닙니다.
- 제번스의 역설(Jevons Paradox): 효율이 오르면 수요가 더 늘어, 총량은 오히려 증가합니다. "AI로 빨라졌으니 일을 더 받자"가 되면 집중은 다시 사라집니다.
- 인지 부하의 이전: 코드 작성 부하는 줄지만, "AI 출력을 신뢰할지 판단하는" 부하가 새로 생깁니다. 검증 없는 수용은 곧 불량(버그)으로 돌아옵니다.
그래서 — AI 도입도 1편의 원칙 그대로입니다. WIP를 제한하고, 병목을 보고, 여백을 지키세요. AI는 흐름을 바꾸는 강력한 레버지만, 흐름의 원리 자체를 바꾸진 못합니다.
핵심 요약 — AI × 산업공학 집중 전략
| 전략 | 산업공학 원리 | 오늘 할 수 있는 행동 |
|---|---|---|
| 컨텍스트 보관 | SMED (셋업 단축) | 복귀 시 "맥락 3줄 요약" AI에게 요청 |
| 병목에 투입 | 제약이론 | 리뷰 전 AI 1차 리뷰 도입 |
| 변동 흡수 | 대기행렬 이론 | 잔질문·잔업을 AI 큐로 우회 |
| 낭비 소거 | 7대 낭비 | 셋업·테스트·문서를 AI 자동화 |
| 흐름 측정 | DMAIC | PR 리드 타임을 AI로 분석 |
| 검증 병목 경계 | 제약이론(재적용) | WIP 상한 유지, AI 출력 반드시 검증 |
한 문장으로 줄이면 — AI는 "일을 더 시키는 도구"가 아니라 "흐름의 병목을 공략하는 레버" 입니다.
자주 묻는 질문 (FAQ)
Q. AI를 쓰면 무조건 생산성이 오르나요? A. 아닙니다. 병목이 아닌 곳에 AI를 투입하면 재공품(WIP)과 검증 부담만 늘어 오히려 느려집니다. 먼저 "내 흐름의 병목"을 찾고, 거기에 AI를 투입해야 효과가 납니다(제약이론).
Q. AI 코딩 도구가 컨텍스트 스위칭을 정말 줄여주나요? A. 줄여줍니다. 단, "코드를 대신 짜는" 효과보다 "내가 자리를 비운 사이 맥락을 붙들어주는" 효과가 더 큽니다. 복귀 시 맥락 요약, 잔질문 즉답이 23분짜리 복구 시간을 크게 줄입니다.
Q. AI가 빨라졌는데 왜 더 바빠질까요? A. 제번스의 역설입니다. 효율이 오르면 일을 더 받아들이게 되고, WIP가 늘면서 집중이 다시 깨집니다. 여백을 지키는 규율(WIP 제한) 이 AI 시대에 더 중요해진 이유입니다.
마무리
1편에서 "집중은 설계할 수 있는 시스템"이라고 했습니다. 2편의 결론은 여기서 한 걸음 더 나갑니다 — AI는 그 시스템을 더 강하게 만드는 레버이지만, 시스템 설계 자체를 대신해주지는 않습니다.
AI에게 "더 많이, 더 빨리"를 시키는 대신, "내 흐름의 어느 병목을 공략할까" 를 먼저 물어보세요. 그 질문 하나가 AI를 소음에서 레버로 바꿔줍니다.
여러분은 AI를 흐름의 어느 지점에 투입하고 계신가요? 효과를 본 곳, 오히려 더 정신없어진 곳 — 댓글로 나눠주시면 함께 정리해보겠습니다. 🙂
함께 읽으면 좋은 글: 개발자 집중 환경 만들기 — 산업공학으로 푸는 딥 워크 설계법 · AI 시대 회사가 원하는 인재상