MCP 아키텍처 선언 — 플랫폼의 새로운 청사진

1. MCP(Modular Cloud Platform) 개요

MCP는 REINDEERS의 핵심 인프라 아키텍처로, 모든 기능을 독립된 모듈로 분리하고, 각 모듈이 자체 CI/CD 파이프라인을 통해 배포되며, 장애 시 자동으로 재배포 및 복구되는 구조를 목표로 설계되었다.

모듈화: 모든 서비스(API, AI, 물류, 결제, WMS 등)는 컨테이너 단위로 격리
복제: 리전 간 데이터 실시간 복제 (DTS + GTID 기반)
자동화: Drone CI/CD, COS 업로드, CDN 캐시 자동 무효화
보안: IAM 최소 권한, HTTPS + mTLS 내부 통신, VPC 내 Private Endpoint

MCP라는 이름에 "Modular"가 들어간 이유는 명확하다. REINDEERS는 단일 서비스가 아니다. 거래 플랫폼(REINDEERS), 물류 SaaS(DVRP), 생산/재고 관리(POP), 문서 자동화(Document AI), 업무 자동화(Workflow AI)까지 5개의 플랫폼이 하나의 생태계를 이루고 있다. 이 플랫폼들이 독립적으로 배포되면서도 데이터와 이벤트를 공유하려면, 처음부터 모듈 간 경계가 명확하게 정의되어야 한다. MCP는 이 경계를 인프라 수준에서 강제하는 구조다.

2. 왜 이벤트 드리븐인가 — 일반 커머스 플랫폼과의 차이

일반적인 이커머스 플랫폼은 요청-응답(Request-Response) 패턴으로 충분하다. 사용자가 주문하면 서버가 처리하고 결과를 돌려준다. 하지만 B2B 무역 플랫폼은 다르다. 하나의 거래가 견적 → 주문 → 인보이스 → 선적 → 통관 → 정산이라는 긴 생명주기를 가지며, 각 단계마다 다른 주체(바이어, 공급사, 포워더, 은행)가 관여한다.

이 흐름에서 "주문이 확정되었다"는 사실은 단순히 주문 서비스에만 영향을 주는 것이 아니다. 물류 서비스가 선적 준비를 시작해야 하고, 재고 시스템이 할당을 확정해야 하며, 환율 서비스가 결제 통화를 고정해야 한다. 이 모든 것을 동기적으로 처리하면 하나의 API 호출이 수십 초가 걸리고, 중간에 하나라도 실패하면 전체 트랜잭션을 롤백해야 한다.

이벤트 드리븐 아키텍처는 이 문제를 해결한다. 주문 서비스는 "주문 확정" 이벤트를 MQ(LavinMQ)에 발행하고, 자신의 역할을 끝낸다. 물류, 재고, 환율 서비스는 각자 이 이벤트를 구독하여 독립적으로 처리한다. 서비스 간 결합도가 낮아지고, 개별 서비스의 장애가 전체 시스템으로 전파되지 않는다.

3. 글로벌 인프라 구조 — 홍콩 메인 / 서울 DR

REINDEERS MCP는 홍콩(ap-hongkong)을 메인 리전, 서울(ap-seoul)을 재해복구 리전으로 구성한다. 데이터는 DTS(Data Transmission Service)를 통해 실시간으로 비동기 복제된다.

아키텍처 구성

[Global Routing]
   DNSPod Geo Routing (TTL=60s, Health Monitor Enabled)
        ↓
[ap-hongkong]
   - COS + CDN Edge (Static)
   - API Gateway (Private)
   - Container Cluster
   - LavinMQ (AMQP)
   - Redis Cluster (Session, Cache)
   - DB Master
        ↓ DTS (Async, GTID)
[ap-seoul]
   - DB Replica
   - Standby Containers
   - AutoFailover via Cloud Function + DNSPod API

Cloud Monitor가 DB 혹은 API 응답 실패를 감지하면, Cloud Function이 DNSPod API를 호출하여 자동으로 DR 리전으로 트래픽을 전환한다. Failover 과정은 평균 45~60초 내에 완료된다.

