AI 기술 부채 — 빨라진 생성, 미뤄진 이해

본문 §7 원칙 6 "대규모 작업은 체크리스트로 격파하라"에서 에이전트에게 일을 맡길 때의 워크플로우를 다뤘어요. 그런데 "에이전트가 코드를 빠르게 만들어준다"는 사실에는 그늘이 하나 따라붙어요. 빠르게 만든 만큼 빠르게 쌓이는 빚이 있다는 거예요. 이 부록은 그 빚 — AI 기술 부채 — 가 무엇이고, 사람들이 이걸 어떻게 바라보는지 정리해요.

한 줄 요약

기술 부채(technical debt) 는 빨리 끝내려고 미뤄둔 작업이 나중에 이자처럼 불어나는 비용을 말해요. AI 기술 부채 는 같은 개념이 AI 시대에 두 갈래로 갈라진 것이에요 — (1) 머신러닝 시스템 자체가 구조적으로 떠안는 숨은 빚, (2) AI가 대신 써준 코드가 빠르게 쌓는 빚. 두 번째 갈래에서 특히 새로운 점은, 빚이 코드뿐 아니라 "아무도 이 코드를 이해하지 못한다" 는 사람 쪽으로 옮겨간다는 거예요.

기술 부채라는 비유

이 말은 1992년 워드 커닝햄(Ward Cunningham)이 만들었어요. 돈을 빌리면 당장은 편하지만 갚을 때까지 이자가 붙죠. 코드도 마찬가지예요 — "일단 돌아가게만 만들고 정리는 나중에" 하고 미뤄둔 부분은, 시간이 지날수록 그 위에 무언가를 더 얹기 어려워지면서 유지보수 비용이 이자처럼 불어나요.

핵심은 빚 자체가 나쁜 게 아니라는 점이에요. 갚을 계획이 있으면 빚은 전략이에요 — 급할 때 빨리 출시하고 나중에 정리하면 돼요. 문제는 빚이 있다는 사실 자체를 잊어버릴 때예요. 그러면 어느 순간 이자만 갚느라 새 일을 못 하는 상태가 돼요.

AI는 이 비유를 두 방향으로 확장했어요.

갈래 1 — ML 시스템의 숨은 부채 (원조)

2014~2015년, 구글 연구진(D. Sculley 등)이 "Hidden Technical Debt in Machine Learning Systems" 라는 논문을 냈어요. 부제가 강렬했어요 — "머신러닝은 기술 부채의 고금리 신용카드(high-interest credit card)".

이들의 핵심 통찰은 이거예요. 사람들은 머신러닝 프로젝트에서 모델 코드 에만 신경을 써요. 하지만 모델 코드는 전체 시스템에서 작은 상자 하나일 뿐이고, 그 상자를 둘러싼 데이터 수집·전처리·설정·연결용 코드(glue code — 서로 다른 부품을 이어붙이는 코드)가 훨씬 크다는 거예요. 진짜 빚은 그 주변 배관에서 조용히 쌓여요.

이들이 꼽은, ML에만 있는 부채 유형들:

• 얽힘(entanglement) — 일반 소프트웨어는 모듈을 깔끔하게 나눠서 "여기만 고치면 됨"이 가능해요. 그런데 ML 모델은 입력 특징(feature — 모델이 보는 입력 항목) 하나만 바꿔도 학습된 가중치 전체가 흔들려요. 연구진은 이걸 CACE 원칙 이라 불렀어요 — Changing Anything Changes Everything, "뭐든 하나 바꾸면 전부 바뀐다".
• 숨은 피드백 루프(hidden feedback loop) — 모델이 내놓은 결과가 사용자 행동을 바꾸고, 그 행동이 다시 다음 학습 데이터가 돼요. 아무도 의도하지 않은 방향으로 시스템이 서서히 자기 자신을 바꿔나가요.
• 데이터 의존성(data dependency) — 코드가 어떤 라이브러리에 의존하는지는 도구로 추적이 돼요. 그런데 모델이 어떤 데이터에 기대고 있는지는 문서화가 잘 안 돼서, 그 데이터가 조용히 바뀌거나 사라져도 아무도 몰라요.
• 파이프라인 정글(pipeline jungle) — 데이터를 준비하는 단계가 누더기처럼 얽혀서, 어느 순간 전체 흐름을 이해하는 사람이 아무도 없게 돼요.
• 외부 세계의 변화 — 코드는 한 글자도 안 바뀌었는데, 바깥 현실(시장, 사용자 습관, 계절)이 바뀌어서 모델이 갑자기 틀리기 시작해요.

이 갈래의 메시지를 한 문장으로 줄이면 — "빠른 성과(quick win)가 공짜처럼 보이지만, 절대 공짜가 아니다."

