기술 부채(technical debt)는 1992년 Ward Cunningham이 만든 개념이다. 빨리 짜면 나중에 리팩터링 비용이 쌓인다는 뜻이다. 지난 30년 업계의 기본 어휘였다. 그런데 AI 시대에 이것만으로는 부족하다. 새 개념이 하나 더 필요하다. 이해의 부채(comprehension debt). 내가 이해하지 못한 채 쌓인 코드의 양.
사전이해
기존 technical debt는 내가 짠 나쁜 코드가 쌓이는 빚이었다. 리팩터링이 해결책이고, 이자는 “수정 비용 증가"로 낸다.
이해의 부채는 다르다. AI가 짠 (아마도) 좋은 코드가 내 이해 바깥에 쌓이는 빚이다. 코드는 돌아간다. 그런데 왜 돌아가는지 모른다. 이 개념은 Addy Osmani가 **“comprehension debt”**로, Simon Willison이 **“cognitive debt”**로 비슷한 시기에 정리했다. 전통 개발에선 존재할 수 없던 빚이다. 내가 직접 쳤으면 최소한 이해는 하고 있었으니까.
문제 — 체감과 실제의 간극
METR(Model Evaluation & Threat Research)가 2025년 중반에 공개한 연구가 있다. 경험 많은 오픈소스 개발자 16명을 대상으로 246개 실제 태스크를 AI 툴(Cursor Pro + Claude 3.5/3.7 Sonnet) 유무로 비교했다.
결과:
- AI를 쓴 경우 19% 더 느렸다.
- 본인들은 20% 빨라졌다고 느꼈다.
- 체감-실제 간극 39%포인트.
이게 왜 위험하냐면, 내가 빠르다고 느끼는 순간 멈춰서 이해를 쌓을 이유가 사라진다. 가속 페달만 밟게 된다.
GitClear가 2024년 2억 줄 이상 코드를 분석한 결과도 비슷한 방향이다. 중복 코드 블록이 8배 증가했고 리팩터링은 역대 최저였다. Google DORA 2024 리포트는 AI 사용이 25% 늘 때마다 delivery stability가 7.2% 떨어진다고 보고했다.
속도는 올라가는데 구조는 무너지고 있다. 이해의 부채가 쌓이는 신호다.
핵심 — 이해의 부채란
한 문장 정의.
이해의 부채 = 내가 설명할 수 없는 채로 쌓인, AI가 생성한 코드·결정·구조의 양.
기존 기술 부채와의 차이를 표로 정리하면:
| 기술 부채 | 이해의 부채 | |
|---|---|---|
| 누가 만드나 | 내가 빨리 짬 | AI가 빨리 생성 |
| 코드 품질 | 낮음 | 대개 괜찮음 |
| 해결책 | 리팩터링 | 정독·재학습 |
| 이자 | 수정 비용 | 판단력 저하, 인수인계 불가 |
| 청구되는 순간 | 기능 추가·변경 | 버그·확장·인터뷰·후임 교체 |
핵심은 청구되는 순간이 다르다는 것이다. 기술 부채는 기능을 추가할 때 느려진다. 이해의 부채는 갑자기 무너진다. 프로덕션 버그가 터졌는데 재현이 안 될 때, 인터뷰에서 아키텍처 근거를 물었는데 대답이 막힐 때, 후임 엔지니어에게 인수인계를 할 수 없을 때.
접근 — 의존성 스펙트럼
AI에 대한 의존도를 0~100%로 놓고 각 구간에서 쌓이는 부채를 가늠해볼 수 있다.
| 의존도 | 작업 방식 | 이해 부채 | 관찰 |
|---|---|---|---|
| 0% | 전부 손코딩 | 없음 | 전통 개발. 대신 속도 낮음 |
| 25% | AI 초안 → 내가 전면 리뷰·수정 | 낮음 | Willison 식 추천 레벨 |
| 50% | AI 생성 → 부분만 직접 작성 | 중간 | 대부분의 “vibe coder"가 생각하는 지점 |
| 75% | AI 생성 → “동작 확인"만 | 높음 | METR 실험 대상자들의 실제 위치 |
| 100% | AI 설계+생성+테스트 전부 | 최대 | “프롬프트만 던지는 사람” 모드 |
각 구간에서 필요한 “상환 루틴"은 다르다. 75% 이상이면 기능 추가마다 이해 정독을 병행해야 부채가 복리로 늘지 않는다.
세부 — Alpha Court 사례
Alpha Court 베타를 만들면서 나는 이 부채의 정체를 처음 체감했다. Claude Opus로 생성한 코드가 돌아가는 데엔 문제가 없었다. 그런데 어느 날 검증 로직에서 예상치 못한 결과가 나왔고, 나는 그 모듈을 한 줄씩 읽으며 반나절을 썼다. 그게 내가 “짜지 않은” 코드였다는 사실이 그제야 구체적으로 다가왔다.
콘텐츠 자동화 파이프라인을 만들 때도 같았다. 양산이 가능하고 결과물이 수준급으로 나왔는데, 중간에 끼어있는 일부 로직은 내가 완전히 설명할 수 없다. 제품화하기 전에 내가 사용하면서 그 블랙박스를 하나씩 정독하기로 한 이유다. 속도를 빠르게 가져간 만큼 이해의 부채를 갚는 일정이 제품 출시 앞에 붙었다.
공개된 경고 — Cloudflare CVE 사례
이게 나만의 문제가 아니라는 걸 보여주는 공개 사례가 있다. Cloudflare의 Kenton Varda는 원래 Cap’n Proto 창작자이자 Google Protobuf v2 리드였던 AI 회의론자였다. 그가 Claude Code로 workers-oauth-provider 라이브러리를 만들고 README에 “이 라이브러리는 대부분 Claude가 썼다"고 밝혔다. 커밋 히스토리에 실제 프롬프트가 남아있다.
그런데 나중에 CVE-2025-4143과 CVE-2025-4144가 붙었다. redirect-URI 검증 누락이었다. Claude가 놓친 것이다. 그리고 Varda도 놓쳤다. Varda 같은 실력자조차 AI가 만든 코드의 보안 감사를 놓칠 수 있다는 뜻이다.
교훈이 분명하다. 이해하지 않은 코드는, 보안을 기대할 수 없다.
영향 — 부채는 어디로 향하는가
짧게 보면:
- 단기(1주–1개월): 속도 증가, 출시 빨라짐
- 중기(3–6개월): 확장성 저하, 디버깅 지연, 자신감 침식
- 장기(1년+): 후임 인수 불가, 개인이 대체 가능한 존재로 환원
조직 관점: 당신이 나가면 프로젝트가 멈춘다. 그런데 당신이 들어와도 프로젝트를 빠르게 이해하지 못한다. 이해의 부채는 인수인계라는 개념 자체를 파괴한다.
개인 관점: “나만 아는 부분"이 있다는 착각에 빠지는 순간 가장 위험하다. 당신은 그 부분을 정말 아는 게 아니라, AI가 대신 기억하고 있을 뿐이다.
결과 — 상환 전략
내가 현재 쓰는 상환 루틴은 네 가지다.
- Willison 골든 룰 — “내가 누군가에게 설명할 수 없는 코드는 커밋하지 않는다.”
- 주 1회 정독 — 지난 한 주 동안 AI가 생성한 모듈 중 가장 큰 것 하나를 주말에 한 줄씩 읽는다.
- 검증 하네스 강제 — 테스트·린트·타입체크 통과를 커밋 전 훅으로 묶는다. 통과하지 못한 상태로 merge 할 수 없게 한다.
- Fresh-context 리뷰 — 작업한 에이전트 말고 깨끗한 컨텍스트의 별도 서브에이전트로 코드 리뷰를 한 번 더 돌린다.
75% 의존도에서 시작해, 3개월 안에 50% 레벨로 낮추는 게 이번 분기 내 목표다.
마무리
교훈 하나로 끝낸다.
속도는 공짜가 아니다. 이해를 내준 값이다.
AI-native 시대에 가장 큰 moat는 도구도 아니고, 프롬프트 엔지니어링도 아니다. 내가 이해한 채로 쌓은 코드의 양이다. 그것이 곧 당신이 내일 답할 수 있는 질문의 범위다.
참고한 1차 자료
- Ward Cunningham, “The WyCash Portfolio Management System” OOPSLA 1992 (technical debt 원조)
- Martin Fowler, “TechnicalDebt” bliki
- Simon Willison, “My LLM codegen workflow” 시리즈
- METR, “Measuring the Impact of AI on Experienced Open-Source Developer Productivity” (2025)
- GitClear, “Coding on Copilot” 2024 보고서
- Google DORA, “2024 State of DevOps Report”
- Kenton Varda,
workers-oauth-providerGitHub · CVE-2025-4143, 4144 - Addy Osmani, “comprehension debt” 용어 제안