[병목 이동] 코드가 거의 제로 비용이 되었을 때, 소프트웨어 공학의 병목은 어디로 갔는가? AI 시대의 소프트웨어 공학 혁신 — 천천히 AI 배우기 173
코드가 거의 무료가 되면서, 병목은 요구사항, 통합, 검증, 정렬로 이동했다
코드 생산이 거의 무료가 되면서, 소프트웨어 배포의 병목은 “코드 작성”에서 다른 곳으로 이동했다: 올바른 문제를 정의하고, 조각들을 실행 가능한 전체로 조합하며, 그것이 실제로 올바른지 검증하고, 조직 내에서 정렬을 이뤄내는 것이다. 이는 소프트웨어 산업에서의 제약 이론(Theory of Constraints)의 재연이다. 제조업은 40년 전 이미 이 길을 걸어왔다: 한 공정이 저렴해지면 병목이 사라지는 것이 아니라, 다음으로 가장 비싼 공정으로 이동한다. 이 점을 이해하면 일반적인 혼란을 설명할 수 있다: AI 프로그래밍 도구가 전사에 도입되었고, 코드 작성은 분명히 빨라졌지만, 배포 속도는 크게 변하지 않았다.
한 제조 그룹의 CIO가 지난 반년간의 데이터를 나에게 보여주었다. IT 팀은 80명 이상으로, 모든 구성원이 AI 프로그래밍 도구를 도입했다. 코드 생산량만 보면, 인당 커밋 수와 병합 속도가 모두 30% 이상 증가했다. 그러나 비즈니스 측의 체감은 완전히 달랐다: 스마트 생산 계획이라는 작은 기능 하나도, 기획에서 릴리즈까지 여전히 3개월 이상 걸렸다. 그는 도구로 2배의 가속을 기대했지만, 실제로 얻은 것은 “코드를 빨리 쓸 수 있게 된 것”뿐이었다. 그의 말은 직설적이었다: “수백만 달러를 라이선스에 써서 얻은 건, 개발자는 더 바빠지고, 비즈니스는 더 급해진다는 것뿐이다.”
그는 병목 위치를 잘못 판단했다. 진정한 병목은 다른 곳에 있었다: 새로운 기능마다 MES, ERP, 품질 검사 시스템, 공장 단말기, 그리고 규제 보고 기준이라는 다섯 개의 시스템을 통과해야 했고, 통합과 연동에 대부분의 일정이 소모되었다. 반면 AI가 생성한 코드는 생산 환경과 사이에 단 하나의 공식적인 검수 단계도 존재하지 않는다. 코드가 얼마나 빠르게 작성되든, 그건 잘못된 병목 뒤에서 줄 서는 것에 불과하다.
1. 제조업은 40년 전부터 알고 있었다: 병목은 움직인다
현재를 이해하려면, 제조업이 40년 동안 사용해온 안경을 끼어보자.
1984년, 이스라엘 컨설턴트이자 물리학자인 Eliyahu Goldratt는 소설 『The Goal』을 썼다. 이 책은 파산 직전에 몰린 공장장이 어떻게 공장을 부흥시켰는지를 그린다. 전 책의 핵심은 단 한 문장이다: 어떤 시스템의 출력은 가장 좁은 부문(제약, 즉 병목)에 의해 결정된다.
병목이 아닌 부문을 넓히는 것은 총 출력에 아무런 도움이 되지 않는다. 오직 병목 자체를 넓힐 때만 전체 시스템이 빨라진다. 그리고 병목을 넓힌 순간, 그 병목은 다음으로 가장 좁은 지점으로 즉시 이동한다. 이것이 바로 제약 이론(Theory of Constraints, TOC)이다.
제조업 이후 40년의 자동화 역사는 거의 ‘병목 현상의 이동사’였다. CNC 기계가 절삭 공정을 저렴하게 만들자, 병목은 투모드와 품질 검사로 옮겨갔다. 유연한 생산 라인이 투모드를 빠르게 만들자, 병목은 생산 계획과 공급망 협업으로 옮겨갔다. MES가 생산 계획을 정확하게 만들자, 병목은 수요 예측과 공장 간 스케줄링으로 옮겨갔다. 자동화가 한 단계를 해결할 때마다, 다음 단계의 병목이 떠올랐다. 자동화는 병목을 없애지 않고, 단지 병목의 위치를 바꿀 뿐이다. 이 법칙은 제조업만의 전유물이 아니다. 2026년 7월, a16z 팟캐스트 『Software in the Age of Agents』에서 전 마이크로소프트 윈도우 사장 스티븐 시노프스키는 기업 소프트웨어 사례를 통해 이와 동일한 결론을 독립적으로 도출했다. 그의 말은 다음과 같다:
“The long tail got no shorter. It just got longer in a different way.”
그는 아마존 고객 서비스 사례를 들었다: 전화를 없애고 챗봇이 상품을 자동 재발송하게 하면 인력이 절약되는 것처럼 보이지만, 백엔드에는 즉시 “이런 문제를 다시 방지하려면 어떻게 해야 할까”라는 근본 원인 분석 요구가 생기며, 이는 전화를 받는 것보다 훨씬 복잡하다. 비용 보고 프로세스도 마찬가지다: OCR이 자동으로 회계 처리를 한 뒤, 재무팀이 해야 할 일은 출장 성과 최적화와 동적 가격 비교로 바뀐다. 업무가 사라진 게 아니라, “입력”에서 “분석 및 의사결정”으로 옮겨졌을 뿐이다. 마이크로소프트의 베테랑이자 a16z 파트너는 골드랫의 이론을 사용하지 않았지만, 제조업에서 40년 전에 도출된 결론과 동일한 결론에 도달했다. 한쪽은 공장 현장에서, 다른 한쪽은 기업 소프트웨어에서 비롯된 두 개의 독립된 경로가 같은 법칙을 가리킨다.
하지만 이 법칙에 한 가지 제한 조건을 추가해야 한다. 절대 진리로 오해되지 않도록 말이다. 실제로 영구히 사라진 병목은 존재한다: 타이피스트, 전화 교환원, 금속활자 조판공—이 직종들은 “상승”하지 않고 진짜로 사라졌다. 어떤 업무가 이동할지, 아니면 소멸될지를 판단하는 핵심은, 자동화로 해방된 생산력이 새로운 수요를 창출하는지(경제학에서 ‘제븐스 역설’이라 부름), 아니면 단순히 해당 수요를 축소시키는지에 달려 있다. 기업 핵심 시스템 주변의 대부분의 업무는 전자에 속한다: 계산이 빨라질수록 경영진이 원하는 분석은 더 많고 더 세밀해진다. 따라서 여기서의 결론은 “자동화가 얼마나 많은 일을 없앨 수 있는가”가 아니라, “사람과 예산을 자동화된 층에서 새로 떠오른 층으로 옮기는 것”이다. (기업 소프트웨어 관점의 롱테일 이동은 부록 《기업 소프트웨어의 점착성》에서 완전히 다룬다.)
이 일은 소프트웨어와의 거리가 당신이 생각하는 것보다 훨씬 가깝습니다. 2013년, 진 킴은 골드랫의 공장 이야기를 거의 그대로 IT 운영에 적용하여 『더 페닉스 프로젝트』(The Phoenix Project)를 저술했습니다: 한 CIO가 제약 이론을 사용해 회사를 거의 붕괴 직전으로 몰아넣은 IT 부서를 구하는 과정입니다. 따라서 “제조업의 병목 사고방식을 소프트웨어에 적용한다”는 것은 임시로 끌어온 비유가 아니라, 이미 검증된 경로입니다. # 2. 소프트웨어로 돌아가기: 코드 작성은 이제 가장 저렴한 단계가 되고 있다 세 개의 숫자가 “코드 생산 비용이 제로에 가까워지고 있다”는 사실을 명확히 보여줍니다.
- Copilot: GitHub 자체 연구에 따르면, Copilot을 활성화한 파일에서 약 46%의 코드가 Copilot에 의해 작성됩니다. 주의할 점은, 이 수치는 GitHub 전체 코드의 46%가 아니라, “Copilot을 활성화한 파일 내”에서의 비율입니다.
- Stripe: 내부에서 자체 개발한 코딩 에이전트 “Minions”는 매주 1,300개 이상의 PR을 생성하고 병합합니다(초기 1,000개에서 지속적으로 증가). 여기서 중요한 세부 사항 하나를 기억하세요: 모든 PR은 인적 리뷰를 거쳐야 병합됩니다. Stripe는 “작성”을 자동화했고, “검수”는 인간에게 남겼습니다. 이 점은 제4장에서 다시 등장합니다.
- NVIDIA: 황仁勳은 공개적으로, NVIDIA의 모든 엔지니어가 Cursor 같은 AI 프로그래밍 도구를 사용하고 있으며, “AI 없이 일하는 것”은 NVIDIA에서 더 이상 받아들여지지 않는다고 말했습니다.
이 세 가지 수치를 합치면 명확한 결론이 도출됩니다: 코드 한 줄을 작성하는 단위 비용이 급속히 제로에 근접하고 있다. 날카로운 질문이 따라옵니다: 코드 작성 비용이 거의 제로가 되었는데, 왜 소프트웨어는 여전히 비싸고, 느리며, 배포하기 어려운가? 답은 제약 이론이 제공합니다: 당신은 “코드 작성”이라는 공정을 넓혔을 뿐, 병목은 단지 이동했을 뿐입니다. 그 병목은 어디로 이동했나요?
3. 병목은 네 곳으로 이동했다
이번에는 병목이 네 가지 공정에 집중되어 있다. 각각은 AI가 단기적으로 도달할 수 없는 영역이다.
첫 번째: 올바른 문제를 정의하기.
AI는 몇 초 안에 “당신이 입으로 말한 기능”을 작성할 수 있지만, “당신이 진정으로 필요한 기능”은 작성할 수 없다. 대부분의 소프트웨어 프로젝트가 실패하는 근본 원인은, 만들어진 제품이 아무도 사용하지 않기 때문이다. 처음부터 해결해야 할 문제를 명확히 파악하지 못했기 때문이다. 코드 생산 비용이 싸진 이후, “모호한 비즈니스 과제를 명확하고, 해결 가능하며, 해결할 가치가 있는 사양으로 분해하는 것”(problem formulation)이 가장 희소하고도 가장 비싼 역량이 되었다. 제조업 동료들은 이를 익숙하게 알고 있다: 공정 경로나 엔지니어링 도면이 잘못되면, 공장이 얼마나 효율적으로 가공하든, 단지 대량 폐기품을 생산할 뿐이다.
두 번째: 시스템 통합.
AI는 “한 줄의 코드”, “한 개의 함수”, “한 개의 페이지”를 생성하는 데 능하다. 그러나 실전에 배포 가능한 시스템은 수백 개의 조각을 통합한 결과물이며, 이 조각들은 데이터를 상호 교환하고, 경계 조건을 처리하며, 일관성을 유지하고, 예외 상황에 견뎌야 한다. 조각을 생성하는 것은 저렴하지만, 이 조각들을 신뢰할 수 있는 전체로 조립하는 것은 비싸다. 이 비용의 근본은 조직과 아키텍처의 정렬에 있으며, 이는 콘웨이의 법칙과 팀 토폴로지가 다루는 핵심 주제이다(이 시리즈의 앞 두 편 참조). 개요에서 언급한 제조업 CIO의 사례를 돌이켜보자: 그의 일정은 코드 작성에 소요되지 않았고, MES, ERP, 품질 검사, 보고 시스템 간의 연동 조정에 소요되었다.
세 번째 장벽: 검증. 코드량이 폭증하고 신뢰도는 제각각이다. 누가 “이게 맞다”고 단정할 것인가? 테스트, 코드 리뷰, 가시성, 그레이스케일 배포——이 모든 “검증” 작업의 중요성은 오히려 커지고 있다. 이는 가장 과소평가된 장벽이자, 제조업의 거울처럼 가장 깊이 반영된 장벽이다. 자세한 내용은 제4장에서 다룬다.
네 번째 장벽: 조직 정렬. 팀에 AI 에이전트가 추가되면, 누가 무엇을 할지 결정하고, 누가 검토하며, 누가 결과에 책임을 져야 하는가? 이는 콘웨이의 법칙과 팀 토폴로지의 연장선이며, 조직 정렬 자체가 장벽이 되었다. 시리즈 11편에서는 조직의 노드가 모두 인간이 아닌 상황에서, 거버넌스가 왜 핵심 역량이 되는지 특별히 다룬다.
4. 가장 깊은 칼날: 검증, 그리고 토요타의 ‘자동화’가 가르치는 진정한 의미
네 개의 장벽 중 가장 오해받는 것은 검증이다. 많은 이들이 이를 “AI가 빠르게 쓰니까, 더 많이 테스트하면 되지”라고 이해한다. 이는 반만 맞는 말이다. 왜 검증이 비싸졌는지를 이해하려면, 가장 오용되고 가장 잘못 이해된 개념을 제대로 설명해야 한다: 자동화(Jidoka).
먼저 널리 퍼진 오해를 바로잡자. 자동화는 “AI나 기계가 사람을 대체하는 것”이 아니다. 또한 “사람을 기계처럼 만들어 끊임없이 일하게 하는 것”도 아니다. 이 두 방향 모두 잘못된 방향이다.
자동화의 문자 그대로의 의미가 답을 내포하고 있다. 일본어에서 “자동화”는 일반적인 자동화를 뜻하지만, 도요타는 특별히 “자働화”라는 표현을 사용한다. 이 “働”자는 사람 편을 가진 글자로, “사람이 개입된 자동화”(automation with a human touch)를 강조한다. 그 정확한 의미는 다음과 같다: 기계나 생산라인이 이상을 감지하면 자동으로 정지하고, 인간이 개입하여 근본 원인을 해결한 후 생산을 재개하는 것. 이 시스템은 두 가지 메커니즘이 병행된다. 하나는 기계 자체가 이상을 감지해 자동으로 정지하는 것이고, 다른 하나는 생산라인의 어떤 직원이라도 이상을 발견하면 안등 로프(andon)를 당기면 전체 라인이 즉시 정지하는 것이다. 품질은 최종 단계에서 검사하는 것이 아니라, 각 공정에 내재되어 즉시 해결된다.
여기에는 직관에 반하는 결론이 있다. 이는 소프트웨어와 직접적으로 연결된다: 자동화가 깊어질수록, 품질 검사 포인트와 인간의 개입 비중은 줄어들지 않고 오히려 증가한다. 자働화는 인간을 “반복적 작업”에서 해방시켜, “이상 발견 → 라인 정지 → 근본 원인 해결”이라는 역할로 재배치한다. 도요타가 일선 작업자에게 전체 생산라인을 정지시킬 권한을 부여한 이유는, 자동화가 아무리 강력하더라도, 문제가 발생했을 때 멈추는 사람의 존재가 필수적이기 때문이다. 이것이 “로봇에게 지혜를 부여한다”는 구호의 진정한 의미다: 기계가 인간을 불러올 수 있는 능력을 갖추는 것. 인간은 항상 현장에 있으며, 근본 원인을 해결하는 책임을 진다.
소프트웨어는 이 길을 다시 걷고 있으며, 매우 빠르게 진행 중이다. GitClear의 AI 보조 코드 품질 연구는 반복 코드 블록 증가와 단기 churn 코드 상승 현상을 관찰했다: AI는 빠르게 코드를 작성하지만, 그 코드는 “전부 다 맞아 보이는” 수준이다. 대량의 코드가 아무도 한 줄씩 직접 작성하지 않게 되면서, 전통적인 “개발자가 마음속으로 알고 있다”는 신뢰 메커니즘은 무너졌다. 이때 필요한 것은 소프트웨어 버전의 안등줄과 생산 중단 메커니즘이다:
- 테스트(유닛, 통합, 엔드투엔드)가 “최대한 하자”에서 강제 기준으로 전환된다: 통과하지 못하면 병합 불가;
- 코드 리뷰의 초점이 “작성 방식 검사”에서 “의도와 경계 조건 검사”로 이동한다: 이 코드는 정확히 무엇을 해결하려 하는가? 경계 조건은 모두 커버되었는가?
- 가시성(모니터링, 로그, 트레이싱)이 표준이 되었다. 왜냐하면 실제 운영 환경에서의 행동이 코드 자체보다 더 중요한 단서를 제공하기 때문이다;
- 그레이드 릴리스 / 기능 플래그를 통해 AI가 생성한 코드를 먼저 소규모 환경에서 검증하고, 문제가 없음을 확인한 후에야 대규모 배포한다.
뒤를 돌아보면, 제2장의 Stripe 사례에서 나온 1,300개의 PR을 보면: 코드 작성은 에이전트가 담당했지만, 병합이라는 관문은 전적으로 인적 리뷰에 맡겨졌다. 이것이 소프트웨어에서의 자동화의 실제 사례다: 생산은 자동화하고, 승인은 인간이 책임지며, 인간에게 “이것을 막을 권한”을 부여한다. 생산은 싸워졌고, 품질 통제는 비싸워졌다. 이는 40년 동안 변하지 않은 법칙이다.
5. “문제 정의”의 프리미엄: 프롬프트보다 더 가치 있는 능력
검증이 과소평가된 병목이라면, “문제 정의”는 심각하게 과소평가된 능력이다.
프롬프트 엔지니어링이 한때 유행했고, 많은 이들이 “프롬프트를 잘 쓰는 것”이 핵심 능력이라고 생각했다. 그러나 프롬프트는 단지 “문제를 표현하는” 기술에 불과하다. 진정으로 희귀한 것은 그 한 걸음 더 나아가는 것—문제 정의(problem formulation): 모호한 비즈니스 과제를 명확하고, 해결 가능하며, 풀 가치가 있는 문제로 분해하는 능력이다. 이 단계는 AI가 단기간 내에 할 수 없는 일이다. 왜냐하면 AI는 먼저 당신이 “문제가 무엇인지” 알려주기를 기다려야 하기 때문이다.
제조업의 경험이 풍부한 베테랑들이 이 단계의 중요성을 가장 잘 느낀다. 공정 도면이나 제조 라인 하나가 잘못 정의되면, 하류 공정과 조립이 아무리 효율적이더라도, 오류를 대량 생산하게 된다. 소프트웨어도 마찬가지다: 요구사항 명세가 잘못 정의되면, AI는 그 문제를 10배 빠르게 해결해 주지만, 결과물은 아무도 원하지 않는 것이 된다.
판단 기준은 매우 명확하다: “코드를 빠르게 쓰는 속도”를 경쟁하지 말고, “문제를 명확히 분해하는 능력”을 연마하라.
조직 내에서 이는 “요구사항 정의”와 “검증 및 수용”을 공식적인 직무로 설정하라는 뜻이다. 개발자가 임의로 맡게 두지 말라. AI가 구현을 저렴하게 만들면서, 이 두 직무의 보상은 가장 빠르게 상승하고 있다.
6. 네 산업의 실제 병목은 무엇인가?
“병목 이동”을 네 개 산업에 적용해 보면, 각 산업의 병목은 모두 코드 작성에 있지 않다.
제조업. 주요 흐름은 개막에서 언급된 CIO다. 지능형 생산 계획, 품질 추적, 에너지 소비 최적화 같은 기능은 기술적으로 어렵지 않으며, 대부분의 모델은 이미 존재한다. 문제는 MES/ERP/품질 검사/보고 시스템 간의 통합 조정과 공장 현장 단말기의 실제 검증에 있다. 이러한 프로젝트의 코드는 빠르게 작성되지만, MES/ERP 시스템 간의 통합 조정에는 코드 작성 시간의 수배가 소요된다. 결함을 생산 단계에서 발견하는 대신, 수용 단계를 공장 단말기와 통합 과정에 배치해야만 결함을 즉시 차단할 수 있다.
통신/통신사. 한 번의 요금제 변경이나 기업 전용 회선 개통 프로세스는 채널, 요금 청구, CRM, 네트워크 개통, 설치 및 유지보수 스케줄링 등 여러 도메인을 통과해야 한다. AI는 각 도메인의 개발 속도를 높였지만, 도메인 간의 엔드투엔드 통합 조정과 일관성 검증이 실제 일정의 핵심을 차지한다. 통신사에는 또 다른 고유한 병목이 있다: 규제 준수 및 대차 대조표. 요금 청구에서 1센트라도 차이가 나면 사고다. 검증의 비중은 어떤 산업보다도 크다. 예를 들어 기업 전용 회선 개통의 경우, AI가 각 도메인의 개발을 가속화했더라도, 엔드투엔드 통합 조정과 요금 청구 대차 대조표 작업이 여전히 전체 일정의 절반 이상을 차지한다.
금융. 신용 리스크 관리 또는 자금세탁 방지 규칙의 조정은 앱 간, 핵심 시스템, 리스크 엔진, 데이터 플랫폼, 감독 보고에 걸쳐 확장된다. 여기서 검증의 중요도는 극히 높다. 한 건의 오류만으로도 규정 위반 사고가 될 수 있기 때문이다. 병목은 설명 가능, 감사 가능, 추적 가능에 있다. AI가 작성한 규칙이 아무리 정확해도, 감독 당국의 “왜 이렇게 판단했는가?”라는 질문에 답하지 못하면 출시될 수 없다. 자금세탁 방지 규칙의 반복 개선이 전형적인 사례다. AI는 규칙 작성 속도를 높였지만, 모델의 설명 가능성 검토와 감독 보고 정합성 확보가 합쳐져 전체 주기의 대부분을 소모한다.
전자상거래. 하나의 프로모션 또는 대규모 캠페인 기능은 상품, 거래, 마케팅, 창고, 고객 서비스에 걸쳐 연결된다. AI는 페이지와 인터페이스 작성 속도를 극적으로 높였지만, 병목은 부하 테스트, 재고 일관성, 리스크 관리(薅羊毛 방지), 정산으로 옮겨갔다. 대규모 캠페인当晚 다운되는 것은 작성 속도가 느린 코드가 아니라, 검증되지 않은 경계 조건이다. 대규모 캠페인 준비는 그 자체로 단면도다. 프로모션 페이지는 AI가 빠르게 생성할 수 있지만, 엔드투엔드 부하 테스트와 재고 일관성 검증이 전쟁 준비의 대부분의 공时을 차지한다.
네 산업의 공통점은 명확하다: AI는 ‘작성’을 가속화하지만, ‘조립, 검증, 정합’에서 막힌다. 절약된 개발 역량을 이 세 가지에 투자할 때 비로소 진정한 효율 향상이 이뤄진다.
七、判断错了会怎样：三种最常见的错配
첫 번째: “코드를 빨리 쓰는 것”을 “배포가 빨라지는 것”으로 착각함.
이것은 가장 흔한 오해다. 코드는 배포 체인의 한 단계에 불과하며, 그 단계만 넓히는 것은 전체 체인의 속도를 높이지 못하고, 병목 지점 뒤에 더 많은 미완성 작업물을 쌓을 뿐이다. 제약 이론에서는 이를 재고라고 부르며, 소프트웨어 개발에서는 승인되지 않은 PR과 통합 테스트되지 않은 브랜치로 표현된다. 결과는 개발자는 더 바빠지고, 비즈니스는 더 급해지며, 산출량은 그대로라는 점에서, 개머리에서 언급한 CIO의 상황과 정확히 일치한다.
두 번째: 생산 속도를 높이면서도 품질 검증 단계를 제거함.
이는 자동화 원칙에 위배되는 전형적인 실수다. 일부는 “AI가 빠르고 잘 쓰니, 코드 리뷰는 간소화하고 테스트는 줄이자”고 생각한다. 오히려 그 반대다. 생산 속도가 빠를수록 안등 로프(An andon cord)는 더 단단히 잡아야 한다. 검증 단계를 없애는 것은 아무도 감시하지 않는 생산 라인을 최대 속도로 공회전시키는 것과 같으며, 결함은 더 빠르게 프로덕션 환경으로 흘러들어간다.
세 번째: 병목이 아닌 곳에 자원을 투자함.
통합이 병목이라면, 당신은 AI 프로그래밍 라이선스를 더 많이 사고 있다. 검증이 병목이라면, 당신은 개발자를 더 많이 채용하고 있다. 제약 이론은 이미 명확히 밝혔다: 병목이 아닌 곳에 자원을 투입하는 것은 총 산출량에 아무런 기여도 하지 않으며, 단지 재무 상태만 악화시킨다. 올바른 순서는 먼저 병목을 식별한 후, 모든 자원을 그 병목에 집중시키는 것이다.
VIII. 의사결정자에게 주는 시사점
첫 번째 통찰: 도구를 사기 전, 병목도를 그려라.
최근 세 번의 배포에서 막힌 지점을 분해해 보라. 시간이 어디에 쓰였는가? 코드를 쓰지 못해서인가, 조립이 안 되어서인가, 검증을 받지 못해서인가, 요구사항이 명확하지 않아서인가? 명확히 표시되지 않는 부분은 기술 레이어에서 막연히 추측하고 있다는 신호다. 병목도는 어떤 도구 구매 목록보다도 가치가 크며, 대기업의 무의미한 IT 투자 중 최소 절반을 차단할 수 있다.
두 번째 통찰: 절약한 생산력을 요구사항과 검증에 투자하라.
AI는 개발을 빠르게 만들었고, 그 결과 인력을 여유롭게 뺄 수 있다. 이 인력을 ‘요구사항 정의’와 ‘검증 및 수용’이라는 두 역할에 공식적으로 배치하라. 그들이 계속 코드를 더 쓰게 두지 마라. 이 두 역할의 수익률은 AI 시대에 가장 빠르게 상승하고 있다.
세 번째 통찰: 소프트웨어에 안등줄을 달아라.
자동화의 가장 직접적인 구현은 CI/CD에 단단한 기준을 두는 것이다: 테스트 통과하지 않으면 병합 금지, 리뷰는 의도와 경계를 반드시 검증해야 하며, 그레이스케일 배포는 먼저 소규모로 실행하고, 관측 가능성은 표준이 되어야 한다. 생산 환경이 자동화될수록 이 관문은 더 단단해야 한다. 이는 “코드가 무료”라는 말이 “사고가 무료”가 되는 것을 막기 위한 것이다.
네 번째 통찰: 사람의 위치를 재배치하라, 사람을 없애지 마라.
자働화는 하나의 결론을 가리킨다: 자동화가 깊어질수록, 사람은 ‘판단, 수용, 근본 원인 분석’의 위치로 이동해야 한다. 반복적인 작업에서 사람을 해방시키고, 검증과 조율의 위치로 재배치하는 것. 이것이 AI 시대의 조직 설계 핵심 행동이며, 본 시리즈의 다음 몇 편에서 더 깊이 다룰 내용이다.
아홉 번째: 당신이 궁금해할 만한 질문
“우리는 AI를 일부 부서에서만 시범 도입할 뿐인데, 전사적 병목 지도를 그릴 필요가 있을까?”
시범 도입 전에 먼저 확인해야 한다: 이 시범 단계가 진짜 병목인가? 만약 진짜 병목이 통합이나 검증 단계에 있다면, “코드 작성” 단계에 AI를 도입하는 것은 병목이 아닌 곳에 돈을 쏟는 것이며, 이는 제7장에서 언급한 세 번째 불일치에 정확히 해당한다. 먼저 소규모로 병목 진단을 수행하고 나서야 도구 투자 비용이 제대로 쓰인다.
“검증 단계가 배포 속도를 늦추지 않을까?”
단기적으로는 마찰이 생기지만, 장기적으로는 가속화된다. 검증 단계 없이 달려가는 “빠름”은 결함을 프로덕션 환경으로 밀어넣는 빠름이며, 재작업 비용은 최소 10배 이상 증가한다. 자동화 경험에 따르면: 결함을 바로 그 자리에서 해결하는 비용은, 하류로 흘러간 후에야 해결하는 비용의 극히 일부에 불과하다.
“이것이 우리가 진행 중인 AI 전환과 어떤 관련이 있을까?”
관계는 매우 명확하다. AI 전환에서 가장 흔히 범하는 실수는 병목이 ‘코드 작성/생산 능력’에 있다고 가정하고, 이 단계를 넓히기 위해 도구를 대량 구매하는 것이다. 먼저 병목 진단을 하고, 그 후에 돈을 어디에 쓸지 결정하라. 이것이 바로 내가 ‘역량 평가’와 ‘가치 시나리오 식별’을 《AI 전환 7단계 코칭 프레임워크》의 앞부분에 배치한 이유다: 도구를 논하기 전에, 먼저 병목이 어디에 있는지 보아야 한다.
역방향 자기 점검 (답변할 때 과장하지 마세요): 최근 당신이 겪은 배포 지연은 코드를 작성하는 데 시간이 더 많이 들었나요, 아니면 조립하고 검증하고 정렬하는 데 더 많이 들었나요? 당신의 AI 도구가 생성한 코드 중 안정적으로 릴리스되고 실제 사용자에게 제공되고 있는 비율은 얼마나 되나요? CI/CD 파이프라인에 “테스트 통과하지 않으면 병합 불가”라는 강제 브레이크가 있나요? 위 세 가지 중 하나라도 마음이 흔들린다면, 더 많은 AI 도구를 구매하기 전에 먼저 자신의 병목 지점을 찾아내세요.
다음 단계
이것은 “AI 시대의 소프트웨어 엔지니어링 혁명” 시리즈 15편 중 세 번째 편입니다. 콘웨이 법칙(조직이 아키텍처를 결정한다)에서 출발해 팀 토폴로지(조직을 어떻게 설계할 것인가)를 거쳐, 이제는 병목 이동(코드가 거의 무료가 되었을 때, 병목은 어디로 옮겨갔는가)에 도달했습니다. 다음 편(4편)에서는 더 실용적인 관점으로 전환합니다: 주류 AI 프로그래밍 도구를 어떻게 선택할 것인가. 그러나 결론은 직관에 반할 수 있습니다: 도구 선택은 결국 조직적 결정이며, 당신의 성숙도와 거버넌스 수준에 따라 선택해야지, “누가 더 멋진 코드를 쓰는가”로 결정해서는 안 됩니다.
시리즈 설명: 본 시리즈는 AI 프로그래밍 도구, 조직 구조, 소프트웨어 엔지니어링 패러다임의 최신 진화를 지속적으로 추적합니다. 예를 들어 2026년 AI 에이전트 시대의 콘웨이 법칙 변화, 최신 도구 생태계의 성숙도 등입니다. 본 시리즈를 구독하여 지속적인 통찰을 받아보세요.
본 시리즈에 대해
AI 시대의 소프트웨어 엔지니어링 혁신은 통신, 금융, 제조, 전자상거래 등 산업의 CIO/CDO/CTO 및 디지털화 담당자를 위한 심층 연구 시리즈로, 총 15편으로 구성됩니다. 200여 편의 학술 논문과 산업 보고서를 기반으로, 증거 수준이 표기된 의사결정 참고 자료를 제공합니다.
저는 전 IBM 엔지니어이자 ICF 인증 코치로, 통신사 및 대기업의 AI/디지털화 프로젝트 실행을 직접 수행했습니다. 여기에 기록된 내용은 기업과 함께 고난을 겪으며 얻은 실전 판단입니다.
참고 자료(모두 검증됨)
a16z (2026). Software in the Age of Agents. The a16z Podcast. (전 마이크로소프트 윈도우 사장 스티븐 시노프스키의 명언: “The long tail got no shorter, it just got longer in a different way” — 기업 소프트웨어 관점에서 TOC 병목 이동 법칙을 독립적으로 입증; 1차 자료 — 팟캐스트 원음. 입장 표시: a16z 파트너 / 전 마이크로소프트 임원, VC 입장. 게스트 검증 완료: a16z 기업 팀 파트너 세마 암블, 전 마이크로소프트 윈도우 사장 스티븐 시노프스키(board partner), a16z 기고가 일레나 버거; 방영일 2026년 7월.)
Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (제약 이론(TOC)의 원천 자료, 1차 자료; 제조 공장 환경을 배경으로 한 소설)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (Goldratt의 TOC를 IT 운영에 그대로 적용한 사례 — 제조에서 소프트웨어로의 다리, 1차 자료)
Toyota. Toyota Production System — Jidoka(자동화). toyota-global.com (자동화 = ‘자’에 사람 편이 붙은 ‘자働화’ — 이상 발생 시 라인 정지 + 인간의 개입으로 근본 원인 해결; 안등 시스템; 1차 자료)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot가 파일 내 완성 기능을 통해 약 46%의 코드를 생성 — ‘파일 내 활성화’ 기준; 1차 자료)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ 보도에 따르면 매주 1,300개 이상의 PR 생성, 전량 수동 리뷰 수행 (1차 + 2차 자료)
NVIDIA / 황 Jen-hsun. “100%의 엔지니어가 Cursor 등 AI 프로그래밍 도구를 사용한다”는 공개 발언 (1차 발언)
GitClear (2025). AI-Assisted Code Quality Research. (AI 보조 하에서 중복 코드 및 단기 churn 증가 현상 관찰 — “검증 비용 증가”를 뒷받침, 2차 자료)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (배포 성과는 개인 코딩 속도가 아니라 문화, 흐름 속도, 피드백에 의해 결정됨; 1차 자료)
buymeacoffee
![[병목 이동] 코드가 거의 제로 비용이 되었을 때, 소프트웨어 공학의 병목은 어디로 갔는가? AI 시대의 소프트웨어 공학 혁신 — 천천히 AI 배우기 173](https://cdn.iaiuse.com/img/2026/07/13/d39583784356669e4e768cd4d75981e6.webp)
