④ AI로 직원들이 빨라져도 일은 계속 밀리는 이유

2026년 발표된 한 연구는 생성형 AI가 소프트웨어 개발 현장을 어떻게 뒤바꾸고 있는지를 50만 명이 넘는 깃허브(GitHub) 개발자들의 실제 사용 기록을 통해 치밀하게 추적했다. 연구진이 파고든 질문은 단순히 "AI를 쓴 개발자가 코드를 더 많이 짜냈는가?"가 아니었다. 자동완성 도구에서 대화형 코딩 에이전트, 나아가 자율적으로 움직이는 에이전트로 AI가 진화하는 동안, 개발의 각 단계별 실제 산출물이 어떻게 달라지는지를 차례대로 짚어보았다.

결과는 꽤 극적이었다. 최신 세대의 AI 도구를 쥐여주자 개발자의 코딩 활동을 나타내는 커밋(Commit) 횟수는 누적으로 약 240%나 폭증했다. 그런데 이 마법 같은 효과는 개발 프로세스의 뒤쪽으로 갈수록 급격하게 증발해 버렸다. 개발자가 손을 댄 프로젝트 수의 증가는 약 80%에 그쳤고, 최종적으로 실제 사용자에게 배포된 릴리스(Release)는 고작 30% 늘어나는 데 그친 것이다(Demirer et al., 2026).

AI가 코드를 쏟아내는 속도는 가히 폭발적으로 높아졌지만, 그 코드가 실제 완제품이 되어 세상에 나오는 속도는 결코 그에 비례하여 빨라지지 않은 것이다. 어딘가 이상하지 않은가? 코드를 짜는 것이 소프트웨어 개발의 핵심 업무라면, 코드를 세 배 넘게 쏟아낼 수 있게 되었을 때 완제품 역시 세 배 가까이 쏟아져 나와야 정상 아닐까? 이 딜레마의 원인은 명확하다. 기업의 일이란 결코 단일한 업무 하나로 끝맺음되지 않는다는 데 있다.

코드를 짜는 것과 소프트웨어를 내놓는 것은 전혀 다른 일

개발자가 모니터 앞에서 코드를 신나게 짜냈다고 해서 그것이 곧바로 고객이 결제하고 사용할 수 있는 제품이 되는 것은 아니다. 만들어진 코드는 다른 동료 개발자의 꼼꼼한 검토(Review)를 거쳐야 하고, 기존 시스템의 코드들과 충돌하지 않는지 확인해야 한다. 까다로운 테스트를 통과해야 하며 치명적인 보안 구멍은 없는지 점검받아야 한다. 이 모든 관문을 뚫고 나서야 비로소 다른 기능들과 결합되어 배포(Deploy)된다. 이를 단순화하면 업무의 흐름은 다음과 같다.

요구사항 결정 → 코드 작성 → 코드 검토 → 수정 → 테스트 → 최종 배포

최신 AI 코딩 에이전트는 이 사슬 가운데 코드 작성이라는 단일 고리의 속도를 엄청나게 끌어올릴 수 있다. 그러나 코드를 검토하는 사람의 시간과 집중력은 그대로이고 조직의 테스트 처리 능력도 과거와 똑같다면 어떤 일이 벌어질까?

앞 단계에서 AI가 코드를 미친 듯이 쏟아낸 만큼, 바로 그다음 단계의 담당자 책상 위에는 처리해야 할 일감이 무서운 속도로 쌓이게 된다. 실제로 Demirer 등의 연구에서도 AI로 인한 생산성 향상의 축포는 코드 작성 단계에서만 터졌을 뿐, 최종 배포로 갈수록 그 효과가 처참하게 희석되었다.

연구진은 이를 약한 고리(Weak-link) 문제로 설명한다. AI가 맹활약하는 단계와 사람이 짊어져야 하는 후속 단계가 강하게 얽혀 있는 보완적 관계이기 때문에, 어느 한 단계의 생산 능력만 부풀려 놓아도 나머지 단계가 보폭을 맞추지 못하면 최종 산출물은 꽉 막혀버린다는 것이다.

