기술 부채, 인지 부채, 의도 부채: AI 시대에 쌓이는 세 가지 빚

AI로 만든 결과물을 수정하려다가 “어디를 바꿔야 하지?”, “이 계산은 어떻게 된 거지?”, “왜 이 방식을 택했지?” 하고 막힌 적이 있나요? 세 질문은 비슷하지만 확인할 대상이 다릅니다.

여기서 부채는 돈을 갚으라는 뜻이 아닙니다. 지금 남긴 문제가 나중에 수정이나 인수인계의 부담을 늘린다는 비유입니다. 세 종류는 서로 배타적인 분류가 아니어서 한 결과물에 함께 나타날 수 있습니다.

세 부채를 구분하는 이유

기술 부채는 소프트웨어의 내부 구조 때문에 변경과 확장이 어려워지는 문제를 설명할 때 쓰는 오래된 개념입니다. 인지 부채와 의도 부채를 함께 보는 방식은 2026년 Margaret-Anne Storey의 논문이 제안한 모델입니다. 모든 업무의 문제를 세 가지로 확정 분류한 법칙은 아닙니다. 논문 원문

그림의 아래 왼쪽은 구조와 코드, 아래 오른쪽은 팀의 이해, 위쪽은 목표와 결정 기록을 뜻합니다. 화살표는 이 문제가 서로 영향을 줄 수 있다는 모델의 설명입니다. 그림만으로 AI가 언제나 세 부채를 늘린다고 판단할 수는 없습니다.

기술 부채: 바꾸려면 여러 곳을 고쳐야 합니다

할인율 10%가 파일 다섯 곳에 각각 적혀 있다고 가정해 보겠습니다. 15%로 바꾸려면 다섯 곳을 찾아 수정해야 하고, 하나를 놓치면 표시 금액과 결제 금액이 달라질 수 있습니다. 같은 값을 여러 곳에서 관리하는 구조가 변경 부담을 만든 사례입니다.

대응은 할인율의 관리 원본을 정하고, 참조하는 곳을 연결하고, 변경 후 금액이 같은지 확인하는 것입니다. 코드의 겉모습만 정돈해서 해결되지는 않습니다. 정적 분석 도구, 즉 코드를 실행하지 않고 문제를 찾는 도구로 일부 징후를 찾을 수 있지만 설계 문제와 미래의 수정 비용까지 모두 측정할 수는 없습니다. 기술 부채 설명

인지 부채: 결과는 있지만 설명할 사람이 없습니다

코드가 잘 정리되어 있어도 담당자가 계산 순서와 예외 조건을 모를 수 있습니다. 이 글에서 말하는 인지 부채는 개인이 단어 하나를 잊은 일이 아니라, 팀이 시스템을 함께 이해하는 정도가 부족해지거나 약해지는 문제입니다.

AI가 계산 코드를 만들었다면 입력값 하나를 정해 직접 결과를 확인하고, 담당자가 계산 순서를 설명해 볼 수 있습니다. AI의 설명을 다시 복사하는 것만으로 이해 여부가 확인되지는 않습니다. 사람이 코드를 직접 썼다고 항상 이해하는 것도, AI를 썼다고 이해 과정이 반드시 사라지는 것도 아닙니다.

의도 부채: 왜 이 조건인지 기록이 없습니다

10% 할인이 정확히 계산되어도 왜 10%인지 모를 수 있습니다. 신규 고객 체험을 늘리려는 목적이었는지, 특정 계약 조건이었는지에 따라 다음 변경이 달라집니다.

결정 당시 목표와 이유를 적으면 이런 혼선을 줄이는 데 도움이 됩니다. 이미 기록이 없다면 과거 문서나 담당자에게 확인해 보세요. 다만 그럴듯한 이유를 AI가 만들어 냈다고 실제 결정 근거가 되는 것은 아닙니다. 확인하지 못한 내용은 “미확인”으로 남기고, 새로 합의한 이유는 새 결정으로 구분합니다.

뇌파 연구는 어디까지 말해 줄까요?

이 그림은 MIT 미디어랩 연구진의 「Your Brain on ChatGPT」에서 제시한 뇌파 비교입니다. EEG는 두피에서 뇌의 전기적 활동을 측정하는 방법입니다. LLM은 ChatGPT 같은 대형 언어 모델을, Search는 검색엔진 사용 조건을, Brain은 해당 도구 없이 작성하는 조건을 뜻합니다. 선과 색은 연구에서 계산한 연결성 등을 표시하며 뇌세포 수나 지능 점수는 아닙니다.

2025년 공개된 이 연구에서는 54명이 세 조건으로 나뉘어 글쓰기 과제에 참여했습니다. 연구진은 도구 없이 쓴 조건의 연결성이 가장 넓게 나타났고, LLM 조건에서는 자신이 작성한 글을 정확히 인용하는 데 어려움이 있었다고 보고했습니다. 연구 원문과 방법

