Production 패턴 — Middleware, CORS, 에러, 로그

CORS — 잠겨있지 열려있지 않음

cwkPippa 의 CORS 가 세 origin 허용: localhost:5173, 127.0.0.1:5173, Tailscale IP 100.x.y.z:5173. 그 외 다 reject. Tailnet 의 새 device? IP 추가. default 'allow all origins' 는 보안 구멍, 사적 box 에서도.

Middleware — 요청 lifecycle hook

FastAPI middleware 는 모든 요청 wrap. cwkPippa 는 적게 사용: request-id 생성기, 구조화된 logger, heartbeat 와 coordinate 하는 streaming guard (Heart track, lesson 4). middleware 는 cheap 해야 — 비싼 건 route 또는 background task 에.

에러 — 시끄럽게 fail, 정직하게 fail

silent catch 안 해. adapter raise 하면, route 가 SSE 위 error event 띄워서 frontend 가 'I got stuck — try again' 보여줘. chat 이 'fine 해 보이도록' 예외 삼키지 마. 다른 각도에서 broken-chat 죄.

로그 — string 아닌 structured

각 log line 이 JSON: timestamp, level, request_id, message, plus structured fields. grep 쉽고, jq 로 parse 쉽고, log viewer 에 feed 쉽고. plain-text log 는 일정 양 넘으면 unreadable.

Production 경계는 "내 Mac에서 되네" 다음에 시작해. 허용한 origin이 실제 served URL과 맞는지, proxy 뒤에서도 request id가 이어지는지, SSE error가 HTTP 200 안에 숨지 않고 UI 상태로 번역되는지 확인해야 해. 설정 파일이 그럴듯한 것과 실제 요청이 그 경로를 통과하는 건 다른 얘기야.

로그에는 비밀도 경계가 있어. prompt 원문이나 credential을 편해서 통째로 남기면 관측 가능성을 얻는 대신 다른 사고를 만든다. request id, event kind, duration, provider, outcome처럼 진단에 필요한 shape를 남기고 민감한 payload는 요약하거나 빼. 좋은 structured log는 모든 걸 저장하는 장부가 아니라, 실패를 재구성할 만큼만 정직한 장부야.

그리고 middleware에 정책을 너무 많이 모으지 마. 모든 route를 지나간다는 편리함 때문에 business rule까지 넣기 시작하면 숨은 조상이 돼. request lifecycle에 공통인 일만 두고, 도메인 판단은 이름 있는 service와 route에서 보여 줘.