쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

Intro: “IT는 한 우물을 파야 한다.”

그렇다면 어떤 우물을 파야 할까? 강의에서는 ‘한 우물’의 조건으로 다음 세 가지를 제시했다.

  • 재미있고 깊이 있는 기술로 백발이 되어도 계속할 수 있어야 한다.
  • 한 번 익히면 다른 환경에서도 쉽게 응용할 수 있어야 한다.
  • 다양한 도메인에서 폭넓게 사용되는 기술이어야 한다.

물론 깊이와 넓이를 함께 가져갈 수 있다면 가장 이상적이지만 한 가지 기술이라도 깊이 있게 파고들어 진짜 전문가가 되는 것이 더 중요하다고 생각한다.

이제 막 DevOps 엔지니어로서 커리어를 시작했기에 다양한 영역을 넓게 경험해보고 있지만 꾸준히 하다보면 언젠가 나도 한 우물을 깊게판 전문가가 되어있을거라 생각한다.

쿠버네티스 표준 생태계

k8s stnd arch

2025 쿠버네티스 표준 아키텍처(출처)

현재 쿠버네티스 생태계는 엄청난 규모로 성장하고 있다. 이제는 IT의 거의 모든 시스템이 쿠버네티스와 컨테이너 위에서 구동된다고 할 수 있다. 이 방대한 생태계는 크게 세 가지로 나뉜다.

  • CNCF 프로젝트
  • CNCF 멤버 기업의 제품
  • CNCF 비멤버의 제품

CNCF 프로젝트의 성숙도

CNCF에서 관리하는 프로젝트들은 성숙도에 따라 아래와 같이 분류된다. 하지만 성숙도가 높다고 해서 반드시 사용해야 한다는 의미는 아니다.

  • Graduated Projects: 안정성과 사용성이 입증된 프로젝트
  • Incubating Projects: 활성 개발 중이며, 점점 자리잡고 있는 프로젝트
  • Sandbox Projects: 실험적인 초기 단계 프로젝트
  • Archived Projects: 더 이상 유지보수되지 않는 프로젝트 (사용 권장하지 않음)

중요한 건 트렌드에 휘둘리지 않고 하나의 기술을 깊게 파고드는 것이다. 누가 새 기술을 쓴다고 해서 덜 익힌 상태로 이리저리 갈아타다 보면, 결국 깊이가 없는 상태가 되기 쉽다.

쿠버네티스가 편한 이유

실제 프로젝트에서 마주치는 구조적 문제

실제 서비스 규모가 커지면 필연적으로 모니터링과 로깅 시스템이 필요해진다. 하지만 다음과 같은 구조적 문제가 발생할 수 있다.

  • 개발과 모니터링 시스템이 서로 얽히는 구조
  • 개발자는 익숙하지 않은 모니터링 도구를 위해 시스템을 구성해야 하는 상황
  • 오픈 시점에 개발 프로젝트와는 전혀 다른 APP들을 따로 모니터링해야 하는 구조

이런 문제는 쿠버네티스 표준 생태계를 활용하면 크게 줄일 수 있다. 처음부터 표준 아키텍처 기반으로 구성하면, 시스템이 자연스럽게 일관성을 유지하게 된다.

왜 표준이 중요한가?

쿠버네티스 생태계의 강점은 모두가 표준을 기반으로 도구를 설계한다는 점이다. 덕분에 모니터링 시스템을 붙일 때도 별다른 설정 없이도 연동이 잘 된다.
예를 들어, Prometheus, Grafana, Loki 같은 대표적인 도구들은 쿠버네티스의 메타데이터, 네이밍 규칙, 라벨 체계를 기반으로 설계되어 있다. 따라서 어떤 기술을 쓰더라도 “아, 이건 쿠버네티스 표준을 따르니까 이렇게 연결하면 되겠구나” 라는 감을 잡을 수 있다.

쿠버네티스를 사용하면 무엇이 편해질까?

vm vs k8s

기존 VM 환경에서는 리소스를 확장하려면 수동으로 인프라 설정을 바꿔야 했다. 하지만 쿠버네티스에서는 단순히 Pod 하나만 추가하면 되기 때문에 훨씬 간편하다.

또한 쿠버네티스는 인프라 구성을 코드로 선언적으로 관리할 수 있다. 덕분에 변경 이력을 추적하기 쉬워지고, 개발/검증/운영 환경을 파일로 나눠 관리하면 환경 간 차이도 쉽게 구분할 수 있다.
기존 파일을 복사해 새로운 환경을 빠르게 만들 수 있어 반복 작업이 줄고, 이전의 경험을 코드로 재활용할 수 있다는 장점도 있다.

쿠버네티스 공부 TIP(feat.일프로)

1. 전체 흐름부터 만들어보기

처음에는 최소한의 도구만 선택해서 단순한 기능이라도 전체 흐름을 끝까지 구성해본다

2. 전문 분야 파고들기

  • 배포 (CI/CD 파이프라인)
  • 클라우드 (VPC, IAM, 오토스케일링 등)
  • 서비스 메시 (트래픽 관리, 보안, 관찰성)

도구보다는 ‘개념’과 ‘문제 해결 방식’ 중심으로 깊게 공부하자.

3. 상황에 따라 유연하게 공부하기

  • 관심 가는 도구가 생겼을 때
  • 실제 프로젝트를 진행하는 상황일 때

실전에서 느낀 문제를 중심으로 학습하면 이해도와 흡수력이 훨씬 좋아진다.

회고

예전에 들은 강연에서 시니어의 조건으로 다음과 같은 기준이 제시된 적이 있다.

  • 경험과 인사이트를 바탕으로 계획 단계에서 잠재적인 위협 요소를 사전에 파악하고 제거할 수 있는가?
  • 복잡한 문제를 해결할 수 있는 역량이 있는가?
  • 장기적인 관점에서 솔루션을 제시할 수 있는가?

이번 학습을 통해 이 조건들을 충족하기 위해서는 단순히 기술을 깊게 파는 것만으로는 부족하다는 걸 느꼈다. 그 이유는 표준화된 환경이야말로 이러한 능력을 실현할 수 있는 기반이 되기 때문이다.

  • 표준화된 구성은 예상치 못한 설정 오류나 환경 차이에 의한 문제를 줄여준다. 덕분에 계획 단계에서 리스크를 구조적으로 줄일 수 있다.
  • 복잡한 문제 해결: 모든 시스템이 일관된 방식으로 동작한다면, 문제 발생 시 원인을 빠르게 추적하고 해결하는 것이 훨씬 수월하다.
  • 장기적 솔루션 설계: 표준은 조직 전체의 기술 방향성과 맞물린다. 단기적 편의보다 장기적인 유지보수성과 확장성을 고려한 구조를 가능하게 한다.

결국 표준화는 단순한 기술적 선택이 아니라, 시니어로서 문제를 미리 막고 복잡함을 단순하게 만들며, 장기적 관점에서 시스템을 설계하기 위한 핵심 도구라는 것을 이번 학습을 통해 다시 한 번 깨달았다.