설명할 수 없는 코드를 배포하는 것을 멈추세요.

요약 (TL;DR): 이해하지 못한 코드를 병합하는 것은 이해 부채 (Comprehension Debt)를 생성하며, 이는 팀이 더 이상 코드를 유지 관리할 수 없을 때까지 복리로 쌓입니다.

흔한 실수 ❌

AI에게 기능을 구현해 달라고 요청합니다.

코드는 깔끔해 보입니다.

테스트는 통과 (Green) 합니다.

당신은 이를 병합 (Merge) 합니다.

6주 후, 해당 모듈에서 결함 (Defect)이 나타납니다.

팀의 누구도 그것이 어떻게 작동하는지 설명할 수 없습니다.

당신은 다시 AI에게 물어봅니다.

당신은 이해 없이 병합했습니다.

당신은 기능적 부채와 이해 부채 (Comprehension Debt)를 모두 쌓았습니다.

해결되는 문제들 😔

• AI 없이 디버깅 (Debug) 할 수 있는 능력을 상실합니다.

• 팀이 AI가 생성한 모듈에 새로운 구성원을 온보딩 (Onboard) 할 수 없습니다.

• 설계 결정 (Design decisions) 사항들이 보이지 않게 되고 조용히 축적됩니다.

• "테스트 통과"를 "코드 이해"로 착각합니다.

• 이해도가 밑바닥에서 조용히 무너지는 동안, 당신의 속도 지표 (Velocity metrics)는 훌륭해 보입니다.

• 이제 주니어 개발자가 시니어 엔지니어가 코드를 검토 (Audit) 하는 속도보다 더 빠르게 코드를 생성할 수 있습니다.

• 당신이 의존했던 품질 게이트 (Quality gate)가 사라집니다.

실행 방법 🛠️

1. AI가 생성한 코드를 수락하기 전에 사소하지 않은 모든 코드 블록을 설명해 달라고 요청하세요.

2. 채팅창을 닫고, 그 설명을 주석이나 ADR (Architecture Decision Record, 아키텍처 결정 기록)에 자신만의 언어로 다시 작성하세요.

3. AI가 생성한 각 함수에 대해 "여기서 어떤 가정 (assumptions)을 했나요?"라고 물어보세요.

4. 10분간의 AI 블랙아웃 (AI blackout)을 실행하세요: 채팅창을 다시 열지 않고 동료에게 해당 모듈을 설명해 보세요.

5. PR (Pull Request) 템플릿에 이해 확인 (comprehension check) 단계를 추가하세요: "이 변경 사항을 3문장으로 설명할 수 있습니까?"

6. 개념적 탐구 (conceptual inquiry)를 위해 AI를 사용하세요: _어떻게 (how)_를 물을 때만큼 자주 _왜 (why)_를 물으세요.

7. 당신의 하중을 견디는 결정 (load-bearing decisions): 만약 틀렸을 경우 몇 주간의 시간을 허비하게 만들 결정들을 식별하세요.

8. AI가 당신을 대신해 내린 각 아키텍처 결정 (architectural decision)을 한 문장씩 기록하는 짧은 decisions.md 파일을 유지하세요.

이점 🎯

1. 디버깅 가능성 (Debuggability): 시스템을 이해하고 있기 때문에 AI 채팅창을 다시 열지 않고도 결함 (defects)을 수정할 수 있습니다.

2. 온보딩 속도 (Onboarding speed): 새로운 팀원들이 당신의 결정 기록 파일을 읽고 코드가 왜 존재하는지 이해할 수 있습니다.

3. 재작업 감소 (Reduced rework): 잘못된 가정이 프로덕션 (production)에 도달하기 전에 잡아낼 수 있습니다.

4. 정직한 속도 (Honest velocity): 당신의 속도 지표가 미뤄진 이해가 아닌 실제 결과물을 반영합니다.

5. AI 감독 기술 (AI supervision skill): 연구에 따르면 AI의 도움을 받을 때에도 AI와 인지적 상호작용 (cognitive engagement)을 하면 학습 결과가 보존됩니다.

문맥 🧠

이해 부채 (Comprehension debt)는 시스템에 존재하는 코드의 양과 인간이 진정으로 이해하는 양 사이의 점점 커지는 격차를 의미합니다.

Addy Osmani가 2026년 3월에 이 패턴의 이름을 짓고 설명했습니다.

기술 부채 (technical debt)와 달리, 이해 부채 (Comprehension Debt)는 잘못된 자신감을 심어줍니다.

코드베이스는 깨끗해 보입니다.

테스트는 통과합니다.

그리고 심판의 날은 가장 최악의 순간에 조용히 찾아옵니다.

Anthropic의 한 연구 팀은 새로운 라이브러리를 배우는 52명의 소프트웨어 엔지니어를 대상으로 무작위 대조 시험 (Randomized Controlled Trial)을 실시했습니다.

AI를 사용한 그룹은 대조군과 동일한 시간 내에 과제를 완료했지만, 사후 이해도 퀴즈 (Comprehension Quiz) 점수는 17% 더 낮았습니다 (42% vs. 57%) (Shen and Tamkin, Anthropic, 2026).

가장 큰 하락은 디버깅 (Debugging) 능력에서 나타났습니다.

연구진은 여섯 가지의 뚜렷한 AI 상호작용 패턴을 발견했습니다.

그중 세 가지는 인지적 참여 (Cognitive Engagement)를 포함하며, AI의 완전한 도움을 받을 때조차 학습 결과 (Learning Outcomes)를 보존합니다.

도구가 이해력을 파괴하는 것이 아닙니다.

도구를 어떻게 사용하는지가 중요합니다.