홍콩을 메인 리전으로 선택한 것은 지리적 계산의 결과다. 태국(방콕), 한국(서울), 중국(상하이/선전), 말레이시아(쿠알라룸푸르) 4개국에 대해 홍콩은 네트워크 지연 시간의 총합이 가장 작은 위치다. 서울을 DR 리전으로 둔 것은 한국 사용자 비중과 한국 내 규제 대응을 고려한 결정이다.

4. 설계 원칙 — 아키텍처를 관통하는 5가지 기준

MCP 아키텍처는 다섯 가지 원칙 위에 세워졌다. 이 원칙들은 기술 선택뿐 아니라 운영 정책과 팀 구조까지 관통한다.

서비스 독립성: 각 플랫폼(REINDEERS, DVRP, POP, Document AI, Workflow AI)은 독립 배포, 독립 장애 격리가 가능해야 한다.
이벤트 기반 통신: 플랫폼 간 데이터 전달은 반드시 MQ를 통해야 하며, 동기적 API 호출은 최소화한다.
데이터 일관성: Event + State + Log 모델을 따른다. 모든 상태 변경은 이벤트로 기록되고, 현재 상태와 변경 이력이 분리 관리된다.
자동 복구: 장애 감지부터 DR 전환까지 사람 개입 없이 완료되어야 한다.
관측 가능성: 모든 API 호출, 이벤트 처리, 배포 결과가 추적 가능해야 한다. Telegram 알림과 대시보드로 실시간 모니터링한다.

5. Drone CI/CD 파이프라인 — 완전 자동화된 배포

CI/CD는 Drone으로 표준화되었다. 모든 서비스는 YAML 기반 파이프라인으로 정의되며, COS 업로드 시 올바른 Content-Type과 ACL 설정을 자동 적용한다.

kind: pipeline
type: docker
name: reindeers-deploy

steps:
  - name: build
    image: node:20
    commands:
      - npm ci
      - npm run build

  - name: upload
    environment:
      COS_BUCKET: reindeers-fe
      COS_REGION: ap-hongkong
    commands:
      - upload to COS with content-type and acl

  - name: purge-cdn
    commands:
      - invalidate CDN cache for static assets

  - name: notify
    commands:
      - send deploy result to team channel

배포는 Git push 이벤트로 트리거되며, 빌드 완료 후 COS 업로드, CDN 캐시 무효화, 알림까지 25초 내 완료된다. 롤백이 필요한 경우에도 이전 빌드 아티팩트가 COS에 버전별로 보존되어 있어 해당 버전을 다시 활성화하는 것으로 수 초 내에 복원이 가능하다.

6. DNSPod Geo Routing & Health Monitoring

글로벌 접근 시 DNSPod의 Smart Routing 정책을 사용한다. TTL은 60초, Health Monitoring 기능은 5초 간격으로 API Gateway를 검사하며, 응답이 2회 연속 실패하면 DR 리전으로 자동 전환된다.

reindeers.com (A)
├── KR, JP → ap-seoul
├── TH, MY, SG → ap-hongkong
├── CN → ap-shanghai (planned)
└── Default → ap-hongkong

TTL = 60s
Health Monitor:
  Check Interval = 5s
  Fail Threshold = 2
  Action = DNS Record Switch

Geo Routing의 핵심은 사용자가 자신에게 가장 가까운 엣지에서 서비스를 받도록 하는 것이다. 태국의 바이어가 접속하면 홍콩 엣지로 라우팅되고, 한국의 관리자가 접속하면 서울 엣지로 라우팅된다. 이 라우팅은 DNS 수준에서 이루어지기 때문에 애플리케이션 코드 변경 없이 동작한다. 4개국에 걸친 파트너들이 동시에 사용하는 플랫폼에서 이 구조는 필수적이었다.

7. 데이터 동기화 — DTS 복제 및 복구 정책

데이터는 DTS 비동기 복제로 동기화되며, GTID 기반으로 트랜잭션 일관성을 유지한다. 복제 지연 평균은 2~3초이며, 장애 시 자동 Resume 기능이 활성화된다.

DTS 설정 (개념)

Source: DB (ap-hongkong, Primary)
Target: DB (ap-seoul, DR)
Mode: Async
Heartbeat: 5s
Fail Recovery: Auto
Binlog Retention: 7 days
GTID: Enabled

