결제·핀테크 엔지니어링 브리핑
← 목록으로

결제 시스템 모니터링, 오픈소스(Prometheus·Grafana) vs 상용 APM 선택 기준

2026-09-05인프라·시스템
#관측성#모니터링#PG#오픈소스
Ad slot

정산 배치, 카드사·PG 연동 API, 원장까지 여러 시스템이 얽혀 있는 결제 서비스에서 장애가 나면, "어디서 문제가 생겼는지"를 빨리 찾아내는 게 복구 속도를 좌우한다. AWS 기반 결제 인프라 설계 글에서 다룬 것처럼 전자금융감독규정은 장애 발생 후 복구까지 걸려도 되는 최대 시간(RTO)을 3시간 이내로 요구하는데, 이 3시간은 장애를 실제로 감지한 시점부터 계산되는 게 아니라 장애가 "발생한" 시점부터 흐른다. 즉 관측성(observability, 시스템 내부 상태를 외부에서 들여다볼 수 있게 만드는 것) 스택이 부실해서 장애를 늦게 알아채면, RTO를 지킬 수 있는 시간 자체가 그만큼 줄어든다.

오픈소스: Prometheus + Grafana + OpenTelemetry

Prometheus는 서버·애플리케이션의 수치 데이터(메트릭 — 초당 요청 수, 응답 시간, 에러율 같은 숫자)를 주기적으로 수집해 저장하는 오픈소스 시계열 데이터베이스다. CNCF(Cloud Native Computing Foundation, 쿠버네티스 같은 클라우드 네이티브 프로젝트를 관리하는 재단)의 졸업 프로젝트로, 사실상 업계 표준으로 자리 잡았다.

Grafana는 Prometheus 같은 곳에 쌓인 메트릭과 로그를 대시보드로 시각화하는 도구다. 2026년 4월 GrafanaCON에서 공개된 Grafana 13은 로그 저장소인 Loki의 아키텍처를 새로 짜는 것이 핵심 변경사항이었다.

OpenTelemetry는 애플리케이션에서 메트릭·트레이스(요청이 여러 서비스를 거치는 경로를 추적하는 기록)·로그를 표준화된 방식으로 뽑아내는 계측(instrumentation) 표준이다. 특정 벤더의 SDK에 묶이지 않고 코드를 계측해둘 수 있다는 게 핵심이다. Grafana Labs의 Alloy는 이 OpenTelemetry Collector(수집기)의 배포판 중 하나로, 최근에는 표준 OpenTelemetry Collector 설정(YAML)을 그대로 쓸 수 있게 개편됐다.

이 조합의 장점은 명확하다 — 서울 리전 안에서 전부 직접 운영할 수 있어 데이터가 국내를 벗어나지 않는다. 단점은 클러스터·스토리지·알림 규칙을 직접 구축하고 운영해야 한다는 것이다. 트래픽이 커질수록 메트릭·로그 저장 용량 계획이 까다로워진다.

상용 APM: Datadog, New Relic 등 — 리전을 반드시 확인해야 한다

Datadog·New Relic 같은 상용 APM(Application Performance Monitoring) SaaS는 자동 계측, 통합 대시보드, 이상 탐지 기능을 빠르게 도입할 수 있다는 게 강점이다. 그런데 국내 PG가 놓치기 쉬운 함정이 있다.

Datadog 공식 문서 기준으로, 아시아태평양 지역에서 지원하는 사이트(리전)는 AP1(일본/도쿄)과 AP2(호주)뿐이다 — 서울 리전은 없다. 국내 PG가 Datadog을 쓰면 수집한 데이터가 도쿄로 전송·저장된다는 뜻이다.

