텔레그램 첨부를 검증 가능한 로컬 파일로 보관하기

6월 21일 Codex 수정 기록, 설치된 OpenClaw 저장 스킬, 6·7월 저장 색인을 대조했습니다. 9월 9일 색인에 남은 파일 5건의 크기와 SHA-256이 실제 파일과 일치함을 확인했습니다.

텔레그램으로 받은 음성 파일과 문서를 다시 업무에 쓰려면 채팅에 첨부가 보이는 것만으로는 부족했습니다. OpenClaw가 처리 중인 첨부 경로, 사용자가 알아볼 수 있는 이름, 실제로 보관된 파일이 서로 연결되어야 했습니다. 2026년 6월 21일 작업은 비서에게 파일 저장을 요청했을 때 로컬 컴퓨터에 결과가 남고, 그 결과를 다시 확인할 수 있도록 만드는 데서 시작했습니다.

완료 기준은 저장 위치를 알려주는 응답에만 두지 않았습니다. 파일을 날짜별 폴더에 복사하고, 같은 이름의 기존 파일을 덮어쓰지 않으며, 크기와 SHA-256을 기록하도록 정했습니다. 음성 전사나 문서 편집은 저장 이후의 별도 작업으로 두었습니다. 먼저 받은 바이트를 보존해야 이후 변환 결과와 원본을 구분할 수 있기 때문입니다.

Codex는 비서가 사용할 Python 저장 스크립트와 스킬 문서를 만들고 실제 OpenClaw 비서 폴더에 설치했습니다. 입력은 이미 내려받은 첨부의 로컬 경로, 다운로드 URL, Telegram 파일 식별자로 나누었습니다. 결과는 저장 위치·크기·해시·입력 유형을 담은 JSON으로 반환하고, 같은 내용을 누적 색인에도 남기도록 구성했습니다.

비서의 역할은 메시지에 전달된 실제 첨부 정보를 확인하고 적절한 입력을 도구에 넘기는 것입니다. 파일 이름은 경로 구분자와 제어문자를 정리하고, 충돌하면 번호를 붙입니다. 성공 응답 전에 도구가 돌려준 정보를 읽도록 한 덕분에 대화 속 설명과 디스크에 남은 산출물을 연결할 기준이 생겼습니다.

첫 번째 장애는 저장 스크립트가 오래된 환경 설정의 계정을 우선 선택해 Telegram API에서 인증 오류를 받은 것이었습니다. Codex는 현재 OpenClaw에서 사용하는 계정을 우선 참조하도록 순서를 바꾸고, 계정을 명시적으로 선택하는 옵션도 추가했습니다. 당시 기록에는 계정 확인 요청 성공과 로컬 파일 저장 시험 통과가 남아 있습니다.

이후에는 이미 받은 첨부가 media URI로 표현되는 경우를 처리했습니다. 이를 Telegram 파일 식별자로 오해하지 않고 로컬 수신 폴더로 해석하도록 분기했습니다. 한글 파일명의 NFC·NFD 정규화 차이 때문에 이름이 바로 일치하지 않는 경우에는 첨부 이름의 고유한 접미부로 찾는 보완도 들어갔습니다. 현재 메시지에 실제 MediaPath가 있으면 그 경로를 먼저 사용한다는 규칙을 함께 남겼습니다.

6월 21일에는 media URI를 이용한 음성 파일 저장 두 건이 색인에 기록되었습니다. 7월 28일에는 이미 내려받은 로컬 첨부 경로를 이용한 저장 세 건이 추가로 남아 있습니다. 이 기록은 지원한다고 적은 입력 방식 가운데 두 경로가 실제 사용되었다는 근거입니다. 모든 지원 방식이 같은 수준으로 시험되었다고 확대하지는 않습니다.

이번 사례 정리에서는 기록된 다섯 파일을 다시 열어 존재 여부, 바이트 수, SHA-256을 대조했습니다. 다섯 건 모두 색인의 크기와 해시가 실제 파일과 일치했습니다. 이 확인은 저장된 바이트가 기록과 맞는다는 뜻입니다. 음성 내용의 정확한 전사나 문서의 업무상 완결성까지 확인하는 검사는 아닙니다.

이 작업의 산출물은 파일 복사 기능과 그 사용 규칙입니다. 비서는 원본을 추정해 만드는 대신 실제 첨부 정보를 넘기고, 스크립트는 저장 결과를 기계가 읽을 수 있는 형식으로 반환합니다. 사용자는 저장 위치를 확인할 수 있고, 다음 작업은 같은 파일의 크기와 해시를 기준으로 시작할 수 있습니다. 오류가 나면 계정 문제인지, 경로 해석 문제인지, 원본 부재인지도 나누어 볼 수 있습니다.

반복 가능한 교훈은 저장을 하나의 확인 가능한 단계로 만드는 것입니다. 입력 출처, 충돌 처리, 성공 결과의 필드, 재확인 방법을 함께 정하면 메신저 비서의 응답을 이후 작업의 출발점으로 쓸 수 있습니다. 원본 첨부가 이미 사라진 경우에는 경로 해석만으로 복구할 수 없다는 한계도 분명합니다.

실제로 사용할 원본 경로나 파일 식별자가 없으면 비서가 그 값을 추측해서 채우지 않도록 했습니다. 다시 업로드하거나 전달받아야 한다는 조건도 스킬에 적었습니다. 이런 실패 조건까지 있어야 성공 JSON의 의미가 유지됩니다. 저장을 요청했다는 사실과 저장이 끝났다는 사실을 구분하는 규칙이기도 합니다.