---
prevention_deferred: null
summary: "텔레그램 답장 API는 정상이지만 폰 클라이언트에 안 뜨는 지연으로 답이 안 오는 것처럼 보였던 사고"
---

# 텔레그램 답변이 "안 오는 것처럼" 보인 지연 현상

- **발생 일자:** 2026-04-20 08:38 KST
- **해결 일자:** 2026-04-20 08:47 KST
- **심각도:** medium
- **재발 가능성:** medium
- **영향 범위:** 모든 텔레그램 양방향 대화 (WSL ↔ 사용자)

## 증상
강대종님이 06:50 cron 메시지 이후 약 2시간 동안 "답이 안 온다"고 2회 보고. 실제로는 WSL Claude 가 보낸 reply 툴 호출이 매번 `sent (id:N)` 정상 반환했으나, 클라이언트 화면에는 해당 메시지가 뜨지 않음.

## 원인
Telegram Bot API 의 `sendMessage` 는 **서버 수령 시점까지만** `ok=true` 를 반환한다. 클라이언트(폰 앱)가 새 메시지를 pull 해서 화면에 표시하는 것은 별개 과정이며, 사용자 쪽 네트워크/앱 백그라운드 이슈로 pull 이 지연되면 봇은 정상 발송 중이어도 사용자 화면은 정체된다.

## 조치
- WSL 봇 상태 확인 (PID 717 alive, getMe OK, chat_id 정상)
- sent(id:N) 이력 전부 정상 반환된 것 재검토
- 원인 설명 + 앱 강제종료 → 재실행 안내
- 사용자가 앱 재활성 후 밀린 메시지 한꺼번에 수신 확인
- 메모리 `feedback_telegram_sent_ack_semantics.md` 저장

## 예방 (Forcing function 우선)
- **서버 ack ≠ 클라이언트 수신** 원칙을 메모리로 박아둠. 다음에 "답 안 옴" 리포트 받으면 봇/서버 로그 먼저 보지 말고 클라이언트 앱부터 의심.
- 진단 체크리스트 (봇 PID alive / getMe ok / sent(id:N) green) 3개 모두 통과면 95% 이상 클라이언트 이슈로 분류.
- **기기 식별자 prefix** 적용 후보: 매 텔레그램 메시지 앞머리에 `[M]` (Mac) / `[D]` (WSL 데스크탑) 한 글자를 붙이면, 클라 수신 지연으로 순서가 섞여 도착해도 어느 기기에서 보낸 건지 즉시 구분 가능 → 같은 혼선 반복 감소. (2026-04-20 맥 피드백에서 제안)
- Forcing function 수준까진 아님 — 사람 판단 가이드 + 표시 규약. 자동 감지 어려움 (서버 쪽에서 클라 수신 여부를 알 방법 없음).

## 재발 이력
_(없음)_

## 관련 링크
- 메모리: `feedback_telegram_sent_ack_semantics.md`
- 텔레그램 메시지 id: 919 (사용자 질문), 921 (진단 보고), 923 (해결 확인)