AI가 당신의 프로세스를 더 빠르게 만들 것 같지 않다

^{source https://frederickvanbrabant.com/blog/2026-05-15-i-dont-think-ai-will-make-your-processes-go-faster/}

시장이 가라앉을 때면 늘 그렇듯, 요즘 거의 모든 조직이 적어도 어느 정도는 프로세스 최적화에 매달리고 있다는 느낌이 든다. 여기에 이제는 AI라는 요소까지 얹히면서, 그에 따라오는 비현실적인 기대도 함께 커지고 있다.

이걸 제대로 보려고, 이 분야의 대표적인 고전 두 권을 다시 읽어보기로 했다. The Toyota way & The Goal . 대학 시절에도 두 책을 읽었지만, 다시 보니 많은 프로세스 최적화 시도가 너무 단순하게 흘러가고, 정작 어디에 집중해야 하는지를 자주 잘못 짚고 있다는 생각이 더 선명해졌다.

눈에 보이는 병목

무슨 말인지 예를 들어보자.

이건 설명을 위한 Gantt chart다. 보통은 BPMN으로 보는 게 맞지만, 여기서는 Gantt가 요점을 더 쉽게 보여준다.

이 Gantt chart를 보면 어디에 가장 많은 시간이 들어가는지 바로 눈에 띈다. 소프트웨어 개발이다. 만약 당신의 과제가 프로젝트 throughput을 끌어올리는 일이라면, 가장 먼저 들여다볼 곳도 여기일 것이다. 그 판단 자체는 맞다.

문제는 그다음이다. 내가 흔히 보는 방식은 이렇다. 사람을 더 투입하거나, 아니면 AI가 이걸 훨씬 더 빠르게 만들어줄 거라고 그냥 가정해버린다.

하지만 사람들이 대체로 보지 않는 건, 왜 이 단계가 이렇게 오래 걸리는지다. 더 중요한 건, 오래 걸린다고 해서 문제가 반드시 그 단계에서 시작된다는 뜻은 아니라는 점이다.

upstream에서 문제를 푼다

지금은 소프트웨어 개발을 예로 들고 있지만, 이 얘기는 원하는 것보다 오래 걸리는 모든 프로세스에 그대로 적용된다.

소프트웨어 개발자라면 누구나 안다. 타자를 더 빨리 친다고 프로젝트가 더 빨라지지는 않는다. 그게 통했다면 우리 모두 타자 학원부터 다녔을 것이다.

소프트웨어 개발은 문제를 컴퓨터가 이해하고 자동으로 해결할 수 있는 해법으로 옮기는 일이다. 가능하면 보안과 확장성까지 갖춘 방식이어야 한다.

그런 일을 하려면 문제를 전체적으로 볼 수 있어야 한다. waterfall 쪽에 가깝다면 feature 문서나 scope 문서가 필요하고, agile 쪽에 가깝다면 도메인 전문가들과 계속 반복적으로 맞춰가야 한다.

소프트웨어 개발이 느려지는 지점은 대개 여기다. 제목만 달랑 있는 모호한 feature request가 실제로 무엇을 뜻하는지 해석하느라 시간을 쓰는 것이다.

예를 들어 "판매가 완료되면 사용자에게 메일을 보낸다"는 말이 정확히 무슨 뜻일까? 메일을 보내는 것까지는 좋다. 그런데 메일 내용은 무엇이어야 할까? 판매 과정에서 문제가 생기면 에러 메일이라도 보내야 할까? 판매 완료는 정확히 언제로 봐야 할까?

그냥 AI를 들이밀자

소프트웨어 개발 자동화, 그러니까 AI generated code를 두고 내가 계속 듣는 주장은 이렇다. 개발 단계를 그냥 건너뛸 수 있고, 소프트웨어 개발자는 결국 project manager 역할만 하게 된다는 것이다. 사실 소프트웨어 개발을 둘러싼 AI 논의는 이 문제를 아주 잘 보여준다.

많은 사람은 AI 개발의 결과가 대략 이렇게 생겼을 거라고 기대한다.

하지만 실제로는 그렇게 돌아가지 않는다. 여기서도 앞서와 똑같은 upstream 문제를 맞닥뜨리게 된다.

맞다. AI는 코드를 빠르게 만들어낼 수 있다. 그게 좋은 일인지는 논쟁의 여지가 있지만. 그렇다고 해서 올바른 코드를 만들고 있다는 뜻은 아니다.

사람과 AI 개발을 비교할 때는 늘 AI가 일을 하도록 옆에서 계속 잡아줘야 하는 과정을 빼놓는다. 실제 모습은 오히려 이쪽에 가깝다.

예전 방식보다 이 구성이 더 빠를 수도 있다. 다만 이 비교는 공정하지 않다고 본다. 이렇게 일하려면 도메인 전문가와 제품 전문가가 훨씬 더 깊이 관여해야 한다. 그리고 그 관여는 결국 모든 feature와 bug fix를 아주 사소한 부분까지 다 문서로 풀어 써야 한다는 뜻이 된다.

사실 이건 소프트웨어 개발자들이 직업이 생긴 이래 줄곧 바라온 바로 그 상황이다. 문제가 무엇인지, 최종 결과가 어떤 모습이어야 하는지 상세하게 정리된 설명을 받는 것.

인간 개발자에게도 똑같은 수준의 feature/scope 문서를 준다면 생산성이 치솟는 모습을 보게 될 것이다.

프로세스를 진짜로 빠르게 하려면

프로세스를 빠르게 만들고 싶다면, 실제로 일을 해야 하는 사람들이 그 일을 해낼 수 있는 조건을 제대로 갖추고 있는지부터 봐야 한다.

예를 들어 법무 승인 프로세스가 느리다면, 법무 검토를 시작하려면 무엇이 필요한지부터 살펴봐야 한다. 서류가 빠진 채 올라와서 담당자가 다섯 사람을 쫓아다녀야 한다면, 부서에 변호사를 더 넣는다고 그 프로세스가 빨라지지는 않는다.

The Goal의 큰 교훈 가운데 하나는 이거다. "병목에는 예측 가능하고 품질 높은 입력이 들어가야 한다."

프로세스 자동화에서 가장 먼저 봐야 할 것도 바로 여기라고 생각한다.

HN 댓글에서 가장 많이 나온 반응은, 요구사항만 자세히 적어 두면 구현은 거의 자동화될 거라는 전제가 현실과 다르다는 것이었다. 댓글에서는 소프트웨어 개발이 원래 모호한 요구를 해석하고, 구현 과정에서 드러나는 예외와 제약 때문에 요구사항 자체를 다시 다듬는 일이라고 보는 사람이 많았다.

AI가 도움이 되는 구간을 부정하는 분위기는 아니었다. 초안 작성, 프로토타입, 보일러플레이트, 테스트 초안, 눈에 보이는 기능의 빠른 시제품에서는 확실히 속도가 난다는 경험담이 이어졌고, 도메인 전문가가 직접 PoC를 만져 보면서 설계 논의를 줄였다는 반응도 있었다.

다만 그 속도가 곧 자율 구현으로 이어진다고 보지는 않았다. 댓글에서는 사람이 범위를 작은 단계로 나누고, 막히는 지점을 풀어 주고, 코드와 테스트를 따로 검토하지 않으면 모델이 엉뚱한 방향으로 가거나 유지보수하기 어려운 코드를 쌓는다고 봤다.

병목이 코딩보다 조율에 있다는 반응도 많았다. 다른 팀과의 합의, 국가별 규제, 기존 시스템과의 충돌, 권한과 보안처럼 구현 바깥에서 생기는 문제는 그대로 남기 때문에, AI가 코드를 빨리 써도 전체 리드타임이 쉽게 줄지는 않는다는 지적이다.

PM이나 요구사항 작성자가 AI로 티켓을 더 길고 구조적으로 쓰기 시작하면서 도움이 됐다는 사례도 있었지만, 그 흐름을 경계하는 시선도 강했다. 사람이 제대로 검토하지 않은 채 그럴듯하게 부풀린 설명을 다시 에이전트에 넣으면, 처음의 부정확한 전제가 요구사항과 코드, 테스트에 함께 스며든다는 우려가 반복됐다.

자율 코딩의 한계를 두고는 Anthropic의 C 컴파일러 사례가 계속 언급됐다. 진전 자체는 인정하더라도, 상세한 명세와 많은 테스트가 있어도 만만치 않은 소프트웨어를 사람의 감독 없이 안정적으로 만들 수준은 아직 아니라는 쪽이 우세했고, 특히 보안, 내구성, 권한처럼 사용자가 바로 확인하기 어려운 요구일수록 인간의 검토가 더 필요하다는 기준이 분명했다.