트랜잭션 추적이란 — 느린 요청 하나를 코드 레벨까지 따라가는 기술

코드를 안 고쳤는데 어떻게 측정되나 — 동작 원리

트랜잭션 추적은 에이전트가 바이트코드에 측정 코드를 자동으로 심는 계측 방식으로 동작합니다. 개발자가 소스 코드를 수정하지 않아도 메서드·SQL 단위 측정이 가능한 이유입니다.

Java 환경을 기준으로 원리를 따라가 보겠습니다. 애플리케이션을 시작할 때 APM 에이전트(agent)를 JVM 옵션으로 함께 붙입니다. 이 에이전트가 하는 일이 계측(instrumentation)입니다. Java 클래스는 실행 전에 바이트코드로 변환되는데, 에이전트는 클래스가 메모리에 로딩되는 순간 이 바이트코드를 가로채 측정 코드를 끼워 넣습니다. 이를 바이트코드 계측(bytecode instrumentation)이라고 부릅니다.

쿠버네티스 환경이라면 이 “붙이는 작업”까지 자동화됩니다. 파드에 라벨만 달아 두면 어드미션 웹훅(admission webhook)이 파드 스펙을 변형해 에이전트를 담은 init 컨테이너와 -javaagent 옵션을 주입합니다. 컨테이너 이미지도, 애플리케이션 코드도 손대지 않습니다.

그림 2. 컨테이너 환경의 에이전트 자동 주입. 라벨이 붙은 파드에 웹훅이 볼륨·init 컨테이너·-javaagent 옵션을 끼워 넣고, 기동한 JVM이 에이전트를 로드해 지표를 보냅니다. “코드를 안 고쳤는데 어떻게 측정되나”의 쿠버네티스 버전 답입니다. (OPENMARU APM Operator 사용자 가이드)

측정 코드가 심어지는 대표 지점은 세 곳입니다.

• 요청의 입구: 서블릿·컨트롤러 진입 지점에 트랜잭션의 시작과 끝을 기록합니다. 트랜잭션 이름(URL·메서드)과 전체 응답시간이 여기서 나옵니다.
• 메서드 호출: 주요 프레임워크와 업무 클래스의 메서드 앞뒤에 시각 기록을 넣어, 호출 스택을 따라 어느 메서드에서 시간이 소비됐는지 프로파일링합니다.
• 바깥으로 나가는 호출: JDBC 드라이버를 감싸 SQL 문장과 실행 시간을 캡처하고, HTTP 클라이언트를 감싸 외부 API 호출의 대상과 소요 시간을 기록합니다.

이렇게 모은 스팬들이 하나의 트랜잭션 ID로 묶여 수집 서버로 전송되고, 화면에서는 호출 트리 형태로 펼쳐집니다. OpenTelemetry 문서의 표현을 빌리면, 트레이스 데이터가 나오려면 애플리케이션 코드가 “계측되어야” 하며, 자동 계측은 이 작업을 코드 수정 없이 대신해 주는 방식입니다(OpenTelemetry — Traces).

그림 3. 계측한 데이터가 화면까지 오는 경로. 수집(에이전트) → 전송(APM 서버) → 저장(메트릭은 시계열, 이벤트·트랜잭션은 별도) → 표시(웹 콘솔) 네 단계입니다. 실시간 화면은 약 5초 주기로 갱신되고, 지난 구간은 저장된 데이터를 조회합니다. 추적 화면에서 “지금”과 “그때”를 함께 볼 수 있는 이유가 이 갈림에 있습니다. (OPENMARU APM 사용자 가이드 — 개념 이해)

물론 계측에는 비용이 있습니다. 모든 메서드를 다 재면 측정 자체가 부하가 되므로, 실무에서는 프레임워크 경계와 I/O 지점을 기본으로 계측하고, 필요한 업무 패키지만 추가하는 방식으로 범위를 조절합니다. 전 구간을 다 기록하는 대신 표본 추출(sampling)로 수집량을 조절하는 것도 표준 기법입니다.

단일 서버 추적과 분산 추적은 무엇이 다른가?

