Payment logging flag

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

왜 런타임 로깅 전환이 필요했나

이 작업이 기록할 가치가 있는 이유는 기술적 구현보다 전파 전략에 있다. 공통 결제 라이브러리에 기능을 추가하고, 공통 결제 클라이언트 라이브러리를 거쳐, 3개 워커 서비스에 순차적으로 적용한 전파 과정이 7일(4월 24~30일) 만에 이루어졌다. 1개 라이브러리 변경이 어떻게 6개 서비스에 안전하게 전파되는지를 보여주는 사례다.

재배포 방식의 한계는 무엇이었나

결제 서비스에서 프로덕션 이슈가 발생하면 디버깅을 위해 더 상세한 로그가 필요하다. 하지만 항상 상세 로그를 남기면 로그 볼륨이 과도하게 커지고, 성능에도 영향을 줄 수 있다. 필요할 때만 상세 로깅을 켜고 끌 수 있어야 한다.

기존에는 로그 레벨을 바꾸려면 설정을 변경하고 서비스를 재배포해야 했다. 프로덕션 이슈 상황에서 재배포는 부담이 크다 — 이슈를 조사하면서 동시에 배포 리스크를 감수해야 한다. 런타임에 로그 레벨을 전환할 수 있다면, 이슈 조사에만 집중할 수 있다.

핵심 체크포인트

• 4월 19일 전후: 각 결제 워커 서비스에 공통 클라이언트 라이브러리 적용과 필수 런타임 보완이 먼저 들어갔다.
• Day 1 (4/24): 공통 결제 라이브러리에 logging flag 핵심 기능을 구현했다.
• Day 2 (4/25): 공통 결제 클라이언트 라이브러리에 이를 연결했다.

기능을 여러 서비스에 어떻게 전파했나

2024년 4월 24일, 공통 결제 라이브러리에 Payment logging flag 기능을 구현했다. 핵심은 특정 API endpoint나 설정을 통해 런타임에 로깅 수준을 DEBUG/INFO/WARN 등으로 전환할 수 있는 메커니즘이다.

공통 결제 라이브러리에 구현한 이유는 이 라이브러리가 모든 결제 서비스의 공통 기반이기 때문이다. 여기에 한 번 구현하면 이 라이브러리를 사용하는 모든 서비스에서 같은 방식으로 동작한다. 서비스마다 개별 구현하면 방식이 달라지고 유지보수가 어려워진다.

2024년 4월 25일, 공통 결제 클라이언트 라이브러리에도 logging flag를 적용했다. 공통 결제 클라이언트 라이브러리는 결제 서비스들이 공통으로 사용하는 클라이언트 라이브러리로, 공통 결제 라이브러리 위에 구축되어 있다. 공통 결제 라이브러리의 logging flag 기능을 공통 결제 클라이언트 라이브러리 수준에서도 활용할 수 있도록 연동했다.

이 단계에서 logging flag의 전파 구조가 확정되었다: 공통 결제 라이브러리 (핵심 메커니즘) → 공통 결제 클라이언트 라이브러리 (클라이언트 레벨 연동) → 각 워커 서비스 (최종 적용). 계층적 전파다.

로깅 플래그 예시 코드

런타임 로깅 플래그는 TTL을 둔 임시 활성화로 운영하면, 디버깅 후 자동 복귀가 가능하다.

paymentLogging:
  enabled: true
  level: DEBUG
  ttlMinutes: 15
  scope:
    - approval-worker
    - gateway-worker

public boolean isVerboseEnabled(String service) {
    return config.enabled() && !config.isExpired() && config.scope().contains(service);
}

전파 가능한 운영 기능이 남긴 기준

logging flag는 단순한 디버깅 편의 기능이 아니었다. 한 번의 라이브러리 변경으로 여러 서비스를 같은 운영 방식 아래 묶을 수 있다는 점을 보여줬고, 이후 공통화 작업을 평가할 때도 “전파 가능한가”가 중요한 기준이 됐다.

다음 글에서는 이렇게 공통 기능을 전파하는 흐름과 별개로, 외부 벤더 변화에 의해 강제로 따라가야 했던 변경들을 이어서 다룬다.