AI 코딩이 기술 부채 (Technical Debt)를 사라지게 만들지는 않습니다.

그것은 기술 부채가 이자를 청구하는 방식을 바꿀 뿐입니다.

AI 보조 전달 (AI-assisted delivery) 이전에는 기술 부채의 비용이 느린 온보딩 (Onboarding), 취약한 릴리스 (Releases), 혼란스러운 소유권 (Ownership), 중복된 작업, 그리고 긴 디버깅 (Debugging) 세션으로 나타났습니다. 그러한 비용은 여전히 존재합니다. 하지만 이제 또 다른 계층이 생겼습니다. 지저분한 저장소 (Repository)를 다루는 모든 AI 에이전트 (AI Agent)는 시스템이 무엇을 해야 하는지 이해하기 위해서 더 많은 컨텍스트 (Context), 더 많은 도구 호출 (Tool calls), 더 많은 재시도 (Retries), 그리고 더 많은 검증 노력 (Validation effort)을 소비해야 합니다.

이것이 바로 기술 부채의 토큰 세금 (Token Tax)입니다.

모델 제공업체는 별도의 "기술 부채 수수료"를 부과하지 않습니다. 청구서는 간접적으로 나타납니다. 코드가 불분명할수록 더 많은 프롬프트 컨텍스트 (Prompt context)가 필요합니다. 경계 (Boundaries)가 더 취약할수록 더 많은 코드 검색 (Code search)이 필요합니다. 테스트가 더 많이 누락될수록 더 많은 설명과 수동 검증 (Manual verification)이 필요합니다. 로직이 더 많이 중복될수록 더 많은 반복적 추론 (Reasoning)이 필요합니다.

엔지니어링 리더들에게 이것은 중요한 문제입니다. 왜냐하면 AI 보조 소프트웨어 전달은 단순히 생산성 (Productivity)에 관한 대화가 아니기 때문입니다. 그것은 운영 비용 (Operating-cost) 및 거버넌스 (Governance)에 관한 대화로 변하고 있습니다.

토큰 세금이 발생하는 곳

AI 에이전트에게 가장 비용이 많이 드는 코드베이스 (Codebases)가 항상 가장 큰 코드베이스인 것은 아닙니다.

비용이 많이 드는 코드베이스는 에이전트가 다음과 같은 기본적인 질문에 저렴하게 답할 수 없는 곳입니다:

• 실제 진실의 원천 (Source of truth)은 어디인가?
• 어떤 모듈이 이 동작을 소유하고 있는가?
• 어떤 테스트가 실패 모드 (Failure mode)를 증명하는가?
• 어떤 의존성 (Dependency)이 어떤 경계 (Boundary)를 호출할 수 있는가?
• 이것은 의도적으로 중복된 것인가, 아니면 실수인가?
• 회귀 (Regression)를 일으키지 않고 안전하게 변경할 수 있는 것은 무엇인가?

만약 저장소가 이러한 질문들에 명확하게 답할 수 없다면, 에이전트는 이를 추론 (Infer)해야 합니다. 추론은 컨텍스트 (Context)를 태웁니다.

예시 1: 중복된 비즈니스 로직

중복된 로직은 유지보수 문제일 뿐만 아니라, AI 컨텍스트 문제입니다.