단일 서버 추적은 한 프로세스 안의 호출 스택을 파고들고, 분산 추적은 서버 경계를 넘는 요청 경로를 잇습니다. 갈림길은 trace context를 다음 서비스로 전파하는지 여부입니다.

WAS 한 대 안에서 처리가 끝나는 요청이라면, 추적은 그 프로세스 안의 호출 스택과 SQL 구간만 기록하면 충분합니다. 국내 엔터프라이즈 시스템의 다수를 차지하는 모놀리식(monolithic) 구성에서는 이 단일 서버 추적만으로도 병목의 대부분이 드러납니다. 느린 SQL, 느린 외부 연계, 무거운 비즈니스 로직이 모두 한 프로세스 안에 있기 때문입니다.

문제는 요청이 서버 경계를 넘을 때입니다. 주문 요청이 주문 서비스 → 재고 서비스 → 결제 서비스를 거친다면, 각 서비스가 따로 기록한 추적은 서로 남남입니다. 주문 서비스 화면에서는 “재고 서비스 호출이 2초 걸렸다”까지만 보이고, 그 2초 안에서 무슨 일이 있었는지는 재고 서비스의 추적을 따로 열어 맞춰 봐야 합니다. 장애 상황에서 이 수작업 대조는 시간을 잡아먹는 주범이 됩니다.

분산 추적은 이 단절을 문맥 전파(context propagation)로 해결합니다. 첫 서비스가 요청에 트레이스 ID를 부여하고, 다음 서비스를 호출할 때 그 ID를 HTTP 헤더에 실어 보냅니다. 받은 서비스는 같은 ID 아래에 자기 스팬을 이어 붙입니다. 이렇게 하면 서비스 여러 개를 거친 요청도 하나의 트레이스로 꿰어져, 전체 경로에서 어느 서비스의 어느 구간이 느렸는지 한 화면에서 보입니다. microservices.io의 패턴 정리도 분산 추적의 핵심을 “외부 요청마다 고유 ID를 부여하고, 그 ID로 서비스들을 가로지르는 작업을 한데 묶어 중앙에서 조회하는 것”으로 설명합니다(microservices.io — Distributed Tracing 패턴). 서비스가 늘어날수록 이 능력은 선택이 아니라 필수가 됩니다.

이 경계선은 제품 구성에서도 그대로 나타납니다. 오픈마루의 경우 단일 WAS 안의 호출 스택과 SQL 구간은 OPENMARU APM이 담당하고, 서비스를 가로지르는 트레이스는 OPENMARU Observability가 이어받습니다. 제품 소개는 트레이스를 “한 사용자의 요청이 여러 서비스에서 처리되는 과정을 스팬(span) 단위로 나누어 추적”해 서비스 간 인과 관계와 시간 관계를 보여 주는 데이터로 정의하고, 메트릭·로그와 함께 묶어 분석해야 재현되지 않는 장애도 식별할 수 있다고 설명합니다. 서비스 간 호출 관계와 의존성은 마이크로서비스 토폴로지 맵으로 시각화합니다(OPENMARU Observability 제품 페이지).

W3C Trace Context와 OpenTelemetry 표준은 왜 중요한가?

두 표준은 서로 다른 도구로 계측된 서비스 사이에서도 추적이 이어지도록 만드는 공통 규약입니다. 표준 이전에는 벤더가 다르면 추적이 경계에서 끊겼습니다.

문맥 전파가 동작하려면 “트레이스 ID를 어떤 헤더에 어떤 형식으로 싣는가”가 통일돼야 합니다. 과거에는 APM 벤더마다 전용 헤더를 썼기 때문에, A사 에이전트를 붙인 서비스와 B사 에이전트를 붙인 서비스 사이에서 추적이 끊겼습니다. W3C Trace Context 표준은 이 문제를 풀기 위해 traceparent·tracestate라는 공통 HTTP 헤더 형식을 정의했습니다(W3C — Trace Context). traceparent 헤더에 트레이스 ID와 부모 스팬 ID가 표준 형식으로 담기므로, 이 표준을 따르는 도구들 사이에서는 벤더가 달라도 트레이스가 이어집니다.