갈래 2 — AI가 써준 코드의 부채 (지금 뜨거운 쪽)

코딩 에이전트(Claude Code, Codex 등)로 코드를 대량 생성하게 되면서, 완전히 새로운 이야기가 나왔어요. 특히 바이브 코딩(vibe coding — 개발자가 생성된 코드를 직접 꼼꼼히 읽지 않고 "느낌"으로 AI에게 맡겨 만들고 그대로 커밋하는 방식) 이 2026년 들어 주류 워크플로우가 됐어요. 2026년 초 기준 전문 개발자의 약 85%가 매주 AI 코딩 도구를 쓰고, 작업 흐름은 "프롬프트 → 생성 → 슬쩍 보기 → 커밋" 패턴으로 굳어졌어요.

조사된 수치들이 꽤 무거워요.

여기서 흥미로운 패턴 두 가지가 관찰됐어요.

• 추론-복잡도 트레이드오프(Reasoning-Complexity Trade-off) — 모델이 똑똑해질수록 오히려 더 비대하고 서로 얽힌 코드를 만드는 경향이 있어요.
• 양-품질 반비례 법칙(Volume-Quality Inverse Law) — 생성된 코드의 양이 많을수록 구조 품질이 떨어져요. 코드 양이 구조 악화를 거의 정확하게 예측한다고 할 정도예요.

빚이 사람 머릿속으로 옮겨갔다 — 두 가지 새 개념

갈래 2에서 가장 새로운 점은, 빚이 코드 파일이 아니라 사람의 이해 안에 쌓인다는 거예요.

이해 부채(comprehension debt) — 개발자 애디 오스마니(Addy Osmani)가 만든 말이에요. "시스템에 존재하는 코드의 양과, 사람이 진짜로 이해하는 코드의 양 사이에 벌어지는 간격." 기존 기술 부채는 "고치기 불편하다"는 마찰로 자기 존재를 알려요. 그런데 이해 부채는 그런 신호가 없어요 — 코드가 일단 돌아가니까 "가짜 자신감(false confidence)" 을 키우며 조용히 쌓여요. 오스마니의 진단이 날카로워요: "주니어 개발자가 코드를 생성하는 속도가, 시니어가 그 코드를 비판적으로 검토하는 속도보다 빨라졌다." 품질을 거르는 관문이던 코드 리뷰가, 이제는 처리량 병목이 돼버린 거예요. 그가 든 비유 한 줄 — "코드를 싸게 만들 수 있게 됐다고, 이해를 싸게 건너뛸 수 있게 된 건 아니다."

인지 부채(cognitive debt) — AI에 계속 의존하면 개발자 본인의 능력이 약해진다는 관찰이에요. 한 연구에서, AI 보조를 쓴 엔지니어가 자기가 다룬 코드의 이해도 퀴즈에서 약 17% 낮은 점수를 받았고, 특히 디버깅 능력에서 가장 크게 떨어졌어요. 근육을 안 쓰면 약해지는 것과 같은 원리예요.

사람들의 견해 — 갈라진 전선

이 주제는 2026년 현재 개발자 커뮤니티에서 가장 뜨겁게 논쟁 중인 주제 중 하나예요. 견해는 크게 셋으로 나뉘어요.

낙관론

• AI가 반복 작업에서 개발자를 해방시켜, 창의적·전략적 사고에 시간을 더 쓰게 해줘요.
• 실제 성과도 분명해요 — 2026년 신규 SaaS MVP(최소 기능 제품)의 약 40%가 바이브 코딩으로 만들어지고, 일부 스타트업은 바이브 코딩 플랫폼으로 8개월 만에 연 매출 1억 달러 규모에 도달했어요.
• "코드를 싸게 만들 수 있게 된 것"은 그 자체로 되돌릴 수 없는 진보예요.

비관·경계론

• AI 코드는 "거의 맞지만 정확히는 아닌(almost, but not quite, right)" 상태가 많아요. 처음엔 잘 돌아가다가, 문제가 시간이 지나며 복리로 불어나요.
• 가장 날카로운 지적은 인력 구조 에 관한 거예요. 엔지니어링 리더의 약 54%가 AI 때문에 주니어를 덜 뽑겠다고 했는데 — 정작 AI가 만든 부채를 고치려면 인간의 판단력이 필요하고, 그 판단력은 주니어가 수년에 걸쳐 코드를 직접 다루며 키우는 것이에요. 주니어 자리를 없애면, 미래에 오늘 쌓은 빚을 갚을 사람이 사라진다는 거예요.

실용론 (지금 주류로 자리잡는 견해)