이게 왜 문제가 될 수 있을까. 순수 숫자 메트릭(CPU 사용률, 응답시간 분포 같은 데이터)은 그 자체로는 개인 신용정보가 아니라서 대체로 문제가 없다. 하지만 로그나 트레이스는 얘기가 다르다 — 개발자가 디버깅 편의를 위해 요청·응답 본문을 그대로 로그에 남기는 습관이 있다면, 카드번호나 고객 식별 정보 같은 개인 신용정보가 실수로 해외로 전송되는 사고로 이어질 수 있다. 클라우드 이용 절차 글에서 다룬 "개인 신용정보는 국내 리전에만" 원칙은 결제 시스템 본체뿐 아니라 그걸 들여다보는 관측성 스택에도 그대로 적용된다는 걸 놓치기 쉽다.

비교 정리

항목 오픈소스(Prometheus+Grafana+OTel) 상용 APM(Datadog 등)
데이터 위치 서울 리전에서 직접 운영 가능 대체로 해외 리전(Datadog은 도쿄)
도입 속도 직접 구축·튜닝 필요 빠름(SaaS로 바로 시작)
운영 부담 클러스터·스토리지를 직접 관리 벤더가 인프라를 관리
벤더 종속 낮음(오픈 표준 기반) 높음(SaaS 전환 시 마이그레이션 부담)
국내 PG 적합도 민감정보가 섞일 수 있는 로그·트레이스에 유리 순수 메트릭 위주 사용이면 무방, 로그·트레이스는 마스킹 필수 검토

개발팀이 챙겨야 할 것

계측 단계에서 마스킹을 강제한다 로그나 트레이스에 카드번호·주민등록번호 같은 패턴이 남지 않도록, OpenTelemetry의 속성 처리기(attribute processor) 같은 기능으로 계측 코드 단계에서부터 자동으로 마스킹되게 만드는 게 안전하다. "개발자가 조심하면 된다"는 규칙이 아니라 시스템이 강제하는 규칙이어야 사고를 막을 수 있다.

데이터 종류별로 도구를 분리하는 것도 방법이다 메트릭(숫자 데이터)은 상용 SaaS를 써도 리스크가 작지만, 로그·트레이스처럼 민감정보가 섞일 가능성이 있는 데이터는 국내에 직접 운영하는 오픈소스 스택으로 분리하는 하이브리드 구성을 검토할 만하다.

"장애 발생"과 "장애 인지" 사이의 시간을 직접 관리한다 RTO는 장애가 발생한 시점부터 흐르므로, 관측성 스택 자체의 목표로 평균 탐지 시간(MTTD, Mean Time To Detect)을 정해두고 관리해야 한다. 알림이 5분 뒤에 와도 되는 지표와, 1분 안에 와야 하는 지표(결제 실패율 급증, 정산 배치 지연)를 구분해두지 않으면 정작 중요한 신호가 다른 알림에 묻혀버린다.

알림 피로를 줄인다 모든 지표에 알림을 걸면 오히려 진짜 중요한 알림을 놓치게 된다("알림 피로", alert fatigue). 결제 실패율, 정산 배치 지연, 카드사 API 응답 지연처럼 사업에 직접 영향을 주는 핵심 지표 위주로 알림 우선순위를 설계하는 게 실무적으로 더 효과적이다.

체크리스트

  • 상용 APM을 쓴다면 데이터가 실제로 어느 리전에서 처리되는지 확인했는지 (예: Datadog은 서울이 아니라 도쿄)
  • 로그·트레이스에 카드번호 등 개인 신용정보가 실수로 남지 않도록 계측 단계에서 마스킹 규칙을 강제하고 있는지
  • 민감정보가 섞일 가능성이 큰 데이터(로그·트레이스)와 순수 메트릭을 분리해서 도구를 선택했는지
  • 장애 발생부터 알림까지 걸리는 시간(MTTD)을 자체적으로 측정·관리하는지
  • 알림 규칙이 핵심 지표(결제 실패율, 정산 배치 지연) 위주로 설계돼 있어 알림 피로가 없는지

참고자료

관련 글

Ad slot