Shared-Claude-Chats 딥다이브
— 공유 링크 하나를 깨끗한 마크다운으로 바꾸는 5인분 스크래퍼

1한 줄 정체

Shared-Claude-Chats는 "다섯 개 AI 챗봇의 공개 공유 링크를 넣으면, 모두 동일한 형식의 깨끗한 마크다운 대화록으로 뽑아 주는 스크래퍼 모음 + 그 결과물 아카이브"다. 이름은 Claude만 들어가지만 실제로는 Claude·Grok·Kimi·Qwen·DeepSeek 5종 + 구글 AI Studio(수동)까지 6개 소스를 다룬다. 링크를 한 줄씩 텍스트 파일에 넣고 스크립트를 돌리면, 대화 한 개가 마크다운 파일 하나(제목.md)로 저장된다.

2왜 주목받는가 — "공유 링크를 어떻게 긁지?"의 정답지

AI 대화를 백업·인용·연구하려는 수요는 큰데, 각 서비스가 공식 내보내기(export)를 잘 안 준다. 그래서 "공유 링크를 어떻게 긁느냐"는 개발자 사이 단골 질문이다. 이 레포가 떠오른 이유는 그 질문에 대해 서비스별로 정확히 어디를 어떻게 두드리는지를, 실제로 도는 코드 + 놀랄 만큼 상세한 README로 공개했기 때문이다. 단순 도구가 아니라 리버스 엔지니어링 사례집으로 읽힌다.

두 번째 강점은 결과의 일관성이다. 6개 소스가 전부 같은 마크다운 뼈대(메타데이터 헤더 + ---로 구분된 사람/어시스턴트 턴)로 정규화된다. 그래서 이 코퍼스를 그대로 데이터셋·검색·인용에 쓸 수 있다. 세 번째는 재현성 — 링크 목록 파일이 함께 공개돼 있어 누구나 같은 아카이브를 다시 만들 수 있다.

비슷한 접근들과의 비교

3기술 스택 전체 지도

놀랍도록 얇다. 프레임워크도, 무거운 라이브러리도 없다. requirements.txt는 딱 두 줄 — curl_cffi와 requests. 나머지는 전부 파이썬 표준 라이브러리(re, json, argparse, pathlib, tempfile, unicodedata, datetime)로 짰다. "의존성을 최소로, 대신 각 서비스의 실제 동작을 깊이 이해"가 이 프로젝트의 철학이다.

① 네트워킹 — 두 개의 서로 다른 HTTP 클라이언트

• curl_cffi — Claude·Grok 전용. 일반 requests는 파이썬 특유의 TLS 지문을 남겨 Cloudflare에 막힌다. curl_cffi는 실제 크롬의 TLS 지문을 흉내(impersonate) 내서 통과한다(impersonate="chrome").
• requests — Kimi·Qwen·DeepSeek 전용. 이 세 서비스는 데이터 경로가 Cloudflare TLS 게이트 뒤에 있지 않아 평범한 요청으로 충분하다.
• AI Studio는 네트워크를 아예 안 쓴다 — 사람이 붙여넣은 텍스트 덤프를 파일에서 읽어 변환한다.

② 파싱 — 정규식과 json이 전부

• JSON API 직접 호출(Claude·Grok·Qwen·DeepSeek): 응답이 곧 JSON이라 response.json()으로 끝.
• 임베디드 상태 파싱(Kimi): 서버가 그려 준 HTML 안 window.HYDRATION_INIT_STATE = {…}를 정규식으로 뽑아 json.loads.
• UUID/ID 추출: 추적 쿼리스트링·로케일 세그먼트가 붙은 지저분한 링크에서 re로 순수 id만 뽑는다(서비스마다 id 형태가 다름 — UUID vs 18자 영숫자).

③ 출력 & 안전장치 — 공유 헬퍼 export_io.py

• 원자적 쓰기(atomic_write_text): 임시 파일에 쓰고 fsync 후 os.replace로 교체 — 도중에 죽어도 반쪽짜리 파일이 남지 않는다.
• 경로 탈출 방지(resolve_within): 매니페스트가 가리키는 경로가 지정 폴더 밖으로 새는지 검사(디렉토리 트래버설 차단).
• 매니페스트: 폴더마다 .<provider>-share-export.json 하나. 이미 받은 대화를 기록해 재실행 시 건너뛴다(멱등성).

