[자문] auto-ship 1800s timeout — CCR 오프로드 vs 단계 분리

TL;DR

/auto-ship은 구조적으로 Slack 세션 타임아웃(1800s)을 초과할 수 있는 long-running 작업이다. 단기 대응은 CCR 오프로드, 장기 해소는 단계 분리를 권장한다.

질문 / 결정 사항

/auto-ship이 Slack DM 봇 세션 1800s 타임아웃 안에 완료되지 못하는 사건이 반복(3회+)됨. 구조적으로 어떻게 해소할 것인가?

문제 진단

작업 흐름 분석

/auto-ship <PR번호>
  └─ 1. code-review:code-review  (코드 리뷰, 수 분)
       └─ 리뷰 코멘트 N건 처리
  └─ 2. fix-review 실행            (코멘트 수에 비례, 수 분~수십 분)
       └─ 코드 수정 → 커밋 → 푸시
  └─ 3. code-review 재실행         (fix 검증, 수 분)
       └─ 이슈 없으면 → 반복, 있으면 → 다시 fix
  └─ 4. gh pr merge                (수 초)

리뷰 이슈가 많거나 fix-review가 여러 라운드를 돌 경우, 총 소요 시간은 30분~1시간+ 가능.

왜 1800s가 문제인가

Slack 봇 세션은 응답 타임아웃이 1800s(30분) 로 고정되어 있다. 이 제한은 Pantheon bridge의 claude -p subprocess call에 적용된다. Slack DM 세션 자체가 장시간 블로킹 태스크에 맞게 설계되지 않았다.

요소	값
Slack 세션 타임아웃	1800s (고정)
auto-ship 예상 소요	600s ~ 3600s (가변)
초과 가능성	리뷰 이슈 5건+ 또는 fix-review 2라운드+ 시 현실적

왜 반복되는가

/auto-ship이 CLAUDE.md에 PR 생성 후 자동 실행 기본값으로 지정됨
Wansu(codex) 페르소나에서 /code-review:code-review 스킬 미노출 → Jarvis 위임 → Jarvis도 동일 타임아웃 적용
HAN-453(timeout 로그 알림)은 1회성 noise로 archived 처리되어 구조 문제가 추적되지 않음

옵션 비교

Option A: CCR 오프로드 (원격 에이전트)

auto-ship 호출 자체를 CCR(Claude Code Remote) 에이전트로 오프로드. Slack 봇 세션과 별개로 실행, 완료 시 DM으로 보고.

장점
- Slack 세션 타임아웃 완전 회피
- 기존 /auto-ship 스킬 내부 변경 최소화
- 실패 시 에이전트 로그 별도 추적 가능

단점
- CCR 에이전트 설정 필요 (CronCreate or RemoteTrigger 활용)
- 완료 알림 채널 별도 설계 필요 (PushNotification + Slack DM)
- 에이전트 실행 지연 (큐 대기) 가능

트레이드오프
- 실행 환경이 분리되어 디버그 복잡도 증가, 대신 세션 블로킹 문제 근본 해소

Option B: 단계 분리 (Phase Split)

/auto-ship을 단계별로 쪼개 각 단계를 독립 Slack 메시지로 호출.

사용자: /auto-ship 237
봇:    1단계(code-review) 완료. fix-review 시작할까요?
사용자: 네
봇:    2단계(fix-review) 완료. 머지할까요?
사용자: 네
봇:    머지 완료.

장점
- 각 단계가 1800s 안에 완료 가능 (단일 단계는 통상 600s 이내)
- 사용자가 중간 결과 확인 + 개입 가능
- 추가 인프라 불필요

단점
- 사용자 개입 포인트 증가 (자율성 저하)
- "자동 ship"이라는 본래 목적과 괴리
- 스크립팅 복잡도 증가 (auto-ship.md 재설계 필요)

트레이드오프
- 신뢰성 ↑, 자율성 ↓. PR 검토 개입을 원하는 경우엔 오히려 선호 가능

Option C: 타임아웃 임계값 상향

claude -p subprocess timeout을 1800s → 3600s 또는 제거.

장점
- 가장 단순한 설정 변경

단점
- 타임아웃은 Pantheon bridge 설정에 박혀 있으며, 제거 시 hang 탐지 불가
- 근본 원인(long-running 작업을 Slack 세션 안에 돌리는 구조) 미해소
- 3600s도 초과 가능성 존재

트레이드오프
- 임시방편. 재발 가능성 높음. 단독 적용 비권장.

권장안

단기: Option A (CCR 오프로드)

선택 근거:
- Slack 세션 타임아웃은 변경 불가 환경 제약
- auto-ship의 자율 실행 특성을 유지하면서 타임아웃 회피 가능
- PushNotification + Slack DM 완료 알림 패턴이 이미 검증됨 (reference_ccr_routines.md)

구현 방향:
1. /auto-ship 호출 시 즉시 CCR 에이전트 spawn (RemoteTrigger)
2. Slack 봇은 "백그라운드 진행 중" 응답 후 세션 종료
3. 에이전트 완료 시 PushNotification → Slack DM 보고

장기: Option B (단계 분리) 병행

리뷰 이슈 규모가 큰 PR에서 사용자가 중간 확인을 원할 경우 opt-in 선택지로 제공.

/auto-ship 237          # CCR 오프로드 (기본)
/auto-ship 237 --step   # 단계 분리 (대화형)