기술 부채(technical debt)는 코드 안에 쌓이고, 인지 부채(cognitive debt)는 머릿속에 쌓입니다. 의도 부채(intent debt)는 끝내 작성되지 않은 산출물 안에 쌓입니다. 시스템이 왜 지금의 모습이 되었는지 설명해 줄 목표, 제약 조건, 설계 근거들이 바로 그것입니다. 에이전트가 대신 청산해 줄 수 없는 유일한 부채이자, 에이전틱(agentic) 엔지니어링이 그 비용을 가장 크게 키우는 부채이기도 합니다.
Margaret-Anne Storey의 트리플 부채 모델(Triple Debt Model)은 소프트웨어의 건강 상태를 바라보는 깔끔한 틀을 제공합니다. 세 가지 부채란 기술 부채, 인지 부채, 그리고 의도 부채입니다.
기술 부채는 코드 안에 쌓입니다. 나중에 시스템을 변경하기 어렵게 만드는 구현상의 선택들이 누적된 결과입니다. 뒤엉킨 모듈, 마감에 쫓겨 택한 지름길, 새어나간 추상화. 기술 부채는 수십 년 전부터 우리가 이해해 온 개념이고, 스스로 존재를 알립니다. 느려진 빌드, 깨지기 쉬운 테스트, 특정 파일에 손댈 때마다 밀려오는 불안감이 바로 그 신호입니다.
인지 부채는 사람 안에 쌓입니다. 공유된 이해가 서서히 무너지는 현상, 즉 존재하는 코드의 양과 사람이 실제로 파악하는 양 사이의 간극입니다. 제가 '이해 부채(comprehension debt)'라고 불러온 바로 그것입니다. 시스템이 팀의 멘탈 모델보다 빠르게 성장할 때 쌓입니다. 코드가 아무리 깔끔해도 인지 부채는 심각하게 누적될 수 있습니다. 아무도 이해하지 못하는 깔끔한 코드는 결국 아무도 이해하지 못하는 코드일 뿐이니까요.
의도 부채는 산출물 안에 쌓입니다. 시스템이 왜 지금의 모습이 되었는지 설명해 줄 외재화된(externalized) 설계 근거, 목표, 제약 조건이 부재하거나 소실된 상태입니다. 머릿속에 담긴 이해가 아니라, 팀원이나 미래의 자신, 혹은 에이전트가 실제로 읽을 수 있도록 어딘가에 기록된 이해를 말합니다. 의도 부채가 높아지면 시스템은 원래 무엇을 하려 했는지를 서서히 잃어가고, 언제부터 어긋나기 시작했는지 누구도 정확히 말할 수 없게 됩니다.
여기서 제가 받아들이는 데 시간이 걸렸던 부분이 있습니다. 이 세 가지는 독립적입니다. 기술 부채는 낮고 의도 부채는 높을 수 있습니다. 시스템을 완벽히 이해하고 있어도(본인에게는 인지 부채 없음) 그 시스템의 의도가 본인 머릿속 밖에는 어디에도 존재하지 않을 수 있습니다(다른 모든 이에게는 막대한 의도 부채). 내부에서는 비슷하게 느껴지지만, 같은 청구서가 아닙니다.
AI는 그 어느 때보다 빠르게 코드를 생성합니다. 그래서 기술 부채는 감수하기도 더 쉬워졌고, 점점 청산하기도 더 쉬워지고 있습니다. 뒤엉킨 모듈에 에이전트를 붙이면 리팩토링해 줍니다.
인지 부채도 사람들이 과소평가하는 방식으로 회복 가능합니다. 시스템의 어떤 부분을 이해하지 못한다면, 에이전트에게 설명을 요청하면 됩니다. 잃어버린 멘탈 모델은 필요할 때 부분적으로 재구성할 수 있습니다. 코드가 여전히 존재하고 모델이 그것을 읽어줄 수 있으니까요.
의도는 다릅니다. 에이전트는 의도를 만들어낼 수 없습니다. 의도란 반드시 사람에게서 나와야 하는 유일한 입력값이기 때문입니다. 모델은 코드에서 그럴듯한 설계 근거를 추론할 수 있습니다. 이전 엔지니어가 왜 그렇게 했는지 짐작하는 것처럼요. 하지만 의도에 대한 추측은 의도 자체가 아닙니다. 그 300밀리초의 디바운스가 의도적인 UX 결정이었는지, 벤치마크 결과였는지, 아니면 누군가 한 번 입력하고 다시는 돌아보지 않은 숫자인지 모델은 알지 못합니다. 모델은 자신 있어 보이는 이유를 기꺼이 지어낼 것이고, 이는 모른다고 인정하는 것보다 더 나쁜 결과를 낳습니다.
결국 세 가지 부채 중에서 의도 부채만이 에이전트가 구조적으로 해결해 줄 수 없는 유일한 부채입니다. 코드는 작성할 수 있고, 이해는 복원할 수 있지만, 이유는 오로지 날조할 수 있을 뿐입니다.
팀들이 높은 의도 부채를 수년간 안고도 버텨온 데는 이유가 있습니다. 의도를 서로의 머릿속에 담아 나눠 들고 있었기 때문입니다.
새로운 팀원이 합류할 때, 모든 것을 문서로 남길 필요가 없었습니다. 팀원들이 복도에서 나누는 대화, 코드 리뷰 댓글, "아, 그 방식은 2023년 장애 이후로 안 씁니다" 같은 말들을 통해 의도를 천천히 흡수했으니까요. 암묵지는 사람에서 사람으로 전달되며 축적됐습니다. 4년째 그 팀에 있는 시니어 엔지니어가 곧 의도 문서였습니다. 비용이 많이 들고 손실도 있었지만, 어쨌든 작동했습니다.
에이전트는 이 모델을 특정한 방식으로 무너뜨립니다. 팀에 에이전트를 도입하는 것은 하룻밤 사이에 팀 규모를 두 배로 늘리되, 전원이 주니어인 상황과 같습니다. 여기에 한 가지를 덧붙이자면, 장기 기억이 없는 주니어들입니다. 에이전트는 대부분의 세션을 백지 상태로 시작합니다. 팀원들이 수년에 걸쳐 쌓아온 암묵적 의도를 이어받지 못합니다. 에이전트가 읽을 수 있는 산출물로 외재화되지 않은 것은 단순히 갖고 있지 않습니다.
이는 기록하지 않는 것의 경제학을 바꿔놓습니다. 외재화되지 않은 의도는 예전에는 가끔 치르는 비용이었습니다. 온보딩할 때, 누군가 팀을 떠났을 때. 하지만 이제는 세션마다 치러야 하고, 실행하는 에이전트 수만큼 곱해집니다. 사람들이 병렬화하고 싶어 안달인 그 20개의 에이전트? 각각은 당신을 한 번도 만난 적 없고, 당신 마음을 읽지 못하며, 의도의 빈틈이 있으면 그럴듯한 추측으로 자신 있게 채워버리는 팀원입니다. 제가 글에서 다룬 오케스트레이션 세금(orchestration tax)은 부분적으로 의도 부채 세금입니다. 다수의 에이전트를 관리하는 일이 지치게 느껴지는 이유 중 상당 부분은, 애초에 기록해 두지 않은 의도를 매번 다시 공급해야 하기 때문입니다.
이해 부채에 관해 글을 썼을 때 제기했던 한 가지 주장으로 돌아가고 싶습니다. 의도 부채가 그 논점을 더 날카롭게 만들어주기 때문입니다.
당시 저는 상세한 명세서(spec)가 완전한 답이 아니라고 주장했습니다. 명세서를 작동하는 코드로 변환하는 과정에는 어떤 명세서도 완전히 포착할 수 없는 수많은 암묵적 결정들이 개입하며, 프로그램 자체가 될 만큼 상세한 명세서는 그냥 더 느린 언어로 쓴 프로그램일 뿐이라고요. 지금도 그 생각은 변함없습니다.
의도 부채는 그 보완적 진실입니다. 모든 의도를 포착할 수 없다는 사실이 아무것도 포착하지 않아도 된다는 면죄부가 되지는 않습니다. 이제 에이전트가 대신 내리는 암묵적 결정들, 명세서가 끝내 완전히 열거하지 못하는 결정들이야말로 잘못될 경우 비용이 큰 핵심 결정들의 설계 근거가 기록되지 않으면 사라져버리는 결정들입니다. 모든 것을 기록할 수는 없습니다. 하지만 잘못 판단하면 비용이 큰 선택들의 이유만큼은 반드시 기록해야 합니다. 나중에 아무도 재구성할 수 없게 되는 것이 바로 그것들이니까요.
이해 부채의 요점은 코드가 존재한다고 해서 정확하다고 믿지 말라는 것이었습니다. 의도 부채의 요점은 코드가 살아남는다고 해서 그 이유까지 살아남는다고 믿지 말라는 것입니다. 코드는 답입니다. 의도는 그 답이 풀어야 했던 질문이고, AI는 당신이 기록하는 걸 잊어버린 질문에 대한 답을 탁월하게 만들어냅니다.
의도 부채는 마찰로 느껴지지 않습니다. 특정한 종류의 무력감으로 느껴집니다.
실제로 재구성할 수 없는 설계 결정을 방어해야 했던 인지적 항복(cognitive surrender)을 경험해 봤다면, 의도 부채는 팀 전체 규모에서, 기록의 영역에서 벌어지는 동일한 구멍입니다. 차이가 있다면, 항복은 그 순간 당신 개인의 자세에 관한 것이라는 점입니다. 의도 부채는 그런 순간들이 수백 번 쌓인 끝에 저장소(repo)에 남겨지는 것, 즉 다음 사람과 다음 에이전트가 물려받는 것입니다.
좋은 소식은, 지난 몇 달간 제가 써온 글들이 돌이켜보면 모두 의도 부채 관리에 관한 것이었다는 점입니다. 그 단어를 몰랐을 뿐이죠. 어떤 경우든 접근 방식은 동일합니다. 의도를 머릿속에서 꺼내어 에이전트가 읽을 수 있는 곳에 두는 것입니다.
구현이 아닌 의도를 위한 명세서를 작성하라. 좋은 명세서란 목표, 제약 조건, 타협 불가능한 것들, 그리고 완료의 명시적 정의(빠른, 접근 가능한, 안전한, 만족스러운 — 단순히 "기능적으로 올바른"이 아닌)입니다. 명세서의 역할은 코드 혼자서는 담을 수 없는 의도를 운반하는 것입니다.
AGENTS.md를 설정 파일이 아닌 의도 원장(ledger)으로 다루라. 제가 계속 /init 사용을 중단하라고 말하는 이유가 바로 이것입니다. 자동 생성된 파일은 코드가 무엇인지를 설명합니다. 의도 파일은 팀이 무엇을 의미하는지를 설명합니다. 어떤 단일 파일에서도 보이지 않는 컨벤션, "이 방식은 쓰지 않는 이유", 보이지 않는 제약 조건들이 바로 그것입니다. 에이전트가 스스로 추론할 수 없으면서 가장 필요로 하는 부분이기도 합니다.
결정이 일어나는 순간 포착하라. 결정 로그(Decision logs), 즉 경량 ADR(Architecture Decision Record)은 순수한 의도 부채 청산입니다. 결정하는 순간 이유를 기록하는 비용은 미미합니다. 그 내용을 알던 사람이 8개월 뒤 다른 팀으로 이동한 후 재구성하는 비용은 엄청납니다. 에이전트 덕분에 기록의 비용은 사상 최저 수준입니다. 더 이상 핑계는 없습니다.
학습 루프가 의도를 다시 기록하게 만들라. 저는 세션 말미에 학습 파일을 업데이트하는 자기 개선 에이전트(self-improving agents)를 주장해 왔습니다. 동일한 루프는 의도 부채 펌프를 역방향으로 돌리는 것이기도 합니다. 근본 원인을 기록한 모든 실수, "X를 시도했는데 Y 때문에 작동하지 않았다"는 모든 기록은, 그렇게 하지 않으면 최악의 오후에 대한 기억 속에만 남았을 의도입니다.
이것들은 새로운 도구가 아닙니다. 작업의 대부분이 더 이상 자신의 머릿속에서 일어나지 않는 시대에, 이유가 오직 머릿속에만 존재하게 두기를 거부하는 규율입니다.
오랫동안 소프트웨어에서 희소하고 가치 있는 것은 올바른 구현을 만들어내는 능력이었습니다. 코드는 비쌌고, 그래서 우리는 코드 작성을 최적화했습니다.
AI가 코드를 저렴하게 만들었습니다. 이해는 회복 가능합니다. 하지만 의도, 즉 목표와 제약 조건과 이유는 여전히 사람에게서 시작되어야 하는 유일한 입력값입니다. 그리고 우리가 외재화하는 데 가장 서툰 것이기도 합니다. 수십 년 동안 머릿속에 담고 다니는 것으로도 충분했으니까요.
그 방식은 수년간 공유된 맥락 속에서 의도를 흡수할 수 있는 소수의 팀에게는 통했습니다. 팀의 절반이 매 세션마다 낯선 이로 시작하는 에이전트일 때는 통하지 않습니다.
기술 부채는 시스템을 변경하기 어렵게 만들고, 인지 부채는 이해하기 어렵게 만듭니다. 의도 부채는 시스템이 여전히 원하는 일을 하고 있는지조차 알 수 없게 만듭니다. 그리고 세 가지 중 에이전트가 대신 갚아줄 수 없는 유일한 것입니다. 그러니 당신이 갚아야 합니다. 이유를 기록하세요. 그것이 저장소에 남길 수 있는 가장 가치 있는 것이 되어가고 있습니다.
