분석 완료 알림은 push 없이 폴링으로 한다
맥락
분석은 수십 초가 걸리는 비동기 작업이다. AI가 callback으로 결과를 보내면 서버가 잡을 종료 상태로 전이시키는데, 그 사실을 web에 알릴 경로가 없었다. 알림이 필요한 사건은 잡당 한 번뿐이다. 서버는 여러 인스턴스로 뜰 수 있다.
결정
GET .../analyses/latest폴링으로 알린다. STOMP/SSE push를 만들지 않는다.- 즉시성이 필요해지면 후속 이슈에서 SSE로 승격한다고 이슈 본문에 적어 둔다.
대안
대안 1 — STOMP/SSE push. 즉시 알림이 가고 빈 왕복이 사라진다. 기각한 이유: 실시간 채널을 하나 더 유지해야 하고 전달 보장·재연결이 딸려온다. 1회성 완료 신호에 그만한 비용을 쓸 이유가 없었다. 폴링은 서버 인스턴스가 늘어도 안전하다. MVP 단순성을 우선했다.
결과
- 실시간 채널을 유지하지 않는다. 서버 인스턴스가 늘어도 동작은 그대로다.
- 실시간 채널(
/topic/notes/{noteId})이 생긴 뒤에도 완료 알림은 폴링에 남았다. 채널이 있어도 1회성 신호에는 폴링이 맞다고 사후에 확인된 셈이다. 이 판단은 알림 도메인 전체가 "type+resource_id얇은 범용 구조 + GET 폴링"으로 굳으면서 그쪽에 흡수됐다. - 폴링 주기만큼 알림이 늦는다. 즉시성이 필요해지는 순간 SSE 승격이 통째로 남은 작업이 된다.
- 노트 화면이 떠 있는 동안 완료 여부와 무관하게 요청이 계속 나간다. 분석이 수십 초 걸리므로 대부분은 "아직"이라는 답을 받는 빈 왕복이다.
- 완료 시점을 서버가 아는데 클라이언트가 물어봐야만 안다. 알림 지연의 하한이 클라이언트 주기로 정해지고 서버는 그 지연을 줄일 수단이 없다.
- 폴링이 끝나는 조건이 다른 결정에 의존한다. 잡을
SUCCEEDED/FAILED로 반드시 수렴시키는 것은 워치독(APP-73)이다. 워치독이 없으면PENDING에 남거나RUNNING에 갇힌 잡 앞에서 폴링이 끝나지 않는다. 워치독은 같은 주에 들어와 이 종료 조건을 보장했다.