클로드 대화 내보내기와 세션 ID, 개발자가 놓치는 4가지 접근법

결론부터 말하면, 클로드 앱에서 나눈 채팅을 Claude Code에서 직접 읽어오는 공식 경로는 존재하지 않습니다. 두 제품은 대화 데이터를 완전히 분리된 저장소에 보관하며, 이를 연결해 주는 공개 API도 제공되지 않습니다. 다만 대화를 식별하는 고유 ID 자체는 분명히 존재하고, 목적에 따라 쓸 만한 우회 경로가 네 가지 정도 있습니다.

이 글에서는 각 경로가 실제로 어디까지 되는지, 어떤 조건에서 깨지는지, 그리고 자동화 파이프라인을 만들 때 어느 쪽을 원본으로 삼아야 하는지를 정리합니다. “되긴 되는데 언제 터질지 모르는” 방법과 “구조적으로 안정적인” 방법을 구분하는 것이 핵심입니다.

클로드 앱 채팅에도 고유 ID는 존재한다

먼저 오해를 풀고 가야 할 부분이 있습니다. 대화를 식별할 방법이 아예 없는 것은 아닙니다. 웹에서 클로드 대화를 열어 보면 주소창이 claude.ai/chat/{uuid} 형태이고, 여기서 UUID가 바로 그 대화의 고유 식별자입니다.

모바일 앱에서도 마찬가지입니다. 공유 메뉴로 링크를 뽑으면 동일한 UUID를 확인할 수 있습니다. 대화가 삭제되지 않는 한 이 값은 변하지 않으므로, 특정 대화를 가리키는 키로 쓰기에는 충분합니다.

문제는 그다음입니다. 식별자는 있는데, 그 식별자로 내용을 조회할 수 있는 공개 API가 없습니다. 흔히 혼동하는 지점인데, 개발자용 API 엔드포인트는 상태를 저장하지 않는 메시지 완성(completion) 방식이라 앱의 대화 기록과는 아무 관련이 없습니다. 같은 회사의 같은 모델을 쓴다고 해서 대화 저장소가 공유되는 것은 아닙니다.

공식 경로: 데이터 내보내기로 conversations.json 확보

공식적으로 지원되는 유일한 방법은 계정 데이터 내보내기입니다. 설정 화면에서 Privacy 탭으로 들어가 데이터 내보내기를 실행하고, 원하는 기간 범위를 고른 뒤 요청하면 됩니다. 준비가 끝나면 이메일로 다운로드 링크가 전달됩니다.

받은 압축 파일 안에는 대화 기록이 들어 있는 JSON 파일이 포함되어 있습니다. 각 대화마다 고유 UUID, 메시지 목록, 작성 시각이 구조화된 형태로 담겨 있어서, 스크립트로 파싱하기에는 오히려 편한 편입니다. 대화 제목과 생성일 기준으로 필터링해 원하는 항목만 뽑아내는 처리도 어렵지 않습니다.

다만 명확한 한계가 두 가지 있습니다. 첫째, 실시간이 아닙니다. 요청 시점의 스냅샷이므로 방금 나눈 대화를 즉시 가져오는 용도로는 쓸 수 없습니다. 둘째, 수동 조작이 필요합니다. 설정 화면에서 버튼을 누르고 메일을 확인하는 과정을 자동화할 방법이 없기 때문에, 무인 파이프라인의 입력으로 삼기는 어렵습니다.

정리하면 이 경로는 주기적인 백업이나 일괄 아카이빙에는 적합하지만, 대화 하나를 바로 이어받아 처리하는 워크플로우에는 맞지 않습니다.

비공식 경로: 브라우저 세션 기반 추출의 한계

검색해 보면 브라우저 확장 프로그램이나 북마클릿 형태로 대화를 마크다운·JSON으로 내보내 주는 도구가 여럿 나옵니다. 개별 대화를 내보내거나, 전체를 압축 파일로 일괄 저장하거나, 대화 분기(branch)를 인식해 현재 갈래만 추출하는 등 기능도 제법 다양합니다.

