AI 시대, 인간은 과연 병목인가

최근 AI 협업에 관한 화두를 접하며, 1년 남짓 전의 실무 경험이 자연스레 떠올랐다. 당시 조직 내에서는 AI를 도입하면 최소한의 노동으로 극대화된 산출물을 얻을 수 있으리라는 장밋빛 기대가 가득했다. 그러나 막상 실무에 부딪혀 보니, 단순히 제작 속도가 단축된다고 해서 모든 업무가 매끄럽게 맞물려 돌아가지는 않았다.

무언가를 신속히 만들어내더라도 결국 누군가의 검토를 거쳐야 했고, 수정 사항이 발생하면 작업은 원점으로 회귀하기 일쑤였다. 하나의 과업이 미처 마무리되기 전에 새로운 과업이 밀려드는 일도 다반사였다. AI 도입이 실질적인 업무 프로세스의 단축이나 유의미한 비용 절감으로 이어졌는지 명확히 가늠하기 어려웠다.

직장생활을 하는 주변 친구들의 토로 역시 비슷하다. 결국 ‘인간이 병목’이라는 자조 섞인 결론이다. 자본주의적 효율성의 잣대로 보자면 타당한 지적일 수 있다. 산출물이 우선시되는 조직은 최소 비용으로 최대 성과를 지향하며, AI가 쏟아낸 결과물을 인간이 검증하느라 지체되는 시간조차 줄여야 할 비용으로 여길 테니 말이다.

하지만 나는 여기서 근본적인 질문을 던져야 한다고 본다. 과연 ‘병목’으로 지목된 인간의 실체는 무엇일까?

생산보다 검증이 지연되는 역설

최근 소프트웨어 개발 생태계를 분석한 Chen과 Stratton의 연구^{¹Chen·Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production, 2026년 10월 28일 작업논문 버전.}는 이 딜레마를 짚어낸다. AI 코딩 에이전트 도입 이후, 도리어 검토 요청부터 최종 승인까지 소요되는 시간이 약 56%나 증가했다는 것이다. 코드 생산량 자체는 늘었을지언정, 검토 대기 시간과 실제 검증 시간이 동반 상승하며 최종 산출물은 그만큼 비례해서 늘어나지 않았다.

이 연구의 인터뷰에 따르면, 특정 코드를 깊이 이해하고 승인할 수 있는 권한을 가진 선임 개발자는 단 한 명뿐이었고, 그마저도 과중한 타 업무로 인해 주 1회 정도만 검토에 참여할 수 있었다고 한다. 표면적으로는 이 검토자가 명백한 병목인 듯하다. 그러나 승인권자가 한정되어 있고 그에게 업무가 편중된 상황이라면, 진단이 필요한 본질은 ‘도구의 속도’가 아니라 ‘업무의 배분’일 것이다.

그렇다고 검토 권한을 기계적으로 분산하는 것만으로 해결될 일도 아니다. 초기 요구사항의 맥락과 과거 의사결정 과정을 온전히 이해하지 못한 이에게 검증을 맡길 수는 없기 때문이다. 시스템의 산출 속도는 비약적으로 높아졌으나 검토 인력의 규모와 역량은 여전히 AI 이전 과거에 머물러 있다면, 이는 구조적 결함에 가깝다고 본다. 경영진이 산출물의 단순 수치만 척도로 삼는다면, 현장의 병목 현상을 납득하기란 영원히 불가능할지도 모르겠다.

생산량의 증가는 곧 성공을 의미할까

반면, He 등의 연구^{²He 외, AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise “2×” Mandate, 2026년 10월 27일 프리프린트 수정본.}는 AI 도입 후 생산 목표를 달성한 이면의 변화를 비추고 있다. 한 기업은 10개월 만에 개발자당 병합된 PR^{³PR(Pull Request). 작성한 코드를 검토받고 공동 코드에 반영하기 위한 요청.} 수를 두 배로 늘리는 데 성공했다. 하지만 이 과정에서 인간이 직접 피드백을 글로 남긴 PR 비율은 39%에서 21%로 급감했고, 그 빈자리는 ‘자동화된 검토’가 채웠다.

