AI가 여러분의 프로세스를 더 빠르게 만들지는 않을 것 같습니다
9 hours ago
1
- 프로세스 최적화 흐름 속에서 AI에 대한 비현실적 기대가 확산되고 있으나, 단순히 AI 도입만으로 처리 속도가 개선되지는 않음
- 소프트웨어 개발이 오래 걸리는 진짜 원인은 코딩 속도가 아니라, 모호한 요구사항을 명확한 문제 정의로 전환하는 과정에 있음
- AI 코드 생성도 동일한 업스트림 문제에 직면하며, 정확한 결과를 위해 도메인·제품 전문가의 깊은 개입이 필수적임
- AI 활용 비교 사례에서 흔히 누락되는 핸드홀딩(handholding) 과정이 실제 생산성 격차를 만들며, 인간 개발자도 동일한 상세 문서를 받으면 생산성이 급상승함
- 진정한 프로세스 가속화를 위해서는 The Goal의 교훈처럼 "병목 지점에 예측 가능하고 고품질의 입력을 공급" 하는 것이 우선 과제임
시장 침체 속 프로세스 최적화와 AI 기대
- 시장이 침체될 때 조직 대부분이 부분적으로라도 프로세스 최적화에 집중하는 경향, 최근에는 여기에 AI라는 요소와 비현실적인 기대가 더해지는 상황
- The Toyota Way와 The Goal은 많은 프로세스 최적화가 무엇에 집중해야 하는지 오해하기 쉽다는 점을 떠올리게 함
- 오래 걸리는 구간은 개선을 시작할 신호일 수 있지만, 문제가 실제로 생기는 지점이라고 단정할 수 없음
- 단순히 사람을 더 투입하거나 AI가 속도를 크게 높일 것이라고 기대하면, 왜 일이 늦어지는지 보지 못함
- 프로세스를 빠르게 하려면 작업자가 실제로 일을 시작하고 끝낼 수 있는 입력과 조건을 갖췄는지 먼저 확인해야 함
시각적 병목(The visual bottleneck)
- Gantt 차트 예시를 통해 가장 오래 걸리는 단계가 소프트웨어 개발임을 시각적으로 확인 가능
- 본래 BPMN을 사용하는 것이 일반적이나, 설명을 쉽게 하기 위해 Gantt 차트로 제시
- 프로젝트 throughput 개선이 목표라면 가장 오래 걸리는 단계를 우선 살펴보는 접근 자체는 옳음
- 문제는 사람들이 이를 해결하는 방식
- 인력을 더 투입(throw people at the problem)
- AI가 훨씬 빠르게 만들어 줄 것이라 가정
- 정작 "왜 이 단계가 오래 걸리는가" 를 들여다보지 않음, 더 중요한 점은 소요 시간이 길다고 해서 문제의 원인이 그 단계에 있는 것은 아님
업스트림에서 문제 해결하기
- 소프트웨어 개발을 예로 들지만, 원하는 것보다 오래 걸리는 모든 프로세스에 동일하게 적용 가능
- 소프트웨어 개발은 단순히 타이핑 속도를 높인다고 빨라지지 않음, 그렇다면 모두가 타이핑 수업을 듣고 있었을 것
- 소프트웨어 개발의 본질은 문제를 컴퓨터가 자동으로 해결할 수 있는 솔루션으로 번역하는 작업, 가급적 안전하고 확장 가능한 방식으로
- 이를 위해서는 문제에 대한 전체적인 이해가 필요함
- 워터폴 방식에 가깝다면 기능 문서나 범위 문서가 필요함
- 애자일 방식이면 도메인 전문가와의 지속적 반복(iteration)
- 실제로 개발을 느리게 만드는 부분은 제목만 있는 모호한 feature 요청이 무엇을 의미하는지 파악하는 과정
- "판매가 완료되면 사용자에게 메일을 보낸다(send mail to user once sale is completed)" 이 요청도 바로 구현 가능한 요구사항이 아님
- 메일을 보낼 수는 있지만 메일에 무엇이 들어가야 하는가
- 판매 프로세스에 문제가 있었다면 오류 메일은 보내야 하는가
- 판매가 "완료"되는 시점은 언제인가
AI에 다 맡기면 된다는 주장
- 자주 듣는 주장은 AI 코드 생성으로 개발 단계를 우회하고, 소프트웨어 개발자가 프로젝트 매니저 역할만 하면 된다는 것
- 많은 사람은 기존의 긴 소프트웨어 개발 구간이 3일 정도의 AI 개발 구간으로 대체될 것이라고 기대함
- 사람들이 기대하는 AI 개발의 결과 모습이 있으나, 실제로는 그렇게 작동하지 않음, 동일한 업스트림 이슈에 그대로 직면
- AI가 코드를 빠르게 생성할 수 있다는 점은 사실(그것이 좋은 일인지는 별개 논쟁)이지만, 빠른 생성이 곧 올바른 코드 생성은 아님
- 인간 vs AI 개발 비교에서 항상 무시되는 것은 AI가 제대로 작동하도록 하기 위한 핸드홀딩(handholding) 과정
- 이 방식이 기존 방식보다 빠를 수는 있지만, 공정한 비교가 아님
- AI 개발이 작동하려면 도메인 전문가와 제품 전문가의 훨씬 깊은 참여가 필요함
- 모든 기능을 아주 작은 세부사항까지 작성해야 함
- 모든 버그 수정도 원하는 결과가 무엇인지 자세히 정리해야 함
- 이것이 바로 소프트웨어 개발자들이 직업이 시작된 이래로 줄곧 요구해 온 것, 즉 문제와 최종 결과물에 대한 상세한 개요 제공
- 인간 개발자에게 동일한 분량의 feature/scope 문서를 제공하면 생산성도 급격히 향상될 것
실제로 프로세스 속도를 올리는 방법
- 프로세스 속도를 높이려면 일을 해야 하는 사람들이 실제로 그 일을 할 수 있는 수단을 모두 갖추도록 보장해야 함
- 법률 승인 프로세스가 느리다면, 법률 승인 프로세스를 시작하기 위해 무엇이 필요한지 먼저 살펴야 함
- 불완전한 문서 때문에 다섯 명을 쫓아다녀야 하는 상황이라면, 부서에 변호사를 더 투입해도 속도가 빨라지지 않음
- The Goal의 큰 교훈 중 하나는 병목이 예측 가능하고 품질 높은 입력을 받아야 한다는 것임
- "bottlenecks should receive predictable, high-quality inputs"
- 프로세스 자동화의 첫 번째 출발점은 병목 구간 자체가 아니라, 병목이 받을 입력 품질과 예측 가능성을 높이는 쪽이어야 함
-
Homepage
-
Tech blog
- AI가 여러분의 프로세스를 더 빠르게 만들지는 않을 것 같습니다