기존 네트워크 환경에서 IaC Boundary 설계하기

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 기존 네트워크 환경에서 IaC Boundary를 설계해 봤습니다.

AWS 설계 및 구축 시 고민하는 부분

AWS 환경을 설계하고 구축할 때마다 항상 고민하는 부분이 있습니다.

특히 이미 운영 중인 환경을 확장해야 하는 경우라면 더욱 그렇습니다.

새로운 환경이라면 처음부터 IaC(Infrastructure as Code) 기반으로 구성하면 되지만, 기존 환경이 이미 수동으로 구축되어 있다면 이야기가 조금 달라집니다.

이런 상황에서는 자연스럽게 다음과 같은 고민이 생깁니다.

• 기존 수동 환경에 IaC를 어디까지 적용해야 할까?
• 기존 리소스까지 모두 IaC로 편입하는 것이 맞을까?
• 수동 관리 영역과 IaC 관리 영역의 경계가 모호해지지는 않을까?
• 오히려 운영 복잡도만 증가하는 건 아닐까?

이번 글에서는 기존 네트워크 환경 위에 CloudFormation을 도입하면서 고민했던 IaC Boundary에 대한 내용을 정리해보려고 합니다.

실제 사례

프로젝트를 진행하던 중, 이미 웹 서비스를 운영하고 있는 고객 환경을 확장해야 하는 상황이 있었습니다.

고객사는 이미 VPC를 포함한 네트워크 환경을 수동으로 구축하여 운영 중이었고, 해당 VPC 내부에는 기존 서비스와 연결된 여러 리소스들이 함께 사용되고 있었습니다.

하지만 신규 서비스 구축을 위해 추가적인 네트워크 확장과 새로운 리소스 구성이 필요했습니다.

이 과정에서 가장 고민했던 부분은 다음이었습니다.

• 기존 환경을 모두 IaC로 전환하여 코드 기반으로 재구성할 것인가?
• 아니면 기존 네트워크 구성은 유지한 채, 신규 리소스만 IaC로 관리할 것인가?

처음에는 기존 환경까지 모두 CloudFormation으로 편입하는 것도 고려했습니다.
하지만 운영 중인 네트워크를 직접 수정하거나 Import 하는 과정 자체가 부담이었고, 자칫하면 기존 서비스에 영향이 발생할 가능성도 있었습니다.

특히 네트워크 영역은 여러 서비스와 연결되어 있는 경우가 많기 때문에, 작은 변경 하나가 예상치 못한 장애로 이어질 수 있다는 점도 무시하기 어려웠습니다.

결국 이번 프로젝트에서는 다음과 같은 방향으로 IaC Boundary를 정리했습니다.

• 기존 VPC 및 네트워크 영역은 기존 방식 그대로 유지
• 신규 ALB, EC2, Security Group 등의 리소스는 CloudFormation으로 관리
• CloudFormation은 기존 네트워크를 "참조"만 하고 직접 관리하지 않도록 구성

결과적으로 운영 안정성을 유지하면서도, 신규 인프라에 대해서는 IaC 기반의 관리 체계를 적용할 수 있었습니다.

IaC Boundary를 어떻게 나눴는가

가장 중요했던 부분은 "CloudFormation이 어디까지 관리할 것인가"를 명확하게 정의하는 것이었습니다.

이번 프로젝트에서는 네트워크 영역과 애플리케이션 영역의 책임을 분리하는 방향으로 구성했습니다.

먼저 기존에 생성되어 있던 리소스들을 하나씩 정리하기 시작했습니다.

• 현재 어떤 역할을 수행하고 있는가
• 어떤 리소스와 연결되어 있는가
• 실제 운영 환경에 어떤 영향을 주고 있는가

위와 같은 기준으로 리소스를 파악하면서 전체 구조를 정리했습니다.

이 과정에서 더 이상 사용하지 않는 리소스나, 역할이 불분명한 리소스들도 함께 정리했습니다.

특히 기존 환경은 여러 차례 수동 작업이 반복되면서 불필요하게 남아있는 보안 그룹이나 기본 VPC 등과 같이 일부 불필요한 부분이 존재하고 있었고, IaC를 적용하기 전에 이러한 부분들을 먼저 정리하는 과정이 필요했습니다.

이후 관리 경계를 다음과 같이 나누었습니다.

• 기존 VPC 및 네트워크 리소스는 기존 방식 그대로 유지
• CloudFormation은 기존 네트워크를 참조만 하도록 구성
• 신규 ALB, EC2, Security Group 등의 애플리케이션 리소스는 CloudFormation으로 관리

기존 네트워크 환경은 고객사에서 이미 운영 중인 리소스였기 때문에,CloudFormation이 직접 생성하거나 수정하지 않도록 구성했습니다.

왜 네트워크는 IaC로 관리하지 않았는가

