AI 기술 부채: 코드 부채와 인지 부채라는 두 가지 문제

AI로 생성된 코드가 문제라고 생각하는 것들의 절반은 사실 문제가 아니다. 중복된 함수나 일관성 없는 네이밍처럼 린터가 지적할 수 있는 것들이 아니기 때문이다. 나머지 절반은 풀 리퀘스트에서는 완벽해 보이고, 코드 리뷰를 통과하고, 배포되었다가 6주 후에야 나타난다. 그때쯤이면 팀의 누구도 왜 한 곳의 변경이 예상치 못한 세 곳을 깼는지 설명할 수 없다. 이게 바로 대부분의 팀이 측정하지 않는 부분이다.

AI 기술 부채는 하나가 아닌 두 가지 문제다

엔지니어링 매니저 다섯 명에게 AI 기술 부채가 뭐냐고 물으면 다섯 가지 답변을 얻는다. 하지만 대부분은 두 가지 카테고리로 나뉜다.

첫 번째는 코드 부채다: 중복, 일관성 없는 패턴, 기술적으로는 맞지만 아무도 원하지 않은 표면적 영역을 추가하는 코드다. 이건 정적 분석 도구가 처음부터 설계된 문제다.

두 번째는 인지 부채다: 코드가 생성되는 속도와 팀이 실제로 그 코드가 뭘 하는지에 대한 공유된 정신 모델을 구축하는 속도 간의 간극이다. Sonar의 2026년 개발자 설문조사에 따르면, 88%의 개발자가 AI로 인한 기술 부채의 부정적 영향을 최소 하나는 겪었고, 53%는 AI가 생성한 코드가 맞아 보이지만 숨겨진 결함을 도입한다고 했다. 이것이 코드 부채다. 그런데 이 설문조사가 완전히 포착하지 못하는 게 두 번째 종류고, LeadDev의 보도가 우리가 본 가장 명확한 설명이다.

다섯 팀 중 세 팀은 이 둘을 헷갈린다. 나머지 두 팀이 뭘 다르게 하는지 알아보자: 그들은 도구로 코드 부채를 추적하고, 대화로 인지 부채를 추적한다.

코드 부채: 맞아 보이지만 틀린 코드

코드 부채는 우리가 잘 아는 종류다. AI로 생성된 코드는 세 파일 떨어진 곳에 이미 있는 로직을 중복하는 경향이 있다. 왜냐하면 어시스턴트는 그 로직이 맥락에 없으면 존재하는지 모르기 때문이다. Sonar의 설문조사에 따르면, 40%의 개발자가 AI가 불필요하거나 중복된 코드를 생성해서 부채를 늘렸다고 말했다.

위험한 변종은 틀려 보이는 코드가 아니다. 맞아 보이는 코드다. 함수가 테스트를 통과하고, 행복한 경로를 깔끔하게 처리하며, 시니어 엔지니어가 쓴 것처럼 읽힌다. 단, 조용히 원래 구현이 처리했던 엣지 케이스를 놓친다. 리뷰는 오타를 잡는다. 리뷰는 그럴듯해 보이지만 미묘하게 불완전한 함수를 잡는 데는 훨씬 못하다.

// AI 생성: 테스트 통과, 깔끔해 보임
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// 원래 처리했던 것, 세 파일 떨어진 곳:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

여기서는 아무것도 에러를 던지지 않는다. CI에서 실패하는 것도 없다. 그 간격은 소프트 삭제된 사용자가 3주 후 리포트에서 다시 나타날 때만 드러난다. 그러면 페이저를 받은 누군가가 grep하고, blame하고, 다니며 물어봐야 어느 버전이 맞고 왜 그런지 알아낸다. 그 grep-and-ask 루프가 실제 비용이고, 그건 "뭔가 이상해" 같은 모호한 감각이 아니라 시간 단위로 측정된다.

레포 옆에 있고 별도의 위키에 있지 않은 Docs-as-code 도구는 함수 뒤의 추론이 함수 자체에서 한 클릭 떨어져 있고 누군가의 기억에 있지 않다는 뜻이므로, 이 루프가 얼마나 자주 일어나는지를 줄인다.

인지 부채: 팀이 방향을 잃을 때

빅토리아 대학교 컴퓨터 과학 교수 마가렛-앤 스토레이(Dr. Margaret-Anne Storey) 박사는 2025년 10월, 학생들이 AI로 빠르게 배포했다가 자신들의 사용자 피드백에 행동하는 데 어려움을 겪는 것을 지켜보며 "인지 부채"를 만들어낸 개념이다. 그녀의 진단: 학생들이 코드를 잃어버리지 않았고, 자신들이 뭘 만들고 있는지, 그리고 왜 그걸 만들고 있는지를 잃어버렸다. 그리고 팀에 누가 뭘 아는지를 잃어버렸다.

