Observability — 작은 팀의 가난한 자의 스택

결제·정산 팀에게 Observability는 선택이 아니다

결제와 정산을 다루는 팀에게 "서비스가 지금 살아있는가"는 단순한 운영 질문이 아니다. 결제 엔드포인트가 60초 다운되는 동안 실패한 트랜잭션은 재시도 로직이 있어도 사용자 경험에 흔적을 남기고, 정산 자동화 파이프라인이 조용히 멈추면 다음 날 아침 거래처와의 정산 불일치로 이어진다. 도메인 특성상 에러 하나가 단순 UX 저하가 아니라 돈의 흐름에 직결된다.

우리 팀은 세 명이고, 서비스는 결제 연동 API, 정산 배치, 자동화 워크플로우 등 여러 개가 동시에 돌아간다. Datadog Enterprise 플랜은 호스트당 월 $23 이상에서 시작하고, 로그 인덱싱은 GB당 별도 과금이다. 서버 5대 기준으로 로그와 APM까지 붙이면 월 $300~$500을 가볍게 넘는다. 팀 규모와 매출 규모가 불균형한 초기엔 이 숫자가 부담스럽다. 그래서 우리는 "완벽한 가시성"이 아니라 "장애를 빨리 아는 것"을 목표로 스택을 설계했다.

무엇을 알아야 하는지부터 정의했다

툴부터 고르면 반드시 실패한다. 우리가 먼저 한 것은 실제로 필요한 질문 목록을 만드는 일이었다. ① 서비스가 지금 살아있는가, ② 응답이 느려지고 있는가, ③ 에러가 갑자기 늘었는가, ④ 서버 리소스가 한계에 근접하고 있는가. 이 네 가지가 전부였다. 분산 트레이싱, 실시간 대시보드, 커스텀 메트릭 파이프라인은 이 네 가지가 안정적으로 커버된 이후의 이야기다.

이 프레임이 중요한 이유는 도구 선택의 기준이 되기 때문이다. 정산 배치가 실패했을 때 우리에게 필요한 것은 예쁜 대시보드가 아니라 "배치가 에러 없이 끝났는가"를 알리는 알림이다. 결제 API 응답 지연은 Jaeger 트레이스보다 단순한 P95 레이턴시 메트릭 하나가 더 빠르게 이상을 포착한다. 필요 이상의 도구는 세팅·유지보수 비용을 올릴 뿐이다.

실제 스택: 도구별 선택 이유와 한계

UptimeRobot(무료 플랜) 은 헬스체크와 다운타임 알림을 담당한다. 1분 간격 폴링, 슬랙 웹훅 연동, 무료. 결제 API의 /health 엔드포인트 외에 정산 배치 서버의 특정 상태 URL도 등록해두어, 배치가 예정 시간 내에 응답하지 않으면 바로 알람이 온다. 한계는 명확하다. 1분 폴링이라 59초짜리 장애는 탐지를 못 할 수 있고, 내부 네트워크 이슈는 감지하지 못한다. 이 한계를 알고 쓰는 것과 모르고 쓰는 것은 다르다.

Loki + Promtail(셀프호스팅) 은 로그 수집을 맡는다. Elasticsearch 기반 ELK 스택과 비교할 때 Loki의 최대 장점은 메모리다. Loki는 로그를 인덱싱하지 않고 레이블만 인덱싱하기 때문에, 동일한 로그 볼륨에서 Elasticsearch 대비 메모리 사용량이 5~10배 적다는 것이 공식 벤치마크와 실제 운영 경험 모두에서 확인된다. 우리는 기존 서비스 서버에 Promtail을 사이드카로 붙였고, Loki는 별도 소형 인스턴스(월 $5 수준)에서 운영한다. Grafana는 붙이지 않았다. logcli 로 터미널에서 직접 쿼리하는 방식이 우리 3인 팀 워크플로우에는 오히려 더 빠르다.

Prometheus + node_exporter 는 핵심 서버 두 대의 시스템 메트릭을 수집한다. 전체 인프라를 커버하려 하지 않은 것이 포인트다. 결제 처리 서버와 정산 배치 서버, 이 두 대만 붙여두었다. CPU, 메모리, 디스크 I/O, 네트워크 트래픽. Grafana 없이 Prometheus 기본 UI로 필요할 때 들여다본다. 알림은 Alertmanager를 통해 슬랙으로 연결했다. 디스크 사용률 85% 초과 시 알림 규칙 하나가 실제로 여러 번 위기를 예방했다.

