생성 AI가 소프트웨어 개발의 속도를 폭발적으로 높이고 있다. 작은 팀이 몇 년 전에는 상상도 못 할 빠른 속도로 기능을 출시한다. AI 코딩 도구를 쓰는 팀이라면 이 속도 뒤에 숨겨진 비용, 즉 눈에 보이지 않지만 점점 커지는 부채를 직시할 필요가 있다.
Margaret-Anne Storey 교수는 From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI 논문에서 기술 부채(Technical Debt), 인지 부채(Cognitive Debt), 의도 부채(Intent Debt)라는 3중 부채 모델로 이 문제를 명확히 정리했다. AI는 기술 부채를 줄여줄 수 있지만, 인지 부채와 의도 부채는 오히려 급속도로 쌓이게 만든다는 점이 핵심이다.
1. 소프트웨어 시스템의 세 가지 층
소프트웨어는 단순히 코드가 아니다. Storey에 따르면 세 층으로 구성된다:
- 목표와 의도(Intent): 이해관계자들이 원하는 요구사항, 제약 조건, 사업 목적
- 코드와 구조: 실제 구현된 소스코드, 아키텍처, 인프라
- 공유 이해(Shared Understanding): 팀원들이 시스템을 어떻게 생각하고, 어떻게 변화시킬지 공유하는 정신 모델(mental model)
기술 부채는 코드 층의 문제다. 지저분한 코드, 임시방편 아키텍처, 유지보수가 어려운 설계 등. Ward Cunningham이 The WyCash Portfolio Management System (OOPSLA 1992)를 통해 처음 제안한 개념으로, 지금은 가장 잘 알려져 있고 관리 방법도 많다(TDD, 리팩토링, 코드 리뷰 등). 인지 부채는 공유 이해가 점점 희미해지는 팀·프로젝트 수준의 문제이고, 의도 부채는 외부화된 지식(문서, ADR, 테스트, 제약 조건 등)이 부족하거나 오래된 상태다. 이 글은 AI 시대에 특히 빠르게 축적되는 인지 부채와 의도 부채에 집중한다.
| 레이어 | 부채 | 위치 |
| 코드 계층 | Technical Debt | 코드 |
| 사람 계층 | Cognitive Debt | 개발자 이해 |
| 지식 계층 | Intent Debt | 문서/설계 의도 |
2. AI가 부채를 어떻게 바꾸는가
기술 부채는 AI 리팩토링, 자동 테스트 생성 등으로 오히려 줄일 가능성이 크다. 반면 인지 부채는 AI가 코드를 빠르게 만들어주면 개발자는 “작동하네?”로 끝낸다. 본래 코드를 직접 작성할 때는 이해하려는 마찰이 있었지만, 그 과정이 사라진다. Storey 교수는 이를 Cognitive Surrender(인지적 항복)라고 부르는데, 이해를 위한 노력을 AI에 위임하면서 개발자 스스로의 시스템 이해도가 낮아지는 현상이다. 의도 부채는 AI 에이전트가 코드를 다루려면 인간의 암묵지가 아니라 명시적 의도(ADR, BDD 테스트, 도메인 모델)가 필요한데, 의도가 없으면 AI도 잘못된 방향으로 최적화한다.
실제 연구에서도 AI가 작성한 코드 중 상당수가 문제를 일으키고, 일부는 오랜 기간 잔존한다는 결과가 나오고 있다.
- AI-introduced issues의 장기 잔존율 (2026년 대규모 실증 연구): 수많은 오픈소스 저장소에서 AI 코딩 어시스턴트가 만든 커밋을 분석한 결과, AI가 도입한 이슈 중 22.7%가 최신 버전(HEAD)까지 살아 있었다.
- CodeRabbit 실증 연구 (2025년 12월): 470개의 실제 Pull Request 분석(AI-co-authored vs Human-only) 결과, AI가 관여한 PR은 전체 이슈가 1.7배 많고 보안 취약점도 2.74배 더 많았으며 코드 품질·유지보수성 이슈도 1.64배 증가했다.
- Veracode GenAI Code Security Report (2025): 100개 이상의 LLM을 80개 코딩 태스크로 테스트한 결과, AI 생성 코드의 45%가 보안 취약점을 포함했다.
3. 인지 부채 (Cognitive Debt)
인지 부채는 팀 전체의 공유 이해(shared understanding)가 점차 침식되는 팀·프로젝트 수준의 부채다. 개발자들이 시스템이 어떻게 동작하는지, 왜 그렇게 설계되었는지, 어떻게 안전하게 변경할 수 있는지에 대한 정신 모델(mental model)이 부족해지는 상태를 의미한다. Storey 교수는 이를 “팀의 ‘시스템 이론(theory of the system)‘이 약화되는 현상”으로 설명하며, AI 시대에 특히 빠르게 축적된다고 지적한다.
주요 증상은 다음과 같다:
- 변경 시 예상치 못한 결과 발생
- 변경에 대한 저항(Resistance to change)
- 신입 온보딩 지연
- Bus Factor 저하 — 특정 한두 명만 시스템을 이해하는 상태
- 팀 내 Transactive Memory(누가 무엇을 아는지에 대한 공유 기억) 상실
대응 방안으로는 코드 리뷰를 단순 버그 체크가 아닌 지식 공유의 기회로 전환하고, 페어 프로그래밍, 시스템 워크스루(System Walkthrough), 리트로스펙티브를 적극 활용해야 한다. AI 출력을 검증할 때 “이 코드가 왜 이렇게 동작하는지 직접 설명해보기” 같은 의식적 노력이 중요하며, 완전 자동화에 의존하지 않고 인간의 이해 과정을 의도적으로 유지하는 문화가 핵심이다. AI를 활용하되, 이해를 위한 ‘마찰’을 전략적으로 남겨두는 균형이 필요하다.
4. 의도 부채 (Intent Debt)
의도 부채는 시스템의 목표, 제약 조건, 설계 결정의 근거(rationale)가 외부화(externalized)되지 않거나 오래되어 사라지는 부채다. 코드와 사람의 이해를 넘어 “왜 이 시스템을 이렇게 만들었는가?”에 대한 명시적 기 록이 부족한 상태를 말한다. Storey 교수의 Triple Debt Model에서 의도 부채는 아티팩트(문서, ADR, 테스트 등)에 존재하며, AI 에이전트가 참여하는 환경에서 특히 중요해진다.
아래 코드를 보자.
if order.total_amount >= 50000 and order.destination_country in ["KR", "JP"]:
apply_free_shipping(order)개발자가 이 코드를 보면 “5만원 이상이면 한국/일본은 배송비 무료구나”까지는 이해한다. 하지만 “이 정책은 왜 만들었을까? 어떤 조건에서 바꿔도 되는가?”를 알 수 없다. 이것이 의도 부채다. AI 시대에는 아이디어 → 티켓 → 프롬프트 → 코드로 압축되는 과정에서 맥락이 대량으로 손실된다. 코드 생성 속도는 빨라졌지만, 이해와 기록 속도는 그대로다.
대표 증상으로는 Behavior Drift(시스템 동작이 이해관계자 기대와 점차 멀어짐), AI 에이전트의 변경 실패, 비기능 요구사항(성능, 보안, 접근성 등) 상실, 코드만으로는 변경 판단이 어려운 상황 등이 있다.
대응 방안으로는 Architectural Decision Records(ADR, 설계 결정과 그 근거를 기록하는 문서), Behavior-Driven Development(BDD) 테스트, Domain-Driven Design의 유비쿼터스 언어, Living Documentation 등을 통해 의도를 명시적으로 기록해야 한다. 특히 “Intent-first workflow”(의도 먼저 명시 후 코드 생성)를 도입하고, AI 에이전트에게도 충분한 컨텍스트(플레이북, 제약 조건)를 제공하는 것이 효과적이다. 의도 부채는 나중에 회복하기 어렵기 때문에, 결정 순간에 기록하는 습관이 가장 강력한 예방책이다.
결론
세 부채를 종합하면, AI는 기술 부채를 줄여주는 동시에 인지 부채와 의도 부채를 급속히 쌓는다. 이 비대칭이 AI 도구를 도입한 팀이 직면하는 진짜 위험이다.
Peter Naur가 1985년에 말한 Programming as Theory Building이 이 문제를 오래전에 예고했다. 프로그래밍의 본질은 코드 작성이 아니라 이론 구축(Theory Building)이라는 주장이다. 여기서 이론이란 “어떤 일을 지능적으로 수행할 뿐만 아니라, 그것을 설명하고, 질문에 답하고, 논쟁할 수 있게 하는 지식”이다. 이 이론은 문서화로 완전히 전달할 수 없는 암묵지(tacit knowledge)를 포함한다.
프로그래머의 지식이 문서를 초월하는 세 가지 영역이 있다:
- 현실 세계와 프로그램의 매핑: 어떤 현실 요소가 프로그램에 포함되고, 무엇이 제외되었는지에 대한 판단
- 변경의 합리성(Rationality of Change): 시스템을 어떻게 수정해야 일관성을 유지할 수 있는지에 대한 이해
- 예상치 못한 질문에 대한 대응 능력: 코드에 직접 명시되지 않은 다양한 질문에 답할 수 있는 능력
개발자가 떠나거나 지식을 잃으면 코드가 남아 있어도 그것을 제대로 이해하고 진화시킬 수 있는 “이론”이 없으면 무용지물이 된다. 개발자의 역할은 이제 “코드 생산자”에서 “시스템 이론 구축자”로 바뀌고 있다. 의도를 명시적으로 남기고, 팀의 공유 지식을 지속적으로 재건하는 문화가 AI 시대 소프트웨어 건강의 핵심이다.