이 틀은 피터 나우르의 옛 주장을 빌려온다: 소프트웨어는 사실 코드가 아니라, 그걸 만든 사람들의 머릿속에 있는 공유된 이론이다. 코드가 팀이 그 이론을 구축할 수 있는 것보다 빠르게 생성되면, 이론은 절대 만들어지지 않는다. 깨끗하고 완전히 테스트된 코드베이스가 있어도, 그걸 배포한 사람들이 완전히 설명할 수 없거나, 단 한 명만 할 수 있으면, 린터가 뭐라고 말하든 상관없이 상당한 인지 부채가 있다.

이것이 표준 AI 기술 부채 메트릭이 완전히 놓치는 부분인데, 대시보드는 코드를 추적하고 이해는 추적하지 않기 때문이다. 다음 레트로에서 던질 만한 질문은 노골적하다: 아키텍처 다이어그램을 띄우고, 팀의 누가 각 박스를 설명할 수 있는지 물어봐라. 답이 "한 명, 그리고 그 사람은 이번 주에 휴가 중이다"라면, 린터가 뭐라고 말하든 인지 부채가 있다는 뜻이다.

살아있는 내부 위키는 인지 부채를 자체로 고치지 못한다. 그것은 팀이 그 "왜"를 한 명의 머릿속에서만 살기 전에 써내릴 장소를 제공한다. 그게 시작이다.

코드 리뷰가 생성 속도를 따라잡지 못하는 이유

여기서 두 가지 부채 밑에 깔려 있는 기계적 문제가 있다: AI는 단일 엔지니어가 점심 전에 일주일치 코드를 생성하게 해주지만, 리뷰 역량은 전혀 확장되지 않았다. 병목이 쓰기에서 읽기로 옮겨갔고, 읽기는 아무도 속도를 올리지 않은 부분이다.

이것이 도구 비교가 사실 중요해지는 곳이고, 모호한 말보다는 구체적으로 말할 가치가 있다. Copilot과 Cursor는 이미 열려 있는 파일 안에서 코드를 생성하는 데 빠르다. 그게 정확히 리뷰할 수 있는 것보다 더 많은 코드를 생성하는 데 좋은 이유다. Cody와 Continue.dev는 생성하기 전에 리포 전체에서 검색에 더 의존하는 경향이 있다. 이는 위의 중복 문제를 피하는 데 도움이 되지만, 새 코드가 시스템이 어떻게 작동해야 하는지에 맞는지 결정하는 인간의 단계를 어느 것도 대체하지 않는다. 어느 것도 PR을 병합하는 사람이 실제로 뭐가 바뀌었는지 이해하는지 말해주지 않는다. 그건 다른 질문이고, 차이는 문법적으로 괜찮은지와는 다르다.

Codebase 도구는 정확히 이 간극 때문에 존재한다: AI로 생성된 코드를 잘 리뷰하는 가장 빠른 방법은 평문으로 "이 패턴이 다른 어디에 있나" 또는 "이미 이 케이스를 처리하는 게 뭐가 있나"라고 물을 수 있는 것이다. 그 질문은 예전에 시니어 엔지니어에게 grep과 blame으로 20분 걸렸다. 그럴 필요는 없다.

리포 크기 효과도 이름 붙일 가치가 있다. 5,000줄 서비스에서는 한 리뷰어가 시스템의 대부분을 머릿속에 들고 있을 수 있으니, 그럴듯해 보이는 함수가 튀어나온다. 리뷰어의 정신 모델과 안 맞거든. 80,000줄 모노레포에 여섯 팀이 손을 댔으면, 단일 리뷰어가 이제 그 정신 모델을 더는 가질 수 없다. 그럴듯한 코드가 단순히 방에 있는 누구도 그게 틀렸다는 걸 알 맥락이 없어서 통과된다. 리포가 클수록, 리뷰 병목이 한 시니어 엔지니어의 기억보다는 도구에 더 의존한다.

주니어가 이 부채를 가장 먼저, 가장 빠르게 지불한다

Anthropic은 2026년 1월, 52명의 주니어 개발자가 참여한 무작위 대조 시험을 했고, AI 어시스턴트를 쓴 사람들이 코드 이해도 테스트에서 17% 더 낮은 점수를 얻었다는 걸 알았다. 대략 두 학점 떨어진다. Infobip의 인턴십 프로그램은 2022년 이후 225명의 인턴을 추적하며, 실제 종단 자료에서 같은 패턴을 봤다: AI 이전 코호트는 인턴십 동안 자체 평가 기술 스킬에서 평균 2.50포인트 성장; AI 시대 코호트는 1.56.

