클라우드‐WHY‐설계 - 100-hours-a-week/16-Hot6-wiki GitHub Wiki

목차

설계

왜 클라우드 환경을 사용하나요?

서비스 초기에는 비용을 줄이기 위해 물리 서버(on-premise)를 직접 구성하거나, 남는 서버 자원을 임시로 빌려 쓰는 방식도 고려할 수 있습니다. 실제로 우리가 직접 배포했던 프로젝트 초기에 수작업으로 빌드 및 배포를 수행하며 정말 클라우드가 꼭 필요할까?에 대한 고민을 했습니다. 그리고 다음과 같은 이유를 정리했습니다.

예측 불가능성 대응

  • 서비스에 트래픽이 몰리거나 AI 모델 추론이 몰릴 경우, 온프레미스 환경은 유연하게 대응하기 어렵습니다.
  • 기능 추가/삭제가 빈번한 개발 초기 단계에서, 클라우드는 인프라 구조를 빠르게 수정·확장할 수 있습니다.

우리의 서버가 아니다

  • 지인 서버나 임대 VPS는 보안, 리소스 할당, 네트워크 설정 등에서 우리가 직접 통제할 수 없습니다.
  • 특히 GPU가 필요한 AI 작업은 클라우드에서 필요한 시점에만 인스턴스를 생성해 사용하는 것이 효율적입니다.

금전적 효율성

  • AWS의 부트캠프 크레딧(100만원), GCP 무료 크레딧(약 43만원)을 병행 사용해 초기 비용 부담을 크게 낮췄습니다.
  • 클라우드 도입이 오히려 물리 서버보다 저렴하고 실험 친화적인 선택이 될 수 있었습니다.

결론

클라우드는 서비스 초기의 불확실성과 실험적 시도에 가장 적합한 인프라입니다. 유연성과 자기 결정권을 확보하면서도, 실질적 비용까지 절감할 수 있습니다.

🔝 Top

왜 AWS + GCP 멀티클라우드를 도입했나요?

GCP의 무료 크레딧과 AWS 지원

AWS는 카카오테크 부트캠프 기간동안 총 100만원의 금액이 지원됩니다. 다만 저희의 최종 목표인 쿠버네티스 도입 + AI 자체 모델 개발을 고려하면 AWS만 사용했을 때 금액이 부족해질 수 있는 문제가 생깁니다. 따라서 GCP의 가입 시 무료 크레딧 300달러(현재 약 43만원)를 추가로 이용하여 금액 문제를 해결하고자 합니다. Azure의 경우 역시 200달러 무료 크레딧을 제공하나, 기간이 1달이므로 GCP가 이 부분에서 낫다고 평가했습니다.

AWS에서 사용하는 스택

기본적으로 AWS는 하나의 계정을 고정적으로 사용하므로, 이동에 불리한 기술들을 주로 사용할 계획입니다.

  • Route 53
    Route 53에서 도메인을 발급받으면 ACM 발급도 편리할 뿐만 아니라 운영 기간 동안 도메인 호스팅을 이동할 필요가 없습니다.
    만약 GCP에서 도메인을 발급받으면 3개월 이후에는 비용이 발생할 뿐만 아니라 매번 호스팅 이전이 필요하게 됩니다.
  • S3
    GCP의 Cloud Storeage를 이용하는 경우 초기 GCP에서의 업로드에서 이점(GCP 내부망을 통해 업로드)을 얻을 수 있지만, 역시 마이그레이션 비용이 발생하게 됩니다. 이 비용은 서비스가 커짐에 따라 비례하여 증가합니다.
    반대로 이후 EKS를 이용하게 되었을 때에는 같은 논리로 AWS에서의 업로드 이점을 얻게 됩니다.
    AI 서버 개발의 경우 CloudFront를 이용하면 S3 조회 비용이 매번 발생하지 않고, boto3라이브러리를 이용하면 AWS로의 이전이 있더라도 같은 로직으로 개발이 가능합니다.

GCP에서 사용하는 스택

GCP에서는 주로 테라폼 기반으로 계정 및 프로젝트 설정만 바꾸어도 바로 구축이 가능한 시스템들을 사용합니다.

  • Compute Engine
    Cloud Repository에 Terraform을 활용하여 인스턴스를 정의할 계획입니다. 계정이 바뀌더라도 프로젝트 설정 및 서비스 계정 설정만으로 손쉽게 클라우드 이전이 가능합니다.

결론

