Terraform & Kubernetes 도입 후기
최근 인프라 구성과 서비스 운영 전반에서 (늦었지만…)
Terraform과 Kubernetes를 본격적으로 사용해 보았고,
생각보다 경험이 꽤 좋아서 기록 겸 공유해 둔다.
TL;DR
이걸 왜 이제 썼지. 진작 써볼 걸. (feat. 관리할 서버가 많아질수록 체감이 큼)
기존에 사용하던 방식
- 웹 브라우저 → AWS 콘솔에서 마우스 클릭으로 인프라 구성 (EC2 생성, 네트워크 설정 등)
- 로컬 서버에 Docker / Docker Compose 기반 운영
이번에 사용한 방식
Terraform (IaC)
- VPC, Subnet, NAT, Kubernetes Cluster 까지 인프라를 코드로 선언
- 변경 이력이 Git에 남아 변경 추적과 리뷰가 가능
- 코드로 명확히 남기니 재사용성과 일관성이 크게 좋아짐
- 콘솔 수작업이 줄어들어 휴먼 에러 감소
- '이 인프라가 왜 이렇게 생겼는지'가 코드로 설명됨
내 경우는 NCP(Naver Cloud Platform) 를 사용했는데, 지원하는 리소스 범위가 제한적이라 일부는 여전히 웹 콘솔에서 수작업이 필요했다.
그럼에도 불구하고, Terraform을 도입한 만족도는 꽤 높았다.
Kubernetes
- 배포, 롤링 업데이트(무중단), 오토스케일링이 정책 기반으로 자동 동작
- 모든 설정을
yaml파일로 관리할 수 있는 점이 매우 편리
- 서비스 디스커버리, 헬스 체크, 셀프 힐링 덕분에 운영 부담이 체감될 정도로 감소
- Pod / Node / Resource 단위로 문제를 분리해서 볼 수 있어 장애 원인 추적이 수월
- 서비스 규모가 커질수록 정리된 상태를 유지하기 쉬운 구조
- GitLab CI + Container Registry + ArgoCD 조합의 배포 자동화 경험이 매우 만족스러웠음
그리고, AI의 도움
이번에 느낀 또 하나의 큰 포인트는 AI의 존재감이었다.
- Terraform module 구조 설계, variable 정리
- Kubernetes manifest 작성 및 리팩토링
(Deployment, HPA, Ingress 등)
- 에러 메시지 / 이벤트 로그 해석
- 필요한 CLI 명령어를 바로 바로 알려줌
- “이 구성, 더 나은 패턴이 있는가?” 같은 설계 피드백
- 문서를 처음부터 끝까지 파는 방식보다, AI와 대화하면서 검증하고 다듬는 흐름이 훨씬 효율적이었다.
결과적으로,
- 러닝 커브는 여전히 존재하지만 AI를 보조 도구로 사용하면서 학습 속도와 시행착오 비용이 크게 줄어든 느낌
요약하자면,
- 수많은(?) 장애와 벽에 부딪히는 순간에도 언제든 도움을 받을 수 있다는 점에서 덜 두려웠다.
부록) K8S, 다음에도 바로 쓸 것인가?
- 서비스 초기부터 바로 도입할 것 같지는 않다
(K8S Cluster만 해도 NCP 기준 월 약 7만 원)
- 초기에는 인스턴스 1~2대 + 오토스케일링 정도로 충분할 듯
(아예 오토스케일링이 필요 없는 경우도 많다)
- 사용하는 인스턴스 수가 늘고, 서비스 규모가 커지면 그때 도입을 고민
- 사용 경험은 긍정적이지만 작은 서비스에는 확실히 오버스펙
- 서버에 바로 SSH 접근해서 띄우고 로그보고 재기동 시키고 하는 게 더 편안한 1인이라, 그런 거 못할 때 가끔 불편하게 느껴지기는 했음 (물론 셸 접근은 가능하나, 그러기에는 Pod이 너무 많..)
정리하면
- Terraform: 서비스 초기부터 도입하고 싶다
- Kubernetes: 상황에 따라 선택, 작은 서비스라면 초반 도입은 X
Read more →