이해 부채(Comprehension Debt) - AI가 생성한 코드에 숨겨진 비용

https://addyosmani.com/blog/comprehension-debt/

이해 부채(Comprehension debt)는 AI와 자동화에 과도하게 의존하면서 인간의 지능과 기억에 발생하는 숨겨진 비용입니다. 엔지니어에게는 특히 에이전틱 엔지니어링(agentic engineering)에 가장 크게 해당합니다.

팀이 AI 코딩 도구를 깊게 활용할수록, 특히 AI가 생성한 모든 코드를 검토하는 일이 지루해질수록, 속도 지표에는 잘 드러나지 않는 비용이 생깁니다. 이 비용은 서서히 쌓이다가 결국에는 이자를 붙여서라도 언젠가는 갚아야 합니다. 이를 이해 부채(Comprehension debt) 혹은 인지 부채(cognitive debt)라고 부릅니다.

이해 부채(Comprehension debt)는 시스템 안에 존재하는 코드의 양과 그 코드들에 대해 얼마나 사람이 이해하고 있는지 사이에 벌어지는, 점점 커지는 격차입니다.

빌드가 느려지고, 의존성이 엉키고, 특정 모듈을 건드릴 때마다 밀려오는 막연한 두려움 같은 형태로 스스로를 드러내는 기술 부채와 달리, 이해 부채(Comprehension debt)는 가짜 자신감을 키웁니다. 코드베이스는 깨끗해 보이고, 테스트는 모두 통과합니다. 진짜 청산 시점은 조용히, 보통 가장 최악의 타이밍에 찾아옵니다.

마가렛 앤 스토리(Margaret-Anne Storey)는 어떤 학생 팀이 7주 차에 이 벽에 부딪힌 사례를 설명합니다. 그 시점이 되자, 이들은 더 이상 예상치 못한 문제를 일으키지 않고는 간단한 변경조차 할 수 없게 되었습니다. 실제 문제는 지저분한 코드가 아니었습니다. 팀 내 어느 누구도 왜 특정 설계 결정이 내려졌는지, 시스템의 서로 다른 부분들이 원래 어떻게 함께 동작하도록 설계되었는지 설명할 수 없다는 점이었습니다. 시스템에 대한 이론, 즉 시스템의 개념적 모델이 증발해 버린 것입니다.

이것이 바로 실시간으로 복리로 쌓여 가는 이해 부채(Comprehension debt)입니다.

저는 해커 뉴스(Hacker News)에서 이 문제의 구조적인 측면과 진지하게 씨름하는 엔지니어들의 글을 읽었습니다. 단순한 낙관론 vs 회의론의 이분법이 아니라, 병목 지점이 이동했을 때 무엇이 진짜 엄밀함(rigor)을 구성하는지 이 분야가 스스로 규정하려고 애쓰는 모습이었습니다.

AI 보조가 코딩 이해도에 미치는 영향을 보여주는 차트에는, 코드 생성에 AI를 사용한 그룹이 개념 탐구에 AI를 사용한 그룹에 비해 이해도 점수가 상당히 떨어지는 모습이 나타납니다.

최근 Anthropic의 “How AI Impacts Skill Formation” 연구는 AI 코딩 어시스턴트에 과도하게 의존했을 때 발생할 수 있는 잠재적인 부정적 영향을 강조했습니다. 새로운 라이브러리를 학습하고 있는 52명의 소프트웨어 엔지니어를 대상으로 한 무작위 대조 실험에서, AI 도움을 받은 참가자들은 과제 완료 시간은 대조군과 거의 비슷했지만, 이후 진행된 이해도 퀴즈에서 17% 낮은 점수를 받았습니다(50% vs. 67%). 가장 큰 하락은 디버깅에서 나타났고, 개념적 이해와 코드 읽기 영역에서도 작지만 유의미한 하락이 관찰되었습니다. 연구진은 수동적인 위임(“그냥 되게 만들어 줘”)이 능동적으로 질문하며 AI를 활용하는 방식보다 기술 습득을 훨씬 더 크게 저해한다고 강조합니다. 전체 논문은 arXiv에: https://arxiv.org/abs/2601.20245.

여기에는 속도의 비대칭성 문제가 있습니다

AI는 인간이 코드를 평가하는 속도보다 훨씬 빠르게 코드를 생성합니다. 이건 너무 당연하게 들리지만, 그 함의는 쉽게 과소평가됩니다.

팀 내 개발자가 코드를 작성할 때, 인간이 수행하는 코드 리뷰 과정은 항상 병목이었습니다. 하지만 생산적이고 교육적인 병목이었습니다. PR을 읽는 과정 자체가 이해를 강요합니다. 이는 숨겨진 가정을 드러내고, 6개월 전에 설계한 시스템 아키텍처와 충돌하는 설계 결정을 잡아내며, 코드베이스가 실제로 무엇을 하는지에 대한 지식을 유지·보수 책임을 지는 사람들에게 분산시켜 줍니다.

