기술 부채, 인지 부채, 의도 부채 뜻과 차이 정리

다음 세 가지는 내가 AI로 만든 프로젝트를 두고 스스로에게 던져 보는 질문입니다. 가장 최근에 AI로 마무리한 일 하나를 떠올리면 답하기 쉽습니다.

이 결과물을 지금 고쳐야 한다면, 어디를 건드려야 하는지 바로 말할 수 있나요?
이 결과물이 왜 이렇게 동작하는지, 다른 사람에게 5분 안에 설명할 수 있나요?
왜 다른 방식이 아니라 이 방식으로 정했는지가 어딘가에 적혀 있나요?

세 질문은 비슷해 보이지만 서로 다른 것을 묻고 있습니다. 어느 질문에서 답이 막히는지에 따라, 내가 그동안 느끼면서도 말로 표현하지 못했던 그 문제가 무엇인지도 달라집니다. 어떤 질문이 어떤 문제를 가리키는지는 글 뒷부분에서 풀어 보겠습니다. 그보다 먼저, 요즘 자주 보이는 장면 하나를 이야기하겠습니다.

AI에게 일을 시키면 결과물이 나옵니다. 코드도, 문서도, 기획안도 예전보다 빨리 손에 들어옵니다. 그런데 결과물을 얻는 속도가 빨라진 만큼 일도 편해졌는지 되짚어 보면, 선뜻 그렇다고 답하기 어렵습니다. 분명히 동작하는 코드인데 왜 그렇게 짰는지 설명하지 못하고, 이미 통과된 기획안인데 왜 그 방향으로 정했는지 아무도 기억하지 못하는 일이 생기기 때문입니다.

소프트웨어 공학에서는 이런 현상을 오래전부터 부채로 설명해 왔습니다. 지금 빨리 가려고 빌려 쓴 시간에 나중에 이자가 붙는다는 뜻입니다. 그런데 최근 논의에서는 그 부채가 한 종류가 아니라 세 종류로 나뉩니다. 기술 부채, 인지 부채, 의도 부채입니다. 이 글에서는 세 가지가 각각 어디에 쌓이는지, 왜 AI를 쓸수록 뒤의 두 가지가 커지는지, 그리고 무엇을 기억해야 하는지 정리합니다.

기술 부채, 인지 부채, 의도 부채의 관계를 보여주는 Triple Debt Model 도식. 세 부채가 서로를 키우거나 고치며 AI가 그 속도를 높인다는 구조

위 그림은 2026년 발표된 논문 「From Technical Debt to Cognitive and Intent Debt」에 실린 도식입니다. 세 부채가 각각 소프트웨어, 사람, 기록에 자리 잡는다고 표시하고, 서로를 키우기도 하고 고치기도 하는 관계로 이어 놓았습니다. 가운데에는 AI가 그 속도를 높인다고 적혀 있습니다.

기술 부채라는 말은 어디서 왔을까요?

기술 부채는 세 가지 가운데 가장 익숙한 개념입니다. 1992년 워드 커닝햄이 처음 쓴 비유로, 일단 돌아가게만 만들어 둔 코드를 나중에 정리하지 않으면 이자가 붙는다는 뜻입니다. 커닝햄은 서둘러 내보낸 코드를 빚에 견주면서, 조금 빌리는 것은 개발을 빠르게 해 주지만 갚지 않고 두는 순간부터 문제가 시작된다고 했습니다.

기술 부채가 쌓인 코드는 고치기 어렵습니다. 기능 하나를 바꾸려는데 관련 없어 보이는 곳이 같이 깨지고, 손대기 무서운 파일이 생깁니다. 다행인 점은 이 부채가 눈에 보인다는 것입니다. 코드는 저장소에 남아 있고, 정적 분석 도구로 측정할 수 있고, 리팩터링과 테스트라는 검증된 대응 방법이 있습니다. 최근에는 AI가 리팩터링과 테스트 작성을 도우면서 기술 부채를 줄이는 데 쓰이기도 합니다.

그런데 코드가 깨끗한데도 팀이 곤란해지는 경우가 있습니다. 나머지 두 부채는 바로 그 자리에서 드러납니다.

인지 부채는 무엇이 다를까요?

인지 부채라는 말은 기술 부채에 비하면 낯설 수 있습니다. 쉽게 말하면 코드가 아니라 사람에게 쌓이는 빚입니다. 팀이 그 시스템을 이해하는 정도가 서서히 줄어드는 상태를 가리킵니다.

