누구나법률 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순위가 실패하면 2순위로 간다"는 조건문을, 실제로 1순위를 강제로 실패시켜서 테스트해봐야 한다. 2장에서 다룬 버그가 정확히 이 지점이었다 — 조건문이 특정 provider 값일 때는 fallback 분기 자체를 안 타는 구조였는데, 정상적인 상황(1순위가 잘 작동할 때)에서는 절대 드러나지 않는 버그였다. 실패 케이스를 강제로 만들어보지 않으면 이런 버그는 장애가 실제로 터질 때까지 숨어있는다.
- "가장 똑똑한 모델"과 "실서비스에 적합한 모델"은 다른 기준이다. 응답 품질만 보면 상위 모델이 항상 좋겠지만, 무료 티어 조합으로 체인을 구성하면 비용 부담 없이 "일단 대답은 나온다"는 안정성을 확보할 수 있다. 초기 단계에서는 품질보다 가용성이 우선일 때가 많다.
SSE vs REST — 실시간처럼 보여줄 것인가, 그냥 기다리게 할 것인가
**REST(일반 API 호출)**는 요청 한 번에 응답 한 번이다. AI 분석처럼 시간이 걸리는 작업이면, 사용자는 응답이 올 때까지 그냥 기다린다. 프론트엔드에서 "로딩 중..." 같은 걸 보여주려면, 실제 진행률을 모르니 가짜 애니메이션을 돌리거나 몇 초마다 "다 됐나요?"를 반복해서 묻는(polling) 방식을 쓴다.
**SSE(Server-Sent Events)**는 서버가 연결을 계속 열어둔 채로, 진행 상황이 생길 때마다 클라이언트로 데이터를 계속 밀어준다. "25% 완료 → 50% 완료 → 분석 결과 도착" 같은 실시간 업데이트가 가능하다. 사용자 경험은 확실히 더 좋다.
문제는 SSE가 인프라에 더 많이 기댄다는 것이다. 연결을 오래 열어둬야 하는데, 중간에 있는 프록시 서버나 무료 호스팅은 "일정 시간 응답이 없으면 연결을 끊는" 정책을 갖고 있는 경우가 많다. 2장에서 겪은 것처럼, 이 정책을 모르고 SSE를 붙이면 계속 연결이 끊기고, 그걸 고치려고 하트비트(가짜 신호를 주기적으로 보내 "아직 살아있다"고 알리는 것)까지 붙여도 불안정할 수 있다.
실무 판단 기준: 초기 단계(특히 무료·저사양 호스팅)에서는 SSE 같은 정교한 기술보다 REST + 가짜 진행률 애니메이션이 결과적으로 더 안정적일 때가 많다. 인프라가 안정된 뒤(자체 서버, 유료 티어) 다시 시도해도 늦지 않다. "더 좋은 기술"이 지금 이 인프라 위에서 "더 안정적인 선택"은 아닐 수 있다는 걸 구분해야 한다.

콜드 슬립 — 무료 호스팅이 잠드는 이유
Render 같은 무료 호스팅 티어는 비용을 아끼려고, 일정 시간(보통 15분 안팎) 요청이 없으면 서버 프로세스를 아예 꺼버린다. 이 상태를 "슬립(sleep)"이라 부른다.
슬립 상태에서 첫 요청이 들어오면, 서버가 처음부터 다시 켜져야 한다(콜드 스타트, cold start). 이 과정이 보통 몇 초에서 10초 이상 걸린다. 사용자 입장에서는 "첫 방문자만 유독 느린" 서비스로 보인다.
임시방편은 외부 모니터링 서비스로 주기적으로(예: 5분마다) 가짜 요청을 보내 서버가 절대 잠들지 않게 만드는 것이다(2장에서 쓴 UptimeRobot이 이런 용도다). 다만 이건 "잠들지 않게 계속 깨워두는" 우회일 뿐, 애초에 슬립 정책이 없는 호스팅으로 옮기는 게 근본 해결이다. Fly.io 같은 곳은 설정으로 "이 서버는 절대 자동으로 끄지 마라"를 명시할 수 있다 — 이 이야기는 5장에서 이어진다.

다음 실무 사전 편은 누구나법률 3장(법제처 API와 Groq)이 발행된 후, 그 안에 나오는 개념들을 정리해서 이어간다.
'AI활용법 > PM의 AI실무' 카테고리의 다른 글
| PM을 위한 AI 실무 사전 6편 — 죽은 API와 의존성 함정 (0) | 2026.08.07 |
|---|---|
| PM을 위한 AI 실무 사전 5편 — PG, CORS, 도메인, OAuth (0) | 2026.08.07 |
| PM을 위한 AI 실무 사전 4편 — 사회적기업 인증과 공모전 생태계 (0) | 2026.08.07 |
| PM을 위한 AI 실무 사전 3편 — RAG, 환각, 그라운딩 (0) | 2026.08.05 |
| PM을 위한 AI 실무 사전 1편 — MVP, 그리고 스택 선택 (0) | 2026.08.04 |