이미 갖고 있던 봇이 제가 못 뚫은 걸 뚫었습니다 — 그리고 그 봇도 틀릴 수 있었습니다

소개

혼자 만든 Skill로는 4채널 중 2채널에서 막혔는데, 이미 운영 중이던 에이전트(coco)에게 물었더니 4채널 API를 전부 찾아냈습니다. 그런데 그 결과를 검증해보니 에러 없이 틀린 데이터가 오는 함정이 있었고, 그 발견이 Skill을 가장 크게 바꿨습니다.

시작 전 상태

기본과제에서 만든 편성표 정리 Skill은 절반만 작동했습니다.

제 계획은 "헤드리스 브라우저(crawl4ai)를 서버에 올려서 뚫자"였습니다. 스크롤로 지연 로딩을 트리거하고, 셀렉터로 화면을 긁는 방식이었습니다.

내가 직접 내린 판단

판단 1 — 새로 만들기 전에, 이미 있는 것부터 확인하기

파일을 서버에 올리기 전에 5분짜리 확인을 먼저 하기로 했습니다. Discord에서 운영 중이던 봇에게 그냥 URL을 던져본 겁니다.

이 판단이 이번 과제 전체를 바꿨습니다.

봇의 응답 로그를 보니 skill_view, skill_manage, execute_code, terminal, memory가 찍혔습니다. 이미 Hermes였습니다. 제가 붙이려던 걸 이미 갖고 있었던 겁니다.

그리고 봇은 제가 못 한 걸 했습니다.

GS SHOP 페이지는 본문에 편성표가 없고, JS가 tvScheduleDetail.gs?today=20260727를 호출하는 구조였어유

제가 화면을 긁으려 애쓰던 곳에, 날짜 파라미터가 달린 API가 있었던 겁니다.

판단 2 — 그래서 설계를 바꿨습니다

DOM 스크래핑은 우회로였지 정공법이 아니었습니다. API가 있으면 그게 낫습니다. 렌더링 대기도, 스크롤 트리거도, 셀렉터 깨짐도 없어지니까요.

판단 3 — 수집과 판단을 분리하기

가장 신경 쓴 구조 결정입니다.

수집기 (API 호출)  →  편성 JSON  →  Skill (판단·정리)

• 수집기는 시간대를 자르지 않습니다. 하루 전체를 담습니다.

• 수집기는 상품명을 다듬지 않습니다. [TV상품] 같은 접두어도 그대로 둡니다.

• 17시~22시 필터, 경계 걸침 규칙, 타임테이블 배치는 전부 Skill의 일입니다.

이유는 유지보수입니다. 사이트가 개편되면 수집기만, 업무 규칙이 바뀌면 Skill만 고치면 됩니다. 섞어두면 매번 둘 다 건드려야 합니다.

진행 방법

만든 것

원본 Skill을 덮어쓰지 않고 별도 디렉터리에 candidate를 만들었습니다.

coco-intgration/

├─ contract/

│ ├─ schedule-record.md 데이터 계약 ← 수집기와 Skill의 유일한 접점

│ └─ api-endpoints.md 4채널 경로 + 실측 기록

├─ collector/

│ ├─ channel_specs.py 채널별 파서 — 깨지면 여기만 수정

│ └─ collect_schedule.py 수집기

└─ hermes-skill/

└─ SKILL.md v0.3.0

만들다 발견한 버그 하나

파서 파일 이름을 selectors.py로 지었다가 바꿨습니다. selectors는 파이썬 표준 라이브러리 이름이라, 그대로 두면 asyncio가 깨집니다. channel_specs.py로 바꿨습니다.

결과와 배운 점

배운 점과 나만의 꿀팁을 알려주세요.

과정 중에 어떤 시행착오를 겪었나요?

도움이 필요한 부분이 있나요?

앞으로의 계획이 있다면 들려주세요.

증거와 관찰

Before / After — 같은 입력(2026-07-26 일, 17:00~22:00)

2/4 → 4/4.

규칙이 작동한 증거

경계 걸침 규칙이 세 채널 모두에서 확인됐습니다.

• 16:45~17:45 (CJ) — 17시 이전 시작인데 포함 ✅

• 16:10~17:15 (롯데) — 포함 ✅

• 14:55~17:15 (GS) — 포함 ✅

• 21:45~22:45 (CJ) — 21시 이후 시작도 포함 ✅

제가 "21시 35분에 시작하는 것도 포함해달라"고 말했던 그 경우입니다.

그리고 함정을 발견했습니다

