이 글은 AI가 개발자를 대체한다는 이야기가 아니다. AI 도구가 나쁘다는 이야기도 아니다. 팀의 협업이 원래 어떤 방식으로 조율되고 있었는지, 그리고 그 조율 장치가 AI 앞에서 왜 조용히 사라지는지에 대한 이야기다.

AI 생산성 역설은 속도가 아니라 조율의 문제다

이 글은 AI 생산성 역설을 개발팀의 코드 리뷰 병목에서 출발해 조직 거버넌스 문제로 확장해 보는 글이다. AI 검색과 콘텐츠 구조화 관점은 llms.txt와 AI 검색 최적화 글도 함께 참고할 만하다.

처음에는 이걸 그냥 "일이 늘었다" 정도로 받아들였다. 산출물이 많아졌으니 검토할 것도 많아졌다는, 단순한 총량의 문제라고 생각했다. 그런데 곰곰이 보니 총량의 문제가 아니었다. AI가 들어오기 전에도 팀은 계속 바빴다. 다만 그때는 일이 진행되는 리듬 자체에 조율이 끼어들 틈이 있었다. A가 뭔가를 만들면 B가 그걸 받아서 쓰기까지 시간이 걸렸고, 그 시간 동안 서로 상황을 맞춰볼 여지가 있었다. AI가 그 틈을 지운 것이다.

인간 협업에서 '느림'이 하던 일

이전에는 조율이 사람 노력의 물리적 한계로 자연스럽게 강제됐다. 설계자가 설계 문서를 순식간에 다시 써낼 수 없었기 때문에, 개발자들은 어느 정도 안정된 목표를 두고 작업할 수 있었다. 개발자가 몇 분 만에 모듈 전체를 새로 짤 수 없었기 때문에, 변경은 신중하게 이루어졌고 논의를 거쳤고 눈에 보이는 과정으로 남았다. 테스터가 방대한 테스트 스위트를 자동으로 만들어낼 수 없었기 때문에, 테스트 범위는 협의와 우선순위 조정을 거쳐 정해졌다. PR 하나를 준비하는 데도 품이 들었기 때문에, PR 한 건 한 건이 그만큼의 의도를 담고 있었다.

모두가 비슷한 속도로 움직였다. 그리고 그 비슷한 속도 자체가 하나의 동기화 장치였다. 누군가 느려지면 옆에서 알아챘다. 의존 관계가 바뀌면 변경의 비용이 대화를 강제했다. 산출물이 만들어지는 데 드는 노력 자체가 자연스러운 체크포인트를 만들었다.

느림은 그저 비효율이 아니었다. 그 자체로 팀을 서로 맞춰주는 암묵적 동기화 장치였다.

이 문장을 곱씹고 나서야, 내가 겪었던 리뷰 병목이 단순한 "일이 늘어난 문제"가 아니라 "조율 장치가 사라진 문제"라는 게 보이기 시작했다.

상호의존적 업무에서 유독 도드라지는 이유

모든 업무가 이 문제를 똑같이 겪지는 않는다. 조직에서 업무가 얽히는 방식은 크게 세 가지로 나눌 수 있다. 각자 독립적으로 일하다가 결과만 합치는 방식(풀형), A가 끝나야 B가 시작하는 방식(순차형), A와 B가 서로 주고받으며 진행하는 방식(상호형)이다. 문제가 두드러지는 쪽은 뒤의 두 가지, 그중에서도 A의 산출물이 B의 선결 조건이 되거나 B의 작업에 계속 영향을 미치는 경우다.

사람끼리 일할 때는 A가 산출물을 내는 데 걸리는 시간과 B가 그걸 소화하는 데 걸리는 시간이 비슷한 자릿수 안에 있었다. 그래서 A가 조금 앞서가면 B가 따라잡을 여유가 있었고, 방향이 어긋나면 중간에 재정렬할 시간이 있었다. AI가 A의 속도만 끌어올리면 이 균형이 깨진다. A는 순식간에 여러 버전의 산출물을 만들어낼 수 있지만, B가 그걸 이해하고 검증하고 자기 작업에 반영하는 속도는 예전 그대로다. 이해하고, 판단하고, 책임지는 일은 여전히 사람의 인지 속도를 벗어나지 못하기 때문이다.