OpenTelemetry는 여기서 한 걸음 더 나가, 스팬을 만들고 속성을 붙이고 내보내는 API·SDK 자체를 표준화했습니다. 트레이스 전파의 기본 형식으로 W3C Trace Context를 채택하고 있어, OpenTelemetry로 계측한 서비스는 별도 설정 없이 표준 헤더로 문맥을 주고받습니다(OpenTelemetry — Traces). 실무 관점에서 이 표준화가 갖는 의미는 두 가지입니다. 첫째, 이기종 도구가 섞인 환경 — 일부 서비스는 상용 APM, 일부는 오픈소스 계측 — 에서도 추적의 연속성을 설계할 수 있습니다. 둘째, 계측 자산이 특정 벤더에 묶이지 않으므로, 백엔드를 바꾸더라도 수집 체계를 다시 깔지 않아도 됩니다.

국내 제품에서도 표준 채택은 이미 진행형입니다. OPENMARU Observability는 OpenTelemetry 같은 표준을 지원하는 통합 에이전트를 제공해 여러 언어와 프레임워크에서 데이터를 수집한다고 밝히고 있습니다(OPENMARU Observability 제품 페이지). 계측 자산을 표준에 맡겨 두면, 나중에 수집 백엔드를 바꾸더라도 애플리케이션 쪽 작업을 되풀이하지 않아도 됩니다.

도구를 평가할 때는 “표준 지원 여부”를 이분법으로 보기보다, 우리 환경의 어느 경계에서 추적이 끊기는지를 먼저 그려 보고, 그 경계를 이어 줄 수 있는지 확인하는 접근이 실용적입니다.

실전 절차 — 느린 요청에서 슬로우 쿼리까지 어떻게 내려가나?

실전 추적은 느린 트랜잭션 선별 → 호출 트리 열기 → 최장 구간 확인 → 원인 판정의 네 단계로 진행됩니다. 각 단계마다 보는 화면과 판단 기준이 다릅니다.

응답 지연 신고가 들어왔다고 가정하고 절차를 따라가 보겠습니다.

1단계 — 느린 트랜잭션을 선별합니다. 트랜잭션 목록을 응답시간 내림차순으로 정렬하거나, 산점도에서 위쪽에 찍힌 점들을 봅니다. 여기서 확인할 것은 패턴입니다. 특정 URL만 느린가(해당 기능의 문제), 전 트랜잭션이 고르게 느린가(공용 자원의 문제), 특정 시간대에만 느린가(배치·외부 요인)에 따라 이후 경로가 갈립니다.

그림 4. 트랜잭션 히트맵(T-Map). 점 하나가 트랜잭션 묶음이고, 위로 솟을수록 느린 요청입니다. 위쪽에 몰린 구간을 드래그하면 그 시간·응답시간 범위의 트랜잭션만 목록으로 추려집니다. 1단계에서 봐야 할 “특정 시간대인가, 상시인가”가 띠의 모양으로 먼저 드러납니다. (OPENMARU APM 사용자 가이드)

2단계 — 대표 트랜잭션의 호출 트리를 엽니다. 느린 트랜잭션 하나를 골라 스팬들을 시간축으로 펼칩니다. 전체 응답시간이 구간별로 분해되어, 어디까지가 애플리케이션 코드이고 어디부터가 SQL·외부 호출인지 드러납니다.

그림 5. 호출 흐름(워터폴). 응답시간 3.02초짜리 요청 한 건을 스팬 단위로 펼친 화면입니다. 서블릿 필터에서 JSP 실행까지 내려간 뒤 ConnectionPool.getConnection() 한 줄이 3.02초(99.9%)를 차지한다는 사실이 막대 길이로 바로 보입니다. (OPENMARU APM 사용자 가이드)

3단계 — 가장 긴 구간을 확인합니다. 갈래는 대체로 셋입니다. SQL 구간이 길면 해당 쿼리 문장과 실행 횟수를 봅니다. 같은 쿼리가 수백 번 반복된다면 N+1 호출 패턴입니다. 외부 HTTP 구간이 길면 연계 시스템의 지연이고, 순수 애플리케이션 구간이 길면 메서드 프로파일에서 반복 호출되거나 오래 걸린 메서드를 찾습니다.

