실제 사례: 메시지 큐 리스너 정지
- 큐 선언 실패 3번에 리스너 영구 정지
- 약 90시간 소비 정지, 경보 없음
- 지수 백오프 재선언, Slack 경보
- 최근 30일 선언 실패 279회에도 정지 0회
- 약 90시간 정지 → 0회
- 최근 30일 선언 실패 279회에도 영구 정지 0회
01 planning
기획을 받으면
기획안을 받으면 코드를 쓰기 전에, 이 기능이 비즈니스에 필요한지와 지금 방식이 맞는지부터 확인합니다.
- INPUT기획안기획자
- GATE판단비즈니스 임팩트
- 정말 필요한 기능인가
- 이 방식이 맞는가
아니라면 기획자와 다시 이야기합니다
- 01비즈니스 설계지금 인프라 구조 안에서
- 02DB 설계
- 03API 개발
02 with AI
AI 활용
설계와 검증은 제가 하고, 반복되는 구현은 Claude에게 맡깁니다.
01직접
설계는 직접
범위와 구조는 제가 정합니다. 프롬프트로 작업 범위를 적고, Claude가 정리한 개발 설계서(HTML)를 읽고 의도와 맞는지 확인합니다.
02Claude
반복 구현은 Claude로
설계서를 바탕으로 한 구현, 단위·통합 테스트 작성, PR 생성은 Claude에게 맡깁니다.
03직접
리뷰·테스트·e2e는 직접
PR을 직접 읽고, 테스트가 모두 통과했는지 확인하고, e2e를 직접 돌린 뒤 팀원에게 리뷰를 요청합니다.
- 아키텍처와 컨벤션을 지켰는가
- 의도한 비즈니스대로 구현됐는가
↩ 설계가 틀렸으면 설계부터 다시
03 incident
장애 대응
장애가 나면 원인을 찾아 고치고, 같은 문제가 다시 생기지 않게 구조를 바꾼 뒤 팀에 공유합니다.
- AI 보조Claude가 Grafana MCP로 로그를 먼저 정리
- 직접판단과 조치는 제가
01AI 보조
감지
알람과 매일 받는 로그 분석 리포트로 이상을 확인합니다.
- 알람
- 일간 리포트
02직접
영향 범위 파악
Loki 쿼리와 대시보드로 어디까지 영향이 있는지 봅니다.
- Loki
- Grafana
03AI 보조
원인 분석
로그와 메트릭으로 원인을 좁힙니다. 운영 DB에 직접 붙지 않고 읽기 전용 관측 경로를 씁니다.
- 로그
- 메트릭
04직접
조치·복구
원인에 맞게 조치하고 서비스를 정상으로 돌립니다.
05직접
재발 방지
구조를 고치고 테스트로 같은 문제를 다시 확인합니다.
- 구조 개선
- 테스트
06직접
팀 공유
원인과 조치를 팀에 공유합니다.
매일 전날 에러 로그를 확인합니다
Grafana MCP로 Claude가 Loki에서 전날 에러 로그를 모아 문제점과 해결 방안을 HTML 리포트로 정리하면, 제가 읽고 판단해 조치합니다.
- 일간전날 에러 로그, 문제점과 해결 방안
- 주간최근 7일과 직전 7일 비교: 새로 생긴 예외, 사라진 예외, 요일별 패턴