일하는 ai

19. 채팅 URL 자동저장 안 될 때 inbox·hook부터 점검

15 min read

-

채팅에 URL이 들어왔는데 메인 볼트 0.Inbox/Clipping에 문서가 안 생기면, 대개 모델이 링크를 “이해 못한” 문제가 아니라 훅이 어느 시점에 걸려 있는지, 저장 경로가 실제 폴더 구조와 맞는지, 후속 triage 크론이 살아 있는지 셋 중 하나에서 틀어진 경우가 많다. OpenClaw 공식 hooks 문서 기준으로 링크·미디어 이해가 끝난 뒤의 가장 안정적인 지점은 message:preprocessed다. 여기서는 bodyForAgent처럼 이미 풍부해진 본문을 다룰 수 있어서, URL 수집 자동화의 기준점으로 잡기 좋다.

반대로 저장 경로가 예전 가정(0.Inbox/...)에 묶여 있거나, triage 제안만 맡은 크론을 본문 저장 훅과 헷갈리면 “링크는 들어왔는데 파일은 안 생김” 같은 착시가 생긴다. 그래서 복구는 복잡한 디버깅보다 이벤트 시점 → 저장 경로 → 크론 역할 순서로 자르면 빠르다. heartbeat가 과업을 놓치지 않게 묶는 기본 원리는 37. Scheduled reminder가 떴는데 액션이 안 이어질 때와도 연결된다.

먼저 결론만 보면

  • URL 자동저장은 message:received보다 message:preprocessed 기준이 안정적이다.
  • 파일이 안 생기면 먼저 훅 실행 문제보다 잘못된 저장 경로를 의심하는 편이 빠르다.
  • 18:00 inbox triage 크론은 이동 제안 작업이지, 원문 저장 작업 자체를 대신하지 않는다.
  • 크론 설정은 jobs.json 직접 편집보다 CLI/툴 경로로 관리하는 편이 안전하다.
flowchart LR
A[채팅에 URL 도착] --> B[message:preprocessed]
B --> C{저장 경로 유효?}
C -- 아니오 --> D[0.Inbox/Clipping 실제 경로 수정]
C -- 예 --> E[클리핑 문서 생성]
E --> F[18:00 triage cron]
F --> G[폴더별 이동 제안]
D --> E

칠판 치트시트

  1. URL 저장은 message:preprocessed 기준으로 본다
  2. 기본 경로가 0.Inbox/Clipping/<유형>과 맞는지 먼저 본다
  3. 훅은 저장, 크론은 분류 제안 — 역할을 섞지 않는다
  4. 크론 수정은 jobs.json 생편집보다 CLI/툴 호출로 처리한다
  5. 링크는 들어오는데 파일이 없으면 경로·권한·훅 우선순위를 차례로 자른다

왜 이 문제가 자주 생기나

공식 hooks 문서를 보면 메시지 이벤트가 단계별로 나뉜다.

  • message:received는 아주 이른 단계라 미디어/링크가 아직 정리되기 전일 수 있다.
  • message:transcribed는 오디오 전사 중심이다.
  • message:preprocessed는 미디어와 링크 이해가 끝난 뒤, agent가 보기 직전의 풍부한 본문을 다룰 수 있다.

즉 URL 저장 자동화는 “메시지를 빨리 잡는 것”보다 충분히 정리된 시점에 잡는 것이 중요하다. 여기에 더해 hooks 문서 기준으로 훅 우선순위는 workspace/hooks → ~/.openclaw/hooks → bundled hooks 순이다. 그래서 예전 훅이 다른 위치에 남아 있거나, workspace 훅이 새 규칙을 덮어쓰고 있으면 생각보다 쉽게 경로가 어긋난다.

