AI가 빠를수록 팀이 먼저 쌓아야 할 부채가 있다

AI가 빠를수록 팀이 먼저 쌓아야 할 부채가 있다

Triple Debt Model이 폭로한 AI 코딩 속도의 역설—기술 부채보다 인지 부채와 의도 부채가 먼저 팀을 멈춘다.

Triple Debt Model 인지 부채 의도 부채 CLAUDE.md AGENTS.md AI 코딩 에이전트 개발 생산성 컨텍스트 설계
광고

코드는 빨라졌는데, 왜 프로젝트는 느려지는가

AI 코딩 도구를 도입한 팀이라면 한 번쯤 이 이상한 감각을 경험했을 것이다. 분명히 코드는 더 빠르게 나온다. 며칠 걸리던 기능이 몇 시간 만에 완성된다. 그런데 프로젝트 전체 속도는 체감상 별로 달라진 게 없다. PR은 오히려 더 커졌고, 리뷰는 더 오래 걸리고, 디버깅은 더 예측 불가능해졌다.

이 역설을 그냥 '팀원들이 AI 도구에 아직 익숙하지 않아서'라고 넘기면 안 된다. 구조적인 문제다.

Triple Debt Model: 기술 부채는 빙산의 일각이었다

dev.to에 소개된 Margaret-Anne Storey의 연구 프레임워크는 이 역설을 꽤 정확하게 해부한다. Triple Debt Model은 소프트웨어 건강도를 세 가지 부채로 나눈다.

기술 부채(Technical Debt) 는 우리가 이미 알고 있는 것이다. 중복 로직, 깨진 추상화, 임시방편이 영구화된 코드. 눈에 보이고, 정적 분석 도구로 탐지할 수 있으며, AI도 이 부채를 줄이는 데 꽤 쓸만하다.

문제는 나머지 두 가지다.

인지 부채(Cognitive Debt) 는 사람 안에 쌓인다. 코드가 실행되고 테스트도 통과하는데, 팀에서 그 코드가 왜 그렇게 동작하는지 설명할 수 있는 사람이 없는 상태다. AI 에이전트가 수백 줄을 몇 분 만에 생성할 때, 개발자는 테스트 통과 여부만 확인하고 머지한다. '왜 이 접근법을 선택했는가', '어떤 가정 위에 서 있는가', '어떤 부분이 이것에 의존하는가'—이 질문들에 대한 답이 코드에는 없고, 팀 안에도 없다. 코드는 저장소에 들어갔지만 이해는 들어가지 않았다.

의도 부채(Intent Debt) 는 아티팩트 안에 쌓인다. 어떤 캐싱 로직이 왜 거기 있는지 아무도 모른다. 프로덕션 장애 때문인지, 외부 API 제한 때문인지, 아니면 그냥 아무도 지우지 않은 레거시인지. 이 맥락이 어딘가에 기록되어 있지 않으면 인간도, AI 에이전트도 추측으로 결정할 수밖에 없다.

AI는 기술 부채를 줄이지만, 인지·의도 부채를 폭발적으로 늘린다

이게 핵심 딜레마다. AI가 코드를 생성하는 속도는 인간이 그 코드를 이해하는 속도를 훨씬 앞질렀다.

AI 도입 이전에는 코드를 짜는 데 시간이 걸렸고, 그 마찰이 오히려 학습의 기회였다. 기능을 구현하면서 자연스럽게 주변 모듈과 의존성, 제약 조건을 파악했다. 에이전트는 그 마찰을 제거했다. 유용하지만, 그 마찰 안에 학습이 있었다.

결과는 위험한 거래다. 코드 생산 비용은 줄였지만, 나중에 이해하고 안전하게 수정하는 비용은 늘렸다. 처음엔 이 거래가 이득처럼 보인다. 기능이 빠르게 나오고 백로그가 줄어든다. 비용은 나중에 청구된다—시스템을 디버깅하거나, 확장하거나, 마이그레이션하거나, 재설계할 때.

컨텍스트 파일 패밀리: 의도 부채에 대한 실전 처방

그렇다면 팀이 지금 당장 할 수 있는 건 뭔가? 여기서 두 번째 소스가 실용적인 답을 준다.

dev.to의 'DESIGN.md, CLAUDE.md, AGENTS.md' 아티클이 소개하는 컨텍스트 파일 패밀리는 본질적으로 의도 부채를 선제적으로 갚는 설계다. 각 파일의 역할은 명확히 분리된다.

  • CLAUDE.md / AGENTS.md: 스택, 컨벤션, 명령어 등 코드·프로젝트 컨텍스트
  • DESIGN.md: 디자인 토큰과 그 결정의 이유
  • SKILL.md: 에이전트가 필요할 때 참조하는 역량 정의

이 파일들은 단순한 문서가 아니다. 에이전트가 매 인터랙션마다 읽는 영속적 컨텍스트다. 저장소에 코드와 함께 버전 관리된다. 팀이 '왜 이렇게 설계했는가'를 기록해두면, 에이전트가 코드를 생성할 때 그 의도를 반영한다. 서비스를 분리해야 하는 보안 경계, 배포 스케줄, 규제 요건—이런 맥락이 AGENTS.md에 명시되어 있다면, 에이전트가 두 서비스를 '효율적으로' 합쳐버리는 실수를 막을 수 있다.

도입 순서도 현실적이다. 에이전트가 코드 컨벤션을 자꾸 틀리면 CLAUDE.md부터 시작하고, UI가 브랜드에서 벗어나면 DESIGN.md를 추가한다. 한꺼번에 다 갖출 필요 없이, 가장 아픈 지점부터 하나씩.

팀 설계가 AI 속도보다 먼저다

두 글감을 겹쳐놓으면 하나의 명제가 나온다. AI의 속도를 높이기 전에, 팀이 먼저 갚아야 할 부채가 있다.

Triple Debt Model이 진단이라면, 컨텍스트 파일 패밀리는 처방의 시작점이다. CLAUDE.md에 아키텍처 결정과 제약 조건을 기록하는 것은 의도 부채를 줄이는 가장 빠른 실행이다. PR 설명에 'what'이 아니라 'why'를 남기는 문화는 인지 부채 축적을 늦춘다.

AI-First 팀 리빌딩을 주도하는 입장에서 솔직하게 말하자면, 많은 팀이 에이전트 도입 순서를 거꾸로 잡는다. 컨텍스트 설계 없이 에이전트를 먼저 풀어놓으면, 속도는 잠깐 오르고 이해도는 천천히 무너진다. 그 무너짐은 화려한 사고가 아니라 '왜 이게 이렇게 됐지?'라는 질문이 늘어나는 방식으로 조용히 찾아온다.

전망: 부채 관리가 AI-First 팀의 핵심 역량이 된다

앞으로 AI 코딩 에이전트는 더 빨라진다. 생성 속도의 갭은 더 벌어질 것이다. 그 속도 안에서 살아남는 팀은 단순히 'AI를 잘 쓰는 팀'이 아니라 인지 부채와 의도 부채를 의식적으로 관리하는 팀이다.

CLAUDE.md 하나를 잘 쓰는 것, ADR(Architecture Decision Record)을 PR과 함께 남기는 것, 코드 리뷰에서 구현이 아니라 의도를 묻는 것—이 작은 습관들이 AI 속도가 팀 전체 속도로 이어지는지를 결정한다. 기술 부채는 나중에 리팩토링으로 갚을 수 있다. 팀의 이해가 무너진 시스템은 리팩토링 전에 먼저 해독이 필요하다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요