#e-commerce

레거시 주문 이력 서비스 현대화

한국 전자상거래법이 요구하는 5년 주문 이력 보관 의무를 이행하던 레거시 주문 이력 서비스를 단계적으로 현대화한 과정을 정리한다.

Fiserv AAA 제거 + NaverPay 도메인 변경

벤더(Fiserv, NaverPay) 측의 변화에 따라 기존 코드를 정리하거나 수정해야 했던 경험을 기록한다. Fiserv settlement endpoint 폐기와, 예전 Nike AAA 인증 체계에서 OAuth 체계로 넘어가며 정리된 인증 경로 제거, 그리고 NaverPay 개발 환경 API 도메인 변경 대응을 함께 다룬다.

Payment logging flag

하나의 라이브러리 변경이 6개 서비스에 전파되는 cross-service 아키텍처 변경을 기록한다. Payment logging flag는 운영 중인 결제 서비스의 로깅 수준을 런타임에 동적으로 전환할 수 있게 만든 시스템이다. 디버깅이 필요할 때 서비스를 재배포하지 않고 로그 레벨을...

NaverPay 동시성 파싱 버그 수정

NaverPay 서비스에서 잘못된 파서 사용으로 발생한 동시성 버그와 그 수정 과정을 기록한다. 평소에는 잘 드러나지 않다가 트래픽이 몰릴 때 간헐적 결제 오류와 이상 로그로 드러난 문제를 어떻게 추적하고 바로잡았는지 정리한다.

공통 결제 클라이언트 라이브러리 개발

여러 결제 워커 서비스에 흩어져 있던 결제 벤더 연동 코드를 공통 결제 클라이언트 라이브러리로 정리한 과정을 기록한다. KakaoPay v2와는 별개로, KakaoPay client 부트스트랩으로 시작해 여러 벤더 client를 같은 구조로 전파한 흐름을 다룬다.

double quote 인코딩

결제 연동 서비스 API에서 상품명에 큰따옴표(double quote)가 포함된 경우 파싱 에러가 발생하는 문제를 발견하고 수정한 경험을 기록한다. 이후 같은 유형의 버그가 다른 필드에서도 반복될 수 있음을 보여준 사례였다.

테스트 커버리지 80%

내부 품질 게이트가 요구한 코드 커버리지 80% 기준을 KakaoPay v2에서 어떻게 달성했는지 기록한다. 단순히 커버리지 수치를 올린 이야기가 아니라, 커버리지 목표가 코드 구조 자체를 어떻게 바꾸게 했는지, 그 과정에서 배운...

Redocly API 문서 빌드

KakaoPay v2를 구축하면서 API 문서 관리 방식을 근본적으로 바꾼 경험을 기록한다. 기존 API Blueprint(.apib) 문서 체계에서 Redocly 기반의 자동 빌드 체계로 전환했고, 이것이 API-first 설계 접근을 실현하는 핵심 도구가 되었다.

KakaoPay v2 DynamoDB/KMS

KakaoPay v2 신규 구축 과정에서 DynamoDB 엔티티 설계와 KMS 키 관리를 어떻게 결정했는지를 기록한다. 데이터 저장 계층의 설계 결정이 이후 서비스 운영과 데이터 호환성에 어떤 영향을 미쳤는지, 그리고 공통 결제 라이브러리의 convention과 동기화해야 했던...

KakaoPay v2 신규 구축

KakaoPay v2를 처음부터 새로 만든 과정을 남긴다. 왜 v1을 확장하지 않고 v2 계열로 다시 세웠는지, 그리고 그 과정에서 공통 규칙, OpenAPI, 모델링, 벨리데이션, 로깅 구조를 어떻게 정리했는지를 기록한다.

SNKRS App KakaoPay 활성화

Nike.com에서 이미 동작하던 KakaoPay를 SNKRS App에서도 활성화한 작업을 기록한다. 기술적으로는 공통 결제 라이브러리의 설정 한 줄을 바꾸는 일이었지만, 이 경험이 이후 Payment logging flag 시스템처럼 라이브러리 하나의 변경으로 여러 서비스를...

WebView redirect POST→GET

KakaoPay 결제수단 등록 확인 과정에서 WebView의 redirect 동작 문제를 발견하고 해결한 경험을 기록한다. 모바일 WebView에서 POST redirect가 동작하지 않는 환경이 존재한다는 사실은 문서에 나와 있지 않고, 실제 테스트에서만 발견할 수 있는 문제였다.

저장결제 관리 계층 KakaoPay/Fiserv API 명세

