90DaysOfDevOps (Day 13)

고태규·2025년 9월 21일

DevOps

목록 보기

12/21

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 13 - Architecting for Versatility

단일 클라우드의 장점
- 클라우드 제공업체의 Managed Service를 활용하여 개발 속도를 높일 수 있음
- 자동화, Observability, 지원, 계약 및 재무 관계를 단일 창구로 관리하여 복잡성이 줄어들게 됢.
- 하나의 플랫폼에 집중하여 더 깊은 전문 지식을 쌓을 수 있음
단일 클라우드의 단점
- 특정 제공업체에 묶여 (벤더 종속, Vendor Lock-in) 경쟁력 있는 신기술 도입이나 가격 협상에 불리해질 수 있음
- 특정 리전에서 원하는 컴퓨팅 자원이나 스토리지 확보에 어려움을 겪을 수 있음
- 가격 변동이나 새로운 할인 혜택에 기민하게 대응하기 어려움
멀티 클라우드의 함정
- 각 환경에 맞는 자동화와 관측 가능성 시스템을 따로 구축하고 유지보수해야함
- 여러 환경에 데이터를 복제하면서 Storage와 데이터 전송 (Egress) 비용이 낭비됨
- 처음부터 멀리 클라우드 아키텍쳐를 고려하지 않았다면, 기존 아키텍처와 코드를 다른 환경에서 작동하도록 수정하는 것은 많은 어려움을 가짐

이렇게 단일 클라우드의 장점도 존재하지만 단점도 존재하여 많은 업체들이 하이브리드나 멀티클라우드 환경으로 전환하려고 하지만 많은 함정들이 존재한다.

따라서, 더 쉬운 전환을 위해 아키텍처를 어떻게 다재다능 (Versatility)하게 유지할 수 있는지가 주요 쟁점이 되었다.

특정 클라우드에 종속되지 않고 미래에 쉽게 전환할 수 있는 '다재다능한(Versatile) 아키텍처'를 구축하는 방법이다.

1. 서비스 유연성 확보

특정 클라우드 제공업체의 고유 서비스 대신, 여러 클라우드에서 공통으로 제공하는 '오픈소스 기반 Managed Service'를 활용하는 것이 좋음.
AKS, EKS, GKE는 모두 Kubernetes라는 표준 API를 사용하므로 상호 전환이 용이
Redis, ElasticSearch, PostgreSQL

2. 코드 유연성 확보

3. 데이터 전송 비용 최적화

4. 통합된 관측 가능성 (Observability) 구축

CloudWatch (AWS) 나 Google Cloud's Operation suite 처럼 특정 벤더에 종속된 도구 보다, 여러 환경의 로그와 메트릭을 하나로 통합하여 모니터링 할 수 있는 도구를 사용하는 것이 유리함.
SaaS 플랫폼 -> Datadog (인프라 모니터링, Application Performance Monitoring), 로그 관리를 하나의 통합된 화면에서 제공
오픈 소스 기반 스택 -> Grafana, Prometheus, Lock, ElasticSearch 등

5. 통합된 보안 접근 방식

벤더별 보안 서비스를 사용하기 보다는, 모든 환경에 일관되게 적용할 수 있는 통합된 보안 정책과 솔루션을 마련해야함.
Palo Alto Networks : 클라우드 보안 형상 관리 (CSPM), 워크로드 보호 (CWPP), 인프라 코드 (IaC) 스캔, 서버리스 보안 등 클라우드 보안에 필요한 기능을 하나의 플랫폼에서 제공
Wiz : 서버나 워크로드에 직접 에이전트를 설치할 필요 없이 클라우드 API를 통해 환경 전체를 스캔
CrowdStrike (Falcon Cloud Security) : 실행 중인 컨테이너나 가상머신(VM) 내부에서 발생하는 악의적인 행위를 실시간으로 탐지하고 차단하는 데 매우 강력
HashiCorp Vault : 여러 클라우드와 시스템에 흩어져 있는 API 키, 비밀번호, 인증서와 같은 민감 정보(Secrets)를 중앙에서 안전하게 관리하고 접근을 제어

앞서말한 '다재다능한 아키텍처'를 구현하기 위하여 구축을 고려해야하는 시점은 '화이트보드 단계'이다.

이 모든 것을 초기 MVP 단계에서 구현하라는 의미는 아니며, 중요한 점은 초기 아키텍처를 설계하는 단계에서 '다재다능한 아키텍처로의 전환'의 가능성을 염두에 두는 것이다.

또한, 초기에 하나의 기술이나 방향으로 완전히 고정되어 나중에 되돌릴 수 없는 '편도문 결정 (One-way door Decision)'을 내리지 않는 것이 좋다.

이러한 원칙들은 물론 개발 및 배포 파이프라인, 백업 및 복구 전략을 수립할 때도 동일하게 적용되므로, 벤더에 중립적인 방식을 고려해야 한다.

DevOps에서 '민첩성 (Agility)'는 단순히 빠른 개발 속도가 아니라, 변화에 대응하고 방향을 전환하며 관성을 극복하는 능력이다.

이러한 민첩성은 약간의 선견지명과 계획을 통해 얻을 수 있는데, 처음부터 모든 문제를 해결하려고 과잉최적화할 필요는 없지만, 미래의 선택지를 스스로 제한하지 않음으로써 실패를 예방할 수 있다.