유사한 결과는 다른 기업 데이터에서도 심심찮게 관찰된다. 2026년 하버드 연구진이 기업용 AI 코딩 도구 도입 효과를 분석한 연구를 보자. AI 도입 후 개발자 개인의 코딩 활동량은 약 8.5% 증가했고 과업 완료 시간은 약 8.7% 줄어들었다. 하지만 개발팀이 최종적으로 완료해 낸 과업의 총량에서는 통계적으로 유의미한 증가가 발견되지 않았다. 직원 한 사람의 손이 빨라진 것과 조직 전체가 돈이 되는 일을 더 많이 끝낸 것은 완전히 별개의 결과였던 셈이다(Chen & Stratton, 2026).

왜 이런 일이 벌어질까? 복잡한 IT 기업 대신 동네 식당을 떠올려 보면 이해가 훨씬 쉽다. 한 시간에 주문을 30건 받을 수 있는 홀 직원 1명과, 한 시간에 요리를 10인분 만들어내는 주방이 있다고 치자. 식당 사장님이 생산성을 높이겠다며 고성능 키오스크 3대를 들여놓아 한 시간에 100건의 주문을 거뜬히 받을 수 있게 만들었다. 홀의 주문 접수 생산성은 무려 3배 이상 폭등했다. 하지만 그렇다고 해서 식당 안의 손님 100명이 한 시간 안에 따뜻한 밥을 먹을 수 있을까? 절대로 아닌걸 누구나 눈치챌 수 있을 것이다. 주방의 낡은 화구는 여전히 10인분밖에 소화하지 못한다. 키오스크 도입으로 달라진 것은 손님상에 요리가 나가는 속도가 아니라, 비좁은 주방 앞에 쌓여가는 주문서와 분통을 터뜨리는 손님들의 대기열뿐이다.

모든 업무를 맹목적으로 빨리 해치울 필요는 없다

이러한 병목 현상은 생산 관리(Operations Management) 분야에서는 너무나 오래되고 익숙한 고전적 과제다. 기업의 프로세스는 수많은 활동이 톱니바퀴처럼 차례로 맞물려 돌아가는 하나의 거대한 흐름이다. 그리고 이 전체 흐름이 얼마나 빨리 목적지에 도달하는지는, 각 활동의 개별 생산성을 덧셈한다고 해서 구해지지 않는다.

처리 능력이 턱없이 부족하거나 변동성이 커서 일이 상습적으로 정체되는 구간이 단 하나라도 있다면, 그 앞단에 거대한 대기행렬(Queue)이 형성된다. 앞 단계에 아무리 비싼 돈을 들여 생산 능력을 과잉 공급해 봐야 최종적인 산출량은 병목의 크기만큼만 빠져나온다. 1961년 존 리틀(John Little)이 정립한 이른바 리틀의 법칙(Little’s Law)은 안정적인 프로세스 안에서 매우 단순하고도 냉혹한 진리를 보여준다. 시스템 내부에 쌓여 있는 일감(재공품)의 양은, 시스템이 최종적으로 일을 뽑아내는 처리율과 일감이 시스템에 머무는 시간을 곱한 값이라는 것이다(Little, 1961).