그림 6. 같은 SQL이 반복 호출된 경우. SELECT ... FROM apm_sample_user WHERE id = ? 한 문장이 50회 호출됐고, 개별 실행은 평균 1ms인데 누적으로는 SQL 시간의 40.6%를 차지합니다. 개별 쿼리 속도만 보면 정상으로 읽히는, N+1 계열 반복 호출의 전형입니다. (OPENMARU APM 사용자 가이드)

4단계 — 원인을 판정하고 교차 확인합니다. 슬로우 쿼리로 지목됐다면 실행계획(인덱스 누락·풀스캔)을 확인하고, 같은 시간대의 커넥션 풀 대기·GC 상태를 함께 봅니다. 쿼리 자체는 그대로인데 DB 커넥션을 얻기까지의 대기가 길었던 경우도 많아, 구간 분해 없이 “DB가 느리다”로 결론 내리면 엉뚱한 곳을 고치게 됩니다. 이 상관 분석을 APM 화면에서 실제로 수행한 사례는 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모 글에서 보실 수 있습니다.

그림 7. 4단계의 함정을 보여 주는 화면. SQL 시간이 전체의 99.9%지만, 원인은 느린 쿼리가 아니라 커넥션 풀 대기입니다. getConnection() 누적 3.02초가 근거로 제시되고 HTTP 상태는 200입니다. 구간을 나눠 보지 않으면 “DB 튜닝”으로 방향을 잘못 잡게 되는 경우입니다. (OPENMARU APM 사용자 가이드)

OPENMARU APM의 트랜잭션 추적 화면은 어떻게 활용하나?

OPENMARU APM은 모든 트랜잭션을 실시간 수집하고, 개별 트랜잭션을 호출 스택과 SQL 구간까지 펼쳐 보여 줍니다. 위 절차를 화면 이동 몇 번으로 수행하는 것이 활용의 핵심입니다.

OPENMARU APM은 애플리케이션 서버에 에이전트를 배포해 페이지 요청의 응답시간과 데이터베이스 쿼리 응답시간을 측정하고, 동시 사용자 수·초당 트랜잭션 수·평균 응답시간·사용 중인 커넥션 수·쿼리 응답시간을 함께 보여 줍니다(OPENMARU Cloud APM 제품 페이지). 제품 소개가 내세우는 목적도 “서비스 장애 감지”와 “장애 원인 특정 시간 단축”입니다.

그림 8. Method Tracer의 드릴다운 경로. 트랜잭션 목록(Instance ID·URL·Status·Duration·SQL Time·CPU Time) → 상세 탭(Transaction Detail·Trace·StackTrace) → Method Call(Start Time·Elapsed·Exclusive·CPUTime) 세 단계를 거치면 실행된 SQL 원문과 org.apache.catalina·springframework·dbcp로 이어지는 호출 스택까지 노출됩니다. (OPENMARU APM 제품 소개 발표 자료)

추적과 직접 맞물리는 기능은 제품 소개에서 다음과 같이 정리됩니다(Application 모니터링).

• 전거래 응답시간 분포도: 전체 거래의 응답시간과 호출 건수를 한 화면에 뿌려 주는 트랜잭션 맵(T-Map)입니다. 느린 점 무리를 드래그하면 그 구간의 트랜잭션 목록으로 곧바로 들어가므로, 1단계의 패턴 판별과 2단계의 대표 선별이 한 동작으로 이어집니다.
• 개별 트랜잭션 상세 프로파일링: 트랜잭션 한 건을 열어 호출 구간을 시각적으로 분해합니다. 어떤 쿼리가 몇 번, 각각 몇 ms 실행됐는지가 문장 단위로 보이므로 N+1 패턴과 슬로우 쿼리가 바로 드러납니다.
• 애플리케이션·SQL 쿼리 튜닝 대상 정보: 애플리케이션에 별도의 로깅 설정을 넣지 않고도 트랜잭션을 상세하게 표현해, 느린 구간과 문제가 되는 메서드를 짚어 줍니다. 코드를 고치지 않고 계측한다는 앞 절의 원리가 화면에서 이렇게 쓰입니다.
• 액티브 스레드 모니터링: 지금 수행 중인 애플리케이션 목록과 SQL 내역을 보여 줍니다. 이미 끝난 트랜잭션이 아니라 “지금 멈춰 있는” 요청을 잡을 때 쓰는 화면입니다.
• 스레드 덤프 통합 모니터링: 스레드 덤프를 URL·Duration·CPU Time 같은 모니터링 정보와 매핑해 줍니다. 4단계의 교차 확인, 즉 “이 지연이 커넥션 대기인가 락 대기인가”를 한 화면에서 가릴 수 있습니다.