장애 발생 후 복구 시 Last GTID Position부터 복제를 재개해 데이터 손실을 방지한다. 또한 DR 복제본은 주기적으로 Read-Only Health Check를 수행한다. 비동기 복제를 선택한 이유는 명확하다. 홍콩-서울 간 네트워크 지연이 존재하는 상황에서 동기 복제를 사용하면 모든 쓰기 작업의 응답 시간이 네트워크 왕복 시간만큼 증가한다. B2B 거래에서 데이터의 "최종 일관성(eventual consistency)"은 허용 가능하지만, 쓰기 작업의 지연은 사용자 경험을 직접적으로 해친다. 2~3초의 복제 지연은 우리 비즈니스 요구사항에서 충분히 허용되는 범위다.

8. MQ와 Redis 통합 구조 — 동기화와 이벤트 분리

MQ는 서비스 간 비동기 이벤트 전달에, Redis는 세션과 캐시 관리에 사용된다. 두 시스템은 서로 다른 목적을 가진다.

Redis: Cluster Mode, Session TTL = 3600s, Cache TTL = 300s
LavinMQ: Topic Exchange, 평균 처리량 3,800 msg/s

exchange: reindeers.global
type: topic
durable: true
bindings:
  - routing_key: order.created
    queue: order_worker
  - routing_key: shipment.updated
    queue: logistics_worker

MQ와 Redis가 공존하는 이유는 역할이 근본적으로 다르기 때문이다. MQ(LavinMQ)는 "무언가 일어났다"는 사실을 관심 있는 서비스에게 전달하는 역할이다. 주문 생성, 선적 상태 변경, 환율 갱신 같은 이벤트가 여기에 해당한다. Redis는 "지금 이 순간의 상태"를 빠르게 조회하기 위한 캐시 역할이다. 사용자 세션, 최근 환율, 자주 조회되는 상품 정보 등이 Redis에 저장된다. 두 시스템이 연동되는 지점은 캐시 무효화다. MQ에서 데이터 변경 이벤트가 발생하면, 해당 데이터의 Redis 캐시를 즉시 삭제한다. 다음 조회 시 최신 데이터가 DB에서 다시 로드되어 캐시에 반영된다.

9. 보안과 권한 관리 — 최소 권한 원칙

IAM 정책은 "최소 권한(Least Privilege)" 원칙을 따른다. 예를 들어, 배포 봇은 COS에만 쓰기 권한을 갖는다. API와 데이터 접근은 모두 HTTPS + JWT 기반으로 인증되며, 내부 컨테이너 간 통신은 mTLS로 암호화된다.

보안 설계에서 특히 신경 쓴 부분은 SSO(Single Sign-On)와 OIDC 기반의 통합 인증이다. 5개 플랫폼을 사용하는 파트너가 각각 별도의 계정을 관리해야 한다면 사용성이 크게 떨어진다. SSO를 통해 한 번의 로그인으로 모든 플랫폼에 접근할 수 있도록 했고, 각 플랫폼별 권한은 RBAC(Role-Based Access Control)로 세밀하게 관리된다. 바이어, 공급사, 포워더라는 세 가지 역할(role)에 따라 볼 수 있는 데이터와 실행할 수 있는 작업이 엄격히 분리된다.

10. 결론 — 자동화, 복제, 회복, 그리고 일관성

MCP는 단순히 기술적 구조가 아니라, REINDEERS가 지속적으로 확장될 수 있는 기반이 되었다. 이제 하나의 코드베이스가 여러 리전에서 동일하게 배포되고, 데이터는 실시간으로 복제되며, 장애 시 자동으로 복구된다.

MCP 아키텍처 선언은 기술적 결정인 동시에 조직적 선언이었다. "우리는 이 방식으로 시스템을 만들겠다"는 약속이자, "이 원칙에서 벗어나는 코드는 머지되지 않는다"는 기준이었다. 스타트업에서 아키텍처 문서를 작성하는 것이 사치처럼 느껴질 수 있다. 하지만 4개국에 걸쳐 5개 플랫폼을 운영하려는 시점에서, 아키텍처 원칙 없이 코드를 작성하는 것은 더 큰 사치였다. MCP는 그 원칙을 코드와 인프라에 직접 내장한 결과물이다.

Blog

Search This Blog