**(1). Kafka Consumer 운영: Lag 모니터링 + 에러 트래킹 품질 개선

(알림 노이즈 제거)** [ 노션 포트폴리오 링크 ]

• 문제: 컨슈머 상태/지연(Lag)을 사후에만 확인할 수 있어 장애 징후를 놓치기 쉬웠고, 예외 발생 시 Sentry 알림이 동일 래퍼 예외로 뭉개져 실제 원인/위치를 빠르게 특정하기 어려움 발생.
• 시도/해결:
  • Burrow 기반으로 컨슈머 Lag를 상시 수집,평가하고 Slack 알림을 자동화해 “직접 접근/수동 확인”을 제거
  • Kafka Interceptor로 메시지 처리 직전 MDC에 Topic/Partition/Offset/Key를 적재하고, Sentry(Logback Appender)/Slack으로 자동 전파되게 구성해 추적성을 강화
  • Sentry fingerprint를 Topic/Partition/Offset 기준으로 커스터마이즈하고, DefaultErrorHandler 확장으로 root cause를 남겨 **알림을 “하나의 원인 = 하나의 이슈”**로 정리
• 결과: 장애 인지 10분 미만, 복구/원인 파악 시간 60~70% 단축, 불필요한 알림 노이즈 감소, 에러 발생률 0% 유지 운영 품질 향상

(2). 병렬 배치 동시성/정합성: Redis 분산락으로 Silent Overwrite 제거

[ 노션 포트폴리오 링크 ]

• 문제: 멀티 환경 병렬 처리 중 읽기→계산→쓰기 타이밍 차이로 silent overwrite / 레이스 컨디션이 발생 락 획득 실패가 누적되며 운영 리스크 증가
• 시도/해결: [ 노션 링크 ]
  • Redis 기반 분산락을 설계/적용해 덮어씌움을 방지
  • 운영/개발 환경의 Redis 커넥션 풀 차이를 분석해 적정 사이즈 조정
• 결과: 배치 병렬 처리 중 락 획득 실패율을 100건/day → 2건/day → 0건/day로 개선해 정합성과 운영 안정성을 확보

(3). 야놀자 공급사 API 마이그레이션: 구 API 종료 대응 & 신규 API 전환(무중단)

[노션 링크]

• 문제

  • 구 API 종료 일정에 맞춰 서비스 중단 없이 신규 API로 전환해야 했고, 기존 구조상 외부 연동 로직이 한 곳에 모여 있어 변경 영향 범위가 커질 위험

  • 신규 API에서는 기존의 “캘린더(시설 1회 호출로 90일 요금 조회)” 방식이 사라지고 일자별 요금 조회를 90회 호출해야 하는 구조로 변경

  • 야놀자 매핑 시설(약 3,000개) 기준으로 3,000 × 90 = 270,000건 호출이 예상하며, 동시에 TPS 20 제한까지 존재해 Limit 리스크가 있었습니다.

    [캘린더/요금 조회 이슈 링크]

• 시도/해결

  • 전환 범위를 통제하기 위해 외부 연동 로직을 역할 기준으로 분리/모듈화하고, 예약/조회/취소 등 핵심 실시간 API 6종을 단계적으로 확장했습니다.

  • 호출 폭증 구간은 요청 분할 + TPS 제어(딜레이 기반)로 우선 안정화해 운영 리스크를 줄였고, 이후에는 RateLimiter + 백오프 재시도 + 모니터링 지표 기반 제어로 고도화 예정.

  • Static 데이터 동기화 배치 호출 구조 재 구성하여 다건 조회(10개 단위)로 전환하고, 알림/중복 실행 방지/부분 실패 허용 등 운영 요소를 함께 정비

    [배치 개선 링크]

  • Claude Code 활용 : 전환 작업용 커스텀 Skill을 직접 정의하고, 스펙 매핑 → 구현 체크리스트 → 테스트 시나리오/검증 가이드를 반복 보완하며 표준화 그 과정에서 AI를 코드 리뷰/테스트 관점의 동반자로 활용해 누락을 방지

• 결과

  • 실시간 핵심 API 6종 전환 완료, 운영 영향 없이 마이그레이션을 마무리
  • Static 배치 최적화로 API 호출 1000회 → 100회(90%↓), 예상 소요시간 ~50분 → ~5분(90%↓)로 단축
  • TPS 제약 구간 안정적인 운영