[인프라] Sentry vs Elastic APM 비교 분석

Sentry Elastic APM 비교를 고민하시는 분들은 보통 비슷한 시점에 막히더라고요. 서비스는 클라우드에 올렸는데, 장애는 간헐적으로 터지고, CPU나 응답 시간도 오락가락하고, 로그만 봐서는 도대체 어디서부터 추적해야 할지 감이 안 오는 순간이 있습니다. 저도 홈랩이랑 실서비스 비슷한 테스트 환경에서 이것저것 붙여보면서 꽤 삽질했었는데요. 결론부터 말씀드리면 Sentry와 Elastic APM은 겹치는 영역이 있지만 출발점이 꽤 다릅니다. 하나는 에러 트래킹(Error Tracking, 예외 중심 추적)에 강하고, 다른 하나는 APM(Application Performance Monitoring, 애플리케이션 성능 모니터링)과 관측성(Observability, 시스템 상태를 추론하는 능력) 전체 흐름에 더 가깝습니다.

그래서 오늘은 마케팅 문구 말고, 실제 운영자 시점에서 어떤 팀에 뭐가 더 맞는지 차근차근 정리해보겠습니다. 클라우드 모니터링을 처음 붙이는 분도 이해할 수 있게 풀어볼게요.

애플리케이션, SDK/Agent, 수집 서버, 대시보드까지 이어지는 전체 흐름을 한눈에 보여주는 비교용 다이어그램입니다.

Sentry와 Elastic APM, 쉽게 말해 뭐가 다른가요?

쉽게 말해 Sentry는 에러가 났을 때 개발자가 바로 달려가게 만드는 도구에 가깝고, Elastic APM은 서비스가 느려지거나 병목이 생길 때 시스템 전체 문맥을 보게 해주는 도구에 가깝습니다.

• Sentry: 예외(Exception, 런타임 오류), 스택 트레이스(Stack Trace, 오류 호출 경로), 릴리스 추적(Release Tracking, 배포 버전별 상태) 쪽이 직관적입니다.
• Elastic APM: 트랜잭션(Transaction, 요청 단위 처리 흐름), 스팬(Span, 세부 작업 구간), 인프라 메트릭(Metrics, CPU/메모리 같은 수치), 로그 연계가 자연스럽습니다.

처음엔 저도 둘 다 비슷해 보였거든요. 근데 실제로 써보니까 질문 자체가 달라집니다.

1. Sentry를 볼 때는 “왜 이 에러가 났지?”를 먼저 묻게 됩니다.
2. Elastic APM을 볼 때는 “왜 이 요청이 느리지?” 또는 “어느 서비스 구간이 병목이지?”를 먼저 보게 됩니다.

여기서 중요한 포인트! 장애 대응의 시작점이 예외냐, 성능 저하냐에 따라 체감 가치가 꽤 달라집니다.

클라우드 모니터링 관점에서 보는 핵심 차이

제가 직접 해보니, 팀에 로그 플랫폼이 이미 있느냐가 생각보다 큽니다. 이미 Elasticsearch(엘라스틱서치, 검색/분석 엔진)와 Kibana(키바나, 시각화 대시보드)를 쓰고 있다면 Elastic APM 쪽이 훨씬 자연스럽게 이어집니다. 반대로 그런 기반이 없고 일단 에러부터 빨리 잡아야 한다면 Sentry가 체감 속도가 빠르더라고요.

Sentry가 잘 맞는 상황

Sentry는 특히 이런 상황에서 강합니다.

• 배포 직후 특정 버전에서 에러가 급증하는지 빠르게 보고 싶을 때
• 프론트엔드와 백엔드 예외를 한 번에 추적하고 싶을 때
• 개발자가 스택 트레이스와 컨텍스트만 보고 바로 수정 포인트를 잡아야 할 때
• 소규모 팀에서 운영 복잡도를 크게 늘리지 않고 에러 트래킹을 붙이고 싶을 때

실제로 써보니까 Sentry는 “이 에러가 몇 명에게 영향을 줬는가”, “어느 릴리스 이후 시작됐는가” 같은 질문에 답하기 좋았습니다. 특히 이슈 그룹화(Issue Grouping, 같은 유형 오류 묶기)가 잘 되면 알림 피로도도 꽤 줄어듭니다.

Elastic APM이 빛나는 상황

Elastic APM은 다음처럼 전체 흐름을 보려는 팀에 잘 맞습니다.

• 마이크로서비스(Microservices, 기능별로 쪼갠 서비스 구조) 환경에서 요청 경로를 따라가야 할 때
• 애플리케이션 성능 문제와 인프라 메트릭을 같이 보고 싶을 때
• 로그, 메트릭, 트레이스를 한 플랫폼에서 묶어 보고 싶을 때
• 운영팀과 개발팀이 같은 관측성 도구를 공유해야 할 때

