마틴 파울러가 말하는 세 가지 빚: 기술 부채, 인지 부채, 그리고 의도 부채

파울러가 왜 또 부채 이야기를 꺼냈을까

소프트웨어 개발을 조금이라도 해본 분이라면 '기술 부채(Technical Debt)'라는 말은 한 번쯤 들어봤을 거예요. 워드 커닝햄이 처음 만든 이 비유는 "지금 당장 빠르게 짜느라 대충 넘어간 코드는 나중에 이자까지 쳐서 갚아야 한다"는 뜻이거든요. 그런데 이번에 마틴 파울러가 자신의 블로그에 올린 글에서 이 개념을 한 걸음 더 밀고 나갔어요. 기술 부채 하나로는 요즘 개발 현장에서 벌어지는 일들을 다 설명할 수 없다는 거예요.

특히 LLM(거대 언어 모델, 쉽게 말해 ChatGPT 같은 AI)과 코딩 에이전트가 코드를 쏟아내기 시작하면서, '부채'의 모양이 달라지고 있다는 게 파울러의 진단이에요. 예전에는 사람이 급하게 짜서 생긴 빚이었다면, 이제는 AI가 빠르게 생성한 코드가 전혀 다른 종류의 빚을 만들고 있다는 거죠. 그래서 파울러는 두 가지 새로운 개념을 추가로 꺼냈어요. 바로 인지 부채(Cognitive Debt)와 의도 부채(Intent Debt)입니다.

기술 부채, 인지 부채, 의도 부채가 각각 뭔데요

먼저 기술 부채는 우리가 흔히 아는 그거예요. 설계가 엉성하거나, 테스트가 부족하거나, 중복된 코드가 여기저기 박혀 있어서 변경하기 어려운 상태. 눈에 보이고, 리팩터링 같은 기술적 활동으로 갚을 수 있어요.

그다음 인지 부채는 좀 다른 이야기예요. 코드를 읽고 이해하는 '사람의 머릿속' 관점에서 쌓이는 빚이거든요. 예를 들어 AI가 아주 복잡하지만 겉보기엔 잘 돌아가는 코드를 짜줬다고 해봐요. 테스트도 통과하고, 기능도 작동해요. 그런데 팀 누구도 그 코드가 '왜 그렇게' 짜여졌는지 깊이 이해하지 못한 상태라면? 지금은 문제없어 보여도, 나중에 버그가 터지거나 기능을 고쳐야 할 때 아무도 손을 못 대는 상황이 와요. 이게 바로 인지 부채예요. 코드는 멀쩡한데, 그 코드에 대한 '이해'가 팀에 쌓이지 않은 상태.

마지막으로 의도 부채는 더 근본적인 문제예요. "우리가 왜 이런 결정을 내렸지?"에 답을 못 하는 상황이거든요. 예전엔 개발자가 한 줄 한 줄 짜면서 자연스럽게 '왜 이렇게 했는지'가 커밋 로그나 PR 코멘트, 회의록 같은 곳에 남았어요. 그런데 AI가 대량의 코드를 생성하기 시작하면, 프롬프트 하나로 만들어진 수백 줄의 코드 뒤에 숨은 의도가 사라져버려요. 나중에 "이거 왜 이렇게 만든 거야?"라고 물어봐도 아무도 답을 못 해요. 그게 의도 부채의 무서움이에요.

왜 이 구분이 중요한가

파울러가 굳이 세 가지로 나눈 이유는, 각각 해결 방법이 완전히 다르기 때문이에요. 기술 부채는 리팩터링과 테스트로 갚을 수 있어요. 도구도 많고 방법론도 성숙해 있죠. 그런데 인지 부채는 코드를 고친다고 사라지지 않아요. 팀 전체가 그 코드를 함께 읽고, 페어 프로그래밍을 하고, 문서화를 하고, 설명을 나누는 시간을 가져야 줄어들어요. 시간과 대화가 필요한 빚인 거예요.

의도 부채는 더 까다로워요. 한 번 사라진 '왜'는 복구가 어렵거든요. 그래서 파울러는 AI 에이전트를 쓸 때 프롬프트와 의사결정의 맥락을 같이 기록하는 문화가 중요해진다고 말해요. 단순히 "이 코드를 AI가 짰다"가 아니라, "왜 이 요구사항을 이런 방식으로 풀기로 했는지"를 사람이 남겨둬야 한다는 거죠.

업계에서 비슷한 고민들

사실 이런 고민은 파울러만 하는 게 아니에요. 애디 오스마니는 '바이브 코딩(vibe coding, AI한테 대충 느낌만 말해서 코드 받는 방식)'이 유행하면서 생기는 문제들을 여러 번 지적했고, DHH도 AI 생성 코드를 팀이 소화하지 못하면 장기적으로 독이 된다고 경고한 적 있어요. 깃허브도 최근 Copilot 사용 팀들에서 "생산성은 올라갔지만 코드 리뷰 시간과 온보딩 시간은 더 길어졌다"는 내부 데이터를 공유하기도 했고요.

즉, 업계 전반적으로 AI가 빠르게 만든 코드의 '사후 비용'을 어떻게 관리할 것인가가 새로운 화두로 떠오르고 있는 거예요. 파울러의 세 가지 부채 프레임은 이 논의에 이름표를 달아준 셈이죠.

한국 개발자에게 주는 시사점

요즘 한국 스타트업이나 대기업 개발팀에서도 커서(Cursor), 클로드 코드, 코파일럿을 적극 도입하고 있잖아요. 생산성은 분명 올라가요. 그런데 3개월쯤 지나고 나면 "이 모듈 누가 짰지? 왜 이렇게 짰지?"라는 질문에 답을 못 하는 경우가 슬슬 생겨요. 이게 바로 파울러가 말한 인지 부채, 의도 부채가 쌓이는 순간이에요.

당장 실무에서 해볼 수 있는 건 몇 가지가 있어요. 첫째, AI가 생성한 코드를 머지하기 전에 "내가 이 코드를 설명할 수 있는가" 를 체크리스트에 넣어보세요. 둘째, PR 설명에 "어떤 프롬프트로, 어떤 맥락에서 만들었는지"를 같이 적는 문화를 시도해볼 수 있어요. 셋째, 팀 내 코드 리딩 세션을 의식적으로 늘려서 인지 부채를 줄이는 거예요. 기술 부채 잡는 데 쓰던 시간의 일부를 '이해 공유'에 써야 하는 시대가 온 거죠.