Kakao Chat Analysis

카카오톡 대화 논의 분석

이 스킬이 만드는 것

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

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

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

절차

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

1. 파싱

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로 고정한다. 여러 줄 메시지, 사진/이모티콘/파일 표시, 삭제된 메시지는 스크립트가 처리한다.

소규모 방(28명)과 오픈채팅(수십수백 명)은 읽는 방식이 다르다. 소규모 방은 모든 화자에게 역할 프로필을 쓴다. 오픈채팅은 메시지 수 상위 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/에 있다. 다 쓰면 검사한다:

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 두 가지

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 이내)만 확인하고 넘어간다. 검증에 쓰는 시간이 분석 시간보다 길어지면 안 된다. 실명·계약·소송이 들어 있는 대화가 대부분이므로 공개 아티팩트로 게시하지 말고 파일로 준다.

상태 판정 기준

"흐지부지"와 "정보공유"를 헷갈리기 쉽다. 누군가 답을 기다렸는지가 기준이다. 질문·요청·경고가 있었는데 답이 없으면 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 배경색 유지).