# 토큰 경제성 평가: B (기본 원칙 준수, 비효율 지점 존재)
- Task 1~3 메모리 유지 + Task 4 단일 write_file, ID 중심 참조, Top 5 상세 + 나머지 요약, 2,000단어 제한 등 기본적인 토큰 절약 원칙은 잘 수립되어 있습니다.
- 그러나 Task 1에서 7개 파일을 전량 로드하는 것은 비효율적입니다. 
- 특히 client_meeting.md는 "배경 정보(참조용)"으로만 사용되는데, 면담록은 통상 수천 토큰에 달합니다. 
- Stage 1에서 이미 구조화한 client_goal.json과 BO.json이 면담록의 핵심을 포함하고 있으므로, client_meeting.md의 전량 로드는 중복이며 불필요합니다. 
- 마찬가지로 evidence_indexed.json은 Stage 3에서 증거 현황 확인용으로만 쓰이는데, 실제로 필요한 것은 각 BO의 Evidence 배열에 이미 내장된 증거 참조 정보이므로, 별도 로드의 한계효용이 낮습니다.
- case_kinds.md도 전체 taxonomy를 컨텍스트에 올리는 대신, 사건의 ActionType/Legal_Keywords 기반으로 관련 소송대분류를 먼저 좁힌 후 해당 부분만 참조하는 2단계 접근이 더 경제적입니다.

# 토큰 경제성을 증대하기 위한 세부적인 해결책
### 1. 현재 방식의 문제점

현재 `Prompt_Stage_3_tbu_edit.txt`의 Task 1 ([1-1] 파일 로드)은 **7개 필수 파일을 일괄 로드**합니다. 이 중 `case_kinds.md`는 **한국 민사소송 전체 사건종류 분류 체계**를 담고 있습니다.

이 파일의 구조는 3계층입니다:

```
소송대분류(6종) → 분쟁유형(18종) → 사건종류(수백 종)
```

구체적으로 보면, 파일 전체가 context window에 올라갈 때 가장 토큰을 많이 소비하는 부분은 **"이행의 소 > 금전의 지급을 구하는 소"** 행입니다. 이 행 하나에만 약 55개 이상의 사건종류 문자열이 쉼표로 나열되어 있습니다 (대여금 청구, 계금 청구, 계약금 청구, 공사대금 청구 … 하자보수비·할부대금·화해금·확약금·환급금·회원가입비 등). 여기에 확인의 소(8개 분쟁유형), 형성의 소, 가사소송, 가족관계등록, 행정소송까지 합하면 **전체 taxonomy가 약 1,500~2,000 토큰**을 차지합니다.

문제의 핵심은 이것입니다: **실제 사건에서 관련 있는 소송대분류는 보통 1~2개**인데, 6개 대분류 전체를 무조건 로드하고 있다는 점입니다. 이 사건을 예로 들면, BO.json의 27개 행위 중 어떤 것도 가사소송, 가족관계등록, 행정소송과 관련이 없습니다. 확인의 소와도 관련이 없습니다. 그런데도 이 카테고리들이 전부 context에 올라가서 토큰을 소비하고, 더 나쁘게는 에이전트의 attention을 분산시킵니다.

---

### 2. 2단계 접근법의 원리

핵심 아이디어는 간단합니다: **BO.json에 이미 사건종류를 좁힐 수 있는 강력한 단서가 들어 있으므로, 이 단서를 먼저 활용하여 taxonomy의 검색 범위를 좁힌 후, 좁혀진 범위 내에서만 exact-match를 수행**하는 것입니다.

BO.json의 각 행위에는 두 가지 핵심 필드가 있습니다:

**(a) `ActionType`** — Stage 1에서 부여한 행위 유형 분류 (11종 enum):

```
법률행위, 준법률행위, 사실행위, 위법행위, 채무불이행, 
재산처분, 보전행위, 소송행위, 행정행위, 법적사건, 불법행위
```

**(b) `Legal_Keywords`** — 각 행위의 법적 성격을 요약하는 법률 키워드 배열

