칼럼 | AI 생산성의 함정, 최고의 엔지니어가 오히려 느려지는 이유

이제는 누구나 한 번쯤 들어본 이야기다. 거의 모든 기술 콘퍼런스에서 배경음처럼 반복된다. AI 코딩은 이미 해결됐고, 대규모 언어 모델이 곧 전체 코드의 80%를 작성하게 될 것이며, 인간 엔지니어는 결과물을 감독하는 역할만 남게 될 것이라는 주장이다.

CIO의 관점에서 이런 서사는 상당히 매력적으로 들린다. 소프트웨어 개발 비용을 대폭 낮추는 동시에 엔지니어링 속도를 끌어올릴 수 있을 것처럼 보이기 때문이다. 코드 작성이라는 병목이 곧 사라질 것이라는 기대도 담겨 있다.

하지만 필자는 미션 크리티컬 금융 인프라와 자율 에이전트 플랫폼을 구축하는 일을 매일같이 해오고 있는 입장에서, 다소 불편한 소식을 전해야 한다. 현실은 그렇게 흘러가고 있지 않다. 최소한 최고의 엔지니어에게는 그렇다.

숙련 엔지니어의 업무 흐름에 AI 코파일럿을 도입해도, 브로슈어에서 약속한 것처럼 마찰 없는 가속 효과는 나타나지 않고 있다. 오히려 가장 가치 있는 기술 인재에게 불균형적으로 부담을 주는 ‘생산성의 함정’이 모습을 드러내고 있다. 이는 속도에 부과되는 숨겨진 비용이자, 눈에 잘 띄지 않는 세금과도 같다.

이런 문제 제기는 기술 자체에 대한 회의에서 나온 것이 아니다. 필자는 AI에 대해 낙관적인 입장을 가지고 있으며, AI 시스템을 개발하며 일하고 있다. 다만 데이터에 대해서는 솔직해야 한다. 복잡하고 실패 비용이 큰 엔지니어링 과제에서, 현재의 AI 도구는 숙련 개발자의 속도를 높이지 못하고 있다. 오히려 더 느리게 만들고 있는 것이 현실이다.

속도에 숨겨진 보이지 않는 비용

생성형 AI 붐이 시작된 초기 몇 년 동안 업계는 사실상 ‘분위기’에 기대 움직여 왔다. 생산성이 크게 향상됐다는 일화와 벤더가 후원한 연구 결과가 이를 뒷받침했다. 단순한 작업을 맡은 주니어 개발자에게는 이런 효과가 실제로 존재했다. 로그인 버튼을 위한 기본적인 리액트 컴포넌트가 필요하다면, AI를 활용하는 경험은 기적처럼 느껴질 수 있다.

그러나 2025년 중반, 상황을 다시 보게 만드는 계기가 찾아왔다. 모델 평가 및 위협 연구(METR)가 진행한 무작위 대조 실험은 시니어 엔지니어를 대상으로 AI 도구의 영향을 분석했다. 장난감 수준의 문제를 사용한 기존 연구와 달리, 이 실험은 숙련 개발자가 실제로 관리하고 있는 성숙한 코드베이스에서 작업하는 과정을 관찰했다. 즉, 기업 비즈니스를 실제로 떠받치고 있는 복잡하고 난해한 레거시 시스템을 분석 대상으로 삼았다.

결과는 분명했다. 숙련 개발자가 실제 유지보수 작업을 수행할 때 AI 도구를 사용하면, 사용하지 않았을 때보다 작업 시간이 평균 19% 더 길어졌다.

코드를 즉시 생성하는 도구가 어떻게 전체적으로는 시간 손실로 이어질 수 있을까.

그 이유는 필자가 ‘속도의 착각’이라고 부르는 현상에 있다. 연구에 참여한 개발자들은 자신이 더 빠르게 일하고 있다고 느꼈다. AI가 막대한 시간을 절약해 줄 것이라고 예상했다. 작업을 마친 뒤에도, 객관적인 기록상으로는 더 느렸음에도 불구하고 AI가 시간을 아껴줬다고 믿었다.

AI는 도파민을 자극한다. 초인적인 속도로 텍스트가 화면에 나타나고, 빈 페이지에서 시작해야 하는 부담이 사라진다. 하지만 이 과정에서 엔지니어의 역할은 창작자에서 검토자로 바뀌며, 바로 그 지점에서 생산성의 함정이 작동하기 시작한다.

‘거의 맞는 코드’의 죽음의 계곡