처음 IaC 도입을 검토할 때는 기존 환경을 포함해 네트워크 영역까지 모두 CloudFormation으로 전환하는 방안도 함께 고려했습니다.

하지만 실제 운영 환경과 의존 관계를 분석하면서, 네트워크 영역을 IaC로 전환하는 것은 기대 효과 대비 리스크가 더 크다고 판단했습니다.

네트워크는 단순히 하나의 리소스가 아니라, 이미 여러 서비스가 공유하고 있는 기반 구조이기 때문에 작은 변경도 전체 서비스에 영향을 줄 수 있는 영역이었습니다.

특히 이번 환경에서는 기존 VPC가 이미 수동으로 구성되어 운영 중이었고, 해당 네트워크 위에서 여러 서비스가 안정적으로 동작하고 있는 상태였습니다. 이 상태에서 IaC를 도입하기 위해 네트워크까지 구조를 변경하는 것은 운영 안정성 측면에서 부담이 컸습니다.

이러한 판단의 주요 이유는 다음과 같습니다.

1. 운영 영향 범위가 매우 큰 구조

VPC, Subnet, Route Table, NAT Gateway와 같은 네트워크 리소스는 특정 서비스에 종속된 구조가 아니라, 여러 시스템이 동시에 사용하는 공통 인프라입니다.

따라서 이 영역을 CloudFormation으로 관리하게 될 경우, 작은 설정 변경이나 실수도 다수 서비스에 직접적인 영향을 줄 수 있습니다.

2. 이미 안정화된 운영 환경

해당 네트워크는 이미 실제 서비스 운영을 통해 안정화된 상태였으며, 추가적인 구조 변경이 반드시 필요한 상황은 아니었습니다.

이러한 상태에서 IaC 적용을 위해 네트워크 구조를 재구성하는 것은 기존 안정성을 깨뜨릴 가능성이 더 큰 작업이었습니다.

3. 기존 리소스 Import 및 전환의 복잡성

기존 리소스를 CloudFormation으로 Import하여 관리하는 방식도 존재하지만, 네트워크 리소스는 의존 관계가 복잡하게 얽혀 있는 경우가 많습니다.

예를 들어 서브넷, Route Table Association, NAT Gateway, 보안 그룹 간의 관계를 정확하게 맞춰야 하며, 이 과정에서 실수나 누락이 발생할 경우 장애로 이어질 가능성이 있습니다.

또한 Import 이후에도 실제 운영 중인 환경과 CloudFormation 상태를 지속적으로 일치시키는 작업이 필요합니다.

4. 관리 주체 혼재로 인한 소스 오브 트루스 문제

기존 환경은 이미 콘솔 기반으로 운영되고 있었기 때문에, 여기에 CloudFormation까지 도입하면 다음과 같은 구조가 됩니다.

• 일부 리소스는 콘솔에서 관리
• 일부 리소스는 CloudFormation에서 관리

이 경우 가장 큰 문제는 어떤 방식이 기준인가가 불명확해진다는 점입니다.

즉, 인프라 변경 시마다

• 콘솔을 수정해야 하는지
• CloudFormation을 수정해야 하는지

판단이 어려워지고, 장기적으로 운영 복잡도가 증가하게 됩니다.

이러한 이유로 이번 프로젝트에서는 네트워크 영역은 기존 방식 그대로 콘솔 기반으로 유지하고, CloudFormation은 애플리케이션 및 신규 리소스 영역에만 적용하는 방향으로 결정했습니다.

정리 및 결론

이번 프로젝트에서는 기존에 수동으로 구축된 AWS VPC 환경 위에 CloudFormation을 도입하면서, 전체를 IaC로 전환하는 방식이 아닌 경계 기반 설계를 선택했습니다.

핵심은 모든 인프라를 코드로 관리하는 것이 아니라, 현실적인 운영 환경을 고려해 어디까지를 IaC로 가져갈 것인가를 명확히 정의하는 것이었습니다.

결과적으로 다음과 같이 정리할 수 있었습니다.

• 네트워크 영역(VPC, 서브넷, Route 등): 기존 방식 유지 (콘솔 관리)
• 애플리케이션 영역(ALB, EC2, 보안 그룹 등): CloudFormation 관리
• CloudFormation은 기존 네트워크를 생성하지 않고 참조만 수행

이러한 구조를 통해 기존 운영 환경의 안정성을 유지하면서도, 신규 리소스에 대해서는 IaC 기반의 재현 가능성과 관리 효율성을 확보할 수 있었습니다.

IaC를 도입할 때 중요한 것은 얼마나 많은 리소스를 코드로 관리하는가가 아니라, 어디까지를 코드로 관리할 것인가를 명확하게 정의하는 것이라고 생각합니다.

특히 이미 운영 중인 환경에서는 무조건적인 전환보다, 현실적인 경계 설정이 더 중요한 설계 요소가 됩니다.