인지적 부채(Cognitive Debt): 아무도 측정하고 싶어 하지 않는 AI 코드 스멜

Thoughtworks는 최신 Technology Radar에서 "인지적 부채 (cognitive debt)"를 지적했으며, 저는 이 문구가 짜증 날 정도로 정확하게 시대의 흐름을 반영할 것이라고 생각합니다. 단순히 귀여운 새로운 라벨이기 때문이 아닙니다. 우리는 이미 충분히 많은 귀여운 라벨들을 가지고 있습니다. 이 용어가 중요한 이유는 많은 팀이 AI 보조 개발 (AI-assisted development)을 통해 조용히 느끼고 있는 현상을 명명하기 때문입니다. 바로 코드베이스 (codebase)가 팀의 이해도보다 더 빠르게 성장하고 있다는 사실입니다. 이것이 불편한 지점입니다. AI 도구들은 팀이 더 많은 코드를 배포할 수 있게 해줍니다. 때로는 훨씬 더 많은 코드를 말이죠. AI는 테스트 초안을 작성하고, 보일러플레이트 (boilerplate)를 채우며, API를 연결하고, 오래된 모듈을 변환하며, 마이그레이션 계획을 생성하고, 오후 5시에 아무도 하고 싶어 하지 않는 지루한 첫 번째 작업을 수행할 수 있습니다. 저도 이 도구들을 사용합니다. 저는 이 도구들을 좋아합니다. 하지만 AI 보조 개발의 어떤 버전은 저장소 (repo)가 기술적으로는 작동하지만, 설명할 수 있는 인간이 점점 줄어드는 코드로 가득 차게 만듭니다. 그것은 생산성이 아닙니다. 그것은 병목 현상 (bottleneck)을 타이핑에서 이해 (comprehension)로 옮기는 것뿐입니다. 그리고 이해야말로 소프트웨어가 실제로 존재하는 지점입니다.

기술적 부채 (technical debt)는 결코 지저분한 코드에 대해서만 논의된 것이 아니었습니다. 사람들이 기술적 부채를 이야기할 때, 보통 눈에 보이는 추함(ugliness)을 지적합니다. 이상한 헬퍼 함수 (helper function), 7개의 플래그가 있는 엔드포인트 (endpoint), 하나의 동작을 바꾸기 위해 세 번의 배포가 필요한 서비스 같은 것들 말이죠. 그러한 부채는 실재합니다. 하지만 더 비용이 많이 드는 부채는 인지적 (cognitive) 부채입니다. 즉, 시스템이 수행하는 일과 팀이 추론할 수 있는 능력 사이의 간극입니다. 간단한 변경을 위해 시니어 엔지니어 세 명이 회의에 참석해야 할 때, 왜냐하면 아무도 로컬 코드 경로를 신뢰하지 않기 때문일 때 여러분은 이를 느낍니다. 모든 사람이 특정 모듈이 중요하다고 동의하지만, "그것을 이해했던 마지막 사람이 떠났다"는 이유로 아무도 건드리고 싶어 하지 않을 때 여러분은 이를 느낍니다. AI는 그러한 상황을 더 빠르게 만들 수 있습니다. 생성된 코드가 항상 나쁘기 때문이 아닙니다. 때로는 깔끔하고, 지루하며, 유용하기도 합니다. 위험 요소는 AI가 팀의 멘탈 모델 (mental model)을 구축하는 능력을 앞지르는 속도로 코드를 생성할 수 있다는 점입니다. 여러분은 더 많은 파일, 추상화 (abstractions), 엣지 케이스 (edge cases), 테스트, 통합 지점 (integration points), 그리고 이 모든 것을 둘러싼 확신을 주는 텍스트를 얻게 됩니다. 저장소는 팀이 느끼는 상태보다 더 건강해 보일 것입니다. 그 간극이 바로 인지적 부채 (cognitive debt)입니다.

