압축하지 말고, 승격시키세요

AI 코딩에는 모델 자체의 문제가 아닌, 세션 전반에 걸쳐 컨텍스트 (Context)를 어떻게 관리하느냐에 따른 숨겨진 병목 현상이 존재합니다.

1단계를 마쳤습니다. 코드베이스는 5,000줄 늘어났습니다. 2단계를 시작할 때, "AI가 알고 있는 것"을 어떻게 다음 단계로 전달할까요?

오늘날 흔히 쓰이는 답변은 Repomix입니다. 전체 코드베이스를 하나의 마크다운 (Markdown) 파일로 압축하여 프롬프트 (Prompt)에 쏟아붓는 방식이죠. 이는 해결책처럼 보이지만, 더 큰 문제를 야기합니다.

Repomix는 전체 GC 힙 덤프 (Full GC Heap Dump)와 같습니다

-XX:+HeapDumpOnOutOfMemoryError 스냅샷에는 모든 살아있는 객체, 모든 죽은 객체, 모든 파편화된 바이트가 포함되어 있습니다. 디스크에 전체 힙 (Heap)을 담을 수는 있지만, 그것을 로드하고, 파싱하고, 수천 개 중에서 실제로 필요한 12개의 객체를 찾아내는 과정 — 이것이 진짜 비용입니다.

AI 컨텍스트 (Context) 관점에서 보면 다음과 같습니다:

• 100K 라인의 코드베이스 → Repomix가 이를 약 150K 토큰 (Tokens)으로 패킹 → 프롬프트에 투입
• AI는 150K 토큰 내부에서 "2단계에서 변경해야 할 3개의 파일"을 찾아내야 함
• 150K 토큰으로 인한 지연 시간 (Latency) + 어텐션 희석 (Attention dilution) + 보일러플레이트 (Boilerplate) 속에 파묻힌 핵심 신호
• 2단계 코드가 1단계의 의도에서 벗어나기 시작함 → 더 많은 수정 필요 → 더 많은 컨텍스트 팽창 (Context bloat) → 죽음의 소용돌이 (Death spiral)

이 현상에는 이름이 있습니다: lost in the middle. 긴 컨텍스트의 중간 부분에 대한 정확도는 낭떠러지처럼 급격히 떨어집니다. 150K 토큰의 전체 힙 덤프를 제공함으로써, 당신은 AI가 중간에 있는 100K 토큰을 잊어버리도록 보장하는 셈입니다.

하지만 더 깊은 문제는 이것입니다:

전체 GC 덤프만이 "압축"을 필요로 합니다. 승격 (Promotion)은 압축하는 것이 아니라 — 승격시키는 것입니다.

JVM은 25년 전에 이미 이 문제를 해결했습니다

HotSpot은 메모리를 세 가지 세대 (Generations)로 나눕니다:

세대 (Generation)	역할	수집 전략 (Collection Strategy)
Eden	새로운 객체가 생성되는 곳	대부분 Minor GC에서 소멸하며, 생존자는 승격됨
...

이는 AI 보조 개발 과정 중 코드베이스 내 정보의 생명 주기 (Lifecycle)와 완벽하게 매칭됩니다:

단계 완료 → 살아남은 것은 다음 단계로 이동
     │
     ├─ Eden 코드 (90%)             → 앞으로 가져가지 마세요
...

차이점은 압축이 아니라 **승격 (promotion)**입니다. 힙 (heap) 전체를 평탄화할 필요는 없습니다. 살아남은 객체들을 다음 세대의 컨텍스트 (context)로 업그레이드하기만 하면 됩니다.

승격 방법 (Takeaway Template)

단계 종료 시: 세 가지 질문

Q1: 어떤 데이터 구조와 인터페이스가 장기적인 가치를 증명했는가? → 구현 (implementation)이 아닌 선언 (declaration)을 승격시키세요.

# 핵심 도메인 (Core Domain) (Phase 1에서 승격됨)
- User: { id, email, hashedPassword, displayName }
  불변식 (invariant): email은 전역적으로 유일하며, 생성 시 검증됨
...

Q2: 어떤 가정이 깨졌는가? → 각각 한 줄씩 작성하세요. 다음 단계에서 이를 다시 배울 필요가 없어야 합니다.

