[GN⁺] AI가 여러분의 프로세스를 더 빠르게 만들지는 않을 것 같습니다

9bow · 5월 20, 2026, 9:30오전

'AI는 여러분의 프로세스를 더 빠르게 만들지 않을 것 같습니다' 글 소개

프로세스 최적화 흐름 속에서 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"
프로세스 자동화의 첫 번째 출발점은 병목 구간 자체가 아니라, 병목이 받을 입력 품질과 예측 가능성을 높이는 쪽이어야 함

Hacker News 의견들

소프트웨어 개발이 처음부터 원해 온 건 "문제와 원하는 결과를 자세히 설명받는 것"이라는 말이 있지만, 사실 그 자체가 소프트웨어 엔지니어링임. 2026년에도 충분히 자세한 요구사항과 명세만 있으면 완벽한 해법을 한 번에 만들 수 있다는 생각은 버려야 함. 내 경험상 AI 덕분에 기능이나 아이디어를 훨씬 빠르게 반복할 수 있게 됐고, 이제 마찰은 대부분 다른 팀과의 정렬과 조율에서 생김. 프로세스를 빠르게 하려면 조율 비용을 줄이고 개인과 팀이 판단하고 실행할 권한을 더 가져야 한다고 봄
- 2026년에는 충분히 자세한 요구사항이 있어도 작동 가능한 해법조차 한 번에 만들 수 있다는 생각도 버려야 함. Anthropic도 완벽한 명세, 참조 구현, 수년간 사람이 쓴 수천 개의 테스트가 있었는데도 작동 가능한 C 컴파일러 같은 단순한 것조차 만들지 못했음. 현재 모델은 완벽한 명세와 완벽한 테스트가 있어도, 세심한 사람의 감독 없이 사소하지 않은 운영 소프트웨어를 만들 만큼 충분하지 않음
- 동의하지 않음. 오후에 제품 담당자가 떠올린 작업을 자주 받는데, 그들은 정상 경로만 신경 쓰고 때로는 그 일부만 신경 씀. 글로벌 회사라 각 국가의 규정과 법을 지켜야 하는데, 기능을 구현한 뒤 "사실 우리가 운영하는 시장의 90%에서는 법적으로 이걸 할 수 없다"는 말을 듣고, 다시 비활성화 기능을 붙임. 소프트웨어 엔지니어의 일은 요구사항 목록을 받아 그 요구사항을 달성하는 방법을 찾는 것이고, 요구사항 수집은 소프트웨어 엔지니어링 문제가 아님
- 완전히 동의함. 첫 프로그램을 쓴 지 40년이 넘었지만, 먼저 명세를 완성하고 그다음 소프트웨어를 작성해서 모든 게 잘된 경우를 본 적이 없음. 사소하지 않은 엔지니어링에서 가장 어려운 부분은 문제를 이해하는 것이고, 소프트웨어의 초기 버전들은 그 이해에 도달하는 방식임. AI는 틀린 첫 번째 버전에서 덜 틀린 두 번째 버전으로 빠르게 가는 데는 매우 좋음
- 모호한 요구사항을 해결할 최선의 방법을 찾는 일이 좋아서 엔지니어링에 들어왔음. 자세한 명세만 받는다면 그냥 코딩 로봇일 뿐이고, 그런 일은 주니어에게 넘김
- 요즘 의사결정자나 요구사항을 쓰는 사람들도 AI를 쓰기 시작하는 걸 일상에서 봄. 예전처럼 내 일은 그 요구사항을 읽고, 이해하고, 내가 아는 현실에 비춰 검증하는 것임. 지난 최소 20년간 소프트웨어 엔지니어링의 핵심은 아무도 믿지 말라였고, 이건 변하지 않았으며 여전히 많은 시간과 노력이 듦
LLM이 처음 나왔을 때는 사람들이 "Facebook 클론 만들어줘" 같은 식으로 말하면 된다고 생각했던 것 같음. 이제는 요구사항을 더 정확히 쓰고 더 잘 정의해야 한다는 걸 깨닫고 있음. 이것이 늘 소프트웨어의 병목이었음. 모호한 요구사항은 모호한 결과를 낳음
- 내가 본 바로는 PM들이 Claude Code나 Codex처럼 코드베이스에 연결된 AI를 써서 티켓이 훨씬 더 상세해졌음. 어떤 문제가 왜 있는지, 데이터를 어디서 어떻게 가져올지, 수용 기준은 무엇인지까지 적음. 솔직히 첫 단계만 보면 PM들이 이미 기능 구현의 절반까지 와 있는 것 같아서, 미래에는 PM들이 전부 직접 하고 몇몇 개발자는 완전한 구현자라기보다 SDET처럼 남을지도 모르겠음
- 이건 Fred Brooks가 1986년 고전 에세이 No Silver Bullet의 "Expert Systems"와 "Automatic Programming" 절에서 상당 부분 예측했음. 신중히 선택된 몇몇 영역에서 초기 성공을 거둔 뒤, 그 영역 밖으로 확장되면서 합리적이지만 혁명적이지는 않은 생산성 향상이 나타난다는 내용임. https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf
- 완전히 맞고, 이건 당연하다고 생각했음. LLM에 제대로 된 명세를 주면 잘 만들며, 원하는 걸 설명하기 위해 가짜 DSL을 만들어도 알아서 이해함
- 이제 제품 책임자들이 자기 일을 LLM에 떠넘기려 함. LLM은 같은 모호하거나 나쁜 요구사항을 그럴듯해 보이게 만들 뿐이고, 깊이 파보면 문제가 드러남
- 더 나쁜 점은, 사람으로 된 소프트웨어 팀이라면 모호한 요구사항에 대해 적어도 잘 운영되는 조직에서는 추가 명세를 요구한다는 것임. LLM은 그냥 "물론이죠! 데이터를 가져와 사용자에게 주는 완성된 코드입니다"라고 하고 끝냄
이 글은 AI가 개발 단계에만 영향을 준다고 가정하지만, 그건 확실히 사실이 아님. 아이디어 발상, 법무, 문서화, 개발, 배포를 포함해 모든 단계의 속도를 높일 수 있음. 개발도 마찬가지로, 문제를 누구보다 잘 이해하고 해법을 만드는 부분도 있지만 순수하게 잡일인 부분도 있음
- 글에 대체로 동의함. 새로운 중요한 기능을 추가하려고 하면 보통 업무 담당자들과 며칠, 몇 주, 몇 달씩 회의하면서 시스템 X, Y, Z 사이에서 일이 어떻게 흐르는지와 중요한 예외들을 이해해야 함. 코딩 속도를 높이는 데 가치는 분명 있지만, 퍼즐의 한 조각일 뿐이고 현재 LLM은 도메인 정보를 수집하고 해법을 정의하는 데 도움을 주지 못함
- 우리 조직의 경험도 위 내용과 맞음. 이제 더 많은 역할의 사람들이 예전에는 물리적인 절차로 힘으로 밀어붙이던 문제를 해결하는 소프트웨어 도구를 만들 수 있게 됨. 출하 책임자가 예전에는 많은 노동 시간을 태워 해결하던 문제를 맞춤 도구로 풀 수 있게 되면 정말 놀라운 일이 벌어짐
- 이 글은 우리 회사에서 실제로 벌어지는 일과 거의 같음. 소프트웨어 개발에 AI를 많이 쓰고 있지만 더 빨리 출시하고 있지는 않고, 비슷하거나 다른 이유로 더 느린 것 같기도 함. 유토피아가 오길 기다리는 묘한 느낌인데 오지 않고, 정확히 어디가 문제인지도 짚기 어려움
한편으로 이 글은 대규모 조직에서 기술 업무를 하는 많은 사람이 생각하고 현장에서 보는 것을 정확히 설명한 깔끔한 글임. 다른 한편으로는 HN에서도, 실제 직장에서도 최근 이런 얘기를 수십 번은 한 느낌임. 리더들은 AI가 정말 속도를 높일 거라고 가장할 사회적, 금전적 유인이 있기 때문에 블로그 글 하나로 설득되지 않을 것임
- 슬프지만 맞는 것 같음. 회사에서 이런 글을 공유하는 것도 꺼리게 되는데, 현상 유지와 맞지 않는 내용은 잘 받아들여지지 않는 느낌임
- 이런 글이 회사에서 논의될 때마다 핵심은 항상 다른 곳이 더 빠르게 새 기능을 출시하거나 가져올 수 있다면 뒤처질 위험, 더 정확히는 FOMO가 더 크다는 쪽으로 감
흥미로운 양면성이 있음. 이미 잘하는 일에서는 LLM이 상대적으로 별 영향이 없지만, 내가 못하는 일에서는 엄청난 게임 체인저임. 대기업은 프로젝트에 필요한 대부분의 역할을 채용할 수 있으므로 전체 효과가 상대적으로 작을 것임. 하지만 작은 스튜디오나 독립 개발자에게 LLM은 큰 변화임
- "이미 잘하는 일에서는 LLM이 상대적으로 별 영향이 없고, 못하는 일에서는 엄청난 변화"라는 건 겔만 망각 효과일 가능성이 있지 않나 싶음. 개인적으로는 정반대임. LLM은 내가 무엇을 하는지 정확히 이미 알고 있을 때만 도움이 됨
사소하지 않은 소프트웨어 개발이 코딩 50%도 안 된다는 걸 사람들이 잘 이해하지 못함. 큰 조직에서 대부분의 제품 변경은 여러 시스템과 사람의 운영을 가로지름. 시니어와 미드레벨은 대체로 로컬 우선순위를 기존의 사이버네틱 개체 안에서 새 배열로 맞추고, 각자 우선순위를 가진 다른 팀들로부터 그 새 비전에 대한 동의를 얻는 데 시간을 씀
- LLM이 거의 코드 작성자에 불과했다는 말은 1년 전에는 맞았지만 지금은 아님. 이제는 도구 호출자라서 코딩 에이전트는 린트, 타입 검사, 테스트를 실행하고 그 오류를 고치며, Sentry 같은 관측성 플랫폼을 파고들어 근본 원인을 찾고, 벤치마크를 돌려 느린 코드나 핫 패스를 찾을 수 있음
이 글은 대체로 맞고, AI가 프로세스를 더 빠르게 하려면 어디에 집중해야 하는지 힌트를 줌. 한 제품 관리자가 이해관계자와의 회의가 끝날 때 인터랙티브 프로토타입이 나오지 않으면 실패로 간주되는 미래를 상상한다고 말했는데, 방향성은 맞다고 느낌. 또 하나 예상하는 건 바이브 코딩이 "Excel 2.0"이 되는 것임
제시된 Gantt는 폭포수 모델이거나 소프트웨어에 최종 목적지가 있다고 보는 다른 방법론의 예시임. 오늘날 소프트웨어의 99.999%는 그렇게 만들어지지 않음. 2주 단위로 비즈니스가 소프트웨어가 해야 할 일을 바꿈. 사람은 습관의 동물이므로 AI를 써도 같은 문제가 모두 생길 것임. 도구로 비즈니스 문제를 해결할 수는 없음
"AI가 코드를 빠르게 생성할 수는 있지만, 그게 올바른 코드를 생성한다는 뜻은 아니다"라는 말에 대해, 실제로 코드는 거의 항상 맞음. 마음에 안 드는 건 보통 코드가 추가되는 방식임. 코드베이스를 충분히 잘 알면 어디에 추가해야 하는지, 이름을 어떻게 지어야 하는지, 주석을 얼마나 어디에 달아야 하는지 같은 의례가 있음
- 내 경험으로는 완전히 일상적으로 일어남. 이미 작성된 시스템을 복제하는 데 드는 노력과 그 시스템을 처음부터 만드는 데 드는 노력을 비교해 보면 됨
- "코드는 거의 항상 맞다"는 건 내 경험과 다름. 특히 입력이 버그나 성능 문제일 때 자주 환각하고, 손잡아주지 않으면 오진함

원문

출처 / GeekNews

[GN] 함께 보면 좋은 글β

알려드립니다

이 글은 국내외 IT 소식들을 공유하는 GeekNews의 운영자이신 xguru님께 허락을 받아 GeekNews에 게제된 AI 관련된 소식을 공유한 것입니다.

출처의 GeekNews 링크를 방문하시면 이 글과 관련한 추가적인 의견들을 보시거나 공유하실 수 있습니다!

아래쪽에 좋아요를 눌러주시면 새로운 소식을 정리하고 공유하는데 힘이 됩니다~