봇이 현대홈쇼핑 해법을 찾아왔습니다. brodPrrgPage가 시간대 페이지 파라미터였고, 권장 호출법으로 직접 API를 알려줬습니다.

그대로 믿지 않고 직접 호출해봤습니다.

직접 API로 부르면 brodPrrgPage가 조용히 무시됩니다.

에러가 나지 않습니다. 그럴듯한 데이터가 그냥 돌아옵니다. 검증 없이 썼다면 새벽 편성을 저녁 편성으로 착각한 표가 만들어졌을 겁니다.

봇의 데이터 자체는 정확했습니다. 프록시 경로로 부르니 봇이 보고한 16:10~17:15 셀폰즈 녹는실이 제 조회에서도 똑같이 나왔습니다. 호출 경로 안내만 틀렸던 겁니다.

실패·막힘·수정

수정 1 — 데이터 계약의 구멍

처음 계약에는 ok / fail 두 상태만 있었습니다. 그런데 "수집은 성공했는데 그 시간대에 편성이 없음"을 표현할 수가 없었습니다.

실제로 이 구멍 때문에 봇이 정상 수집을 fail로 잘못 분류했습니다.

상태를 4단계로 늘렸습니다.

수정 2 — 정보가 사라지고 있었습니다

한 시간 칸에 대표 상품 1개만 넣었더니, 17시 칸에 16:10~17:15만 나오고 17:15~18:20이 사라졌습니다. "무슨 상품을 파는지 본다"는 목적에 어긋납니다. 한 칸에 걸치는 편성은 전부 표시하도록 바꿨습니다.

수정 3 — 데이터 신뢰성 검사 (가장 중요)

함정을 발견한 뒤, Skill에 표를 만들기 전에 반드시 통과해야 하는 4가지를 넣었습니다.

1. 하루 총 편성이 10건 이상인가? 홈쇼핑은 하루 20건 내외가 정상입니다. 1건·3건·5건은 "편성 없는 날"이 아니라 수집 오류 신호입니다.

2. 응답 날짜가 요청 날짜와 같은가? 8/1을 요청했는데 7/31이 돌아온 사례가 실제로 있었습니다.

3. 반환된 시각 범위가 요청한 구간과 맞는가? page=5(16:00~20:39)를 요청했는데 전부 00:00~01:30이면 파라미터가 안 먹은 겁니다.

4. 모든 항목의 시각이 동일하지 않은가? 26건이 전부 00:00~00:59면 실제 편성이 아니라 플레이스홀더입니다.

아직 못 한 것

• crawl4ai 수집기 서버 실행: not_checked (봇이 API를 찾아내면서 우선순위가 밀렸습니다)

• 정정된 호출 경로를 봇에 반영한 뒤 재검증: 진행 예정

• CJ온스타일 파서: DOM 방식이 남아 있어 API로 전환 필요

결과와 다음 실험

지금 상태

• 4채널 전부 수집 경로 확보

• 데이터 계약 v0.2.0, Skill v0.3.0

• 봇의 잘못된 안내를 정정하는 프롬프트 작성 완료

배운 것 세 가지

1. 도구를 만들기 전에, 이미 있는 도구가 뭘 할 수 있는지 먼저 확인하기

저는 서버에 새 크롤러를 올릴 준비를 하고 있었습니다. 그런데 이미 돌고 있던 봇이 제가 못 뚫은 채널을 다 뚫었습니다. 하네스는 새로 짓는 게 아니라, 이미 가진 것을 알아보는 데서 시작합니다.

2. 에이전트의 결과도 검증 대상입니다

봇은 유능했습니다. 제가 못 찾은 API를 넷 다 찾았습니다. 하지만 권장 호출법은 틀렸습니다. 그대로 믿었다면 몇 주 뒤에 "편성표가 이상한데?"라고 느낄 때까지 몰랐을 겁니다.

3. 가장 위험한 실패는 에러가 안 나는 실패입니다

빈 표는 금방 알아챕니다. 하지만 그럴듯한데 틀린 표는 알아채기 어렵습니다. 그래서 Skill에 "0건인데 성공 처리 금지", "하루 20건이 정상" 같은 정상 범위를 아는 규칙을 넣었습니다.

다음 한 가지

정정된 호출 경로를 봇에 반영하고, 같은 날짜로 다시 돌려 4채널이 전부 ok로 나오는지 확인하겠습니다. 그다음 토·일 오전에 자동 실행되도록 스케줄을 걸 계획입니다.

도움 받은 글 (옵션)

참고한 지피터스 글이나 외부 사례를 알려주세요.

(내용 입력)