결제 시스템에서 장애를 막는 것만큼 중요한 것은 장애가 발생했을 때 운영자가 빠르게 상황을 인지하고 대응할 수 있게 만드는 것입니다.
PG사 응답이 늦거나 결제 결과를 확정하지 못하는 상황은 언제든 발생할 수 있습니다. 이때 시스템이 오류를 기록하는 것만으로는 충분하지 않습니다.
- 지금 장애가 발생한 것인가?
- 일시적인 오류인가, 계속 확산되는 장애인가?
- 어떤 결제들이 영향을 받았는가?
- PG사 확인이 필요한 결제는 몇 건인가?
이번 운영 모니터링에서는 단순히 Grafana 대시보드를 만들거나 Slack 메시지를 보내는 것보다, 장애 감지부터 운영자의 후속 확인까지 하나의 흐름으로 연결하는 것에 집중했습니다.
장애 발생
↓
Grafana가 이상 상태 감지
↓
Slack으로 운영 알림 전송
↓
운영자가 Admin에서 영향받은 결제 확인
↓
PG 거래 결과 및 결제 이력 확인
↓
미확정 결제 후속 처리
↓
복구 여부와 잔여 미처리 건 확인모든 오류를 알림으로 보내지 않았다
운영 알림을 구성할 때 가장 먼저 정한 원칙은 모든 오류를 Slack으로 보내지 않는 것이었습니다.
결제 과정에서는 일시적인 네트워크 지연이나 단건 승인 실패가 발생할 수 있습니다. 이런 오류를 모두 알림으로 만들면 운영 채널에 비슷한 메시지가 반복적으로 쌓입니다.
- 중요한 장애와 단건 오류를 구분하기 어렵습니다.
- 동일한 장애에 여러 사람이 중복 대응할 수 있습니다.
- 반복되는 알림에 익숙해져 실제 장애를 늦게 확인할 수 있습니다.
- Slack 채널이 운영 알림이 아니라 로그 저장소처럼 변합니다.
따라서 “오류가 발생했는가?”보다 “운영자가 지금 행동해야 하는가?”를 기준으로 알림을 설계했습니다.
| 운영 상황 | 알림 기준 | 운영 의미 |
|---|---|---|
| PG Circuit Breaker OPEN | PG 장애가 누적돼 외부 호출이 차단됨 | PG사 상태와 결제 오류 추이를 즉시 확인해야 함 |
| TIMEOUT_UNKNOWN 증가 | 최근 5분 동안 결과 미확정 결제가 5건 이상 발생 | PG 거래 결과를 확인해야 할 결제가 빠르게 증가 중 |
Circuit Breaker 알림은 PG 연동 경로의 장애 상태를 알리고, TIMEOUT_UNKNOWN 알림은 후속 확인이 필요한 실제 결제의 누적을 알립니다.
알림 1 — PG 호출이 차단된 상황
PG사의 응답 지연이나 오류가 계속되면 Circuit Breaker가 OPEN 상태로 전환됩니다. 이 상태에서는 새로운 결제 요청이 PG사의 긴 타임아웃을 반복해서 기다리지 않도록 외부 호출을 빠르게 차단합니다.
운영 관점에서 Circuit Breaker OPEN은 단순한 애플리케이션 오류가 아닙니다.
PG 연동 구간에서 지속적인 이상이 감지됐고, 시스템의 보호 장치가 실제로 동작하기 시작했다는 의미입니다.
결제 성공률에 직접적인 영향을 줄 수 있으므로 critical 등급으로 분류했습니다.
Slack 메시지에는 내부 계산값보다 운영자가 바로 판단할 수 있는 정보를 우선했습니다.
🔥 [장애 발생] PocketPay PG Circuit Breaker OPEN
서비스: pocketpay-core
컴포넌트: pg-client
심각도: critical
PG 호출 실패율이 임계치를 넘어 Circuit Breaker가 OPEN됐습니다.
PG 서버 상태와 최근 결제 오류를 확인해주세요.알림을 받은 뒤 확인할 내용
- PG사 장애 공지 또는 상태 페이지 확인
- 최근 PG 호출 오류와 타임아웃 증가 여부 확인
- 일부 서버에서만 발생했는지 전체 서버에서 발생했는지 확인
TIMEOUT_UNKNOWN결제 증가 여부 확인- 상품 조회 등 비결제 API의 응답시간과 서버 자원 상태 확인
- 회로가 정상 상태로 복구되는지 관찰
Circuit Breaker가 복구됐다고 대응을 바로 끝내지는 않습니다. 이미 타임아웃을 겪은 결제는 결과 확인이 필요할 수 있기 때문입니다.
알림 2 — 결과를 확정하지 못한 결제가 누적된 상황
PG 승인 요청에서 타임아웃이 발생했다고 해서 실제 결제가 실패했다고 단정할 수는 없습니다.
우리 서버는 제한 시간 안에 응답을 받지 못했지만 PG사에서는 승인이 완료됐을 가능성이 있습니다. 이런 결제를 바로 실패 처리하거나 다시 승인하면 중복 결제로 이어질 수 있습니다.
따라서 승인 결과를 확정할 수 없는 결제는 TIMEOUT_UNKNOWN으로 관리했습니다.
PG 승인 요청
↓
응답 지연 또는 네트워크 단절
↓
승인 성공 여부를 즉시 확정할 수 없음
↓
TIMEOUT_UNKNOWN
↓
운영자 또는 자동 대사 프로세스의 확인 필요단건 타임아웃은 일시적인 지연일 수 있으므로 즉시 알리지 않았습니다. 대신 최근 5분 동안 5건 이상 발생했을 때 운영자가 확인하도록 설정했습니다.
이 알림은 서비스 전체 장애를 반드시 의미하지는 않지만, 실제 결제 결과를 확인해야 하는 건이 누적되고 있다는 뜻이므로 warning으로 분류했습니다.
알림 이후 운영자가 확인할 화면
Slack 알림은 장애 대응의 시작점일 뿐입니다. 어떤 결제에서 문제가 발생했고 현재 상태가 무엇인지 확인할 수 있어야 실제 대응으로 이어집니다.
이를 위해 Admin을 다음 두 영역으로 구성했습니다.
- 전체 결제 관리
- 확인 필요 결제
결제 상세 모달
전체 결제 목록에서 상세보기를 누르면 결제 정보를 모달로 확인할 수 있습니다.
| 정보 | 운영 목적 |
|---|---|
| 결제 ID | 내부 시스템에서 결제 건 식별 |
| 주문 ID·주문번호 | 주문 및 고객 문의 내역과 연결 |
| PG 거래 ID | PG사에서 실제 승인·취소 결과 조회 |
| 멱등키 | 동일 요청의 중복 실행 여부 확인 |
| 결제 금액 | PG 승인 금액과 내부 금액 대조 |
| 환불 가능 금액 | 취소·부분 취소 가능 범위 확인 |
| 실패 코드·실패 사유 | 원인과 후속 조치 판단 |
| 생성·변경 시간 | 장애 발생 시점과 처리 지연 확인 |
TIMEOUT_UNKNOWN 상태에서는 특히 PG 거래 ID가 중요합니다. PG사에는 승인이 완료됐지만 내부 시스템이 결과를 받지 못했을 수 있기 때문입니다.
최종 상태보다 중요한 상태 변경 이력
결제는 한 번에 최종 상태로 바뀌지 않습니다.
결제 대기
↓
결제 처리 중
↓
결과 확인 필요
↓
PG 거래 확인
↓
결제 완료 또는 실패
현재 상태만 보면 결제가 어떤 과정을 거쳤는지 알 수 없습니다. 따라서 상태 변경 이력을 시간순으로 확인할 수 있게 했습니다.
상태 이력을 통해 다음 질문에 답할 수 있습니다.
- 결제 처리는 언제 시작됐는가?
- 어느 시점에 타임아웃이 발생했는가?
- 운영 확인 전에 상태가 다시 바뀌었는가?
- 동일 결제에서 실패와 재처리가 반복됐는가?
- 고객 문의 시점에 결제가 어떤 상태였는가?
이는 장애 분석뿐 아니라 고객 문의 대응과 사후 정산 과정에서도 중요한 근거가 됩니다.
확인 필요 결제를 별도로 모은 이유
전체 결제 목록에서 장애 건을 일일이 검색하는 방식만으로는 운영 효율이 떨어집니다. 장애가 길어지면 운영자가 확인해야 할 결제가 빠르게 늘어나기 때문입니다.
따라서 FAILED와 TIMEOUT_UNKNOWN 상태를 별도의 화면에 모았습니다.
상단에서는 다음 지표를 한눈에 확인할 수 있습니다.
- 전체 확인 필요 결제 수
- 결제 실패 수
- 결과 확인 중인 결제 수
- 10분 이상 미처리된 결제 수
목록에는 상태뿐 아니라 실패 사유와 발생 후 경과 시간을 표시했습니다.
장기 미처리 건을 따로 표시한 이유
확인 필요 결제가 많아지면 모든 건을 동시에 처리하기 어렵습니다. 장기 미처리 건은 다음 위험이 있으므로 우선 확인해야 합니다.
- 고객이 결제 결과를 알 수 없는 상태로 오래 기다립니다.
- 실제 승인 건이 내부에서는 미확정으로 남을 수 있습니다.
- 재결제 과정에서 중복 승인 가능성이 커집니다.
- 취소나 재고 복구 같은 후속 처리가 늦어질 수 있습니다.
- 일 마감과 정산 데이터가 맞지 않을 수 있습니다.
따라서 단순 건수뿐 아니라 얼마나 오래 처리되지 않았는가를 운영 지표로 사용했습니다.
운영 화면을 실시간으로 갱신한 이유
운영자가 화면을 보고 있는 동안에도 결제 상태는 계속 바뀔 수 있습니다. 화면을 새로고침하지 않아 이전 상태가 계속 보이면 이미 처리된 결제를 다시 확인하거나 여러 운영자가 같은 건을 중복 처리할 수 있습니다.
이를 줄이기 위해 결제 상태 변경을 운영 화면에 실시간으로 전달했습니다.
운영자는 새로고침하지 않아도 다음 변화를 확인할 수 있습니다.
- 결제 상태 변경
- 최종 변경 시각
- 확인 필요 결제 수 변화
- 열린 상세 화면의 최신 상태와 이력
다만 실시간 이벤트 자체를 최종 데이터로 사용하지는 않았습니다. 이벤트는 “데이터가 변경됐다”는 신호로 사용하고 상세 정보와 통계는 저장된 최신 데이터를 다시 확인합니다.
결제 상태 변경
↓
운영 화면에 변경 신호 전달
├── 목록 상태 즉시 변경
├── 통계 카드 갱신
└── 열린 상세 화면 재조회이 방식은 실시간성과 데이터 신뢰성을 함께 확보하기 위한 선택이었습니다.
실제 동작 영상
영상에서는 다음 운영 흐름을 확인할 수 있습니다.
- 결제 상태가 변경됩니다.
- 운영 화면의 목록이 새로고침 없이 갱신됩니다.
- 확인 필요 결제 수와 상태별 통계가 변경됩니다.
- 상세 모달에서 최신 상태와 변경 이력을 확인합니다.
- 일정 시간 동안 TIMEOUT_UNKNOWN이 누적됩니다.
마무리
이번 운영 모니터링에서는 다음 흐름을 만들었습니다.
PG 연동 장애 또는 결제 결과 미확정 발생
↓
Grafana가 운영 기준에 따라 이상 감지
↓
Slack으로 장애 상황과 확인 항목 전달
↓
Admin에서 영향받은 결제와 실패 사유 확인
↓
상태 변경 이력과 PG 거래 결과 대조
↓
미확정 결제 후속 처리
↓
시스템 복구와 잔여 운영 업무를 각각 확인운영 모니터링의 목적은 장애가 발생했다는 사실을 보여주는 데서 끝나지 않습니다.
운영자가 어떤 결제를 먼저 확인해야 하는지, 어떤 정보를 기준으로 판단해야 하는지, 복구 이후 어떤 업무가 남아 있는지까지 연결해야 합니다.
Grafana와 Slack은 장애를 알려주는 시작점이고, Admin은 실제 영향을 확인하고 후속 조치를 수행하는 공간입니다. 실시간 갱신은 여러 운영자가 같은 상태를 보며 대응하도록 돕습니다.
결국 좋은 운영 모니터링은 많은 숫자를 보여주는 화면이 아니라, 장애 상황에서 다음 행동을 명확하게 알려주는 시스템이라고 생각합니다.