이쪽은 처음엔 좀 묵직합니다. 저도 처음엔 “이걸 다 연결해야 하나?” 싶었는데, 한 번 구조가 잡히면 장점이 확실합니다. 예를 들어 API 응답이 느릴 때, 단순히 느리다는 사실만 보는 게 아니라 DB 쿼리, 외부 HTTP 호출, 특정 서비스 구간까지 내려가서 볼 수 있거든요. 이거 진짜 편하더라고요.

실전 구현: Python 앱에 둘 다 붙여보기

비교는 결국 손에 붙여봐야 감이 옵니다. 여기서는 가장 단순한 예제로 Flask(플라스크, Python 웹 프레임워크) 기준으로 보여드릴게요. 실제 서비스에서는 환경 변수로 키를 분리하고, 운영/스테이징 환경을 나눠서 쓰시는 걸 권장합니다.

1. Sentry SDK 연결

pip install flask sentry-sdk

import os
from flask import Flask
import sentry_sdk
from sentry_sdk.integrations.flask import FlaskIntegration

sentry_sdk.init(
    dsn=os.environ.get("SENTRY_DSN"),
    integrations=[FlaskIntegration()],
    traces_sample_rate=0.1,
    send_default_pii=False,
)

app = Flask(__name__)

@app.route("/")
def index():
    return {"status": "ok"}

@app.route("/error")
def error():
    raise RuntimeError("sentry test error")

여기서 dsn은 Sentry 프로젝트에서 발급받는 연결 정보입니다. traces_sample_rate는 성능 이벤트 샘플링 비율인데요. 무조건 높게 두기보다 트래픽 규모를 보고 잡는 게 좋습니다.

2. Elastic APM Agent 연결

pip install flask elastic-apm

import os
from flask import Flask
from elasticapm.contrib.flask import ElasticAPM

app = Flask(__name__)
app.config["ELASTIC_APM"] = {
    "SERVICE_NAME": "demo-flask-app",
    "SECRET_TOKEN": os.environ.get("ELASTIC_APM_SECRET_TOKEN"),
    "SERVER_URL": os.environ.get("ELASTIC_APM_SERVER_URL"),
    "ENVIRONMENT": os.environ.get("APP_ENV", "production"),
}

apm = ElasticAPM(app)

@app.route("/")
def index():
    return {"status": "ok"}

@app.route("/slow")
def slow():
    import time
    time.sleep(1.2)
    return {"status": "slow"}

Elastic APM은 보통 APM Server 또는 Elastic Cloud 쪽 엔드포인트로 데이터를 보냅니다. 서비스 이름을 어떻게 나누느냐가 꽤 중요하더라고요. 나중에 대시보드에서 서비스별로 분리해서 보게 되기 때문입니다.

3. 컨테이너 환경 변수 분리

services:
  app:
    image: my-flask-app:latest
    environment:
      SENTRY_DSN: "${SENTRY_DSN}"
      ELASTIC_APM_SERVER_URL: "${ELASTIC_APM_SERVER_URL}"
      ELASTIC_APM_SECRET_TOKEN: "${ELASTIC_APM_SECRET_TOKEN}"
      APP_ENV: "production"
    ports:
      - "8000:8000"

클라우드 환경에서는 Kubernetes(쿠버네티스, 컨테이너 오케스트레이션)나 ECS 같은 플랫폼에서도 같은 원칙입니다. 민감한 값은 Secret으로 빼고, 서비스명과 환경명은 일관되게 가져가세요.

실전 구현 단계에서 앱 코드, 환경 변수, 외부 모니터링 서비스가 어떻게 연결되는지 보여주는 구성 이미지입니다.

⚠️ 실제로 자주 겪는 문제와 트러블슈팅

여기서부터가 진짜 운영 팁입니다. 문서만 보면 금방 붙을 것 같았는데, 저는 여기서 삽질 좀 했습니다 ㅎㅎ

에러는 들어오는데 성능 데이터가 비어 있는 경우

• Sentry에서는 트레이싱 샘플링 설정이 너무 낮거나 꺼져 있는지 확인합니다.
• Elastic APM에서는 Agent 설정은 되었는데 서버 URL 또는 인증 토큰이 맞지 않는 경우가 많습니다.
• 프록시(Proxy, 중간 전달 장비)나 보안 그룹 때문에 수집 엔드포인트로 아웃바운드가 막힌 경우도 자주 있습니다.

서비스 이름이 제각각 찍히는 경우

이건 운영하면서 은근 치명적입니다. 배포마다 이름이 달라지면 대시보드가 찢어집니다. service name 규칙을 미리 정해두세요. 예를 들면 team-service-env 같은 형태로요.

알림이 너무 많이 오는 경우

Sentry는 같은 유형의 예외를 얼마나 잘 묶어주느냐가 중요하고, Elastic APM은 임계값(Threshold, 경고 기준치) 설계를 잘해야 합니다. 처음부터 모든 알림을 켜면 금방 무뎌집니다. 저도 초반엔 메신저가 울리기만 하고 아무도 안 보는 상태가 됐었거든요.

