Test

시대의 변화

DevOps 문화의 확산

“만든 사람이 운영한다(You build it, you run it)”는 원래 아마존 CTO 베르너 포겔스가 언급하며 널리 퍼진 원칙이다. 핵심은 책임의 분리를 없애는 것에 있다. 예전에는 개발팀이 코드를 “던지면(throw over the wall)” 운영팀이 받아서 배포하고 장애를 처리했다. 이 구조에서는 개발자가 운영의 고통을 체감하지 못했고 그래서 운영하기 어려운 코드가 계속 만들어졌다.

하지만 개발자도 자신이 만든 코드의 전 생애주기(설계 → 배포 → 운영 → 장애대응 → 개선)를 책임진다. 하지만 인력이 부족한 스타트업에서는 이것은 선택이 아니라 생존 조건이다. 전담 SRE(Site Reliability Engineer)를 둘 여유가 없으므로 백엔드 개발자 한 명이 곧 인프라 담당이자 온콜(on-call) 담당이 된다.

클라우드 네이티브 전환

IaC(Infrastructure as Code)가 표준이 되면서 인프라가 얻은 세 가지 속성이 있다.

• 재현 가능성(Reproducibility): 동일한 코드로 개발/스테이징/프로덕션 환경을 동일하게 만들 수 있다. “내 로컬에선 됐는데요” 문제가 구조적으로 줄어든다.

• 추적 가능성(Traceability): 인프라 변경이 깃 히스토리에 남는다. 누가, 언제, 왜 바꿨는지가 커밋으로 기록된다. 장애 원인 추적이 코드 리뷰처럼 가능해진다.

• 이식성(Portability): 코드로 정의된 인프라는 환경 간 이동이 쉽다.

그러나 다뤄야 할 도구와 개념의 범위가 폭발적으로 넓어졌다. Terraform, Helm, ArgoCD, Prometheus, Grafana, Loki, Istio… 각각이 독립된 학습 대상이다. 편의를 얻은 만큼 인지 부하(cognitive load)가 늘어난 것이다. 바로 이 지점이 뒤에서 다룰 AI의 개입 여지를 만든다.

풀스택 범위의 확장

과거의 “풀스택”은 프론트엔드와 백엔드를 아우르는 것을 뜻했다. 지금의 풀스택은 여기에 인프라 계층이 추가된다. 개발자에게 요구되는 질문이 늘어났다.

이 기능을 어떻게 배포할 것인가? (롤링 업데이트? 블루-그린? 카나리?)

장애를 얼마나 빨리 감지할 수 있는가? (메트릭, 로그, 트레이스는 준비돼 있는가?)

트래픽이 몰릴 때 어떻게 대응할 것인가? (오토스케일링? 레이트 리밋? 서킷 브레이커?)

기능 구현은 이제 전체 업무의 일부일 뿐이다. “돌아가게 만드는 것”과 “운영 가능하게 만드는 것”은 다른 일이며 후자가 점점 더 큰 비중을 차지한다.

왜 쿠버네티스인가?

쿠버네티스의 본질은 추상화 계층이다. 특정 클라우드(AWS, GCP, Azure)에 종속되지 않고 그 위에서 배포·네트워킹·스토리지·보안을 표준화된 방식으로 다룰 수 있게 해준다.

• 배포: Deployment, Pod, ReplicaSet으로 “원하는 상태(desired state)”를 선언하면 쿠버네티스가 알아서 맞춘다.

• 네트워킹: Service, Ingress로 트래픽 라우팅을 추상화한다.

• 스토리지: PersistentVolume으로 클라우드별 디스크 차이를 감춘다.

• 보안: RBAC, NetworkPolicy, Secret으로 권한과 통신을 통제한다.

그래서 쿠버네티스를 이해하는 것이 곧 클라우드를 이해하는 것이 되어버렸다. 클라우드 종속을 벗어나기 위한 도구가 역설적으로 반드시 알아야 할 새로운 표준이 된 셈이다.

문제는 학습 곡선이다. CNCF Landscape를 열어보면 수백 개의 프로젝트가 빼곡히 들어차 있다. “제대로” 운영하려면 알아야 할 것이 너무 많고 하나의 개념을 이해하려면 그 밑에 깔린 다섯 개의 개념을 먼저 알아야 하는 식이다. 진입 장벽이 너무 높다.