위험한 문구는 바로 "작동한다(it works)"입니다. "작동한다"는 문구는 스파이크 (spike) 단계에서는 유용한 문장입니다. 하지만 리뷰 (review) 단계에서는 위험한 문장입니다. AI 어시스턴트 (AI assistant)가 변경 사항을 생성할 때, 가장 먼저 드는 유혹은 결과물을 확인하고 바로 다음 단계로 넘어가는 것입니다. 테스트는 통과합니다. API는 올바른 형태를 반환합니다. 배포는 성공(green) 상태입니다. 좋습니다. 하지만 소프트웨어 팀은 결과물만을 고립된 상태로 유지하지 않습니다. 그들은 의사결정 (decisions)을 유지합니다. 왜 여기서 이 캐시 (cache)가 무효화됩니까? 왜 트랜잭션 경계 (transaction boundary) 이전에 이 재시도 (retry)가 발생합니까? 왜 이 필드는 API에서는 선택 사항(optional)이지만 데이터베이스에서는 필수 사항(required)입니까? 왜 명백한 경로 대신 이 마이그레이션 (migration) 경로를 선택했습니까? 만약 아무도 모른다면, 팀은 논리적 근거에 대한 소유권 (ownership)을 받아들이지 않은 채 코드만을 수용한 것입니다. AI가 생성한 코드는 시스템을 약화시키면서도 리뷰를 통과할 수 있는데, 이는 코드 리뷰 (code review)가 이해의 전달 (transfer of understanding)보다는 정확성 (correctness)을 더 많이 확인하는 경우가 많기 때문입니다. 우리는 버그, 스타일 문제, 보안 리스크, 그리고 테스트 커버리지 (test coverage)를 찾습니다. 그것들도 중요합니다. 하지만 우리는 리뷰어가 도구가 사라진 후에도 그 변경 사항을 설명할 수 있는지도 물어야 합니다. 만약 대답이 '아니오'라면

그렇지 않다면 코드베이스는 서서히 고아(orphaned)가 된 선택지들로 채워지게 됩니다. 테스트는 단순히 커버리지 (coverage)를 높이는 것이 아니라 의도 (intent)를 인코딩해야 합니다. AI는 테스트의 개수를 늘리는 데는 꽤 능숙합니다. 하지만 그것은 신뢰도 (confidence)를 높이는 것과는 다른 문제입니다. AI 중심의 코드베이스에서 제가 원하는 테스트는 의도를 잃어버리기 어렵게 만드는 테스트입니다. returns_400_for_invalid_input이라는 이름의 테스트는 괜찮지만, 그다지 풍부하지는 않습니다. 반면 does_not_recalculate_settled_interest_after_statement_close라고 명시된 테스트는 비즈니스 규칙 (business rule)을 담고 있습니다. 이것이 중요한 이유는 인지적 부채 (cognitive debt)가 코드는 여전히 로컬에서 작동하지만 그 의미가 표류할 때 자주 나타나기 때문입니다. 생성된 테스트는 아무도 신경 쓰지 않는 구현 세부 사항 (implementation details)을 고착화할 수 있으며, 새로운 코드가 위반하기 전까지는 모두가 당연하다고 가정하는 기묘한 도메인 규칙 (domain rule)을 놓칠 수 있습니다. 우리의 역할은 다음과 같이 질문하는 것입니다: '미래의 유지보수자가 이 동작을 안전하게 변경하기 위해 무엇을 알아야 하는가?' 그런 다음 그것을 실행 가능한 압력 (executable pressure)으로 기록하십시오.

프롬프트 형태의 차이 (prompt-shaped diff)를 검토하십시오. 제가 좋아하는 실용적인 습관 중 하나는 AI의 도움을 받은 코드를 '프롬프트 형태의 차이 (prompt-shaped diff)'로 검토하는 것입니다. 단순히

그것은 "에이전트를 활용하는 10배 개발자"라는 말보다는 덜 흥미롭게 들릴지 모르지만, 실제 업무에는 훨씬 더 가깝습니다. 시니어 엔지니어는 어떤 제약 사항이 실질적인지, 어떤 지름길이 허용 가능한지, 그리고 어떤 아름다운 리팩터링(refactoring)이 다음 분기를 비참하게 만들지를 알고 있습니다. AI는 이러한 판단을 덜 중요하게 만드는 것이 아니라, 오히려 더 중요하게 만듭니다. 만약 당신의 가치가 주로 상용구 코드(boilerplate)를 생성하는 데 있었다면, 도구들이 그 자리를 대체하러 올 것입니다. 만약 당신의 가치가 시스템을 안전하게 변경할 수 있을 만큼 깊이 이해하는 데 있다면, 도구들은 당신을 더 강력하게 만들 수 있습니다. 하지만 이는 당신이 수동적인 머지(merge) 버튼이 되기를 거부할 때만 가능합니다. 제가 아는 최고의 엔지니어들은 AI를 '운영 환경에 대한 기억이 없는, 빠르지만 주니어급인 엔지니어'처럼 사용합니다. 도움이 되고 때로는 천재적이지만, 혼자서 아키텍처(architecture)를 재정의하도록 내버려 두어서는 안 되는 존재 말입니다.

