AI 드리븐 코드베이스 문서화 (2편) - 4계층 정보 구조 설계
TL;DR
- 증상: AI가 전체 코드베이스를 탐색하면서 토큰 폭탄 (5,000+ 토큰), 관련 없는 파일도 읽고, 응답 시간 30초+
- 원인: 22만 줄 코드를 한 번에 이해할 수 없음, 필요한 정보만 선별적으로 읽을 구조 없음, 단계적 정보 제공 메커니즘 부재
- 해결: 4계층 정보 구조 설계 (오케스트레이션 → 요약 → 인덱스 → 상세), Progressive Disclosure 패턴, YAML 메타데이터 스키마, 트리거 기반 문서 선택
- 효과: 토큰 85% 절약 (13,000 → 2,000), 응답 시간 67% 단축 (30초 → 10초), 개발 속도 3배 향상, 할루시네이션 감소
- 한계: 문서 작성 초기 비용 (2주), 최신화 부담 (주 1회), 계층 설계 복잡도, 팀 전체 학습 필요, 측정 비용
글 머리말
지난 글에서 AI 코딩 도구를 도입했지만 오히려 생산성이 떨어졌던 경험을 공유했습니다. 토큰 낭비, 할루시네이션, 컨벤션 미준수 등의 문제가 있었죠.
이번 글에서는 그 문제들을 해결하기 위해 설계한 4계층 정보 구조를 다룹니다.
핵심 아이디어는 Progressive Disclosure( 점진적 공개)입니다. AI가 한 번에 모든 정보를 읽는 게 아니라, 필요한 만큼만 단계적으로 읽도록 설계했습니다.
4계층 정보 구조 - 핵심 아키텍처
전체 구조
graph TB
%% 스타일 정의
classDef nodeStyle fill:#fff,stroke:#333,stroke-width:1px,rx:5,ry:5
subgraph Layer1 [Layer 1: 오케스트레이션<br/>]
A[<b>ai-rules.md</b><br/>어떤 작업에 어떤 문서를 읽을지 결정]:::nodeStyle
end
subgraph Layer2 [Layer 2: 요약/프록시<br/>]
B[<b>START.md</b><br/>토큰 절약용 대표 컨텍스트<br/>약 65줄]:::nodeStyle
end
subgraph Layer3 [Layer 3: 인덱스<br/>]
C[<b>quick.md</b><br/>도메인 맵, 코드/문서 위치<br/>약 120줄]:::nodeStyle
end
subgraph Layer4 [Layer 4: 상세<br/>]
D1[<b>domain.md</b><br/>src 내 코드 위치 요약<br/>30-60줄]:::nodeStyle
D2[<b>domains/*.md</b><br/>도메인별 상세 문서<br/>100-270줄]:::nodeStyle
end
A --> B
B --> C
C --> D1
C --> D2
style Layer1 fill:#e3f2fd,stroke:#90caf9,stroke-width:2px
style Layer2 fill:#e8f5e9,stroke:#a5d6a7,stroke-width:2px
style Layer3 fill:#fff3e0,stroke:#ffcc80,stroke-width:2px
style Layer4 fill:#fce4ec,stroke:#f48fb1,stroke-width:2px각 계층은 명확한 역할을 가집니다. Layer 1은 행동 규칙 (ai-rules.md, 331줄), Layer 2는 AI 진입점 (START.md, 65줄), Layer 3는 프로젝트 전체 구조 (quick.md, 120줄), Layer 4는 도메인별 상세 (domain.md, domains/*.md, 30~270줄)입니다.
Layer 1: 오케스트레이션 레이어 (ai-rules.md)
“어떤 작업에 어떤 문서를 읽어야 하는지” 를 결정하는 최상위 규칙입니다.
Cursor의 .cursorrules 파일에서 자동으로 참조되어, AI가 작업을 시작할 때 가장 먼저 읽는 문서입니다.
구조 예시
# AI Rules - Epyon API
## 문서 참조 규칙
### 작업 시작 시
1. 먼저 docs/START.md를 읽어 키워드→도메인 매핑 확인
2. 해당 도메인의 src/.../domain.md 읽기
3. 필요시 docs/domains/{domain}.md 상세 참조
### 트리거 기반 문서 선택
(키워드-도메인-필수문서 매핑 표)
## 금지 규칙
- 다른 도메인의 Repository 직접 호출 금지
- @ai-deprecated 태그가 있는 코드는 수정하지 말 것예를 들어, “재계약”이라는 키워드가 나오면 contract 도메인의 domains/contract.md 문서를 읽도록 매핑합니다.
핵심 포인트
Single Source of Truth: 행동 규칙은 이 문서 하나에서만 정의합니다. 다른 문서에서 규칙을 중복 정의하면 혼란이 생깁니다.
❌ Bad:
- ai-rules.md: "JPA 우선 사용"
- conventions.md: "MyBatis 우선 사용"
→ 충돌!
✅ Good:
- ai-rules.md: "JPA 우선 사용" (유일한 정의)
- conventions.md: ai-rules.md 참조Layer 2: 요약/프록시 레이어 (START.md)
역할
토큰 절약용 대표 컨텍스트입니다. AI가 프로젝트 전체를 파악하는 데 필요한 최소한의 정보만 담습니다.
65줄 정도로 짧게 유지하는 게 핵심입니다. 이 문서를 읽는 데 약 300 토큰만 사용됩니다.
구조 예시
# START - AI 진입점
## 프로젝트 개요
(프로젝트 정보 표)
## 키워드 → 도메인 매핑
(키워드-도메인 매핑 표)
## 문서 탐색 가이드
- 프로젝트 전체 구조: docs/quick.md
- 도메인별 상세: docs/domains/{domain}.md
- 코드 위치 요약: src/.../domain/{domain}/domain.md핵심 포인트
프록시 역할: AI가 “계약 관련 작업”이라고 하면, 이 문서에서 contract 도메인을 찾고, 해당 도메인의 상세 문서로 이동합니다.
사용자: "재계약 API 수정 해줘"
AI: (START.md 읽음)
→ 키워드 "재계약" → contract 도메인
→ domain/contract/domain.md 읽기
→ 필요시 docs/domains/contract.md 상세 참조전체 코드베이스를 탐색하지 않고, 정확한 위치로 바로 이동합니다.
Layer 3: 인덱스 레이어 (quick.md)
역할
코드/문서 위치 빠른 탐색을 위한 인덱스입니다. 프로젝트 전체 구조와 도메인 맵을 담습니다.
구조 예시
# Quick Reference - 도메인 맵
## 디렉토리 구조
project-root/
├── src/main/java/com/example/
│ ├── domain/ # 도메인별 비즈니스 로직
│ ├── model/ # JPA Entity
│ └── infra/ # 외부 연동
└── docs/
├── START.md # AI 진입점
└── domains/ # 도메인별 상세
## 핵심 도메인 (5개)
(도메인-역할-파일수-상세문서 표)
## 도메인 간 의존성
(Mermaid 다이어그램)예를 들어, site 도메인은 45개 파일, room 도메인은 38개 파일로 구성되어 있고, 각각 상세 문서 링크를 포함합니다.
도메인 간 의존성도 Mermaid 다이어그램으로 시각화합니다:
graph TB
Site[사이트] --> Room[객실]
Room --> Contract[계약]
Contract --> Customer[고객]
Contract --> Fee[요금]
style Site fill:#e3f2fd
style Contract fill:#e8f5e9핵심 포인트
인덱스 역할: AI가 특정 도메인의 상세 정보가 필요할 때, 이 문서에서 해당 도메인의 문서 경로를 찾습니다.
AI: (quick.md 읽음)
→ contract 도메인 찾기
→ 파일 수: 19개, 상세 문서: domains/contract.md
→ 의존성: Site → Room → ContractLayer 4: 상세 레이어 (domain.md, domains/*.md)
두 가지 문서 유형
Layer 4는 두 가지 유형으로 구성됩니다. domain.md는 코드 위치 요약 + YAML 메타데이터 (30~60줄), 는 도메인별 상세 문서 (100~270줄)입니다.
domain.md (코드 위치 요약)
코드와 같은 위치에 있는 요약 문서입니다. YAML 메타데이터가 핵심입니다.
---
role: domain
responsibility: '계약 관리 - 임대차, 재계약, 퇴거 처리'
dependencies: [site, room]
entrypoints: ['ContractService', 'ContractAdminApi']
gotchas: ['상태 전이 규칙', '암호화 필수', 'FeeService 연동']
---
# Contract Domain
## 패키지 구조
domain/contract/
├── api/ # REST Controllers
├── service/ # Business Logic
├── repository/ # Data Access
└── dto/ # DTOs
## 핵심 클래스
(클래스-역할 표)
## 주의사항 (gotchas)
1. 상태 전이 규칙: ContractStateManager 경유 필수
2. 암호화 필수: 개인정보 저장 시 EncryptService 사용
3. FeeService 연동: 재계약 시 요금 계산 누락 주의YAML 메타데이터 스키마
---
role: domain # 역할 (domain, service, infra 등)
responsibility: '한 줄 설명' # 이 도메인이 무엇을 하는지
dependencies: [site, room] # 의존하는 다른 도메인 (읽기 전용)
entrypoints: ['ContractService'] # AI가 건드릴 수 있는 클래스
gotchas: ['상태 전이 규칙', '암호화'] # 주의사항
---AI는 이 메타데이터를 읽고:
- dependencies: 어떤 도메인을 참조할 수 있는지 파악
- entrypoints: 어떤 클래스부터 봐야 하는지 파악
- gotchas: 무엇을 조심해야 하는지 파악
domains/*.md (도메인별 상세 문서)
비즈니스 로직, 상태 전이, 주의사항을 상세히 담습니다.
# Contract 도메인 상세
## 비즈니스 개요
임대 계약의 전체 라이프사이클을 관리합니다.
- 신규 계약 (입주)
- 재계약 (연장)
- 퇴거 (종료)
## 상태 전이
<!-- Mermaid 다이어그램은 별도로 렌더링됩니다 -->
## 핵심 비즈니스 규칙
- 상태 전이는 반드시 ContractStateManager 경유
- 재계약 시 FeeService.calculateRenewalFee() 호출 필수
- 퇴거 시 보증금 정산 누락 주의계약 상태 전이는 Mermaid로 시각화합니다:
stateDiagram-v2
[*] --> 대기중: 계약 생성
대기중 --> 활성: 입주 완료
활성 --> 재계약중: 재계약 신청
재계약중 --> 활성: 재계약 완료
활성 --> 퇴거중: 퇴거 신청
퇴거중 --> 종료: 퇴거 완료핵심 설계 원칙
1. Single Source of Truth
규칙은 한 곳에서만 정의합니다. 행동 규칙은 ai-rules.md, 코딩 컨벤션은 conventions.md, 도메인 규칙은 해당 domains/*.md에만 정의하고, 다른 문서에서는 참조만 합니다.
2. Progressive Disclosure
필요한 만큼만 정보를 제공합니다.
사용자: "프로젝트 전체 구조 알려줘"
AI: START.md (65줄) + quick.md (120줄) → 약 600 토큰
사용자: "계약 도메인 상세히 알려줘"
AI: + domain.md (60줄) + domains/contract.md (270줄) → 약 2,000 토큰전체 정보를 한 번에 읽지 않고, 단계적으로 읽습니다.
3. 트리거 기반 탐색
키워드로 관련 문서를 자동 선택합니다.
# ai-rules.md의 트리거 규칙
"재계약", "퇴거" → contract 도메인
"세금계산서" → admin/tax 도메인
"IoT", "도어락" → iot 도메인
"고객", "입주민" → customer 도메인4. 메타데이터 우선
전체 문서를 읽기 전에 YAML 메타데이터로 빠르게 판단합니다.
# 메타데이터만으로 파악 가능한 정보
---
role: domain
responsibility: '계약 관리'
dependencies: [site, room] # 어디를 참조하는지
entrypoints: ['ContractService'] # 어디부터 보는지
gotchas: ['상태 전이 규칙'] # 무엇을 조심하는지
---5. Living Document
코드와 함께 진화하는 문서입니다.
# PR 템플릿에 추가
## Documentation Checklist
- [ ] 관련 도메인의 `src/.../domain.md` 업데이트 완료
- [ ] `docs/domains/*.md` 변경 사항 반영 (필요시)
- [ ] 새 용어가 있다면 `glossary.md`에 추가산출물 현황 - 실제로 만든 문서들
전체 문서 구조
docs/
├── START.md ← AI 진입점 (65줄)
├── quick.md ← 도메인 맵 (120줄)
├── ai-rules.md ← AI 행동 규칙 (331줄)
├── conventions.md ← 코딩 컨벤션 (127줄)
├── layers.md ← Global/Infra 상세 (91줄)
├── glossary.md ← 용어집 (147줄)
├── ai/
│ └── ai-onboarding-overview.md ← 아키텍처 개요 (Living Doc)
│
└── domains/
├── site.md ← 핵심 도메인 (5개)
├── room.md
├── contract.md
├── customer.md
├── fee.md
├── iot.md ← 확장 도메인 (16개)
├── auth.md
├── goods.md
├── ...
└── admin/ ← 관리자 하위 도메인 (6개)
├── admin.md
├── contract.md
├── customer.md
├── tax.md
└── ...
src/main/java/.../domain/
└── {각 도메인}/
└── domain.md ← 코드 위치 요약 (22개)총 56개의 문서를 작성했습니다. 상위 문서 7개 (전역 가이드), 도메인 문서 21개 (docs/domains/), Admin 하위 6개, src domain.md 22개 (코드 위치 요약 + 메타데이터)입니다.
주요 문서 역할은 다음과 같습니다. START.md (65줄)는 AI 작업 시작점, quick.md (120줄)는 프로젝트 전체 구조, ai-rules.md (331줄)는 행동 규칙입니다.
시스템 점검 체크리스트
저도 4계층 정보 구조를 구축할 때 이 항목들을 확인합니다. AI용 문서 시스템을 구축한다면 참고하시면 좋을 것 같습니다.
- Layer 1 오케스트레이션: ai-rules.md에 작업별 필수 문서 매핑이 명확한가?
- Layer 2 요약: START.md가 65줄 이내로 전체 프로젝트를 요약하는가?
- Layer 3 인덱스: AI_INDEX.md에 DOC-ID 시스템 으로 모든 문서를 매핑했는가?
- Layer 4 상세: domain/, spec/, recipes/ 폴더에 상세 문서가 체계적으로 정리되어 있는가?
- 토큰 절약: START.md만 읽고도 AI가 다음 문서를 찾을 수 있는가?
마무리
이번 글에서는 4계층 정보 구조를 설계하고 실제로 56개의 문서를 작성한 과정을 공유했습니다.
핵심 원칙을 다시 정리하면, Single Source of Truth (규칙은 한 곳에서만 정의), Progressive Disclosure (필요한 만큼만 단계적으로 정보 제공), 트리거 기반 탐색 (키워드로 관련 문서 자동 선택), 메타데이터 우선 (YAML 메타데이터로 빠른 판단), Living Document (코드와 함께 진화하는 문서)입니다.
다음 글에서는 이 문서 시스템의 실제 효과를 다룹니다. 토큰 절감률, 응답 시간 개선, 운영 가이드 등을 공유하겠습니다.
참고 :
https://docs.cursor.com/context/rules-for-ai
https://martinfowler.com/bliki/DocumentationAsCode.html
https://adr.github.io/