// billing/discounts.js
export function applyDiscount(customer, amount) {
  if (customer.plan === "enterprise" && customer.monthsActive > 12) {
...

// checkout/pricing.js
export function calculateFinalPrice(user, subtotal) {
if (user.accountType === "enterprise" && user.monthsActive > 12) {
...

사람 리뷰어는 이 문제를 빠르게 발견합니다: 동일한 가격 책정 규칙이 서로 다른 이름을 가진 두 개의 모듈로 분산되어 있습니다.

AI 에이전트는 더 많은 질문을 던져야 합니다:

- `customer.plan`과 `user.accountType`은 동일한 개념인가?
- 어떤 구현체가 권위 있는(authoritative) 것인가?
- 할인이 변경된다면, 두 파일 모두를 수정해야 하는가?
- 한쪽 경로가 레거시(legacy)인가?
- 두 경로를 모두 검증하는 테스트가 존재하는가?

그러한 불확실성은 단순한 변경 작업을 더 넓은 리포지토리(repository) 검색 작업으로 변질시킵니다.

해결책은 단순히 "중복을 제거하는 것"이 아닙니다. 유용한 기술 부채(technical debt) 탐색 결과는 더 안전한 경로를 권장해야 합니다:

// pricing/discount-policy.js
export function calculateDiscountRate(account) {
if (account.type === "enterprise" && account.monthsActive > 12) {
...

더 나은 버전은 단일한 정책 경계(policy boundary)를 생성합니다. 이는 사람과 에이전트에게 추론할 수 있는 단일 지점을 제공합니다.

## 예시 2: 실패 동작(Failure Behavior)의 누락

취약한 테스트 또한 토큰 세금(token tax)을 발생시킵니다.

test("creates an invoice", async () => {
const invoice = await createInvoice(customerId);
expect(invoice.status).toBe("created");
...

이 테스트는 해피 패스(happy path)만을 증명합니다. 결제 승인이 실패할 때, 고객 정보가 없을 때, 결제 제공업체(billing provider)에서 타임아웃이 발생할 때, 또는 멱등성(idempotency)이 요구될 때 어떤 일이 발생하는지는 설명하지 않습니다.

결제 동작을 수정하도록 요청받은 AI 에이전트는 이제 누락된 계약(contract)을 추론하기 위해 구현 세부 사항, 의존성(dependencies), 로그, 그리고 호출 지점(call sites)을 모두 조사해야 합니다.

더 강력한 테스트 스위트(test suite)는 미래의 추론 비용을 줄여줍니다:

test("does not create duplicate invoices for the same idempotency key", async () => {
const first = await createInvoice(customerId, { idempotencyKey: "order-123" });
const second = await createInvoice(customerId, { idempotencyKey: "order-123" });
...

이러한 테스트는 단순한 품질 게이트(quality gates)가 아닙니다. 이것들은 실행 가능한 컨텍스트(executable context)입니다.

이것들은 미래의 모든 엔지니어와 모든 AI 에이전트(AI agent)가 내려야 하는 가정(assumptions)의 수를 줄여줍니다.

## 예시 3: 불분명한 소유권 경계 (Unclear Ownership Boundaries)

AI 에이전트(AI agents)는 코드베이스가 비공식적인 관례(informal conventions) 속에 아키텍처 결정 사항을 숨기고 있을 때 어려움을 겪습니다.

// order-service.js
import { updateInventory } from "../warehouse/inventory.js";
import { sendMarketingEmail } from "../marketing/campaigns.js";
...

이 방식이 작동할 수도 있습니다. 하지만 이는 모든 변경 사항이 창고(warehouse), 결제(billing), 마케팅(marketing), 그리고 분석(analytics)을 동시에 이해하도록 강요합니다.

에이전트(agent)가 하나의 워크플로(workflow)를 변경해야 하는데 갑자기 네 개의 도메인(domain)에 걸친 광범위한 컨텍스트(context)가 필요해질 때, 바로 토큰 세금(token tax)이 발생합니다.

더 깔끔한 경계는 오케스트레이션(orchestration)을 명시적으로 만듭니다:

export async function completeOrder(order, services) {
await services.inventory.reserve(order.items);
await services.billing.createInvoice(order.customerId, order.total);
...

이러한 개선은 단순히 미적인 문제가 아닙니다. 이는 의존성(dependencies)을 가시화합니다. 테스트를 격리(isolate)하기 쉽게 만듭니다. 소유권(ownership)을 논의하기 쉽게 만듭니다. 그리고 AI 에이전트(AI agents)에게 향후 수정을 위한 더 작은 컨텍스트 윈도우(context window)를 제공합니다.

## 토큰 세금 리스크를 측정하는 방법

저장소 감사(repository audit)는 코드 라인 수(lines of code)를 통해 토큰 비용을 추측해서는 안 됩니다.

더 나은 질문은 이것입니다: 어떤 기술 부채(technical debt) 패턴이 반복적인 컨텍스트 수집(context gathering)을 강요하는가?

유용한 신호는 다음과 같습니다:

- 높은 팬인(fan-in)을 가지며 소유권이 불분명한 모듈(modules)
- 관련 없는 폴더 전반에 걸쳐 반복되는 로직(logic)
- 실패 동작(failure behavior) 주변의 취약한 테스트 커버리지(test coverage)
- 워크플로(workflow), 영속성(persistence), 검증(validation), 그리고 부수 효과(side effects)가 뒤섞인 광범위한 파일들
- 인터페이스(interface) 없이 도메인 경계를 넘나드는 의존성(dependencies)
- 설명(explanation) 커버리지가 없는 생성된 코드 또는 AI 보조 코드
- 동일한 영역 주변의 높은 리뷰 혼란(review churn) 또는 반복적인 재작성(rewrites)

이것들은 추상적인 품질 불만이 아닙니다. 이는 향후 AI 보조 변경 사항이 아마도 더 많은 검색, 더 많은 추론(reasoning), 더 많은 재시도(retries), 그리고 더 많은 인간의 검토(human review)를 필요로 하게 될 지점들입니다.

## 리더들이 요구해야 할 사항

AI 보조 엔지니어링 환경에서 기술 부채(technical debt) 보고서가 유용하려면, 단순히 경고 목록을 나열하는 것 이상의 내용을 포함해야 합니다.

다음 내용이 포함되어야 합니다:

1. 정확한 코드 증거 (exact code evidence).
2. 해당 발견 사항이 인도(delivery), 신뢰성(reliability), 보안(security) 또는 AI 보조 변경(AI-assisted change)에 왜 중요한지에 대한 이유.
3. 이를 무시했을 때 발생할 가능성이 높은 운영 비용 (operational cost).
4. 실행 가능한 가장 작은 규모의 수정 경로 (remediation path).
5. 정리(cleanup) 후에 존재해야 하는 테스트 또는 증거.
6. 팀이 즉시 행동할 수 있게 하는 우선순위.

목표는 코드베이스에 수치심을 주는 것이 아닙니다. 목표는 다음 변경 사항을 더 저렴하고, 안전하며, 설명하기 쉽게 만드는 것입니다.

## 핵심 요점

AI 보조 인도(AI-assisted delivery)의 미래는 단순히 프롬프트(prompt)를 더 잘 작성하는 팀에 의해서만 결정되지 않을 것입니다.

그것은 저장소(repository)를 더 쉽게 추론(reason about)할 수 있는 팀에 의해 결정될 것입니다.

명확한 경계(boundaries), 강력한 테스트(tests), 명시적인 소유권(ownership), 그리고 가시적인 수정 계획(remediation plans)은 인간의 비용을 줄여줍니다. 또한 AI 에이전트(AI-agent)의 비용도 줄여줍니다.

이것이 바로 기술 부채가 AI 거버넌스(AI governance) 이슈가 되고 있는 이유입니다.

Clear Code Intelligence는 이러한 아이디어를 중심으로 구축되고 있습니다. 즉, 저장소 스캔(repository scans)은 증거에 기반한 발견 사항, 코드 예시, 수정 순서, 그리고 정리 후의 증거를 생성해야 한다는 것입니다.

만약 여러분의 팀이 AI 코딩 도구를 도입하고 있다면, 질문은 단지 "얼마나 빨리 코드를 생성할 수 있는가?"에 그쳐서는 안 됩니다.

더 어려운 질문은 이것입니다: "우리의 코드베이스가 미래의 모든 엔지니어와 에이전트에게 얼마나 많은 컨텍스트(context)를 다시 학습하도록 강요하는가?"