AI와 자동화에 대한 과도한 의존이 엔지니어링 팀에 초래하는 숨겨진 비용인 이해 부채와, 코드 이해 부족이 품질·검토·책임성에 미치는 영향을 살펴봅니다.
HomeGitHubPressBiographyLinkedInTwitterNewsletterBlog
이해 부채는 AI와 자동화에 대한 과도한 의존으로 인해 인간의 지능과 기억에 발생하는 숨겨진 비용입니다. 엔지니어에게는 특히 에이전틱 엔지니어링에 가장 크게 적용됩니다.
팀이 AI 코딩 도구에 깊이 의존할 때, 속도 지표에는 드러나지 않는 비용이 있습니다. 특히 AI가 생성한 코드를 모두 검토하는 일이 고될 때 더욱 그렇습니다. 이 비용은 꾸준히 쌓이고, 결국에는 이자까지 붙어 반드시 치러야 합니다. 이것이 바로 이해 부채, 또는 인지 부채입니다.
이해 부채란 시스템에 존재하는 코드의 양과 어떤 인간이든 그것을 진정으로 이해하는 정도 사이에 점점 벌어지는 격차를 말합니다.
기술 부채는 점점 커지는 마찰을 통해 자신을 드러냅니다. 느려지는 빌드, 얽힌 의존성, 그 특정 모듈을 건드릴 때마다 스며드는 불안감처럼 말입니다. 반면 이해 부채는 잘못된 자신감을 키웁니다. 코드베이스는 깔끔해 보입니다. 테스트는 모두 통과합니다. 하지만 대가는 조용히 찾아오고, 대개는 가장 최악의 순간에 모습을 드러냅니다.
Margaret-Anne Storey는 한 학생 팀이 7주 차에 이 벽에 부딪힌 사례를 설명합니다. 그들은 더 이상 예상치 못한 무언가를 깨뜨리지 않고는 간단한 변경조차 할 수 없었습니다. 진짜 문제는 지저분한 코드가 아니었습니다. 팀 안의 누구도 왜 그런 설계 결정이 내려졌는지, 시스템의 서로 다른 부분이 어떻게 함께 작동하도록 되어 있는지 설명할 수 없었다는 점이었습니다. 시스템에 대한 이론이 증발해 버린 것입니다.
이것이 바로 실시간으로 복리처럼 불어나는 이해 부채입니다.
저는 Hacker News 스레드들에서 엔지니어들이 이 문제의 구조적 버전과 진지하게 씨름하는 모습을 읽었습니다. 익숙한 낙관론 대 회의론의 이분법이 아니라, 병목이 이동한 상황에서 엄밀함이 실제로 어떤 모습이어야 하는지를 한 분야 전체가 파악하려 애쓰는 모습이었습니다.
최근 Anthropic의 연구인 “How AI Impacts Skill Formation”은 AI 코딩 어시스턴트에 과도하게 의존할 때의 잠재적 단점을 강조했습니다. 새로운 라이브러리를 학습하는 52명의 소프트웨어 엔지니어를 대상으로 한 무작위 대조 실험에서, AI 지원을 사용한 참가자들은 대조군과 거의 비슷한 시간 안에 과제를 완료했지만 후속 이해도 퀴즈에서는 17% 더 낮은 점수(50% 대 67%)를 기록했습니다. 가장 큰 하락은 디버깅에서 나타났고, 개념 이해와 코드 읽기에서도 더 작지만 여전히 유의미한 하락이 있었습니다. 연구진은 수동적 위임(“그냥 돌아가게만 해”)이 적극적이고 질문 중심적인 AI 활용보다 기술 발달을 훨씬 더 크게 저해한다고 강조합니다. 전체 논문은 arXiv에서 확인할 수 있습니다: https://arxiv.org/abs/2601.20245.
AI는 인간이 평가할 수 있는 속도보다 훨씬 빠르게 코드를 생성합니다. 당연하게 들리지만, 그 함의를 과소평가하기 쉽습니다.
팀의 개발자가 코드를 작성할 때 인간의 리뷰 과정은 언제나 병목이었지만, 동시에 생산적이고 교육적인 병목이기도 했습니다. 그들의 PR을 읽는 일은 이해를 강제합니다. 그것은 숨은 가정을 드러내고, 6개월 전 시스템이 설계된 방식과 충돌하는 설계 결정을 잡아내며, 코드베이스가 실제로 무엇을 하는지에 대한 지식을 유지보수 책임이 있는 사람들 사이에 분산시킵니다.
AI가 생성한 코드는 이 피드백 루프를 깨뜨립니다. 양이 너무 많습니다. 출력은 문법적으로 깔끔하고, 종종 형식도 잘 맞고, 겉보기에는 올바릅니다. 바로 역사적으로 머지에 대한 확신을 유발하던 신호들입니다. 그러나 표면적 정합성이 시스템적 정합성을 뜻하지는 않습니다. 코드베이스는 건강해 보이지만, 그 아래에서는 이해가 조용히 속이 비어 갑니다.
저는 어떤 엔지니어가 병목은 언제나 유능한 개발자가 프로젝트를 이해하는 데 있었다고 말하는 것을 읽었습니다. AI는 그 제약을 바꾸지 않습니다. 그저 그것을 벗어났다는 착각을 만들어낼 뿐입니다.
그리고 그 역전은 보기보다 더 날카롭습니다. 코드 생산 비용이 높았을 때는 시니어 엔지니어가 주니어 엔지니어가 작성하는 속도보다 더 빠르게 리뷰할 수 있었습니다. AI는 이것을 뒤집습니다. 이제 주니어 엔지니어는 시니어 엔지니어가 비판적으로 감사할 수 있는 속도보다 더 빠르게 코드를 생성할 수 있습니다. 리뷰를 의미 있게 만들던 속도 제한 요인이 사라진 것입니다. 예전에는 품질 게이트였던 것이 이제는 처리량 문제가 되었습니다.
결정론적 검증에 더 강하게 기대려는 본능, 즉 단위 테스트, 통합 테스트, 정적 분석, 린터, 포매터에 더 의존하려는 태도는 이해할 수 있습니다. 저도 AI 코딩 에이전트에 크게 의존하는 프로젝트에서 이런 방식을 자주 씁니다. 리뷰 병목에서 자동화로 빠져나오자는 것입니다. 기계가 기계를 검사하게 하자는 것이죠.
이것은 도움이 됩니다. 하지만 분명한 한계가 있습니다.
모든 관찰 가능한 동작을 포괄할 수 있는 테스트 스위트는 많은 경우 그것이 검증하는 코드보다 더 복잡할 것입니다. 하지만 스스로 추론할 수 없는 복잡성은 안전을 제공하지 않습니다. 그리고 그 아래에는 더 근본적인 문제가 있습니다. 명세해야 한다는 생각조차 하지 못한 동작에 대해서는 테스트를 작성할 수 없습니다.
아무도 드래그된 항목이 완전히 투명해지면 안 된다는 테스트를 쓰지 않습니다. 물론 그렇습니다. 그런 가능성 자체를 떠올리지 못했기 때문입니다. 바로 그런 종류의 실패가 빠져나갑니다. 테스트 스위트가 형편없이 작성되었기 때문이 아니라, 아무도 그 지점을 보려 하지 않았기 때문입니다.
여기서 이름 붙일 가치가 있는 특정 실패 모드도 있습니다. AI가 구현 동작을 바꾸고 새로운 동작에 맞춰 수백 개의 테스트 케이스를 업데이트할 때, 질문은 “이 코드가 올바른가?”에서 “그 모든 테스트 변경이 정말 필요했는가, 그리고 내가 미처 생각하지 못한 것을 잡아낼 만큼 충분한 커버리지가 있는가?”로 바뀝니다. 테스트는 그 질문에 답할 수 없습니다. 오직 이해만이 답할 수 있습니다.
데이터도 점점 이를 뒷받침하기 시작했습니다. 연구에 따르면, 코드 생성 위임을 위해 AI를 사용하는 개발자는 이해도 테스트에서 40% 이하의 점수를 받는 반면, 질문을 던지고 트레이드오프를 탐색하는 식의 개념적 탐구를 위해 AI를 사용하는 개발자는 65% 이상의 점수를 받습니다. 도구가 이해를 파괴하는 것은 아닙니다. 문제는 그것을 어떻게 사용하느냐입니다.
테스트는 필요합니다. 하지만 충분하지는 않습니다.
자주 제안되는 해결책이 있습니다. 먼저 자세한 자연어 명세를 작성하라는 것입니다. 그것을 PR에 포함합니다. 코드를 리뷰하지 말고 명세를 리뷰합니다. 그리고 AI가 의도를 충실하게 구현으로 번역했다고 믿는 것입니다.
이 생각은 한때 폭포수 방법론이 매력적으로 보였던 것과 같은 방식으로 매력적입니다. 먼저 문제를 엄밀하게 정의하고, 그다음 실행하는 것입니다. 관심사의 깔끔한 분리입니다.
문제는 명세를 동작하는 코드로 번역하는 과정에는 엄청나게 많은 암묵적 결정이 들어간다는 점입니다. 엣지 케이스, 데이터 구조, 오류 처리, 성능 트레이드오프, 상호작용 패턴 등은 어떤 명세도 완전히 포착하지 못합니다. 같은 명세를 구현하는 두 명의 엔지니어는 관찰 가능한 동작에서 수많은 차이를 보이는 시스템을 만들어낼 것입니다. 어느 쪽 구현도 틀린 것은 아닙니다. 그저 다를 뿐입니다. 그리고 그 차이들 중 많은 것은 결국 아무도 예상하지 못한 방식으로 사용자에게 중요해집니다.
자세한 명세와 관련해 짚고 넘어갈 또 다른 가능성도 있습니다. 프로그램을 완전히 설명할 만큼 충분히 자세한 명세는 거의 프로그램 그 자체이며, 단지 실행 불가능한 언어로 쓰였을 뿐입니다. 리뷰를 대체할 만큼 철저한 명세를 작성하는 조직적 비용은, 그것을 실행하는 데 AI를 사용함으로써 얻는 생산성 향상을 충분히 초과할 수 있습니다. 그리고 여전히 실제로 무엇이 만들어졌는지는 리뷰하지 않은 상태입니다.
더 깊은 문제는 흔히 올바른 명세라는 것이 존재하지 않는다는 점입니다. 요구사항은 만드는 과정에서 드러납니다. 엣지 케이스는 사용을 통해 모습을 드러냅니다. 사소하지 않은 시스템을 만들기 전에 그것을 완전히 명세할 수 있다는 가정은 반복적으로 시험되었고, 번번이 기대에 못 미쳤습니다. AI는 이것을 바꾸지 않습니다. 다만 인간의 숙고 없이 내려지는 새로운 암묵적 결정의 층을 추가할 뿐입니다.
맥락과 의사소통 대역폭이 서로 다른 분산 팀들 사이에서 소프트웨어 품질을 관리해 온 수십 년의 경험은 실제로 검증된 실천을 만들어냈습니다. 팀원이 이제 모델이 되었다고 해서 그런 것들이 사라지지는 않습니다.
AI로 인해 바뀌는 것은 비용(극적으로 낮아짐), 속도(극적으로 빨라짐), 대인 관리 오버헤드(사실상 0)입니다. 바뀌지 않는 것은 코드베이스가 실제로 무엇을 하고 왜 그렇게 하는지에 대한 일관된 이해를 유지하기 위해 깊은 시스템 맥락을 가진 누군가가 필요하다는 사실입니다.
이것이 이해 부채가 강요하는 불편한 재분배입니다.
AI가 만들어내는 양이 늘어날수록, 시스템을 진정으로 이해하는 엔지니어의 가치는 줄어드는 것이 아니라 오히려 커집니다. diff를 보고 즉시 어떤 동작이 핵심 하중을 떠받치고 있는지 아는 능력. 8개월 전 압박 속에서 왜 그런 아키텍처 결정이 내려졌는지 기억하는 능력 말입니다.
안전한 리팩터링과 사용자가 의존하는 무언가를 조용히 바꾸고 있는 리팩터링을 구별할 수 있는 능력. 그 기술은 전체 시스템이 의존하는 희소 자원이 됩니다.
이해 부채가 그토록 위험한 이유는 현재의 어떤 측정 체계도 그것을 포착하지 못하기 때문입니다.
속도 지표는 흠잡을 데 없어 보입니다. DORA 지표는 안정적으로 유지됩니다. PR 수는 늘어납니다. 코드 커버리지는 초록색입니다.
성과 보정 위원회는 속도 향상을 봅니다. 하지만 이해의 결손은 볼 수 없습니다. 조직이 산출물을 측정하는 방식의 어떤 인공물도 그 차원을 포착하지 못하기 때문입니다. 인센티브 구조는 자신이 측정하는 것에 대해 올바르게 최적화됩니다. 문제는 이제 그 측정치가 중요한 것을 더 이상 담아내지 못한다는 점입니다.
이것이 이해 부채를 기술 부채보다 더 음험하게 만드는 이유입니다. 기술 부채는 보통 의식적인 트레이드오프입니다. 지름길을 택한 것도 알고, 대략 어디에 있는지도 알고, 상환 일정을 잡을 수도 있습니다. 반면 이해 부채는 보이지 않게 축적되며, 대개 누구도 의도적으로 그렇게 두기로 결정하지 않았는데도 쌓입니다. 코드는 멀쩡해 보였고 테스트도 통과했고 대기 중인 다른 PR도 있었던, 그런 수백 번의 리뷰가 합쳐진 결과입니다.
리뷰된 코드는 이해된 코드라는 조직적 가정은 더 이상 성립하지 않습니다. 엔지니어들은 자신이 완전히 이해하지 못한 코드를 승인했고, 그 승인에는 이제 암묵적 보증이 실려 있습니다. 아무도 눈치채지 못한 사이 책임이 분산된 것입니다.
너무 빠르게 움직인 모든 산업은 결국 규제를 끌어들였습니다. 기술 업계는 예외적으로 그 역학에서 비교적 보호받아 왔습니다. 부분적으로는 소프트웨어 실패가 종종 복구 가능했고, 부분적으로는 업계가 규제 당국이 따라올 수 있는 속도보다 더 빨리 움직여 왔기 때문입니다.
그 창이 닫히고 있습니다. AI가 생성한 코드가 의료 시스템, 금융 인프라, 정부 서비스에서 돌아가고 있을 때, 생명이나 막대한 자산이 걸린 사고 이후 보고서에서 “AI가 썼고 우리는 완전히 검토하지 못했다”는 말은 통하지 않을 것입니다.
지금 이해의 규율을 구축하는 팀, 즉 단지 테스트 통과가 아니라 진정한 이해를 협상 불가능한 기준으로 다루는 팀은, 순수하게 머지 속도만 최적화한 팀보다 그런 순간이 왔을 때 훨씬 더 유리한 위치에 있을 것입니다.
지금 올바른 질문은 “어떻게 하면 더 많은 코드를 생성할 수 있을까?”가 아닙니다. “우리가 배포하는 것 중 더 많은 부분을 어떻게 실제로 이해할 수 있을까?”입니다. 그래야 사용자가 일관되게 높은 품질의 경험을 얻도록 보장할 수 있습니다.
이러한 재구성은 실질적인 결과를 낳습니다. 이는 변경 사항이 작성되기 전에 그것이 무엇을 해야 하는지에 대해 가차 없을 정도로 명시적이어야 한다는 뜻입니다. 검증을 사후 생각이 아니라 구조적 제약으로 다뤄야 한다는 뜻입니다. 줄 단위가 아니라 아키텍처 규모에서 AI의 실수를 잡아낼 수 있게 해주는 시스템 수준의 정신 모델을 유지해야 한다는 뜻입니다. 그리고 “테스트가 통과했다”와 “이것이 무엇을 하고 왜 그렇게 하는지 이해한다” 사이의 차이에 대해 솔직해야 한다는 뜻입니다.
코드를 싸게 생성할 수 있게 되었다고 해서 이해를 건너뛰는 비용까지 싸지는 것은 아닙니다. 이해하는 일이 곧 일 그 자체입니다.
AI는 번역을 담당합니다. 하지만 여전히 누군가는 무엇이 만들어졌는지, 왜 그런 방식으로 만들어졌는지, 그리고 그 암묵적 결정들이 올바른 것이었는지 이해해야 합니다. 그렇지 않으면 결국 전액 청구될 비용을 그저 뒤로 미루고 있을 뿐입니다.
이해에 대한 대가는 결국 언젠가 치르게 됩니다. 그 부채에는 이자가 빠르게 붙습니다.
Addy Osmani는 Google Cloud와 Gemini를 담당하는 Google의 소프트웨어 엔지니어입니다.TweetBlueskyMastodonThreadsLinkedInShare
더 보고 싶으신가요? 제 무료 뉴스레터를 구독하세요:
