1. 하려던 것
* 제작한 콘텐츠가 방송을 시작하면, 시청률·시청자 및 미디어 반응을 실시간으로 체크해서 상황에 맞게 후속 방송 준비나 대응을 해야 함. 방송 직후 흩어져 있는 이 데이터를 한 번에 모아 확인하려고 drama-deep-dive(특정 작품 반응 체크)를 만듦.
* drama-deep-dive는 "방송 직후 모드"(실시간 반응만 빠르게)와 "다음날 확장 모드"(다채널 분석+피드백/홍보 의견) 두 갈래로 나눔.
* 반응 체크와 홍보 방향 의견까지는 됐지만, 안 좋은 이슈가 발생했을 때 현재 상황을 객관적으로 체크해서 위기 리스크 관리 방법을 제안받는 기능은 없었음. 논란이 터지고 나서야 찾아보는 게 아니라, 자동으로 이슈 여부를 감지하고 실시간 시청자 반응에 맞춰 추후 홍보 방향까지 제안받고 싶었음.
* 별도 스킬을 새로 만들지 않고, 기존 drama-deep-dive의 "방송 직후 모드"·"다음날 확장 모드" 양쪽에 이슈 체크 기능을 통합하는 방향으로 결정함.
2. 활용한 툴
* Claude Code skill (SKILL.md 한 장으로 정의): drama-deep-dive 확장에 활용함.
* k-skill naver-blog-research, naver-news-search: 시청자 후기·뉴스 검색에 계속 활용함.
* Claude in Chrome: 로그인된 크롬으로 X(트위터) 실시간 검색에 활용함.
* Browser pane: 더쿠(theqoo)·IMDb 접근, group_srl 태그 URL 확인에 활용함.
* Artifact(SVG): 시청률 회차별 그래프를 외부 라이브러리 없이 순수 SVG로 직접 그리는 데 활용함.
* CronCreate( 세션 내 예약): 다음 방송 직후 자동 체크를 걸어두는 데 활용함.
* /schedule(클라우드 routine): 시도했지만 로컬 파일·Browser pane 접근이 안 돼 실제로는 못 씀.
* sources.yaml(스킬 폴더 내 데이터 소스 관리 파일): 시청률·커뮤니티·뉴스·소셜미디어·라운지 소스별 접근 방법·상태를 기록하는 데 활용함.
3. 진행 세부 내용
1️⃣ 이슈 체크 기능 설계
- 트리거 문구("이슈 대응해줘")를 따로 두려다가, "자체 판단으로 미리 알려달라"는 요청을 받고 설계를 바꿈.
- 두 모드 안에 "이슈 체크" 단계를 항상 자동으로 돌게 넣고, 신호 없으면 한 줄로 짧게, 있으면 원인·심각도·대응 옵션 2~3개(참가자가 고르게)로 구성하도록 SKILL.md에 명시함.
- 이름을 "위기 징후 자동 점검"에서 "이슈 체크"로 통일함(더 일반적이고 명료한 표현 요청).
2️⃣ 소스별 접근 방법 확립
- X는 로그인 없이 검색 자체가 막혀 있어, Claude in Chrome 연결로 실제 로그인 세션 검색이 되는 걸 확인함. get_page_text로는 내용이 안 잡히고 read_page/스크린샷으로 읽어야 함도 확인함.
- 더쿠는 게시글 본문 검색 기능 자체가 없다는 걸 확인함(헤더 돋보기는 게시판 이름 검색용). 대신 theqoo.net/dyb?group_srl=[숫자] 형태의 "작품 전용 게시물 모아보기" 태그 URL을 발견해 우선 시도 경로로 추가함(다만 모든 작품에 있는 건 아님).
- 더쿠 반응 수집 시간대를 "방송 시작 시각~+5시간"으로 고정하는 규칙을 만들고, 인용 전 게시물의 실제 타임스탬프를 확인하는 절차를 추가함.
- IMDb는 WebFetch(403)로 "없다"고 잘못 결론 냈다가, Browser pane으로 재확인해 실제로 페이지가 있음을 확인함.
- 네이버 라운지는 WebFetch·Browser pane·Claude in Chrome 세 가지 방법 모두 막혀 있어, 참가자가 직접 복사해서 붙여넣는 방식만 유효한 경로로 남김.
3️⃣ 시청률 표+그래프 신규 기능
- 최신 회차 하나만 보던 걸 "1화~오늘 기준 최신 방영분 전체" 표+그래프로 확장함.
- 외부 차트 라이브러리 없이 순수 SVG로 꺾은선 그래프를 직접 그리고, 각 점 위에 시청률 숫자를 바로 표시함.
4️⃣ 리포트 포맷 표준화
- 이슈 체크를 "소제목(한 줄 요약) + 세부 내용(- 불릿)" 3단 구조(원인/심각도/대응 옵션 또는 참고)로 재정리함.
- 채널별 반응 항목도 "요약 제목(src-summary) + 데이터값(src-stat, 키워드 N개·게시물 M건) + 원문 인용" 3단 구조로 통일함.
- 리포트 본문에서 "Claude in Chrome 로그인 세션으로 검색", "이번 검색에서" 같은 검색 방법·과정 설명 문구를 전부 빼고 결과 내용만 남기도록 정리함.
6️⃣ 실사용 장기 추적
- 오싹한 연애: 4화 → 6화까지 갱신하며 참가자가 직접 붙여준 라운지 원문과 스킬 조사 수치를 교차검증함(거의 일치 확인).
- 그대에게 드림: 6화 → 8화까지 갱신. "넷플릭스 확인 안 됨"이라 고 썼다가 "TVING 독점이라 애초에 대상이 아니다"라는 지적을 받고 "확인 안 됨"과 "해당 없음"을 구분하는 원칙을 세움.
- 유부녀 킬러: 새로 만든 작품. 남주 정준원의 예능 태도 논란이 실제로 터진 걸 이슈 체크로 잡아내고, 3·4회 시청률(8.3%→9.4%, 4회 연속 상승)로 "논란·경쟁작 등판 둘 다 시청률에 영향 없음"이라는 결론까지 실시간으로 확인함 — 이슈 체크 기능이 발생부터 해소까지 전 과정을 실제로 추적한 첫 사례가 됨.
7️⃣ 자동화 시도
- "다음 방송 직후 자동 실행을 위해 /schedule(클라우드 routine)을 먼저 시도했으나, 로컬 Browser pane·로컬 파일에 접근이 안 되서 실패함.
- 대신 CronCreate로 세션 내 1회성 예약 2건(9회·10회 방송 직후)을 만듦 — 단, 세션이 그때까지 살아있어야 실행된다는 제약이 있음을 확인.
8️⃣ 데이터 소스 정식 관리 체계 도입
- 데이터 확인에 꼭 참고해야 하는 URL 목록으로, 스킬 폴더에 sources.yaml을 만들어 소스별 URL·접근 방법(`access`)·상태(`status: ok/blocked/untested`)·주의사항을 정리함.
- SKILL.md에서 이 파일을 참고하도록 연결해, 앞으로 소스를 열기 전에 먼저 상태를 확인하고 untested를 실제로 써보면 결과를 그 파일에 계속 업데이트하는 구조로 만듦.
4. 시행착오
* 문서화한 규칙을 스스로 안 지킨 문제:
* "검색어 여러 개로 바꿔가며 검색"하는 규칙을 SKILL.md에 적어뒀는데도, "새 소식만 추가해줘" 같은 빠른 처리 요청을 받으면 검색어 1개만 쓰고 넘어간 적이 있었음.
* 표본이 작아서 "관련 반응 없음"이 나온 걸 "진짜 없음"으로 오판할 뻔한 걸 계기로, 이 규칙이 모든 소스(뉴스뿐 아니라 블로그·더쿠·스레드·X)에 동일하게 적용된다고 SKILL.md에 다시 못박음.
* 검색 실패와 해당 없음을 혼동한 문제:
* TVING 독점작의 넷플릭스 순위를 "확인 안 됨"으로 적었다가, 애초에 그 플랫폼 대상이 아니라는 지적을 받음.
* 이후 방영 플랫폼을 먼저 확인해 "검색 실패"와 "해당 없음"을 구분하는 원칙을 세움.
* 더쿠 게시물을 방송 시간대 반응으로 잘못 인용한 문제:
* WebSearch로 걸린 더쿠 링크를 확인 없이 "방송 직후 반응"으로 인용했다가, 실제 게시 시각이 다음날 오전이었던 걸 뒤늦게 발견함.
* 이후 인용 전 실제 타임스탬프를 반드시 확인하는 절차를 추가함.
* 리포트 서술 방식에 대한 수정:
* "몇 개 키워드로 몇 건 검색했는지 데이터값으로 알고 싶다"는 요청을 받아, 별도 데이터 라벨(`src-stat`)로 정리함.
* 클라우드 자동화 한 계를 뒤늦게 파악한 문제:
* "다음 방송 직후 자동으로"라는 요청을 받고 바로 /schedule을 쓰려다가, 로컬 파일·브라우저 접근이 안 되는 완전히 다른 실행 환경이라는 걸 뒤늦게 알아차림. 세션 내 예약(`CronCreate`)으로 대체함.
* 소스마다 반응 편향이 다르다는 걸 뒤늦게 확인한 문제:
* 뉴스·블로그만 보고 "호평 일색"으로 정리했다가, 키노라이츠 관람객 평점(2.2/5)과 디시인사이드 반응을 나중에 추가해보니 톤이 꽤 달랐음.
* 디시인사이드는 특히 논란성 게시물에 조회수·댓글이 쏠리는 경향이 있어, 이것만 보면 실제보다 더 부정적으로 보일 수 있다는 것도 함께 확인해 sources.yaml에 남겨둠 — 소스 하나만으로 톤을 판단하면 안 됨을 다시 확인함.
5. 배운 점
* 규칙은 적어두는 것과 지키는 것이 다름:
* SKILL.md에 규칙을 문서화해도 매 실행마다 실제로 따르는지 스스로 점검해야 함을 반복해서 확인함.
* 판단을 내리기 전에 실제 지표로 검증해야 함:
* 정준원 논란처럼 언론 보도만으로 심각도를 올렸다가, 실제 커뮤니티 댓글(더쿠 HOT글)을 확인하니 언론 톤보다 더 부정적이었음. 반대로 3·4회 시청률로는 논란이 실제 영향을 안 줬다는 게 확인됨 — 판단은 매번 수치·원문으로 재검증해야 함을 학습함.
* "확인 안 됨"과 "해당 없음"은 다른 결론임:
* 못 찾은 것과, 애초에 대상이 아닌 것을 구분해야 리포트가 정확해짐을 학습함.
* 리포트는 과정이 아니라 결과를 담아야 함:
* 검색 방법·도구 이름·검색 횟수를 문장으로 설명하는 건 참가자에게 불필요한 정보이고, 필요하면 별도 데이터 라벨로 분리하는 게 더 읽기 좋음을 확인함.
* 반응이 좋아 보여도 소스를 넓혀봐야 함:
* 시청률이 오르고 뉴스·블로그가 호평 일색이어도, 관람객 평점 사이트나 더 거친 커뮤니티까지 보면 다른 그림이 나올 수 있음을 확인함.
* 소스를 관리 파일(`sources.yaml`)로 만들어두면, 새로 발견한 소스를 "확인 안 해봤다"로 방치하지 않고 계속 검증해가는 습관이 생김을 학습함.
6. 향후 계획
* 그대에게 드림 10회(8/11 밤) 방송 직후 자동 체크 예약이 실제로 발동하는지 확인할 것 — 9회분은 예약이 사라진 걸 확인했으나 실행 결과는 못 봐서, 10회분은 결과까지 직접 확인할 것.
* 채널별 반응의 "제목+데이터값+인용" 3단 구조를 다음에 새로 만드는 작품 리포트에도 처음부터 적용할 것.
* 유부녀 킬러처럼 "이슈 발생 → 실제 지표로 해소 확인"까지 간 사례를 더 쌓아, 이슈 체크의 심각도 판단 기준을 계속 다듬을 것.
* sources.yaml에 아직 untested로 남아있는 소스가 더 없는지 다음 실행 때 점검하고, 새로 발견하는 소스도 계속 이 파일에 추가할 것.
