[FEAT] Learning-Activity 메트릭 설정

[dlxodus02]

📊 개발 단계 및 우선순위

해당하는 우선순위에 체크해 주세요.

• P0 : 서비스 핵심 동작
• P1 : 운영 및 확장 기능
• P2 : 부가적인 고도화 기능

🎯 도메인 연관 관계 및 완료 조건 (Definition of Done)

이 이슈가 완료되기 위해 충족해야 하는 조건들을 나열해 주세요.

• 연관 도메인 : learning_activity
• 설명 : 영상 재생/완료 처리 흐름에 성공/실패를 집계하는 운영 metric이 없어, 장애(수강권 검증 실패, 완료 조건 미충족 등)가 얼마나 자주 발생하는지 사후에 로그를 뒤지지 않으면 알 수 없다. study_timer.session.result에 적용한 것과 동일한 패턴(성공/실패 카운터 + errorCode 태그)을 적용한다.
• CompleteVideoService, VideoAccessService.validatePlayable(), GetCourseProgressService 3곳의 성공/실패가 카운터로 집계된다.
• 실패 시 어떤 ErrorCode로 실패했는지 구분해서 집계할 수 있다 (VIDEO_COMPLETION_CONDITION_NOT_MET, COURSE_NOT_PUBLISHED, ENROLLMENT_REQUIRED, VIDEO_NOT_FOUND 등).
• metric 기록 로직 자체에서 예외가 나도 핵심 트랜잭션(진도 저장 등)에는 영향이 없다.
• (결정 필요) 공유 레코더 컴포넌트를 새로 만들지(study_timer.session.result처럼 learning_activity.access.result 전용 컴포넌트), 아니면 서비스 3곳에 인라인으로 직접 기록할지 — 어느 쪽으로 갈지 PR 리뷰에서 확정.
• Grafana/Prometheus 대시보드에서 조회 가능한지 확인.

💻 상세 작업 내용

클린 아키텍처(Clean Architecture) 구조에 맞춰 작업이 발생하는 계층에 체크하고 세부 내용을 작성해 주세요.

• Model / Policy: 해당 없음 (도메인 로직 변경 없음)
• UseCase / Command: 해당 없음
• Service: CompleteVideoService, VideoAccessService, GetCourseProgressService에 성공/실패 metric 기록 추가 (study_timer 도메인에 적용한 try/finally + errorCode 패턴 재사용)
• Port / Adapter: 해당 없음
• Repository: 해당 없음
• Controller: 해당 없음
• response / request: 해당 없음 (응답 스펙 변경 없음)

🚨 검증 및 예외 처리 (TestCode)

정상 작동뿐만 아니라, 잘못된 값이나 예외 상황에 대한 처리를 꼼꼼히 확인해 주세요.

• 각 서비스 성공 시 성공 카운터가 1 증가하는지 검증
• 각 서비스 실패(BusinessException) 시 실패 카운터가 1 증가하고 에러코드별로 구분되는지 검증
• repository.save()(또는 동급 저장 호출) 직전이 아니라 성공 반환 지점 이후에 success 플래그가 세팅되는지 확인 — PR #255에서 발견된 "save 실패가 성공으로 집계되는" 버그 재발 방지
• metric 기록 로직에서 예외가 발생해도 핵심 로직(진도 저장 등)은 정상 커밋되는지 검증

🔗 참고 자료

• 동일 패턴 적용 사례: PR feature 순공시간 세션 재게 #253(feature/study-timer-resume), PR feature 스터디 타이머 메트릭 설정 #255(feature/study-timer-metric)
• 관련 CodeRabbit 코멘트: PR feature 순공시간 세션 재게 #253 코멘트(운영 metric 부재 지적)