이 사례의 핵심은 단순한 생산성 향상이 아니라 ‘검토 방식의 구조적 재편’에 있다. 앞서 언급했듯 조직은 더 적은 인력으로 더 많은 가치를 창출하길 원한다. 하지만 AI로 앞단의 제작량을 늘린 대가로 뒷단의 검토에 더 많은 자원을 투입해야 한다면, 초기 비용 절감의 기대는 어긋날 수밖에 없다. 결국 기존 인력의 검증 방식을 개선해야 하며, 이는 결코 도구의 도입만으로 자생적으로 이루어지지 않을 것이다.

가장 우려스러운 지점은 조직이 사내 직원들에게 AI라는 도구를 쥐여준 것만으로 프로세스가 개선되었다고 착각하는 것이다. 낡은 승인 절차를 고수하면서 실무자에게만 속도전을 강요한다면, 전체 프로젝트의 완료 시점은 앞당겨지기 어렵다고 느껴진다. 중복된 검증 단계를 축소하는 등 ‘무엇을 위해 확인하는가’라는 목적의식을 바탕으로 시스템을 재설계해야 할 것이다.

제안의 문턱이 낮아질수록 검토자의 부담은 늘어난다

병목 현상은 기존 업무뿐 아니라 새로운 제안을 하는 영역에서도 두드러진다. 이제는 AI 활용으로 아이디어를 기획서로 발전시키는 작업이 무척 수월해졌다. 그러나 제안의 문턱이 낮아짐으로써 쏟아지는 방대한 문서량을 ‘누가, 어떻게’ 심도 있게 평가할 것인가는 완전히 다른 차원의 과제다.

중소벤처기업부의 2026년 ‘모두의 창업 프로젝트’ 사례에서도 참여의 문턱과 검토의 역량 사이의 간극을 살펴볼 수 있다.^{⁴중소벤처기업부, 6.2만 명의 열기, 도전부터 재도전까지 「모두의 창업」이 혁신의 길을 이끈다, 2026년 5월 22일. 1차 지원자 62,944명 및 선발 계획. 실제 5000명 선발은 1기 출범식 공식 자료, 2026년 6월 17일.} 6만 명이 넘는 지원자가 몰렸으나, 초반에는 아이디어 한 건당 멘토 한 명이 교차 검증 없이 심사를 맡았고, 일부 지원자들은 자신의 지원서와 동떨어진 평가를 받았다며 문제를 제기했다.^{⁵김세연, 6만명 넘게 지원했는데…심사위원 규모도 모르는 ‘깜깜이 심사’, 이데일리, 2026년 6월 11일; ‘깜깜이 심사 논란’ 중기부 창업프로젝트…다면평가·AI검증 도입한다, 2026년 6월 16일. 지원자 항의와 심사체계, 후속 보완에 관한 직접 취재.} 결국 정부는 3인 공동 심사와 최소 글자 수 피드백을 도입하는 등 시스템을 뒤늦게 보완해야만 했다.

AI로 가속화된 모방, 원작자가 짊어진 새로운 짐

창작의 최전선이라 볼 수 있는 인디 게임 생태계에서는 이러한 문제가 생존과도 직결되고 있다. 누군가의 고유한 아이디어를 AI로 손쉽게 복제해 먼저 상용화하려는 시도가 현실화되고 있는 것이다.

국내 개발팀 YNOT이 모방작 출시 우려로 ‘스푸키친’의 공개 데모를 중단한 일이나^{⁶윤서호, ‘AI 카피캣’ 우려에 국내 인디 스푸키친 데모 닫았다, 인벤, 2026년 10월 20일. 개발자 발표 등을 다룬 보도.}, 복제작 선출시를 빌미로 개발자에게 금전을 요구한 사건^{⁷稲川ゆき, 일본 인디 SRPG 개발자에게도 도착한 AI 복제작 선출시 협박 메일, Game*Spark, 2026년 10월 19일. 개발자가 공개한 이메일과 반응에 관한 보도.}, 모방 이슈 때문에 비공개 테스트로 전환한 Alliance Arts의 결정 등은 시사하는 바가 크다.^{⁸Alliance Arts, Change to the Demo Release Plan for Drunken Goddess Reflux, 2026년 10월 16일. 공개 데모 취소와 비공개 테스트 전환에 관한 공식 공지.}