4아키텍처 심화 — 다섯 개의 서로 다른 관문 뚫기

이 레포의 진짜 내용은 "서비스 A의 공유 데이터는 정확히 어디에 있고, 그 앞에 무슨 문이 있으며, 어떻게 여느냐"를 다섯 번 반복한 것이다. 전체 파이프라인은 서비스가 달라도 모양이 같다:

① Claude · Grok — Cloudflare TLS 게이트를 지문 위장으로

두 서비스의 공유 페이지(/share/<uuid>)는 빈 SPA 껍데기다 — HTML엔 대화가 없고, 자바스크립트가 나중에 JSON API를 불러 채운다. 그래서 익스포터는 그 JSON API를 직접 호출한다(Claude는 /api/chat_snapshots/<uuid>). 문제는 그 API가 Cloudflare 뒤에 있고, Cloudflare가 헤더가 아니라 TLS 지문으로 봇을 거른다는 것. 해결책이 curl_cffi다:

# scripts/claude_share_export.py — 크롬 TLS 지문으로 위장해 호출
from curl_cffi import requests as cffi_requests
IMPERSONATE = "chrome"

response = cffi_requests.get(
    API_URL.format(uuid=uuid),
    impersonate=IMPERSONATE,                # ← 핵심: 크롬인 척
    timeout=TIMEOUT,
    headers={"Accept": "*/*", "Referer": SHARE_URL.format(uuid=uuid)},
)

흥미로운 디테일: HTTP 403이 두 가지 다른 뜻을 갖는다. Cloudflare 차단(HTML 응답)일 수도, 비공개 공유(JSON permission_error)일 수도 있다. 코드는 응답이 JSON인지 보고 둘을 구분해, "공유가 비공개다"를 "TLS 문제"로 잘못 보고하지 않는다 — 안 그러면 사용자가 애먼 curl_cffi만 업그레이드하며 헤맨다.

② Kimi — 서버가 그려 준 페이지에 JSON이 박혀 있다

Kimi는 반대다. 공유 페이지가 서버 렌더링이라 대화 JSON이 이미 HTML 안 <script>에 들어 있다. 별도 API 호출도, Cloudflare 게이트도 없어 평범한 requests로 페이지를 받아 정규식으로 상태를 뽑는다:

# scripts/kimi_share_export.py
HYDRATION_RE = re.compile(
    r"window\.HYDRATION_INIT_STATE\s*=\s*(.*?)</script>", re.DOTALL
)
match = HYDRATION_RE.search(response.text)
blob   = normalise_hydration_literals(match.group(1))   # JS 리터럴 → JSON
payload = json.loads(blob)                               # queryKey == "share" 항목에서 대화 추출

③ Qwen — 항상 200을 주는 공개 API의 함정

Qwen도 SPA 껍데기지만, API(/api/v2/chats/share/<uuid>)가 진짜 공개라 토큰 없이 열린다. 함정은 삭제·비공개 대화도 HTTP 200을 준다는 것 — 실패 신호가 상태 코드가 아니라 JSON 본문의 "success": false에 있다. 상태 코드만 믿으면 빈 대화를 "성공"으로 착각한다.

④ DeepSeek — 페이지는 못 읽지만, 데이터 API는 문 밖에 있다

가장 교육적인 사례. DeepSeek 공유 페이지는 AWS WAF의 자바스크립트 챌린지 뒤에 있다 — challenge.js를 실행 못 하는 클라이언트(curl_cffi 포함)에는 HTTP 202와 퍼즐 조각만 준다. 즉 페이지 자체는 어떤 스크립트로도 못 읽는다. 그런데 저자는 실제 브라우저로 페이지를 열고 네트워크 패널을 뒤져, 그 게이트 바깥에 있는 데이터 API를 찾아냈다:

# scripts/deepseek_share_export.py — WAF 밖의 순수 JSON API
API_URL = "https://chat.deepseek.com/api/v0/share/content"
response = requests.get(API_URL, params={"share_id": share_id}, ...)  # 토큰·쿠키 불필요

data = response.json()["data"]
if data.get("biz_code"):                                  # 200이어도 실패는 여기에
    raise ExportError(f"not found -- {data.get('biz_msg')}")