앞서 언급한 논문은 인지 부채를 "팀이 함께 쌓아 온 시스템 이해가 시간이 지나면서 깎여 나가는 상태"로 정의합니다. 개인이 잠깐 헷갈리는 수준의 문제가 아니라, 팀 전체에 모르는 부분이 쌓여 가는 상태라는 점이 핵심입니다.

AI를 쓰기 시작하면서 이 과정이 달라졌습니다. 사람이 코드를 직접 쓰면, 결과물이 지저분하더라도 그 과정에서 머릿속에 코드의 그림이 어느 정도 그려집니다. 막히고 고치는 과정 자체가 이해를 남깁니다. 그런데 같은 코드를 AI가 만들어 주면 그 과정이 통째로 빠집니다. 코드는 돌아가지만 이 시스템이 어떻게 움직이는지는 머릿속에 그려지지 않습니다.

논문은 이런 모습을 인지적 항복(cognitive surrender)이라는 개념으로 설명합니다. AI가 내놓은 결과를 거의 검토하지 않고 받아들이면서 직관과 숙고를 모두 건너뛰는 태도입니다. 그리고 이 태도를 인지적 위임(cognitive offloading)과 구분합니다. 맞춤법 검사기나 타입 검사기에 특정 작업을 맡기는 것은 합리적인 선택이지만, 판단 자체를 넘기는 것은 다른 이야기라는 뜻입니다.

인지적 항복이 위험한 이유는 그 대가가 늦게 나타나기 때문입니다. 논문에 따르면 인지적 항복은 AI가 틀렸을 때조차 자신감을 높입니다. 팀은 실제보다 시스템을 더 잘 안다고 느끼고, 무엇을 잃었는지는 다 잃고 난 뒤에야 알게 됩니다.

MIT 미디어랩 연구의 EEG 뇌 연결성 비교 도식. LLM 사용 집단, 검색 사용 집단, 도구 없이 쓴 집단의 뇌 연결 밀도가 차례로 다르게 나타난다

위 그림은 MIT 미디어랩이 2025년 6월 공개한 연구 「Your Brain on ChatGPT」의 도식입니다. 참가자 54명을 세 집단으로 나눠 같은 주제로 글을 쓰게 하고 뇌파를 측정했습니다. 도구 없이 쓴 집단의 뇌 연결이 가장 넓고 촘촘했고, 검색을 쓴 집단이 그다음이었고, LLM을 쓴 집단이 가장 약했습니다. 인지 부채라는 표현이 널리 알려지는 계기가 된 연구이기도 합니다.

이 연구에서 자주 인용되는 결과가 하나 있습니다. 첫 세션이 끝난 직후 자기가 방금 쓴 글에서 한 문장도 정확히 인용하지 못한 참가자가 LLM 집단에서는 83퍼센트였고, 나머지 두 집단에서는 11퍼센트였습니다. 방금 만든 결과물인데도 자기 것으로 남지 않은 셈입니다. 다만 연구진도 한계를 함께 밝혔습니다. 공개 시점에 동료 평가를 거치지 않은 사전 논문이었고, 시험 대상도 ChatGPT 하나였습니다. 그래서 이 결과를 모든 AI 도구에 그대로 적용하기는 어렵습니다.

의도 부채는 왜 가장 늦게 발견될까요?

세 번째가 의도 부채입니다. 논문은 의도 부채를 "시스템이 어떻게 발전해야 하는지 안내하는 명시적 근거와 목표, 제약이 없거나 사라진 상태"로 정의합니다. 기술 부채가 코드에, 인지 부채가 사람에게 쌓인다면 의도 부채는 기록에 쌓입니다. 더 정확히 말하면, 있어야 할 기록이 없는 자리에 쌓입니다. 여기서 기록이란 요구사항 문서, 결정 기록, 명세, 테스트처럼 이 시스템이 무엇을 하기로 했는지를 바깥에 적어 둔 자료를 말합니다.

의도 부채가 특히 곤란한 이유는 나중에 갚기가 어렵다는 점입니다. 기술 부채는 시간이 한참 지난 뒤에도 코드를 다시 정리하면 갚을 수 있습니다. 그런데 의도는 결정하는 그 순간에 붙잡지 않으면 복구하기 어렵고, 때로는 아예 불가능합니다. 왜 그때 그 선택을 했는지는 그 자리에 있던 사람의 머릿속에만 남고, 그 사람이 팀을 떠나면 같이 사라집니다.