이 두 필드의 조합은 해당 행위가 어떤 **소송대분류** 및 **분쟁유형**에 해당하는지를 매우 높은 정확도로 예측합니다. 왜냐하면 ActionType과 Legal_Keywords 자체가 Stage 1에서 법적 분석을 거쳐 부여된 값이기 때문입니다.

---

### 3. 1단계: BO.json 필드 → 소송대분류 범위 축소

#### 3.1 매핑 규칙 테이블

프롬프트에 아래와 같은 **결정적(deterministic) 매핑 규칙**을 삽입합니다. 이 테이블 자체는 약 200토큰이면 충분하며, 전체 taxonomy 2,000토큰보다 훨씬 경제적입니다:

```
[소송대분류 사전 필터링 규칙]

Legal_Keywords에 아래 키워드가 포함되면 → 해당 소송대분류를 후보에 포함:

이행의 소:
  금전 지급 → "대여금", "소비대차", "보증채무", "구상금", "구상권",
               "손해배상", "부당이득", "매매대금", "임대료", "보증금",
               "보험금", "약정금", "위약금", "투자금", "배상금"
  물건 인도 → "인도", "명도", "점유", "반환"
  의사 진술 → "소유권이전", "등기", "말소등기", "명의신탁"

형성의 소:
  → "사해행위", "채권자취소권", "공유물분할", "결의취소"

확인의 소:
  → "소유권확인", "채권부존재", "지위확인", "권리확인"

가사소송:
  → "이혼", "혼인", "친생자", "양육", "재산분할(가사)"

행정소송:
  → "행정처분", "취소소송", "행정심판"

ActionType 보조 규칙:
  "재산처분" + "사해행위" → 형성의 소 강화
  "채무불이행" → 이행의 소(금전 지급) 관련 가능성 강화
  "행정행위" → 행정소송 후보 포함
```

#### 3.2 이 사건에 적용한 구체적 시연

이 사건의 BO.json 27개 행위에서 추출되는 Legal_Keywords를 **중복 제거 후** 취합하면:

```
근저당권, 담보설정, 물권행위, 대여금, 금전소비대차, 채권행위,
연대보증, 보증채무, 인적담보, 임대차, 임차보증금, 주택임대차,
신용보증, 구상권, 구상채무, 기한연장, 이자변제, 기한이익상실,
부도, 채무불이행, 대위변제, 변제자대위, 가압류, 보전처분, 
채권보전, 사해행위, 대물변제, 채권자취소권, 소유권이전,
임의경매, 담보권실행, 부동산매매, 채무인수, 변제, 채무소멸,
배당, 경매, 채권회수, 전득자
```

이것을 위의 매핑 규칙에 대입하면:

| 매칭된 키워드 | → 소송대분류 |
|---|---|
| "대여금", "금전소비대차" | 이행의 소 (금전 지급) |
| "보증채무", "구상금", "구상권" | 이행의 소 (금전 지급) |
| "소유권이전" | 이행의 소 (의사 진술) |
| "사해행위", "채권자취소권" | **형성의 소** |
| (확인 관련 키워드 없음) | 확인의 소 → **제외** |
| (가사 관련 키워드 없음) | 가사소송 → **제외** |
| (행정 관련 키워드 없음) | 행정소송 → **제외** |

**1단계 결과**: 이 사건의 관련 소송대분류는 **「이행의 소」와 「형성의 소」 두 가지만**입니다. 나머지 4개 대분류(확인의 소, 가사소송, 가족관계등록, 행정소송)는 완전히 배제됩니다.

---

### 4. 2단계: 축소된 범위 내에서 분쟁유형/사건종류 결정

1단계에서 소송대분류가 「이행의 소」와 「형성의 소」로 좁혀졌으면, **해당 부분의 taxonomy만 참조**합니다. 구체적으로 두 가지 구현 방식이 가능합니다:

#### 방식 A: 조건부 부분 로드 (런타임 필터링)

프롬프트에 다음과 같이 지시합니다:

```
[2-3 사건종류 결정]

1단계: BO.json의 Legal_Keywords를 취합하여 [소송대분류 사전 필터링 규칙]을 
적용한다. 관련 소송대분류 목록을 확정한다.

2단계: case_kinds.md를 read_doc으로 읽되, 1단계에서 확정된 소송대분류에 
해당하는 행만 추출하여 사용한다. 나머지 행은 무시한다.

3단계: 추출된 범위 내에서 taxonomy exact-match 원칙을 적용하여 각 청구권의 
분쟁유형과 사건종류를 결정한다.
```

이 방식은 `case_kinds.md`를 여전히 로드하지만, 에이전트가 **관련 없는 행을 즉시 버리라고 명시적으로 지시**하므로 후속 처리에서 토큰 낭비가 줄어듭니다.

#### 방식 B: 프롬프트 내 인라인 축약 (파일 로드 자체를 최소화)

더 극단적으로, 소송대분류별 핵심 사건종류만 프롬프트에 인라인으로 넣는 방식입니다:

```
[소송대분류별 핵심 분쟁유형 → 사건종류 매핑]

이행의 소:
  금전 지급 → 대여금 청구, 보증채무금 청구, 구상금 청구, 
              손해배상 청구, 부당이득금·이득상환금 청구, 
              임차 및 전세보증금 청구, 투자금반환 청구, ...
  특정물 인도 → 건물의 명도(인도)의 소, 점유회수(반환)청구의 소, ...
  의사 진술 → 매매를 원인으로 한 소유권이전등기 청구, 
              대물반환·대물변제 등을 원인으로 한 소유권이전등기 청구, ...

형성의 소:
  → 사해행위취소 청구, 공유물분할 청구, 청구이의, ...
```

하지만 이 방식은 **모든 사건종류를 인라인 나열하면 taxonomy 완전성이 깨질 수 있고**, exact-match 원칙에 위배될 수 있습니다. 따라서 실무적으로는 **방식 A가 더 안전**합니다.

#### 권장 방식: A와 B의 혼합

```
1단계 필터링: Legal_Keywords 기반 매핑 규칙 (프롬프트 인라인, ~200 토큰)
2단계 참조: case_kinds.md 파일 읽기, 필터링된 소송대분류 행만 attention에 사용
```

---

### 5. 분쟁유형 수준까지 추가 축소 (선택적 3단계)

1단계에서 소송대분류를 축소한 후, Legal_Keywords를 한 번 더 활용하면 **분쟁유형 수준까지 축소**할 수 있습니다. 이것은 특히 「이행의 소」처럼 분쟁유형이 5개나 되고, 금전 지급 유형 하나에만 55개 이상의 사건종류가 나열되어 있는 경우에 효과가 큽니다.

이 사건의 경우:

```
Legal_Keywords에 "대여금", "보증채무", "구상금"이 있고
"인도", "명도"가 없으므로

→ 이행의 소 내에서도 「금전의 지급을 구하는 소」와 
  「의사의 진술을 구하는 소」만 관련됨
→ 「종류물의 지급 또는 인도를 구하는 소」, 
  「특정물의 인도를 구하는 소」, 
  「특수한 유형의 이행의 소」는 제외
```

이렇게 하면 **이행의 소의 5개 분쟁유형 중 2개만 남기고 3개를 추가 제거**합니다.

---

### 6. 토큰 절감 효과 정량 분석

`case_kinds.md` 원문을 대략적으로 측정하면:

| 소송대분류 | 추정 토큰 수 | 이 사건 관련성 |
|---|---|---|
| 이행의 소 (5개 분쟁유형) | ~800 토큰 | **관련 (2/5 분쟁유형만)** |
| 확인의 소 (8개 분쟁유형) | ~400 토큰 | 무관 — 전량 절감 |
| 형성의 소 | ~100 토큰 | **관련** |
| 가사소송 | ~100 토큰 | 무관 — 전량 절감 |
| 가족관계등록 | ~20 토큰 | 무관 — 전량 절감 |
| 행정소송 | ~80 토큰 | 무관 — 전량 절감 |
| **합계** | **~1,500 토큰** | |

2단계 접근법 적용 시:

| 항목 | 토큰 |
|---|---|
| 매핑 규칙 테이블 (프롬프트 인라인) | ~200 토큰 |
| 필터링 후 실제 참조 범위 | ~400 토큰 (이행의 소 일부 + 형성의 소) |
| **합계** | **~600 토큰** |