내가 만든 AI 코드 리뷰 봇도 정확히 이 지점에서 한계를 보였다. 봇은 A(코드 작성)와 B(리뷰) 사이의 속도 격차를 줄여주는 도구였지만, 격차를 완전히 없애지는 못했다. 봇이 놓친 걸 사람이 다시 봐야 했고, 봇의 코멘트가 맞는지 판단하는 것도 결국 사람의 몫이었다. 병목이 사라진 게 아니라 한 단계 뒤로 밀렸을 뿐이었다.

산출물은 늘고, 검토가 병목이 된다

이 현상은 이제 코드 리뷰 영역에서 꽤 구체적인 수치로도 확인된다. 다만 여기서 자주 뒤섞여 인용되는 두 종류의 데이터를 구분할 필요가 있다. 성격이 전혀 다르기 때문이다.

하나는 개인 차원의 착시다. 2025년 7월 METR가 진행한 무작위 대조 실험에서, 자기 저장소를 오래 다뤄온 숙련 개발자 16명에게 AI 사용 여부를 무작위로 배정했다. 결과는 뜻밖이었다. AI를 쓴 쪽이 작업을 끝내는 데 오히려 19% 더 오래 걸렸다. 그런데 정작 개발자들은 실험 전에는 24% 빨라질 거라 예측했고, 자기 시간 데이터를 눈으로 보고 난 뒤에도 여전히 AI가 자신을 20% 빠르게 만들어줬다고 믿었다. 체감과 실제 사이에 40%p에 가까운 인식 격차가 벌어진 셈이다.

물론 이 실험은 그대로 일반화하기엔 조건이 특수하다. 표본이 16명으로 작고, 초기 2025년 모델을 썼으며, 무엇보다 개발자가 이미 훤히 꿰고 있는 성숙한 대형 오픈소스 코드베이스라는, AI에게 유독 불리한 환경이었다. 낯선 코드나 새로 시작하는 프로젝트에서는 결과가 다를 수 있다. 다만 이 실험이 말해주는 핵심은 "AI가 무조건 느리게 만든다"가 아니라, 개발자 스스로의 체감이 실제 성과를 신뢰할 만한 지표로 삼기 어렵다는 것이다.

다른 하나는 팀 차원의 병목이다. 22,000명 규모의 실제 개발 텔레메트리를 분석한 리서치에서는, AI 도입 이후 개발자당 PR 물량이 배 가까이(약 98%) 늘었고, 그만큼 리뷰에 걸리는 시간도 급격히 늘어난 것으로 나타났다. 개발자는 원래도 코드 리뷰에 상당한 시간을 쓰고 있었는데, 여기에 물량이 배로 더해지면 감당할 여력이 남지 않는다.

여기서 오해하기 쉬운 지점이 있다. 그렇다고 팀의 처리량이 줄어든 건 아니다. 오히려 개발자당 작업 완료량도, 병합되는 PR 수도 함께 늘었다. 문제는 늘어난 산출물을 검증하고 안정적으로 통합하는 속도가 그 증가 폭을 따라가지 못했다는 데 있다. 같은 데이터에서 리뷰 대기 시간은 다섯 배 가까이, 사고율은 몇 배로 뛰었고, 인간 리뷰를 아예 거치지 않고 병합되는 PR 비중까지 늘었다. 생성은 폭발적으로 늘었는데, 그걸 받아 처리하는 하류 공정이 감당하지 못하면서 병목이 뒤 단계로 밀린 것이다.

이 두 데이터를 겹쳐 놓으면 "개인 수준의 생산성 향상이 곧 시스템 수준의 처리량 향상을 뜻하지는 않는다"는 정리가 왜 반복해서 나오는지 이해가 된다. 개발자 개인은 분명 빨라졌다고 느낀다. 코드를 짜는 시간이 줄었으니까. 그런데 팀 전체로 보면 그 이득의 상당 부분이 리뷰 지연과 재작업, 사고 대응으로 다시 새어 나간다. 협업의 조율 비용이 사라진 게 아니라, 어딘가로 옮겨 갔을 뿐이라는 증거다.