AI 에이전트가 개발에 참여하면서 이 문제는 더 시급해졌습니다. 사람이든 에이전트든 시스템을 고치려면 이 시스템이 지금 무엇을 하는지만이 아니라 무엇을 위한 것인지를 알아야 합니다. 그 정보가 없으면 에이전트는 기술적으로는 맞지만 핵심을 벗어난 결과를 내놓거나, 예상보다 훨씬 많은 시간과 토큰을 씁니다.

의도 부채는 다음 세 가지 신호로 알아볼 수 있습니다.

동작이 어긋납니다: 시스템이 하는 일이 관계자들이 알고 있던 것과 다르고, 그 사실을 테스트 막바지나 고객 문의에서야 발견합니다.
AI 에이전트가 유난히 헤맵니다: 같은 작업인데 설명을 여러 번 덧붙여야 하고, 결과가 기술적으로는 맞는데 요점을 비껴갑니다.
말로만 있던 제약이 사라집니다: 성능 기준, 개인정보 처리 원칙, 접근성 요건처럼 몇 사람만 알던 조건이 조용히 잊힙니다.

세 가지 부채는 어떻게 서로를 키울까요?

세 부채는 서로 떨어져 있지 않습니다. 논문은 이들이 서로를 강화한다고 설명합니다. 순서를 따라가 보면 이렇습니다.

의도 부채가 인지 부채를 키웁니다: 왜 그렇게 만들었는지가 기록에 없으면 새로 합류한 사람은 시스템의 구조를 제대로 이해하기 어렵습니다.
인지 부채가 기술 부채를 키웁니다: 시스템을 이해하지 못한 상태에서 내리는 구현 결정은 나쁜 코드가 되기 쉽습니다.
기술 부채가 다시 인지 부채를 키웁니다: 엉킨 코드는 읽고 따져 보기가 어렵고, 그만큼 이해도 더 어려워집니다.

그래서 셋 가운데 하나만 관리해서는 효과를 보기 어렵습니다. 그런데 우리가 먼저 손대는 것은 언제나 측정이 되는 쪽입니다. 코드 품질 지표는 대시보드에 띄울 수 있지만, 팀이 시스템을 얼마나 이해하고 있는지, 결정의 근거가 어디까지 남아 있는지는 숫자로 잡히지 않습니다. 관리하기 쉬운 것만 관리하다 보면 나머지 두 가지가 조용히 늘어납니다.

개발이 아닌 일에서도 같은 일이 벌어질까요?

여기까지는 소프트웨어 이야기지만, 구조만 놓고 보면 다른 일에서도 비슷한 장면이 나타납니다.

마케팅 실무에서 예를 하나 들겠습니다. GA4 이벤트 설계를 AI에게 맡겨서 태그와 파라미터를 한 번에 만든 경우입니다. 설정은 동작하고 데이터도 들어옵니다. 그런데 몇 달 뒤 어떤 파라미터가 왜 그 이름인지, 왜 특정 이벤트만 전환으로 잡았는지 물으면 답할 사람이 없습니다. 설정 자체는 멀쩡하니 기술 부채는 없는 셈입니다. 하지만 팀은 자기 측정 체계를 설명하지 못하고(인지 부채), 그렇게 정한 이유는 어디에도 적혀 있지 않습니다(의도 부채).

보고서도 마찬가지입니다. AI가 정리해 준 분석 보고서는 문장이 매끄럽고 표도 정돈되어 있습니다. 그런데 회의에서 "이 수치는 어떤 기간 기준인가요"라는 질문이 들어왔을 때 바로 답하지 못하면, 그 보고서는 아직 자기 것이 아닙니다. 앞서 본 연구에서 자기가 쓴 글을 인용하지 못했던 참가자들과 크게 다르지 않은 상황입니다.

내 부채는 어느 쪽에 쌓이고 있을까요?

글 앞머리에서 드린 세 질문으로 돌아가 보겠습니다. 세 질문은 각각 다른 부채를 가리키고 있었습니다.

이 결과물을 지금 고쳐야 한다면, 어디를 건드려야 하는지 바로 말할 수 있나요? 말하지 못한다면 기술 부채 쪽입니다. 코드나 설정 자체가 엉켜서 손대기 어려워졌다는 신호입니다.
이 결과물이 왜 이렇게 동작하는지, 다른 사람에게 5분 안에 설명할 수 있나요? 설명하지 못한다면 인지 부채 쪽입니다. 결과물은 멀쩡한데 정작 그 일을 맡은 사람에게 이해가 남지 않은 경우입니다.
왜 다른 방식이 아니라 이 방식으로 정했는지가 어딘가에 적혀 있나요? 머릿속에만 있다면 의도 부채 쪽입니다. 지금은 문제가 없어 보여도, 그 기억이 사라지는 순간 되돌릴 방법이 마땅치 않습니다.

