[발표자료 다운로드] Observability Platform – eBPF로 코드 수정 없이 다양한 언어로 개발된 서비스 모니터링

애플리케이션 대신 리눅스 커널에서 수집하면 에이전트 설치, 개발팀 협의, 재기동이 함께 빠진다. 이 발표자료의 메시지는 이 한 문장이다.

전체 31장, PDF로 31쪽이다. MSAP.ai 옵저버빌리티 세미나의 첫 번째 세션 자료로, 개념, 문제, 해결, 데모, 정리 다섯 부분으로 나뉜다. 마지막에는 도입 전 확인 항목 네 가지와 적용 순서 네 단계를 실었다.

수치와 연표는 ebpf.io, OpenTelemetry, Grafana Labs 조사와 사내 운영 노드 실측을 근거로 정리했고 장마다 바닥글에 출처를 적었다.

운영팀 내부 검토나 개발팀 설명 자료로 바로 쓸 수 있도록 PDF로 공개한다.

이 세션만 다룬 영상은 아직 없다. 대신 같은 eBPF 수집 방식을 쓰는 MSAP.ai Observability의 전체 기능을 30분 동안 보여 주는 개요 영상을 소개한다.

세션 자료가 왜 커널에서 수집하는지를 설명한다면 개요 영상은 그렇게 모은 데이터를 화면에서 어떻게 쓰는지 보여 준다. 아래 영상은 이 세션의 녹화가 아니라 같은 제품의 기능 개요 편이다.

영상에서 다루는 순서는 다음과 같다.

• Observability가 필요한 이유와 SLI·SLO·에러 예산
• eBPF 기반 Zero-Instrument 수집과 APM 비교
• 토폴로지, 분산 추적, 프로파일링, 로그 화면
• 서버·GPU·DB 모니터링과 AI 기반 원인 분석

쿠버네티스 관측성의 전체 구조는 쿠버네티스 관측성, OpenTelemetry, 분산 추적에서 함께 볼 수 있다.

운영팀이 eBPF 기반 수집을 검토할 때 반복해서 묻는 질문을 기준으로 슬라이드를 배치했다.

1. 에이전트 방식 APM 도입은 왜 몇 달씩 걸리는가
2. 모니터링과 Observability는 무엇이 다른가
3. 커널 안에서 프로그램을 실행해도 운영 서비스에 안전한가
4. 소스가 없는 레거시와 상용 패키지도 보이는가
5. 노드 에이전트는 자원을 얼마나 쓰고, 무엇을 못 보는가
6. 도입 전에 무엇을 확인하고 어떤 순서로 넓히는가

흔히 겪는 일정 예시로 시작한다. 3월 초에 APM 도입을 결정했는데 5월 중순에야 서비스 47개 중 6개가 보이기 시작했다. 나머지 41개는 적용 일정도 잡지 못했다.

시간이 걸린 단계는 제품 선정이나 설치가 아니다. 개발팀 요청, 팀별 일정 조율, 배포 일정에 맞춘 재기동 대기가 대부분을 차지했다.

▲ 시간 대부분이 개발팀 요청·일정 조율·배포 대기에 쓰임 (발표자료 3쪽)

3개월을 반나절로 줄이려면 에이전트 설치, 개발팀 협의, 애플리케이션 재기동이 빠져야 한다. 이 세 작업이 빠지면 관측 시작 시점이 서비스 배포 일정과 분리되고, 운영팀이 도입 시점을 직접 정한다.

세 조건을 함께 만족하는 방법이 애플리케이션 대신 리눅스 커널에서 데이터를 수집하는 방식이다.

▲ 세 작업이 빠지면 관측 시작 시점이 서비스 배포 일정과 분리됨 (발표자료 4쪽)

모니터링은 CPU가 80%를 넘으면 알리는 식으로 이미 아는 문제만 잡는다. Observability는 어제 새벽 지연이 어느 서비스에서 시작됐는지처럼 미리 정하지 않은 질문까지 추적한다.

CNCF TAG Observability 백서는 이를 외부로 나오는 데이터로 시스템 내부 상태를 추론하는 능력으로 정의한다. 서버에 접속하지 않고 시스템이 내보내는 데이터만으로 원인을 좁힌다.