• 결론은 "AI를 쓰지 말자"가 아니라 "일하는 방식을 바꿔야 한다" 예요. 한 글의 제목이 이 정서를 잘 담아요 — "바이브 코딩 = 기술 부채 공장, 단 일하는 방식을 안 바꾼다면."
• 처방으로 자주 거론되는 것들:
  • 명세 우선 개발(spec-driven development) — 코드를 짜기 전에 "무엇을 만들지"를 명확히 적고 시작하기. 본문 §7 원칙 8 "계획 모드로 먼저 상의하라"와 같은 맥락이에요.
  • 검증을 선택이 아닌 구조적 의무로 — "테스트가 통과했다"와 "사람이 이 코드를 이해했다"를 정직하게 구분하기.
  • 시스템 전체의 멘탈 모델 유지 — 작은 단위 커밋과 코드 리뷰로, 사람이 따라갈 수 있는 속도로 생성 속도를 묶어두기.
• 학계도 본격적으로 다루기 시작했어요 — 소프트웨어공학 최고 학회인 ICSE 2026 에 "AI 시대의 기술 부채" 패널이 잡혔고, "TODO: Fix the Mess Gemini Created" 같은 제목의 논문도 나왔어요.

에이전트 워크플로우에서 빚을 관리하는 법

이 레포의 다른 부록들이 다루는 도구·습관들이, 사실 대부분 AI 기술 부채를 막는 장치예요.

• 작은 단위 커밋 — 한 커밋의 변경량이 작으면 사람이든 다른 에이전트든 빠르게 훑고 합격·반려를 결정할 수 있어요. 검토가 따라갈 수 있는 크기로 생성을 묶어두는 거예요. 상세는 커밋(Commit)이란 무엇인가.
• 계획 모드·승인 단계 — 코드를 쏟아내기 전에 "무엇을 할지" 합의하는 단계. 명세 우선 개발의 에이전트 버전이에요.
• 시스템 프롬프트 파일 (Claude Code: CLAUDE.md, Codex: AGENTS.md) — 프로젝트의 구조·제약·규칙을 적어두면, 에이전트가 매번 같은 맥락 위에서 일관된 코드를 만들어요. 파이프라인 정글을 막는 문서화의 역할이에요. 상세는 Claude Code 3대 설정 축과 Codex 사용 가이드.
• 읽고 이해하는 단계를 건너뛰지 않기 — 생성된 코드를 "슬쩍 보고 커밋"하는 대신, 왜 이렇게 짰는지 설명하게 하고 직접 읽는 것. 이해 부채를 갚는 가장 직접적인 방법이에요.

핵심은 갈래 1의 교훈과 같아요 — 빠른 성과는 공짜가 아니에요. 다만 빚이 있다는 걸 알고, 갚을 계획을 함께 두면 그건 여전히 좋은 전략이에요.

정리

• 기술 부채 = 빨리 끝내려고 미뤄둔 작업이 이자처럼 불어나는 비용. 빚 자체가 나쁜 게 아니라, 잊어버리는 게 위험해요.
• 갈래 1 (ML 시스템의 숨은 부채) — 모델 코드는 작은 상자일 뿐, 빚은 주변 배관(데이터·설정·glue code)에 쌓여요. CACE 원칙: 뭐든 하나 바꾸면 전부 바뀜.
• 갈래 2 (AI가 써준 코드의 부채) — 생성 속도가 검토·이해 속도를 앞질러요. 빚이 코드가 아니라 사람 머릿속(이해 부채·인지 부채)으로 옮겨가요.
• 사람들의 견해 — 낙관(생산성 진보) vs 비관(주니어 공동화) vs 실용(쓰되 일하는 방식을 바꿔라). 실용론이 주류로 수렴 중이에요.
• 관리법 — 작은 단위 커밋, 계획 모드, 시스템 프롬프트 파일, 그리고 무엇보다 읽고 이해하는 단계를 건너뛰지 않기.

참고 출처

• D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015 — papers.neurips.cc
• Machine Learning: The High-Interest Credit Card of Technical Debt, Google Research — research.google
• Addy Osmani, Comprehension Debt: the hidden cost of AI generated code, 2026 — medium.com
• How AI generated code compounds technical debt, LeadDev — leaddev.com
• Is vibe coding the new gateway to technical debt?, InfoWorld — infoworld.com
• Technical Debt in the AI Era, ICSE 2026 패널 — conf.researchr.org

짝 부록

• 본편 입문: into-the-latent-space 12편 "빌려 쓴 똑똑함" — 같은 주제의 일반 독자용 진입점. 이해 부채·인지 부채를 빚 비유로 풀어둠
• 커밋(Commit)이란 무엇인가 — 작은 단위 커밋이 왜 부채 관리의 기본 장치인지
• Claude Code 3대 설정 축 — CLAUDE.md·Hooks·Skills 로 일관된 생성 환경 만들기
• Codex 사용 가이드 — AGENTS.md·승인 모드로 생성 전 검증 단계 두기