저장결제 관리 계층 서비스에 KakaoPay와 Fiserv Billkey 등록을 통합하면서 겪은 API 명세 문제를 기록한다. 벤더마다 '등록 성공', '등록 실패', '등록 취소'의 의미가 다르다는 것을 알게 된 경험이다. 결제 시스템에서 다중 벤더를 통합할 때 공통 API 명세를...

KakaoPay 확장: 정기결제·저장결제·환불

Payment Expansion 프로젝트의 첫 번째 구현 작업을 기록한다. 기존 KakaoPay 서비스에 정기결제, 저장결제, 환불 흐름을 붙이며 저장결제 확장의 출발점을 만들었던 2023년 상반기 작업을 정리한다.

글로벌 결제 코어를 수정하면 왜 위험한가

Payment Expansion 프로젝트에서 가장 먼저 부딪힌 질문은 '어디를 고칠 것인가'였다. 한국 간편결제를 지원하려면 코드를 바꿔야 하는데, 글로벌 결제 코어를 수정하면 전 세계 결제 흐름에 영향을 준다. 이 글은 그 위험성을 구체적으로 정리하고, 우리가 택한 전략 — 로컬...

한국 결제 시장에서 저장된 결제수단이 왜 필요한가

2023년 상반기부터 본격화된 한국 결제 확장 프로젝트는 '결제수단 하나 추가'가 아니라, 재구매 경험을 바꾸는 구조적 전환이었다. 이 글은 KakaoPay/NaverPay Stored Payment가 왜 필요한지, 그리고 왜 이 주제가 Payment Expansion 시리즈의 출발점인지 설명한다.

컷오버 직후 무엇부터 안정화해야 했나

컷오버가 완료되면 끝이 아니다. DNS가 전환되고 사용자 트래픽이 글로벌 플랫폼으로 흐르기 시작하는 순간부터 안정화(stabilization)가 시작된다. 컷오버 직후의 안정화는 '문제가 발생하면 고치는' 수동적 대

컷오버 당일 최종 남은 데이터를 어떻게 이관했나

대규모 플랫폼 마이그레이션에서 가장 까다로운 기술적 도전 중 하나는 컷오버 당일의 델타(delta) 데이터 이관이다.

2022년 10월 4일 컷오버 직전 무엇을 체크했나

2022년 10월 4일, Nike의 커머스 플랫폼이 Breeze에서 글로벌 플랫폼으로 전환되는 컷오버가 예정되어 있었다.

컷오버 전 상품 정합성, Clickstream, 이메일 바운스 대응

대규모 마이그레이션에서 원래 범위에 포함되지 않았던 문제가 컷오버 직전에 불거지는 것은 드문 일이 아니다.

글로벌 팀과 로컬 팀은 컷오버를 어떻게 나눠 준비했나

Nike Korea Platform Migration은 한 팀이 단독으로 수행한 프로젝트가 아니다.

런칭 데이터와 공유 식별자의 글로벌 분석 연계

마이그레이션 이후 데이터도 새 체계로 전환되어야 했다. Nike가 글로벌 플랫폼으로 전환된 뒤, 한국 시장 데이터를 글로벌 ED&A 파이프라인에 연계하는 작업이 필요했다.

주문 이관 배치, 성능 테스트, 정합성 검증은 어떻게 준비했나

점진적 주문 이관 전략이 결정되면, 다음 질문은 '어떻게 실행할 것인가'다.

CS 조회, 반품, 배송 상태 동기화는 왜 같이 풀어야 했나

플랫폼 마이그레이션에서 기술적으로 가장 복잡한 영역은 개별 문제가 아니라, 서로 얽혀 있는 문제들을 동시에 풀어야 할 때 나타난다.

글로벌 로그인 이후에도 과거 주문 조회를 유지하는 구조

컷오버 이후 사용자는 글로벌 Nike 계정으로 로그인한다.

BLOHA는 왜 필요했고 마이그레이션에서 어떤 역할을 했나

BLOHA(Breeze Legacy Order History API)는 Nike Korea Platform Migration에서 가장 중요한 기술적 결정 중 하나의 산물이다.

기존 계정과 글로벌 계정을 공유 식별자로 연결해야 했던 이유

플랫폼 마이그레이션에서 주문 데이터를 옮기는 것만큼 중요한 것은 '이 주문이 누구의 것인지'를 새 시스템에서도 식별할 수 있게 하는 것이다. Breeze의 사용자 계정과 글로벌 Nike 계정은 별개의 시스템이었고, 두 계정을 연결하는 공유 식별자가 필요했다

반품 기간과 운영 상태를 고려한 점진적 주문 이관 전략