또한 이해 부채를 속도 비대칭 (Speed Asymmetry) 문제로 생각할 수도 있습니다.

AI는 당신이 코드를 평가할 수 있는 속도보다 훨씬 빠르게 코드를 생성합니다.

당신이 코드를 작성할 때, 리뷰 프로세스는 병목 현상 (Bottleneck)이지만 생산적인 과정입니다.

풀 리퀘스트 (PR)를 읽는 행위는 이해를 강제합니다.

AI가 생성한 코드는 그 피드백 루프 (Feedback Loop)를 깨뜨립니다.

그 양이 너무 방대하기 때문입니다.

출력물은 구문론적으로 깨끗하고 표면적으로는 정확합니다. 이는 과거에 당신이 머지 (Merge)해도 안전하다고 느끼게 만들었던 바로 그 신호들입니다.

표면적인 정확함이 시스템적인 정확함을 의미하지는 않습니다.

프롬프트 참조 (Prompt Reference) 📝

나쁜 프롬프트 (Bad Prompt) 🚫

UserRepository 클래스에 Redis 캐싱을 추가해줘.

좋은 프롬프트 (Good Prompt) 👉

UserRepository 클래스에 Redis 캐싱을 추가해줘.

구현한 후에는:
...

고려 사항 (Considerations) ⚠️

테스트는 필수적이지만, 그것만으로는 충분하지 않습니다.

테스트 스위트 (Test Suite)는 당신이 명시하기로 생각했던 동작만을 커버할 수 있습니다.

아무도 상상하지 못한 동작에 대해서는 테스트를 작성하지 않습니다.

AI가 새로운 동작에 맞추기 위해 수백 개의 테스트를 업데이트할 때, 당신은 반드시 물어야 합니다: "이 모든 변경 사항이 정확했는가?"

오직 이해 (Comprehension)만이 그 질문에 답할 수 있습니다.

테스트는 할 수 없습니다.

명세(Specs)가 도움이 되긴 하지만, 리뷰를 대신할 수는 없습니다.

프로그램을 완전히 설명할 수 있을 만큼 상세한 명세는 실행 불가능한 언어로 작성된, 프로그램 그 자체나 다름없습니다.

AI의 컨텍스트 윈도우(Context Window)는 짧게 유지하고, 결정 사항 파일(Decisions file)은 정직하게 유지하세요.

당신은 대화 기록(Transcripts)이 아니라 결정 사항(Decisions)을 문서화해야 합니다.

유형 📝

[X] 반자동 (Semi-Automatic)

한계 ⚠️

이해(Comprehension) 확인 작업은 각 PR(Pull Request)에 시간을 추가합니다.

안전성을 유지하기 위해 팀원 모두가 조금은 속도를 늦추는 것에 동의해야 합니다.

태그 🏷️

• 지식 관리 (Knowledge Management)

레벨 🔋

[X] 중급 (Intermediate)

관련 팁 🔗

AI 코딩 팁 006 - 커밋 전 모든 라인을 리뷰하라

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우

2월 13일

AI 코딩 팁 006 - 커밋 전 모든 라인을 리뷰하라

#ai #programming #development #softwaredevelopment

댓글 1개

7분 읽기

AI 코딩 팁 019 - AI에게 무엇(What)이 아니라 왜(Why)를 말하라

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우

5월 12일

AI 코딩 팁 019 - AI에게 무엇(What)이 아니라 왜(Why)를 말하라

#ai #coding #llm #productivity

3개 반응댓글 3개

4분 읽기

결론 🏁

AI는 코드를 생성하는 비용을 저렴하게 만듭니다.

하지만 이해(understanding)를 생략하는 비용까지 저렴하게 만들지는 않습니다.

설명할 수 없는 코드를 병합(merge)할 때마다, 당신은 미래의 자신으로부터 빌려오는 것입니다.

조만간 이해(comprehension)에 대한 대가를 치르게 될 것입니다.

지금 호기심을 가지고 그 대가를 치르십시오.

추가 정보 ℹ️

Comprehension Debt: The Hidden Cost of AI-Generated Code by Addy Osmani

How AI Impacts Skill Formation, Shen and Tamkin, Anthropic (arXiv 2601.20245)

Comprehension Debt on O'Reilly Radar

Mitigating Epistemic Debt in Generative AI-Scaffolded Programming (arXiv 2602.20206)

AI Technical Debt Compounds: Augment Code Guide

다른 이름들 🎭

• 인지 부채 (Cognitive-Debt)
• AI 이해 격차 (AI-Comprehension-Gap)
• 보이지 않는 기술 부채 (Invisible-Technical-Debt)
• 인식론적 부채 (Epistemic-Debt)

면책 조항 📢

여기에 표현된 견해는 저 개인의 것입니다.

저는 다른 인간들을 위해 최선을 다해 글을 쓰는 인간입니다.

일부 텍스트를 개선하기 위해 AI 교정 도구를 사용합니다.

건설적인 비판과 대화를 환영합니다.

저는 소프트웨어 산업에서의 30년, 교육 분야에서의 25년, 그리고 500편 이상의 기사와 책을 집필한 경험을 통해 이러한 통찰을 형성해 왔습니다.

이 기사는 AI 코딩 팁 (AI Coding Tip) 시리즈의 일부입니다.

AI 코딩 팁 (AI Coding Tips)

Maxi Contieri

Maxi Contieri

Maxi Contieri

팔로우

1월 21일

AI 코딩 팁 (AI Coding Tips)

AI 코딩 팁 (AI Coding Tips)

#webdev #ai #programming #beginners

댓글 추가 (Add Comment)

1분 분량