이 법칙만 가지고 어느 부서가 병목인지 알 수는 없지만, 출구 쪽의 처리율은 그대로인데 입구 쪽에 고성능 AI를 달아 새로운 일감을 마구 쏟아부으면, 그 잉여 불균형이 어디로 향할지는 자명하다. 처리되지 못한 채 썩어가는 일감이 프로세스 내부에 고이고 대기 시간만 하염없이 길어진다. 현실의 기업 환경은 이보다 훨씬 가혹하다. 사람과 시스템의 처리 속도는 공장의 컨베이어 벨트처럼 매번 일정하지 않다. 운 좋게 수월한 일이 몰릴 때도 있지만, 예기치 못한 까다로운 문제 하나가 귀중한 인적 자원을 며칠씩 옴짝달싹 못 하게 붙잡아 두기도 한다. 이미 턱밑까지 일감이 차올라 허덕이는 병목 부서에서는 아주 작은 변동성만 발생해도 전체 대기 시간이 걷잡을 수 없이 폭증한다. 그래서 전문적인 운영 관리에서는 개별 작업자가 "몇 분 만에 일을 끝냈느냐"는 평균 소요 시간만 쳐다보지 않고, 전체 처리 능력, 자원 이용률, 대기행렬의 길이, 재작업 빈도와 변동성을 종합적으로 입체 분석한다(Hopp & Spearman, 2004).

이 관점에서 기업들의 현주소를 돌아보면, "우리 직원들이 가장 많은 시간을 빼앗기고 있는 업무부터 차악으로 골라 AI로 자동화하자"는 흔한 접근법이 얼마나 위험한 착각인지 알 수 있다. 시간을 가장 많이 잡아먹는 덩치 큰 업무와 우리 조직 전체의 성과를 옥죄고 있는 병목 업무는 결코 같은 자리에 있지 않을 확률이 높기 때문이다.

돈이 되는 비싼 문제를 골랐다고 안심하긴 이르다

지난 3회 칼럼에서 우리는 "AI가 알아서 잘하는 뻔한 업무를 찾지 말고, AI가 그 일을 훌륭히 해냈을 때 회사에 큰돈이 굴러들어오는 비싼 문제부터 찾아야 한다"고 강조했다. 좋다, 경영진이 고심 끝에 기업 대출 심사라는 큰 판돈이 걸린 훌륭한 문제를 골라냈다고 가정해 보자. 하지만 대출 심사 역시 책상머리에서 도장 한 번 찍는 단일 과업이 아니다.

서류 접수 → 정보 추출 → 신용 분석 → 담보 평가 → 최종 승인 → 약정 체결

대출 업무는 위와 같은 릴레이식 흐름으로 구성된다. 여기서 실무 직원이 방대한 기업 재무제표와 사업보고서 텍스트를 뒤져 필요한 알짜 정보를 추출해 내는 데 4시간이 걸린다고 치자. 여기에 최신 AI를 투입해 그 시간을 30분으로 단축시킨다. 무려 87.5%의 경이로운 시간 절감이다. 데모 버전으로 경영진 앞에서 시연을 하면 여기저기서 박수가 터져 나올 만한 화려한 기술적 성과다. 그런데 실상은 이렇다면 어떨까? 고객이 최초로 대출 신청 서류를 밀어 넣은 뒤 최종 승인 통보를 받기까지 걸리는 시간은 총 10일이다. 그중 3일은 현장 담보 평가 결과를 하염없이 기다리는 데 허비되고, 또 다른 3일은 바쁜 승인권자의 결재 서류함에서 먼지를 맞으며 대기하는 데 쓰이고 있다.

이런 상황에서 앞단의 정보 추출 시간을 3시간 30분 단축한 것은 분명 기분 좋은 일이다. 하지만 고객이 체감하는 대출 실행 날짜에는 그 어떤 단축도 일어나지 않는다. 3회에서의 질문이 "수많은 문제 중 어떤 문제를 골라야 하는가?"였다면, 이번 4회에서는 한 겹 더 파고들어야 한다. "그 굵직한 문제 안에서, 정확히 '어느 지점'의 막힌 혈을 뚫어내야 회사의 최종 결과물(매출, 고객 만족)이 움직이는가?"

