실행 그래프로 API 이상탐지·드리프트 감지하기: JP모건 결제팀의 실전 관측 전략

핵심 메시지

• '실행 그래프'는 하나의 요청이 엣지·게이트웨이·인증·오케스트레이션 등 여러 서비스를 거치는 처리 과정을 짧게 사는 DAG로 표현한 것이다. Neo4j 같은 영속 그래프와 달리 요청마다 생겼다 사라진다.
• 요청 처리를 DAG로 나타내면 서비스 실행 순서와 노드 간 전달 맥락이 정리되고, 어느 노드에서 지연·문제가 생겼는지 정확히 국소화할 수 있다.
• '이상(anomaly)'은 어느 날의 일회성 사건이고, '드리프트(drift)'는 시간에 걸쳐 패턴 자체가 바뀌는 것이다. 출퇴근이 사고로 하루 늦는 것과, 1년 새 상시 20분 더 걸리게 되는 것의 차이다.
• 드리프트는 구조 변화, 규모/부하, 공변량(요청 구성 변화), 동일 요청의 다른 동작 등으로 분류되며 유형별로 대응(스케일업, 비동기화, 롤백, 기준선 재설정)이 다르다.
• OpenTelemetry로 데이터를 모아 근본원인 분석→드리프트 분류→조치 결정→위험 평가→5~10% 점진 배포 후 100% 확대의 흐름으로 자동화하고, 발견까지 걸리는 시간을 크게 줄인다.

쉽게 이해하기

JP모건 결제팀을 이끄는 발표자는 '실행 그래프(execution graph)'라는 개념을 소개한다. 우리가 흔히 다루는 영속 그래프나 속성 그래프(Neo4j 등)와 달리, 실행 그래프는 하나의 요청이 처리되는 과정을 짧게 사는 DAG로 표현한 것이다. 요청은 엣지 계층, 게이트웨이, 인그레스, 인증·인가, 오케스트레이션, 병렬 호출되는 여러 시스템을 거쳐 클라이언트에 결과가 통지된다. 이 전체 흐름을 DAG로 나타내면 서비스 실행 순서와 각 노드가 다음 노드로 넘기는 맥락이 정돈되고, 재시도나 루프도 별도 개체로 추적할 수 있다.

핵심은 자원을 아끼면서 신뢰성을 높이는 계층적 점검이다. 1차 점검은 공항에서 탑승권만 확인하고 통과시키는 것과 같다. 요청의 종단간 기준선(baseline)을 알고 있어 모든 게 정상이면 다음 단계 점검으로 갈 필요가 없다. 지연이 감지되면 무엇이 바뀌었는지 살핀다. 예컨대 새 노드가 추가되거나 기존 단계가 제거되는 구조 변화가 원인일 수 있다. 또한 기준선은 클라이언트마다 다르다. 로컬 요청과 해외 요청은 정상 처리 시간이 다르므로, 그에 맞춰 임계값을 잡아야 경보 잡음을 줄일 수 있다.

발표자는 이상과 드리프트를 명확히 구분한다. 집에서 회사까지 보통 1시간인데 어느 날 사고로 더 걸렸다면 그것은 '이상'이고, 1년 전엔 1시간이던 길이 이제 상시 20분 더 걸린다면 그것은 '드리프트'다. 드리프트는 다시 몇 가지로 나뉜다. 구조적 드리프트(노드 추가·제거, 카페가 멤버십을 새로 묻기 시작하는 것에 비유), 규모/부하 드리프트(요청량 증가로 서비스가 못 버팀 → 스케일업이나 비동기 호출), 공변량 드리프트(국내 60%·해외 40%였던 요청 구성이 바뀌어 통화·추가 단계가 생김), 그리고 같은 요청이 다른 동작을 보이는 경우(필요 시 롤백)다.

유형을 알면 해법도 정해진다. 전체 파이프라인은 OpenTelemetry가 데이터를 계속 공급하고, 시스템이 모든 데이터포인트를 파악하면 근본원인 분석을 수행해 어떤 드리프트인지 판별한 뒤 필요한 조치를 정한다. 이어 그 조치를 자동화했을 때의 위험을 평가하고, 우선 5~10% 노드에만 적용해 모니터링한 다음 이상이 없으면 100%로 확대한다. 실시간 결제처럼 지연이 치명적인 영역에서는 데이터를 비동기로 OpenTelemetry에 보내고 Kafka와 스트림 평가를 얹으며, 빠르게 판단하는 '핫 패스'와 더 정확한 '재대사(recon)' 경로를 둔다.

발표자는 실전에서의 미세조정 과제도 짚는다. 한 시스템이 이벤트를 지연시켜 6개 노드 데이터만 있고 7번째가 늦게 오는 경우, 이를 구조 변화로 볼지 말지 기준을 정교하게 잡아 오경보를 줄여야 한다. 이 사례에는 요청의 시작·종료를 추적하는 '테일 기반' 방식이 적합하고, 새 엔드포인트는 콜드 스타트로 보아 일반적 기준선 대신 새 기준선을 쓴다. 탐지에는 MMD나 KL 같은 척도를 쓰고, 결과는 잘 설명돼야 한다. 의사가 '건강 점수 22'라고만 말하면 이해되지 않듯, 설명 가능성이 있어야 정보에 근거한 결정을 내릴 수 있다.

주요 인사이트

• 요청 흐름을 DAG로 표현하는 것만으로 관측 문제가 단순해진다. 어느 노드가 갑자기 느려졌는지 알림을 받을 수도 있고, 지연이 전반적이면 공통 원인을 짚을 수도 있다.
• 이상과 드리프트를 구분하는 것이 대응의 출발점이다. 일회성 사건은 시스템의 임계성에 따라 처리하고, 패턴이 바뀐 드리프트는 새 기준선을 세워 잡음을 줄여야 한다.
• 기준선을 'POST 요청은 모두 이 값'처럼 일반화하지 말고 결제·송금 등 용도와 클라이언트·엔드포인트별로 잡아야 오경보가 준다.
• 자동화는 위험 평가와 짝을 이뤄야 한다. 조치를 곧바로 전면 적용하지 않고 5~10%에 먼저 롤아웃해 검증한 뒤 확대하며, 시스템이 새 배포를 인지해 롤백 판단을 할 수 있어야 한다.
• 설명 가능성은 부가 기능이 아니라 필수다. 왜 이상으로 판정했는지 데이터로 설명돼야 운영자가 신뢰하고 올바른 결정을 내린다.

자주 묻는 질문

관련 AI 소식