ADR-0051: BYOC 배포 토폴로지 — 증권사 클라우드 사상, 단계형 구성과 승격 조건¶

상태: 승인됨
날짜: 2026-08-12
관련: ALPHA-954 · ADR-0010(하이브리드 온프렘) · ADR-0012(mTLS CSR) · ADR-0017(데모 compose) · ADR-0034(호스트 단위 ALB) · ADR-0036(Sync 2모듈 토폴로지) · ADR-0040(번들 서명) · ADR-0049(LLM 트리아지) · 논의 기록(노션 "기술 아티클 주제" v3 — 트랙 2 전환 영향 분석·BYOC 사실 재확인, 2026-08-10)

맥락¶

2026-08-12 멘토 확인으로 B2B 납품 형태가 증권사 클라우드 계정 배포로 확정됐다. 이는 ADR-0010 의 On-Prem 정의("물리 서버가 아니라 증권사가 통제하는 실행 환경 — 증권사 명의의 전용/금융 클라우드 포함") 안의 배치 형태이고, context.md 용어 정의 ②는 이미 "클라우드 기반이면 VPC 서브넷 분리로 DMZ/내부망을 사상"이라고 예고했다. 즉 이 결정은 방향 전환이 아니라 사상(mapping)의 확정이다. 현재 개인신용정보 처리가 없어 규제상 비중요업무 트랙이 유지된다는 전제(ADR-0049 맥락 ②)도 이 확정과 일관된다.

그러나 지금까지의 배치 계열 결정 일부는 물리 망분리를 전제로 서 있다: 전송 경로는 "인터넷 outbound 443 + 방화벽 FQDN 화이트리스트"(sync-protocol), Sync 온프렘 2모듈 표준은 망연계(망간자료전송) 요구 증권사를 기본 상황으로 상정 (ADR-0036 — 단 그 결정의 핵심 근거는 장비가 아니라 신뢰 구역 분리다, 아래 "바뀌지 않는 것" 참조), 실납품 패키징은 미확정(compose 는 데모 구동 방식 선택 — ADR-0017 은 데모 토폴로지 결정이고 실납품 패키징 별개는 docs/implementation.md §2 가 명시). 사상 확정으로 무엇이 바뀌고 무엇이 유지되는지, 그리고 어느 시점에 어떤 구성으로 배포하는지 (현행 compose 단일 EC2 를 언제까지 쓰는가)를 한 곳에 기록할 필요가 있다 — 기록하지 않으면 "왜 아직 Fargate 가 아닌가"가 비용 절감으로 오독되고, 반대로 필요 전에 풀 토폴로지를 세워 고정비(파일럿 최소형 기준 월 $160~250, 현행 데모 박스 월 ~$25)를 태우는 양쪽 실수가 다 열린다.

결정¶

배포 모델은 BYOC(Bring Your Own Cloud)다 — 벤더 control plane + 증권사 계정 data plane. 온프렘 5모듈·DB·고객 데이터·검수·노출은 전부 증권사 계정 안에서 실행되고 비용도 증권사 계정으로 청구된다(납품 견적 항목). 벤더 계정에는 분석 파이프라인과 Tenant Sync API 등 기존 Cloud 플레인만 남는다 — ADR-0010 의 하이브리드 분리·데이터 비반출 서사는 그대로다.
망분리는 VPC 로 사상한다. 물리 DMZ/내부망 분리는 서브넷 분리 + Security Group 으로 대응시킨다(context.md 용어 정의 ②의 구체화). 경계의 의미(외부와 닿는 구역과 데이터가 눕는 구역의 분리)는 유지되고 구현 재료만 바뀐다.
벤더↔증권사 전송 경로는 PrivateLink 를 표준으로 한다. 증권사 VPC 의 consumer endpoint 가 벤더 엔드포인트 서비스로 연결한다 — 연결을 여는 쪽이 소비자(증권사)라 outbound Pull only 방향성과 정합한다. mTLS 는 그 위에 유지한다(ADR-0012 불변) — PrivateLink 는 경로 프라이버시만 제공하고 주체 인증은 별개이며, 인증서-테넌트 바인딩은 네트워크가 아니라 조직 간 신뢰·감사 문제다. 벤더 측은 PrivateLink 가 NLB 프론트를 요구하므로 sync 채널만 NLB(TLS passthrough) → 기존 mTLS ALB 타겟 체인으로 재배선한다 — ADR-0034 가 배제한 대안은 "NLB TLS passthrough + 앱 종단 mTLS"(TLS·인증서 운영을 앱이 떠안는 구성)였고, 이 체인은 passthrough 뒤에서 mTLS 종단을 여전히 관리형 ALB 가 맡으므로 그 배제 사유에 걸리지 않는다 — ADR-0034 는 대체가 아니라 유지·연장이다. 비AWS 금융클라우드 테넌트는 PrivateLink 대신 기존 인터넷 outbound 443 경로를 그대로 쓴다 — mTLS·Pull 프로토콜이 전송 경로와 독립이므로 경로만 갈린다.
벤더의 증권사 계정 접근은 zero-access 지향을 기본으로 한다. 벤더는 아티팩트(컨테이너 이미지·IaC 템플릿·마이그레이션)를 제공하고 실행 주체는 증권사다. 증권사 환경에서 벤더 쪽으로 열리는 것은 outbound Pull(sync)과 이미지 pull 뿐이며, 벤더가 증권사 계정 리소스에 접근하는 상시 권한은 두지 않는다 — 개인키 비반출(ADR-0012)·outbound only 와 같은 계열의 서사이고 보안 심사 표면이 최소가 된다. 증권사가 운영 위탁을 원하면 cross-account IAM 역할 위임(배포 파이프라인 한정, 세션 감사 로그 필수)을 옵션으로 제공한다.
토폴로지는 단계형이고, 승격은 조건 도달 시점에 한다. 각 단계는 이전 단계를 포함하며, 승격 트리거가 실물이 되기 전에는 올리지 않는다:

단계	구성	승격 트리거 (이 요구가 실물일 때만)
0 (현행)	단일 EC2 + Docker Compose (컨테이너 Postgres 포함)	— 데모·개발·초기 파일럿 표준 (ADR-0017 유지)
1	0 + DB 를 RDS 로 분리	감사·내구성 요구 — PITR·자동 백업·Multi-AZ 를 요구하는 파일럿/계약
2	1 + 서브넷 경계 분리 — 실행 호스트를 DMZ 사상 구역(sync-agent)과 내부망 사상 구역(나머지 모듈 + DB)으로 분리 배치(EC2 2대 또는 상당), SG 로 경계 규칙 명시	증권사 보안 심사 — "망분리 상당 구성"을 구조로 증명해야 하는 시점
3	2 + ECS Fargate 전환 + internal ALB + VPC interface endpoints	운영 SLA — auto scaling·다 AZ·무중단 배포 요구

단계 0·1 은 망분리 상당 구성(context.md On-Prem 요건 ②)을 아직 충족하지 않는다 — 따라서 실 테넌트 데이터가 실리는 납품 배치의 최소선은 단계 2 이고, 0·1 은 데모·온디맨드 검증·비실데이터 파일럿에 한정된다. 벤더 sync 용 PrivateLink consumer endpoint(결정 3)는 이 단계 축과 독립이다 — 실 벤더 연결이 생기는 시점(실 테넌트 배치, 곧 최소 단계 2)에 단계와 무관하게 구성하며, 단계 3의 interface endpoints 는 이와 별개인 폐쇄 서브넷 운영용 (ECR·Logs·Secrets)이다. 데모 박스는 이 결정으로 바뀌지 않는다 — 0단계가 곧 데모 구성이다. ADR-0017·ADR-0033 의 토폴로지 결정(별도 EC2 + compose)은 유지되나 두 문서의 문면 스택 열거 중 Redis 는 이후 ALPHA-433(인프로세스 Caffeine 채택, Redis 반입 보류)으로 빠진 현실을 반영하지 못한다 — 단계 0 스택 구성의 정본은 배포 compose 파일이고, 두 문면 열거는 이 결정(결정 6)이 부분 대체한다(토폴로지 결정 자체는 존치, 표기는 승인 전환에서 이행 — 아래 의무). 상위 단계 토폴로지의 검증·시연은 상시 운영이 아니라 온디맨드(Terraform apply → 검증 → destroy)로 하고, interface endpoint 는 트래픽 없이도 과금되는 고정비이므로 destroy 대상에 반드시 포함한다. 6. "온프렘 외부 의존 = Postgres 하나" 제약은 유지하되 논거를 교체한다. 이 제약은 현행 실스택과 일치한다 — 배포 compose 에 Redis 는 없고, publication-api 조회 캐시는 인프로세스 Caffeine 이다(ALPHA-433 — "별도 캐시 서버(Redis)는 온프렘 반입 컴포넌트를 늘려 보류"). implementation.md· context.md·architecture/cloud-architecture.md·demo-onprem variables.tf 에 남아 있던 Redis(Publication Cache) 서술은 ALPHA-433 이후의 낡은 드리프트라 이 ADR 과 같은 PR 에서 정정했다. 구 논거(폐쇄망 반입 불가)는 증권사 AWS 계정에서 SQS·ElastiCache 가 기술적으로 열리는 순간 죽는다. 새 논거는 ① CSP 중립성 — 비AWS 금융클라우드 테넌트에 같은 스택을 이식하려면 매니지드 서비스 의존이 족쇄가 된다, ② 보안 승인 표면 최소화 — 증권사 심사 대상 컴포넌트를 늘리지 않는다. ADR-0049 결정 6(Postgres SKIP LOCKED 큐)이 이미 쓰는 근거(딜리버리 스펙 협상 표면 최소화)는 ②와 같은 계열이라 그대로 유효하다 — 이 ADR 이 걷어내는 것은 그 곁에 남아 있던 암묵적 "반입 불가" 전제뿐이다.

