APM vs 옵저버빌리티 — 무엇이 다르고, 무엇부터 갖춰야 하나

세 가지 신호로 보면 커버리지가 어떻게 다른가?

옵저버빌리티는 메트릭·로그·트레이스 세 신호 전체를 지향하고, APM은 그중 트레이스와 애플리케이션 메트릭을 깊게 다룹니다. 신호 범위로 보면 넓이와 깊이의 차이입니다.

옵저버빌리티 논의에서 표준처럼 쓰이는 분류가 세 가지 신호(three pillars)입니다(OpenTelemetry Observability Primer).

• 메트릭(metrics): 일정 시간 구간의 수치를 집계한 값입니다. 응답시간 평균, TPS, CPU 사용률처럼 추세와 총량을 보는 데 적합합니다.
• 로그(logs): 특정 시점에 시스템이 남긴 타임스탬프 기록입니다. “무슨 일이 있었는가”의 원문 증거입니다.
• 트레이스(traces): 요청 하나가 여러 컴포넌트를 거쳐 간 경로의 기록입니다. 트레이스는 처리 구간 하나하나를 나타내는 스팬(span)으로 구성됩니다.

APM 제품의 중심은 트레이스입니다. 요청 단위로 호출 구간을 기록해 병목을 특정하는 트랜잭션 추적이 핵심 기능이고, 그 과정에서 나오는 응답시간·TPS·에러율 같은 애플리케이션 메트릭을 함께 집계합니다. 반면 인프라 전반의 메트릭(네트워크 장비, 스토리지)이나 전사 로그 검색·분석은 전통적으로 APM의 주 무대가 아니었습니다. 이 영역은 메트릭 저장소(Prometheus 계열), 로그 플랫폼(Elasticsearch 계열) 같은 별도 도구가 맡아 왔습니다.

옵저버빌리티 플랫폼을 표방하는 제품들은 이 세 신호를 한 저장소에 모아 서로 연결하는 방향으로 확장해 왔습니다. 트레이스에서 이상 구간을 찾으면 같은 시각의 로그로 바로 건너가고, 메트릭 급변 구간에서 해당 트랜잭션 목록으로 이동하는 식입니다. 즉 신호 커버리지 관점에서 APM은 “트레이스 중심의 깊이”, 옵저버빌리티는 “세 신호를 잇는 넓이”로 성격이 갈립니다.

그림 2. 세 신호(메트릭·로그·트레이스) 커버리지 비교

실무 기준 — "알려진 장애를 빨리 찾기"와 "모르는 질문에 답하기"는 어떻게 다른가?

APM은 알려진 유형의 성능 문제를 빨리 찾는 데 강하고, 옵저버빌리티는 예상하지 못한 질문에 답하는 능력을 지향합니다. 운영 질문의 성격이 두 번째 구분선입니다.

Google SRE 북은 모니터링을 화이트박스와 블랙박스로 나누면서, 모니터링의 근본 목적을 “무엇이 고장났는지, 왜 고장났는지”에 답하는 일로 정리합니다(Google SRE Book — Monitoring Distributed Systems). 여기서 실무적으로 유용한 구분이 나옵니다.

“알려진 미지수(known unknowns)”를 다루는 일. 느린 SQL, 커넥션 풀 고갈, 외부 API 지연, 메모리 부족 — 발생할 수 있다고 이미 아는 유형의 문제들입니다. 언제 어디서 터질지 모를 뿐, 무엇을 봐야 하는지는 압니다. APM은 이 영역에 최적화되어 있습니다. 트랜잭션마다 SQL 실행 시간과 호출 스택을 이미 기록하고 있으므로, 장애가 나면 “어느 요청의 어느 구간”인지 몇 번의 클릭으로 좁혀 갑니다.

“모르는 미지수(unknown unknowns)”를 다루는 일. 배포·설정·트래픽 패턴이 얽혀 만들어지는, 사전에 정의한 지표와 대시보드에 잡히지 않는 문제들입니다. “특정 통신사 회선을 쓰는 사용자만, 특정 버전 앱에서만 느리다” 같은 상황이 대표적입니다. 이런 질문에 답하려면 미리 만들어 둔 화면이 아니라, 높은 카디널리티의 원본 데이터에 즉석 질의를 던질 수 있어야 합니다. 옵저버빌리티가 지향하는 능력이 바로 이것입니다.

우리 조직의 장애 이력을 돌아보면 판단 기준이 나옵니다. 최근 1년의 장애 대부분이 느린 쿼리·자원 고갈·특정 트랜잭션 지연처럼 알려진 유형이었다면, APM의 깊이가 먼저 필요합니다. 반대로 서비스가 수십 개로 쪼개져 있고 “원인 불명”으로 종결된 장애가 쌓여 간다면, 신호를 넓게 잇는 투자가 필요한 시점입니다. 장애 상황에서 APM 데이터를 읽는 구체적 절차는 APM에서 트랜잭션 분석 챠트 활용하기 — T-MAP 글에서 다룹니다.