이 두 질문의 선후를 뒤섞어 버리면 AI 프로젝트의 우선순위는 기괴하게 꼬여버린다. 경제적으로 무척 중요한 핵심 프로세스를 기가 막히게 골라놓고도, 정작 그 안에서는 AI가 가장 만만하게 잘할 수 있는 엉뚱한 부분만 골라 덧칠하는 우를 범하기 때문이다. 그 결과, IT 부서의 슬라이드 위에서는 100점짜리 성공한 AI 프로젝트가 탄생하지만, 정작 고객이 경험하는 리드 타임이나 기업이 하루에 쳐내는 총업무량, 그리고 재무제표상의 매출과 비용에는 털끝만 한 변화도 일어나지 않는 희극이 연출된다.

AI는 병목을 영원히 없애는 것이 아니라 이동시킬 뿐이다

여기서 경영진을 골머리 앓게 만드는 또 다른 난관이 등장한다. 기가 막힌 통찰력으로 진짜 병목을 정확히 짚어내어 AI를 훌륭히 이식했다고 해도 게임은 끝나지 않는다. 어느 조직의 소프트웨어 개발 프로세스에서 코드 작성 단계가 진짜 꽉 막힌 병목이었다고 치자. 천문학적인 비용을 들여 AI를 도입해 그 지긋지긋한 병목을 시원하게 뚫어냈다. 해피엔딩일까? 천만에. 이제부터는 밀려드는 코드를 감당하지 못하는 코드 검토(Review) 단계가 조직의 새롭고 끔찍한 병목으로 등극한다. 부랴부랴 검토 과정까지 자동화의 숨통을 틔워 놓으면, 그다음엔 QA 테스트 단계가 폭발 직전까지 내몰린다. 테스트까지 빛의 속도로 단축시키면? 종국에는 만들어진 기능을 소화하고 도입할 고객의 역량 자체가 새로운 성장의 제약 조건으로 떠오른다. 즉, 압도적인 기술 발전은 조직의 병목을 영원히 소멸시키는 것이 아니라, 그 병목의 위치를 교묘하게 다음 칸으로 이동시킬 뿐이다.

이 사실이 생성형 AI 시대에 유독 뼈아프게 다가오는 이유가 있다. 생성형 AI는 글쓰기, 코딩, 방대한 문서 요약, 복잡한 이미지 생성 같은 특정 인지적 과업의 생산 능력을 찰나의 순간에 몇 배, 몇십 배씩 뻥튀기할 수 있는 파괴력을 지녔다. 반면, 조직 내에서 결재를 내리고, 리스크를 판단하며, 시스템을 통합하는 인간과 관료주의의 속도는 결코 그 기술의 팽창 속도를 따라잡지 못한다. 영업팀에 제안서 작성 AI를 전격 도입했다고 가정해 보자. 영업 사원 한 명이 일주일에 헉헉대며 짜내던 제안서가 5건에서 20건으로 4배나 늘었다. 시장에 우리의 제안을 받아줄 잠재 고객이 널려 있고 후속 미팅을 뛸 영업 인력이 넉넉하다면, 이 생산성 폭발은 짜릿한 매출 폭주로 이어질 것이다.

그러나 현실의 영업 관리자(팀장)가 내용증명과 리스크를 꼼꼼히 따져가며 하루에 최종 결재를 올릴 수 있는 제안서의 한계치가 10건뿐이라면 어떨까? 실무자의 제안서 생산성은 4배로 날개를 달았지만, 이제 관리자의 책상 위에는 승인을 받지 못한 제안서들이 무덤처럼 쌓여간다. 이러한 상황에서 "AI의 프롬프트 엔진을 더 고도화하여 제안서 작성 속도를 2배 더 올리자"고 투자하는 것은 기업의 숨통을 끊어 놓는 짓이다. 그것은 회사의 매출을 늘리는 투자가 아니라, 조직 내부에 불필요한 재고(미완료 업무)만 더 빠르게 찍어내는 공장을 짓는 것과 같다.

AI의 성과는 개별 단계의 속도가 아니라 전체 흐름의 결과로 증명된다

