マネージドへ渡すとき一緒に渡るもの

한 줄 요약

IaaS·PaaS·SaaS 는 기술 분류가 아니라 어디까지 남에게 맡길 것인가의 눈금 입니다. 위로 갈수록 편해지고, 같은 만큼 통제권을 잃습니다.

왜 이게 필요했나

"RDS 쓸까요, EC2 에 직접 설치할까요?" 는 거의 모든 프로젝트가 한 번은 하는 질문입니다. 답은 "무엇이 더 좋은가" 가 아니라 무엇을 포기할 수 있는가로 갈립니다.

	IaaS (EC2에 직접)	PaaS (RDS)
버전 선택	아무 버전이나	사업자가 지원하는 버전만
확장 기능	무엇이든 설치	허용 목록에 있는 것만
OS 접근	root 로 무엇이든	없음 — 셸이 없다
패치	우리가 계획	유지보수 창에 사업자가
장애 조사	로그·프로파일 자유	노출된 지표와 로그만
운영 인력	필요	거의 불필요
비용	대개 저렴	대개 비쌈

OS 접근이 없다는 항목이 실무에서 가장 뼈아픕니다. PostgreSQL 확장 하나를 못 써서, 또는 커널 파라미터를 못 만져서 관리형을 포기하는 경우가 실제로 나옵니다. 그래서 결정 전에 "우리가 지금 서버에서 무엇을 하고 있나" 를 목록으로 적어 보는 게 좋습니다.

어떻게 동작하나

컨테이너는 어디에 있나

IaaS ─ VM ─ 컨테이너(직접 운영) ─ 관리형 K8s ─ 컨테이너 서버리스 ─ PaaS ─ SaaS
                                  (EKS/AKS/GKE)   (Fargate/Cloud Run)

관리형 쿠버네티스는 컨트롤 플레인만 맡깁니다. 워커 노드의 OS·kubelet·CNI 는 여전히 우리 몫인 경우가 많고, 이걸 모르면 "관리형인데 왜 노드 패치를 우리가 하죠?" 라는 질문이 나옵니다.

서버리스는 무엇을 맞바꾸나

함수 단위 실행(Lambda 등)은 운영 부담이 거의 없어지는 대신 제약이 붙습니다.

• 콜드 스타트 — 한동안 호출이 없으면 첫 요청이 느립니다.
• 실행 시간 상한 — 긴 작업은 못 돌립니다.
• 상태 없음 — 로컬 디스크·메모리에 무언가를 쌓을 수 없습니다.
• 벤더 종속 — 이벤트 모델과 런타임이 사업자마다 다릅니다.

트래픽이 들쭉날쭉하고 작업이 짧으면 압도적으로 유리하고, 꾸준한 부하에 긴 작업이면 오히려 비쌉니다.

종속성(lock-in)을 값으로 계산하기

관리형을 쓰면 그 사업자에 묶입니다. 이걸 무조건 피하려 들면 아무것도 못 쓰지만, 값을 모르고 쓰면 나중에 이사 비용이 폭발합니다. 판단 기준은 이렇습니다.

• 표준 위에 있나 — PostgreSQL 호환 관리형은 옮기기 쉽고, 독자 API 는 어렵다.
• 데이터가 얼마나 쌓이나 — 데이터가 클수록 이사가 비싸진다.
• 대체재가 있나 — 다른 사업자에 같은 성격의 서비스가 있는가.

"종속되지 않겠다" 보다 "종속되는 대가로 무엇을 얻는지 안다" 가 더 쓸모 있는 태도입니다.

현장에서 만나는 모습

• 관리형 DB 로 옮겼는데 필요한 확장이 없어 되돌림 → 사전 확인 누락.
• 서버리스로 배치를 돌리다 실행 시간 상한에 걸림 → 작업 성격이 안 맞았다.
• 관리형 K8s 인데 노드 CVE 대응을 우리가 함 → 경계를 오해했다.

책임 경계를 문장으로 적어 둔다

모델을 고르는 것보다 더 자주 사고를 내는 것은 경계를 오해하는 것이다. "관리형이니까 알아서 해 주겠지" 로 남겨 둔 항목이 실은 우리 몫이었던 경우가 대부분이다. 그래서 도입할 때마다 다음 항목이 누구 몫인지 한 줄씩 적어 두는 편이 좋다.

항목	누가 하나
물리 장비와 하이퍼바이저	언제나 사업자
게스트 OS 패치	IaaS 는 우리, PaaS 는 사업자, 관리형 K8s 의 노드는 대개 우리
애플리케이션 취약점	언제나 우리
접근 권한 설정	언제나 우리
데이터 암호화 여부	대개 우리가 켠다
백업 보관 기간과 복구 시험	사업자가 백업을 만들어도 복구 시험은 우리
가용 영역 배치	우리가 정한다

표에서 가장 자주 배신당하는 줄이 백업입니다. 관리형 데이터베이스가 매일 백업을 만들어 준다는 사실을 근거로 안심하지만, 그 백업으로 실제 복구가 되는지, 보관 기간이 우리가 필요한 만큼인지, 그리고 계정 자체가 잘못되었을 때에도 남아 있는지는 전부 우리가 확인할 일이다. 백업이 있다는 것과 복구할 수 있다는 것은 다른 사실이다.

권한도 마찬가지다. 클라우드에서 일어나는 사고의 큰 부분이 "설정을 잘못한 것" 이고, 이 영역은 어떤 모델을 골라도 우리 몫으로 남는다. 위로 올라갈수록 줄어드는 것은 운영 부담이지 책임이 아닙니다. 오히려 관리형을 쓸수록 우리가 통제할 수 있는 수단이 설정뿐이므로, 그 설정 하나하나의 무게가 커진다. 그래서 관리형으로 옮길 때는 손이 덜 가는 만큼 남은 손을 설정 검토와 복구 시험에 써야 하고, 그 시간을 잡아 두지 않으면 절감한 운영 시간이 그대로 위험으로 바뀐다.

다음에 볼 것

관리형 서비스의 값이 어디서 나오는지 — 요금표가 아니라 운영 시간 으로 봅니다.