# 가정의 변화 (Assumption Changes)
- "DB 커넥션 풀 (connection pool) 기본값 10이면 충분하다" ❌ 25로 상향
- "Vercel 무료 티어는 100MB 응답을 지원한다" ❌ 페이지네이션 (pagination) 추가

Q3: 의도적으로 완료하지 않은 것은 무엇인가? → 단계 경계를 넘어 생존할 수 있도록 명시적으로 태그를 지정하세요.

# 이월된 부채 (Carried Debt)
- [ ] Phase 3: 인증 (auth)을 JWT 세션에서 OAuth2로 마이그레이션
      근거 (Rationale): MVP 우선, Phase 3에서 제3자 로그인 필요

단계 시작 시: 승격된 데이터만 로드하기

Phase N 컨텍스트 (context)
├── 제품 사양 (Product spec) (확정됨, 초안 아님)
├── 핵심 도메인 (Core domain) (승격된 타입 + 불변식)
...

Repomix 덤프도, 이전 단계의 전체 세션 히스토리도 필요 없습니다. 이미 추론을 마친 설계 문서도 필요 없습니다.

토큰 (Token) 비교:

접근 방식	토큰 수	어텐션 프로필 (Attention Profile)
전체 Repomix 덤프	~100K-500K	전역적으로 희석되어 주요 신호가 묻힘
승격 기반 로드	~3K-10K	이번 단계에 실제로 필요한 것에 집중됨

이는 두 자릿수(two orders of magnitude)의 차이입니다.

Repomix와 승격은 상호 배타적이지 않습니다

압축은 전송 (transport) 문제를 해결합니다: "전체 코드베이스가 컨텍스트에 들어갈 수 있는가?"

승격은 선택 (selection) 문제를 해결합니다: "다음 단계에 실제로 필요한 것은 무엇인가?"

Repomix는 교차 참조 검색 (cross-reference lookup) 용도로는 괜찮습니다. AI가 필요할 때만 (on demand) 읽을 수 있도록 접이식 참조 (collapsible reference) 형태로 유지하세요. 하지만 모든 단계의 시작점에서 그것이 기반이 되어서는 안 됩니다. 기반은 승격된 지식 (promoted knowledge)이어야 합니다.

올바른 프롬프트 구조:

[단계 컨텍스트 (Phase context)] — 승격된 인터페이스 + 단계 목표       (3K-10K 토큰)
[변경 파일 (Change files)] — 이번 단계에서 수정하는 3~5개의 파일        (10K-20K 토큰)
[Repomix 덤프 (Repomix dump)] — 선택 사항, 교차 참조 검색용           (접이식)

AI의 주의력 (attention)은 가장 중요한 신호, 즉 이전으로부터 살아남은 것과 지금 변경해야 할 것에 집중됩니다. 전체 코드베이스는 필수 읽기 자료가 아닌, 필요할 때 찾아보는 참조 자료가 됩니다.

결론

Repomix는 실제 문제(코드베이스가 컨텍스트에 다 들어가지 않는 문제)를 해결하지만, 잘못된 해답을 선택했습니다. 더 스마트한 필터 대신 더 큰 덤프를 선택한 것입니다. JVM 용어로 표현하자면, 세대별 수집 (generational collection) 대신 더 빈번한 전체 GC (Full GC)를 선택한 것과 같습니다.

JVM을 튜닝해 본 엔지니어라면 누구나 알고 있습니다. 세대 가설 (generational hypothesis)은 유효하다는 것을 말이죠. 대부분의 객체는 일찍 죽습니다. 살아남은 소수의 객체는 승격 (promoting)할 가치가 있습니다.

코드베이스 정보도 동일한 패턴을 따릅니다:

• **90%**는 Eden 영역 — 한 번 작성되고 다시는 필요하지 않음
• **9%**는 Survivor 영역 — 매 단계 승격됨
• **1%**는 Tenured 영역 — 핵심 도메인 모델, 드물게 변경됨

압축은 필요 없습니다. 당신에게 필요한 것은 보존할 가치가 있는 10%를 식별하는 것입니다.

*2026년 6월. JVM 세대별 GC에서 영감을 얻음 — 원조 "압축하지 말고, 승격시키세요."