fix(slack): 300초 이상 실행이 응답 없음으로 끊긴 것처럼 보이는 UX

[cosmosjeon]

증상

Slack에서 오래 걸리는 요청이 실제 실행 상태와 다르게 응답 없음으로 먼저 보이면, 사용자는 작업이 중간에 끊겼거나 실패했다고 판단한다.

2026-09-10 KST의 #squad_hellobot_product_b 사례에서 같은 스레드에 다음 순서가 관찰됐다.

요청 수신: 이 스레드에서 이수지가 언급한 내용만 모아서 요구사항 빠지지 말고 모아봐.
두 번째 동일 요청 수신
jaw:kill reason=steer ...
jaw:main exited code=143, text=0 chars
slack:out ... 응답 없음
이후 재개된 Claude 실행이 계속 tool call/thinking을 수행
result: $3.1547 / 35 turns / 498.2s
jaw:main exited code=0, text=1712 chars

Slack 화면에는 뉴 [오후 12:08] 응답 없음이 남아, 실제로는 재개된 실행이 결과를 만들고 있었던 사실이 보이지 않는다. 이후 다른 주체가 결과를 올리면서 원래 요청이 실패한 것처럼 보인다.

이 사례 자체는 300초 watchdog 발화로 단정할 수 없다. 첫 실행은 약 70초 뒤 새 요청의 steer로 중단됐고, 재개 실행은 498.2초 뒤 정상 종료했다. 다만 300초 이상 걸릴 수 있는 실행에서 동일한 표시가 발생하면 같은 오해를 만든다. 현재 워치독 기본 absoluteMs는 600초이며, 설정에서 별도 값을 주지 않은 현장 인스턴스에서는 300초 초과가 곧 watchdog 발화라는 뜻도 아니다.

문제

1. 응답 없음이 terminal outcome인지, steer로 이전 실행이 교체된 것인지, watchdog timeout인지 Slack에서 구분되지 않는다.
2. 실행이 재개되거나 최종 결과가 뒤따를 수 있는데도 응답 없음이 최종 실패 메시지처럼 노출된다.
3. 300초 이상 걸리는 조사형 요청은 정상 범위일 수 있어, 시간 경과와 현재 상태를 보여주지 않으면 실행 중인 작업을 재요청하게 된다.

관련 구현:

• src/agent/error-classifier.ts:79-86은 stall reason을 사용자 메시지 ⏱️ 응답 없음 — ...으로 변환한다.
• src/agent/lifecycle-handler.ts:719-762는 부분 출력이 watchdog으로 잘린 경우를 별도로 표시하려는 경로를 둔다.
• src/agent/lifecycle-handler.ts:816-847는 watchdog kill을 오류 결과로 전달한다.

제안

• Slack의 중간 상태와 terminal outcome을 분리한다.
• 300초 경과 시에는 ⏳ 5분째 작업 중 — 아직 실행 중입니다처럼 진행 중임을 표시하고, 실제 중단 시에만 terminal 메시지를 보낸다.
• 실제 watchdog timeout은 ⏱️ 5분 제한으로 중단했습니다처럼 원인을 직접 표시한다.
• steer/requeue/resume은 ↪️ 새 요청으로 전환해 이전 실행을 중단했습니다처럼 timeout과 구분한다.
• 부분 답변이 있으면 답변 끝에 중단 사실과 경과 시간을 붙이고, Slack에서 잘린 답변처럼 보이지 않게 한다.
• 동일 실행에서 응답 없음을 먼저 보낸 뒤 나중에 성공 결과를 보내는 상태 전이를 금지하거나, 기존 상태 메시지를 갱신해 단일 최종 상태로 보이게 한다.

완료 조건