**절감량: 약 900 토큰 (60% 절감)**

이 수치 자체는 작아 보일 수 있지만, 두 가지 추가 효과가 있습니다:

**(a) Attention 집중 효과**: 에이전트가 context window에서 관련 없는 55개 사건종류(계금 청구, 공제금 청구, 수표금 청구 등)를 걸러내느라 attention을 소비하지 않아도 됩니다. 이것은 토큰 수로 측정되지 않지만 **분류 정확도에 직접 영향**을 줍니다.

**(b) `client_meeting.md` 절감과의 복합 효과**: 기준 3 평가에서 지적한 `client_meeting.md` 전문 로드 문제와 합하면, 총 절감량은 상당히 커집니다. 실제 Stage 3 전체에서 불필요 토큰을 체계적으로 줄이면 **2,000~3,000 토큰 절감**이 가능하며, 이는 output 할당량(청구전작업.md ≤2,000단어)과 맞먹는 여유를 확보하는 것입니다.

---

### 7. 프롬프트 구현 방안

현재 프롬프트의 Task 2 [2-3]을 다음과 같이 수정합니다:

**현재 (Before):**

```
[2-3] 사건종류 결정

case_kinds.md taxonomy 기준 exact-match:
- taxonomy에 존재하는 문자열만 복사
- 불확실하면 back-off (사건종류 null → 분쟁유형까지만)
```

**개선안 (After):**

```
[2-3] 사건종류 결정 (2단계 접근)

■ 1단계 – 소송대분류 범위 축소
  BO.json 전체의 Legal_Keywords를 취합하고, 아래 [매핑 규칙]을 
  적용하여 관련 소송대분류 목록(1~2개)을 확정한다.

  [매핑 규칙]
  - "대여금"|"소비대차"|"보증채무"|"구상금"|"손해배상"|"부당이득"|
    "매매대금"|"임대료"|"보증금"|"약정금" 중 하나 이상 → 이행의 소
  - "소유권이전"|"등기"|"말소등기"|"명의신탁" → 이행의 소
  - "인도"|"명도"|"점유" → 이행의 소
  - "사해행위"|"채권자취소권"|"공유물분할"|"결의취소" → 형성의 소
  - "소유권확인"|"채권부존재"|"지위확인" → 확인의 소
  - "이혼"|"혼인"|"친생자"|"양육" → 가사소송
  - "행정처분"|"취소소송" → 행정소송
  - 매칭 없는 키워드 → 무시 (보전행위, 경매 등은 소송유형이 아님)

■ 2단계 – 축소 범위 내 exact-match
  case_kinds.md를 읽되, 1단계에서 확정된 소송대분류에 해당하는 
  행(row)만 참조한다. 나머지 행은 무시한다.
  
  참조 범위 내에서 taxonomy exact-match 원칙 적용:
  - taxonomy에 존재하는 문자열만 복사
  - 불확실하면 back-off (사건종류 null → 분쟁유형까지만)
```

---

### 8. 일반화 관점의 보너스 효과

이 2단계 접근법은 **기준 1(일반성)**에도 기여합니다. 어떤 사건이 들어오더라도:

- 가사소송 사건이면 → Legal_Keywords에 "이혼", "양육" 등이 있을 것이므로 → 가사소송만 남김
- 행정소송 사건이면 → "행정처분" 등이 있을 것이므로 → 행정소송만 남김
- 복합 사건(이행 + 형성)이면 → 두 대분류가 동시에 남음

즉, **사건 유형에 무관하게 동일한 메커니즘으로 자동 필터링**이 작동하며, 이것이 프롬프트의 범용성을 유지하면서도 토큰 효율성을 높이는 핵심입니다. 전체 taxonomy를 컨텍스트에 올리는 것은 "어떤 사건이든 대응할 수 있도록" 하기 위한 것이었지만, BO.json의 Legal_Keywords가 이미 그 판단을 대신할 수 있으므로 **범용성을 희생하지 않고도 경제성을 확보**할 수 있습니다.