내가 측정할 것들

만약 한 팀이 인지적 부채(cognitive debt)를 피하는 데 진지하다면, 저는 거창한 정책부터 시작하지 않을 것입니다. 대신 몇 가지 지루한 신호들부터 시작할 것입니다:

• 리뷰어가 단순히 코드 변경 사항뿐만 아니라 그 근거(rationale)를 얼마나 자주 요구하는가?
• AI의 도움을 받은 PR(Pull Request) 중 설명(description)에 트레이드오프(tradeoff)를 포함하는 경우가 얼마나 되는가?
• 생성된 테스트가 구현 세부 사항(implementation details) 대신 비즈니스 규칙(business rules)을 인코딩하는 빈도는 어느 정도인가?
• 안전하게 설명할 수 있는 사람이 단 한 명뿐인 모듈이 몇 개인가?
• 아무도 엣지 케이스(edge case)를 이해하지 못해 팀이 코드를 되돌리는(revert) 일이 얼마나 자주 발생하는가?
• "작게 생성된 변경 사항"이 숨겨진 경계를 침범했다는 사실이 장애(incident)를 통해 드러나는 빈도는 어느 정도인가?

이 중 완벽한 것은 없습니다. 측정은 금방 우스꽝스러워질 수 있습니다. 하지만 측정이 없다는 것은 당신이 보는 것이 오직 출력값(output)뿐임을 의미합니다: PR 개수, 라인 수, 티켓 처리량(throughput), 사이클 타임(cycle time). 이러한 지표들은 이해도(comprehension)가 나빠지는 와중에도 모두 개선될 수 있습니다.

실용적인 규칙

저의 규칙은 간단합니다: AI는 초안을 작성할 수 있지만, 최종적인 멘탈 모델(mental model)은 팀이 소유해야 합니다. 이는 생성된 코드가 이를 유지 관리할 수 있도록 충분한 '인간 형태의 컨텍스트(human-shaped context)'와 함께 제공되어야 함을 의미합니다.

• 왜 이런 설계가 필요한가?
• 어떤 불변량(invariant)이 중요한가?
• 나중에 무엇을 "정리(cleaned up)"해서는 안 되는가?
• 어떤 테스트가 의도(intent)를 포착하는가?
• 도구가 확신을 가지고 틀렸을 경우 어떤 롤백(rollback) 수단이 존재하는가?

이것이 모든 과정을 느리게 만들 필요는 없습니다.

종종 그것은 몇 줄의 PR(Pull Request) 문구와 더 나은 테스트 이름 하나일 뿐입니다. 하지만 그것은 태도를 변화시킵니다. 당신은 더 이상 "모델이 작동하는 코드를 생성할 수 있는가?"라고 묻지 않습니다. 대신 "이것을 수락한 후에도 우리 팀이 여전히 시스템을 이해할 수 있는가?"라고 묻게 됩니다. 그것이 바로 계속해서 간직할 가치가 있는 질문입니다. AI 보조 개발 (AI-assisted development)은 계속해서 빨라질 것입니다. 코드는 계속 쏟아져 나올 것입니다. 데모는 계속 마법처럼 보일 것입니다. 가격 페이지는 엔지니어 한 명당 더 많은 산출물을 약속할 것입니다. 좋습니다. 다만 코드베이스 (codebase) 그 자체는 자산이 아니라는 점을 기억하십시오. 자산은 코드베이스와 그것을 추론할 수 있는 팀의 능력의 결합입니다. 이 두 가지가 서로 멀어질 때, 당신은 더 빨리 나아가고 있는 것이 아닙니다. 당신은 미래로부터 이해력을 빌려오고 있는 것입니다. 그리고 미래는 언제나 청구서를 보냅니다. references Thoughtworks Technology Radar Vol. 34: combat AI cognitive debt Thoughtworks Technology Radar Vol. 34 PDF Thoughtworks macro trends in the tech industry, April 2026