# Kakao Chat Analysis

> 카카오톡 대화 내보내기(.txt, PC·모바일 형식)를 처음부터 끝까지 읽고 "이 방에서 어떤 논의가 있었는가"를 정리한 보고서를 HTML과 PDF 두 가지로 만든다. 화자가 몇 명이고 각자 어떤 역할인지, 날짜별로 무슨 논의가 있었는지, 주제(스레드)별로 이야기가 어떻게 시작되어 발전했는지, 누가 후속을 맡았는지, 해결됐는지·담당만 정해졌는지·진행 중인지·답 없이 사라졌는지를 근거와 함께 보여준다. 사용자가 카톡/카카오톡/단톡방/오픈채팅 대화 파일이나 채팅 로그를 주면서 "분석해줘", "무슨 얘기 했는지 정리해줘", "대화 요약", "주제 흐름", "누가 뭘 맡았는지", "결론이 뭐였는지", "논의 정리"라고 하면 반드시 이 스킬을 사용한다. 파일명이 KakaoTalk_*.txt이거나 "[이름] [오전 h:mm]" 또는 "2025년 1월 5일 오후 3:12, 이름 :" 형식의 텍스트가 보이면 명시적 요청이 없어도 이 스킬을 쓴다.

- Skill: `lumin-on/kakao-chat-analysis` (Agent Skill, multi-file: 13 files)
- Install (CLI): `npx skillmds@latest add lumin-on/kakao-chat-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lumin-on/kakao-chat-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: lumin-on (https://skillmd.com/u/lumin-on)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/lumin-on/kakao-chat-analysis

---


# 카카오톡 대화 논의 분석

## 이 스킬이 만드는 것

사람이 읽는 보고서 한 장을 HTML과 PDF로. (카톡으로 주고받을 때는 PDF, 링크·툴팁이 필요하면 HTML.) 답하는 질문은 다섯 개다.

1. 누가 말했고, 각자 이 방에서 어떤 역할인가
2. 날짜별로 어떤 논의가 있었나
3. 주제(스레드)별로 이야기가 어떻게 시작되어 어떻게 발전했나
4. 그 주제를 누가 이어받아 처리했나
5. 어떻게 끝났나: 해결 / 담당 지정 / 진행 중 / 흐지부지 / 단순 정보공유

보고서에 **넣지 않는 것**: 파싱 규칙 설명, 분석 방법론 카탈로그, 향후 분석 로드맵, 키워드 빈도표. 사용자는 "무슨 논의가 있었는지"를 알고 싶은 것이라 방법 설명은 읽히지 않는다. 파싱 조건은 각주 한 줄이면 충분하다. 정량 차트는 논의의 리듬을 보여주는 일별 막대 하나만 쓴다.

## 절차

작업 폴더는 원본 파일 옆의 `.kakao-analysis/<원본 파일명(확장자 제외)>/`로 고정한다. 파싱 결과, 구간 노트(`notes/`), `analysis.json`이 여기 남으므로 나중에 analysis.json만 고쳐 다시 렌더할 수 있고, 같은 파일을 다시 분석할 때 이전 판정과 비교할 수 있다. 최종 보고서는 원본 옆에 `<방 이름을 짧게>_논의분석.html`과 `.pdf`로 둔다.

### 1. 파싱

```bash
python <skill>/scripts/parse_kakao.py "<대화파일.txt>" --out "<원본 폴더>/.kakao-analysis/<파일명>"
```

PC 내보내기(`[이름] [오전 h:mm]`), 안드로이드(`2025년 1월 5일 오후 3:12, 이름 : `), iOS(`2025. 1. 5. 오후 3:12, 이름 : `) 형식을 자동 인식한다. 결과물:

- `messages.json` — 메시지 배열(id, ts, speaker, text, kind)
- `stats.json` — 화자별·일별·시간대별 집계, 세션, 파일·링크 목록 (보고서 렌더링에 사용)
- `chunks/YYYY-MM-DD.txt` — 날짜별 원문 (`#id [HH:MM] 화자: 본문`), 읽기용
- `chunks/index.txt` — 날짜별 건수와 **서브에이전트 분담 제안**

콘솔에 화자 수와 상위 화자, 봇, 입장·퇴장 시스템 메시지 수가 찍힌다. 붙여넣은 대본·공지 속 `[진행자]`, `[자막]` 같은 대괄호 태그는 타임스탬프가 없어 화자로 잡히지 않는다. 화자 수가 예상과 다르면 `--speakers 이름1,이름2`로 고정한다. 여러 줄 메시지, 사진/이모티콘/파일 표시, 삭제된 메시지는 스크립트가 처리한다.

**소규모 방(2~8명)과 오픈채팅(수십~수백 명)은 읽는 방식이 다르다.** 소규모 방은 모든 화자에게 역할 프로필을 쓴다. 오픈채팅은 메시지 수 상위 5~8명과 운영자·공지 담당만 프로필을 쓰고, 나머지는 "질문하고 사라지는 참여자", "링크만 던지는 참여자"처럼 유형으로 묶는다(렌더러도 상위 7명 + '그 외 N명'으로 차트를 그린다). `오픈채팅봇` 같은 봇은 건수에는 남기되 역할 분석에서는 뺀다. 오픈채팅에서는 "질문 → 답변 → 감사"로 끝나는 짧은 스레드가 많으므로, 스레드는 답이 달렸는지(done)·아무도 답하지 않았는지(drop)가 핵심이고, 운영자의 공지·이벤트가 며칠에 걸쳐 이어지는 것이 긴 스레드가 된다.

### 2. 읽기 — 요약이 아니라 원문을 읽는다

`chunks/`를 **전부** 읽는다. "흐지부지"는 답이 없는 자리를 봐야 보이고, "누가 이어받았는지"는 요청과 응답의 거리에서 보이기 때문에, 키워드 검색이나 앞부분 샘플링으로는 이 보고서를 만들 수 없다.

- 총 1,500건 이하: 직접 날짜순으로 읽으면서 `references/reading-guide.md`의 **구간 노트 양식**으로 메모한다.
- 그 이상: `chunks/index.txt`의 분담 제안대로 날짜 구간을 나눠 서브에이전트에 맡긴다(구간당 600~1,000건). 각 에이전트에게 `reading-guide.md`의 **읽기 프롬프트**를 그대로 주고 `notes/partN.md`에 저장하게 한다. 구간 경계에서 스레드가 잘리므로, 에이전트에게 "다음 날로 이어짐"을 표시하도록 요구하고 통합 단계에서 이어 붙인다.

읽을 때 붙잡을 것: 누가 처음 꺼냈나, 누가 받았나, 요청("해줘")에 응답("했어")이 왔나, 마지막 발화가 무엇이고 그 뒤 얼마나 조용했나, 같은 실체(사람·사업·문서)가 며칠 뒤 다시 나오나. 붙여넣은 장문(광고 카피, AI 산출물, 공지문)은 그 사람의 말이 아니라 가져온 자료다.

### 3. 통합 — analysis.json 작성

구간 노트를 모두 읽고 `analysis.json`을 쓴다. 스키마·기입 예시·요약 작성 규칙은 `references/reading-guide.md`에 있고, 완성 예시 한 벌(대화 → 노트 → analysis.json)이 `assets/example/`에 있다. 다 쓰면 검사한다:

```bash
python <skill>/scripts/check_analysis.py --data <작업폴더> --analysis <작업폴더>/analysis.json
```

오류(날짜 누락, 화자 이름 불일치, 상태 코드 오타, 그룹 누락)는 고쳐야 렌더가 되고, 경고(요약 개수, flow 길이, 확인 포인트 누락)는 가능한 한 없앤다. 이 검사가 "매번 같은 구조·같은 깊이"를 보장하는 장치다. 핵심 규칙:

- **스레드 병합**: 같은 실체가 다른 날 다시 등장하면 하나의 스레드다. 제목은 변화가 드러나게 짓는다(`단체티 주문: 견적 담당 지정 → 기한 2회 연기 → 미이행`). 20일치 대화에서 보통 15~25개가 나온다. 하루짜리 잡담은 스레드로 만들지 말고 날짜별 다이제스트에만 남긴다.
- **상태 판정** (아래 기준표) 은 마지막 언급을 기준으로 하되, 근거 발화를 `end`에 적는다.
- **날짜별 다이제스트**: 하루에 한 줄, 그날 오간 논의를 시간순으로. 조용한 날(2~3건)도 "○○ 링크만 공유"처럼 적어 리듬이 보이게 한다.
- **화자 프로필**: 발화량이 아니라 *무엇을 가져오는지*(정보·실행·검토·요청·격려)와 *누구에게 어떻게 반응하는지*로 쓴다. 근거가 되는 발화를 한두 개 인용한다.
- **핵심 요약** 5~8개: 무엇이 논의됐고, 무엇이 닫혔고, 무엇이 열려 있고, 반복되는 패턴은 무엇인지. 보고서를 여기만 읽어도 되게 쓴다.
- **그룹**: 스레드를 사업·영역 단위로 묶는다(예: 정기 산행 준비 / 회비·운영 / 친목, 또는 사업 A / 사업 B / 가족·개인). 그룹이 곧 "이 방이 굴리는 일의 목록"이 된다.

### 4. 렌더링과 전달 — HTML과 PDF 두 가지

```bash
python <skill>/scripts/build_report.py --data <작업폴더> --analysis analysis.json --out "<보고서.html>" --pdf
```

`--pdf`를 붙이면 같은 이름의 `.pdf`가 옆에 생긴다(설치된 Edge/Chrome을 헤드리스로 띄워 인쇄, 별도 라이브러리 불필요). 결과는 카카오톡으로 주고받는 경우가 많아 PDF가 기본이고 HTML은 링크·툴팁이 살아 있는 상세판이다. **둘 다 전달한다.** 브라우저가 없다는 오류가 나면 `--browser <경로>`로 지정하거나, 그래도 안 되면 HTML만 주고 이유를 말한다. `--anonymize`는 화자 이름·별칭을 화자A·B·C로 바꾼다(외부 공유용).

전달 전에 HTML을 한 번 열어 스레드 카드와 일별 차트가 보이는지 확인한다. 화면 캡처가 안 되는 환경(창 최소화, 헤드리스)이면 캡처를 반복 시도하지 말고 렌더러가 출력한 스레드·일자·화자 수와 PDF 크기(보통 1MB 이내)만 확인하고 넘어간다. 검증에 쓰는 시간이 분석 시간보다 길어지면 안 된다. 실명·계약·소송이 들어 있는 대화가 대부분이므로 공개 아티팩트로 게시하지 말고 파일로 준다.

## 상태 판정 기준

| 상태 | 코드 | 이렇게 보이면 |
|---|---|---|
| 해결·결정 | `done` | 결과물이나 결정이 대화 안에서 확인된다("반영해뒀어"+캡처, "○○로 하자"에 동의). |
| 담당 지정 | `assigned` | 누가 하겠다고 했거나 지목됐지만 이행 확인이 없다("내일 보낼게" 뒤 조용). |
| 진행 중 | `open` | 마지막 언급이 작업 중이거나 다음 일정이 잡혀 있다. |
| 흐지부지 | `drop` | 질문·제안·경고 뒤 응답이 없다, 또는 조언이 기각되고 끝났다, 또는 재언급 없이 사라졌다. |
| 정보공유 | `info` | 결정을 요구하지 않는 공유·잡담·구두 다짐. |

"흐지부지"와 "정보공유"를 헷갈리기 쉽다. 누군가 답을 기다렸는지가 기준이다. 질문·요청·경고가 있었는데 답이 없으면 `drop`, 처음부터 답을 기대하지 않은 공유면 `info`.

"담당 지정"과 "진행 중"도 갈린다. 담당자가 정해졌고 약속한 기한이 지났는데 결과물이 없으면(독촉에 "곧 할게요"만 반복) `assigned`로 두고 배지에 "2회 연기"처럼 적는다. 담당자가 실제 작업물(초안·중간 결과)을 올리며 진행하고 있으면 `open`이다. 독자가 "열려 있거나 사라진 것" 표에서 *누구를 찔러야 하는지*를 바로 알 수 있게 하는 것이 목적이다.

## 쓰기 규칙

- 흐름은 날짜 순서로 `→`를 써서 압축한다. 한 스레드의 `flow`는 5~10문장.
- 인용은 짧게, 그 사람의 말투 그대로. 평가 언어("회피", "기각")는 대화 안의 근거가 있을 때만 쓰고, 추론은 (추정)을 붙인다.
- 비밀번호, 계좌·접근번호, 주민번호, 전화번호는 옮기지 않는다. 대화에 노출돼 있었다는 사실만 요약에 한 줄 적는다.
- 보고서 언어는 대화 언어를 따른다(한국어 대화면 한국어).

## 같은 결과가 나오게 하는 네 가지 장치

결과의 일관성은 모델의 기분이 아니라 다음 네 가지에서 나온다. 하나라도 건너뛰면 보고서가 달라진다.

1. **원문 전부 읽기** — 샘플링·키워드 검색 금지. 큰 파일은 구간을 나눠 위임하되 각 구간은 끝까지 읽는다.
2. **고정된 판정표** — 위의 상태 5분류와 담당 지정/진행 중 구분 기준. 판정 근거 발화를 `end`에 남긴다.
3. **스키마 검사** — `check_analysis.py`가 섹션 구성과 깊이를 강제한다. 경고를 0에 가깝게 만든 뒤 렌더한다.
4. **고정 렌더러** — 보고서 구성(한눈에 보기 → 화자와 역할 → 날짜별 논의 → 주제별 흐름과 결말 → 열려 있거나 사라진 것 → 용어집)과 스타일은 `build_report.py`가 정하며, 손으로 HTML을 쓰지 않는다. 추가 섹션이 필요하면 렌더러를 고쳐 다음 분석에도 적용되게 한다.

같은 파일을 다시 분석해 달라는 요청이면 `.kakao-analysis/<파일명>/analysis.json`이 있는지 먼저 확인하고, 있으면 그것을 기준으로 바뀐 부분만 다시 읽는다.

## 참고 파일

- `references/reading-guide.md` — 구간 노트 양식, 서브에이전트용 읽기 프롬프트, analysis.json 스키마와 기입 예시, 병합 규칙, 요약·다이제스트·프로필 작성 규칙, 완료 기준 체크리스트. **2단계 시작 전에 읽는다.**
- `assets/example/` — 완성 예시(대화 39건 → 구간 노트 → analysis.json). 깊이와 말투의 기준.
- `scripts/parse_kakao.py` — 파서. `--gap 60`(세션 공백 분), `--speakers`, `--encoding` 옵션.
- `scripts/check_analysis.py` — analysis.json 검사. 렌더러가 자동 호출.
- `scripts/build_report.py` — 렌더러. `--pdf`, `--anonymize`, `--title`, `--browser`, `--force` 옵션.
- `scripts/export_pdf.py` — HTML → PDF 단독 실행용(Chrome/Edge 헤드리스 인쇄, HTML 배경색 유지).