왜 노출이 안 되는지 한 번에 추적하는 방법

모듈매장과 코너 영역의 운영 이슈는 단일 API 응답만 봐서는 원인을 찾기 어렵다. 최종 화면은 전시 데이터, 내부 후처리 로직, 여러 서비스의 응답이 합쳐진 결과이기 때문이다.

문제를 추적하려면 보통

• 모듈 설정 확인
• 원천 데이터 저장 여부 확인
• 호출된 API의 요청값 확인
• 응답 데이터 검증
• 후처리 과정에서 제외·변경 여부 확인 을 모두 거쳐야 했고, 기존에는 DB 조회와 로그 확인, 소스 분석을 여러 시스템에서 직접 이어 붙여야 했다.

이 비효율을 줄이기 위해 만든 것이 내부 디버깅 서비스 **영원희(YoungWonHee)**다. 서비스 요청 시작 시 생성·전달되는 logGroupId를 중심으로 내부 API 호출, 세부 로직, 쿼리 조회의 로그를 함께 남기고, 이를 시간 순서대로 수집해 한 화면에서 볼 수 있게 했다. 로그는 Kafka Topic으로 전달되고, Consumer가 이를 받아 MongoDB에 적재한다.

설계의 핵심은 실제 서비스 로직에 부담을 주지 않는 것이다. 공통 처리 지점에서 로그를 남기고 어노테이션을 활용해 개별 서비스 변경을 최소화했으며, 처음에는 모듈매장 중심으로 시작해 코너 로직과 자주구매 등으로 점진적으로 확장했다.

영원희 1.0은 모듈매장 중심의 요청/응답 로그 수집, 요청 단위 흐름 조회, 시간 순서 기반 로그 확인, 데이터 누락 구간 추적에 집중했다. 다만 범위가 좁고, 디버그 모드에서 직접 진입하지 않으면 활용도가 떨어지는 한계가 있었다.

2.0에서는 범위를 전시 전반으로 넓히고, Swagger와 연동해 화면에서 직접 API를 호출할 수 있게 바꿨다. 이제는 단순히 쌓인 로그를 조회하는 도구가 아니라, 요청을 직접 재현하고 그 결과의 흐름까지 즉시 추적하는 실행형 디버깅 도구가 됐다.

도입 이후에는 다음 같은 효과가 생겼다.

• 노출 이슈에서 어느 단계에서 데이터가 사라졌는지 빠르게 확인
• API 응답 문제와 중간 변환, 최종 전시 가공 문제를 구분
• 동일 조건으로 직접 호출해 원인 범위를 좁히는 재현 디버깅 가능
• 반복 호출되는 불필요한 API를 찾아 성능 개선에 활용

현재 영원희는 내부 IP에서만 접근 가능하고, 1회 요청 로그는 1시간 후 삭제된다. 반복되는 운영 문의를 더 빨리 처리하고, 어디서부터 봐야 할지 모르는 상태를 줄이는 데 초점이 맞춰져 있다.