# Kei API Dependency Map

## 목적
이 문서는 현재 `design_agent`에서 `Kei API`가 개입하는 지점과, 앞으로 위키/이슈/에이전트 기반으로 대체해야 하는 지점을 정리한다.

## 현재 Kei API 의존 단계
### 1. classify_content
현재 `Kei API`는 콘텐츠의 주요 꼭지와 관계를 추출하는 역할을 맡는다.

현재 기대되는 성격:
- topic 추출
- relation_type 정리
- expression_hint 초안
- source_data 초안

### 2. refine_concepts
현재 `Kei API`는 추출된 개념을 더 정제하는 역할을 맡는다.

현재 기대되는 성격:
- 핵심/보조 정보 정리
- concept 정제
- relation 보강
- expression_hint 보강
- source_data 보강

## 왜 이 구간이 중요한가
이 두 단계는 단순한 전처리가 아니다.
후속 단계가 어떤 내용을 어느 정도 강조하고 어떤 방식으로 표현할지에 직접 영향을 준다.

즉, 이 구간은 디자인보다 앞선 `의미 판단 단계`다.

## 앞으로의 대체 방향
이 구간은 다음 구조로 옮겨가야 한다.

- 위키 1: 판단 원칙 제공
- 위키 2: 현재 작업 절차 제공
- 위키 3: Stage 1A/1B의 입력/출력/검증 기준 제공
- 이슈: 현재 작업의 실제 입력과 해석 결과 기록
- Codex/Claude: 위 문서를 읽고 topic, concept, hint, source를 직접 정리

즉, API 호출이 아니라 `문서 기반 해석 + 작업 기록 기반 누적`으로 전환한다.

## 대체 후 남아야 하는 정보
Kei API를 없애더라도 아래 정보는 반드시 남아야 한다.

- 핵심 topic
- topic 간 relation
- refined concept
- expression hint
- source data
- 검증 기준

이 정보가 없으면 후반부 코드가 무엇을 중심으로 만들어야 하는지 흔들린다.

## 2단계로 넘길 핵심 질문
- Stage 1A 결과를 어떤 포맷으로 남길 것인가
- Stage 1B 결과를 어떤 포맷으로 남길 것인가
- 이 결과를 이슈에만 남길지, json 산출물로도 남길지
- `src/kei_client.py`를 완전히 제거할지 fallback으로 남길지

## 1단계 결론
현재 `Kei API`는 `design_agent` 전체가 아니라, 초반의 의미 해석과 개념 정제 구간에 집중적으로 묶여 있다.
따라서 2단계에서는 이 구간만 잘 외부화하면 후반부 코드 자산을 상당 부분 유지할 수 있다.