이런 우려에 대해 스팀을 운영하는 밸브 측 입장은 어떨까. 밸브 측은 개발자 행사에서 복제 게임은 이전부터 존재했지만 AI가 그 제작 속도를 높였다고 설명했다. 협박 사례를 신고하면 가능한 도움을 주겠다고도 했지만, 복제에 대한 대응 방향으로는 개발사가 이용자와의 관계를 쌓고 원작을 지속적으로 개선하는 방안을 제안했다.^{⁹Doohyun Lee, Developers Fear AI Slop and Clones — Valve Answers Directly, Inven Global, 2026년 10월 27일. ‘Steam Indie Connect’ 현장 취재.} 인력과 시간이 부족한 소규모 개발팀에 추가적인 운영과 개발 부담을 해법으로 제시한다는 점에서, 내게는 상당히 무책임한 답변처럼 들린다.

이 사태의 맹점은 정작 창작에 매진해야 할 원작자가 모방 여부를 직접 감시하고, 자신의 독창성을 증명하며, 커뮤니티 방어에 귀중한 시간을 쏟아야 한다는 데 있다. 나 또한 과거 한 포럼에 공개했던 데모 아이디어가 몇 달 뒤 유사한 형태로 구현된 것을 목도한 바 있기에, 이러한 우려가 결코 가볍게 여겨지지 않는다. AI가 제작에 소요되는 절대적 시간은 단축했을지언정, 권리 보호와 리스크 대응이라는 거대한 후행 비용을 창작자에게 전가하고 있는 셈이다.

파편화된 업무 맥락

이러한 거시적 현상들을 살피다 보면, 다시 나의 실무 경험으로 돌아오게 된다.

과거 주 단위 마감이라는 빡빡한 일정 속에서 지속된 피드백 반영으로 마감이 지연되면 결국 다음 주의 새로운 과업과 기존 작업을 병렬로 처리해야 하는 압박에 시달렸다. 전혀 다른 캐릭터와 화풍을 요구하는 작업들을 한 번에 관리하는 일은 상당한 피로를 동반했다. 서로 다른 프롬프트와 맥락을 단일 시스템 내에서 온전히 유지하기 어려워, 개인 계정을 동원하는 임시방편을 택해야 했고, 이는 결국 작업 기록 파편화라는 또 다른 부작용을 낳기도 했다.

이것이 지금으로부터 1년도 더 지난 일이라는 점에서 이제 시간이 흘러 도구의 성능은 비약적으로 발전했겠지만, 앞의 업무가 마무리되기도 전에 새 과업을 떠안아야 하는 부담은 도구의 발전만으로 해결되지 않는다. 이는 작업자의 기술 숙련도 문제가 아니라, 조직의 일정 관리와 인력 배분에 기인한 구조적 한계이기 때문이다. AI가 동시다발적인 작업을 가능케 한다고 해서, 인간 개인의 인지적 통제력까지 무한정 확장되는 것은 아니다.

우리를 ‘병목’이라 부르기 전에

이 모든 엇박자를 섣불리 인간이 만든 시스템의 결함으로만 치부할 수는 없다. 모든 검토 대기 시간을 불필요한 지연으로 매도하는 것 역시 위험하다. 다수의 프로젝트를 통솔하는 관리·검토자에게는 조직 전체의 관점에서 조율해야 할 엄연한 우선순위가 존재하기 때문이다.

핵심은 정교한 기준 수립일 것이다. 병목을 해소하려면 승인 단계를 어디까지 축소할 것인지, 지연된 수정 작업과 신규 과업의 일정은 어떻게 재조정할 것인지 명확한 합의가 선행되어야 한다. 이 기준이 부재한 채 속도전만 강요한다면, 작업자는 새 과업을 쳐내고 검토자는 승인 대기 목록에 쌓인 업무를 쫓는 악순환이 반복될 뿐이다.

조직은 앞으로도 더 빠르고 저렴한 효율을 바랄 것이다. AI가 앞단의 생산을 가속했으니, 뒷단의 검증 역시 가속하길 요구하는 것은 어쩌면 자연스러운 수순이다. 인간을 향한 ‘병목’이라는 꼬리표도 결국 그러한 효율성 추구에서 비롯되었으리라 본다.

하지만 묻고 싶다. 낡은 절차를 개선하여 마침내 검토 속도까지 비약적으로 빨라진다면, 우리는 온전한 여유를 누리게 될까? 아니면 그저 ‘더 많은 과업을 구겨 넣을 수 있는 고성능 부품’으로 재위치될 뿐일까. 처리 능력이 향상될 때마다 조직의 요구치도 끝없이 상향 조정된다면, 인간은 계속해서 시스템의 병목으로 지목될 수 있다.