---
title: "AI가 프로세스를 빠르게 만든다는 착각에 대한 꽤 현실적인 반박"
published: 2026-05-17T12:13:45.000Z
canonical: https://jeff.news/article/2812
---
# AI가 프로세스를 빠르게 만든다는 착각에 대한 꽤 현실적인 반박

글쓴이는 AI가 코드 작성 시간을 줄여도 전체 프로세스가 자동으로 빨라지진 않는다고 짚어. 진짜 병목은 개발자가 타이핑하는 속도가 아니라, 애매한 요구사항과 낮은 품질의 입력이 작업자에게 흘러들어오는 구조라는 얘기야.

- 요지는 단순함. AI가 코드를 빨리 써준다고 해서 회사의 프로세스가 자동으로 빨라지는 건 아님
  - 글쓴이는 요즘 조직들이 경기 침체 국면에서 프로세스 최적화에 꽂혀 있고, 거기에 AI 기대감까지 얹히면서 현실 감각이 흐려졌다고 봄
  - 그래서 다시 읽은 책이 『The Toyota Way』와 『The Goal』인데, 둘 다 “보이는 작업 시간이 길다 = 거기가 원인”이라는 식의 단순한 사고를 경계함

- 예시로 든 프로젝트 일정표를 보면 가장 길게 보이는 구간은 당연히 소프트웨어 개발임
  - 기능 탐색 10일, 예산 범위 산정 3일, 법무 검토 10일, 문서화 5일 뒤에 개발 탐색 25일, 실제 개발 70일, 배포 5일, 하이퍼케어 10일 같은 흐름임
  - 겉으로 보면 “개발이 70일이나 걸리네? 개발자를 더 넣거나 AI로 줄이면 되겠네?”라는 결론이 나오기 쉬움

- 그런데 개발이 오래 걸리는 이유가 개발 단계 안에만 있진 않음
  - 개발자는 타이핑을 빨리 못 해서 늦는 게 아님. 그랬으면 다들 타자 연습 프로그램부터 켰겠지
  - 소프트웨어 개발은 문제를 컴퓨터가 처리할 수 있는 해결책으로 바꾸는 일이고, 그러려면 문제의 전체 그림이 필요함
  - 워터폴이면 기능 문서와 범위 문서가 제대로 있어야 하고, 애자일이면 도메인 전문가와 계속 왕복할 수 있어야 함

- 진짜 시간을 잡아먹는 건 “제목만 있는 요구사항”을 해석하는 구간임
  - 예를 들어 “판매가 완료되면 사용자에게 메일 발송”이라는 요구사항은 얼핏 쉬워 보임
  - 근데 메일에 뭘 넣을지, 판매 과정에 오류가 있으면 에러 메일을 보낼지, 애초에 판매 완료의 기준이 뭔지부터 다시 물어봐야 함
  - 이런 질문들이 정리되지 않은 채 개발로 넘어오면 개발자는 코딩보다 요구사항 복원에 시간을 쓰게 됨

> [!IMPORTANT]
> AI가 줄여주는 건 주로 “코드 입력과 초안 생성” 쪽이지, 애매한 비즈니스 문제를 정확한 요구사항으로 바꾸는 비용까지 사라지는 건 아님.

- AI 개발에 대한 흔한 기대는 “개발자가 프로젝트 매니저가 되고, AI가 개발을 3일 만에 끝내는 그림”임
  - 글쓴이가 보여주는 기대 일정은 기존 70일짜리 개발이 AI 개발 3일로 바뀌는 식임
  - 하지만 현실은 AI에게 계속 맥락을 주고, 산출물을 검토하고, 빠진 조건을 다시 넣는 시간이 필요함
  - 그래서 실제 일정은 문서화 40일, AI 개발 40일처럼 요구사항 정리와 AI 핸드홀딩이 길게 늘어나는 쪽에 가까울 수 있음

- 이 비교가 불공정하다는 지적도 꽤 날카로움
  - AI에게 제대로 일을 시키려면 도메인 전문가와 제품 담당자가 모든 기능과 버그 수정 요구를 아주 세세하게 써줘야 함
  - 근데 그건 개발자들이 예전부터 계속 원하던 바로 그거임. “문제가 뭔지, 최종 결과가 어떤 모습이어야 하는지 제대로 알려달라”는 요구 말이야
  - 같은 수준의 상세한 문서를 사람 개발자에게 줘도 생산성은 크게 오를 가능성이 큼

- 법무 프로세스 예시도 같은 논리임
  - 법무 검토가 느리다고 변호사를 더 뽑는다고 해결되는 게 아닐 수 있음
  - 법무팀이 검토를 시작하려면 매번 불완전한 문서 때문에 다섯 명을 쫓아다녀야 한다면, 병목은 법무팀의 인원 수가 아니라 입력 품질임
  - 『The Goal』의 큰 교훈 중 하나도 병목에는 예측 가능하고 품질 높은 입력이 들어가야 한다는 것임

- 그래서 프로세스 자동화의 첫 단계는 AI 도구 구매가 아니라 “일하는 사람이 일을 시작할 수 있는 조건이 갖춰졌는지”를 보는 것임
  - 필요한 정보가 빠져 있는가
  - 승인과 검토의 시작 조건이 불명확한가
  - 병목으로 보이는 팀이 사실은 앞단의 혼란을 흡수하고 있는가

---

## 기술 맥락

- 이 글에서 말하는 핵심 선택은 “AI로 개발 시간을 줄이기 전에 입력 품질을 먼저 고치자”는 쪽이에요. 왜냐하면 대규모 언어 모델(LLM)은 요구사항이 명확할수록 강해지지만, 모호한 요구사항을 받으면 사람처럼 추측과 재작업을 반복하거든요.

- 개발 조직에서 병목은 코드 작성 레이어에만 있지 않아요. 제품 정의, 법무 검토, 도메인 지식 전달, 승인 조건 같은 앞단 프로세스가 흐리면 개발 단계가 모든 불확실성을 떠안게 돼요. 그래서 개발 기간이 길어 보인다고 개발팀만 최적화하면 효과가 제한적이에요.

- AI 개발 워크플로도 결국 “프롬프트를 잘 쓰면 끝”이 아니에요. 기능 기준, 예외 상황, 데이터 흐름, 보안 조건, 운영 제약을 계속 모델에 넣어줘야 하고, 나온 결과가 맞는지도 검증해야 해요. 이 비용을 빼고 70일 개발이 3일로 줄어든다고 말하면 꽤 위험한 계산이에요.

- 실무적으로는 병목 팀에 더 많은 인력이나 더 비싼 도구를 넣기 전에, 그 팀이 받는 입력을 표준화하는 게 먼저예요. 좋은 요구사항 템플릿, 명확한 완료 기준, 빠른 도메인 피드백 루프가 있어야 AI도 사람도 속도가 나거든요.

## 핵심 포인트

- 긴 작업이 보인다고 그 지점이 문제의 원인이라는 뜻은 아님
- AI 개발도 결국 상세한 요구사항과 도메인 지식의 손잡이가 필요함
- 병목에는 예측 가능하고 품질 높은 입력을 먼저 공급해야 함

## 인사이트

AI 도입 논의에서 자주 빠지는 게 ‘누가 문제를 정확히 정의하느냐’야. 코드 생성 속도보다 요구사항 품질이 낮으면, 사람도 AI도 결국 같은 늪에서 헤맨다는 점을 잘 찌른 글이야.