그러므로 경영진이 수많은 AI 투자 후보군을 저울질할 때, "우리 직원들이 하루 중 가장 많은 시간을 빼앗기는 업무 Top 10" 같은 리스트를 뽑아 들고 설레는 것은 해서는 안된다. 최신 AI 모델이 가장 소름 돋는 정확도를 자랑하거나 시간 단축 벤치마크 테스트에서 1위를 차지한 과업부터 골라 담는 것 역시 똑같은 착각에 불과하다.

제대로 된 AI 페이오프를 거두려면, 먼저 단일 업무의 장벽을 허물고 하나의 일감이 고객이나 최종 산출물에 도달하기까지 실제로 어떻게 흘러가는지 전체 프로세스의 지도를 그려봐야 한다. 도대체 어느 구간에서 일이 가장 오래 멈춰서 먼지를 맞고 있는지, 어느 단계에서 윗선의 핑퐁에 막혀 재작업이 무한 반복되는지, 고객의 수요를 뻔히 알면서도 내부 처리 능력이 턱없이 달려 스스로 성장을 갉아먹는 곳이 어디인지, 어느 한 부서가 기침을 하면 조직 전체가 독감에 걸려 멈춰 서는 급소가 어디인지를 투시해야 한다. 그 치열한 탐색이 끝나고 나서야 비로소, "AI가 과연 이 꽉 막힌 혈(제약)을 실제로 뚫어낼 수 있는가?"를 묻는 것이 순서다.

우리가 AI 페이오프의 첫 단추인 발굴(Map) 단계에서 단순히 개별 과업의 이름표만 적지 않고, 전체 프로세스의 투입 대비 산출(기준선), 대기 시간과 재작업 빈도, 그리고 굳건한 병목의 위치를 한 장의 지도 위에 나란히 올려놓고 보는 이유가 바로 여기에 있다. AI 모델의 기술적 벤치마크 점수를 측정하고 감탄하는 것은 언제나 그 지루한 맵핑이 끝난 이후의 일이다.

결국 AI 시대를 헤쳐 나가는 경영자는 "AI를 쥐여줘서 이 구간을 단축시켰을 때, 우리 회사의 최종적인 돈과 결과물도 정말 증가하는가가?"를 추궁해야 한다. 앞서 서두에 언급했던 50만 명의 개발자 연구가 세상에 외치는 경고도 바로 이 간극이다. AI는 놀랍도록 똑똑해져서 코드를 쏟아내는 역량을 240%나 끌어올렸지만 그 텍스트 쪼가리가 살아 숨 쉬는 제품이 되려면 여전히 깐깐한 인간이 검토하고, 시스템과 통합하며, 버그를 잡고, 힘겹게 출시 버튼을 눌러야만 한다.

최신 AI가 우리 직원의 특정 업무를 세 배나 빠르게 만들어준다는 것은 분명 가슴 벅찬 기술적 혁명이다. 하지만 그 업무가 애당초 조직 전체의 흐름을 막고 있던 진짜 병목이 아니었다면, 기업이 얻게 되는 것은 세 배 빨라진 쾌적한 프로세스가 아니라 세 배 더 빠른 속도로 턱밑까지 차오르는 일감의 더미일지도 모른다.

Chen, F., & Stratton, J. (2026). Artificial intelligence in the firm: Bottlenecks in software production [Working paper]. Harvard University.

Demirer, M., Musolff, L., & Yang, L. (2026). Writing code vs. shipping code: Productivity effects across generations of AI coding tools (NBER Working Paper No. 35275). National Bureau of Economic Research. [https://doi.org/10.3386/w35275]

Hopp, W. J., & Spearman, M. L. (2004). To pull or not to pull: What is the question? Manufacturing & Service Operations Management, 6(2), 133–148. [https://doi.org/10.1287/msom.1030.0028]

Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383–387. [https://doi.org/10.1287/opre.9.3.383]