동작 원리는 대체로 비슷합니다. 로그인된 브라우저의 세션 쿠키를 그대로 활용해 내부 엔드포인트를 호출하거나, 화면에 렌더링된 DOM을 긁어옵니다. 실제로 잘 동작하는 도구들이 있고, 로컬에서만 처리하도록 설계된 것들도 있습니다.

그럼에도 자동화 파이프라인의 기반으로 삼기에는 권하기 어렵습니다. 이유는 세 가지입니다.

• 내구성: 공식 계약이 아니므로 UI나 내부 엔드포인트가 바뀌면 예고 없이 깨집니다. 실제로 상당수 도구가 “특정 시점 기준 동작 확인”이라는 단서를 달고 있습니다.
• 인증 취급: 세션 값을 어딘가에 저장해 두고 반복 호출하는 구조가 되는데, 이 값은 계정 접근 권한 그 자체입니다. 서버에 평문으로 두는 순간 심각한 보안 부채가 됩니다.
• 정책 리스크: 자동화 강도가 올라갈수록 정상 이용 범위를 벗어날 여지가 커집니다.

수동으로 한두 개 대화를 백업하는 정도라면 충분히 실용적입니다. 하지만 매일 도는 배치 작업의 첫 단계로 넣을 만한 성격은 아닙니다.

반대 방향은 확실하다: Claude Code 세션 ID 다루기

흥미롭게도 반대 방향, 즉 Claude Code 쪽 대화를 식별하고 접근하는 것은 명확하게 지원됩니다. CLI로 진행한 세션은 로컬 파일로 저장되며, 홈 디렉토리 하위의 프로젝트별 경로에 세션 ID를 파일명으로 하는 JSONL 형식으로 쌓입니다. 프로젝트 디렉토리는 작업 경로를 인코딩한 이름으로 구분됩니다.

이 파일명에서 확장자를 뗀 값이 곧 세션 ID이며, 다음 명령으로 언제든 해당 대화를 복원할 수 있습니다.

claude --resume <session-id>

JSONL 형식이라는 점도 중요합니다. 한 줄에 하나의 이벤트가 들어가므로 스트리밍 파싱이 쉽고, 사용자 메시지·모델 응답·도구 호출을 구분해서 뽑아내기 좋습니다. 별도 API 없이 파일만 읽으면 되니 서버 환경에서 다루기도 편합니다.

몇 가지 실무적인 주의점이 있습니다.

세션 ID를 직접 지정할 때: 비대화형 실행(-p 모드)에서는 --session-id 옵션으로 넘긴 UUID가 실제 저장 파일명과 출력의 세션 식별자에 그대로 반영됩니다. 반면 인터랙티브 모드에서는 이 값이 로컬 저장 ID를 제어하지 못하고, CLI가 내부적으로 별도 UUID를 생성합니다. 스크립트에서 ID를 미리 정해 두고 나중에 찾아 쓰려는 설계라면 이 차이를 반드시 감안해야 합니다.

작업 디렉토리에 묶여 있다는 점: 세션 조회는 기본적으로 현재 작업 경로에 대응하는 프로젝트 디렉토리 안에서만 이루어집니다. 프로젝트 폴더를 옮기거나 이름을 바꾸면 같은 세션 ID로도 복원이 실패할 수 있습니다. 경로 자체가 사실상 키의 일부라고 생각하는 편이 안전합니다.

세션 목록을 프로그래밍 방식으로 다룰 때: 에이전트 SDK에는 특정 디렉토리의 세션 목록을 조회하고 세션 ID로 메시지를 가져오는 메서드가 제공됩니다. 파일 구조를 직접 파싱하는 것보다 안정적이므로, 도구를 만들 계획이라면 이쪽을 먼저 검토할 만합니다.

