아무도 기록하지 않은 기술 부채

코드베이스를 실제로 무너뜨리는 부채의 대부분은 어디에도 기록된 적이 없습니다. 현재의 공포가 약간 빗나가고 있는 지점은 AI가 생성한 코드의 양 자체가 아니라 바로 이것입니다.

우리는 금융에서 "부채 (debt)"라는 개념을 의도적으로 빌려왔습니다. 의도적으로 받는 대출은 이율과 만기가 정해져 있습니다. 따라서 이를 바탕으로 계획을 세우거나, 재융자를 받거나, 이자가 그만한 가치가 있는지 결정할 수 있습니다. 기록된 부채는 하나의 도구입니다. 사람들을 파산하게 만드는 것은 자신이 서명했다는 사실조차 몰랐던 부채이며, 이는 에이전트 (agents)가 몇 초 만에 수천 줄의 코드를 생성할 수 있게 되기 훨씬 전부터 소프트웨어 분야의 사실이었습니다.

이 개념을 공식화한 사람들도 이를 알고 있었습니다. Google 연구원들이 2014년과 2015년에 영향력 있는 논문들을 작성했을 때, 그들은 제목을 "기술 부채 (technical debt)"라고 붙이지 않았습니다. 대신 "머신러닝 (Machine Learning): 기술 부채의 고금리 신용카드"와 "머신러닝 시스템의 숨겨진 기술 부채 (Hidden Technical Debt in Machine Learning Systems)"라고 제목을 붙였습니다. 2015년 논문의 결론은 "실제 머신러닝 (ML) 시스템에서 막대한 지속적 유지보수 비용이 발생하는 것이 일반적이다"라는 것이었습니다. 문제를 명명한 사람들조차 제목에 "숨겨진 (hidden)"이라는 단어를 넣었습니다.

Martin Fowler는 그보다 10년 전에 이미 지도를 그려 놓았습니다. 그의 부채 사분면 (debt quadrant)은 모든 지름길을 두 가지 방식으로 분류합니다: 신중한지 (prudent) 혹은 무모한지 (reckless), 그리고 의도적인지 (deliberate) 혹은 부주의한지 (inadvertent). 여기서 중요한 것은 두 번째 축입니다.

                DELIBERATE                  INADVERTENT
              (you chose it)             (you never noticed)
           +-------------------------+-------------------------+
...

AI 코드에 관한 거의 모든 논쟁은 위아래 축, 즉 좋은 코드냐 형편없는 코드냐에 머물러 있습니다. 합리적인 질문입니다. 하지만 복리가 발생하는 지점은 좌우 축입니다. 왼쪽 열의 부채는 관리 가능합니다. 각 항목에 이름과 위치, 그리고 합의된 이율이 있기 때문입니다. 오른쪽 열의 부채는 관리할 수 없습니다. 존재한다는 사실조차 모르는 것은 관리할 수 없기 때문입니다. 가장 최악의 상황은 오른쪽 하단 셀, 즉 무모하고 부주의한 ("레이어링 (layering)이 뭐지?") 영역에 위치합니다. 이는 오직 문제가 터졌을 때에만 알게 되는 부채입니다.

AI가 그 세포를 발명한 것은 아닙니다. AI는 그것을 산업화했습니다. 사람이 결정을 미룰 때는 Slack 메시지, PR 코멘트, 혹은 그 과정을 지켜본 팀원과 같이 뒤에 증거의 흔적을 남깁니다. 하지만 에이전트 (Agent)는 세션당 수십 번씩 조용히 결정을 미루고는, 그 세션이 아무 문제 없이 잘 진행되었다고 보고합니다.

지난여름 Replit의 데이터베이스 삭제 사건에서 우리는 그 극단적인 버전을 보았습니다. 에이전트가 동결 (freeze) 기간 중에 운영 (production) 데이터베이스를 삭제했고, 그 구멍을 메우기 위해 4,000명의 가짜 사용자를 만들어냈습니다. 삭제 사건은 극적인 부분입니다. 일반화할 수 있는 부분은 더 지루합니다. 즉, (운영 환경 동결, 그 후 동결 중에도 계속 작업, 그리고 성공 보고)라는 일련의 결정들이 사람이 나중에 읽을 수 있는 곳 어디에도 기록되지 않았다는 점입니다. AI 부채 (AI-debt) 이야기에서 극적인 요소를 제거하면, 매번 남는 잔여물은 동일합니다. 그것은 나쁜 코드가 아니라 기록되지 않은 결정입니다.

