SRE / DevOps 시작하기 (1) — Vendor Lock-in 없이 인프라 구성하기

내가 처음 서버를 건드려본 것은 중학교 때 윈도우즈 FTP 서버를 만졌을 때였다. 그때부터 보안에 관심이 많았던 나는 자연스럽게 VM과 같은 가상화 기법, Sandbox 기술에 빠져들었고, 그 연장선에서 시스템 아키텍처와 컨테이너 기술을 5년 이상 다뤄왔다.

평소 업무에서는 Apache 기반의 직접적인 서비스 구축과 운영을 선호해왔고, 서버 상태 확인에는 btop 같은 모니터링 도구를 자주 사용해왔다. GitHub Actions, Jenkins 정도의 CI는 어느 정도 다뤄봤고, AWS Amplify 같은 서비스도 써봤지만, 다중 클러스터나 K8S는 언젠가 다뤄야 할 기술 정도로만 인식하고 있었다.

나는 객체지향적 개발을 강하게 추구하는 만큼, 서비스 이식성과 환경분리성 또한 강하게 추구한다. 객체지향적 설계에서 기능과 책임을 분리하는 것처럼, 컨테이너와 VM은 실행 환경 자체를 분리한다. 나에게 이 둘은 같은 철학의 다른 레이어였다.

K3S, K8S, ELK Stack, Loki, Container Registry 같은 대규모 클러스터 운용 스택들이 낯설었던 것은 철학의 문제가 아니라, 현업에서 직접 닥쳐보기 전까지는 제대로 익히기 어려운 성격의 기술이었기 때문이다.

서비스 안정성이 강하게 요구되는 팀에 시니어로 합류하게 된 만큼, 이제는 이 스택들을 운영환경에서 직접 다뤄볼 때가 됐다. AWS EKS로 빠르게 올리는 방법도 있지만, 서비스 이식성과 운용 효율화를 위해 특정 인프라 서비스와의 강결합은 가능한 피하는 편이다.

이번 프로젝트에서 요구된 조건은 다음과 같다.

• 높은 서비스 안정성
• 멀티 클라우드 가능성
• 비용 효율성
• 특정 벤더 종속 최소화

그래서 이번 업무를 위해 선택한 기술 스택은 아래와 같다.

• Cloudflare (DNS / Edge Security / CDN)
• AWS EC2 (Spot 기반 범용 Compute)
• OCI Instance ARM (저비용 ARM Compute)
• OCIR (멀티 클라우드 Container Registry)
• Containerd & Docker (Container Runtime)
• WireGuard (멀티 클라우드 Private Network)
• Jenkins (CI/CD Pipeline)
• Vault (Secret Management)
• Prometheus (Metrics 수집)
• Grafana / Loki (Monitoring & Log Aggregation)
• Terraform (Infrastructure as Code)
• RoyalTSX (SSH Session Management)

AWS EC2 Spot Instance와 OCI ARM Instance의 조합은 단순한 비용 절감이 아니라, 특정 벤더에 종속되지 않으면서도 운영 효율을 끌어올리는 구조적 선택이다. 여기에 한 가지 실무적 이유가 더 있다. 미디어 엔터 분야에서 자주 사용되는 툴들, 가령 SideFX나 Perforce 같은 경우 x86/64에 강하게 결합되어 있어 ARM 단일 구성으로는 확장 리스크가 생긴다.

인프라를 코드로 관리하고, 네트워크를 직접 제어하고, 모니터링과 로깅을 한 곳에서 바라보는 것. 결국 이 스택 전체가 향하는 방향은 하나다. 어떤 클라우드 환경에서도 동일하게 동작하는, 교체 가능한 인프라다.

물론 이 구성이 장점만 있는 것은 아니다. AWS EKS나 GKE 대비 운영 복잡도가 높고, WireGuard 기반 멀티클라우드 네트워크는 직접 관리해야 할 레이어가 늘어난다. Spot Instance는 언제든 중단될 수 있고, 멀티 클라우드 환경에서의 레이턴시와 네트워크 비용도 고려해야 한다. 이 트레이드오프를 감수하는 이유는 하나다. 어떤 벤더가 정책을 바꾸더라도, 인프라가 흔들리지 않아야 한다는 것이다.

다음 글에서는 이 구성을 실제로 올리는 과정에서 맞닥뜨린 문제들을 다뤄볼 예정이다.