▲ Observability 는 예상하지 못한 장애에도 원인을 좁힐 수 있음 (발표자료 6쪽)

메트릭은 무엇이 이상한지, 로그는 무슨 일이 있었는지, 트레이스는 어느 서비스 구간에서 지연됐는지, 프로파일링은 코드의 어느 부분이 느린지를 보여 준다.

메트릭으로 이상을 찾고 트레이스와 로그, 프로파일링으로 위치를 좁히는 순서다. Grafana Labs 2025 조사에서 프로파일링을 쓰는 조직은 16%에 그쳤다. 네 신호가 한 화면에서 이어져야 원인까지 도달한다. MSAP.ai는 한 번 수집한 L7 요청을 APM 집계와 토폴로지 연결선, 보안 탐지가 나눠 써서, 도구 세 개를 쓸 때처럼 같은 데이터를 세 번 수집하지 않는다.

▲ 메트릭으로 이상을 찾고 트레이스·로그·프로파일링으로 위치를 좁힘 (발표자료 7쪽)

eBPF는 커널 소스를 고치거나 커널 모듈을 넣지 않고 커널 안에서 작은 프로그램을 실행하는 기술이다. 어떤 언어든 네트워크로 요청을 보내거나 파일을 읽으려면 커널을 지난다.

eBPF는 그 지점에서 네트워크, 시스템 콜, 프로세스 이벤트를 관찰하고 지나가는 데이터의 복사본만 읽는다. Cilium과 Falco 같은 쿠버네티스 도구도 이미 이 기술을 쓴다.

▲ 언어와 상관없이 모든 요청과 시스템 콜이 커널을 지나감 (발표자료 8쪽)

eBPF 프로그램은 바이트코드로 컴파일된 뒤 Verifier 검사를 통과해야 JIT로 번역되어 훅에 연결된다. 수집한 데이터는 Map을 통해 사용자 영역으로 전달된다.

Verifier는 반드시 끝나는 프로그램인지, 범위 밖 메모리에 접근하지 않는지, 크기와 복잡도가 상한 안인지, 로드 권한이 있는지를 본다. 다만 커널 안정성을 지키는 안전성 검사이고, 프로그램의 의도를 판정하는 보안 검사 도구는 아니다.

▲ Verifier 가 로드 전에 무한 루프와 범위 밖 메모리 접근을 거부함 (발표자료 9쪽)

2014년 eBPF가 리눅스 커널의 범용 기능으로 확장됐다. 2024년 OpenTelemetry가 프로파일링 신호를 발표했고 Elastic이 eBPF 프로파일러를 기증했다.

2025년 5월 Grafana Beyla가 기증되어 OpenTelemetry eBPF Instrumentation(OBI)이 됐고, 2026년 OBI가 v1.0에 도달했다. 코드 수정 없는 수집이 특정 벤더에 묶이지 않는 공통 방식으로 자리 잡고 있다.

▲ 코드 수정 없는 eBPF 수집이 OpenTelemetry 공식 프로젝트가 됨 (발표자료 10쪽)

Java는 -javaagent 실행 옵션을 바꾸고 재기동한다. Python은 계측 패키지를 설치하고 실행 명령을 래퍼로 바꾼다. Node.js는 다른 의존성보다 먼저 로드되도록 순서를 맞추고, Go는 소스에 SDK를 직접 넣는다.

작업 하나는 어렵지 않다. 서비스 47개에 언어가 네 가지라면 네 종류의 작업을 47번 해야 한다는 점이 문제다.

▲ 작업 하나는 쉽지만 서비스 수만큼 반복됨 (발표자료 12쪽)

계측 작업 자체는 서비스당 30분이면 끝난다. 그 30분을 위해 개발팀에 요청하고, 백로그 순서를 기다리고, 배포 일정을 기다린다. 재기동 때문에 운영팀 승인을 받아야 하고, 담당자가 없는 레거시는 손대기 어렵다.

Grafana Labs 조사에서 옵저버빌리티 도입의 가장 큰 걸림돌로 복잡성과 오버헤드를 꼽은 응답은 2025년 39%, 2026년 38%였다. 새 서비스가 들어올 때마다 같은 협의가 반복된다. 계측에는 기동 옵션 변경과 재배포가 따르므로 변경 심의, 야간 배포 창구, 되돌림 계획까지 함께 준비해야 한다.