또 하나 자주 헷갈리는 점은 크론이다. 공식 cron 문서 기준으로 cron은 gateway 안에서 스케줄을 돌리고, job은 ~/.openclaw/cron/jobs.json에 저장된다. 하지만 이건 정해진 시각에 실행할 작업을 돌리는 장치다. URL이 들어오는 순간 문서를 만드는 실시간 저장 훅과는 역할이 다르다. 그래서 triage 크론이 살아 있어도, 저장 훅이 비어 있으면 클리핑 문서는 생기지 않는다. 크론의 동작 감각이 아직 헷갈리면 06. Cron Job과 42. cron 시간을 바꿨는데 예전 시각에 계속 도는 이유를 함께 보면 훨씬 빨리 감이 온다.

5분 복구 순서

1) 지금 어떤 이벤트 지점에 걸려 있는지 먼저 확인

URL 저장 자동화가 message:received에 묶여 있다면, 링크 요약이나 미디어 이해가 끝나기 전 단계일 수 있다. 이 경우 문서가 불완전하게 만들어지거나 아예 저장이 건너뛸 수 있다.

가장 먼저 볼 포인트는 이것이다.

  • 훅이 message:preprocessed를 기준으로 동작하는가
  • 저장 로직이 bodyForAgent 같은 최종 본문을 기준으로 만드는가

hooks 문서상 message:preprocessed는 “all media + link understanding completes” 뒤에 실행된다. URL 수집 자동화라면 여기부터 보는 게 가장 덜 흔들린다.

2) 저장 경로가 실제 볼트 구조와 맞는지 확인

실무에서는 이 단계가 가장 자주 원인이다. 규칙 문서에는 맞게 써놨는데 실제 폴더 구조가 조금 바뀌어 있으면, 훅은 돌았는데 파일이 엉뚱한 곳에 생기거나 아예 실패한다.

지금 점검 기준은 아래처럼 단순하게 두는 편이 좋다.

  • YouTube → 0.Inbox/Clipping/Youtube
  • Papers → 0.Inbox/Clipping/Papers
  • Blog/Generic → 0.Inbox/Clipping/Blog
  • GitHub → 0.Inbox/Clipping/GitHub

특히 예전 규칙이 0.Inbox/<유형>처럼 남아 있으면, 실제 구조와 어긋나면서 “저장이 안 됐다”고 느끼기 쉽다. 실제로는 다른 위치에 떨어졌거나, 부모 폴더가 달라 실패한 경우가 많다.

3) 훅 우선순위 충돌이 없는지 본다

hooks 문서 기준으로 OpenClaw는 아래 순서로 훅을 찾는다.

  1. <workspace>/hooks/
  2. ~/.openclaw/hooks/
  3. bundled hooks

그래서 같은 목적의 훅이 여러 군데 있으면, “내가 수정한 파일”이 실제로는 안 쓰이고 있을 수 있다. 최근 규칙을 workspace에 넣었는데 예전 managed hook을 보고 있다고 착각하는 장면이 여기서 자주 나온다.

4) 18:00 triage 크론은 저장 훅과 분리해서 본다

공식 cron 문서 기준으로 cron은 gateway scheduler다. 반복 작업을 저장하고 정해진 시각에 깨우는 역할이지, 메시지 수신 즉시 반응하는 훅이 아니다. 그래서 18:00 분류 제안이 안 왔다는 문제와 URL 문서가 처음부터 안 생긴다는 문제는 같은 카테고리로 묶지 않는 편이 맞다. 후자는 저장 훅 체인, 전자는 스케줄/전달 체인 문제에 가깝고, 전달 쪽은 43. cron은 돌았는데 전달이 안 오는 경우와도 연결된다.

그래서 아래처럼 분리해서 판단해야 한다.

  • 실시간 URL 저장 → hooks
  • 저장된 inbox를 저녁에 분류 제안 → cron

둘을 섞어서 보면 “크론은 살아 있는데 왜 링크 문서가 안 생기지?” 같은 혼선이 생긴다.

5) 크론 수정은 live jobs.json 생편집보다 CLI/툴 경로를 쓴다

cron 문서 기준으로 ~/.openclaw/cron/jobs.json은 gateway가 메모리에 올려 관리하므로, gateway가 살아 있는 동안의 수동 편집은 안전하지 않다. 그래서 triage 시간이 틀렸거나 job이 꼬였을 때는 직접 파일을 고치기보다 CLI나 툴 호출로 수정하는 편이 맞다.

