선유진(@seonrilla) Bro님의 이번 “Kubestronaut와 함께하는 커뮤니티 데이” 행사에 사전질문으로 주신 내용을 공유합니다.
- 클라우드의 모든 부분을 IaC로 관리하는게 좋은지, 또는 IaC로 못하는 부분이 있는지 궁금합니다.
전문가 Bro님들의 조언 부탁드립니다.
2 Likes
가능하면 IaC를 기반으로 관리하는 것이 저는 올바른 방향이라고 생각합니다. 의도한 클러스터 상태를 선언적으로 정의하고 관리할 수 있기 때문에 협업과 운영 측면에서 큰 도움이 됩니다.
다만 CSP를 이용하는 형태가 아닌 On-Premise 클러스터의 경우, Baremetal 서버를 IaC로 Provisioning 하는 것은 쉽지 않을 것으로 보입니다. OS 초기화 및 K8s 설치의 경우 IaC로는 어려울 것으로 보이며, 만약 이미 클러스터가 있다면 해당 클러스터를 Managed Cluster로 두고 Cluster API를 기반으로 Provisioning 하는 방법을 생각해볼 수는 있을 것 같습니다.
4 Likes
안녕하세요. IaC 관련 업무를 담당하고 있는 유형욱입니다.
실제로 많은 고객분들이 “클라우드 환경의 모든 것을 IaC로 관리해야 하나요?”라는 질문을 자주 주십니다.
저 역시 여러 프로젝트를 함께하면서 느꼈던 경험을 바탕으로, 몇 가지 관점을 공유드리고자 합니다.
(이 글은 ChatGPT의 도움을 받아 정리했습니다 
)
⸻
IaC는 클라우드 운영 자동화의 핵심 기반이지만, ‘모든 것’을 코드화할 필요는 없습니다.
IaC는 인프라 구성을 일관되고 재현 가능한 방식으로 관리하기 위한 모범 사례(Best Practice)입니다.
다만, 모든 리소스를 코드로 정의하는 것이 항상 효율적인 것은 아닙니다.
예측 가능한 반복 작업이나 자동화가 가능한 변경이라면 IaC를 사용하는 것이 가장 안전하고 효과적입니다.
반대로, 운영 중 수시로 수동 조정이 필요한 리소스(예: 디버깅용 설정, 일회성 실험 환경)까지 IaC로 강제하면 오히려 복잡도와 관리 비용이 늘어날 수 있습니다. → Day 2 영역은 구성관리 자동화(Ansible 등) 전문 IaC를 함께 사용하는 것도 고려해볼 수 있을 것 같네요.
즉, 패턴이 명확하고 재현 가능한 작업은 IaC로 관리하고, 즉각 대응이 필요한 운영성 리소스는 운영 스크립트나 별도 프로세스와 병행하는 것이 현실적인 접근이라고 생각합니다.
⸻
Provider 지원 범위에 따라 일부 리소스는 IaC로 관리가 제한될 수 있습니다.
Terraform을 예로 들면, 대부분의 글로벌 클라우드 서비스 제공자(CSP)는 공식 Provider를 통해 Compute, Network, Storage 등 핵심 리소스를 폭넓게 관리할 수 있습니다.
하지만 일부 관리형 서비스(AI/ML, Big Data, PaaS 등)는 아직 Provider가 완전하게 지원되지 않거나, CSP 측 API 제약으로 인해 수동 설정이 필요한 경우도 있습니다.
특히 일부 국내 CSP(Naver Cloud, NHN Cloud, KT Cloud 등)는 Provider 지원 범위가 제한적이기 때문에, 핵심 인프라 자원은 IaC로 관리하되 일부 고급 서비스는 콘솔 기반 운영(a.k.a. ClickOps)을 병행하는 하이브리드 접근이 현실적입니다.
(물론 이 영역마저도 자동화하려면, 결국엔 방법은 있겠죠 
)
⸻
Kubernetes 환경에서는 IaC와 GitOps를 함께 사용하는 것이 효과적입니다.
@ahinsutime 님이 언급하신 것처럼, 온프레미스 Kubernetes 환경에서도 Cluster API를 활용하면
클러스터 생성을 선언적(Declarative) 방식으로 자동화할 수 있습니다.
Cluster API는 Terraform과 같은 IaC 도구는 아니지만, Kubernetes 네이티브 컨트롤러로 클러스터의 라이프사이클을 선언적으로 관리합니다.
반면, AWS EKS나 Azure AKS 같은 관리형 Kubernetes 서비스는 Terraform Provider를 통해 클러스터와 주요 인프라를 손쉽게 배포할 수 있습니다.
이후 Helm Provider나 Kubernetes Provider를 함께 사용하면 LoadBalancer Controller, CSI Driver, ExternalDNS 등의 애드온 구성도 IaC로 확장 가능합니다.
또 다른 접근으로는 인프라 프로비저닝까지만 IaC로 수행하고, 이후에는 Argo CD의 App of Apps 패턴 등 GitOps 기반 배포 자동화를 결합하는 방식도 많이 사용됩니다.
⸻
Terraform은 인프라를 넘어 ‘플랫폼 전체 자동화’도구로 활용할 수 있습니다.
물론 Terraform의 경우 단순히 클라우드 인프라를 관리하는 도구에 그치지 않습니다.
Datadog, GitHub, Splunk, Vault 등 다양한 SaaS 및 운영 도구를 위한 Provider 생태계를 폭넓게 지원하며, 이를 통해 조직 전체의 표준화된 플랫폼과 셀프서비스형 인프라(Platform Engineering) 환경을 구현할 수 있습니다.
결국 IaC는 단순한 프로비저닝 도구가 아니라, 운영 자동화와 거버넌스의 근간이 되는 기술이라 할 수 있습니다.
⸻
결론
IaC의 목적은 “모든 것을 코드로 만드는 것”이 아니라, “중요한 것을 일관되고 안전하게 관리하는 것”에 있습니다.
조직의 규모, 서비스 특성, 운영 성숙도에 따라 IaC의 적용 범위를 전략적으로 정의하는 것이 가장 현실적이고 효율적인 접근이라고 생각합니다.
6 Likes