AI 기능이 상시 떠 있는 워크로드로 돌면 쓰지 않는 시간에도 자원을 붙잡습니다. 옮길지 말지를 감으로 정하지 않으려고 검토 기준을 먼저 정해 두고 후보를 전수 판정했습니다.
기준 5개를 세우고 하나라도 걸리면 후보에서 빼는 방식으로 12종을 확인해 10종은 옮기고 2종은 남겼습니다.
옮기면 잃는 것도 같은 문서에 먼저 적었습니다. 상시 프로세스에서 유지하던 상태와 연결을 매 호출마다 다시 만들어야 하고, 콜드 스타트가 지연에 더해집니다.
아래부터 당시 작성한 기록을 공개용으로 정제한 전문입니다.
docs/발표자료/근거문서/30초 요약 — 서버리스로 간 목적은 운영 부담 제거였습니다. 그런데 재보니 저희가 겪은 문제 중 «서버리스여야만» 해결되는 건 하나도 없었습니다 — 대부분 EKS + 관리형이면 됐습니다. 그래서 기준을 «관리형보다 나은 이유를 숫자로 말할 수 있는가» 로 잡고 5개 축으로 걸렀고, AI 12종 중 10종만 옮겼습니다. 랭킹 서빙 후보는 동기·지연민감 경로라 콜드스타트가 그대로 응답 시간에 더해진다고 보고 Lambda 이전 대상에서 제외했습니다. 그리고 예상 못 한 발견이 하나 — 비용은 함수가 아니라 네트워크에서 나왔습니다.
«최신 아키텍처라서» 가 아니다. 우리가 실제로 겪은 고통을 먼저 나열하고, 각각이 서버리스로 해결되는지 판정했다.
| 실제 겪은 문제 | 원인 계층 | 서버리스로 해결되나 |
|---|---|---|
| master ×1 단일 장애점(SPOF) | 컨트롤플레인 | 🟢 소멸 — 단 EKS 만으로도 소멸 |
| Redis AOF 손상 → PGSync 16시간 크래시루프 | 상태 관리 | 🟢 상태 없는 캐시로 재정의하면 소멸 |
| 백업·복구 검증 부담 | 데이터 계층 | 🟡 관리형 이전으로 대부분 해결 |
| StorageClass·PV 관리 | 스토리지 | 🟢 소멸 |
| 파드 스케일 튜닝 (KEDA / HPA) | 오케스트레이션 | 🟢 동시성 모델로 대체 |
| 이미지 레지스트리 자격증명 | 배포 | 🟢 IAM 으로 소멸 |
«위 항목 중 서버리스여야만 해결되는 것은 없다. 대부분 관리형(EKS + 매니지드) 이전만으로도 해결된다.»
“이걸 관리형으로 두는 것보다 서버리스로 만드는 게 나은 이유를, 숫자로 말할 수 있는가?”
말할 수 없으면 관리형이 정답이다.
우리는 그 질문을 먼저 던졌고, 그 기준으로 12종을 전부 걸렀다.
| 축 | 묻는 것 | 🔴 인 경우 |
|---|---|---|
| ① | 디스크에 상태를 들고 있는가 | Kafka PV · ES 인덱스 · DB 데이터 |
| ② | 상시 연결을 유지하는가 | PGSync 의 replication slot · WebSocket · 스트림 컨슈머 |
| ③ | 최소 과금이 실사용을 초과하는가 | OpenSearch Serverless(최소 OCU 상시) · MSK Serverless(클러스터 시간 과금) |
| ④ | 실행 시간이 15분을 넘는가 | 대량 재색인 |
| ⑤ | 저지연 + 무거운 초기화가 겹치는가 | 랭킹 서빙(모델 언피클) |
🔴 ②가 특히 중요하다 — 기준은 «실행 시간» 이 아니라 «연결 지속성» 이다. 🔴 ③은 가장 놓치기 쉽다 — “서버리스”라는 이름이 붙었다고 요청당 과금인 게 아니다.
| 분류 | 함수 | 트리거 | 왜 이 자리인가 |
|---|---|---|---|
| 배치 5종 | shelflife-draft ner-backfill sentiment-batch summarize-batch price-detect | Scheduler · 수동 | 저빈도 배치 = 미호출 시 실행 요금 없음. 서버리스 최적 |
| 접수·워커 4종 | video-api+video-worker · ocr-api+ocr-worker | ALB · SQS | 비동기라 콜드스타트가 사용자에게 안 보인다 |
| 서비스 1종 | chat-api | ALB | 호출이 드물고 콜드스타트를 감내할 수 있다 |
| ⛔ 이관 제외 | rank-serve | — | 동기 · 지연민감 — 아래 참조 |
| ⛔ 설계에서 소거 | notify-consumer | — | 함수를 만드는 대신 안 만드는 쪽으로 설계를 줄였다 |
rank-serve 를 안 옮긴 이유 — 발표의 하이라이트진입점을 무엇으로 할지 고르기 전에 물었어야 할 질문이 있었다 — «Lambda 가 맞는 자리인가?»
| 서버리스의 이득 | 랭킹 서빙에서는 |
|---|---|
| scale-to-zero | 🔴 추천은 상시 호출된다 — 0 으로 안 내려간다 |
| 요청당 과금 | 🔴 상시 호출이면 파드가 더 싸다 |
| 운영 부담 감소 | 🔴 오히려 는다 — 유일한 컨테이너라 별도 ECR·빌드 경로가 생긴다 |
«고칠 것이 없는 것을 옮기는 셈» 이었다. 세 후보 중 작업이 0인 것이 답이었다.
| 잃는 것 | 내용 |
|---|---|
| GitOps 서사 | ArgoCD · Kustomize · NetworkPolicy · KEDA 는 전부 K8s 전제 — 기술 문제가 아니라 프로젝트 정체성 문제 |
| 락인 방향이 반대 | K8s 매니페스트는 이동 가능 / Step Functions·EventBridge 배선은 이동 불가 |
| 이전이 아니라 리라이트 | Kafka → EventBridge/SQS · PGSync 대체 · LGTM → CloudWatch. 일정 산정 단위가 다르다 |
그리고 새로 생기는 위험 4가지 — ① 같은 작업의 이중 실행(재시도가 기본) ② 실패가 조용히 사라짐(→ DLQ 전부 부착) ③ 스케줄 미실행은 에러가 안 남(→ «돌았어야 할 시간» 알람) ④ 파드 개수라는 자연 상한이 사라져 외부 API 쿼터에 먼저 걸림(→ 동시성 명시 제한).
chat-api 실물 콜드스타트video-api — 30배 차이rank-serve 결정을 실물로 확증한다
그 결정의 근거는 «로컬 x86 1.05초» 라는 추정 하한이었는데, 성격이 가장 비슷한 함수의 실물이 3.0초로 나왔다. ⇒ 발표에서 «1.05초 추정» 대신 «성격이 유사한 함수의 실물 콜드스타트가 3초였다» 를 쓸 수 있다.
컴퓨트는 20배 싸졌고, 네트워크는 243배 비쌌다.
⚠️ 단, 우리 형상에서는 NAT·엔드포인트가 EKS 때문에 이미 있어서 증분이 0 이다. 정확한 서술 = «서버리스 단독이었다면 월 $89.79 를 새로 냈어야 했다» ⇒ 하이브리드가 더 쌌다.
| 질문 | 답변 |
|---|---|
| 전부 서버리스로 가나요? | 아닙니다. 재보고 경계를 그었습니다. 안 맞는 것은 서버리스 이전 대상에서 제외했습니다 |
| 쿠버네티스를 배웠는데 왜 버리나요? | 버리는 게 아니라 계층별로 나눕니다. 데이터 계층은 그대로 K8s 입니다 |
| EKS 로 그냥 올린 것과 뭐가 다른가요? | 그 질문을 저희가 먼저 던졌습니다. 대부분은 EKS 로 해결됐고, 서버리스는 «그보다 나은 이유가 있는 것» 만 골랐습니다 |
| 응답이 느려지지 않나요? | 사용자 경로는 접수 함수가 93 ms 로 즉답하고 처리는 큐 뒤로 보냅니다. 지연에 민감한 경로(랭킹 서빙 후보)는 이전 대상에서 제외했습니다 |
| 비용이 정말 줄어드나요? | 과금 축이 달라 단순 비교가 안 됩니다. 컴퓨트는 20배 싸고 네트워크는 243배 비쌉니다 |
| 잘못되면 되돌릴 수 있나요? | 이전 경로를 살려 두고 병행합니다. 조건 미달이면 그 상태로 되돌립니다 |
| 왜 AI 부터 하나요? | 상태가 없고 이벤트성이라, 실패해도 다른 계층에 파급이 없습니다 |
| 락인 문제는요? | 인지하고 있습니다 — 비즈니스 로직을 프레임워크에 안 묶이게 유지했습니다 |
| ❌ | 왜 |
|---|---|
| “전부 서버리스로 갑니다” | 사실이 아니다 — 10/12 다 |
| “비용이 줄었습니다” | 과금 축이 달라 단순 비교 불가. «비용이 어디서 나오는지 자리가 바뀌었다» 가 정확하다 |
| 콜드스타트를 숨기기 | 어차피 질문 나온다. 먼저 말하는 게 낫다 |
| “챗봇 응답이 456 ms 입니다” | §9 — 라벨을 바꾸지 않으면 틀린 말이 된다 |
질문: “라이브가 template 모드라도 다듬기(refine)에는 LLM 을 쓰는데 왜 못 쓰나?”
| 확인 대상 | 결과 (2026-08-18 실측) |
|---|---|
| 코드가 refine 을 지원하나 | 🟢 그렇다 — generator_backend = template | gemini | bedrock, 레시피 추천만 다듬음 |
| EKS 라이브 설정 | 🔴 GENERATOR_BACKEND = template |
| 온프렘 라이브 설정 | 🔴 GENERATOR_BACKEND = template |
⇒ 양쪽 클러스터 모두 지금 이 순간 template 이다. 기능이 구현되지 않은 것이 아니라, 생성 백엔드를 고르는 플래그가 template 으로 설정돼 있는 상태다.
456 ms 의 정체 — 모델 선정 벤치마크에서 잰 nova-micro-seoul 의 refine 응답 지연이다.
«프로덕션 refine 경로 20/20 으로 Gemini 와 동률 · 40 % 저렴 · 2배 빠름» 의 근거로 쓰였다. 숫자 자체는 유효한 실측이다.
| ❌ 틀림 | ✅ 맞음 |
|---|---|
| “저희 챗봇 응답 속도는 456 ms 입니다” | “모델을 고를 때 후보 5종을 실측 비교했고, 선정된 nova-micro 의 다듬기 응답이 456 ms 로 Gemini 대비 2배 빠르고 40 % 저렴했습니다” |
| «라이브 성능» 으로 제시 | «모델 선정 근거» 로 제시 — 이쪽이 «재보고 골랐다» 서사에 더 맞는다 |
🔵 버릴 숫자가 아니라 자리를 옮길 숫자다. 다만 이 수치는 모델 선정 벤치마크에서 측정한 값이며 라이브 트래픽 실적이 아니다. 어느 생성 백엔드를 쓸지는 비용 가드와 함께 팀이 정한다.