Fiserv AAA 제거 + NaverPay 도메인 변경

벤더(Fiserv, NaverPay) 측의 변화에 따라 기존 코드를 정리하거나 수정해야 했던 경험을 기록한다. Fiserv settlement endpoint 폐기와, 예전 Nike AAA 인증 체계에서 OAuth 체계로 넘어가며 정리된 인증 코드 제거, 그리고 NaverPay의 개발 환경 API 도메인 변경 대응이다. 이 두 작업은 시기와 성격이 다르지만, ‘외부 변화에 의해 주도되는 코드 변경’이라는 공통점이 있다.

왜 벤더 변화 대응을 따로 남기나

결제 시스템에서 벤더 의존성은 불가피하다. 벤더가 API를 변경하거나 기능을 폐기(deprecate)하면 연동 서비스도 따라가야 한다. 이 글은 그런 변경이 어떤 형태로 오고, 어떻게 대응했는지를 기록한다.

어떤 종류의 외부 변경이 들어왔나

결제 서비스는 외부 벤더(KakaoPay, NaverPay, Fiserv)의 API에 의존한다. 벤더가 API를 변경하면 우리 코드도 변경해야 한다. 문제는 벤더 변경이 항상 충분한 사전 공지와 함께 오지 않는다는 것이다. 때로는 사전 공지 없이 도메인이 바뀌거나, 짧은 공지 기간으로 기능이 폐기되기도 한다.

이 페이지에서 다루는 두 사례는 모두 벤더가 주도한 변경이다. Fiserv는 settlement endpoint를 폐기하면서 관련 코드 제거를 요청했고, NaverPay는 개발 환경 API 도메인을 변경했다. 같은 시기에는 전체 Payment 서비스의 빌드 인증 체계 변경 일괄 대응도 함께 진행되고 있었다.

핵심 체크포인트

• 기능 폐기(Deprecation): Fiserv settlement endpoint 폐기 → 관련 코드 제거. 비교적 사전 공지가 충분하고, 제거할 코드의 범위가 명확하다.
• 인프라 변경(Infrastructure): 빌드 인증 체계 변경 → 6개 저장소 일괄 대응. 전사적 변경이라 공지는 있지만, 대응해야 할 서비스가 많아 작업량이 크다.
• API 변경(API Change): NaverPay 도메인 변경 → URL 설정 수정. 벤더별로 공지 수준이 다르고, 예측 불가능한 시점에 발생할 수 있다.

영향 범위를 어떻게 줄였나

2024년 4월 3일, 결제 연동 서비스에서 Fiserv AAA 코드를 제거했다. Fiserv는 Nike의 글로벌 결제 파트너 중 하나로, 신용카드 결제 처리를 담당한다. settlement endpoint는 거래 정산(settlement) 관련 API였는데, Fiserv가 이를 폐기하기로 결정했다.

여기서 말하는 AAA는 일반적인 Authorization, Authentication, Accounting 약어 설명보다, 예전 Nike 내부 인증 체계에 더 가까웠다. 사내 서비스끼리 통신하려면 앱이 인증되어야 했고, 예전에는 그 경로를 AAA로 처리했다. 이후 내부 호출 인증 체계가 OAuth 중심으로 전환되었고, 지금은 Okta를 통해 OAuth 인증을 처리한다. Fiserv 연동 경로도 한동안 이 AAA 체계를 쓰고 있었지만, settlement endpoint가 폐기되고 인증 체계도 OAuth로 넘어가면서 더 이상 유지할 이유가 줄어들었다. 결국 그 호출 흐름에 묶여 있던 AAA 코드도 함께 정리할 수 있게 되었고, 불필요한 인증 경로를 남겨두지 않도록 제거했다.

이 변경은 한국 팀만의 작업이 아니라 글로벌 결제 방향 변화에 맞춰 각 지역 서비스가 함께 따라간 사례였다. 즉 로컬 판단으로 추가한 코드가 아니라, 더 이상 유지할 필요가 없는 경로를 글로벌 기준에 맞춰 걷어낸 작업에 가까웠다.

같은 시기에는 여러 저장소에 빌드 인증 체계 변경 대응이 함께 들어갔다. 결제 연동 계층과 여러 워커 서비스가 거의 동시에 영향을 받았다는 점에서, 외부 변화가 단일 저장소 문제가 아니라는 사실이 더 선명하게 드러났다.

설정 분리 예시 코드

벤더 변경 대응은 endpoint 설정을 외부화하고, 미사용 경로는 명시적으로 제거하는 방식이 안전하다.

vendors:
  naverpay:
    baseUrl: https://api.naverpay.example
  fiserv:
    settlementEnabled: false

if (!config.fiserv().settlementEnabled()) {
    router.disable("fiserv-settlement");
}
router.updateBaseUrl("naverpay", config.naverpay().baseUrl());

벤더 변화에 끌려가지 않으려면

외부 벤더 변화는 피할 수 없지만, 대응 방식까지 벤더에 끌려갈 필요는 없다. 기능 폐기와 도메인 변경처럼 성격이 다른 변화도 결국은 영향 범위를 빨리 파악하고, 제거할 것과 유지할 것을 분명히 가르는 운영 기준이 있어야 대응 속도가 나온다.

이 글까지가 Payment Expansion 시리즈의 마지막 운영 안정화 구간이다. 앞선 글들이 확장과 재구축의 흐름이었다면, 마지막은 그 구조를 실제 운영 변화 속에서 버텨내는 방법으로 마무리된다.