AI 생산성 역설의 변수는 속도가 아니라 조율이다

한 가지 덧붙일 게 있다. 최근 데이터가 전부 "AI가 팀을 느리게 만든다"는 쪽을 가리키는 건 아니다. 오히려 반대 방향의 반전도 있다. 구글 DORA의 2025년 보고서는, 2024년과 달리 AI 도입이 소프트웨어 배포 처리량 및 제품 성과와 양(positive)의 상관을 보였다고 밝혔다. 전년의 결과가 뒤집힌 것이다. 다만 같은 보고서는 AI가 배포 안정성과는 여전히 음의 상관을 보인다고 덧붙였다. 속도는 나아졌지만 그 속도가 만든 불안정은 그대로였다는 뜻이다.

흥미로운 건 이 보고서가 AI를 "거울이자 증폭기(mirror and multiplier)"라고 표현한 대목이다. 조율이 잘 되는 조직에서는 AI가 효율을 끌어올리지만, 파편화된 조직에서는 오히려 약점을 드러내고 키운다는 것이다. 이건 내가 겪은 병목과 정확히 맞물린다. 문제의 변수는 AI의 속도 그 자체가 아니었다. 그 속도를 받아낼 조율 구조가 이미 있었느냐 없었느냐였다. 속도는 모두에게 공통으로 주어지지만, 결과는 조율의 유무에서 갈린다.

거버넌스가 없는 게 아니라, 낡은 속도로 설계돼 있다

여기서 한 가지는 조금 정정하고 싶다. 처음에는 이 문제를 "팀의 업무 할당과 협업 거버넌스가 아직 정의되어 있지 않아서"라고 생각했다. 그런데 조금 더 들여다보니, 정확히는 "정의가 없다"기보다 "인간의 속도를 전제로 정의된 거버넌스가 AI의 속도 앞에서 무력화된다"는 쪽에 가까웠다.

리뷰 프로세스, 승인 절차, 역할 분담 같은 것들은 원래 있었다. 다만 그 절차들은 사람이 사람 속도로 산출물을 만들던 시절에 맞춰 설계된 것이었다. 강한 CI/CD와 리뷰 프로세스를 갖춘 성숙한 조직조차 품질 저하를 피하지 못했다는 관찰이 있는데, 이유는 단순하다. 그 프로세스들이 애초에 더 낮은 처리량을 전제로 설계돼 있었기 때문이다. 거버넌스가 텅 비어 있는 게 아니라, 낡은 기어비로 맞춰진 채 방치돼 있는 것이다.

한편 조직 전체를 놓고 보면, 이 낡은 기어비를 새로 맞추는 작업 자체가 한참 뒤처져 있다. 여러 조사를 종합하면, AI를 실제로 쓰는 조직은 많아도 제대로 된 거버넌스 프레임워크까지 갖춘 곳은 셋 중 하나 안팎에 그친다. 한 조사에서는 AI 사용 정책은 75%가 두고 있었지만 공식적인 거버넌스 프레임워크까지 갖춘 곳은 36%에 불과했다. AI가 잘못한 게 아니다. 애초에 명확한 지도 없이 다 같이 어두운 방을 걷고 있었는데, 다들 걸음만 빨라진 셈이다.

이 문제는 개발조직만의 것이 아니다

여기까지 쓰고 나서 스스로에게 물었다. 이게 정말 개발팀만의 이야기일까. 아니었다. 최근 여러 조사를 보면 이 어긋남은 오히려 개발조직 바깥에서 더 크게 벌어지고 있었다.

한 대규모 엔터프라이즈 설문(IT 임원 1,600명 대상)에서는 응답자의 82%가 비즈니스 부서와 IT 사이의 사일로 때문에 기술 이니셔티브를 실행하기 어렵다고 답했고, 79%는 비IT 부서 직원들이 AI 애플리케이션이나 에이전트를 스스로 만들어 쓰는 걸 목격했다고 답했다. IT가 정한 절차를 거치지 않고, 각 부서가 각자의 속도로 AI를 들여오고 있다는 뜻이다. IT 리더의 눈에 비친 풍경이라는 점을 감안하더라도, 각 부서가 IT의 승인 리듬을 기다리지 않고 독자적으로 움직이고 있다는 신호는 분명하다.