세 질문 모두 "네"라는 답이 나온다면 지금 여러분의 상황은 빚진 것이 아닙니다. 하나라도 "아니오"가 나온다면 그만큼을 빌려서 쓰고 있는 셈입니다. 그리고 이자는 대체로 몇 달 뒤에 청구되는데, 처음 치르는 사람은 대개 그 일을 이어받은 다음 사람입니다.

그렇다면 AI를 덜 써야 할까요?

여기서 한 가지 짚고 넘어가야 할 것이 있습니다. 지금까지의 이야기가 AI를 쓰지 말자는 결론으로 읽히면 곤란합니다.

앞서 나온 인지적 위임과 인지적 항복의 구분이 여기서 중요합니다. 특정 작업을 도구에 맡기는 것은 합리적인 선택입니다. 오탈자 검사, 반복 코드 작성, 형식 변환 같은 일까지 직접 해야 한다고 말하기는 어렵습니다. 문제가 되는 것은 판단까지 함께 넘기고, 결과를 확인하지 않은 채 다음으로 넘어가는 태도입니다.

논문이 제안하는 대응도 AI를 줄이라는 쪽이 아닙니다. 오히려 코드를 만드는 비용이 낮아진 점을 이용해, 이해가 필요한 부분을 다른 방식으로 다시 구현해 보면서 감각을 되찾는 방법을 권합니다. 구체적으로는 인지 부채에 효과가 있는 방법으로 사람이 직접 하는 코드 리뷰, 자기가 쓰지 않은 코드를 남에게 설명해 보는 자리, 문제가 생겼을 때의 회고를 꼽습니다. 의도 부채에는 결정 기록과 명세, 그리고 에이전트가 읽을 수 있는 형태의 지침 문서를 남기는 방법을 제안합니다.

이 방법들에는 공통점이 하나 있습니다. 대체로 머릿속에만 있던 것을 밖으로 꺼내 적는 일이라는 점입니다. 그리고 이 작업은 일이 끝난 뒤가 아니라 진행하는 동안 해야 의미가 있습니다.

결국 무엇을 기억해야 할까요?

결과물을 얻기 쉬워진 것과 일이 잘 되어 가는 것은 같은 이야기가 아닙니다. 결과물은 눈에 보이고 부채는 보이지 않아서, 잘 되어 가는 것처럼 보이는 구간이 꽤 오래 이어질 수 있습니다.

세 가지만 기억해 두면 좋겠습니다. 첫째, 부채는 코드에만 쌓이지 않습니다. 사람과 기록에도 쌓이고, 이 두 가지는 측정이 어려워서 더 오래 방치됩니다. 둘째, 의도는 결정하는 순간에만 붙잡을 수 있습니다. 코드는 나중에 정리할 수 있지만 왜 그렇게 정했는지는 그때 적지 않으면 대체로 사라집니다. 셋째, AI에게 맡길 일과 넘기지 말아야 할 판단을 구분하는 눈이 곧 실력이 되어 가고 있습니다.

그래서 이 이야기는 AI 도구를 어떻게 쓰느냐의 문제라기보다, 빨라진 속도를 무엇으로 갚을지의 문제에 가깝습니다. 속도는 이미 우리 손에 들어와 있습니다. 남은 선택은 그 속도를 빌린 채로 둘지, 아니면 갚아 가면서 쓸지입니다.

3줄 요약

부채는 세 곳에 쌓입니다. 기술 부채는 코드에, 인지 부채는 사람에게, 의도 부채는 기록에 쌓입니다. AI는 코드 쪽 부담을 줄여 주지만 나머지 두 가지는 오히려 빠르게 늘릴 수 있습니다.
인지 부채는 늦게 드러납니다. AI 결과를 검토 없이 받아들이는 태도는 실제보다 더 잘 안다는 느낌을 주기 때문에, 무엇을 잃었는지 다 잃고 난 뒤에 알게 됩니다.
의도는 그때 적어야 남습니다. 코드는 나중에 정리할 수 있지만, 왜 그렇게 정했는지는 결정하는 순간에 밖으로 꺼내 적지 않으면 복구하기 어렵습니다.