앞 편에서 주문 데이터를 한 번에 옮길 수 없는 이유를 설명했다면, 이 글은 실제로 어떤 전략으로 점진적 이관을 설계했는지를 기록한다. 핵심은 한국 소비자보호법의 7일 반품 기간과 주문의 운영 상태를 기준으로 이관 우선순위를 결정한 것이다

Consent Journey

Consent Journey는 겉으로만 보면 동의 화면을 만들고 이메일을 보내는 작업처럼 보일 수 있다.

Breeze 정기 배포 체계

운영 중인 커머스 플랫폼에서 정기 배포는 단순한 릴리스 절차가 아니다.

Log4j(CVE-2021-44228) 긴급 패치

어떤 운영 체계가 실제로 쓸모 있는지는 평상시보다 위기 상황에서 더 잘 드러난다. Log4j 취약점 대응은 그 점을 가장 선명하게 보여준 사건이었다. 평소라면 정기 배포 원칙을 지키는 것이 맞지만, 제로데이 보안 이

운영 비용 최적화는 왜 인프라 절감보다 구조 문제에 가깝나

운영 비용 최적화라고 하면 대부분 '더 작은 인스턴스를 쓰자', '예약 인스턴스를 구매하자' 같은 인프라 가격 절감을 떠올린다.

왜 주문 데이터는 한 번에 전부 옮길 수 없었나

대규모 데이터 마이그레이션에서 가장 위험한 접근은 '빅뱅(Big-Bang)' 마이그레이션이다

외부 장애가 내부 서비스로 전파되지 않게 막는 방법

현대의 서비스는 혼자 동작하지 않는다. 결제 게이트웨이, 배송 추적 API, 알림 서비스, 외부 인증 시스템 등 수많은 외부 의존성(dependency)이 있다. 이 외부 서비스 중 하나가 장애를 일으키면, 그 장애

Solr 이중화 문제

이중화는 이름만으로 안전을 보장하지 않는다. 실제 전환 로직이 올바르게 작동하지 않으면, 운영자는 “보호 장치가 있다”고 믿는 동안 같은 문제를 더 오래 보게 된다. Solr 이중화 문제는 그 점을 아주 선명하게 보

주문 마이그레이션에서 가장 먼저 정의해야 했던 데이터 경계

대규모 플랫폼 마이그레이션에서 가장 먼저 답해야 할 질문은 '무엇을 옮기고, 무엇을 남길 것인가'다. 모든 데이터를 옮기면 좋겠지만, 수년간 축적된 수백만 건의 주문 데이터를 새로운 스키마로 전부 변환하는 것은 기술적으로도, 운영적으로도 비현실적이다

장애 감지와 알림 체계는 어떤 신호부터 잡아야 실무에 도움이 되나

모니터링과 알림(alerting)은 서비스 운영의 기본이지만, 어떤 신호를 모니터링하고, 어떤 조건에서 알림을 보낼 것인지의 설계는 간단하지 않다.

취약점 점검과 pen test 대응은 왜 상시 체계여야 하나

보안 취약점 점검과 침투 테스트(penetration test)는 많은 조직에서 연 1회 수행하는 '이벤트'로 취급된다.

한국 플랫폼 글로벌 전환은 왜 필요했나

2022년 10월 4일, Nike의 전자상거래 플랫폼은 로컬 Breeze에서 글로벌 플랫폼으로 전환되었다. 이 글은 그 전환이 왜 필요했는지와 전략적 배경을 다룬다.

DR Plan과 실운영 DR 훈련은 무엇을 검증해야 하나

DR(Disaster Recovery, 재해복구) 계획은 거의 모든 서비스 조직이 '가지고 있다'고 말하지만, 실제로 훈련(drill)을 수행하여 계획이 동작함을 검증한 조직은 많지 않다.

운영 사이트에서 먼저 파악한 시스템 경계

운영 중인 커머스 사이트를 맡았을 때 가장 먼저 필요한 것은 기능 목록이 아니라 시스템 경계였다.

ISMS 대응은 실제 개발 조직의 일을 어떻게 바꾸는가

ISMS(Information Security Management System, 정보보호관리체계) 인증은 한국에서 일정 규모 이상의 커머스 플랫폼이 반드시 취득해야 하는 법적 요구사항이다.

왜 큰 피처를 만들지 않았나

전환기가 예정된 시스템에서는 “무엇을 만들 것인가”보다 “무엇을 만들지 않을 것인가”가 더 중요한 판단이 된다. 당시 로컬 플랫폼에는 개선하고 싶은 지점도 많았고, 비즈니스 관점에서 당장 눈에 띄는 기능 요청도 존재