결론적으로 AWS는 **고정적인 자원과 이동이 어려운 서비스(Route 53, S3 등)**를 중심으로 활용하고, GCP는 무료 크레딧을 활용한 유동적인 컴퓨팅 자원(Compute Engine) 중심으로 사용함으로써 비용 효율성과 유연성을 모두 확보할 수 있습니다.

🔝 Top

왜 테라폼을 도입했나요?

처음부터 인프라를 Terraform으로 관리하지는 않았습니다.
Terraform은 강력하지만, 도입 타이밍이 중요했고, 저희에겐 'Docker 도입'이 그 시점이었습니다.

Docker 도입 이전에는 CD가 있어도 여전히 인스턴스 단위 배포였습니다.
즉, 하나의 EC2에 두 버전의 서비스를 띄우는 Blue-Green 배포를 시도하려면, 서로 다른 런타임, 포트, 의존성 충돌 이슈를 일일이 피해야 했습니다.
결국 새 인스턴스를 띄우고 교체하는 방식이 현실적이었고, 이 과정은 Terraform이 아닌 수동 작업 + 배포 스크립트로 진행될 수밖에 없었습니다. (CloudFront 캐시 무효화부터 nginx 설정 변경, health check 전환까지는 TF 단독으론 제약이 큽니다)

그러나 Docker를 도입하며 상황이 달라졌습니다.
서비스는 컨테이너로 캡슐화되었고, 의존성 충돌 없이 같은 서버에 여러 버전을 동시에 띄울 수 있게 되었습니다.
포트 단위로 나뉜 Blue-Green 구조는, 더 이상 새 인스턴스를 만들지 않아도 되었고,
이제는 인프라 자체를 선언형으로 관리할 수 있는 조건이 마련된 것이었습니다.

여기서 Terraform의 도입 가능성이 아니라, 도입 ‘필요성’이 생겼습니다.

  • 수동으로 EC2를 띄우거나, 방화벽을 설정하거나, LB와 Route53을 연결하는 작업이 반복되고 있었고,
  • 점점 그 구조는 복잡해지고, 수정 이력은 Git이 아닌 사람의 기억에만 남아 있었습니다.
  • 컨테이너는 유니버설하게 배포되지만, 그 컨테이너를 담는 환경은 점점 불안정해지고 있었습니다.

Terraform을 도입함으로써 얻고자 했던 것은 '자동화' 그 자체가 아닙니다.
운영 이력의 명문화, 롤백 가능한 인프라 구성, 서비스 스케일 전략을 미리 코드로 정의하는 것,
그리고 무엇보다도, 사람 손으로 하던 실수를 줄이는 것이었습니다.

저희는 여전히 일부 시나리오는 수동으로 구성하고 있습니다. 그리고 모든 것을 선언형으로 관리할 수는 없다는 것도 알고 있습니다. 그러나 분명한 건, Docker 이후의 인프라는 Terraform이 아니면 관리할 수 없다는 점이었습니다.
그건 기술 선택이 아니라, 운영 패턴의 진화에 따른 자연스러운 결과였습니다.

🔝 Top

빅뱅 배포

왜 빅뱅 배포 과정이 필요한가요?

왜 Nginx를 사용하나요?

빅뱅 배포 단계에서 하나의 주소로 SSL 인증서를 사용할 목적으로 리버스 프록시를 구축하기 위해 도입했습니다.

[사이 질문] 왜 SSL 인증서를 통해 HTTPS를 제공해야 하나요?

기본적인 신뢰를 사용자에게 제공하는 것을 넘어 HTTPS를 사용하지 않고 로그인/회원가입 서비스를 이용할 경우 브라우저가 경고문을 만들기 때문에 UX를 크게 해칩니다. 따라서 반드시 도입해야 합니다.

  • 현재 아키텍처에서 HTTPS를 발급받기 위한 방법 후보:
    • AWS ACM + ALB
    • ACM + CloudFront
    • Nginx

Nginx의 장점

  1. AWS 관리형 서비스에 비해 Nginx라는 스택을 사용하는 비용이 전혀 들지 않는다.
  2. 매우 적은 CPU/메모리 사용으로도 최대 수십만 요청을 처리할 수 있으므로 인스턴스에 대한 비용도 거의 발생하지 않는다. 서비스가 성장하더라도 Nginx가 첫 번째 병목이 될 가능성이 굉장히 낮다.
  3. Certbot을 이용하면 자동 갱신이 가능하다.

