AI 파이프라인 단계별 로그와 Prometheus 지표 추가

[hywznn]

왜 필요한가요?

Refs #26

FOWOCO의 PLAN → Slot 조회 → ANALYZE → Renewal → 문서 생성 흐름에서 어느 구간이 얼마나 걸리고 왜 실패했는지 Server 기준으로 확인하기 위한 변경입니다.

데모 발표에서 단순 체감이 아니라 단계별 소요시간·성공 결과·실패 원인을 반복 측정할 수 있도록 하되, 발화문과 개인정보는 로그와 Metric tag에 남기지 않습니다.

무엇이 바뀌나요?

• AiRun에 PLAN_RUNTIME_CALL, SLOT_RESOLUTION, ANALYZE_RUNTIME_CALL, RESULT_PERSIST, TOTAL 계측을 추가했습니다.
• 기존 Renewal 단계 로그에 Micrometer Timer와 실패 Counter를 연결했습니다.
• requestId·attemptId는 구조화 로그에서만 사용하고 Metric tag에는 포함하지 않습니다.
• 분석 Outcome과 안전한 오류 코드별 Counter를 추가했습니다.
• micrometer-registry-prometheus와 /actuator/prometheus를 구성했습니다.
• 지표 endpoint는 기본 환경에서 인증 없이 열리지 않으며, observability & !prod 프로필에서만 공개됩니다.
• 로컬 Prometheus Compose·scrape 설정·PromQL·10회 반복 측정 가이드를 추가했습니다.
• 개발 가이드·배포 Runbook·프로젝트 구조 문서에 실행법과 Server/Infra 소유권을 연결했습니다.
• Flyway 및 DB Schema 변경은 없습니다.

주요 Metric

• fowoco_ai_pipeline_stage_seconds
• fowoco_ai_analysis_outcomes_total
• fowoco_ai_pipeline_failures_total
• fowoco_renewal_stage_seconds
• fowoco_renewal_failures_total

검증

• ./gradlew clean test — GitHub CI 557 tests 성공
• PLAN→Slot→ANALYZE 단계별 지표 통합 테스트
• OUT_OF_SCOPE에서 Slot·ANALYZE가 기록되지 않는지 검증
• 실패 로그에 발화문·실명·문서번호가 남지 않는지 검증
• 기본 프로필에서 /actuator/prometheus가 보호되는지 검증
• observability 프로필에서 Prometheus 형식 지표가 노출되는지 검증
• docker compose -f compose.observability.yml config
• 실제 Prometheus 컨테이너 scrape — 로컬 Docker Desktop이 꺼져 있어 PR 작성 시점에는 미실행

자체 리뷰 결과

• 운영 prod 프로필에서는 observability를 함께 지정해도 공개 Security Chain이 생성되지 않도록 보완했습니다.
• 중첩된 실패가 어느 단계에서 기록됐는지 알 수 있도록 실패 Counter에 제한된 phase·stage tag를 추가했습니다.
• Metric 등록 장애가 실제 업무 처리 실패로 이어지지 않도록 계측 실패를 격리했습니다.
• ID·실명·연락처·발화문·Slot 값은 Metric tag에 사용하지 않음을 코드와 문서에서 확인했습니다.
• 첫 CI에서 기존 Approval 동시성 테스트가 일시 실패했지만 코드 변경 없이 재실행하여 전체 성공을 확인했습니다.

리뷰 시 확인할 부분

• 단계 경계가 정량 평가 목적에 맞는지
• observability 프로필 공개 정책이 로컬 측정 범위에 적절한지
• Renewal 기존 로그에서 taskId를 제거한 개인정보·고카디널리티 기준이 적절한지
• 개발·배포 문서의 Server/Infra 관측 경계가 실제 운영 방향과 맞는지

[krestar]

로컬 Docker 환경에서 Prometheus 정상 작동 확인했습니다.
observability 프로필 범위와 prod 보호, metric tag 및 민감정보 처리도 확인했고 별도 block 이슈는 없어 보입니다 👍