입사 초기의 커머스 운영과 전환 준비

2021년 Nike에 합류한 뒤에는 한국 커머스 플랫폼인 Breeze의 운영을 맡았습니다. 관리자 기능과 배치, 결제·정산 연동, 고객센터 도구, 사용자 웹이 어떻게 연결되어 있는지부터 파악해야 했습니다.

당시에는 글로벌 플랫폼으로의 전환도 준비하고 있었습니다. 기존 서비스를 계속 운영하면서 옮겨 갈 준비를 해야 했기 때문에, 운영 중인 구조를 이해하는 일과 개발 우선순위를 정하는 일이 이어져 있었습니다.

주문과 매장 운영의 연결

온라인 주문이라고 해서 웹 안에서만 처리가 끝나는 것은 아니었습니다. 택배 배송 외에 매장 수령도 지원했고, 선택한 매장에 재고가 없으면 다른 매장에서 재고를 옮기거나 택배로 전환하는 흐름도 있었습니다.

이 과정에서는 판매한 곳과 재고를 가지고 있던 곳, 매출을 인식하는 곳이 달라질 수 있었습니다. 고객에게는 수령 방법을 바꾸는 일이어도 내부에서는 재고와 정산을 함께 확인해야 했습니다. 주문 상태 하나를 수정할 때도 이후 배송이나 고객 응대에 어떤 영향을 주는지 알아야 했습니다.

그래서 화면이나 API만 따로 보는 것으로는 부족했습니다. 주문이 생성된 뒤 어떤 시스템과 배치를 거쳐 상태가 바뀌는지 따라가야 운영 중인 문제를 이해할 수 있었습니다.

배포와 장애 대응의 기본 흐름

정기 배포에 참여하면서 변경 내용을 누가 확인하고, 어느 시점에 운영에 반영하는지 익혔습니다. 대형 이벤트가 예정되어 있으면 배포 일정도 그 영향을 받았습니다. 수정 자체의 크기와 함께 이벤트 전후의 트래픽, 결제와 CS에 미칠 영향도 봐야 했습니다.

문제가 생겼을 때는 화면에 보이는 증상에서 시작해 데이터와 로그를 따라갔습니다. 상품 노출 문제라도 원본 데이터가 잘못된 것인지, 검색 쪽 반영이 늦은 것인지에 따라 확인할 곳이 달랐습니다. 외부 시스템의 응답 문제와 내부 처리 문제도 구분해야 했습니다.

구체적인 시스템 연결 관계는 Breeze 운영에서 먼저 파악한 시스템 구성과 연결 관계에서 이어서 정리합니다.

전환을 앞둔 기능 개발의 우선순위

개선하고 싶은 부분과 새로운 기능 요청도 있었지만, 기존 플랫폼에 큰 기능을 추가하면 전환 후 다시 구현하거나 폐기해야 할 수 있었습니다. 개발 기간뿐 아니라 테스트와 운영, 이후 옮겨 가는 데 드는 작업까지 함께 고려해야 했습니다.

그렇다고 필요한 수정을 모두 미룰 수는 없었습니다. 주문과 결제 오류, 보안 취약점, 서비스 운영에 필요한 변경은 계속 처리했습니다. 요청을 볼 때는 지금 운영에 어떤 영향이 있는지, 전환 전까지 사용할 수 있는 기간은 어느 정도인지, 글로벌 플랫폼에서도 이어서 쓸 수 있는지를 함께 따졌습니다.

이런 우선순위를 설명할 때도 전환 예정이라는 말만으로는 부족했습니다. 기존 플랫폼에서 개발했을 때의 작업과, 전환 준비를 먼저 했을 때의 차이를 요청하는 쪽과 함께 확인해야 했습니다.

운영 경험을 통한 이관 범위 확인

운영하면서 알게 된 데이터와 연동 흐름은 이후 마이그레이션 준비에도 필요했습니다. 어떤 배치를 중단할 수 있는지, 새 플랫폼에서 대체할 기능이 무엇인지, 과거 주문 조회처럼 전환 뒤에도 남겨야 할 부분이 무엇인지 판단하는 데 쓰였습니다.

입사 초기에 맡았던 운영과 큰 기능 개발을 보류한 판단은 이 흐름 안에 있었습니다. 기존 주문과 고객 응대가 계속되는 동안 필요한 수정을 진행하고, 그 과정에서 파악한 내용을 전환 준비에 연결했습니다.