문제의 핵심은 AI가 ‘거의 맞는’ 결과를 만들어내는 데 매우 능숙하다는 점이다.

2025년 스택 오버플로 개발자 설문조사에 따르면, 개발자가 꼽은 가장 큰 불만은 겉보기에는 올바른 것처럼 보이지만 미묘하게 틀린 AI 해법을 다루는 일이었다. 응답자의 거의 절반은 AI가 생성한 코드를 디버깅하는 데 직접 코드를 작성하는 것보다 더 많은 시간이 든다고 분명히 밝혔다.

소프트웨어 엔지니어링에서 완전히 깨진 코드는 오히려 문제가 되지 않는다. 컴파일러가 즉시 오류를 내고, 애플리케이션은 실행과 동시에 중단되며, 편집기에는 빨간 밑줄이 나타난다. 잘못됐다는 사실을 바로 인지할 수 있다.

반면 ‘거의 맞는’ 코드는 훨씬 교묘하다. 컴파일도 되고 실행도 되며, 기본적인 유닛 테스트까지 통과한다. 그러나 즉시 드러나지 않는 미세한 논리 오류나 엣지 케이스 실패를 품고 있다.

코드를 처음부터 직접 작성할 때 필자는 순방향 엔지니어링을 수행한다. 논리 구조에 대한 정신적 모델을 세우고, 모든 변수가 왜 존재하는지 알고 있다. 버그가 발생하면 자신의 사고 과정을 되짚으며 오류 지점을 추적할 수 있다.

하지만 AI를 사용할 경우, 상황은 역방향 엔지니어링으로 바뀐다. 스스로 작성하지 않은 코드 덩어리를 받아들고, 모델의 의도를 해석한 뒤 이를 시스템 요구사항과 대조해야 한다.

기업 물류를 위한 금융 시스템을 구축하던 과정에서 필자는 이 문제를 직접 경험했다. 순매출을 계산하는 로직에는 맞춤형 비즈니스 규칙이 다수 포함돼 있었고, 그 복잡도도 상당했다. 대규모 언어 모델에 청구 코드를 생성해 달라고 하면, 수학적으로는 완벽해 보이는 결과를 내놓았다. 항목 합계 역시 정확하게 계산했다.

그러나 언제나 중요한, 명시되지 않은 맥락 하나를 놓쳤다. 예를 들어, 공차 운임은 특정 전용 프로그램에 참여한 운송사에 한해서만 다른 요율이 적용된다는 조건 같은 것이다. 이런 누락을 100줄에 달하는 AI 생성 코드 속에서 찾아내는 일은, 처음부터 100줄을 직접 작성하는 것보다 훨씬 어렵다. 결국 필자는 일을 직접 처리하는 대신, 그럴듯해 보이는 AI의 환각을 하나하나 반박하는 데 더 많은 시간을 쓰게 됐다.

컨텍스트 붕괴와 몰입 상태

여기에는 컨텍스트 전환에 따른 비용도 존재한다. 깊은 몰입 상태, 이른바 플로우는 고급 엔지니어링의 핵심이다. 분산 시스템의 맥락을 머릿속에 불러오는 데에는 상당한 시간이 필요하다.

하지만 현재의 채팅 기반 AI 도구는 업무 흐름을 잘게 쪼개는 방향으로 작동한다. 코딩을 멈추고, 봇에 프롬프트를 입력하고, 기다렸다가 결과를 검토하고, 거절한 뒤 다시 요청한다. 이 과정에서 몰입은 완전히 사라진다.

더 큰 문제는 AI의 오류를 바로잡기 위해 더 많은 코드 조각을 입력할수록 드러난다. 이른바 컨텍스트 붕괴가 발생한다. 모델은 중요하지 않은 세부사항에 주의를 빼앗기고, 점점 비대해지면서도 엇나간 코드를 만들어내기 시작한다. 결국 시니어 엔지니어는 회사의 역사도 이해하지 못하는, 매우 빠르고 자신감 넘치는 인턴의 편집자 역할을 하게 된다.

전략을 다시 짜야 할 때

그렇다면 현재의 코파일럿 모델이 최고의 인재에게 함정이라면, 우리는 무엇을 해야 할까. 해법은 AI를 금지하는 것이 아니다. 가끔 잘못된 버튼을 누른다고 계산기를 금지하지 않는 것과 같은 이치다.

