문제는 AI의 실력이 아니라 팀의 소화력이다
AI 코딩 도구의 품질 논쟁은 이미 끝났다. Claude Code, GitHub Copilot, Cursor—어느 것을 써도 빈 파일을 채우는 능력은 충분하다. 진짜 병목은 다운스트림으로 이동했다. 2025년 DORA 리포트가 이를 정확하게 짚는다. AI 도입 후 개인 산출물은 늘었다—PR 병합 수 98% 증가, 완료 태스크 21% 상승. 그런데 조직 단위 딜리버리 지표는 제자리였다. PR 리뷰 시간이 91% 늘었고, PR 크기는 154% 커졌다. 코드는 더 많이 들어오는데 리뷰 용량은 그대로다.
'인지 부채'는 기술 부채보다 훨씬 조용하고 훨씬 위험하다
기술 부채는 적어도 눈에 보인다. 지저분하지만 작동하는 코드—팀이 인지하고 계획을 세울 수 있다. 인지 부채(cognitive debt)는 다르다. 코드는 작동하는데 팀 안에 그것을 안전하게 수정할 수 있는 사람이 없는 상태다. MIT 미디어랩 연구를 바탕으로 Margaret-Anne Storey가 정의하고, Simon Willison이 자신의 경험으로 확장한 이 개념은 dev.to의 Max Mendes가 쓴 글에서 핵심 프레임으로 등장한다. Anthropic이 엔지니어 52명을 대상으로 진행한 연구도 같은 방향을 가리킨다. AI 보조 코딩을 사용한 개발자의 코드 이해도 점수는 그렇지 않은 그룹보다 17% 낮았고(50% vs 67%), 특히 디버깅 영역에서 낙폭이 컸다. 코드는 배포됐지만 이해는 배포되지 않은 것이다.
더 불편한 수치도 있다. METR의 무작위 대조 실험에서 숙련된 오픈소스 개발자들은 AI 도구를 쓰면서 실제로 19% 느려졌지만, 본인들은 20% 빨라졌다고 느꼈다. 39포인트짜리 인식 격차다. 생산적이라는 느낌과 실제 속도가 반대로 움직이는 이 구간이야말로 인지 부채가 가장 빠르게 쌓이는 지점이다.
TDD로 AI에게 '한 입 크기'만 주는 법
인지 부채의 근본 원인은 간단하다. AI가 사람이 읽을 수 있는 속도보다 빠르게 코드를 생성한다는 것. 해결 방향도 그만큼 직관적이다—생성 단위를 작게 쪼개라. Walt Disney Company, FIFA, Verizon 등 50명 이상 규모 팀의 개발자들에게 발표해 검증된 방법론을 소개한 dev.to의 Ivan Jijon은 TDD를 AI 협업의 구조적 프레임으로 쓴다. 핵심은 단순하다. AI에게 기능 전체를 맡기는 대신, 실패하는 테스트 하나를 쓰게 하고, 그것을 통과할 최소 코드만 생성하게 하고, 그 다음 리팩터링 여부를 인간이 판단한다. Red-Green-Refactor 사이클 하나가 끝날 때마다 팀원은 그 코드를 완전히 이해한 상태로 다음 단계로 넘어간다.
이 방식이 실제로 작동하려면 AI에게 '규칙 파일'을 줘야 한다. Ivan은 TDD_GUIDELINES.md를 매 세션 시작 시 AI에게 주입한다. "한 번에 테스트 하나만 작성", "현재 테스트가 요구하는 최소 코드만 구현", "추상화는 명시적 요청 없이 도입 금지", "설계 결정의 오너십은 항상 인간에게"—이 규칙들은 이론이 아니라 실제 마찰 지점에서 하나씩 추가된 것들이다. PROJECT_DESCRIPTION.md, ARCHITECTURE.md, SESSION_HANDOFF.md로 구성한 컨텍스트 파일 시스템은 세션 간 기억을 잃는 AI의 한계를 보완한다. 결과는 측정 가능했다. PR은 작아지고 명확해졌으며, 리뷰 속도가 빨라졌고, 개발자들은 다시 자신의 코드를 설명할 수 있게 됐다.
코드 스타일의 '지문'을 지우는 린터, 그게 진짜 문제인가
세 번째 흐름은 다소 결이 다르다. dev.to에 공개된 papertowel은 AI 생성 코드의 스타일 지문—'robust', 'utilize', 'leverage' 같은 슬롭 어휘, 코드를 그대로 반복하는 과잉 주석, 쿠키커터 README 구조—을 탐지하고 제거하는 린터다. 오픈소스 커뮤니티 일부에서 AI 작성 코드를 작동 여부와 무관하게 거부하는 문화에 대한 반응으로 만들어진 도구다. 제작자 스스로 "AI로 AI 지문 제거 도구를 만든 아이러니"를 인정하면서, 핵심 주장을 명확히 한다. '누가 첫 번째 초안을 썼느냐'가 아니라 '코드를 이해하고 검증했느냐'가 품질의 기준이 되어야 한다.
테크 리드로서 이 도구를 보는 시각은 복잡하다. 커뮤니티의 AI 혐오 문화에 반응하는 것은 이해하지만, 지문을 지우는 것 자체가 인지 부채 문제를 해결하지는 않는다. AI 냄새가 나지 않는 코드라도 팀이 이해하지 못하면 여전히 인지 부채다. 다만 이 도구가 가리키는 방향—코드 리뷰가 생산 방식의 프로브너스가 아니라 이해도와 품질에 집중해야 한다는 것—은 옳다.
AI-First 팀에서 인지 부채를 설계로 막는 세 가지 전략
세 기사가 동시에 가리키는 것은 하나다. AI가 생성하는 속도와 팀이 소화하는 속도 사이의 갭을 워크플로우 설계로 좁혀야 한다는 것. 지금 당장 팀에 적용할 수 있는 접근을 정리하면 이렇다.
첫째, 생성 단위를 작게 유지하라. 기능 단위가 아니라 함수 단위, 테스트 단위로 AI에게 요청하라. GitClear가 2020~2024년 2억 1,100만 줄의 코드를 분석한 결과, AI 도구 확산 이후 코드 중복이 8배 증가하고 리팩터링이 40% 감소했다. 큰 배치로 작업할수록 이 패턴이 심화된다.
둘째, 리뷰 기준을 '작동 여부'에서 '설명 가능 여부'로 바꿔라. 팀원이 PR의 모든 줄을 동료에게 설명할 수 없다면 머지하지 않는다는 원칙을 명시적으로 설정하라. CodeRabbit의 470개 PR 분석에서 AI 생성 코드는 보안 취약점이 2.74배, 가독성 문제가 3배 높았다. 작동하는 코드와 검토된 코드는 다르다.
셋째, 가이드라인 파일을 팀 레벨로 올려라. 개인 프롬프트 전략을 팀 공유 문서로 만들어라. TDD 사이클, 네이밍 컨벤션, 추상화 도입 기준, 코드 오너십 원칙—이것들을 AI에게 매 세션 주입하는 컨텍스트 파일로 표준화하면 개인 워크플로우가 팀 품질로 확장된다.
지금 설계하지 않으면 6개월 뒤 디버깅으로 갚는다
AI 코딩 도구는 속도를 빌려주는 도구다. 미래의 자신에게서 이해를 빌리는 것이 아니라, 지금 생성하고 지금 이해하는 루프를 유지할 때만 그 속도가 진짜 생산성이 된다. Max Mendes의 표현이 정확하다. "AI로 노력을 압축하되, 이해를 외주화하지 마라." 팀이 코드를 소화하는 속도보다 AI가 코드를 생성하는 속도가 빠른 상태를 허용하는 것—그것이 AI-First 팀이 지금 빠질 수 있는 가장 조용한 함정이다.