현장 미니 사례 3개

사례 A) 링크는 분명 들어왔는데 문서가 비어 있거나 제목만 저장됨

  • 상황: URL이 감지된 것 같은데 문서 내용이 빈약함
  • 실제 원인: 너무 이른 메시지 이벤트에서 저장 로직이 실행됨
  • 처리: message:received 대신 message:preprocessed 기준으로 재정렬
  • 결과: 링크 이해가 끝난 본문 기준으로 요약/핵심 포인트가 안정적으로 채워짐

사례 B) 저장은 된 줄 알았는데 폴더에 아무것도 없음

  • 상황: 자동화는 돈 것 같은데 목표 폴더에 파일이 안 보임
  • 실제 원인: 기본 경로가 실제 구조와 달라 다른 위치에 생성되었거나 실패
  • 처리: 0.Inbox/Clipping/<유형> 기준으로 경로를 다시 고정
  • 결과: YouTube/Papers/Blog/GitHub 분류가 한 번에 맞춰짐

사례 C) 18:00 triage 알림은 오는데 URL 문서가 계속 없음

  • 상황: inbox 정리 제안은 오는데 정작 새 클리핑이 안 보임
  • 실제 원인: triage 크론만 살아 있고, 수신 시점 저장 훅이 비어 있음
  • 처리: 크론은 그대로 두고 hooks 쪽 저장 체인을 먼저 복구
  • 결과: 실시간 저장과 저녁 분류 제안이 역할별로 정상 분리됨

이렇게 확인되면 거의 복구다

아래 4개가 맞으면 실무에서는 거의 정상으로 봐도 된다.

  • URL이 들어온 직후 0.Inbox/Clipping/<유형> 아래에 문서가 생성된다.
  • 문서 내용에 제목·요약·핵심 포인트가 최소한 채워진다.
  • 18:00 triage 크론은 이미 저장된 문서를 기준으로 이동 제안만 수행한다.
  • 훅 위치가 workspace/hooks 기준으로 정리돼 있고, 우선순위 충돌이 설명 가능하다.

재발 방지 팁

  • URL 수집 자동화는 처음부터 message:preprocessed 기준으로 설계한다.
  • 경로 규칙을 문서에만 적지 말고 실제 폴더 구조와 함께 주기적으로 맞춘다.
  • 크론은 저장 로직이 아니라 후속 정리 로직이라는 점을 운영 규칙에 분리해 둔다.
  • triage 시간 변경이나 delivery 수정은 jobs.json 직접 편집보다 CLI/툴로 처리한다.
  • 새 훅을 넣을 때는 workspace/hooks와 ~/.openclaw/hooks 중 어디가 실제로 우선인지 같이 점검한다.

한 줄 결론

채팅 URL 자동저장이 안 될 때는 모델 문제보다 훅 시점, 저장 경로, 크론 역할 분리에서 어긋난 경우가 훨씬 많다.
message:preprocessed 기준인지 보고, 0.Inbox/Clipping/<유형> 경로를 맞추고, triage 크론은 후속 정리 작업으로 따로 떼어 보면 대부분 빠르게 풀린다.

상황별 바로 가기

내부링크·다음글 연결 (10)

  1. 06. Cron Job
  2. 07. 세션 토큰 운영
  3. 서브에이전트 분산운영
  4. 27. 블로그작성 Excalidraw 루프
  5. 32. HEARTBEAT_OK 반복응답 해결
  6. 37. Scheduled reminder 떴는데 액션이 안 이어질 때
  7. 42. cron 시간 바꿨는데 예전 시각에 계속 돌 때
  8. 43. cron은 돌았는데 텔레그램 전달이 안 올 때
  9. 44. 카카오채널 연결실패 shared relay 먼저 체크
  10. 🚀 OpenClaw 인덱스

다음 추천 읽기: 42. cron 시간 바꿨는데 예전 시각에 계속 돌 때

※ 이 문서는 생성형 AI를 활용해 작성되었습니다.

그래프 뷰

백링크