결론

Nginx는 가격이 거의 들지 않으며, 갱신 자동화도 가능하므로 서비스 초기부터 관리형 서비스를 이용할 필요는 없습니다. 즉, 가장 값싼 가격으로 SSL 인증서 도입이 가능하고, 구축 이후 관리 소요도 적습니다. 이 과정을 통해 실제 보안 및 UX 확보가 가능합니다.

🔝 Top

왜 MySQL을 사용하나요?

왜 VPC를 사용하나요?

VPC(Virtual Private Cloud)는 클라우드 상에 논리적으로 격리된 네트워크 공간을 구성하는 기능입니다.
우리 팀은 GCP와 AWS에서 모두 VPC를 구성하여 사용하고 있으며, 주요 이유는 다음과 같습니다.

1. 보안이 기본입니다 (공개 vs 비공개 서브넷 분리)

  • 외부 접근이 필요한 리소스(FE, Nginx 등)는 공개 서브넷
  • 외부 접근이 불필요한 리소스(DB, AI, 백엔드 등)는 비공개 서브넷

VPC를 사용하면 이런 네트워크 레벨의 접근 제어를 명확하게 구분할 수 있습니다.

2. 서비스 간 네트워크 통신 구조화

  • 서비스 간 통신은 VPC 내부에서 Private IP로 수행
  • GCP에서는 내부 IP로만 통신 가능한 DB 설정
  • VPN 연결, NAT 구성 등도 모두 VPC를 기반으로 작동

클라우드 인프라 간 통신을 체계화하고, 트래픽 흐름을 설계할 수 있는 기반이 됩니다.

3. 향후 확장을 고려한 설계의 출발점

  • 동일 VPC 내에서 AZ별 인스턴스 배치 가능
  • CIDR 블록 설계를 통해 향후 멀티 서비스 또는 멀티 계정 구조로도 확장 가능

즉, VPC는 단순한 네트워크가 아닌 인프라 설계의 뼈대가 됩니다.

결론

클라우드에서 VPC는 "선택"이 아니라 "기본 전제"입니다.
보안, 통신, 확장성 모두를 고려할 때, VPC는 가장 먼저 설계되어야 하는 요소입니다.

🔝 Top

왜 GCP 에서는 VPC를 여러 개 생성하지 않나요?

AWS에서 VPC는 리전(Region) 단위로 생성되며,
GCP에서는 글로벌(Global) 단위의 VPC를 제공합니다.
이 차이점이 곧 VPC 설계 방식의 근본적인 전략 차이로 이어집니다.

AWS: 리전 단위 VPC

  • VPC를 만들면 특정 리전에 속하게 되며, 그 안에서 각 가용 영역(AZ)에 서브넷을 따로 구성해야 합니다.
  • 즉, 리전을 다르게 쓰고 싶다면 새로운 VPC를 만들어야 함
예시: us-east-1 → VPC A  
     ap-northeast-2 → VPC B

GCP: 글로벌 VPC

  • GCP에서는 하나의 VPC 안에서 리전/존에 따라 서브넷을 나누는 방식입니다.
  • 즉, VPC를 한 번만 생성하고, 그 아래에서 서울 리전, 도쿄 리전 등을 서브넷 단위로 나누어 사용할 수 있습니다.
예시: vpc-main  
     ├── subnet-seoul (asia-northeast3)  
     └── subnet-tokyo (asia-northeast1)

그래서 GCP에서는 VPC를 여러 개 만들지 않음

  • 네트워크 경계가 필요한 경우가 아니라면,
    하나의 VPC 내에서 리전 간 통신, 보안 정책, 방화벽 등을 모두 설정할 수 있기 때문에
    VPC를 한 개로 유지하고, 서브넷 레벨에서 리전(AZ)을 분리하는 게 효율적입니다.

  • 또한, VPC 피어링(VPC Peering) 없이도
    같은 VPC 안에서는 서브넷 간 통신이 바로 가능하기 때문에
    관리와 비용 면에서도 유리합니다.

저희의 전략은?

  • 하나의 글로벌 VPC를 생성하고,
    asia-northeast3 리전(서울)을 기준으로 AZ에 따라 서브넷을 분리해 구성했습니다.
  • 예:
    • subnet-a → asia-northeast3-a
    • subnet-b → asia-northeast3-b

이는 AWS에서 VPC 1개, AZ별 서브넷을 나누는 방식과 유사하지만,
GCP에서는 VPC가 글로벌이기 때문에 추가 VPC 생성 없이 같은 맥락을 유지할 수 있습니다.