지금까지도 제가 납득할 수 없는 세부 사항은, 에이전트가 그 규칙을 이해하고 있었다는 점입니다. 에이전트는 자신의 사과문에서 동결 (freeze) 상황을 명시했고, 자신이 어긴 모든 지침을 무미건조한 과거형으로 읊었습니다. 따라서 그곳에서 무엇이 실패했든, 모델이 이해하지 못해서 실패한 것이 아닙니다. 모델은 이해했고, 그렇게 말했습니다. 문제는 그 지식이 다음 날 아침 도구나 팀원이 확인할 수 있는 곳 어디에도 기록되지 않았다는 것입니다. 부족했던 것은 모델이 이해한 내용을 담아둘 장소였습니다.

이에 대한 명백한 반론이자 저 스스로도 스스로에게 던졌던 질문은, 모델이 계속해서 발전하고 있으니 이 문제는 나중에 해결해도 된다는 것입니다. 어느 정도는 타당한 말입니다. 보안 통과율은 상승하고 있습니다. Veracode는 2025년 10월 자사의 보안 스위트에서 GPT-5 Mini가 72%를 기록했다고 밝혔습니다 (이는 그들의 수치이며, 그들은 애플리케이션 보안을 판매하는 기업이므로 그에 맞춰 비중을 조절해 받아들여야 합니다). 하지만 더 나은 모델이라 할지라도 여전히 자신의 결정 사항을 기록하지는 않습니다. 모델은 기록되기를 원하는 더 많은 결정을 더 빠르게 내리며, 사용자가 검증을 멈출 만큼 충분한 신뢰를 얻습니다. Gartner는 자사의 "Predicts 2026" 소프트웨어 엔지니어링 보고서에서, "AI 제안을 암묵적으로 신뢰하는" 개발자들의 이러한 반사적 행동인 "자동화 편향 (automation bias)"에 전체 결함 예측의 근거를 두고 있습니다. 당신이 더 신뢰하는 더 똑똑한 에이전트는 보이지 않는 부채를 더 빠르게 생성합니다. 그것은 그 어떤 것도 기록하지 않기 때문입니다. AI 부채에 관한 Gartner의 자체 기사도 그 결말에 대해 유보적인 태도를 취하지 않습니다: "AI 부채는 불가피하며... AI 부채는 해결되지 않은 채로 복리로 쌓일 것입니다."

당신이 노트를 적는 속도보다 더 빠르게 초안을 작성하는 기계를 규율(discipline)로 이길 수는 없습니다. 따라서 남은 유일한 레버(lever)는 부채가 발생하는 즉시 이를 가시화하여, 항목들을 오른쪽 열에서 왼쪽 열로 옮기는 것입니다. 그것이 부채를 좋게 만드는 것은 아닙니다. 다만 그것을 금융화(financeable)할 수 있게 만듭니다. 이름이 있고 상환 트리거 (payoff trigger)가 있는 대상은 당신이 의도적으로 갚아 나갈지 혹은 계속 유지할지 선택할 수 있는 대상이 됩니다. 아무의 노트에도 기록되지 않은 대상은 당신을 대신해 선택을 내리는 대상이 됩니다.

다음은 제 개인 리포지토리(repo)에서 가져온 작동 버전입니다. 저는 debt-ops를 네 개의 독립된 복사본(claude-code, codex, copilot, 그리고 휴대용 세트)으로 배포합니다. 그래서 모든 공유 헬퍼 스크립트는 네 번 존재하며, 수정 사항이 발생하면 네 곳 모두에 수동으로 적용해야 합니다. 이것이 진짜 부채입니다. 저는 이를 의도적으로 채택했으며, 이는 리포지토리 내의 파일에 다음과 같이 기록되어 있습니다:

title:           adapter-script-duplication
quadrant:        prudent-deliberate
payoff_trigger:  AI-sync drift ships a real bug (fix lands in one copy, not the others)
...

그것이 저를 물 수도 있습니다. 그날이 오면, 제가 지름길을 택했던 바로 그날 작성된 파일이 나타나, 이제 대가를 치러야 할 때임을 의미하는 정확한 조건을 명시하고 있을 것입니다. 이는 Replit 에이전트가 내린 결정과 같은 종류의 유예된 결정(deferred decision)이지만, 이번에는 기록으로 남겨졌다는 점이 다릅니다.

문제는 누군가 기억해서 기록하지 않는 한 아무도 그 항목을 작성하지 않는다는 것이며, 기계의 속도에서는 아무도 기억하지 못할 것이라는 점입니다. 그것이 바로 debt-ops가 자동화하는 단 한 가지입니다. 이 도구는 에이전트에 연결되어, 에이전트가 세션이 어떻게 진행되었는지 기록한 자체 계정과는 별개로, 각 유예된 결정(deferred decision)을 리포지토리(repo) 내의 파일에 기록합니다. 이를 통해 사람이나 스크립트가 나중에 github.com/bcanfield/agentic-tech-debt에서 이를 읽을 수 있게 합니다.

이것이 에이전트가 생성하는 부채를 줄여주는 것은 아닙니다. 단지 그 부채가 보이지 않는 상태로 남아있지 않도록 막아줄 뿐입니다.