• 300초를 넘긴 실행이 정상적으로 계속되는 동안 응답 없음이 terminal 실패처럼 보이지 않는다.
• timeout, steer, resume, provider error가 Slack에서 서로 다른 문구로 구분된다.
• 부분 출력이 있는 watchdog 종료는 부분 답변과 중단 이유를 함께 보인다.
• no-output timeout은 실행 중 상태와 최종 timeout 상태를 혼동하지 않는다.
• 위 상태 전이에 대한 lifecycle/Slack forwarding 테스트가 추가된다.

참고

• 관련 이슈: fix(watchdog): cursor 런타임은 구조화 진행 신호가 없어 raw output만으로 연명하다 조용히 죽는다 #405
• 이번 사례는 #405의 “잘린 답변이 timeout처럼 보이는” 문제와 맞닿아 있지만, 실행이 계속되거나 재개되는 동안 Slack에 먼저 응답 없음이 표시되는 상태 전이 UX를 별도로 다룬다.

[lidge-jun]

코드 확인 결과 — 응답 없음은 하나의 메시지가 아니라 두 개다

dev b5ea3c0(v2.17.46) 기준으로 경로를 읽었습니다. 본문의 "이 사례를 300초 watchdog 발화로 단정할 수 없다"는 판단이 코드상 맞고, 실제로는 watchdog과 전혀 무관한 다른 문자열이 나간 것으로 보입니다.

1. 응답 없음 문자열은 생산자가 둘이고 서로 관계가 없다

표시	생산자	언제
응답 없음	src/orchestrator/collect.ts:145 → t('tg.noResponse') (public/locales/ko.json:198)	orchestrate_done이 빈 텍스트로 도착했을 때의 fallback
⏱️ 응답 없음 — <stallReason>	src/agent/error-classifier.ts:82	stallReason이 설정된 watchdog kill 전용

이슈 로그의 jaw:main exited code=143, text=0 chars → slack:out ... 응답 없음은 앞쪽입니다. watchdog이 아니라 빈 종료의 기본 문구입니다. 두 문구가 사람 눈에 거의 같아서 원인 추적이 어긋나는 것 자체가 별도 부채입니다.

2. 300초는 watchdog 발화 지점이 아니다 — 진행 표시와 watchdog을 결합하면 안 된다

src/agent/watchdog.ts:17-21 기본값은 firstProgressMs 120s, idleMs 90s, absoluteMs 600s, 하드캡 4시간입니다. 게다가 markProgress()가 진행 신호마다 절대 데드라인을 다시 now + absoluteMs로 밀기 때문에(watchdog.ts:55-62), 출력이 계속 나오는 건강한 실행은 600초를 넘겨도 죽지 않습니다. 사례의 498.2초 실행이 정상 종료한 것과 일치합니다.

따라서 제안의 "300초 경과 표시"는 순수한 경과 표시여야 하고 watchdog 임계값과 엮으면 안 됩니다. Slack 진행 카드는 이미 경과 초를 렌더합니다(src/slack/progress-activity.ts:194, :207) — 새 타이머가 아니라 기존 카드의 수명 문제입니다.

3. #655의 supersede 가드가 왜 이 사례를 못 막았나

가드는 src/slack/bot.ts:894에 있습니다.

if (resultData['superseded'] === true && !String(collected.text ?? '').trim()) { ... }

두 조건이 모두 필요한데, superseded는 src/orchestrator/collect.ts:129-135에서 steer_started 이벤트를 직접 관측했을 때만 켜집니다. 조건은 scope 일치 + (sessionId가 undefined이거나 일치) + requestId가 다를 것입니다.

문제는 steer_started가 네 곳에서, 서로 다른 payload로 broadcast된다는 점입니다.

• src/routes/orchestrate.ts:432 — scope는 싣지만 sessionId는 없음
• src/agent/spawn.ts:842, :881, :922 — sessionId: chatSessionId 포함