예외

  • 네트워크 정책이 완전히 달라야 하는 경우 (예: 사내망 / 외부망 분리)
  • VPC 서비스 컨트롤과 조직 정책을 구분해야 하는 경우

이런 경우가 아니라면 단일 VPC + 다중 서브넷 구조가 가장 효율적입니다.

결론

GCP에서는 VPC를 글로벌 단위로 하나만 생성하고,
서브넷 레벨에서 리전과 AZ를 분리하여 사용하는 것이 기본 전략입니다.

  • 비용 및 관리 측면에서 단순화
  • 피어링 없이 리전 간 통신 가능
  • AWS와의 차이점을 이해하고 설계 시 반영

🔝 Top

왜 도메인 기반 라우팅을 사용하나요?

서비스를 구성하는 컴포넌트가 여러 개일수록, 도메인 기반 라우팅은 가장 직관적이면서도 유연한 설계 전략이 됩니다.
특히 onthe-top.com 서비스에서는 CloudFront, HTTPS Load Balancer 등 다양한 네트워크 구성 요소를 거치며 아키텍처가 자주 변하기 때문에, 도메인을 기반으로 라우팅 경로를 설계하는 방식이 가장 효과적이었습니다.

우리가 사용한 도메인 전략

https://onthe-top.com              → 메인 서비스 (CloudFront + S3)
https://www.onthe-top.com          → 동일 메인 서비스 (www 리디렉션 포함)
https://backend.onthe-top.com      → 운영용 백엔드 서버 (HTTPS LB → GCE)
https://ai.onthe-top.com           → 운영용 AI 서버 (HTTPS LB → GCE)

https://dev.onthe-top.com          → 개발용 프론트엔드 (CloudFront + S3)
https://dev-backend.onthe-top.com  → 개발용 백엔드 (HTTPS LB → GCE)
https://dev-ai.onthe-top.com       → 개발용 AI 서버 (HTTPS LB → GCE)

각 도메인은 **컴포넌트의 목적과 환경(prod/dev)**에 따라 명확히 분리되며,
이는 곧 운영 환경과 개발 환경을 동시에 안정적으로 관리할 수 있게 해줍니다.

왜 Path 기반(/api, /admin 등)이 아닌 도메인 기반인가?

구분 Path 기반 도메인 기반
설정 한 도메인에 여러 Path로 구성 각 컴포넌트를 도메인으로 분리
예시 onthe-top.com/api, onthe-top.com/admin backend.onthe-top.com, ai.onthe-top.com
장점 설정이 간단하고 URL이 짧음 인프라 구성 유연성↑, HTTPS 인증 관리 용이, 서비스별 분리배포 가능
단점 인프라 분리 어려움 도메인 관리 필요, SSL 인증서 분산 가능성

우리는 Path 기반이 아닌 도메인 기반을 선택하여,
서비스 구조가 바뀌더라도 DNS/Route 53만 수정하면 전체 구조에 영향 없이 유지보수 가능하도록 설계했습니다.

CloudFront 및 HTTPS LB에서의 도메인 매핑

  • CloudFront는 도메인 단위로 캐시/오리진/인증서 설정이 분리됩니다.
  • HTTPS LB(GCP)는 도메인 → 백엔드 서비스 매핑이 핵심이며,
    여러 호스트네임을 한 Load Balancer 내에서 라우팅 가능하도록 지원합니다.

이러한 기능을 활용하기 위해 도메인을 서비스 단위로 나눈 것이며,
아래와 같은 구조로 아키텍처 변경에도 쉽게 대응할 수 있습니다:

https://backend.onthe-top.com   → LB → backend-v1-group  
                             → backend-v2-group (blue/green 전환)

https://ai.onthe-top.com       → LB → ai-group

아키텍처 변경 시 내성 확보

도메인 기반 구조를 사용하면 다음과 같은 아키텍처 변화에도 유연하게 대응할 수 있습니다:

  • 기존 VM → Kubernetes 전환
  • HTTPS LB → Nginx + Certbot 전환
  • 인스턴스 수직 확장 → 수평 확장 전환
  • Blue-Green 배포 시 도메인 그대로 유지하면서 Target만 변경

도메인을 고정함으로써 외부 사용자는 변화를 느끼지 못한 채 내부 구조만 유연하게 변경할 수 있습니다.

결론