AI가 생성한 코드는 이 피드백 루프를 깨뜨립니다. 출력량이 너무 많기 때문입니다. 결과물은 문법적으로 깔끔하고, 형식도 잘 정리되어 있으며, 겉으로 보기에는 올바른 경우가 많습니다. 그런데 이런 표면적인 신호들은 역사적으로는 머지를 해도 좋다는 자신감을 주던 신호였습니다. 하지만 표면적인 올바름이 곧 시스템 수준의 올바름을 의미하지는 않습니다. 코드베이스는 건강해 보이지만, 그 아래에서 이해가 조용히 비어가기 시작합니다.

능력 있는 개발자가 프로젝트를 제대로 이해하는 일이 예전부터 늘 가장 큰 병목이라는 말을 어떤 엔지니어가 했습니다. AI는 이 제약을 바꿔 주지 않습니다. 다만 우리가 그 한계를 벗어난 것처럼 착각하게 만들 뿐입니다.

이 전환은 생각보다 훨씬 날카롭습니다. 코드 생산이 비쌌던 시절에는, 시니어 엔지니어가 주니어 엔지니어가 코드를 작성하는 속도보다 빨리 리뷰를 할 수 있었습니다. AI는 이 관계를 뒤집어 버립니다. 이제 주니어 엔지니어도 시니어 엔지니어가 비판적으로 검토할 수 있는 속도보다 빠르게 코드를 생성할 수 있습니다. 리뷰를 의미 있게 유지시켜 주던 속도 제약이 사라져 버린 것입니다. 한때 품질 게이트였던 것이 이제는 단순한 처리량(throughput) 문제로 바뀐 것입니다.

저도 테스트를 사랑하지만, 그것만으로는 충분하지 않습니다

단위 테스트, 통합 테스트, 정적 분석, 린터, 포매터 같은 결정론적 검증에 더 깊이 의존하고 싶은 유혹은 이해할 수 있습니다. 저 역시 AI 코딩 에이전트에 많이 기대는 프로젝트에서는 이런 접근을 자주 합니다. 리뷰 병목을 자동화로 뚫어 보려는 것이죠. 기계가 기계를 검증하게 두는 겁니다.

이 방식은 도움이 됩니다. 하지만 분명한 상한선이 있습니다.

관찰 가능한 모든 행위를 커버할 수 있는 테스트 스위트는, 많은 경우 그 테스트가 검증하려는 코드보다 더 복잡해집니다. 그러나 스스로 추론하지 못하는 복잡성은 안전성을 제공하지 못합니다. 그 아래에는 더 근본적인 문제가 있습니다. 생각해 보지 못한 행동에 대해서는 테스트를 쓸 수 없다는 점입니다.

아무도 “드래그한 아이템이 완전히 투명해지면 안 된다”는 테스트를 쓰지 않습니다. 그럴 수 있다는 가능성 자체를 떠올리지 못했기 때문입니다. 바로 이런 류의 실패가 슬그머니 통과합니다. 테스트 스위트가 허술해서가 아니라, 그 방향으로는 아무도 눈을 돌리지 않았기 때문입니다.

여기에는 특정한 실패 모드도 하나 존재합니다. AI가 구현 세부를 변경하면서 새로운 동작에 맞춰 수백 개의 테스트 케이스까지 함께 업데이트해 버리는 상황을 생각해 보십시오. 이 경우 질문은 “이 코드가 올바른가?”에서 “이 많은 테스트 변경이 모두 필요했는가, 그리고 내가 생각하지 못하고 있는 부분을 잡아낼 만큼 충분한 커버리지가 있는가?”로 바뀝니다. 이 질문에 테스트는 답을 줄 수 없습니다. 오직 이해만이 답을 줄 수 있습니다.

데이터도 점점 이런 방향을 뒷받침하고 있습니다. 연구에 따르면, 코드 생성을 AI에게 위임한 개발자들은 이해도 시험에서 40% 미만의 점수를 받는 반면, AI를 개념적 탐구—질문을 던지고, 트레이드오프를 탐색하는 데—사용한 개발자들은 65% 이상의 점수를 받았습니다. 도구 자체가 이해력을 파괴하는 것이 아닙니다. 그 도구를 사용하는 방식이 이해력을 좌우합니다.

테스트는 필수적입니다. 그러나 충분조건은 아닙니다.

스펙에 기대는 것도 좋지만, 그것만으로는 여전히 부족합니다