▲ 관측 시작 시점이 서비스 조직의 배포 일정에 묶임 (발표자료 13쪽)

애플리케이션 계층은 언어마다 작업이 다르고 레거시는 계측할 수 없다. 컨테이너와 운영체제 계층은 자원 지표 정도만 보여 준다.

리눅스 커널에는 모든 요청과 시스템 콜이 지나가므로 여기에 eBPF 노드 에이전트를 두면 언어와 무관하게 수집된다. 쿠버네티스에서는 DaemonSet으로 노드마다 하나씩 배포하고 애플리케이션은 바뀌지 않는다.

▲ 모든 통신이 커널을 지나므로 언어별 계측이 필요 없음 (발표자료 15쪽)

서비스마다 붙일 것이 없고 노드에 한 번만 설치한다. 코드와 실행 옵션을 건드리지 않으니 개발팀에 요청할 일이 없고, 배포 창을 기다리지 않고 운영 중인 서비스에 바로 적용된다.

사내 제품 소개 자료 기준으로 도입 기간은 수주에서 수개월이던 것이 수시간 단위로 줄어든다.

▲ 개발팀 일정과 관계없이 운영 중에 바로 적용 가능함 (발표자료 16쪽)

커널은 그 위에서 어떤 언어가 돌아가는지 알 필요가 없다. Java, Go, Python, Node.js는 물론 .NET, PHP, Ruby, C·C++ 서비스도 같은 방식으로 수집한다.

언어가 늘어도 수집 작업은 늘지 않는다. OpenTelemetry eBPF Instrumentation도 공식 지원 언어가 9종이다.

▲ 새 언어로 만든 서비스도 배포되는 즉시 목록에 나타남 (발표자료 17쪽)

담당자와 소스가 사라진 오래된 jar 파일도 재빌드 없이 수집된다. SDK를 넣을 수 없는 벤더 프로그램과 에이전트를 설치하지 않은 DB도 노드 위에서 통신하면 같은 화면에 나타난다.

HTTP, gRPC, MySQL, PostgreSQL, Oracle, Redis, Kafka 같은 주요 프로토콜을 자동으로 인식한다. 클러스터 밖 외부 API는 우리 서비스가 호출하는 구간까지만 보인다. 상용 미들웨어, 협력사 모듈, 이미지로만 받은 서드파티처럼 소스를 고칠 수 없는 영역은 그동안 계측 대상에서 빠졌는데, 장애는 대체로 이런 곳에서 난다.

▲ SDK 를 넣을 수 없는 프로그램도 통신만 하면 같은 화면에 나타남 (발표자료 18쪽)

1단계는 어떤 프로토콜인지 알아보는 감지, 2단계는 SQL 문장과 HTTP 경로, Kafka 토픽을 읽는 요청 해독, 3단계는 바인드 값과 응답 크기, DB 오류 코드까지 읽는 값 해독이다.

많은 eBPF 도구가 2단계까지 지원한다. 느린 쿼리를 실제 값과 함께 재현하려면 3단계가 필요하므로, 도구를 비교할 때는 지원 목록보다 해독 단계를 확인한다. MSAP.ai 노드 에이전트는 Oracle TNS를 해독해 SQL과 바인드 값, ORA- 오류를 보여 주며 Oracle 12c 이상이 대상이다. 바인드 값 수집은 설정으로 끌 수 있고, 파서 무작위 입력 시험에서 PostgreSQL 150만 회, Oracle 186만 회를 중단 없이 실행했다.

▲ 해독 깊이에 따라 DB 장애 분석 속도가 달라짐 (발표자료 19쪽)

첫째, Verifier가 무한 루프나 잘못된 메모리 접근이 있는 코드를 실행 전에 거부한다. 둘째, 요청을 가로채거나 바꾸지 않고 복사본만 읽는다. 셋째, 애플리케이션 프로세스 밖에서 동작해 힙, 스레드, GC에 관여하지 않는다.

