파일 전송 시스템의 마이크로서비스 아키텍처

개인정보 보호법(PIPA) 제29조는 개인정보 처리 시스템에 기술적·관리적 보호 조치를 요구합니다. 파일 전송 시스템을 마이크로서비스로 분리하면 각 서비스가 독립적으로 스케일링되고, 장애가 격리되며, 필요 시 다른 언어로 재작성할 수 있습니다. 운영 유연성과 명확한 책임 소유권을 얻는 반면, 분산 시스템 복잡성, 네트워크 오버헤드, 강력한 관찰 가능성 요건이 비용으로 따릅니다.

합리적인 서비스 경계

모든 기능이 별도의 서비스를 가질 필요는 없습니다. 파일 전송 플랫폼의 합리적인 분해: Upload Service(프리사인 URL 생성, 멀티파트 조율), Metadata Service(PostgreSQL의 전송 레코드, 공유 링크 생성), Notification Service(SendGrid나 Postmark를 통한 이메일, 웹훅), Scanning Service(ClamAV 또는 상용 AV를 통한 악성 코드 검사), Billing Service(Stripe 통합), Frontend API Gateway(Kong, Traefik 또는 AWS API Gateway). 6~8개의 서비스가 일반적으로 최적점입니다.

무상태 업로드 서비스

Upload Service는 무상태(stateless)이고 수평 확장 가능해야 합니다. 모든 상태는 캐시(Redis)나 데이터베이스(PostgreSQL, DynamoDB)에 있어야 하며, 절대로 로컬 프로세스 메모리에 두어서는 안 됩니다. 이렇게 하면 어떤 인스턴스도 어떤 요청이든 처리할 수 있어 블루/그린 배포와 자동 스케일링이 간단해집니다. Kubernetes 배포에 CPU 또는 요청 속도 기반 Horizontal Pod Autoscaler를 사용하세요. 업로드 초기화의 p99 지연 시간 100ms 미만을 목표로 하세요.

비동기 작업을 위한 메시지 큐

바이러스 검사, 썸네일 생성, 웹훅 전달, 이메일 발송은 업로드 완료를 차단해서는 안 되는 비동기 작업입니다. 메시지 큐를 사용하세요: 단순성과 비용을 위한 AWS SQS, 높은 처리량과 재생을 위한 Apache Kafka, 유연한 라우팅을 위한 RabbitMQ, GCP 사용자를 위한 Google Pub/Sub. 업로드가 완료되면 Upload Service가 "transfer.created" 이벤트를 발행합니다. Scanning Service는 ClamAV를 실행하고, Notification Service는 공유 이메일을 보내며, Webhook Service는 설정된 엔드포인트에 POST합니다. 각 구독자는 실패 시 지수 백오프와 데드레터 큐로 재시도합니다.

이벤트 스키마와 계약 테스트

이벤트 스키마에 합의하고 버전을 지정하세요. JSON Schema 또는 Avro가 작동하고, gRPC를 통한 Protobuf는 강타입 계약에 좋습니다. 예: {"type": "transfer.created", "version": "1.0", "id": "uuid", "sizeBytes": 5242880000, "createdAt": "2026-11-20T12:00:00Z"}. 파괴적 변경은 마이그레이션 기간 동안 두 버전이 모두 지원되는 "v2.0"으로 이동합니다. Pact 같은 계약 테스트 도구는 배포 전에 CI에서 프로듀서와 컨슈머가 합의했는지 검증합니다.

메타데이터 스토리지 선택

PostgreSQL은 대부분의 파일 전송 메타데이터 워크로드를 잘 처리합니다: 전송, 사용자, 공유, 감사 로그, 청구 레코드. 테이블이 100GB를 초과하면 created_at으로 파티셔닝하세요. 더 높은 처리량을 위해 복합 키(user_id, created_at)를 사용하는 DynamoDB는 예측 가능한 지연 시간으로 수백만 레코드까지 스케일링됩니다. Redis나 Memcached 인메모리 캐시가 읽기 많은 워크로드에 도움이 됩니다.

서비스 간 통신

Protobuf를 사용하는 gRPC는 빠르고 타입 안전하며 높은 RPS 내부 API에 적합합니다. OpenAPI 스펙을 갖춘 REST는 더 단순하고 curl로 디버깅 가능합니다. Istio나 Linkerd 같은 서비스 메시는 서비스 간 mTLS, 카나리 배포를 위한 트래픽 전환, 코드 변경 없는 자동 재시도를 추가합니다. 핫 경로에 gRPC를 예약하세요: 업로드 초기화마다 Upload Service와 Metadata Service 간 조회가 발생하므로 JSON over HTTP 대비 5~10배 속도 향상이 의미 있습니다.

서비스 간 인증 및 권한 부여

각 서비스는 호출자를 알아야 합니다. Auth Service(Auth0, Keycloak 또는 커스텀)가 발행한 JWT가 요청 체인을 통해 전파됩니다. 각 서비스 경계에서 JWT 서명을 반드시 검증하세요. 사용자 컨텍스트 없는 서비스 간 호출에는 SPIFFE/SPIRE를 통한 서비스 ID와 함께 mTLS를 사용하세요. OPA(Open Policy Agent) 사이드카가 "사용자 X가 전송 Y를 읽을 수 있는가?" 같은 권한 정책을 평가합니다.

관찰 가능성: 로그, 메트릭, 트레이스

관찰 가능성 없이 마이크로서비스는 불투명한 블랙박스로 전락합니다. OpenTelemetry 계측이 Jaeger, Tempo, Datadog 같은 백엔드로 트레이스, 메트릭, 로그를 내보냅니다. Prometheus와 Grafana의 메트릭이 서비스별 RPS, 오류율, 지연 시간을 추적합니다. Loki나 Elasticsearch의 JSON 구조화 로그로 트레이스 ID 검색이 가능합니다. 오류 예산 소진에 대한 SRE 방식의 SLO 경보로 사용자가 불평하기 전에 회귀를 감지합니다.

언제 마이크로서비스가 과도한가

개발자 1~2명과 월 10만 건 전송의 소규모 서비스에는 8개의 마이크로서비스가 필요하지 않습니다. Go, Node.js, Rails로 잘 구성된 모놀리스가 두 대의 적당한 VM에서 그 워크로드를 처리하고, 몇 분 만에 배포하며, 서비스 메시 디버깅 대신 기능 구축에 시간을 씁니다. 마이크로서비스는 약 20명 이상의 엔지니어 규모 또는 컴포넌트별 스케일링 요건이 크게 다를 때 성과를 냅니다. HexaTransfer는 S3 호환 스토리지와 CDN에 크게 의존하는 소수의 집중된 서비스를 사용해 글로벌 저지연 10GB 전송을 지원하면서도 운영 복잡성을 관리 가능한 수준으로 유지합니다.

https://hexatransfer.com — 무료, 계정 불필요, 최대 10GB.