1. 최적화 그 이상의 대응: 관찰 가능성(Observability) 확보
전통적인 성능 최적화 기법인 캐싱, 인덱싱, 백그라운드 작업만으로는 해결할 수 없는 지연이 존재합니다. 원격 API 호출, OCR 처리, 이미지 프로세싱, 그리고 최근 급증하는 LLM 추론과 같은 작업은 애플리케이션의 통제 범위를 벗어난 경우가 많습니다. 이러한 상황에서 단순히 로딩 스피너를 보여주는 것은 사용자에게 아무런 확신을 주지 못합니다. Kaigi on Rails 2025에서 강조된 핵심 아이디어는 “지연이 불가피하다면, 그것을 관찰 가능하게 만들라”는 것입니다. 사용자가 시스템의 진행 상황을 알 수 있게 함으로써 새로고침을 하거나 페이지를 이탈하는 부정적인 경험을 방지할 수 있습니다.
2. UX 전략으로서의 Server-Sent Events (SSE)
SSE는 서버에서 클라이언트로 실시간 업데이트를 스트리밍하는 가벼운 메커니즘을 제공합니다. 이는 단순한 네트워킹 기술을 넘어, 작업의 진행 상태, 중간 단계 결과, 그리고 완료 신호를 실시간으로 전달하는 사용자 경험 전략으로 기능합니다.
- 주요 활용 사례: 장시간 실행되는 작업의 진행률 표시, 백그라운드 처리 로그의 실시간 스트리밍, AI 기반 워크플로우의 증분 업데이트 제공.
- Rails의 지원: Rails는 ActionController::Live를 통해 SSE를 네이티브로 지원하므로, 별도의 외부 인프라 구축 없이도 구현이 가능합니다. 이는 클라이언트가 서버의 응답을 수동적으로 기다리는 대신, 서버가 준비된 정보를 즉시 밀어낼 수 있게 합니다.
3. Async Gem과 Fiber 기반의 병렬 처리 시너지
SSE의 효용을 극대화하기 위해서는 Ruby의 async gem을 활용한 비동기 실행이 필수적입니다. I/O 바운드 작업에서 Fiber 기반의 동시성을 활용하면 다음과 같은 기술적 이점을 얻을 수 있습니다.
- 병렬 I/O 실행: 여러 외부 API 호출을 동시에 진행하여 전체 대기 시간을 최적화합니다.
- 점진적 피드백: 병렬 작업 중 일부 결과가 먼저 도착하면, 전체 작업이 완료될 때까지 기다리지 않고 즉시 SSE를 통해 클라이언트에 스트리밍할 수 있습니다.
- 응답성 유지: 대규모 I/O 대기 상황에서도 서버의 메인 실행 흐름이 차단되지 않아, 시스템의 전반적인 처리 능력이 향상됩니다.
4. 실제 운영 환경에서의 기술적 함정 및 해결책
SSE를 실제 서비스에 도입할 때는 인프라 계층에서의 여러 제약 사항을 고려해야 합니다. 세션 발표에서는 특히 다음과 같은 실무적 문제들을 지적했습니다.
- 리버스 프록시 버퍼링: Nginx와 같은 리버스 프록시가 응답 본문을 버퍼링하여 스트리밍이 작동하지 않는 경우가 있습니다. 이를 방지하기 위해 X-Accel-Buffering: no 헤더 설정이 필요합니다.
- HTTP 헤더 최적화: 실시간성 보장을 위해 Cache-Control: no-cache 헤더를 명확히 설정해야 하며, 미들웨어가 응답 본문을 가로채지 않도록 구성해야 합니다.
- 통합의 어려움: OpenAPI 도구와의 통합이나, 기존 JSON 응답 방식과 ActionController::Live를 혼용할 때 발생할 수 있는 데이터 구조의 일관성 문제를 사전에 검토해야 합니다. SSE를 단순히 부가 기능이 아닌 일급 시민(First-class delivery mechanism)으로 대우할 때 안정적인 서비스 운영이 가능합니다.