자주 제안되는 해결책 중 하나는 다음과 같습니다. 먼저 상세한 자연어 스펙을 작성하라. PR에 이 스펙을 포함하라. 코드는 보지 말고 스펙만 리뷰하라. 그리고 AI가 의도를 구현으로 충실히 옮겼다고 믿으라.

이 접근은 한때 워터폴(Waterfall) 방법론이 매력적으로 보였던 이유와 비슷한 매력을 가지고 있습니다. 먼저 문제를 엄격하게 정의한 뒤, 그다음에 실행하는 방식입니다. 역할과 책임이 깔끔하게 분리된 듯 보이지요.

하지만 스펙을 실제 동작하는 코드로 옮기는 과정에는, 어떤 스펙도 완전히 포착하지 못하는 엄청나게 많은 암묵적 결정들이 개입됩니다. 엣지 케이스, 데이터 구조, 에러 처리, 성능 트레이드오프, 상호작용 패턴까지. 같은 스펙을 두 명의 엔지니어가 구현해도, 관찰 가능한 행동에서 상당히 다른 시스템이 나올 수 있습니다. 두 구현 중 어느 쪽도 ‘틀렸다’고 할 수는 없습니다. 단지 서로 다를 뿐입니다. 그리고 그 차이들 가운데 상당수는, 아무도 예상하지 못한 방식으로 언젠가 사용자에게 중요한 영향을 미치게 됩니다.

또 하나 짚고 넘어가야 할 가능성이 있습니다. 프로그램을 온전히 기술할 만큼 충분히 상세한 스펙은, 사실상 그 프로그램 그 자체와 크게 다르지 않습니다. 다만 실행 불가능한 언어로 쓰여 있다는 점만 다릅니다. 리뷰를 대체할 만큼 치밀한 스펙을 작성하는 조직적 비용은, AI로 구현을 맡겼을 때 얻는 생산성 향상을 기껏해야 상쇄해 버릴 가능성이 큽니다. 게다가 여전히 실제로 생성된 결과물 자체를 리뷰하지는 않았다는 문제도 남습니다.

더 깊은 문제는, 종종 ‘정답인’ 스펙 같은 것은 애초에 존재하지 않는다는 점입니다. 요구사항은 만드는 과정에서 드러나고, 엣지 케이스는 실제 사용을 통해 드러납니다. 복잡한 시스템을 만들기 전에 완전히 스펙으로 고정할 수 있다는 가정은 수차례 시험대에 올랐고, 번번이 실패했습니다. AI가 이 사실을 바꾸지는 못합니다. 다만 인간의 숙고 없이 이뤄지는 암묵적 결정의 새로운 층을 하나 더 얹을 뿐입니다.

역사에서 배워야 합니다

분산된 팀, 다양한 맥락과 제한된 커뮤니케이션 대역폭 속에서 소프트웨어 품질을 관리하는 수십 년의 경험이 우리에게 실제로 검증된 여러 실천법을 남겼습니다. 팀원이 이제 모델로 바뀌었다고 해서, 이 모든 것이 사라지는 것은 아닙니다.

AI로 바뀌는 것은 비용(엄청나게 낮아짐), 속도(엄청나게 빨라짐), 그리고 사람 간 관리 오버헤드(사실상 제로)가 전부입니다. 바뀌지 않는 것은, 시스템에 대한 깊은 맥락을 가진 누군가가 코드베이스가 실제로 무엇을 하고 있는지, 왜 그런 식으로 동작하는지에 대한 일관된 이해를 유지해야 한다는 필요성입니다.

이해 부채(Comprehension debt)는 이런 불편한 재분배를 강제합니다.

AI를 통해 생성되는 코드의 양이 늘어날수록, 시스템을 진정으로 이해하는 엔지니어의 가치는 줄어들지 않고 오히려 커집니다. 어떤 diff를 봤을 때, 어떤 동작이 실제로 ‘하중을 지탱하는지(load-bearing)’ 직감적으로 알아차릴 수 있는 능력. 8개월 전 압박 속에서 왜 그 아키텍처 결정이 내려졌는지를 기억하고 있는 능력.

리팩터링이 진짜로 안전한지, 아니면 사용자가 의존하고 있는 어떤 것을 조용히 바꾸고 있는지를 구분해 내는 능력. 이 능력이 전체 시스템이 의존하게 되는 희소 자원이 됩니다.

여기에는 측정의 공백도 있습니다

이해 부채(Comprehension debt)가 위험한 이유는, 여러분이 현재 사용하는 어떤 측정 시스템에도 이 부채가 포착되지 않기 때문입니다.

속도 지표는 흠잡을 데 없어 보입니다. DORA¹ 지표도 안정적입니다. PR 개수는 늘었습니다. 코드 커버리지는 초록색입니다.