Google, Meta, Netflix 같은 대규모 운영 환경도 eBPF 위에서 돌아간다. 다만 노드 에이전트는 높은 권한(privileged)으로 실행되므로 도입 전에 보안 검토를 거친다. MSAP.ai는 에이전트를 노드 에이전트(커널 권한), 클러스터 에이전트(쿠버네티스 읽기 권한), 선택형 DB 에이전트(DB 계정)로 나눠 검토 범위를 좁힌다.

▲ 검사를 통과한 코드만 읽기 전용으로 프로세스 밖에서 동작함 (발표자료 20쪽)

사내 운영 노드 실측(2026년 7월)에서 노드 에이전트의 상시 CPU 사용량은 72코어 노드에서 평균 0.61코어였다. 128코어 노드에서 기동 순간 최고치는 14.7코어에서 0.86코어로 낮췄다.

수집이 애플리케이션 처리 경로 밖에서 일어나 응답 시간은 늘지 않는다. 부하는 프로브를 건 이벤트 빈도에 비례하므로 일부 노드에서 먼저 켜고 넓힌다. 상시 CPU는 개선 전 평균 0.82코어에서 0.61코어로 줄었고, 941Mi 가운데 약 500MB는 커널 eBPF 맵과 메모리에 올린 실행 파일이다. CPU가 부족한 순간에는 일부 통계가 빠질 수 있다.

▲ 상시 부담이 작아 운영 노드에 계속 켜 둘 수 있음 (발표자료 21쪽)

주문번호 같은 업무 식별자, 코드 안에서 정의한 커스텀 스팬과 비즈니스 이벤트는 커널에서 알 수 없다. Java처럼 암호화를 자체 방식으로 처리하는 서비스의 HTTPS 본문도 읽지 못한다.

eBPF가 한 번에 읽는 양은 4,096바이트까지라 긴 요청은 뒷부분이 잘리는데, 이때는 그럴듯한 값을 채우지 않고 표시하지 않는다. 잠금 대기나 느린 쿼리 통계 같은 DB 내부 지표도 네트워크 관측으로는 알 수 없어 DB 계정으로 따로 수집한다.

전체 서비스는 노드 에이전트로 기본 수집하고, 깊이가 필요한 서비스에만 OpenTelemetry SDK를 붙이면 같은 화면에서 보완된다.

▲ 업무 식별자와 일부 암호화 구간은 커널에서 읽을 수 없음 (발표자료 22쪽)

데모 환경은 서비스가 서로 호출하는 쇼핑몰이다. 게이트웨이는 .NET, 주문과 회원은 Java, 상품은 Go, 재고는 Ruby, 결제는 Node.js, 배송은 Python, 알림은 PHP로 만들었고 MySQL과 Redis가 붙어 있다.

각 노드에는 eBPF 에이전트만 설치했고 서비스 쪽에는 SDK도 에이전트도 넣지 않았다.

▲ 언어가 다른 서비스 8개와 DB·캐시를 노드 에이전트 하나로 수집함 (발표자료 24쪽)

데모는 세 장면으로 구성된다. 첫째, Go 상품, Python 배송, Node.js 결제, Java 회원 서비스를 코드 수정 없이 본다. 둘째, 손대지 않은 MySQL에서 실행된 실제 쿼리와 호출 서비스, 응답 시간을 본다. 셋째, 처리량과 응답 시간, 오류율을 한 화면에 모은 APM 대시보드를 본다.

서비스 화면마다 메트릭, 로그, 트레이스, 프로파일이 탭으로 이어져 언어를 몰라도 같은 순서로 원인을 좁힌다.

▲ 서비스·DB·전체 현황을 화면 전환 없이 한 제품 안에서 확인함 (발표자료 25쪽)

가장 큰 차이는 보이는 범위와 작업량 두 가지다.

▲ 보이는 범위가 적용한 서비스에서 노드 위 전체 서비스로 넓어짐 (발표자료 28쪽)

도입 전에 확인할 항목은 네 가지다. 노드의 리눅스 커널 버전이 제품 지원 범위에 드는지, privileged 권한 승인을 받았는지, CPU 아키텍처가 amd64·arm64인지, 배포 방식이 Helm·DaemonSet 또는 Docker Compose인지 본다.

