Addy Osmani블로그
이해 부채 — AI 생성 코드에 숨겨진 대가
이해 부채(Comprehension Debt)란 AI와 자동화에 지나치게 의존하면서 개발자의 사고력과 기억력이 서서히 약화되는 현상을 말한다. 특히 에이전트 기반 개발에서 이 문제가 두드러진다. 팀이 AI 코딩 도구에 깊이 빠져들수록, 생산성 지표에는 드러나지 않는 비용이 조용히 쌓여간다.
팀이 AI 코딩 도구에 깊이 빠져들수록, 생산성 지표에는 드러나지 않는 비용이 조용히 쌓여간다. AI가 생성한 코드를 일일이 리뷰하기가 번거로울수록 더욱 그렇다. 이 비용은 꾸준히 누적되다가, 결국 이자까지 붙어서 갚아야 할 날이 온다. 이것이 바로 이해 부채, 또는 인지 부채(Cognitive Debt)다.
이해 부채란 시스템에 존재하는 코드의 양과 그중 누군가가 실제로 이해하고 있는 코드의 양 사이에서 점점 벌어지는 간극이다.
기술 부채는 자신의 존재를 스스로 드러낸다. 느려지는 빌드, 얽히는 의존성, 특정 모듈을 건드릴 때마다 찾아오는 불안감처럼 마찰이 점점 커지면서 신호를 보낸다. 반면 이해 부채는 거짓된 자신감을 심어준다. 코드베이스는 깔끔해 보이고, 테스트는 모두 통과한다. 그러다 가장 치명적인 순간에, 아무 예고 없이 대가를 치르게 된다.
Margaret-Anne Storey는 한 학생 팀이 7주 차에 벽에 부딪힌 사례를 소개한다. 간단한 수정조차 예상치 못한 곳에서 무언가를 깨뜨리지 않고는 진행할 수 없게 된 것이다. 진짜 문제는 코드가 지저분한 게 아니었다. 팀원 중 누구도 설계 결정의 이유를 설명하지 못했고, 시스템의 각 부분이 어떻게 맞물려 돌아가는지 파악하지 못했다. 시스템에 대한 이론적 이해가 완전히 증발해버린 것이다.
이것이 바로 이해 부채가 실시간으로 복리처럼 불어나는 모습이다.
Hacker News에서 이 문제의 구조적 측면을 진지하게 고민하는 엔지니어들의 토론을 읽은 적이 있다. 흔히 보이는 낙관론 대 회의론의 이분법이 아니라, 병목이 이동한 상황에서 진정한 엄밀함이란 무엇인지 업계 전체가 답을 모색하는 흐름이었다.
최근 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가 이 관계를 뒤집었다. 이제 주니어 엔지니어가 시니어 엔지니어가 비판적으로 검증할 수 있는 속도보다 빠르게 코드를 생성할 수 있다. 리뷰를 의미 있게 만들어주던 속도 제한 장치가 사라진 셈이다. 품질 관문이었던 것이 이제 처리량 문제가 되었다.
테스트를 신뢰하지만, 완전한 해답은 아니다
결정론적 검증 — 유닛 테스트, 통합 테스트, 정적 분석, 린터, 포매터 — 에 더 의지하려는 본능은 충분히 이해된다. AI 코딩 에이전트에 크게 의존하는 프로젝트에서 나 역시 이 방법을 자주 쓴다. 리뷰 병목을 자동화로 돌파하는 것, 기계가 기계를 검증하게 하는 것이다.
분명 도움이 된다. 하지만 명확한 한계가 있다.
모든 관찰 가능한 동작을 커버하는 테스트 스위트는 많은 경우 검증 대상 코드보다 더 복잡해진다. 그런데 추론할 수 없는 복잡성은 안전을 보장하지 못한다. 더 근본적인 문제도 있다. 미처 생각하지 못한 동작에 대해서는 테스트를 작성할 수 없다는 것이다.
드래그한 항목이 완전히 투명해지면 안 된다는 테스트를 작성하는 사람은 없다. 당연하다. 그런 가능성 자체를 떠올리지 못했으니까. 바로 이런 유형의 결함이 테스트를 빠져나간다. 테스트 스위트가 부실해서가 아니라, 아무도 그곳을 살펴볼 생각을 하지 못했기 때문이다.
한 가지 구체적으로 짚어둘 만한 실패 유형도 있다. AI가 구현의 동작을 변경하면서 수백 개의 테스트 케이스를 새 동작에 맞춰 함께 수정해버리면, 질문이 "이 코드가 맞는가?"에서 "이 테스트 변경이 모두 정당한가, 그리고 내가 미처 생각하지 못한 부분까지 커버할 수 있는가?"로 바뀐다. 테스트는 이 질문에 답할 수 없다. 오직 이해만이 답할 수 있다.
데이터도 이를 뒷받침하기 시작했다. 연구에 따르면, AI에 코드 생성을 위임하는 방식으로 사용한 개발자는 이해도 테스트에서 40% 미만을 기록한 반면, 개념적 탐구 — 질문을 던지고 트레이드오프를 탐색하는 방식 — 에 AI를 활용한 개발자는 65% 이상을 기록했다. 도구 자체가 이해를 파괴하는 것이 아니다. 사용 방식이 문제다.
테스트는 필요하다. 하지만 그것만으로 충분하지 않다.
스펙에 기대되, 그것도 완전한 해답은 아니다
자주 제안되는 해법이 있다. 먼저 자연어로 상세한 스펙을 작성하고, PR에 포함시킨 뒤, 코드가 아닌 스펙을 리뷰하는 것이다. AI가 의도를 구현으로 충실하게 변환했으리라 신뢰하는 방식이다.
이 접근은 한때 폭포수(Waterfall) 방법론이 매력적이었던 것과 같은 이유로 매력적이다. 먼저 문제를 엄밀하게 정의하고, 그다음에 실행한다. 깔끔한 관심사의 분리다.
문제는, 스펙을 실제 동작하는 코드로 변환하는 과정에서 엄청난 수의 암묵적 결정이 개입한다는 것이다. 엣지 케이스, 데이터 구조, 에러 처리, 성능 트레이드오프, 인터랙션 패턴 등 어떤 스펙도 완벽하게 담아내지 못하는 영역이다. 같은 스펙을 두 명의 엔지니어가 구현하면, 관찰 가능한 동작에서 수많은 차이가 생긴다. 어느 쪽이 틀린 것이 아니다. 그냥 다를 뿐이다. 그리고 그 차이 중 다수는 아무도 예상하지 못한 방식으로 결국 사용자에게 영향을 미친다.
상세 스펙과 관련해 한 가지 더 짚을 점이 있다. 프로그램을 완전히 기술할 수 있을 만큼 상세한 스펙은 사실상 그 프로그램 자체이며, 단지 실행 불가능한 언어로 작성된 것일 뿐이다. 리뷰를 대체할 수 있을 정도로 철저한 스펙을 작성하는 조직적 비용은, AI를 활용해 실행하는 것으로 얻는 생산성 향상을 상회할 수 있다. 그리고 여전히 실제로 생성된 결과물을 리뷰하지 않은 상태인 것은 마찬가지다.
더 근본적인 문제는, 올바른 스펙이란 애초에 존재하지 않는 경우가 많다는 것이다. 요구사항은 만들면서 드러나고, 엣지 케이스는 사용하면서 발견된다. 복잡한 시스템을 구축하기 전에 완전히 명세할 수 있다는 가정은 수차례 검증되었고, 그때마다 부족한 것으로 판명되었다. AI가 이 사실을 바꿔주지는 않는다. 다만 사람의 숙고 없이 내려지는 암묵적 결정의 층위를 하나 더 얹을 뿐이다.
역사에서 배우자
서로 다른 맥락과 커뮤니케이션 환경을 가진 분산 팀에서 소프트웨어 품질을 관리해 온 수십 년의 경험은 실전에서 검증된 실천 방법들을 남겼다. 팀원이 모델로 바뀌었다고 해서 이 경험이 무효가 되는 것은 아니다.
AI로 인해 달라지는 것은 비용(극적으로 낮아짐), 속도(극적으로 빨라짐), 대인 관리 오버헤드(사실상 제로)다. 달라지지 않는 것은 깊은 시스템 맥락을 가진 누군가가 코드베이스가 실제로 무엇을 하고 있고 왜 그런지에 대한 일관된 이해를 유지해야 한다는 점이다.
이것이 이해 부채가 강요하는 불편한 역할 재분배다.
AI가 생성하는 코드의 양이 늘어날수록, 시스템을 진정으로 이해하는 엔지니어의 가치는 줄어드는 것이 아니라 더 높아진다. diff를 보고 어떤 동작이 핵심 기둥인지 즉시 판별할 수 있는 능력, 8개월 전 압박 속에서 내려진 아키텍처 결정의 이유를 기억하는 능력이 그렇다.
안전한 리팩터링과 사용자가 의존하는 무언가를 조용히 바꿔버리는 리팩터링의 차이를 구별하는 능력, 바로 이것이 전체 시스템이 의존하는 희소 자원이 된다.
측정의 공백 문제도 있다
이해 부채가 위험한 진짜 이유는, 현재의 측정 체계 어디에서도 이를 포착하지 못하기 때문이다.
생산성 지표는 나무랄 데 없어 보인다. DORA 지표도 안정적이다. PR 수는 늘었고, 코드 커버리지도 녹색이다.
성과 평가 위원회는 생산성 향상을 본다. 하지만 이해력 결핍은 볼 수 없다. 조직이 산출물을 측정하는 어떤 지표에도 이 차원이 반영되어 있지 않기 때문이다. 인센티브 구조는 측정 대상에 맞춰 정확하게 최적화된다. 문제는, 그 측정 대상이 더 이상 진짜 중요한 것을 담아내지 못한다는 점이다.
이해 부채가 기술 부채보다 더 교묘한 이유가 여기에 있다. 기술 부채는 대부분 의식적인 트레이드오프의 결과다. 지름길을 선택했다는 것을 알고 있고, 어디에 있는지도 대략 파악하고 있으며, 갚을 일정을 잡을 수 있다. 반면 이해 부채는 눈에 보이지 않게 쌓이며, 누구도 의도적으로 방치한 적이 없는 경우가 대부분이다. 코드가 괜찮아 보이고, 테스트가 통과했고, 큐에 다음 PR이 대기 중이었던 수백 번의 리뷰가 누적된 결과일 뿐이다.
리뷰를 거친 코드는 곧 이해된 코드라는 조직적 전제가 더 이상 성립하지 않는다. 엔지니어들은 완전히 이해하지 못한 코드를 승인했고, 그 코드에는 암묵적인 보증이 부여되었다. 아무도 인지하지 못하는 사이에 책임이 분산된 것이다.
규제의 지평선은 생각보다 가깝다
지나치게 빠르게 움직인 모든 산업은 결국 규제를 불러들였다. 테크 업계는 유독 이 역학에서 벗어나 있었는데, 소프트웨어 장애가 대부분 복구 가능했다는 점과 업계가 규제 기관의 대응 속도보다 빠르게 움직였다는 점이 작용했다.
그 유예 기간이 끝나가고 있다. AI가 생성한 코드가 의료 시스템, 금융 인프라, 공공 서비스에서 실행되는 상황에서, "AI가 작성했고 우리는 완전히 리뷰하지 않았습니다"라는 말은 인명이나 중대한 자산이 걸린 사후 보고서에서 통하지 않을 것이다.
지금부터 이해 역량을 체계화하는 팀 — 단순히 테스트를 통과하는 것이 아니라 진정한 이해를 타협 불가한 기준으로 삼는 팀 — 은, 그 심판의 날이 왔을 때 머지 속도만 최적화한 팀보다 훨씬 유리한 위치에 서게 될 것이다.
이해 부채가 요구하는 것
지금 던져야 할 질문은 "어떻게 더 많은 코드를 생성할까?"가 아니다. "우리가 출시하는 것을 어떻게 더 깊이 이해할까?"다. 사용자에게 일관되게 높은 품질의 경험을 보장하기 위해서라도 그렇다.
이렇게 관점을 바꾸면 실질적인 변화가 따른다. 변경 사항이 정확히 무엇을 해야 하는지 코드를 작성하기 전에 냉정하리만큼 명확하게 정의해야 한다. 검증을 뒤늦은 부록이 아니라 구조적 제약으로 다뤄야 한다. AI의 실수를 한 줄 한 줄이 아닌 아키텍처 수준에서 잡아낼 수 있는 시스템 수준의 멘탈 모델을 유지해야 한다. 그리고 "테스트가 통과했다"와 "이 코드가 무엇을 하고 왜 그런지 이해한다" 사이의 차이에 솔직해야 한다.
코드 생성 비용이 낮아졌다고 해서 이해를 건너뛰는 비용까지 낮아지는 것은 아니다. 이해하는 작업이야말로 본업이다.
AI는 번역을 담당한다. 하지만 생성된 결과가 무엇인지, 왜 그렇게 생성되었는지, 그 과정에서 내려진 암묵적 결정들이 올바른 것이었는지는 여전히 누군가가 이해해야 한다. 그렇지 않으면 결국 전액을 갚아야 할 청구서를 미루고 있는 것에 불과하다.
이해에 대한 대가는 조만간 반드시 치르게 된다. 이 부채의 이자는 빠르게 불어난다.