🚀 마이크로서비스 보안: API Gateway + Docker Private Networks

Source: Dev.to

🚀 첫 번째 분산 시스템을 구축하는 개발자를 위한 실용 가이드

마이크로서비스를 처음 만들 때 대부분의 개발자는 기능, 확장성, 혹은 모놀리스를 분리하는 데 집중하지만 보안 아키텍처에 대해서는 거의 이야기하지 않습니다. 바로 여기서 문제가 발생할 수 있습니다. 제가 직접 분산 시스템을 개발하면서 내부 API 몇 개와 PostgreSQL 데이터베이스까지 실수로 퍼블릭에 노출된 것을 발견했습니다. 😬

그래서 저는 간단하면서도 프로덕션에 바로 적용 가능한 패턴을 구현했습니다: API Gateway + Docker Private Networks. 이 글에서는 제가 어떻게(그리고 왜) 구현했는지, 그리고 여러분이 동일한 접근 방식을 자신의 프로젝트에 어떻게 적용할 수 있는지 보여드립니다.

실제 문제: 마이크로서비스가 실수로 모든 것을 노출하는 경우

초보자들이 흔히 설정하는 방식은 다음과 같습니다:

• 각 서비스가 자체 포트로 노출됨
• 클라이언트가 모든 서비스에 직접 접근
• 데이터베이스도 노출될 수 있음
• 중앙 제어나 라우팅이 없음

이로 인해 보안 문제가 발생하고, 디버깅이 복잡해지며, 아키텍처가 엉망이 됩니다.

Part 1 — API Gateway: 단일 진입점

API Gateway가 중요한 이유

작동 방식

• 클라이언트는 게이트웨이에 단일 요청을 보냅니다.
• 게이트웨이는 어떤 서비스가 해당 요청을 처리할지 결정합니다.
• 요청을 프라이빗 Docker 네트워크 내부로 전달합니다.
• 내부 URL은 외부에 절대 노출되지 않습니다.

게이트웨이는 단순한 라우터가 아니라 전체 시스템의 정문 역할을 합니다.

왜 중요한가

• 인증을 한 곳에서 관리
• 라우팅을 한 곳에서 관리
• 내부 서비스는 숨김 처리
• 코드가 깔끔해지고 제어가 쉬워짐

각 서비스를 직접 호출하는 대신:

http://localhost:3000/orders
http://localhost:4000/reports

클라이언트는 다음과 같이 호출합니다:

http://gateway/api/orders

게이트웨이가 내부적으로 요청을 전달하므로 서비스 자체를 외부에 노출할 필요가 없습니다.

Part 2 — Docker Private Networks (물리적 보안 레이어)

Docker 네트워크가 시스템을 보호하는 방법

왜 중요한가

프라이빗 네트워크가 없으면 Docker는 컨테이너를 호스트 머신에 노출합니다. 프라이빗 네트워크를 사용하면:

• 외부에서 접근 가능한 것은 게이트웨이뿐
• 모든 내부 트래픽은 네트워크 내부에 머무름
• 데이터베이스에 직접 접근할 수 없음

서비스를 프라이빗 Docker 네트워크에 넣으면 명시적으로 노출한 것 외에는 외부에서 접근할 수 없게 됩니다.

이점

• 내부 전용 통신
• 포트 실수 노출 제로
• 데이터베이스 완전 격리
• 깔끔하고 전문적인 아키텍처

게이트웨이를 우회한다 하더라도(극히 드물게) Service A, B 혹은 데이터베이스에 접근할 수 없습니다. 왜냐하면 해당 컨테이너들은 퍼블릭 네트워크에 없기 때문입니다.

두 가지를 결합한 간단하고 견고한 보안 패턴

전체 아키텍처가 함께 작동하는 방식

다음 두 요소를 결합하면:

• 논리적 보안 (API Gateway)
• 물리적 보안 (프라이빗 네트워크)

Kubernetes, 서비스 메쉬, 복잡한 DevOps 도구 없이도 단순하면서도 강력한 마이크로서비스 아키텍처를 만들 수 있습니다.

Client
   ↓
API Gateway
   ↓
Private Docker Network
 ├── Service A
 ├── Service B
 └── Database

게이트웨이만 퍼블릭에 노출되고, 나머지는 모두 안전하게 뒤에 숨겨집니다.

최소 Docker Compose 예시 (복사/붙여넣기 가능)

services:
  api-gateway:
    build: ./gateway
    ports:
      - "8080:8080"
    networks:
      - public_net
      - private_net

  service-a:
    build: ./service-a
    expose:
      - "3000"
    networks:
      - private_net

  service-b:
    build: ./service-b
    expose:
      - "4000"
    networks:
      - private_net

  internal-db:
    image: postgres:16
    expose:
      - "5432"
    environment:
      POSTGRES_PASSWORD: password
    networks:
      - private_net

networks:
  public_net:
  private_net:

핵심 정리

• 퍼블릭 포트를 가진 것은 오직 게이트웨이뿐 → 외부에 공개
• 내부 서비스는 expose 사용 → 프라이빗
• 모든 서비스가 private_net 안에 존재
• 최소한의 설정으로 깔끔하고 안전한 아키텍처 구현

배운 점

• 내부 서비스가 실수로 노출되는 일 제로
• 안전하고 예측 가능한 진입점 확보
• 디버깅 속도 향상
• 팀원 온보딩이 쉬워짐
• 향후 서비스 확장을 위한 스케일러블한 기반
• 초보자 친화적인 도구만으로도 프로 수준 아키텍처 구현

마무리 생각

이 아키텍처는 매우 단순해 보이지만, 바로 그 점이 작동하는 이유입니다. 보안과 확장성을 갖춘 분산 시스템을 구축하기 위해 Kubernetes, 서비스 메쉬, 복잡한 DevOps 설정이 필요하지 않습니다.

시작은 이렇게:

• 하나의 API Gateway
• 하나의 프라이빗 Docker 네트워크

이 기반 위에 시스템이 성장함에 따라 자연스럽게 확장됩니다.

단순함. 깔끔함. 보안. 효율성.