| 축 | 묻는 것 | 🔴 인 경우 |
|---|---|---|
| ① | 디스크에 상태를 들고 있는가 | Kafka PV · ES 인덱스 · DB 데이터 |
| ② | 상시 연결을 유지하는가 | PGSync 의 replication slot · WebSocket · 스트림 컨슈머 |
| ③ | 최소 과금이 실사용을 초과하는가 | OpenSearch Serverless(최소 OCU 상시) · MSK Serverless(클러스터 시간 과금) |
| ④ | 실행 시간이 15분을 넘는가 | 대량 재색인 |
| ⑤ | 저지연 + 무거운 초기화가 겹치는가 | 랭킹 서빙(모델 언피클) |
🔴 ②가 특히 중요하다 — 기준은 «실행 시간» 이 아니라 «연결 지속성» 이다. 🔴 ③은 가장 놓치기 쉽다 — “서버리스”라는 이름이 붙었다고 요청당 과금인 게 아니다.
| 잃는 것 | 내용 |
|---|---|
| GitOps 서사 | ArgoCD · Kustomize · NetworkPolicy · KEDA 는 전부 K8s 전제 — 기술 문제가 아니라 프로젝트 정체성 문제 |
| 락인 방향이 반대 | K8s 매니페스트는 이동 가능 / Step Functions·EventBridge 배선은 이동 불가 |
| 이전이 아니라 리라이트 | Kafka → EventBridge/SQS · PGSync 대체 · LGTM → CloudWatch. 일정 산정 단위가 다르다 |
그리고 새로 생기는 위험 4가지 — ① 같은 작업의 이중 실행(재시도가 기본) ② 실패가 조용히 사라짐(→ DLQ 전부 부착) ③ 스케줄 미실행은 에러가 안 남(→ «돌았어야 할 시간» 알람) ④ 파드 개수라는 자연 상한이 사라져 외부 API 쿼터에 먼저 걸림(→ 동시성 명시 제한).