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

2021년 Nike에 합류했을 때 가장 먼저 맡은 일은 새로운 기능을 설계하거나 새 서비스를 만드는 일이 아니었다. 이미 매일 실제 주문과 고객 응대가 발생하던 nike.com/kr의 운영 구조를 이해하고, 그 구조가 흔들리지 않도록 붙잡는 일이 먼저였다. 이 경험은 겉으로 보면 유지보수처럼 보이지만, 실제로는 이후 글로벌 마이그레이션을 준비하는 데 필요한 가장 중요한 학습 과정이었다.

새 회사에 들어가면 신규 개발부터 해야 실력이 드러난다고 생각하기 쉽다. 하지만 운영 중인 커머스 사이트는 그런 기대를 허용하지 않는다. 시스템의 경계를 모르고 배포하면 사고가 나고, 배치의 역할을 모르고 변경하면 데이터 일관성이 깨지며, 외부 연동의 제약을 모르고 문제를 보면 원인을 잘못 짚게 된다. 그래서 이 글은 “왜 입사 직후의 핵심 업무가 개발이 아니라 운영 이해였는가”를 시리즈의 출발점으로 남기기 위해 쓴다.

당시의 로컬 커머스 플랫폼은 이미 오래 운영된 시스템이었고, 한국 조직 안에서는 충분히 실전적인 복잡도를 갖고 있었다. 관리자 기능, 배치, 외부 연동, 결제와 정산, 고객센터용 도구, 실제 사용자 트래픽을 받는 웹 계층이 서로 맞물려 있었다. 코드만 보면 구조를 일부 따라갈 수는 있었지만, 실제로 무엇이 비즈니스상 중요하고 어느 순서로 봐야 하는지는 운영을 겪지 않으면 잡히지 않는 부분이 많았다.

여기에 O2O 성격의 운영 흐름도 함께 있었다. 당시 Nike는 O2O에 지속적으로 투자하고 있었고, 온라인에서 상품을 주문해 택배로 받거나 매장에서 수령하는 흐름을 모두 지원했다. 매장에 재고가 없으면 다른 매장 재고를 이동시켜 수령하거나 바로 택배로 전환하는 시나리오도 있었다. 문제는 이 과정에서 판매처, 매출 인식 주체, 재고 보유 주체가 분리되는 경우가 많아 정산과 재고 계산이 복잡해진다는 점이었다. 그래서 웹 운영은 단순 온라인 채널 관리가 아니라 앱-웹-매장 흐름이 끊기지 않도록 책임 경계를 유지하는 일이기도 했다.

동시에 이 플랫폼은 영구적으로 확장될 시스템이 아니라, 글로벌 플랫폼으로 넘어가기 전까지 한국 비즈니스를 버텨내야 하는 전환기의 시스템이기도 했다. 즉 당장 안정적으로 굴러가야 했고, 그 과정에서 축적한 이해가 나중에는 마이그레이션 판단의 근거가 되어야 했다. 운영 업무는 단순히 장애를 막는 일이 아니라, 앞으로 무엇을 남기고 무엇을 버릴지 판단할 수 있는 재료를 모으는 일이기도 했다.

초기 90일 운영 학습 흐름

Breeze 플랫폼의 전체 풍경

입사 초기에는 먼저 내부 운영 컴포넌트들이 어떤 역할을 맡고 있는지 큰 그림부터 그렸다. 당시에는 화면 하나를 깊게 보는 것보다, 상품 등록과 가격 운영을 담당하는 계층, 주기적 동기화와 정합성을 담당하는 배치 계층, 외부 시스템과 연결되는 연동 계층, 고객 응대를 위한 내부 도구, 실제 사용자 트래픽을 받는 웹 계층이 어떻게 묶여 있는지를 이해하는 편이 더 중요했다. 그래야 장애가 나도 문제를 “기능”이 아니라 “경계” 단위로 볼 수 있었기 때문이다.

이 큰 그림을 먼저 잡아두니 이후의 세부사항이 훨씬 빨리 들어왔다. 같은 주문 문제라도 어느 화면에서 시작됐는지보다 어떤 계층이 책임을 갖는지, 어떤 데이터가 어느 저장소를 통해 지나가는지가 먼저 보였고, 그 덕분에 질문의 수준도 달라졌다. 단순히 “왜 안 되지?”가 아니라 “이 문제는 공유 데이터 저장소 쪽 정합성 문제인가, 검색 인프라 반영 지연인가, 아니면 외부 연동 시스템 응답 문제인가?”처럼 사고할 수 있게 됐다.

배포 사이클의 이해

운영 적응에서 두 번째로 중요했던 것은 내부 배포 채널을 중심으로 흘러가는 정기 배포의 리듬을 익히는 일이었다. 커머스 운영에서는 코드를 아는 것만으로는 부족하고, 어떤 시점에 변경이 들어가며 누구의 확인을 거쳐 실제 트래픽에 반영되는지 알아야 한다. 배포 일정이 곧 조직의 리듬이고, 그 리듬을 모르면 좋은 변경도 위험한 변경이 된다.

