이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
정산 시스템의 장애는 금액 불일치, 지연 처리, 중복 처리 세 가지 유형이 가장 빈번하게 발생한다고 생각합니다. 각 유형마다 탐지 방식이 달라서 금액 불일치는 reconciliation 배치 결과로, 지연은 SLA 초과 건수로, 중복은 결제 키 기준 중복 레코드 카운트로 각각 알람을 설계했습니다. 알람 임계값은 금액 비례로 설정했는데, 1만 원 미만 불일치와 100만 원 불일치를 같은 알람으로 처리하면 우선순위 판단이 어려워집니다.
Grafana에 정산 완료율, 오류율, 평균 처리 시간을 대시보드로 올려두고, 정상 상태의 기준값을 먼저 정의해두는 것이 이상 감지 민감도를 높이는 핵심이었습니다.
정산 모니터링에서 초기에 가장 많은 문제를 일으킨 것은 알람 오탐이었습니다. 고정 임계값으로 알람을 설정했더니 월말 정산 몰림 현상처럼 정상적인 급증 패턴에도 알람이 울렸고, 팀이 점점 알람을 무시하게 되는 현상이 생겼습니다. 이를 해결하기 위해 이전 7일 이동 평균 대비 편차로 임계값을 바꿨습니다.
정상 변동 범위를 데이터로 먼저 정의해두면 비정상 편차만 알람이 울리는 구조가 됩니다. 알람이 울린 횟수보다 알람이 울렸을 때 실제 조치가 필요한 비율이 높아지는 것이 모니터링 성숙도의 지표라고 생각합니다. 이 방식으로 주간 알람 건수는 줄었고 실제 이상으로 이어진 비율은 오히려 높아졌습니다.
정산 시스템 장애에서 가장 오래 걸린 부분은 개발자가 개입해야만 재처리를 할 수 있는 구조였습니다. 오류 건이 생기면 개발자가 직접 DB를 조작하거나 스크립트를 돌려야 했고, 야간 장애 시 대응 시간이 평균 40분 이상 걸렸습니다. 운영 팀이 직접 이상 건을 조회하고 재처리 버튼을 누를 수 있는 관리 콘솔을 만들었습니다.
조건 검색 → 대상 선택 → 재처리 실행 → 결과 확인을 한 화면에서 할 수 있도록 구성했고, 실행 이력은 Audit Log에 자동 기록되도록 설계했습니다. 콘솔 도입 후 야간 장애 대응에서 개발자 호출이 줄었고 운영 팀의 평균 처리 시간이 40분에서 8분으로 단축됐습니다. 모니터링 체계는 감지 이후 조치 경로가 분리돼 있어야 실효성이 생긴다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.