이전 페이지에서는 성능, 보안, 권한 점검 기준을 정리했습니다. 이번 페이지에서는 서비스가 실행 중일 때 운영자가 무엇을 보고 상태를 판단할지 정합니다. 기능이 동작하고 테스트가 통과해도, 운영 중 장애를 발견하고 원인을 추적할 수 없다면 실전 서비스라고 보기 어렵습니다.
운영 관점에서 중요한 것은 "로그를 많이 남긴다"가 아닙니다. 구매자가 주문을 못 하는지, 결제가 실패하는지, admin이 주문을 못 보는지, 챗봇이 잘못된 응답을 하는지 판단할 수 있어야 합니다. 즉 로그와 모니터링은 개발자의 디버깅 도구이면서 운영자의 의사결정 도구입니다.
이번 페이지의 목표는 장애가 발생했을 때 어디부터 봐야 하는지, 어떤 지표가 나빠지면 위험 신호인지, 릴리스 전후에 무엇을 확인해야 하는지 운영 점검표로 정리하는 것입니다.
운영 관찰성은 배포 직전에 급히 붙이면 빈틈이 많아집니다. 이미 구매, 주문, 결제, admin, 챗봇 흐름을 만들었기 때문에 지금이 어떤 이벤트와 지표가 필요한지 정리하기 좋은 시점입니다.
- 주문 생성 실패가 늘어나는지 알아야 한다
- 결제 실패가 외부 문제인지 내부 문제인지 구분해야 한다
- admin 조회 실패가 권한 문제인지 서버 문제인지 알아야 한다
- 챗봇 실패가 RAG 검색 실패인지 LLM 호출 실패인지 구분해야 한다
- 배포 후 오류율이 올라갔는지 확인해야 한다
이 정보를 볼 수 있어야 운영자는 감이 아니라 근거로 대응할 수 있습니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
- 어떤 이벤트를 로그로 남길 것인가
- 로그에는 어떤 필드를 포함하고 어떤 필드는 제외할 것인가
- 어떤 지표를 대시보드에서 볼 것인가
- 어떤 상황에서 알림을 받을 것인가
- 장애가 발생하면 어떤 순서로 확인할 것인가
- 릴리스 전후 운영 점검표는 무엇인가
로그의 목적은 세 가지입니다.
- 장애 재현
- 사용자 문의 대응
- 보안과 권한 문제 추적
따라서 로그는 "무슨 함수가 호출됐다"보다 "어떤 업무 이벤트가 어떤 결과로 끝났는가"를 남겨야 합니다. 예를 들어 create_order called보다 order_create_failed가 더 운영적으로 의미 있습니다.
모든 로그에 공통으로 들어가면 좋은 필드는 아래입니다.
- timestamp
- request_id
- actor_id
- actor_role
- event_name
- result
- status_code
- duration_ms
- resource_type
- resource_id
request_id는 특히 중요합니다. 프론트 오류, 백엔드 로그, 외부 결제 호출, 챗봇 응답을 하나의 흐름으로 묶어 추적할 수 있기 때문입니다.
운영 로그에 민감 정보를 그대로 남기면 나중에 더 큰 문제가 됩니다.
남기지 말아야 할 정보는 아래입니다.
- 비밀번호
- 인증 토큰
- 결제 수단 원문
- 전체 배송 주소
- 전체 전화번호
- LLM 프롬프트 전체
- 상담 대화 원문 전체
필요하다면 ID, 마스킹된 값, 요약, 실패 유형만 남깁니다. 로그는 문제를 찾는 도구이지 개인정보 저장소가 아닙니다.
구매자 흐름에서는 주문 전환과 실패 지점을 확인할 수 있어야 합니다.
우선 남길 이벤트는 아래입니다.
- product_list_viewed
- product_detail_viewed
- cart_item_added
- cart_quantity_changed
- checkout_started
- order_created
- payment_confirmed
- payment_failed
- order_completed
모든 클릭을 남길 필요는 없습니다. 하지만 구매 퍼널의 핵심 단계는 남겨야 사용자가 어디에서 막히는지 볼 수 있습니다.
운영자 화면은 권한과 변경 추적이 중요합니다.
우선 남길 이벤트는 아래입니다.
- admin_login_succeeded
- admin_login_failed
- admin_order_list_viewed
- admin_order_detail_viewed
- admin_product_updated
- admin_access_denied
- admin_api_failed
특히 상품 가격, 재고, 판매 상태 변경은 누가 언제 무엇을 바꿨는지 추적할 수 있어야 합니다.
챗봇은 실패 원인을 나눠서 봐야 합니다.
우선 남길 이벤트는 아래입니다.
- chat_message_received
- chat_intent_classified
- chat_retrieval_succeeded
- chat_retrieval_failed
- chat_domain_lookup_denied
- chat_llm_succeeded
- chat_llm_failed
- chat_handoff_requested
챗봇 로그에서 중요한 것은 답변 문장 전체가 아니라, 어떤 근거를 찾았고 어떤 이유로 실패했는지입니다.
지표는 운영자가 현재 상태를 빠르게 판단할 수 있게 해야 합니다.
핵심 지표는 아래입니다.
- API 요청 수
- API 오류율
- API p95 응답 시간
- 주문 생성 성공 수
- 주문 생성 실패 수
- 결제 성공률
- 결제 실패율
- admin API 오류율
- 챗봇 handoff 비율
- LLM 호출 실패율
처음부터 복잡한 지표를 많이 만들기보다, 서비스 생존과 구매 흐름을 판단할 수 있는 지표부터 봅니다.
화면마다 봐야 하는 지표가 다릅니다.
storefront에서는 아래가 중요합니다.
- 상품 목록 응답 시간
- 장바구니 변경 실패율
- 주문 생성 실패율
- 결제 실패율
admin에서는 아래가 중요합니다.
- 로그인 실패율
- 주문 목록 응답 시간
- 상품 수정 실패율
- 권한 거부 이벤트 수
챗봇에서는 아래가 중요합니다.
- 평균 응답 시간
- RAG 검색 실패율
- LLM 실패율
- handoff 비율
- 권한 거부 응답 수
알림은 너무 많으면 무시되고, 너무 적으면 장애를 놓칩니다. MVP에서는 아래 기준으로 시작할 수 있습니다.
- 5분 동안 API 5xx 오류율이 기준 이상
- 주문 생성 실패가 연속 발생
- 결제 실패율이 평소보다 급증
- admin 로그인 실패가 반복 발생
- LLM 호출 실패가 연속 발생
- DB 연결 실패 발생
알림 기준은 처음부터 완벽할 필요는 없지만, 구매와 결제 실패는 빠르게 알 수 있어야 합니다.
장애가 발생하면 아래 순서로 확인합니다.
- 어떤 사용자 흐름이 실패했는지 확인한다
- 최근 배포가 있었는지 확인한다
- API 오류율과 응답 시간을 본다
- request_id로 관련 로그를 찾는다
- DB 또는 외부 API 실패 여부를 본다
- 임시 우회 또는 롤백 필요 여부를 판단한다
- 재현 절차와 조치 결과를 기록한다
이 순서가 있어야 장애 대응이 사람마다 달라지지 않습니다.
주문 생성 실패가 늘어난 경우에는 아래를 확인합니다.
- 주문 생성 API의 오류율을 본다
- 실패 로그에서 error_type을 확인한다
- 재고 검증 실패인지 결제 전 단계 실패인지 구분한다
- DB 쓰기 실패가 있는지 확인한다
- 동일 상품에서만 발생하는지 확인한다
- storefront 오류 메시지가 사용자에게 적절히 보이는지 확인한다
주문은 매출과 직접 연결되므로 가장 먼저 런북을 가져야 하는 흐름입니다.
결제 실패가 늘어난 경우에는 아래를 확인합니다.
- payment_failed 이벤트 수를 본다
- 외부 결제 mock 또는 PG 연동 상태를 확인한다
- 주문 상태와 결제 상태가 불일치하는 건을 찾는다
- 재시도 가능한 실패인지 운영자 확인이 필요한 실패인지 구분한다
- 사용자에게 보여주는 실패 메시지를 확인한다
- admin에서 해당 주문을 조회할 수 있는지 확인한다
결제 장애에서는 사용자 안내와 운영자 확인 화면이 같이 중요합니다.
챗봇 실패가 늘어난 경우에는 아래를 확인합니다.
- RAG 검색 실패인지 LLM 호출 실패인지 구분한다
- 특정 질문 유형에서만 실패하는지 확인한다
- 주문 권한 거부가 정상 동작인지 확인한다
- handoff_required 비율이 급증했는지 본다
- 프롬프트에 민감 정보가 들어가지 않았는지 확인한다
- 사용자에게 재시도 또는 운영자 연결이 보이는지 확인한다
챗봇 장애는 답변 품질 문제와 시스템 실패를 구분해야 합니다.
운영 점검표는 매일 또는 릴리스 전후에 확인할 항목입니다.
기본 점검표는 아래로 시작합니다.
- storefront 상품 목록이 열린다
- buyer 로그인과 현재 사용자 조회가 된다
- 장바구니에 상품을 담을 수 있다
- 주문 생성과 결제 확인이 된다
- admin에서 주문 목록이 보인다
- admin 권한 없는 사용자는 차단된다
- 챗봇이 상품 질문에 답한다
- 챗봇이 권한 없는 주문 질문을 거절한다
- 최근 오류율이 기준 이하이다
- 최근 배포 이후 5xx가 급증하지 않았다
점검표는 길게 만들기보다 매번 실제로 확인할 수 있는 항목으로 구성해야 합니다.
배포 직후에는 아래 지표를 집중해서 봅니다.
- 5xx 오류율
- p95 응답 시간
- 로그인 실패 증가
- 주문 생성 실패 증가
- 결제 실패 증가
- admin API 실패 증가
- 챗봇 LLM 실패 증가
릴리스 직후 10분에서 30분 정도는 특히 중요합니다. 문제가 있으면 빠르게 롤백하거나 원인을 좁혀야 합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
- 주요 업무 이벤트 로그가 정의되어 있다
- 민감 정보 로그 제외 기준이 있다
- 핵심 운영 지표가 정의되어 있다
- 알림 기준 초안이 있다
- 주문, 결제, 챗봇 장애 런북이 있다
- 릴리스 전후 운영 점검표가 있다
- request_id 기준 추적 방식이 정리되어 있다
즉 장애가 발생해도 어디부터 봐야 하는지 설명할 수 있어야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
- 공통 request_id middleware
- 구조화 로그 포맷
- 주문/결제/admin/챗봇 이벤트 로그
- 민감 정보 마스킹 규칙
- 기본 health check
- 핵심 지표 수집 지점
- 운영 점검표 문서
- 장애 런북 문서
이 산출물이 있어야 다음 페이지에서 품질 회귀와 릴리스 체크리스트를 현실적인 기준으로 닫을 수 있습니다.
- 로그를 많이 찍으면 충분하다고 생각한다
- request_id 없이 로그를 남겨 흐름을 추적할 수 없다
- 민감 정보를 디버깅 편의로 그대로 로그에 남긴다
- 주문 실패와 결제 실패를 같은 오류로 뭉갠다
- 챗봇 실패 원인을 RAG, 권한, LLM으로 구분하지 않는다
- 알림 기준을 너무 민감하게 잡아 무시하게 만든다
- 운영 점검표를 실제로 실행할 수 없는 긴 문서로 만든다
이 일곱 가지 실수는 장애가 발생했을 때 시간을 크게 낭비하게 만듭니다.
이번 페이지에서는 운영자가 서비스 상태를 판단하기 위한 로그, 모니터링 지표, 알림 기준, 장애 런북, 운영 점검표를 정리했습니다. 핵심은 모든 것을 기록하는 것이 아니라, 구매와 결제와 운영자 화면과 챗봇의 실패를 빠르게 구분하고 재현할 수 있게 만드는 것입니다.
다음 페이지에서는 품질 회귀와 릴리스 체크리스트를 닫습니다.