필요한 것은 AI 보조 코딩에서 AI 기반 아키텍처로의 전환이다. 목표는 시니어 엔지니어가 더 빠르게 타이핑하도록 만드는 것이 아니라, AI가 생성한 코드의 혼란을 감당할 수 있을 만큼 견고한 시스템을 구축하도록 돕는 데 있다.

검토자에서 설계자로

흔히 언급되는 80대 20 비율, 즉 AI가 80%를 맡고 인간이 20%를 담당한다는 구분은 오해를 낳는다. 이는 인간의 역할이 단순한 마무리 단계에 불과하다는 인상을 준다. 하지만 실제로 그 20%가 가치의 전부다. 아키텍처, 보안 모델, 비즈니스 로직이 모두 여기에 포함된다.

생산성의 함정에서 벗어나려면, 엔지니어링 리더의 초점을 전적으로 이 인간의 20%에 맞춰야 한다.

필자의 업무 역시 기능 구현에서 코드베이스의 ‘물리 법칙’을 정의하는 방향으로 옮겨가고 있다. 우버에 재직하던 시절, 시스템 전반을 엄격한 타입과 스키마 기반으로 마이그레이션하는 데 막대한 시간을 투입했다.

엄격한 규칙을 강제함으로써 사실상 가드레일 시스템을 구축한 셈이다. 이 환경에서 AI를 활용하면, 모델은 규칙을 준수하는 코드만 작성할 수밖에 없다. 존재하지 않는 필드를 환각으로 만들어내면, 컴파일러가 즉시 이를 거부한다.

이것이 전략적 전환의 핵심이다. 시니어 엔지니어의 역할은 AI를 위한 컴파일러를 만드는 것이다. AI의 행동 범위를 제약하는 스키마, 타입 시스템, 자동화된 규칙을 설계해야 한다.

이 접근법은 ‘거의 맞는’ 문제의 성격을 바꾼다. 사람이 일일이 코드를 검토해 오류를 찾는 대신, 아키텍처에 맞지 않는 코드는 시스템이 자동으로 거부한다. 검토자가 아니라 규칙을 제정하는 입법자의 역할로 전환되는 것이다.

변화를 이끄는 방법

CIO의 입장에서 이는 관리 전략의 전환을 요구한다. 단순히 커서 같은 도구의 구독을 구매한다고 해서 속도나 안정성 지표가 자동으로 개선되지는 않는다.

우선 산출물 중심의 측정을 중단해야 한다. 지금 가장 위험한 선택은 생산성을 코드 라인 수(LOC)나 하루 커밋 수로 평가하는 것이다. AI 환경에서는 이런 지표가 얼마든지 조작될 수 있으며, 실제 가치와는 완전히 분리돼 있다.

대신 결과를 측정해야 한다. 시니어 엔지니어가 한 달 동안 코드를 한 줄도 작성하지 않았더라도, 특정 유형의 운영 환경 버그를 100% 차단하는 스키마를 설계했다면 이는 매우 큰 성과다. 단순히 일을 ‘완료한 것’이 아니라, 애초에 일을 발생시키지 않도록 한 성과를 보상해야 한다.

둘째, 컨텍스트 엔진에 투자해야 한다. AI는 맥락이 부족할수록 한계를 드러낸다. 시니어 엔지니어에게 내부 개발자 플랫폼을 구축하도록 맡겨, 코드베이스를 구조화된 형태로 노출해야 한다. 정돈돼 있고 엄격한 타입을 적용한 코드베이스는 효과적인 AI 도입을 위한 필수 조건이다.

마지막으로, 시니어 엔지니어에게 기대하는 역량을 재정의해야 한다. 문법을 잘 아는 능력의 가치는 빠르게 하락하고 있는 반면, 시스템을 검증하는 역량의 가치는 급격히 높아지고 있다.

스키마, 타입 안정성, 아키텍처를 중심으로 사고하는 엔지니어가 필요하다. AI와 대화를 잘하는 사람이 아니라, AI의 행동을 제약하는 가드레일을 설계할 수 있는 인재를 찾아야 한다.

AI 생산성의 함정은 분명 존재하지만, 피할 수 없는 운명은 아니다. 이는 새로운 기술을 낡은 업무 방식에 그대로 적용한 결과일 뿐이다. 앞으로 나아갈 길은 엄격하고, 아키텍처 중심이며, 본질적으로 인간적이다. 설계와 제약 설정을 엔지니어링의 진정한 핵심으로 다시 평가해야 할 시점이다.
dl-ciokorea@foundryco.com