메커니즘은 AI 사용 자체가 아니다. Infobip의 가장 최근 코호트에서 두 인턴이 같은 빈도로 AI를 썼는데, 정반대 결과였다. 한 명은 추적 질문을 했고 AI가 만든 것을 완전히 설명할 수 있었다. 그들의 성장은 코호트에서 가장 높았다. 다른 한 명은 최소한의 리뷰로 출력을 받아들였고, 그걸 블랙박스처럼 다뤘고, 0으로 성장했다. 도구는 동일했다. 그것과의 관계는 그렇지 않았다.

페어링 세션과 아키텍처 워크스루를 녹음하고 나중에 검색 가능하게 만드는 것은 주니어들에게 누가 자유로운지에 다시 물어보는 대신 돌아갈 무언가를 제공한다. 멘토를 대체하진 못하지만, 두 번째 질문의 비용을 낮춘다.

"주니어를 위해 AI를 금지하라"는 해결책은 건너뛰어라

이 주제에 대한 모든 정리는 결국 같은 추천에 빠진다: 주니어 엔지니어의 AI 접근을 "벌었을" 때까지 제한하라. 그 추천은 건너뛰자. 그것은 문제를 실제로 측정한 팀들이 알아낸 것과 일치하지 않고, 한 실패 모드를 다른 것으로 바꾼다. 자기 팀이 배포하는 도구를 못 쓰는 주니어는 같은 정도로 현실적인 다른 방식으로 뒤떨어진다.

Infobip에서 일한 것은 금지가 아니라 시퀀싱이었다: 문제를 먼저 시도하고, 두 번째로 AI를 확인해라. 독립적인 사고의 습관이 AI가 기본 움직임이 되기 전에 형성되게 해야 한다. 그들은 벌칙이 아니라 보정으로서 AI 없는 체크포인트를 추가했다. 그래서 인턴과 멘토 둘 다 스킬이 실제로 어디에 서 있는지 안다. 멘토들은 풀 리퀘스트 리뷰를 추적하는 것에서 프로세스 추적으로 이동했다: 누가 뭘 물었는지, 누가 어디서 막혔는지, 누가 도움 없이 자신의 변경을 설명했는지.

만족도 점수는 내내 올라갔는데, 스킬 성장은 떨어졌다. 이게 그들 자료의 진짜 경고다: 도구에 대해 사람들이 어떻게 느끼는지만 추적하면, 이 게 올 걸 못 본다. Infobip의 가장 최근 코호트 중 20%는 주니어 엔지니어가 자신들 수준에서 기대하는 게 뭔지 몰랐고, 그게 자체 평가를 측정하기 위해 설정한 참조 포인트 없이는 거의 무의미했다. 아무도 써내려지지 않은 참조 포인트에 대한 간격은 측정할 수 없다.

이번 스프린트에서 우리가 실제로 바꿀 것

위의 레트로 질문으로 시작하자: 지금 이 순간에 누가 시스템 각 부분을 설명할 수 있는가. 그 단일 질문은 어떤 대시보드보다도 10분 안에 더 많은 인지 부채를 표면화한다.

코드 부채는 정적 분석을 계속 루프에 둬야 한다. Sonar의 2026 개발자 설문조사는 70%의 개발자가 이미 그걸 쓴다고 보여주고, 그걸 실행하는 팀은 그걸 건너뛰는 팀보다 재작업 비용에 훨씬 더 나은 결과를 보고한다. 그건 논쟁의 여지가 없는 추천이고, 단순히 팀이 빠르게 움직일 때 AI 출력이 완료돼 보여서 건너뛰는 팀들이 있을 따름이다.

AI가 코드 쓰기에서 제거하는 고생은 사라지지 않는다. Sonar는 이걸 "큰 고생 이동"이라고 부른다: 그것은 다운스트림에서 다시 나타난다. 부채 관리와 AI 출력 수정에서. 그 트리아주의 반복 부분을 자동화하는 것, 오래된 PR에 플래그를 기고, 리뷰 요청을 라우팅하고, 후속을 쫓는 것은 시니어 시간을 실제로 인간을 필요로 하는 부분으로 해방시킨다: 팀이 방금 배포한 것을 이해하는지 결정한다.

궤적을 측정하자, 만족도는 아니다. AI에 대해 기분이 좋고 6개월에 자신들의 아키텍처를 설명할 수 없는 팀은 시간을 절약한 게 아니다. 그것은 시간을 빌렸고, 금리는 아무도 써내려지지 않았다.