여기에 응답시간·TPS·액티브 서비스 그래프의 급변 구간에서 그 시간대의 트랜잭션으로 내려가는 동선이 짧다는 점이 더해져, 경보에서 원인 후보까지 걸리는 시간이 줄어듭니다.

트랜잭션 추적은 결국 “느리다”는 증상과 “여기를 고치면 된다”는 처방 사이의 간격을 좁히는 기술입니다. 그 간격이 줄어든 만큼 장애 대응 시간이 줄고, 성능 개선 작업은 감이 아니라 데이터에서 출발하게 됩니다.

자주 묻는 질문 (FAQ)

트랜잭션 추적이란 무엇인가요?

사용자 요청 한 건이 처리되는 전체 과정을 호출 구간(span) 단위로 기록해, 어느 메서드·어느 SQL에서 시간이 걸렸는지 특정하는 기술입니다. 집계 지표가 이상을 알려 준다면, 트랜잭션 추적은 그 원인 지점을 지목합니다.

소스 코드를 수정해야 추적이 되나요?

대부분의 경우 수정하지 않아도 됩니다. Java 환경에서는 APM 에이전트가 클래스 로딩 시점에 바이트코드에 측정 코드를 자동으로 심는 바이트코드 계측 방식으로 동작합니다. 프레임워크 경계와 JDBC·HTTP 호출 지점이 자동으로 측정 대상이 됩니다.

트랜잭션 추적과 분산 추적의 차이는 무엇인가요?

트랜잭션 추적은 요청 단위 기록이라는 기술 전반을 가리키고, 분산 추적은 그 기록을 서버 경계 너머까지 잇는 확장입니다. 트레이스 ID를 HTTP 헤더로 다음 서비스에 전파해, 여러 서비스를 거친 요청을 하나의 트레이스로 묶습니다.

W3C Trace Context는 왜 필요한가요?

서로 다른 도구로 계측된 서비스 사이에서 추적이 끊기지 않게 하는 공통 헤더 규약이기 때문입니다. traceparent 헤더에 트레이스 ID를 표준 형식으로 담아, 벤더가 달라도 문맥 전파가 이어지도록 합니다.

추적 기능의 성능 부담은 없나요?

계측 범위와 표본 비율로 관리합니다. 프레임워크 경계·I/O 지점 중심의 기본 계측은 부담이 낮게 설계되며, 전 구간을 다 기록하는 대신 표본 추출로 수집량을 조절합니다. 계측 대상을 무분별하게 넓히지 않는 것이 운영 요령입니다.

참고 리소스

자사 콘텐츠 (OPENMARU)
– APM이란? 서버 지표로 못 잡는 장애, 개념부터 도입까지 — OPENMARU
– APM 핵심 지표 읽는 법 — 응답시간·TPS·에러율, 숫자 너머의 의미
– APM 트랜잭션 분석 차트 활용하기 : T-MAP
– 프롬프트로 WAS 장애 분석 — OPENMARU APM AI Agent 데모
– OPENMARU Cloud APM 제품 소개 — 클라우드 네이티브 환경에 최적화된 APM
– Application 모니터링 — 트랜잭션 맵·상세 프로파일링·SQL 튜닝 대상 정보
– OPENMARU Observability — 메트릭·로그·트레이스 통합과 마이크로서비스 토폴로지 맵
– OPENMARU APM 문서

표준·공식 문서 (외부)
– Traces — OpenTelemetry
– Trace Context — W3C Recommendation
– Pattern: Distributed Tracing — microservices.io