---
task_id: task-2064
type: context
scope: task
created: 2026-04-21
updated: 2026-04-21
status: in-progress
---

# 맥락 노트: task-2064

**task**: task-2064

---

## 결정 근거

### 3 Step Why

**1st Why: "왜 이 설계가 필요한가?"**
A: 정제 프로세스가 24% 시점에서 crash하여 카카오톡 인사이트 추출이 완료되지 못한다. PID 2083447이 이미 죽어있고, output 디렉토리도 생성되지 않았다. task-2057에서 체크포인트 mkdir을 수정했지만 다른 원인으로 재crash.

**2nd Why: "왜 A(subprocess 에러 핸들링 강화)가 최선의 접근인가?"**
B: `_call_claude()` 함수가 `subprocess.run(timeout=120)`을 호출하지만, `subprocess.TimeoutExpired`를 명시적으로 처리하지 않아 자식 프로세스 좀비화 + 메모리 누수 가능성이 있다. 24%에서 crash하는 것은 약 30번의 LLM 호출 이후이며, 반복적 subprocess 생성으로 리소스가 누적될 수 있다. dmesg에 OOM 흔적이 없으므로 단순 메모리 초과보다는 subprocess 관리 문제가 유력하다.

**3rd Why: "왜 B가 다른 대안보다 나은가?"**
C: 대안1(배치 크기 축소)은 근본 원인을 해결하지 않으며, 대안2(전체 try/except)는 에러 정보를 잃어 디버깅이 어렵다. subprocess 에러 핸들링 강화(TimeoutExpired 명시적 처리 + 자식 프로세스 kill + 상세 로깅)는 crash 원인을 특정하면서도 안전하게 fallback 경로로 진행할 수 있게 한다.

### 핵심 분석 결과

1. **dmesg OOM 흔적 없음** → 리눅스 OOM killer가 아닌 프로세스 내부 문제
2. **output 디렉토리 미존재** → 프로세스가 배치 저장 전에 crash (배치 1~2에서 이미 죽음)
3. **24% = 약 30 스레드 처리** → 반복적 subprocess 호출 30회 이후 실패
4. **progress 파일 미존재** → 프로세스가 극초기에 crash되거나 output_dir 자체가 생성 안 됨
5. `_call_claude()`: TimeoutExpired 미처리, stdout 전량 메모리 적재, subprocess 좀비 위험

## 참조 자료

- task-2057 보고서: `/home/jay/workspace/memory/reports/task-2057.md`
- 핵심 파일: `/home/jay/projects/insuwiki/scripts/kakao_knowledge/knowledge_extractor_v2.py`
- 테스트 파일: `/home/jay/projects/insuwiki/scripts/kakao_knowledge/tests/test_knowledge_extractor_v2.py`

## 주의사항

- insuwiki는 workspace와 별도 git 레포 — worktree는 insuwiki 레포에서 생성
- `_call_claude()`는 `/home/jay/.local/bin/claude` CLI를 subprocess로 호출
- 테스트에서 실제 LLM 호출은 모킹 필요