그림 3. 장애 이력의 성격이 도입 순서를 정한다

OpenTelemetry 표준화는 APM 도구 지형을 어떻게 바꿨나?

OpenTelemetry는 신호 수집 계층을 표준화해, 도구 선택과 데이터 수집을 분리했습니다. 계측의 벤더 종속이 풀리면서 APM 도구 지형이 바뀌고 있습니다.

과거 APM 도입의 숨은 비용은 계측(instrumentation)의 벤더 종속이었습니다. 제품마다 전용 에이전트와 전용 데이터 형식을 썼기 때문에, 도구를 바꾸려면 수집 체계를 처음부터 다시 깔아야 했습니다. OpenTelemetry는 CNCF가 관리하는 오픈소스 프로젝트로, 메트릭·로그·트레이스를 수집하는 API·SDK와 전송 프로토콜(OTLP)을 표준화합니다(OpenTelemetry 공식 문서). 애플리케이션은 표준 방식으로 신호를 내보내고, 그 신호를 어느 백엔드로 보낼지는 나중에 정하는 구조입니다. 프로젝트의 구성 요소와 데이터 흐름은 오픈텔레메트리(OpenTelemetry)는 무엇인가요 글에서 따로 정리했습니다.

이 표준화가 가져온 변화는 세 가지입니다. 첫째, 분산 추적의 문맥 전파가 W3C Trace Context 표준으로 수렴하면서, 서로 다른 도구로 계측한 서비스 사이에서도 트레이스가 이어질 수 있게 됐습니다. 둘째, 상용 APM 제품들이 자사 에이전트와 함께 OpenTelemetry 데이터 수신을 지원하기 시작해, “에이전트를 바꾸지 않고 백엔드만 바꾸는” 선택지가 생겼습니다. 셋째, 오픈소스 백엔드 조합으로 자체 관측 스택을 구성하는 팀이 늘면서, 상용 제품은 수집 그 자체보다 분석 깊이·운영 편의·지원으로 차별화하는 방향으로 이동했습니다.

다만 표준이 모든 것을 해결하지는 않습니다. OpenTelemetry는 수집과 전송의 표준이지, 저장·분석·시각화는 여전히 각 백엔드의 몫입니다. 자동 계측만으로는 프레임워크 경계의 큰 구간만 보이고, 업무 로직 내부의 세밀한 구간 분해는 도구별 역량 차이가 큽니다. “표준을 따르는가”와 “문제를 빨리 찾게 해 주는가”는 별개의 평가 항목으로 봐야 합니다.

그림 4. OpenTelemetry 표준화 — 계측과 백엔드의 분리

국내 운영 조직은 무엇부터 갖춰야 하나?

대부분의 국내 운영 조직에는 APM으로 시작해 옵저버빌리티로 넓혀 가는 경로가 현실적입니다. 이유는 장애의 분포와 운영 인력의 구조에 있습니다.

국내 엔터프라이즈·공공 시스템의 주력은 여전히 Java 웹 애플리케이션과 WAS(Web Application Server) 중심 구성입니다. 이 환경에서 서비스 품질을 위협하는 문제의 다수는 느린 SQL, 커넥션 풀 고갈, GC(garbage collection) 부하, 특정 화면의 응답 지연처럼 애플리케이션 계층에 몰려 있습니다. 즉 “알려진 미지수”의 비중이 높고, 그 영역을 가장 깊게 파는 도구가 APM입니다. 응답시간·TPS·에러율 같은 기본 지표의 정의와 APM이 답하는 질문은 APM, 애플리케이션 성능 관리란 무엇인가요 글에서 정리했습니다.

운영 인력 구조도 고려해야 합니다. 세 신호를 모두 자체 스택으로 구성하면 수집기·저장소·대시보드 각각이 운영 대상이 되고, 그 자체가 새로운 운영 부담이 됩니다. 전담 플랫폼 팀이 없는 조직이라면, 잘 만들어진 APM으로 애플리케이션 계층의 깊이를 먼저 확보하고, 로그·인프라 메트릭은 기존 도구와 연계하는 편이 총비용이 낮습니다.

그림 5. 자체 스택을 구성하면 운영 대상이 늘어난다

확장 시점을 알리는 신호는 분명합니다. 서비스 간 호출이 늘어 단일 서버 안의 추적만으로 전체 그림이 안 보이기 시작할 때, “원인 불명” 종결 장애가 반복될 때, 조직이 MSA(마이크로서비스 아키텍처)와 컨테이너 기반으로 이동할 때입니다. 특히 MSA 환경에서는 분산 추적과 서비스 맵이 사실상 필수가 되는데, 컨테이너 환경에서의 실제 모니터링 구성은 활용 사례로 이해하는 쿠버네티스 모니터링 글에서 다룹니다.

그림 6. APM 으로 시작해 옵저버빌리티로 넓히는 순서

OPENMARU APM은 두 영역을 어떻게 잇나?

OPENMARU APM은 트랜잭션 중심의 깊이를 기본으로 하고, 오픈 표준·오픈소스 스택과의 연계로 관측 범위를 넓히는 접근을 취합니다.

