BLOHA는 왜 필요했고 마이그레이션에서 어떤 역할을 했나
BLOHA(Breeze Legacy Order History API)는 Nike Korea Platform Migration에서 가장 중요한 기술적 결정 중 하나의 산물이다. 한국 전자상거래법의 주문 데이터 5년 보관 요건을 충족하면서, Breeze 시스템 종료 후에도 과거 주문을 조회할 수 있게 하는 읽기 전용 API다. 이 글은 BLOHA가 왜 필요했고, 어떤 아키텍처 결정을 거쳐 만들어졌으며, 마이그레이션 전체에서 어떤 역할을 했는지를 기록한다.
BLOHA의 핵심 가치는 “전량 이관”과 “레거시 전체 유지” 사이에서 법적 요구와 운영 리스크를 동시에 통제한 것이다.
BLOHA가 없었다면 선택지는 사실상 두 가지였다.
- 모든 과거 주문을 글로벌 플랫폼으로 전량 이관한다.
기술적으로 부담이 크고 전환 리스크가 높다. - Breeze 전체를 5년간 그대로 운영한다.
운영/유지 비용이 과도하게 커진다.
BLOHA는 이 딜레마에 대한 실용적 해답이었다. Breeze의 핵심(관계형 DB + 조회 API)만 남기고, 나머지 스택은 종료하는 방식이다.
브리지 도입 절차
요구조건 고정
5년 보관, CS 조회, 사용자 주문 조회 연계를 필수 조건으로 정의한다.
최소 경계 설계
읽기 전용 DB + 얇은 조회 API로 유지 범위를 축소한다.
접근 제어 결합
글로벌 계정 연결 키 기반 사용자 단위 권한 검증을 넣는다.
종료 조건 명시
한시 운영 기간과 종료 기준을 설계 단계에서 함께 고정한다.
선택지 비교 표
| 선택지 | 장점 | 한계 | 판단 |
|---|---|---|---|
| 과거 주문 전량 이관 | 구조 단일화 가능 | 변환 리스크/검증 비용 큼 | 컷오버 리스크 과도 |
| Breeze 전체 5년 유지 | 기존 기능 그대로 유지 | 운영/보안/유지 비용 과도 | 비효율적 |
BLOHA 브리지 운영 | 법적 요건 + 전환 안정성 균형 | 이중 경계 운영 필요 | 현실적 대안 |
한국 전자상거래법은 온라인 거래 기록을 5년간 보관할 것을 요구한다. 이 요건은 단순히 데이터를 어딘가에 저장해 놓으면 되는 것이 아니다. 고객이 요청하면 조회할 수 있어야 하고, CS 상담원이 고객 문의 시 접근할 수 있어야 한다. 법적 요건은 ‘데이터의 존재’가 아니라 ‘데이터에 대한 접근 가능성’을 요구한다.
컷오버 후 Breeze는 종료된다. 서버, 미들웨어, 배포 파이프라인 모두 해제(decommission)된다. 그러나 Breeze에 축적된 수년간의 주문 데이터는 5년 보관 요건에 따라 접근 가능해야 한다. 이 데이터를 모두 글로벌 플랫폼으로 마이그레이션하는 것은 앞선 편에서 논의한 이유(스키마 차이, 변환 리스크, 비용)로 비현실적이다.
BLOHA의 아키텍처
BLOHA의 핵심 설계 원칙은 ‘최소한의 시스템으로 읽기 전용 서비스를 제공’하는 것이었다. Breeze의 전체 스택(애플리케이션 서버, 미들웨어, 배치 시스템 등)을 유지하는 것이 아니라, 관계형 데이터베이스와 그 위에 얇은 API 레이어만 남기는 구조다.
BLOHA의 아키텍처는 대략 다음과 같다: 관계형 DB(기존 Breeze 데이터베이스, 읽기 전용) → API 레이어(REST API, 주문 조회 엔드포인트 제공) → 인증(글로벌 Nike 토큰을 검증하여 글로벌 계정 연결 키를 추출, 해당 사용자의 주문만 반환). 쓰기 작업은 일체 허용하지 않는다. 반품, 교환, 상태 변경 등은 BLOHA에서 불가능하다.
왜 파일 덤프가 아닌 API인가
‘주문 이력을 파일로 내보내서(CSV/JSON dump) 어딘가에 저장하면 되지 않는가?‘라는 질문이 있을 수 있다. 이 접근이 불가능한 이유는 두 가지다. 첫째, CS 상담원이 실시간으로 고객 주문을 조회해야 한다. 고객이 전화로 ‘3년 전에 주문한 운동화가…’라고 문의하면, CS 상담원이 즉시 해당 주문을 찾아서 정보를 확인할 수 있어야 한다. 파일 기반으로는 이 실시간 조회가 불가능하다.
둘째, 고객 자신도 로그인 후 자신의 과거 주문을 볼 수 있어야 한다. 글로벌 플랫폼의 마이페이지에서 ‘주문 내역’을 클릭하면 과거 Breeze 주문도 표시되어야 한다. 이를 위해서는 프로그래밍 방식(API)으로 데이터를 가져올 수 있어야 한다. 파일 기반 보관은 규제 대응에는 도움이 될 수 있어도, CS의 실시간 조회와 서비스 연동 흐름을 안정적으로 지원하기에는 한계가 크다.
DB 유지 비용과 수명
BLOHA의 핵심 인프라인 관계형 DB를 유지하는 비용은 Breeze 전체를 유지하는 비용보다 훨씬 적다. 애플리케이션 서버, 배치 시스템, 외부 연동(PG사, 물류 등)을 모두 제거하고, 데이터베이스와 최소한의 API 서버만 운영하면 된다. 그래도 데이터 스토리지/운영 비용은 작지 않으므로, BLOHA의 운영 기간과 비용은 면밀히 계획되어야 했다.
5년 보관 요건에 따라 BLOHA는 컷오버 이후 최소 5년간 운영되어야 한다. 이 기간 동안 DB 패치, 보안 업데이트, 인프라 유지가 필요하다. 이 비용은 마이그레이션의 숨은 비용 중 하나로, 사전에 경영진의 승인을 받아야 했다.
BLOHA의 마이그레이션에서의 역할
BLOHA는 마이그레이션 전략의 핵심 구성 요소다. BLOHA가 있기 때문에 모든 과거 주문을 글로벌 플랫폼으로 마이그레이션할 필요가 없어진다. 마이그레이션 대상은 활성 주문(반품 가능 기간 내, 진행 중인 주문)으로 한정되고, 이력 주문은 BLOHA가 서빙한다. 이것이 마이그레이션의 범위와 복잡도를 극적으로 줄여준다.
또한 BLOHA는 마이그레이션의 안전망(safety net) 역할도 한다. 마이그레이션 과정에서 특정 주문의 변환이 실패하더라도, 원본 데이터는 BLOHA의 DB에 그대로 남아 있다. 최악의 경우에도 BLOHA를 통해 원본 데이터에 접근할 수 있으므로, 데이터 유실의 위험이 감소한다.
글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 글로벌 로그인 이후에도 과거 주문 조회를 유지하는 구조를 통해 이 흐름을 계속 좁혀 본다.
브리지 아키텍처의 장단점
BLOHA 같은 브리지 서비스의 장점은 컷오버 시점의 기술/운영 리스크를 크게 줄인다는 점이다. 과거 주문을 별도 경계로 분리하면 활성 주문 이관에 집중할 수 있고, 법적 보관 요건도 동시에 충족할 수 있다.
단점은 이중 경계를 일정 기간 운영해야 한다는 점이다. 데이터베이스 유지 비용, 조회 매핑 로직, 운영 모니터링 포인트가 늘어난다. 다만 이 구조는 영구 운영을 전제로 한 것이 아니라, 법적 보관 의무 기간(최소 5년)을 안전하게 통과하기 위한 한시적 브리지였다.
즉 “복잡도를 영구히 가져간다”가 아니라 “정해진 기간 동안 통제 가능한 복잡도를 감수한다”는 판단이었다. 이 기간이 끝나면 브리지도 단계적으로 축소/종료할 수 있으므로, 당시에는 전량 이관 실패 리스크보다 이 선택이 더 실무적이었다.
기술 체크포인트
- 브리지 계층은 쓰기를 금지하고 조회 전용으로 제한해 운영 책임을 단순화했다.
- 인증 토큰에서
글로벌 계정 연결 키를 추출해 사용자 단위 접근 제어를 보장했다. - 브리지의 목표 기간을 명확히 두고 영구 시스템이 되지 않도록 종료 조건을 함께 설계했다.