도메인 기반 라우팅은 단순히 URL을 보기 좋게 만드는 것이 아니라,
변화에 강한 아키텍처, 컴포넌트별 배포 독립성, 운영/개발 환경 분리를 동시에 달성하는 전략입니다.

  • 서비스 명확도 향상 (역할 기반 도메인 분리)
  • CloudFront, HTTPS LB 등 클라우드 네이티브 인프라 활용 극대화
  • Blue-Green 전환, 스케일링, 인증서 갱신 등에서 유연성 확보

🔝 Top

왜 VPN을 사용하나요?

VPN은 단순히 “보안을 강화하기 위한 도구” 그 이상이었습니다.
저희는 실제로 운영 중인 서비스에 대해 자동화된 의심스러운 요청을 수차례 경험했고,
그 경험은 저희로 하여금 Dev 환경조차 퍼블릭하게 열어두는 것은 실질적인 위협이라는 결론에 도달하게 했습니다.

실 로그 예시 (FastAPI)

운영 중인 서비스에서 실제로 수집된 FastAPI 서버의 로그입니다.
기억하건대 .env, actuator/env, config.js 등을 탐색하는 자동화된 요청이 반복되었습니다.

INFO:     172.17.0.1:60726 - "GET /env HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:60736 - "GET /actuator/env HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:39632 - "GET /actuator%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:39638 - "GET /message-api/actuator/env HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:39642 - "GET /api%3B/actuator%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:39646 - "GET /api%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:39656 - "GET /api%3B/internal%3B/actuator%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:46630 - "GET /manage%3B/actuator%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:36626 - "GET /babpat%3B/actuator%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:36640 - "GET /babpat%3B/env%3B HTTP/1.0" 404 Not Found
INFO:     172.17.0.1:37678 - "GET /api/actuator/env HTTP/1.0" 404 Not Found

👆 위 로그 중 babpat은 저희가 이전에 운영했던 서비스 이름입니다.
서비스명을 유추해서 접근을 시도한 정황이 있다는 건,
단순 크롤러 수준을 넘어선 의도적 추적 시도로도 해석될 수 있습니다.

Dev 환경을 숨긴 이유

이러한 경험 이후, 저희는 Dev 환경을 완전히 프라이빗화하고, VPN 기반으로만 접근 가능하게 설계했습니다.

  • Dev 서버는 공인 IP 없이 10.10.10.2 등 내부 IP로만 존재
  • HTTPS LoadBalancer, 도메인 연결 모두 생략
  • VPN에 연결된 운영자만 접근 가능
  • Dev 백엔드/AI 서버의 접근 로그는 완전 차단된 상태에서만 기록됨

운영자는 불편을 감수했지만, 그 대가로 Dev 환경은 더 이상 공격 표면이 되지 않습니다.

그렇다면 Prod는 어떻게 방어할 수 있을까?

Prod 환경은 사용자와 외부 서비스가 접근해야 하므로, VPN으로만 숨기는 건 현실적으로 어렵습니다.