구체적인 사례도 한 건 보고돼 있다. 한 논문이 소개한 중견 전문 서비스 기업의 이야기다. 이 회사 마케팅팀은 AI로 제안서 콘텐츠 작성 시간을 40% 줄이며 성공적으로 파일럿을 마쳤다. 문제는 이걸 다른 부서로 확산하려던 순간 시작됐다. 마케팅의 AI 워크플로우는 그 부서에 맞게 지나치게 세밀히 조정되어 있어서 다른 팀으로 그대로 옮겨지지 않았고, 법무·컴플라이언스 팀은 고객 정보가 걸린 AI 사용에 사전 승인을 요구하는 정책을 새로 만들면서 사실상 대부분의 실용적인 활용을 막아버렸다. 코드 리뷰 병목과 형태만 다를 뿐, 구조는 똑같았다. 한쪽의 산출물 속도가 갑자기 빨라지자, 그걸 받아서 처리해야 하는 쪽이 감당하지 못했다.

어떤 경계가 흔들리는가는 그 경계를 무엇이 붙들고 있었느냐에 달렸다

부서마다 업무 경계가 있다는 건 똑같다. 다른 건 그 경계를 무엇이 붙들고 있느냐다. 크게 세 가지로 나뉘고, AI 앞에서 버티는 힘도 그 종류에 따라 갈린다.

첫째는 기술적 인터페이스로 강제되는 경계다. 개발조직이 여기에 해당한다. 백엔드가 프론트엔드 코드를 마음대로 고칠 수 없는 건 예의나 관행 때문이 아니라, API와 DB 스키마와 서비스 경계가 애초에 그렇게 접근할 수 있는 구조를 허용하지 않기 때문이다. 사람이 합의해서 지키는 게 아니라 구조가 물리적으로 막는다.

둘째는 외부 규제로 문서화된 경계다. 재무와 인사, 법무가 대체로 이쪽이다. 회계기준, 노동법, 자격증 체계 같은 외부의 규칙이 "여기까지가 재무의 영역"이라는 선을 문서로 붙들고 있다. 인터페이스만큼 물리적이진 않지만, 어긋났을 때 감사나 법적 책임이라는 외부의 힘이 뒤에서 경계를 다시 세워준다.

가장 취약한 건 셋째, 오직 사람 간 관행과 결재 프로세스로만 유지되는 경계다. 마케팅과 재무 사이, 영업과 법무 사이가 대표적이다. 여기엔 접근을 막아줄 기술적 인터페이스도 없고, 곧바로 붙잡아줄 외부 규제라는 방어막도 얇다. "이건 재무팀 일이고 저건 우리 일"이라는 암묵적 합의와 결재 라인이 경계의 거의 전부다.

AI는 정확히 이 세 번째 종류의 경계를 손쉽게 우회하게 해준다. 마케터가 재무 모델을 대신 만들어보고, 영업 담당자가 법무 검토 없이 계약서 초안을 뽑아보는 일이 이제는 기술적으로 아무 문제 없이 가능해졌다. 인터페이스가 막아주지도 않고, 규제가 곧바로 붙잡아주지도 않기 때문이다. 그러니 어떤 부서가 더 흔들리느냐는 그 부서가 얼마나 오래됐느냐나 얼마나 'IT스러우냐'가 아니라, 경계를 붙들던 게 인터페이스였는지, 규제였는지, 아니면 관행뿐이었는지에 달려 있다.

무너졌을 때 남는 결과도 다르다

