AI와 함께 만드는 삶

PM으로 일하며 AI와 함께 무언가를 만들어가는 삶을 기록합니다.

AI활용법/PM의 AI실무

PM을 위한 AI 실무 사전 2편 — 폴백 체인, 스트리밍, 콜드 슬립

makewithai 2026. 8. 4. 16:20

누구나법률 2장(진짜 문제는 기술이 아니라 돈이었다)에서 나온 개념 세 가지: LLM 멀티 프로바이더 체인, SSE vs REST, 무료 호스팅의 콜드 슬립.

LLM 폴백 체인 — 왜 모델 하나로는 안 되나

AI 서비스를 하나의 LLM(예: Claude API)에만 의존해서 만들면, 그 모델이 막히는 순간 서비스 전체가 멈춘다. 막히는 이유는 다양하다 — API 비용 한도 초과, 요청 제한(rate limit), 일시적 서버 장애. 하나에만 의존하면 그 하나가 곧 전체의 장애 지점(single point of failure)이 된다.

그래서 실무에서 흔히 쓰는 패턴이 "주 모델이 실패하면 다음 모델로 자동 전환"하는 폴백 체인이다.

 
1순위(Groq) 실패 → 2순위(Gemini) 시도 → 3순위(Ollama, 로컬) 시도 → 최후(Mock 응답)

여기서 실무적으로 중요한 건 두 가지다.

  1. "1순위가 실패하면 2순위로 간다"는 조건문을, 실제로 1순위를 강제로 실패시켜서 테스트해봐야 한다. 2장에서 다룬 버그가 정확히 이 지점이었다 — 조건문이 특정 provider 값일 때는 fallback 분기 자체를 안 타는 구조였는데, 정상적인 상황(1순위가 잘 작동할 때)에서는 절대 드러나지 않는 버그였다. 실패 케이스를 강제로 만들어보지 않으면 이런 버그는 장애가 실제로 터질 때까지 숨어있는다.
  2. "가장 똑똑한 모델"과 "실서비스에 적합한 모델"은 다른 기준이다. 응답 품질만 보면 상위 모델이 항상 좋겠지만, 무료 티어 조합으로 체인을 구성하면 비용 부담 없이 "일단 대답은 나온다"는 안정성을 확보할 수 있다. 초기 단계에서는 품질보다 가용성이 우선일 때가 많다.

SSE vs REST — 실시간처럼 보여줄 것인가, 그냥 기다리게 할 것인가

**REST(일반 API 호출)**는 요청 한 번에 응답 한 번이다. AI 분석처럼 시간이 걸리는 작업이면, 사용자는 응답이 올 때까지 그냥 기다린다. 프론트엔드에서 "로딩 중..." 같은 걸 보여주려면, 실제 진행률을 모르니 가짜 애니메이션을 돌리거나 몇 초마다 "다 됐나요?"를 반복해서 묻는(polling) 방식을 쓴다.

**SSE(Server-Sent Events)**는 서버가 연결을 계속 열어둔 채로, 진행 상황이 생길 때마다 클라이언트로 데이터를 계속 밀어준다. "25% 완료 → 50% 완료 → 분석 결과 도착" 같은 실시간 업데이트가 가능하다. 사용자 경험은 확실히 더 좋다.

문제는 SSE가 인프라에 더 많이 기댄다는 것이다. 연결을 오래 열어둬야 하는데, 중간에 있는 프록시 서버나 무료 호스팅은 "일정 시간 응답이 없으면 연결을 끊는" 정책을 갖고 있는 경우가 많다. 2장에서 겪은 것처럼, 이 정책을 모르고 SSE를 붙이면 계속 연결이 끊기고, 그걸 고치려고 하트비트(가짜 신호를 주기적으로 보내 "아직 살아있다"고 알리는 것)까지 붙여도 불안정할 수 있다.

실무 판단 기준: 초기 단계(특히 무료·저사양 호스팅)에서는 SSE 같은 정교한 기술보다 REST + 가짜 진행률 애니메이션이 결과적으로 더 안정적일 때가 많다. 인프라가 안정된 뒤(자체 서버, 유료 티어) 다시 시도해도 늦지 않다. "더 좋은 기술"이 지금 이 인프라 위에서 "더 안정적인 선택"은 아닐 수 있다는 걸 구분해야 한다.

SSE와 REST 방식 비교, REST는 요청 한 번에 응답 한 번으로 인프라 부담이 낮고, SSE는 연결을 유지하며 실시간 진행률을 보여주지만 인프라 부담이 높음

 

콜드 슬립 — 무료 호스팅이 잠드는 이유

Render 같은 무료 호스팅 티어는 비용을 아끼려고, 일정 시간(보통 15분 안팎) 요청이 없으면 서버 프로세스를 아예 꺼버린다. 이 상태를 "슬립(sleep)"이라 부른다.

슬립 상태에서 첫 요청이 들어오면, 서버가 처음부터 다시 켜져야 한다(콜드 스타트, cold start). 이 과정이 보통 몇 초에서 10초 이상 걸린다. 사용자 입장에서는 "첫 방문자만 유독 느린" 서비스로 보인다.

임시방편은 외부 모니터링 서비스로 주기적으로(예: 5분마다) 가짜 요청을 보내 서버가 절대 잠들지 않게 만드는 것이다(2장에서 쓴 UptimeRobot이 이런 용도다). 다만 이건 "잠들지 않게 계속 깨워두는" 우회일 뿐, 애초에 슬립 정책이 없는 호스팅으로 옮기는 게 근본 해결이다. Fly.io 같은 곳은 설정으로 "이 서버는 절대 자동으로 끄지 마라"를 명시할 수 있다 — 이 이야기는 5장에서 이어진다.

 

무료 호스팅 콜드 슬립 흐름도, 정상 응답 상태에서 15분간 요청 없으면 서버 슬립, 첫 요청 시 콜드 스타트로 지연 발생 후 다시 정상 응답으로 돌아오는 과정


다음 실무 사전 편은 누구나법률 3장(법제처 API와 Groq)이 발행된 후, 그 안에 나오는 개념들을 정리해서 이어간다.