이 결과는 특정 글쓰기 과제에서 관찰한 차이입니다. 모든 AI 사용이 뇌를 손상시킨다거나, 특정 사용자의 지능이 떨어졌다고 판단할 근거는 아닙니다. 연구 대상이 글쓰기 참가자였으므로 소프트웨어 팀이 시스템을 이해하는 정도를 직접 측정하지도 않았습니다. 이 글에서는 결과물을 만들었다는 사실과 내용을 이해했다는 사실을 구분할 필요가 있다는 참고 자료로 다룹니다.

직접 확인하기: 할인 계산 기록 한 장

아래는 실제 매장 정책이 아닌 연습용 상황입니다. 메모 앱이나 종이에 다음 내용을 옮겨 적으세요. AI나 계산 프로그램을 설치할 필요는 없습니다.

먼저 할인 금액과 최종 금액을 계산해 보세요. 10%는 100분의 10이므로 계산할 때는 10 ÷ 100 = 0.10을 곱합니다. 할인 금액은 20,000 × 0.10 = 2,000원, 최종 금액은 20,000 - 2,000 = 18,000원입니다. 2,000원이 최종 금액이라고 적었다면 할인 금액과 결제할 금액을 혼동한 것입니다. 두 줄로 나누어 다시 적으면 확인하기 쉽습니다.

그다음 세 문제를 나누어 적습니다.

관리 방법은 예를 들어 “할인율은 계산표에서 관리하고 안내문에는 계산표 위치를 적는다. 변경 후 안내문을 읽는 사람이 최신 할인율을 찾을 수 있는지 확인한다”라고 기록할 수 있습니다. 실제 안내문에 가격을 직접 표시해야 한다면, 관리 원본을 바꾼 뒤 안내문도 갱신하고 두 금액을 대조하는 절차가 필요합니다.

한 번 설명하지 못했다고 바로 팀 전체의 인지 부채를 확정할 수는 없습니다. 이 연습에서는 내가 더 확인해야 할 부분을 찾는 데 사용합니다.

마지막으로 아래 결정 기록의 빈칸을 채웁니다. 원래 이유를 모르는 상황이므로 목적과 이유에는 “미확인”이라고 씁니다. 가상 연습에서는 확인할 자료나 사람의 종류만 적으면 됩니다.

혼자 다시 해 볼 때는 상품 가격만 30,000원으로 바꾸세요. 할인율과 예외 조건은 유지합니다. 할인 금액 3,000원, 최종 금액 27,000원이 나오는지 확인하고 기록의 계산 줄을 바꿉니다. 가격을 바꿨다는 사실만으로 10% 할인 이유가 새로 밝혀지는 것은 아닙니다.

마케팅 업무에는 어떻게 적용할까요?

GA4에서 구매 이벤트가 들어온다고 가정해 보겠습니다. 이벤트는 사이트에서 일어난 행동을 기록한 데이터입니다. 데이터가 수집된다는 사실만으로 설정이 올바르거나 기술 부채가 없다고 할 수는 없습니다. 실제 주문과 중복 여부, 금액 등이 일치하는지 먼저 확인해야 합니다.

설정이 맞아도 팀이 언제 구매 이벤트를 보내는지 설명하지 못하면 이해를 보완해야 합니다. 특정 행동을 성과로 정한 이유가 없다면 목적과 판단 기준을 확인해야 합니다. 수집 오류와 이해 부족, 판단 기준 누락을 구분해서 해결하는 과정입니다.

보고서를 인수인계할 때도 같은 질문을 쓸 수 있습니다. 수치의 출처와 계산 방법, 그 지표를 선택한 이유가 함께 있으면 다음 담당자가 결과를 검토하기 쉽습니다. 설명이 막히는 곳부터 원자료를 확인하고 기록을 보완하세요.

내 업무에 적용할 세 질문

1. 변경할 때 여러 곳을 중복 수정하거나 예상하지 못한 오류가 생기나요? 구조 문제를 먼저 확인합니다.
2. 담당자가 입력에서 결과까지 설명하고 작은 예시로 확인할 수 있나요? 설명이 막히는 부분을 찾아 예시로 다시 확인해 보세요.
3. 목표, 예외 조건, 선택 이유와 근거가 남아 있나요? 빠진 결정 기록을 찾아 보완할 내용을 적습니다.

수정 위치를 모르는 이유는 복잡한 구조일 수도, 인수인계를 받지 못했기 때문일 수도 있습니다. 질문 하나의 답으로 부채 종류를 확정하지 마세요. 세 질문에 답할 수 있어도 다른 문제가 없다는 보증은 아닙니다.

AI가 만든 결과물을 모두 다시 작성할 필요는 없습니다. 변경할 가능성이 높거나 실수의 영향이 큰 부분부터 예시를 확인하고 설명과 근거를 남기면 됩니다. 기록은 결정할 때 남기는 것이 좋습니다. 이미 끝난 일이라도 확인한 근거를 추가해서 보완할 수 있습니다. 에이전트에 전달할 목적과 제약을 더 구체적으로 정리하려면 의도와 지침 문서 작성 글을 이어서 볼 수 있습니다.