개발조직에서 경계가 흔들리면 대개 리뷰가 밀리는 비효율로 끝난다. 불편하지만 되돌릴 수 있는 문제다. 그런데 전통 부서에서 경계가 흔들리면 얘기가 달라진다. 누가 만들었는지 불분명한 재무 추정치, 법무 검토를 거치지 않은 계약서 문구는 비효율이 아니라 곧바로 컴플라이언스와 법적 리스크로 이어진다. 앞서 본 사례에서 법무팀이 서둘러 사전 승인 정책을 만든 것도 이런 이유였을 것이다. 같은 구조의 문제라도, 부서에 따라 결과의 무게가 다르다.

조율을 다시 설계하는 네 가지 방법

이 문제를 완전히 없앨 수는 없다고 본다. 다만 줄이는 방향은 있다고 생각한다. 아래는 개발조직을 기준으로 정리했지만, 산출물의 속도가 관행이 아니라 인터페이스로 조율되어야 한다는 원리 자체는 다른 부서에도 그대로 적용된다.

1. 의존성의 종류부터 구분한다

모든 업무를 같은 무게로 다룰 필요는 없다. 각자 독립적으로 진행하다 결과만 합치는 일이라면 AI로 인한 속도 격차가 크게 문제되지 않는다. 반대로 A의 산출물이 B의 선결 조건이거나, B의 작업에 계속 영향을 주는 상호형 업무라면 여기에만 별도의 조율 장치를 붙여야 한다. 문제를 전사적으로 뭉뚱그리지 말고, 어디가 진짜 취약한 지점인지부터 가려내는 게 먼저다.

2. 결정 권한과 체크포인트를 사전에 명시한다

무엇을 누가 결정하는지, 어느 지점에서 재검토가 이루어지는지를 작업이 시작되기 전에 정해둔다. AI가 산출물을 빠르게 여러 버전 만들어낼 수 있다는 걸 전제로, "이만큼 진행되면 반드시 한 번 맞춰본다"는 지점을 인위적으로라도 박아둔다. 예전에는 이런 지점이 산출물을 만드는 데 걸리는 시간 덕분에 저절로 생겼지만, 이제는 의식적으로 설계해야 생긴다.

3. 검토를 사람의 시간이 아니라 파이프라인 용량의 문제로 본다

리뷰어를 더 갈아 넣는 방식으로는 물량 증가를 따라잡을 수 없다. 형식적인 검사(포맷, 보안 패턴, 알려진 취약점)는 자동화된 계층으로 넘기고, 사람의 판단은 의도와 아키텍처 적합성처럼 진짜 사람이 필요한 부분에만 집중시키는 방향이 현실적이다. 검토를 늘리는 게 아니라, 검토가 다뤄야 할 범위를 좁히는 쪽으로 접근을 바꾸는 것이다. 실제로 이 문제를 오래 관찰해 온 리서치들도, 리뷰를 끝단에 더 쌓는 대신 PR 크기를 통제하고 품질 게이트를 개발 단계 앞쪽으로 당기라고 권한다.

4. 인위적인 동기화 지점을 다시 만든다

예전에는 느림이 자연스럽게 만들어주던 정렬의 순간을, 이제는 일부러 설계해야 한다. 일간 스탠드업이나 주간 회고 같은 형식적인 의식을 늘리라는 말이 아니다. 상호의존이 강한 지점, 즉 A의 결과가 B의 작업 방향을 바꿀 수 있는 지점에 한해서, 산출물이 다음 단계로 넘어가기 전에 반드시 확인하는 좁고 명확한 게이트를 두는 쪽이 효과적이었다.

지금도 이 문제는 진행형이다

AI 코드 리뷰 봇은 여전히 잘 돌아간다. 하지만 봇을 만든 것만으로 이 문제가 풀리지는 않았다. 봇은 속도 격차를 줄여주는 도구이지, 조율 장치 자체는 아니었다. 결국 남는 질문은 도구를 얼마나 잘 만들었느냐가 아니라, 그 도구가 만들어낸 산출물을 누가, 어느 시점에, 어떤 권한으로 확인할 것인가였다.

