공통 라이브러리의 로깅 플래그를 결제 서비스에 적용하기

결제 문제를 조사할 때는 평소보다 자세한 로그가 필요할 수 있습니다. 반대로 모든 요청의 상세 로그를 항상 남기면 로그량과 처리 비용이 늘어납니다. 필요한 때 로깅을 조절할 수 있도록 공통 결제 라이브러리에 logging flag를 추가하고, 이를 사용하는 서비스에 적용했습니다.

이 작업은 공통 라이브러리 한 곳을 수정한 뒤 끝나는 변경이 아니었습니다. 중간 클라이언트 라이브러리와 개별 서비스의 의존성까지 올라가야 실제로 사용할 수 있었습니다.

공통 계층에서 시작한 이유

같은 기능을 서비스마다 따로 넣으면 설정 방식과 동작이 달라질 수 있습니다. 공통 결제 라이브러리에 기능을 두고, 서비스들이 사용하는 클라이언트 라이브러리에서도 이를 사용할 수 있도록 연결했습니다.

적용 흐름은 다음과 같았습니다.

공통 결제 라이브러리
    → 공통 결제 클라이언트 라이브러리
        → 각 결제 서비스

라이브러리의 기능 추가와 서비스를 통한 사용 가능 여부를 나눠 확인해야 했습니다. 아래 계층에서 기능을 제공하더라도 서비스가 이전 버전을 사용하면 변경이 전달되지 않습니다.

라이브러리와 워커 적용 순서

당시 기록에서 확인되는 주요 변경은 다음과 같습니다.

4월 19일의 준비 작업과 4월 30일의 플래그 적용은 구분해야 합니다. 클라이언트 라이브러리를 사용하기 시작한 날과 새 로깅 기능이 들어간 날이 같지는 않았습니다.

전체 작업은 공통 라이브러리의 변경을 여섯 서비스로 전달한 이력으로 정리돼 있습니다. 위 표는 그중 라이브러리 계층과 세 워커의 적용 기록을 기준으로 정리했습니다.

기능 추가 이후의 확인

서비스 적용 여부를 확인할 때는 소스의 의존성 선언만 봐서는 부족합니다. 빌드 결과에 새 라이브러리가 포함됐는지, 그 버전이 실제로 실행 중인지까지 확인해야 합니다.

로깅 기능 자체도 적용 범위를 확인해야 합니다. 플래그를 바꿨을 때 어떤 로그가 추가되는지, 설정을 되돌리면 원래 상태로 돌아오는지, 결제 요청과 응답의 민감한 값이 섞이지 않는지 살펴봐야 합니다.

특정 로그의 출력 여부를 플래그로 제어하는 것과 로그 프레임워크의 레벨을 바꾸는 것은 서로 다른 방식입니다. 어떤 방식을 사용하든 설정의 적용 대상과 해제 동작을 확인해야 합니다.

변경 완료의 범위

여러 서비스가 공통 라이브러리를 사용하면, 라이브러리 릴리스 이후에도 적용할 곳이 남습니다. 이번 작업에서도 라이브러리 수정, 클라이언트 연결, 개별 서비스 적용을 나눠 진행하고 전체 완료를 확인했습니다.

이 순서를 구분해 두면 다음 변경에서도 어느 서비스까지 반영됐는지 확인하기 쉽습니다. 공통 코드를 수정한 뒤에도 각 운영 서비스에 적용됐는지까지 확인해야 했습니다.