Sentry(무료 플랜) 는 에러 트래킹을 담당한다. 프로젝트당 월 5,000 이벤트 제한이 있는데, 우리 규모에서는 아직 한 번도 한도에 걸린 적이 없다. 스택 트레이스, 환경 정보, 발생 빈도가 슬랙으로 즉시 도착하는 것이 핵심이다. 결제 연동 코드에서 외부 PG사 API 타임아웃이 급증했을 때, Sentry 알림이 UptimeRobot보다 먼저 우리에게 알려준 사례가 있었다. 서비스가 다운되기 전에 에러율 이상 징후를 잡은 것이다.

비용과 기능의 트레이드오프: 우리가 포기한 것들

현재 이 스택의 월 비용은 Loki 호스팅 $5 + Sentry/UptimeRobot 무료 플랜 = 사실상 $5다. Datadog 최소 구성과 비교하면 월 $250~$300 절감이다. 연간으로 환산하면 $3,000 이상이다. 하지만 포기한 것도 분명히 있다.

분산 트레이싱이 없다. 결제 요청이 여러 서비스를 거칠 때 어디서 지연이 발생했는지를 추적하려면 지금은 로그를 request ID로 직접 grep해야 한다. APM 없이 코드 레벨 성능 병목을 찾는 것도 불편하다. 그리고 이 스택은 규모가 커지면 분명히 한계를 드러낸다. 서버가 10대를 넘어가거나, SLA를 외부에 보고해야 하는 시점이 오면 유료 SaaS로 이전할 계획을 명확히 갖고 있다. 지금은 이 한계를 알고 감수하는 것이지, 최선이라고 착각하는 것이 아니다.

결제·정산 현장 실전 시나리오: 정산 배치 무음 장애

가장 위험한 장애 유형이 있다. 서비스가 다운되지 않았는데 데이터가 틀리는 경우다. 우리가 실제로 경험한 시나리오다. 정산 배치가 실행은 됐으나 특정 조건의 거래를 누락한 채 완료 상태로 기록됐다. UptimeRobot은 서버가 살아있으니 알림을 안 보냈다. Sentry도 예외가 발생하지 않았으니 조용했다.

이 경우를 잡아낸 것은 Loki 로그와 Prometheus 메트릭의 조합이었다. 배치 완료 로그에 처리 건수를 함께 기록해두었고, 전일 대비 처리 건수가 비정상적으로 낮은 것을 다음 날 아침 수동 확인으로 발견했다. 이 경험 이후 배치 완료 시 처리 건수를 커스텀 메트릭으로 Prometheus에 기록하고, 전일 대비 50% 이하로 떨어지면 Alertmanager가 알림을 보내는 규칙을 추가했다. "서비스가 살아있는가"가 아니라 "서비스가 올바르게 동작하는가"를 묻는 알림이 필요했던 것이다. 이 구분이 결제·정산 도메인에서는 특히 중요하다.

바로 써먹을 실행 시사점

지금 Observability 스택이 없거나 부족하다면, 이 순서로 하루 안에 기본을 세울 수 있다.

1단계 (30분): UptimeRobot으로 핵심 엔드포인트 5개 등록. 결제 API, 정산 서버, 주요 웹훅 수신 URL. 슬랙 알림 연동까지. 비용 제로.

2단계 (1시간): Sentry 무료 플랜 프로젝트 생성 및 SDK 삽입. 결제 연동 코드와 정산 배치에 최소한 Sentry SDK를 붙인다. 에러 발생 시 슬랙으로 스택 트레이스가 오는 것만으로도 대응 속도가 크게 달라진다.

3단계 (반나절): 배치·자동화 작업에 처리 건수 로그 추가. 완료 로그에 processed=N, skipped=M, failed=K 형태로 기록. 이것만 있어도 무음 장애의 80%를 수동이라도 탐지할 수 있다.

4단계 (여유 있을 때): Loki + Promtail 셀프호스팅. 이미 서버가 있다면 추가 비용 최소화로 구성 가능. ELK 스택을 고려하고 있다면 Loki를 먼저 검토하라. 로그 볼륨이 작을 때는 메모리 효율 차이가 체감된다.

유료 SaaS로 넘어가는 기준도 미리 정해두면 좋다. 우리 기준은 두 가지다. 서버가 10대를 초과하거나, 정산 SLA를 외부 보고해야 하는 계약이 생기는 시점. 그 전까지는 이 스택으로 충분하고, 절감된 비용을 제품에 쓰는 것이 더 합리적이다.

— by mings