개인정보와 민감정보 유출 위험

가장 조심해야 할 부분입니다. 에러 이벤트나 트레이스에 요청 본문, 헤더, 사용자 식별값이 섞여 들어갈 수 있습니다. 그래서 기본값을 그대로 믿지 말고 다음 원칙을 꼭 적용하세요.

1. 민감한 필드는 수집 전에 마스킹(Masking, 값 가리기)합니다.
2. PII(개인식별정보) 전송 여부를 명시적으로 검토합니다.
3. 운영 환경과 개발 환경의 수집 범위를 분리합니다.

검증: 붙인 뒤 무엇을 확인해야 하나요?

연동이 끝났다고 바로 끝은 아닙니다. 최소한 아래 시나리오는 확인해보셔야 합니다.

1. Sentry 검증: 테스트 예외를 한 번 발생시켜 이슈가 생성되는지 확인합니다.
2. Elastic APM 검증: 응답이 느린 엔드포인트를 호출해 트랜잭션과 스팬이 보이는지 확인합니다.
3. 배포 검증: 새 릴리스 이후 에러 추세가 구분되는지 확인합니다.
4. 알림 검증: 실제로 필요한 채널로 경고가 가는지 확인합니다.

curl http://localhost:8000/error
curl http://localhost:8000/slow

제가 실제로 써보니까, 검증할 때는 일부러 실패를 만들어보는 게 제일 확실합니다. 정상 상태만 보면 연동이 된 것처럼 보이는데, 막상 장애가 터지면 필요한 필드가 빠져 있는 경우가 있거든요. 드디어 됐다! 싶어서 넘겼다가 나중에 다시 뜯어보는 경우, 정말 많습니다.

하나는 에러 중심, 다른 하나는 성능 흐름 중심이라는 차이를 직관적으로 보여주는 결과 화면 예시입니다.

어떤 팀이 무엇을 선택하면 좋을까?

사실 둘 중 하나만 절대 정답이라고 보긴 어렵습니다. 팀의 현재 성숙도와 운영 방식이 더 중요합니다. 로그 플랫폼이 아직 없고 개발자 중심으로 빠르게 대응해야 한다면 Sentry가 훨씬 덜 부담스럽습니다. 반대로 이미 Elastic 기반 운영 체계가 있다면 Elastic APM은 확장성이 좋습니다.

자주 묻는 질문 정리

Q. 둘 다 같이 써도 되나요?

네, 가능합니다. 실제로 에러 트래킹은 Sentry, 통합 관측성은 Elastic APM으로 나눠 가져가는 팀도 있습니다. 다만 데이터 중복과 운영 포인트 증가를 감안하셔야 합니다.

Q. 클라우드 모니터링 입문자는 무엇부터 시작할까요?

개인적으로는 장애를 빨리 잡는 경험을 먼저 만드는 걸 추천합니다. 그래서 입문자는 Sentry 같은 에러 중심 도구부터 시작하고, 이후에 성능 모니터링과 분산 추적으로 넓히는 흐름이 덜 헷갈립니다.

Q. Elastic APM은 언제 더 빛나나요?

서비스가 여러 개로 나뉘고, 느려지는 구간이 앱 코드인지 DB인지 외부 API인지 구분이 안 될 때요. 그때부터는 트레이스 기반 분석 가치가 확 올라갑니다.

팀 규모, 운영 방식, 분석 목적에 따라 어떤 도구가 더 맞는지 빠르게 판단할 수 있도록 요약한 비교 인포그래픽입니다.

마무리: 결국 질문은 도구가 아니라 운영 방식입니다

Sentry Elastic APM 비교를 한 줄로 줄이면 이렇습니다. Sentry는 에러 대응의 속도를 높여주고, Elastic APM은 성능과 구조를 읽는 시야를 넓혀줍니다.

저도 처음엔 “둘 중 뭐가 더 좋지?”만 붙잡고 있었는데, 실제로 써보니까 질문을 바꿔야 하더라고요. 우리 팀은 지금 무엇이 더 아픈가? 에러 원인 파악이 급한지, 아니면 서비스 전체 병목과 클라우드 모니터링 체계를 정리해야 하는지가 먼저입니다.

혹시 지금 막 APM 솔루션 도입을 검토 중이시라면, 제 추천은 이렇습니다. 작게 붙이고, 일부러 장애를 내보고, 대시보드와 알림이 실제 운영에 도움이 되는지 먼저 확인하세요. 그 다음에 범위를 넓히는 게 훨씬 덜 고생합니다.

다음 글에서는 OpenTelemetry(OpenTelemetry, 관측성 데이터 수집 표준) 기준으로 Sentry와 Elastic 계열 도구를 어떻게 같이 엮을 수 있는지도 다뤄볼 예정입니다. 이전 글에서 로그 수집 파이프라인 정리한 내용과도 이어보시면 도움이 될 겁니다. 🎉