Skip to Content
BackendSNKRS App KakaoPay 활성화
💻 Backend2023년 7월 12일

SNKRS App KakaoPay 활성화

#e-commerce#payment-expansion#backend#kakaopay
Payment Expansion · Series 2 · Integration Rollout6 / 15Backend
SNKRS App에서 KakaoPay를 활성화하며 공통 라이브러리 전파 패턴을 확인한 작업이다.

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

이 글에서 말하는 KakaoPay도 KakaoPay 자체 서비스가 아니라, Nike Payment 시스템 안에서 채널별로 제어하던 KakaoPay 연동 서비스를 뜻한다.

왜 채널 확장이 중요했나

Nike의 결제 서비스는 채널(channel)별로 사용 가능한 결제수단을 제어하고 있었다. Nike.com 웹사이트는 하나의 채널이고, SNKRS App은 다른 채널이다. KakaoPay는 Nike.com에서 활성화되어 있었지만 SNKRS App에서는 비활성 상태였다.

사이트와 앱의 차이는 무엇이었나

SNKRS App은 한정판 스니커즈 구매에 특화된 앱으로, 결제 속도가 특히 중요하다. The Draw(추첨 구매) 같은 이벤트에서는 수만 명이 동시에 결제를 시도한다. KakaoPay 활성화는 비즈니스 요구사항이었다.

핵심 체크포인트

  • 2023년 상반기 말: 공통 결제 라이브러리에서 SNKRS App 채널에 KakaoPay를 활성화하는 설정을 추가했다.
  • 같은 설정 구조를 활용하면 특정 채널, 특정 환경, 심지어 디버깅 앱에서만 결제수단을 열어두는 식의 제어도 가능했다.
  • 변경 자체는 작았지만, 이 라이브러리를 사용하는 여러 서비스가 함께 버전을 올려야 한다는 점에서 운영 영향은 작지 않았다.
  • 이 작업은 “공통 라이브러리 1곳의 설정 변경으로 여러 서비스의 동작을 제어한다”는 패턴이 실제로 유효하다는 것을 보여준 첫 사례였다.
  • 반대로 말하면 이 설정을 잘못 건드리면 여러 서비스와 여러 채널에 동시에 영향을 주면서 전체 장애로 이어질 수도 있었다.

설정 한 줄이 왜 배포 문제였나

2023년 상반기 말, 공통 결제 라이브러리에서 SNKRS App 채널에 KakaoPay를 활성화하는 설정을 변경했다.

변경 자체는 매우 작았다. 채널별 결제수단 매핑 설정에 SNKRS 채널용 KakaoPay 항목을 추가하는 것이 전부였다. 하지만 이 변경이 공통 결제 라이브러리를 사용하는 여러 워커 서비스에 반영된다는 점이 중요했다. 라이브러리 버전을 올리고 각 워커 서비스를 다시 빌드하고 배포해야 했다.

장점도 분명했다. 같은 설정 구조를 이용하면 테스트 환경에서만 특정 결제수단을 열거나, 채널별로 노출 범위를 다르게 가져가거나, 디버깅 앱에서만 우선 활성화하는 식의 제어가 가능했다. 그래서 실제로도 여러 채널/환경 조합으로 나눠가며 테스트해볼 수 있었다. 즉 기능 활성화뿐 아니라 점진적 검증과 운영 통제에도 유용한 구조였다.

하지만 위험도 컸다. 공통 라이브러리 설정 하나가 여러 서비스와 채널에 동시에 퍼지기 때문에, 잘못된 값이나 잘못된 매핑이 들어가면 특정 앱 채널 문제로 끝나지 않고 전체 결제 흐름에 영향을 줄 수 있었다. 그래서 이 작업은 단순 설정 변경처럼 보여도 실제로는 배포 순서와 검증 범위를 함께 관리해야 하는 변경이었다.

이 작업은 ‘공통 라이브러리 1곳의 설정 변경으로 여러 서비스의 동작을 제어한다’는 패턴의 첫 번째 사례였다. 이후 logging flag 전파 작업에서 같은 패턴을 더 체계적으로 적용했다.

차이가 있다면, SNKRS KakaoPay 활성화는 ‘정적 설정 변경’이었고, Payment logging flag는 ‘런타임 동적 제어’였다는 점이다. 전자는 빌드/배포 시 확정되지만, 후자는 운영 중에 on/off를 전환할 수 있다. 같은 패턴이지만 진화한 형태다.

채널별 매핑부터 수정했다

웹 채널과 앱 채널에서 어떤 결제수단을 열지 설정 기준을 먼저 맞췄다.

공통 라이브러리 버전을 올렸다

설정 변경이 포함된 라이브러리를 사용하는 서비스들이 같은 버전을 보도록 맞췄다.

채널 동작을 다시 검증했다

앱 채널에서 KakaoPay가 실제로 노출되고 결제 흐름이 깨지지 않는지 확인했다.

공통 설정 리스크를 함께 봤다

테스트 환경과 특정 채널만 제어할 수 있는 장점이 있는 대신, 설정 오입력이 여러 서비스에 동시에 퍼질 수 있는 위험도 같이 확인했다.

채널 설정 예시 코드

채널별 활성화는 공통 라이브러리 설정으로 통제하고, 웹/앱 채널과 이벤트성 흐름을 분리해 점진적으로 열어가는 방식으로 운영할 수 있다.

yaml
sample/channel-payment-toggle.yaml
payment: environments: debug_app: kakaopay: true channels: nike_web: kakaopay: true nike_app: kakaopay: false snkrs_app: kakaopay: true storedPayment: true rolloutPercent: 20 experiences: launch: kakaopay: true storedPayment: true draw: kakaopay: true storedPayment: true autoChargeOnWin: true

채널 확장이 공통화 문제로 바뀌는 순간

SNKRS App 활성화는 작은 설정 변경처럼 보였지만, 실제로는 공통 라이브러리의 변경이 채널 정책과 배포 순서까지 함께 움직인다는 사실을 드러낸 작업이었다. 이후 Payment 시리즈에서 반복되는 “한 곳을 고치면 여러 서비스가 따라온다”는 감각이 여기서 더 선명해졌다.

다음 글에서는 이런 확장 작업을 더 이상 누적만 하지 않고, 왜 KakaoPay v2를 새로 구축해야 했는지로 넘어간다.

Last updated on