“왜 노출이 안 될까?”를 한 번에 추적하는 방법

이 게시물은 모듈유닛으로 구성된 매장 운영과 디버깅을 위한 내부 도구 '영원희'를 소개합니다.

문제

• 노출 및 데이터 정합성 이슈의 원인이 여러 전시 데이터와 후처리 로직의 결합으로 한곳에서 파악 불가

핵심 아이디어

• 요청 흐름을 하나의 식별자(logGroupId)로 묶어 시간 순서대로 수집·조회
• 로그 전송: 각 서비스 → Kafka 토픽 → Consumer 비동기 수집 → MongoDB 적재

설계 원칙

• 서비스 본래 로직에 미치는 영향 최소화(공통 처리 지점, 어노테이션 활용)
• 운영 기능 확장 및 다른 전시 서비스로의 확장 고려

버전별 발전

• 1.0: 모듈매장 중심의 요청/응답 로그 수집과 흐름 조회 중심
• 1.0 한계: 적용 범위 제한 및 직접 호출 불편
• 2.0: 전시 전반으로 범위 확장 및 Swagger 연동으로 화면에서 직접 API 호출·재현 가능

효과 및 활용

• 운영 대응 시간 단축, 누락 구간 추적 및 재현 기반 디버깅 가능
• 불필요한 API 호출 발견으로 성능 개선 및 비용 절감
• 오반장 대시보드·유효성 검증 기능 등으로 확장 활용

운영 제약

• 내부 IP에서만 접근 가능
• 로그는 1시간 보관 후 삭제