OpenTelemetry에 프로파일링이 추가됐어요 — 옵저버빌리티 퍼즐의 마지막 조각

트레이스, 메트릭, 로그 다음은 프로파일

OpenTelemetry(줄여서 OTel)가 프로파일링(Profiles) 기능을 퍼블릭 알파로 공개했어요. OpenTelemetry를 처음 들어보신 분도 계실 텐데요, 이게 뭐냐면 애플리케이션이 실제로 어떻게 돌아가고 있는지를 관찰하기 위한 오픈소스 표준이에요. 서버에서 에러가 났을 때 "어디서 문제가 생겼지?" 하고 추적하는 것, 응답 시간이나 CPU 사용량 같은 숫자를 모니터링하는 것, 로그를 남기는 것 — 이런 걸 통틀어 옵저버빌리티(Observability, 관측 가능성)라고 부르거든요.

지금까지 OpenTelemetry는 이 세 가지 — 트레이스(Traces, 요청 추적), 메트릭(Metrics, 수치 측정), 로그(Logs, 기록) — 를 하나의 표준으로 통합하는 데 집중해왔어요. 그런데 하나 빠진 퍼즐 조각이 있었는데요, 바로 프로파일링이에요.

프로파일링이 뭔데 이렇게 중요한가요?

프로파일링은 쉽게 말하면 "우리 애플리케이션이 시간과 자원을 어디에 쓰고 있는지"를 아주 세밀하게 들여다보는 거예요. 예를 들어볼게요. 메트릭으로는 "CPU 사용률이 80%야"라는 걸 알 수 있어요. 트레이스로는 "이 API 호출이 2초나 걸렸어"라는 걸 알 수 있고요. 그런데 "그 2초 동안 코드의 어느 함수에서 얼마만큼의 시간을 썼는지"는 프로파일링이 아니면 알기 어려워요.

프로파일은 일정 간격으로 프로그램의 콜 스택(call stack, 현재 실행 중인 함수의 호출 순서)을 캡처해서, 어떤 함수가 CPU를 많이 먹고 있는지, 메모리를 어디서 많이 할당하고 있는지를 보여줘요. 성능 병목을 찾을 때 결정적인 도구죠.

이번 알파에서 뭐가 달라졌나요?

사실 프로파일링 도구는 이미 많아요. Go의 pprof, Java의 async-profiler, 파이썬의 py-spy 같은 것들이요. 문제는 이 도구들이 각자 다른 포맷으로 데이터를 만들어내고, 트레이스나 메트릭과 연결이 안 된다는 거예요.

이번에 OTel이 한 건 바로 이 파편화를 해결하는 거예요. OTel Profiles는 프로파일 데이터를 위한 표준 데이터 모델과 OTLP(OpenTelemetry Protocol) 전송 규격을 정의했어요. 이게 의미하는 건, 언어나 런타임에 관계없이 동일한 형태로 프로파일 데이터를 수집하고, 기존의 트레이스·메트릭·로그와 같은 파이프라인에서 처리할 수 있게 된다는 거예요.

예를 들어, 트레이스에서 느린 스팬(span)을 발견했을 때, 그 시간대의 프로파일 데이터를 바로 연결해서 "아, 이 함수 내부의 JSON 파싱에서 시간을 다 썼구나"까지 한 번에 파악할 수 있게 되는 거죠. 지금까지는 트레이스 도구와 프로파일링 도구를 따로 보면서 시간대를 수동으로 맞춰봐야 했는데, 이게 자동으로 연결되는 세상이 오는 거예요.

Datadog, Grafana와는 어떤 관계인가요?

상용 APM(Application Performance Monitoring) 도구들은 이미 프로파일링을 지원하고 있어요. Datadog의 Continuous Profiler, Grafana의 Pyroscope 같은 것들이 대표적이죠. 이들은 자체 에이전트와 포맷으로 프로파일을 수집하고 있었는데요.

OTel이 프로파일링 표준을 만들면 이 시장에도 변화가 올 수 있어요. 벤더 종속 없이 프로파일 데이터를 수집하고, 원하는 백엔드로 보낼 수 있게 되니까요. 실제로 Grafana의 Pyroscope 팀도 OTel Profiles 스펙 개발에 참여하고 있고, 이 표준을 지원할 계획이라고 밝혔어요. 장기적으로는 "OTel로 한 번 계측하면 어떤 모니터링 서비스든 갈아끼울 수 있는" 상태가 되는 거죠.

한국 개발자에게 주는 시사점

아직 알파 단계라 프로덕션에 바로 적용하기는 이르지만, 방향성은 명확해요. 옵저버빌리티 스택을 구축하거나 개선할 계획이 있는 팀이라면, OTel 기반으로 가는 게 장기적으로 유리해요. 트레이스·메트릭·로그·프로파일까지 하나의 표준으로 통합되면, 도구 간 전환 비용이 크게 줄어들거든요.

특히 Go나 Java 기반 백엔드를 운영하고 있다면, 이 알파 버전을 테스트 환경에서 미리 체험해보는 것도 좋아요. 프로파일링 데이터가 트레이스와 자동으로 연결되는 경험을 해보면, 기존 디버깅 워크플로우가 얼마나 달라질 수 있는지 감이 올 거예요.

정리하면

OpenTelemetry가 트레이스·메트릭·로그에 이어 프로파일링까지 표준에 포함시키면서, 옵저버빌리티의 네 번째 기둥이 세워지기 시작했어요. 아직 알파지만, 성능 문제를 추적할 때 "어디가 느린지"에서 "왜 느린지"까지 한 번에 볼 수 있는 시대가 가까워지고 있어요.

여러분 팀은 프로파일링을 어떤 방식으로 하고 계세요? 별도 도구를 쓰고 계신가요, 아니면 아직 체계적으로 하고 있지 않으신가요?