eBPF 프로그램을 미리 컴파일해 실행 파일에 담기 때문에 BTF(커널 디버그 정보)가 필요 없고, 오래된 배포판에서도 커널 교체가 선행 과제가 되지 않는다. Go 서비스는 Go 1.17 이상이고 심볼을 제거하지 않은 바이너리여야 언어가 Go로 표시된다.

적용은 일부 노드 설치, 수집 데이터와 자원 사용량 확인, 전체 노드 확대, 업무 식별자가 필요한 서비스만 OpenTelemetry SDK 병행 순서다.

▲ 커널 버전과 권한 정책만 먼저 맞추면 설치는 Helm 한 번으로 끝남 (발표자료 29쪽)

모니터링 도입이 여러 팀과 협의하는 프로젝트에서 노드에 에이전트를 한 번 설치하는 작업으로 바뀐다. 코드 수정과 재기동 없이 노드 위의 모든 서비스를 수집하고, 업무 식별자처럼 커널에서 보이지 않는 부분만 SDK로 보완한다.

모든 서비스가 보이면 다음 질문은 장애 원인을 얼마나 빨리 찾느냐다. 다음 세션은 마이크로서비스 장애의 원인 서비스를 AI 분석으로 찾는 과정을 다룬다.

eBPF란 무엇인가

리눅스 커널을 고치지 않고 커널 안에서 작은 프로그램을 안전하게 실행하는 기술이다. 모든 요청과 시스템 콜이 지나가는 커널에서 네트워크와 프로세스 이벤트를 관찰한다.

eBPF 수집은 운영 서비스에 안전한가

Verifier를 통과한 코드만 읽기 전용으로 애플리케이션 프로세스 밖에서 동작한다. 다만 노드 에이전트가 높은 권한으로 실행되므로 도입 전에 보안 검토가 필요하다.

코드 수정 없이 어떤 언어를 수집할 수 있는가

Java, Go, Python, Node.js, .NET, PHP, Ruby, C·C++ 서비스를 같은 방식으로 수집한다. 커널은 그 위에서 어떤 언어가 돌아가는지 알 필요가 없다.

노드 에이전트는 자원을 얼마나 쓰는가

사내 운영 노드 실측에서 72코어 노드 기준 평균 0.61코어, 메모리 473Mi~941Mi를 썼다. 부하는 프로브를 건 이벤트 빈도에 비례한다.

eBPF로 보이지 않는 것은 무엇인가

주문번호 같은 업무 식별자와 커스텀 스팬, 자체 암호화를 쓰는 HTTPS 본문이다. 필요한 서비스에만 OpenTelemetry SDK를 붙여 같은 화면에서 보완한다.

도입은 어떤 순서로 진행하는가

커널 버전, 권한, CPU 아키텍처, 배포 방식을 확인한 뒤 일부 노드에 설치한다. 수집 데이터와 자원 사용량을 확인하고 전체 노드로 넓힌다.

MSAP.ai 자료

• 쿠버네티스 관측성, OpenTelemetry, 분산 추적
• 코드 수정 없이 쿠버네티스 운영 상태 진단 (Observability)
• AI Native Observability 완전 가이드 — Zero-Instrument부터
• AI 장애 원인 분석 실전 데모 — 알람에서 조치까지
• AI로 쿠버네티스 노드 상태 확인하는 방법
• AI Native 옵저버빌리티로 5분 내에 장애 원인 찾는 3가지 방법

외부 공개 자료

• ebpf.io — What is eBPF?
• Linux Kernel 문서 — eBPF verifier
• CNCF TAG Observability — Observability Whitepaper
• OpenTelemetry — eBPF Instrumentation(OBI)
• OpenTelemetry — OBI v1.0 릴리스
• Grafana Labs — Observability Survey 2025
• InfoQ — Netflix의 eBPF 기반 noisy neighbor 탐지

모니터링과 Observability의 차이, eBPF 로드 과정과 표준화 연표, 언어별 계측 작업과 조직 협의 비용, 커널 수집 구조와 노드 에이전트 실측 자원, 두 방식 비교표와 도입 순서가 PDF 한 파일에 들어 있다. 아래 버튼에서 31쪽 발표자료 PDF를 내려받을 수 있다.