OPENMARU APM은 오픈소스 웹 서버와 WAS를 쓰는 Java 애플리케이션에 에이전트를 붙여, 모든 트랜잭션의 응답시간·호출 횟수를 실시간으로 수집하고 개별 트랜잭션을 코드 레벨까지 프로파일링합니다(OPENMARU APM 제품 페이지). 느린 요청의 호출 스택과 SQL 구간이 바로 펼쳐지므로, 앞서 말한 “알려진 미지수”를 빠르게 좁히는 깊이를 갖추고 있습니다. 여기에 JVM 힙·스레드·커넥션 풀 같은 자원 지표를 트랜잭션과 같은 시간축에서 대조할 수 있어, 애플리케이션과 WAS 계층의 상태를 한 축으로 봅니다.

동시에 컨테이너·쿠버네티스(Kubernetes) 환경으로 확장하는 팀을 위해 애플리케이션 지표 기반의 지능형 오토스케일링(HPA 연계)처럼 클라우드 네이티브 전환 이후의 운영 시나리오도 지원합니다(OPENMARU APM 쿠버네티스 HPA 자료). 트랜잭션이라는 깊은 축을 유지한 채 관측 범위를 넓혀 가는 구조이므로, “APM으로 시작해 옵저버빌리티로 확장”하는 경로와 자연스럽게 맞물립니다. 결론적으로 두 개념 사이에서 고민하는 조직이라면, 오늘의 장애를 빨리 잡는 깊이를 먼저 확보하고, 내일의 아키텍처 변화에 맞춰 넓이를 더해 가면 됩니다.

자주 묻는 질문 (FAQ)

APM과 옵저버빌리티의 차이는 무엇인가요?

APM은 애플리케이션 성능 관리라는 목적을 가진 도구 범주이고, 옵저버빌리티는 시스템 상태를 데이터로 설명할 수 있는 성질입니다. APM은 트레이스와 애플리케이션 메트릭을 깊게 다루고, 옵저버빌리티는 메트릭·로그·트레이스 세 신호 전체를 잇는 넓이를 지향합니다.

옵저버빌리티가 있으면 APM은 필요 없나요?

아닙니다. 세 신호를 모아 두는 것과 애플리케이션 병목을 코드 레벨까지 분해하는 것은 다른 능력입니다. 느린 SQL·커넥션 풀·GC처럼 애플리케이션 계층에 몰리는 문제는 트랜잭션 추적 깊이를 갖춘 APM이 가장 빨리 좁혀 줍니다. 둘은 대체가 아니라 보완 관계입니다.

무엇부터 도입해야 하나요?

최근 장애 이력을 기준으로 판단하면 됩니다. 느린 쿼리·자원 고갈처럼 알려진 유형이 다수라면 APM의 깊이가 먼저이고, 서비스가 잘게 쪼개져 “원인 불명” 장애가 쌓인다면 신호를 넓게 잇는 투자가 필요합니다. 국내 Java·WAS 중심 환경 다수는 APM으로 시작하는 편이 현실적입니다.

OpenTelemetry만 도입하면 옵저버빌리티가 확보되나요?

OpenTelemetry는 신호의 수집·전송 표준이지 완성된 관측 체계가 아닙니다. 저장·분석·시각화 백엔드는 따로 갖춰야 하고, 자동 계측만으로는 업무 로직 내부의 세밀한 구간 분해에 한계가 있습니다. 표준 준수 여부와 분석 깊이는 별개 항목으로 평가해야 합니다.

모니터링과 옵저버빌리티는 같은 말인가요?

모니터링은 미리 정한 지표를 지켜보며 알려진 문제를 감지하는 활동이고, 옵저버빌리티는 예상하지 못한 질문에도 데이터로 답할 수 있는 시스템의 성질입니다. 모니터링은 옵저버빌리티를 구성하는 활동 중 하나로 이해하면 정확합니다.

참고 리소스

자사 콘텐츠 (OPENMARU)
– APM이란? 서버 모니터링으로 못 잡는 장애, 개념부터 도입까지
– APM, 애플리케이션 성능 관리(Application Performance Management)란 무엇인가요?
– 오픈텔레메트리(OpenTelemetry)는 무엇인가요?
– APM에서 트랜잭션 분석 챠트 활용하기 — T-MAP
– 활용 사례로 이해하는 쿠버네티스 모니터링
– 쿠버네티스 HPA의 한계를 넘어, 지능형 오토스케일링을 구현하다
– OPENMARU APM 제품 소개
– OPENMARU APM 기술 문서
– AI 기반 VibeOps — WAS OOM 분석의 패러다임을 바꾸다 (Cloud Native Forum)

표준·공식 문서 (외부)
– Observability Primer — OpenTelemetry
– OTLP Specification — OpenTelemetry
– 관측 가능성 (Observability) — CNCF 용어집(한국어)
– Monitoring Distributed Systems — Google SRE Book
– Trace Context — W3C Recommendation