그래서 어떤 구조를 선택해야 하나

지금까지의 내용을 목적별로 정리하면 판단이 단순해집니다.

단발성 백업이 목적이라면 공식 데이터 내보내기로 충분합니다. 가장 안전하고, 데이터 형식도 안정적입니다.

특정 대화 하나를 다른 도구로 옮기는 것이 목적이라면 그냥 복사해서 붙여넣는 편이 가장 빠릅니다. 자동화 코스트를 들일 만한 반복성이 없다면 수동이 정답입니다.

반복되는 파이프라인을 만드는 것이 목적이라면, 앱 대화를 원본으로 삼는 발상 자체를 재검토해야 합니다. 앱 채팅은 프로그래밍 방식 접근을 전제로 설계된 저장소가 아니기 때문에, 여기에 파이프라인을 얹으면 구조적으로 취약해집니다.

이 경우 훨씬 나은 대안은 원격 서버에서 Claude Code 세션을 원본으로 두고, 모바일 앱은 그 세션에 접속하는 클라이언트로만 사용하는 구조입니다. 원격 접속 기능을 쓰면 앱에서 시작한 작업도 결국 서버의 세션 파일로 기록되므로, 앞서 살펴본 JSONL 구조를 그대로 활용할 수 있습니다. 대화 이력이 처음부터 파일로 존재하니 재현성도 확보됩니다.

정리하면, 앱 대화를 억지로 끌어오는 대신 처음부터 파일로 남는 곳에서 대화를 시작하는 것이 핵심 전환점입니다.

자주 묻는 질문

Q. 개발자용 API 키가 있으면 앱 대화를 조회할 수 있나요?
아닙니다. API는 상태를 저장하지 않는 메시지 처리 방식이고, 앱의 대화 기록과는 저장소가 분리되어 있습니다. 같은 계정이라도 서로 조회되지 않습니다.

Q. 대화 공유 링크를 만들면 그걸로 가져올 수 있나요?
공유 링크는 사람이 브라우저로 열어 보는 용도입니다. 구조화된 데이터를 반환하는 엔드포인트가 아니므로, 파싱해서 쓰는 것은 앞서 설명한 비공식 경로와 동일한 리스크를 갖습니다.

Q. 세션 파일이 사라지는 경우도 있나요?
로컬 파일이므로 디스크 정리, 경로 변경, 도구 업데이트 등의 영향을 받을 수 있습니다. 장기 보관이 필요한 세션이라면 별도 위치로 복사해 두는 습관이 안전합니다.

Q. 여러 대화를 하나로 합쳐서 처리하고 싶습니다.
데이터 내보내기 결과물이나 세션 JSONL 모두 구조화된 형식이므로, 스크립트로 병합하는 것 자체는 어렵지 않습니다. 관건은 대화 경계를 어떻게 표시할지와 토큰 분량을 어떻게 관리할지입니다.

마치며

핵심만 세 줄로 요약합니다.

1. 클로드 앱 대화에는 URL 기반의 고유 UUID가 있지만, 이를 조회할 공개 API는 없습니다.
2. 공식 경로는 데이터 내보내기 하나뿐이며 실시간성이 없고, 브라우저 기반 추출 도구는 편리하지만 언제든 깨질 수 있습니다.
3. Claude Code 세션은 세션 ID와 JSONL 파일로 명확하게 식별·복원되므로, 자동화의 원본은 이쪽에 두는 것이 구조적으로 안정적입니다.

도구를 어떻게 연결할지 고민하기 전에, 데이터가 어디에 어떤 형태로 남는지를 먼저 확인하는 것이 훨씬 빠른 길일 때가 많습니다. 관련해서 CLI 기반 개발 환경을 원격 서버에 구성하는 방법이나, JSONL 로그를 파싱해 활용하는 패턴도 이어서 다뤄 볼 만한 주제입니다.