성과 평가 위원회는 속도 향상을 봅니다. 하지만 이해도의 결핍은 볼 수 없습니다. 조직이 산출을 측정하는 어떤 아티팩트에도 그 차원이 기록되지 않기 때문입니다. 인센티브 구조는 측정되는 것에 대해서는 올바르게 최적화됩니다. 하지만 이제 그 측정 대상이 더 이상 진짜 중요한 것을 반영하지 못합니다.

이 점이 이해 부채(Comprehension debt)를 기술 부채보다 더 교묘하게 만드는 지점입니다. 기술 부채는 보통 의식적인 트레이드오프입니다. 지름길을 택했고, 그 지름길이 어디에 있는지 대략 알고 있으며, 나중에 갚을 계획을 세울 수 있습니다. 반면 이해 부채(Comprehension debt)는 보통 누구도 그것을 허용하겠다고 명시적 결정을 내리지 않은 채, 보이지 않게 쌓여 갑니다. 코드가 좋아 보이고, 테스트가 모두 통과했으며, 리뷰 대기 중인 PR이 또 하나 더 있었던 수백 번의 리뷰가 누적된 결과입니다.

“리뷰된 코드는 이해된 코드다”라는 조직의 기본 가정은 더 이상 통하지 않습니다. 엔지니어들은 완전히 이해하지 못한 코드를 승인했고, 그 코드는 이제 묵시적으로 ‘승인된 것’으로 간주됩니다. 아무도 눈치채지 못한 사이, 그 책임과 잠재적 부채는 조직 전체로 분산되었습니다.

규제의 수평선은 생각보다 가까이 와 있습니다

너무 빠르게 움직인 모든 산업은 결국 규제를 맞이하게 되었습니다. 테크 업계는 이 동학에서 유난히 오랫동안 자유로웠습니다. 부분적으로는 소프트웨어 실패가 대체로 복구 가능했기 때문이고, 또 부분적으로는 업계가 규제 당국이 따라잡을 수 없을 만큼 더 빨리 움직여 왔기 때문입니다.

이제 그 창문은 닫혀 가고 있습니다. AI가 생성한 코드가 의료 시스템, 금융 인프라, 정부 서비스에서 실제로 돌고 있는 상황에서, 사고 이후 보고서에 “AI가 작성했고, 우리는 충분히 리뷰하지 못했습니다”라는 설명은, 사람의 생명이나 막대한 자산이 걸린 상황에서는 통하지 않을 것입니다.

지금 이 시점에 이해에 대한 규율을 쌓고 있는 팀—단순히 테스트 통과가 아니라 진정한 이해를 비가역적인 조건으로 대우하는 팀—은, 오직 머지 속도에만 최적화한 팀보다 훨씬 더 좋은 위치에서 다가올 청산 국면을 맞이하게 될 것입니다.

이해 부채(Comprehension debt)가 실제로 요구하는 것

지금 우리가 던져야 할 올바른 질문은 “어떻게 더 많은 코드를 생성할 것인가?”가 아닙니다. “우리가 배포하고 있는 것들에 대해 실제로 더 많이 이해하는 방법은 무엇인가?”입니다. 그래야 사용자에게 일관되게 높은 품질의 경험을 제공할 수 있기 때문입니다.

이 관점 전환은 실질적인 결과를 가져옵니다. 이는 변경이 작성되기 전에, 그 변경이 무엇을 하려는 것인지 잔혹할 정도로 명확하게 드러내야 한다는 뜻입니다. 검증을 사후 단계가 아니라 구조적 제약으로 취급해야 한다는 뜻입니다. 라인 단위가 아니라 아키텍처 수준에서 AI의 실수를 잡아낼 수 있도록 시스템 수준의 정신 모델을 유지해야 한다는 뜻입니다. 그리고 “테스트가 통과했다”는 말과 “이 코드가 무엇을 왜 하는지 내가 이해한다”는 말 사이의 차이에 대해 정직해야 한다는 뜻입니다.

코드를 싸게 생성할 수 있게 되었다고 해서, 이해를 건너뛰는 일까지 싸게 만들어 주지는 않습니다. Comprehension, 즉 이해의 작업이 곧 이 일의 본질입니다.

AI는 번역을 담당합니다. 그러나 무엇이 생성되었는지, 왜 그런 식으로 생성되었는지, 그 과정에서 내려진 암묵적 결정들이 과연 적절했는지를 이해하는 일은 여전히 누군가의 몫입니다. 그렇지 않다면, 결국에는 온전히 갚아야 할 청구서를 뒤로 미루고 있을 뿐입니다.

이해에 대한 비용은 언젠가 반드시 지불해야 합니다. 이 부채는 매우 빠른 속도로 이자가 붙습니다.