"2025년 Jason Gorman이 처음 사용하고 2026년 Addy Osmani가 대중화한 "이해 부채(Comprehension debt)"는 시스템 내 코드의 양과 인간이 실제로 이해하는 양 사이의 격차가 커지는 것을 설명합니다. 이 부채는 AI 에이전트가 인간이 이해하는 것보다 훨씬 빠르게 코드를 생성할 수 있기 때문에 발생하며, 이는 코드가 인간의 이해를 의미한다는 70년 된 가정을 무너뜨립니다. 코드 자체의 속성인 기술 부채와 달리, 이해 부채는 코드와의 팀 관계의 속성입니다. 완벽하게 깔끔하고 잘 테스트된 모듈이라도 아무도 이해하지 못하면 여전히 부담이 될 수 있으며, 이는 작동하는 나쁜 코드에서 작동하다가 고장 나는 좋은 코드로의 일반적인 우려를 역전시킵니다.현대 도구 체인이 커버리지 및 속도와 같은 메트릭을 측정하지만 인간의 이해는 측정하지 않기 때문에 이 부채는 보이지 않았습니다. 가장 가까운 대리 지표인 코드 검토는 단순한 샘플링 이벤트이며, AI 네이티브 처리량 하에서는 검토가 더 짧아지고 실제 이해도를 덜 나타냅니다. "버스 계수(bus factor)" 휴리스틱도 실패하는데, 에이전트가 작성한 코드는 부분적이거나 존재하지 않는 버스 계수를 가질 수 있으며, 이는 아무도 실제로 이해하지 못한다는 것을 의미합니다.이해 부채는 보이지 않는 유지 비용을 축적하지만, 사고, 향후 변경, 팀 이탈 및 신규 엔지니어 온보딩 중에 가혹한 이자 지불을 발생시킵니다. 이러한 순간들은 팀이 획득하지 못한 이해를 프리미엄으로 다시 구매하도록 강요합니다. 이해도 측정은 git 기록에서 실질적인 검토 댓글, 최근 인간 작성자, 파일과 진정으로 상호 작용한 고유한 인간 수와 같은 관찰 가능한 신호에 초점을 맞춰야 합니다.이러한 측정에 대한 규율은 중요합니다. 이해는 시간이 지남에 따라 희미해진다는 것을 반영하여 결정론적이고, 분해 가능하며, 논쟁의 여지가 있고, 감소해야 합니다. 결정적으로, 시스템을 속이는 것을 방지하기 위해 원래 작성자 외의 다른 사람이 검증해야 합니다.팀은 AI가 작성한 코드에 대한 기록상 인간 작성자를 지정하고, 에이전트가 생성한 풀 리퀘스트에 대한 침묵 승인을 금지하고, 시스템의 어떤 부분이 제대로 이해되지 않는지에 대해 공개적으로 논의함으로써 즉시 이해 부채 관리를 시작할 수 있습니다. 명명된 사각지대를 백로그 항목으로 취급하는 것도 도움이 될 수 있습니다. 수동 노력은 제한적이지만, Fathohm과 같은 도구는 전체 코드베이스에 걸쳐 이해 부채를 매핑하여 포괄적이고 동적인 보기를 제공할 수 있습니다. 궁극적으로 AI가 계속해서 코드를 작성함에 따라, 이해 부채를 적극적으로 관리하기로 선택하는 것이 해당 코드가 이해되는 상태로 유지될지 여부를 결정할 것입니다."