예전에는 이 문제를 그냥 "일이 많아서 그렇다"고 생각했다. 지금은 조금 다르게 본다. AI 도입으로 생긴 비효율은 도구의 완성도 문제라기보다, 조직이 오랫동안 인간의 속도에 기대어 암묵적으로 굴리던 조율 장치가 걷혀나가면서 생기는 구조적인 비용에 가깝다. 도구를 더 잘 만든다고 저절로 해결되지 않는다. 그 자리를 대신할 장치를 의식적으로 다시 설계해야 한다.

그렇다고 비관할 필요는 없다고 본다. 오히려 최근 데이터는 조율이 잘 갖춰진 조직에서는 AI가 처리량까지 끌어올린다는 걸 보여준다. 문제의 정체를 "속도가 빨라져서"가 아니라 "조율이 사라져서"로 정확히 짚어내는 순간, 대응할 지점도 훨씬 또렷해진다. 어디를 자동화하고 어디에 사람의 체크포인트를 남길지가 명확해지기 때문이다.

그리고 이건 개발조직만 풀어야 할 숙제도 아니다. 산출물의 속도를 관행이 아니라 인터페이스로 조율해야 한다는 원리는 마케팅과 재무, 영업과 법무 사이에도 똑같이 적용된다. 오히려 기술적 인터페이스라는 방어막이 없는 부서일수록 이 설계를 더 서둘러야 할지도 모른다.

짧은 질문들

AI 도입 자체가 문제라는 뜻인가

아니다. AI가 개별 작업의 속도를 끌어올리는 건 분명한 이득이고, 조율이 잘 된 조직에서는 팀 전체 처리량까지 함께 오른다는 데이터도 있다. 문제는 그 속도 격차를 흡수하던 조율 장치를 같이 업데이트하지 않을 때 생긴다.

리뷰어나 검토 인력을 늘리면 해결되나

일시적으로는 도움이 되지만 근본적인 해결책은 아니다. 사람의 검토 속도는 AI의 생성 속도만큼 늘어나지 않기 때문에, 인력을 늘리는 방식은 결국 다시 한계에 부딪힌다. 형식적 검사를 자동화로 넘기고 사람의 판단 범위를 좁히는 쪽이 더 지속 가능하다.

이 문제는 개발팀에만 해당하나

아니다. 코드 리뷰가 가장 눈에 띄는 사례일 뿐, 구조 자체는 상호의존적 업무가 있는 모든 팀에 적용된다. 오히려 최근 조사들을 보면 마케팅, 재무, 법무처럼 기술적 인터페이스로 경계가 보호되지 않는 부서에서 더 크게 나타나는 경향도 있다.

그럼 전통 부서가 개발조직보다 더 취약하다는 뜻인가

경계가 더 쉽게 무너진다는 의미이지, 경계가 원래 더 모호했다는 뜻은 아니다. 개발조직의 경계는 API나 DB 스키마 같은 기술적 인터페이스가 대신 지켜주지만, 전통 부서의 경계는 사람 간 관행과 결재 프로세스로 유지되어 왔다. AI는 그 관행을 손쉽게 우회하게 해주기 때문에, 방어막이 없는 부서일수록 더 쉽게 흔들린다. 게다가 그 결과도 다르다. 개발조직에서는 대개 리뷰 지연으로 끝나지만, 전통 부서에서는 컴플라이언스나 법적 리스크로 번질 수 있다.

참고한 자료

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR, 2025)
• The AI Acceleration Whiplash — AI Engineering Report 2026 (Faros AI)
• AI Productivity Paradox (Faros AI, 2025)
• 2025 DORA Report: State of AI-assisted Software Development (Google Cloud)
• Nutanix Enterprise Cloud Index 2026: Shadow IT and Organizational Silos Create AI Risks
• From AI Hype to Workflow Reality: A Strategic Framework for Integrating Generative AI Across Organizational Functions (ScienceDirect)
• The 20 Biggest AI Governance Statistics and Trends of 2025 (Pacific AI 조사 인용)
• State of AI Trust in 2026 (McKinsey)
• GitHub Copilot is generating more code than your team can review (CIO)
• The Review Bottleneck: Why More AI Code Means Slower Teams in 2026 (dev.to)

The post AI 생산성 역설: 왜 팀은 더 빨라졌는데 더 자주 어긋날까 appeared first on .