sessionId가 없는 payload는 undefined 허용 조건 덕에 통과하지만, 다중 세션에서는 다른 대화의 steer도 이 턴을 supersede 처리합니다. 반대로 payload가 실렸는데 collector의 binding과 어긋나면 supersede가 아예 안 켜지고, 그러면 fallback 응답 없음이 그대로 나갑니다. 리스너 부착 이전에 steer가 발생한 경우도 복구 경로가 없습니다.

이미 있는데 안 쓰는 신호가 하나 있습니다. lifecycle-handler는 agent_done payload에 steered: true를 싣습니다(src/agent/lifecycle-handler.ts:705, :810, :961). 그런데 collect.ts는 이 필드를 전혀 읽지 않습니다. 종료 payload에서 직접 읽으면 이벤트 도착 순서 의존성이 사라집니다.

4. wasSteer 판정이 종료 경로마다 다르다 — 같은 행동이 런타임에 따라 다르게 분류된다

src/agent/spawn.ts에서 같은 질문("이 턴이 새 요청으로 교체됐나")에 세 가지 답이 나옵니다.

위치	인정하는 kill reason
:2027	steer / interrupt / dup-registration
:2648, :2677, :3167	steer / dup-registration
:2395 (ACP), :3882 (표준 print)	steer 만

즉 ACP나 표준 print 경로에서 dup-registration kill이 나면 steered 플래그가 붙지 않고, 그 턴은 "교체됨"이 아니라 "그냥 빈 응답"으로 흘러갑니다. 사례가 Claude 실행이었다는 점을 감안하면 이 갈래가 유력한 후보입니다.

5. 중단 통지가 3사분면 중 한 칸만 비어 있다

	부분 출력 있음	출력 0
watchdog	STALL_TRUNCATION_NOTICE 부착 + 저장 (src/agent/stall-notice.ts:8)	⏱️ 응답 없음 — <reason> (error-classifier.ts:82)
steer	⏹️ [interrupted] 접두사 (lifecycle-handler.ts:740-744)	비어 있음 → collect fallback 응답 없음

shouldAnnounceStallTruncation은 wasSteer면 false를 반환합니다(error-classifier.ts:156-158). 의도된 설계이고 맞는 판단이지만, 그 결과 steer + 0출력 칸에 아무 문구도 배정되지 않았습니다. 이 빈칸이 이 이슈의 정확한 위치입니다.

6. ErrorKind에 이 상태를 담을 자리가 없다

src/messaging/error-block.ts:17의 ErrorKind는 rate_limit | auth | stall | connection | exit 5종입니다. "새 요청으로 교체됨"을 표현할 종류가 없어서, 채널 문구를 분기하려면 새 kind와 ACTION 항목(:36-43)이 함께 필요합니다.

---

제안하는 착수 순서

각 단계가 독립 PR로 떨어집니다.

1단계 — 신호 통일 (선행 필수). spawn.ts의 7개 종료 지점에 흩어진 wasSteer 판정을 헬퍼 하나로 모으고, dup-registration / interrupt / steer가 모든 경로에서 같은 결론을 내게 합니다. 이어서 collect.ts가 agent_done.steered를 supersede 신호로 받아들이게 해서, steer_started 관측 실패에도 복구되게 만듭니다. 이 단계만으로 사례의 표면 증상은 사라질 가능성이 높습니다.

2단계 — terminal 문구 분리. tg.noResponse 한 문자열을 원인별로 쪼갭니다: 교체됨 / watchdog timeout / 실제 무출력 / provider 오류. ErrorKind에 supersede 계열을 추가하고 ACTION 문구를 붙입니다. 여기서 ⏱️ 응답 없음 —과 응답 없음의 문자열 충돌도 함께 해소합니다.

3단계 — 진행 상태와 terminal 분리. 진행 카드가 실행 중에는 살아 있고 terminal 메시지는 실제 종료에서만 나가게 합니다. 이미 settle된 카드가 있으면 새 메시지 대신 갱신해서, 응답 없음 다음에 성공 결과가 오는 전이를 구조적으로 금지합니다.