return data["biz_data"]

여기에도 함정이 둘. (1) Qwen처럼 실패가 200 안 biz_code에 숨어 있고, (2) 어떤 공유는 긴 대화의 꼬리 일부만 담겨 온다 — 가장 앞 메시지의 parent_id가 페이로드에 없는 조상을 가리켜서, 순서 복원 시 "부모가 없는 메시지를 뿌리로" 취급하는 방어 로직이 들어간다.

5디렉토리 구조 해부

구조가 말하는 의도는 명확하다. 왼쪽(scripts + link_lists)은 "만드는 법", 오른쪽(*_chats)은 "만들어진 것"이다. 각 *_chats/ 폴더는 결과물이면서 동시에 자기 매니페스트를 품어 스스로 "무엇을 이미 받았는지" 안다. 그래서 링크 목록에 계속 이어붙이고 다시 돌려도 안전하다(이미 있는 건 건너뜀). 파일 이름은 대화 제목에서 만들되(slugify), 비-라틴 문자(한글 등)는 그대로 둔다 — 예: 네이버-AI-모델서비스-기획-...md.

6학습 포인트 — 기술별 배울 것

1) 현대 웹 스크래핑의 진짜 첫걸음 — Network 패널 읽기

HTML을 긁기 전에 "이 데이터는 어느 요청으로 오나"를 개발자도구로 관찰하는 습관. SPA는 십중팔구 JSON API를 부르고, 그게 파싱하기 훨씬 쉽다. DeepSeek의 숨은 데이터 API를 찾은 방법이 바로 이것.

2) 안티봇 장벽의 종류와 대응 (가장 희귀)

TLS 지문 검문(Cloudflare) → curl_cffi 위장, JS 챌린지(AWS WAF) → 게이트 밖 API 찾기, 게이트 없음 → 평범한 requests. 벽마다 뚫는 방법이 다르다는 걸 실물 코드로 배운다. 이건 튜토리얼에 잘 안 나오는 실전 지식이다.

3) "성공/실패를 어디서 읽는가" — 상태 코드의 함정

Qwen·DeepSeek은 실패해도 HTTP 200을 준다. 진짜 신호는 success:false·biz_code처럼 응답 본문에 있다. API를 다룰 때 "200이면 OK"라는 순진한 가정이 왜 위험한지 체감하는 좋은 예.

4) 안전한 파일 쓰기 — 원자적 교체와 경로 방어

export_io.py 40여 줄이 보석이다. 임시파일 + fsync + os.replace로 "쓰다 죽어도 원본이 반쪽 안 남는" 원자적 쓰기, 그리고 resolve().relative_to(root)로 경로 탈출(디렉토리 트래버설)을 차단하는 법. 모든 파일 도구에 필요한 기본기.

5) 멱등한 배치 파이프라인 설계

매니페스트로 중복 스킵, --force로 갱신, 링크에서 순수 id 정규화, 실패 한 건이 배치를 안 죽이게 하는 예외 처리(ExportError). "밤새 돌려도 안전한" 수집기의 골격.

6) 데이터 정규화 & 출처 관리(provenance)

6개 소스를 하나의 마크다운 규격으로 통일하되, 소스별 차이(Author/Model/thinking/tool-call)를 헤더로 표현. 그리고 검수→banned.txt→히스토리 재작성으로 데이터 위생을 관리하는 실전 사례. 데이터셋을 만드는 사람이라면 반드시 볼 부분.

7시스템 / 실행 요구사항

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 로드맵 (주차별)

10핵심 키워드 사전

11참고 링크

• GitHub 저장소: github.com/fuadmefleh/Shared-Claude-Chats
• 1차 소스: 저장소 README.md(서비스별 관문·형식·검수 정책이 매우 상세) · scripts/*_share_export.py · scripts/export_io.py
• curl_cffi(TLS 임퍼소네이션): github.com/lexiforest/curl_cffi · curl-impersonate: github.com/lwthiker/curl-impersonate
• requests: requests.readthedocs.io
• 참고 개념: TLS/JA3 fingerprinting, Cloudflare bot management, AWS WAF challenge, SPA hydration, atomic file replace, path traversal, idempotent pipelines