왜 쿠버네티스를 포기하고 단순성에서 행복을 찾았는가

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

DevOps

대상자

• DevOps 엔지니어, 인프라 관리자, 팀 리더
• 중간 난이도: 인프라 복잡성과 도구 선택에 대한 실무 경험 필요

핵심 요약

• 쿠버네티스는 복잡성과 시간 소모로 인해 실무에서 과도한 부담을 유발
• Fargate, Fly.io, VPS 등 단순한 인프라 솔루션으로 전환하여 생산성 향상
• "복잡성이 아니라 실용성"을 기준으로 인프라 결정을 수정

섹션별 세부 요약

1. 쿠버네티스 도입의 초기 기대

• Kubernetes가 제공하는 자동 확장, 롤링 업데이트, 컨테이너 오케스트레이션 기능 강조
• DevOps 문화에 대한 자부심 유발 (예: .yaml 파일 조작)
• Netflix 등 대규모 인프라 사례로의 비유 사용

2. 쿠버네티스 사용 중 발생한 문제점

• 라이브니스 프로브 설정 오류, 네트워크 이슈, YAML 인덴트 오류로 인한 프로덕션 다운타임
• DevOps 팀이 클라우드 제공자 SRE 역할을 수행하는 상황 발생
• 인프라 관리가 애플리케이션 개발보다 우선순위가 되는 문제

3. 쿠버네티스 포기 결정과 대안 탐색

• 팀 내부 회의에서 "실제로 필요한 인프라"에 대한 재검토
• 필요한 기능: 빠른 배포, 간단한 롤백, 고가용성, Dev 환경의 용이성
• Fargate, Fly.io, VPS 등 단순한 솔루션 탐색

4. 단순한 솔루션의 성공 사례

• Fargate: AWS 기반의 자동 프로비저닝, 노드 관리 불필요
• Fly.io: fly deploy 명령어로 간단한 배포, 전역 엣지 배포 지원
• VPS + GitHub Actions: 예측 가능한 인프라, YAML 복잡성 제거

5. 결과와 문화적 변화

• 배포 시간 단축, 다운타임 감소, 온콜 팀의 스트레스 감소
• "Kubernetes가 필요했던 적 없다"는 인식 확산
• 팀원의 생산성과 자신감 향상, 기능 개발 속도 증가

결론

• "복잡성이 아니라 실용성"을 기준으로 인프라 선택하는 것이 핵심
• Fargate, Fly.io 등 단순한 솔루션은 복잡성 감소와 생산성 향상에 효과적
• 과도한 인프라 선택은 미래의 확장성보다 현재의 실용성을 희생하는 것