입사 직후, 먼저 맡은 일은 nike.com/kr 운영이었다

2021년 Nike에 합류했을 때 가장 먼저 맡은 일은 새로운 기능을 설계하거나 새 서비스를 만드는 일이 아니었다.

대량 트래픽 발생 당시 캡처로 다시 보는 운영 포인트

대량 트래픽 당시 직접 남긴 운영 캡처와 모니터링 경험을 기준으로, 운영자가 어떤 포인트를 보고 판단했는지 다시 정리합니다.

The Draw 운영에서 배치와 캐시 초기화가 맡고 있던 역할

The Draw 운영 경험을 기준으로 배치와 캐시 초기화가 왜 중요한 역할을 했는지 정리합니다.

추첨, 재추첨, 구매 제한은 어떻게 연결되어 있었나

Nike The Draw 운영 흐름에서 추첨, 재추첨, 구매 제한, 당첨자 rule이 어떤 구조로 이어졌는지 정리합니다.

Nike The Draw 운영 구조 다시 읽기

Nike The Draw에서 등록, 응모, 추첨, 운영자 개입, 구매 흐름이 어떻게 연결되어 있었는지 운영 경험을 바탕으로 다시 정리합니다.

운영 중 로그 레벨을 바꾸는 도구는 왜 필요했나

운영 중 문제가 발생했을 때 재배포 없이 더 많은 단서를 확보하기 위해 왜 log4j 기반 런타임 동적 로그 레벨 조정 도구가 필요했는지 정리합니다.

어드민 세션 관리 기능은 왜 필요했는가

운영자는 어떤 기능을 가져야 하는가라는 관점에서, 어드민 세션 관리 기능이 왜 필요했고 어떤 운영 문제를 해결하려 했는지 정리합니다.

운영 로그는 어떻게 설계하고 봐야 하는가

커머스 플랫폼 운영에서 로그가 왜 단순 출력이 아니라 장애 해석 도구였는지, 서비스별 로그 관점을 기준으로 정리합니다.

배치 스케줄러를 운영 관점에서 다시 정리해보기

커머스 플랫폼 운영에서 배치가 어떤 역할을 맡고 있었는지, 실제 운영 경험과 스케줄 가시화 관점에서 다시 정리합니다.

주문/어드민 성능 문제를 어떻게 분석하고 튜닝했는가

주문과 어드민 영역의 성능 문제를 어떤 기준으로 분석하고, 병목을 어떻게 분리해 튜닝했는지 운영 경험을 바탕으로 정리합니다.

부분반품 환불 금액은 어떻게 다시 계산해야 하는가

부분반품이 전체 취소보다 어려운 이유와, 환불 금액 재계산에서 무엇을 어떤 순서로 다시 봐야 하는지 실제 계산을 정리하고 개선했던 경험을 바탕으로 정리합니다.

대량 트래픽에서 병목은 어디서 생기고 어떻게 줄였는가

Nike 관련 서비스 운영 경험을 기준으로 대량 트래픽에서 병목이 어디에서 나타나고 어떤 식으로 줄였는지 정리합니다.

주문 안정화를 위해 재고 처리 구조를 어떻게 봤는가

커머스 플랫폼 적응 초기에 주문 안정화의 핵심 축으로 왜 재고를 먼저 봐야 했는지, 그리고 어떤 구조와 전략을 주목했는지 정리합니다.

Broadleaf/Breeze 커스터마이징 포인트 정리

Broadleaf/Breeze를 다루면서 반복적으로 만났던 관리자 확장, 도메인 확장, 권한, 운영 설정 같은 커스터마이징 포인트를 정리합니다.

Breeze Commerce를 빠르게 이해할 때 먼저 봐야 했던 것들

Broadleaf를 먼저 살펴본 뒤 실제 적응 단계에서 Breeze Commerce 구조를 빠르게 파악하기 위해 무엇을 먼저 봐야 했는지 정리합니다.

Broadleaf Commerce를 어떻게 분석했는가

처음 보는 커머스 플랫폼 Broadleaf Commerce를 데모, 문서, 로컬 실행, 관리자 확장 구조 관점에서 어떤 순서로 해석했는지 정리합니다.

왜 GS SHOP은 Broadleaf 과제를 냈을까

GS SHOP 이직 과정에서 받은 Broadleaf Commerce 과제가 단순한 구현 테스트가 아니라, 실제 커머스 플랫폼 적응력을 보기 위한 구조 해석 과제였다고 해석한 배경을 정리합니다.