서비스 운영의 시작은 데이터를 보는 것입니다.
2026년 8월 25일 | SKYWARE INSIGHT
서비스 장애는 보통 이렇게 알려집니다. 고객센터에 “결제가 안 된다”는 전화가 몇 통 들어오고, 담당자가 서버에 접속해 로그를 뒤지고, 한참 뒤에야 “30분 전부터 결제 모듈 응답이 느려졌다”는 사실을 확인합니다. 장애가 발생한 이후 원인을 찾는 방식만으로는 안정적인 서비스 운영이 어렵습니다. 고객이 먼저 알고 운영팀이 나중에 아는 구조이기 때문입니다.
최근에는 시스템에서 발생하는 다양한 데이터를 실시간으로 수집하고 주요 지표를 지속적으로 확인하는 관제 환경이 중요해지고 있습니다. 이 글에서는 무엇을 봐야 하는지, 어떻게 봐야 알림이 소음이 되지 않는지, 그리고 쌓인 운영 데이터를 장애 대응 외에 어디에 쓸 수 있는지 정리합니다.
01. 인프라 지표만으로는 서비스 상태를 알 수 없습니다
전통적인 모니터링은 CPU 사용률, 메모리, 디스크 같은 인프라 지표를 봅니다. 이 숫자들이 정상이어도 서비스는 얼마든지 고장 나 있을 수 있습니다. 결제 대행사 연동이 10초씩 지연되거나, 특정 상품 페이지만 오류를 내거나, 메시지가 발송은 됐는데 통신사에서 반려되는 경우가 그렇습니다.
그래서 인프라 지표와 함께 서비스 요청량, 오류율, 응답시간, 사용자 활동 데이터를 같이 분석해야 서비스의 상태를 정확하게 파악할 수 있습니다. 요즘은 이를 관측 가능성(Observability)이라 부르고, 로그 · 지표 · 추적 세 가지를 한데 모아 봅니다.
도식 1 · 관측 가능성의 세 축
- Logs로그무슨 일이 있었나. 오류 메시지 · 요청 기록 · 처리 결과
- Metrics지표얼마나 · 얼마나 빨리. 요청량 · 오류율 · 응답시간 · 처리 건수
- Traces추적어디서 막혔나. 한 요청이 거친 서비스 경로와 구간별 소요 시간
로그+지표+추적=“결제가 느린 이유가 결제 서비스인지, 그 뒤 카드사 연동인지”를 바로 짚는다
02. 무엇을 볼 것인가 · 네 가지 핵심 지표
지표를 많이 모은다고 잘 보이는 것은 아닙니다. 서비스마다 핵심 지표를 네 가지 정도로 추리면 대시보드 한 화면에서 상태가 읽힙니다. 흔히 지연 시간, 트래픽, 오류, 포화도를 기본으로 삼고, 여기에 그 서비스만의 업무 지표 한두 개를 더합니다.
도식 2 · 서비스별 핵심 지표 예시
| 지표 | 커머스 플랫폼(SCOS) | 통합 메시징(sOMP) | 왜 보나 |
|---|---|---|---|
| 지연 시간 | 상품 조회 · 결제 응답시간 | 접수 → 통신사 전달까지 걸린 시간 | 느려지는 것이 장애의 첫 신호 |
| 트래픽 | 분당 주문 · 페이지 요청량 | 분당 발송 건수 · 채널별 비중 | 급증과 급감 모두 이상 징후 |
| 오류 | 결제 실패율 · 5xx 비율 | 발송 실패율 · 통신사별 반려 코드 | 건수보다 비율의 변화를 본다 |
| 포화도 | DB 커넥션 · 큐 적체 | 발송 큐 대기 건수 · 워커 점유율 | 한계에 닿기 전에 늘릴 시점을 알려 준다 |
| 업무 지표 | 장바구니 → 결제 전환율 | 인증 메시지 도달률 | 기술 지표가 정상이어도 사업이 멈춘 것을 잡는다 |
마지막 줄이 중요합니다. 결제 전환율이 평소의 절반으로 떨어졌는데 서버 지표는 모두 정상이라면, 결제창에 들어간 외부 스크립트나 프로모션 설정 오류처럼 인프라 밖의 문제입니다. 업무 지표를 같이 보지 않으면 이런 장애는 매출 보고서가 나올 때까지 모릅니다.
03. 어떻게 볼 것인가 · 알림이 소음이 되지 않으려면
모니터링을 도입하고 가장 먼저 겪는 문제는 알림 피로입니다. CPU 80% 넘을 때마다 울리는 알림은 며칠 안에 무시됩니다. 실제로 울려야 할 알림이 그 사이에 묻힙니다.
- 증상을 기준으로 알림 “CPU 80%” 대신 “결제 응답시간 2초 초과가 5분 지속”처럼 고객이 느끼는 증상을 기준으로 둡니다.
- 기준선은 평소 패턴에서 발송량은 월요일 오전과 일요일 새벽이 다릅니다. 고정 임계값 대신 같은 요일 · 시간대의 평소 값과 비교합니다.
- 심각도를 나눈다 바로 깨워야 하는 것(결제 중단), 아침에 봐도 되는 것(디스크 70%), 주간 리뷰용(느린 쿼리 상위 10개)을 구분합니다.
- 알림에는 다음 행동을 “오류율 상승” 같은 상태와 함께 관련 대시보드 링크, 최근 배포 내역, 담당자를 보냅니다.
최근에는 알림이 오면 AI가 로그 · 지표 · 최근 배포 내역을 모아 “원인은 이것일 가능성이 높다”고 요약해 담당자에게 건네는 방식도 쓰입니다. 초기 정보 수집에 쓰던 시간을 줄여 주지만, 실제 조치는 사람이 판단하도록 두는 것이 안전합니다.
04. 쌓인 데이터는 어디에 쓰이나
실시간 모니터링은 다음과 같은 영역에서 활용됩니다.
- 장애 조기 발견고객이 전화하기 전에 응답시간과 오류율 변화로 먼저 알아챕니다.
- 성능 저하 분석어느 배포 이후, 어느 구간에서 느려졌는지 추적 데이터로 좁힙니다.
- 서비스 사용량 파악시간대 · 채널 · 기능별 사용량으로 어떤 기능이 실제로 쓰이는지 봅니다.
- 이상 트래픽 감지특정 IP의 반복 요청, 비정상 로그인 시도처럼 보안 신호도 같은 데이터에서 나옵니다.
- 운영 데이터 기반 의사결정프로모션 때 결제만 3배로 늘었던 기록이 다음 행사 때 서버를 얼마나 늘릴지, 어디에 투자할지를 알려 줍니다.
운영 데이터가 쌓이면 향후 서비스 확장과 인프라 투자 판단에도 활용할 수 있습니다. 6개월치 발송량 추이가 있으면 다음 분기 용량을 감으로 정하지 않아도 되고, 느린 쿼리 상위 목록이 있으면 성능 개선 우선순위가 그대로 나옵니다.
05. 스카이웨어의 운영 방식
스카이웨어는 커머스 플랫폼과 통합 메시징 서비스를 구축형과 ASP로 운영하면서, 시스템 상태와 주요 지표를 지속적으로 확인하고 장애 발생 시 빠르게 원인을 파악할 수 있는 운영 환경을 함께 구축합니다. 메시징 서비스에서는 발송 결과 코드와 통신사별 반려 현황을 실시간으로 집계해 전송 품질을 관리하고, 커머스 플랫폼에서는 주문 · 결제 구간의 응답시간과 실패율을 핵심 지표로 봅니다.
모니터링은 구축 단계에서부터 함께 설계하는 것이 원칙입니다. 어떤 지표를 볼지, 어느 선에서 알릴지, 알림을 누가 받을지는 설계 단계에서 함께 정합니다. 고객사 내부망에 구축하는 경우에도 같은 기준으로 관제 화면과 알림 체계를 넘깁니다.
좋은 운영은 문제가 생겼을 때 빨리 고치는 것과 함께, 문제가 생기기 전에 이상 징후를 찾아내는 데서 시작합니다.