특히 대형 이벤트가 예정된 주에는 배포 타이밍 자체가 기술 판단이 아니라 운영 판단이 되었다. 이벤트 직전에 기능을 넣지 않는 이유, 이벤트 이후에야 변경을 미루는 이유, 배포 전에 어떤 계층을 먼저 살펴야 하는지가 모두 트래픽과 매출, CS 부담과 연결돼 있었다. 이런 리듬을 몸으로 익히면서 “운영을 안다는 것”이 단순한 시스템 이해가 아니라, 시스템과 비즈니스가 만나는 접점을 이해하는 일이라는 걸 배웠다.

인시던트 대응의 경험

운영을 맡으며 가장 빠르게 학습하게 되는 순간은 결국 문제 상황이다. 검색 결과가 비정상적으로 보이거나, 결제 흐름이 흔들리거나, 배치 결과가 기대와 다르게 나오는 순간에는 평소에 추상적으로만 알던 구조가 매우 구체적인 책임 경계로 다가온다. 문제가 보이면 어디부터 확인해야 하고, 어떤 로그와 어떤 데이터 흐름을 먼저 봐야 하는지가 곧바로 실무 역량이 된다.

여기서 결정적인 것은 “빠른 해결”보다 “빠른 분류”였다. 문제가 내부 운영 컴포넌트 안쪽인지, 외부 연동 시스템에서 온 것인지, 검색 인프라 반영 문제인지 먼저 가르는 능력이 중요했다. 이 분류가 빨라질수록 대응 순서와 커뮤니케이션이 정리됐고, 운영자의 판단도 덜 흔들렸다. 입사 직후 운영을 맡는 경험은 결국 이 분류 체계를 몸에 익히는 시간이기도 했다.

글로벌 마이그레이션 준비와의 연결

운영은 시간이 지나면 자연스럽게 마이그레이션 준비와 연결됐다. 실제로 어떤 데이터가 어디서 생성되고, 어떤 배치가 정합성을 떠받치며, 어떤 화면이 비즈니스상 중요하고, 어떤 기능은 생각보다 대체 가능하다는 사실을 운영 과정에서 알게 됐기 때문이다. 나중에 글로벌 플랫폼으로 옮길 때 중요한 것은 단순한 화면 목록이 아니라, 로컬 플랫폼이 실제로 어떤 역할을 수행하고 있었는지 설명할 수 있는 능력이었다.

운영 경험이 쌓일수록 “이 기능을 글로벌에서는 무엇이 대체할까”, “이 배치는 정말 별도 구현이 필요한가”, “이 내부 도구는 운영 관점에서 어떤 역할을 해왔나” 같은 질문에 더 구체적으로 답할 수 있었다. 즉 입사 직후의 운영은 미래 작업을 잠식한 우회로가 아니라, 오히려 미래 작업을 가능하게 만든 가장 직접적인 학습 경로였다.

전략적 결정: 큰 피처를 만들지 않기

초기 적응이 어느 정도 끝난 뒤에는 자연스럽게 “무엇을 새로 만들 것인가”보다 “무엇을 만들지 않을 것인가”가 더 중요해졌다. 전환기가 예정된 시스템에서는 모든 기능 요청을 같은 무게로 받을 수 없고, 운영 안정성과 마이그레이션 준비를 해치지 않는 선에서 우선순위를 다시 정의해야 했다. 그래서 입사 직후 운영 이해는 단지 현재를 버티기 위한 작업이 아니라, 이후 전략 판단의 기준점을 마련하는 과정이기도 했다.

다음 글에서는 바로 그 지점, 즉 글로벌 마이그레이션이 예정된 상태에서 왜 큰 피처를 만들지 않는 선택이 합리적이었는지를 더 좁혀서 정리한다.

운영 적응의 기술적 의미

운영 적응은 단순한 온보딩이 아니라 아키텍처 해석 과정이었다. 장애 분류, 배포 리듬, 데이터 경계, 외부 연동 실패 패턴을 먼저 이해해야 이후 기술 판단의 정확도가 올라간다. 즉 “지식을 쌓는 시간”이 아니라 “실패 비용을 줄이는 시간”에 가까웠다.

이 접근의 장점은 의사결정의 일관성이 빨리 생긴다는 점이고, 단점은 단기적으로 신규 기능 가시성이 낮아 보일 수 있다는 점이다. 전환기 환경에서는 후자가 감수할 수 있는 비용이었고, 결과적으로 안정성과 이관 준비도를 높이는 선택이 됐다.

운영 적응 우선순위 매트릭스

기술 체크포인트

• 신규 기능 착수 전, 장애 분류 기준(데이터/검색/외부 연동)을 팀 공통 모델로 정리했다.
• 배포 리듬과 이벤트 일정 충돌 구간을 먼저 파악해 변경 위험을 낮췄다.
• 문제 대응은 “해결 속도”보다 “원인 경계 분류 속도”를 우선했다.