4단계 — 회귀 테스트. 아래 표의 케이스를 lifecycle 단위 테스트와 Slack forwarding 통합 테스트로 고정합니다.

케이스	기대 표시
steer로 교체, 출력 0	원래 턴은 terminal 메시지 없음. 후속 실행이 답을 소유
steer로 교체, 부분 출력 있음	⏹️ [interrupted] + 부분 답변, 경과 시간 포함
watchdog timeout, 출력 0	timeout 원인을 명시한 문구
watchdog timeout, 부분 출력	부분 답변 + 중단 사유
정상 종료지만 텍스트 0자	"실행은 끝났지만 답변이 비었다"로, timeout과 구분
600초 넘겨 정상 완료	terminal 실패 문구가 전혀 나가지 않음
ACP / 표준 print 경로에서 dup-registration kill	위 steer 케이스와 동일하게 분류

---

확인 필요

이 분석은 코드 읽기이고 인시던트를 재현하진 않았습니다. 3단계 가설(왜 #655 가드가 비껴갔는지)은 해당 사례 서버 로그에서 두 가지만 보면 확정됩니다.

• steer_started broadcast의 실제 payload — sessionId가 실렸는지, collector binding과 일치했는지
• [slack:out:superseded] 로그 라인의 유무 (src/slack/bot.ts:895)

로그가 남아 있다면 1단계 범위를 정확히 좁힐 수 있고, 없다면 1단계는 어차피 방어적으로 옳은 변경이라 그대로 진행해도 됩니다.

관련: #405(부분 출력이 timeout처럼 보임), #655(steer 직후 placeholder 억제).

[lidge-jun]

PR #734 가 dev 에 머지됐다 (머지 커밋 18e1724, PR head 09aa10f, 그 SHA 의 Tests run 34570870434 conclusion=success). base 가 dev 라 GitHub 자동 닫기가 걸리지 않아 수동으로 닫는다.

원문 요구를 전부 새로 구현한 것은 아니다. 확인한 대로 적는다.

이미 해결돼 있던 것

• 이슈가 재현으로 든 그 사건(steer 로 은퇴한 턴이 자리표시자를 올리는 것)은 fix(steer): stop a steered Slack turn from posting "no response" and losing its answer #655 에서 막혔다. collect.ts 가 superseded 면 폴백을 비우고 slack/bot.ts 가 전송 전에 return 한다. 통합 테스트 SLACK-INT-002 가 이미 금지로 고정 중이다. 이슈가 "게시한다"고 지목한 줄이 사실은 그 skip 코드였다.
• 경과 시간 표시는 이미 있었다 — 진행 카드 제목이 요청 진행 상황 · 경과: N초 이고 네이티브 1초 주기로 갱신된다.
• "300초 = watchdog" 전제도 사실과 다르다. 기본 absoluteMs 는 600초다.

이 PR 이 고친 것

• 중단된 실행과 빈 완료가 같은 문장("응답 없음")으로 보이던 것을 구분한다.
• 5분을 넘긴 장시간 실행이 그렇게 읽히도록 표시한다.
• 네이티브 watchdog 발화가 crash 로 오분류되던 것을 바로잡는다.

남긴 것 → 후속 이슈로 분리
watchdog timeout / 사용자 Stop / 네이티브 steer-kill 세 가지를 서로 다른 문구로 구분하는 것. lifecycleRuntimeOutcome(..., wasKilled || wasSteer || stallReason) 이 셋을 하나의 runtimeStatus 로 누르고, 진짜 원인을 스레드 본문까지 옮기려면 orchestrate_done 에 필드가 필요한데 그건 pipeline.ts 소유다. 억지로 문구를 만들지 않고 분리한다.

NOT COVERED: 실시간 Slack progress / Socket Mode 장시간 UX 는 CI 에서 재현 불가. 문구·상태기계 유닛까지만 증명된다.