이 결정으로 바뀌지 않는 것: sync 프로토콜 전체(cursor·at-least-once·멱등 upsert·테넌트별 outbox — 정확성 문제라 전송 계층과 무관), mTLS 와 CSR 부트스트랩(ADR-0012), 번들 서명 목표 계약(ADR-0040), 하이브리드 플레인 분리 (ADR-0010). ADR-0036 의 2모듈 표준도 이 ADR 로는 바뀌지 않는다 — 그 표준의 핵심 근거(외부와 닿는 Pull 과 데이터를 눕히는 저장의 신뢰 구역 분리)는 망연계 장비 유무가 아니라서 VPC 사상만으로 자동 소멸하지 않는다. 단일 모듈 표준화 여부는 서브넷+SG 경계가 그 신뢰 구역 분리를 대체하는지를 정면으로 다루는 별도 ADR 에서 결정한다 — 그 재검토는 ADR-0052 가 수행했고, 결론은 2모듈 표준 유지·근거 재정초(조율 메커니즘 문면만 부분 대체)다.

대안¶

풀 Fargate 토폴로지를 즉시 표준으로 — 승격 조건 도달 전에 월 $160~250 고정비를 상시 태우고, 데모·개발에는 아무 이득이 없다. 단계 3으로 유보.
물리 온프렘 전제 유지(사상하지 않음) — 확인된 납품 형태와 어긋난 전제 위에 결정이 계속 쌓인다. 배제.
mTLS 를 IAM SigV4 인증으로 대체 — PrivateLink 환경에서 기술적으로 가능하나 인증이 CSP 에 종속되어 비AWS 테넌트와 이원화되고, 인증서-테넌트 바인딩·CSR 서사(ADR-0012)를 버리게 된다. mTLS 가 CSP 중립 기본으로 잔류. 배제.
벤더 계정 서빙(SaaS)으로 전환 — 고객 데이터·검수·노출이 벤더 통제 환경으로 들어와 ADR-0010 이 배제한 방향으로 되돌아간다. 배제.
cross-account IAM 위임을 기본 권한 모델로 — 업계 일반형(Databricks classic)이나, 벤더 상시 접근 권한이 심사 표면과 책임 소재 논쟁을 키운다. zero-access(WarpStream 형)가 기존 서사와 정합해 기본이 되고, 위임형은 운영 위탁 옵션으로 강등.

결과¶

얻는 것: 배치 계열 결정의 전제가 확인된 사실 위로 정렬된다. 심사 대응 서사 ("망분리는 서브넷+SG 로 구조화, 벤더는 zero-access, 데이터 비반출")가 문서로 선다. 단계·승격 조건이 명시되어 현행 구성 유지가 근거 있는 결정이 된다 — 벤더 실부담 순증은 벤더 측 NLB(월 $16~25)뿐이고 data plane 비용은 견적 항목이다. 기존 sync·mTLS 코드는 무변경이다.
잃는 것/트레이드오프: 물리 반입·망연계를 실제로 요구하는 증권사 대응 경로 (ADR-0036 2모듈 + 망연계 전달)는 표준 그대로 유효하게 남아 이 ADR 이 줄여주는 것이 없다. PrivateLink 는 AWS 전제라 전송 경로가 테넌트 CSP 에 따라 이원화된다(프로토콜은 단일, 경로만 분기). 단계형은 "지금 안 올린다"의 근거를 주지만 승격 트리거 판정이라는 운영 판단을 남긴다.
따라오는 의무: ~~ADR-0017·0033 부분 대체 표기~~(승인 전환 ALPHA-957 에서 이행 — 0046→0047 부분 대체 선례), ~~ADR-0036 재검토 ADR 별도 작성~~(ADR-0052 로 이행 — 결론은 2모듈 표준 유지·근거 재정초). 남은 것: ADR-0049 의 배치 전제 정합 확인 후 승인 전진, 구현 착수 시 context.md §3(네트워크 배치)· sync-protocol 문서의 전송 경로 서술 갱신(이 ADR 은 방향 합의만 기록하며 문서 일괄 갱신은 구현 티켓에서), 승격 트리거 도달 시 단계 전환을 결정 로그로 기록, 상위 단계 온디맨드 검증 시 endpoint 포함 전체 destroy 확인. 구현은 전부 별도 티켓이다.