그러나 다음과 같은 대안을 통해 방어할 수 있습니다:

  • Strict URI Filtering: /.env, /actuator/*, /config.js 등에 대한 접근을 Nginx/Backend에서 명시적으로 차단
  • Cloud Armor, WAF 적용: 의심스러운 User-Agent, URI 패턴 탐지 → 자동 차단
  • 로그 감시 및 알림 연동: /env, /actuator 요청을 감지하면 Slack/Discord로 즉시 알림 전송
  • Robots.txt 방어: 존재하지 않거나 일부 경로에 대해 Disallow: /로 대응

결론

보안은 결국 “뭘 막느냐”가 아니라 “어디까지 숨기느냐”의 문제입니다.
Dev 환경은 완전히 숨길 수 있으므로 그렇게 했고, Prod 환경은 공개가 불가피하므로 방어선을 구축하고자 합니다.

VPN은 단순히 “내부 서비스 접근용”이 아니라, 서비스의 민감도가 낮은 영역을 구조적으로 격리하기 위한 설계의 일부였습니다.

🔝 Top

왜 WireGuard VPN을 사용했나요?

VPN은 단순히 내부 리소스를 보호하기 위한 수단이 아닙니다.
저희에게 VPN은 Dev 환경을 은닉하고,
운영자만이 명시적으로 접근할 수 있도록 통제하는 인프라의 일부입니다.

여러 VPN 솔루션 중에서 왜 WireGuard였는가?

처음엔 Tailscale이나 ZeroTier 같은 SaaS형 VPN도 고려했습니다.
설정은 편하고, 로그인만으로 바로 접속 가능한 매력적인 방식이었지만,
다음과 같은 현실적인 판단을 거쳐 WireGuard로 결정하게 되었습니다:

항목 WireGuard OpenVPN Tailscale ZeroTier Cloudflare Tunnel Algo VPN
설치 난이도 낮음 보통~복잡 없음 (클라우드 서비스) 없음 없음 중간
성능 매우 빠름 (UDP 기반) 중간 (TLS/SSL, TCP) 빠름 (WireGuard 기반) 보통 빠름 (Tunnel) 빠름
보안성 최신 표준, 검증됨 검증되었지만 설정 복잡 매우 강력 (서버리스) 암호화 있지만 구조가 공개됨 HTTP 트래픽만 안전, 자동화됨
키/접속 관리 수동 관리 (CLI/스크립트 필요) 인증서 기반 (복잡) 자동, GUI 자동 자동 (SSO도 가능) Ansible 기반 자동화
접속 제어 IP + 키 기반 (정밀) TLS Cert + 사용자 관리 이메일 기반 ACL 네트워크 기반 ACL 도메인/이메일 기반 SSH + 키 관리
클라이언트 설치 수동 설정 필요 수동 (GUI도 있음) 앱 설치 후 로그인 앱 설치 후 로그인 없음 (웹 + Cloudflare) 없음 (VPN을 설정)
팀 협업 적합도 좋음 (수동) 설정 부담 큼 아주 우수 (SSO/ACL) 우수 제한적 (HTTP 전용) 자동화 용이
사설 네트워크 구성 직접 구성 직접 구성 자동 생성 자동 생성 ❌ (HTTP only) 직접 구성
Terraform 연동 O (Docker/Systemd 등으로 가능) O ❌ ❌ ❌ O (모듈 있음)
고려 항목 판단 기준 결과
팀 규모 6명 → 키 기반 수동 관리도 가능 O
Cloud 역량 전담 인프라 담당자 2명 보유 O
보안 위협 경험 Dev 환경에 .env 접근 시도 실재 반드시 네트워크 레벨 차단 필요
프라이빗 구성 Dev/Prod 모두 내부 IP 기반 구성 SaaS형 VPN으로는 한계 있음
성능/간결성 UDP 기반 고성능, 경량 설정 WireGuard 우세
종속성 외부 서비스 의존 최소화 자체 구성 선호

결국, Tailscale은 충분히 편리했지만,
저희 서비스 구조에는 WireGuard가 더 잘 맞는다는 결론에 도달했습니다.

운영 환경에 맞춘 WireGuard 설계

  • 각 개발자는 자신만의 키 쌍을 가지고 있으며,
    peer.conf 형태로 서버에 등록됩니다.
  • QR로 모바일 접속도 가능하도록 구성되어 있어 실사용 편의성도 확보했습니다.
  • 접속한 사용자는 10.100.100.X 대역의 내부망에 진입하여,
    프라이빗 서브넷에 있는 리소스들(Dev 서버, ArgoCD, Grafana, DB 등)에 접근할 수 있습니다.
  • 반대로 VPN에 연결되지 않으면, 이 리소스들은 존재 자체가 보이지 않습니다.

WireGuard 운영 전략

  • Cloud 팀은 Terraform + cloud-init을 통해 WireGuard 서버를 자동으로 구성하며,
  • 사용자 추가 시, CLI 기반 키 발급 → .conf 파일 또는 QR 전송
  • 접속 로그는 journalctl 기반으로 확인하며, 필요 시 WireGuard exporter로 Grafana 연동 가능

이런 구조는 복잡한 인증서 체계(OpenVPN)나 SaaS 종속(Tailscale)을 피하면서도,
필요한 만큼의 강력한 보안과 운영 편의성을 모두 충족해 주었습니다.

결론

WireGuard는 단순히 빠른 VPN이 아닙니다.
저희에겐 Dev 환경을 구조적으로 은닉하고,
운영자의 행위만이 내부 리소스에 도달할 수 있도록 제어하는 방화벽 그 자체였습니다.

우리는 서비스 운영에서 얻은 보안 인사이트와,
구성 가능한 인프라 경험을 바탕으로 WireGuard를 선택했고,
그 선택은 지금까지도 "적절한 수준의 통제"를 제공해주는 현실적인 해답이 되어주고 있습니다.