MCP로 커널 트레이스포인트까지 연결한다고? AI 에이전트가 시스템 관측성을 바꾸는 방법

AI 에이전트가 리눅스 커널 속까지 들여다보는 시대

요즘 AI 에이전트 이야기가 정말 많죠. 코드 짜주고, 검색해주고, 이메일도 보내주고. 그런데 한 가지 흥미로운 시도가 등장했어요. AI 에이전트를 시스템 관측성(Observability) 영역에 연결하는 거예요. 그것도 리눅스 커널의 트레이스포인트(Tracepoint)까지요.

관측성이 뭐냐면, 쉽게 말해서 "시스템 내부에서 무슨 일이 벌어지고 있는지 바깥에서 들여다볼 수 있게 해주는 능력"이에요. 서버가 느려졌을 때, CPU가 왜 바쁜지, 메모리가 어디서 새는지, 네트워크 패킷이 어디서 막히는지를 파악하는 게 바로 관측성의 영역이거든요. 그리고 이걸 AI 에이전트한테 시키겠다는 거예요.

MCP, 연결의 표준이 되려는 프로토콜

여기서 핵심 역할을 하는 게 MCP(Model Context Protocol)예요. MCP는 Anthropic이 공개한 프로토콜인데, AI 모델이 외부 도구나 데이터 소스와 표준화된 방식으로 소통할 수 있게 해주는 일종의 "범용 어댑터"라고 보면 돼요. USB-C가 여러 기기를 하나의 포트로 연결해주듯이, MCP는 AI 에이전트가 다양한 도구를 하나의 규격으로 사용할 수 있게 해주는 거예요.

이번에 소개된 프로젝트는 이 MCP를 활용해서 AI 에이전트가 리눅스 커널의 트레이스포인트에 접근할 수 있도록 만든 건데요. 트레이스포인트는 리눅스 커널 코드 곳곳에 미리 심어둔 "관측 지점"이에요. 커널이 스케줄링을 할 때, 메모리를 할당할 때, 네트워크 패킷을 처리할 때마다 이 지점에서 이벤트를 뿜어내거든요. 기존에는 perf, ftrace, bpftrace 같은 전문 도구를 직접 다뤄야 했는데, 이제 AI 에이전트한테 "지금 CPU 스케줄러에서 뭔 일이 일어나고 있는지 봐줘"라고 자연어로 요청할 수 있게 되는 거예요.

구체적으로 어떻게 동작하나

구조를 좀 더 들여다보면, MCP 서버가 중간에서 브릿지 역할을 해요. AI 에이전트가 MCP 클라이언트를 통해 "트레이스포인트 목록 보여줘" 같은 요청을 보내면, MCP 서버가 이걸 받아서 실제 커널 인터페이스에 접근하고, 결과를 다시 에이전트가 이해할 수 있는 형태로 돌려주는 방식이에요.

기존 방식과 뭐가 다르냐면, 전통적으로 시스템 엔지니어가 bpftrace -e 'tracepoint:sched:sched_switch { printf(...) }' 같은 명령어를 직접 작성해야 했어요. BPF 프로그램의 문법도 알아야 하고, 어떤 트레이스포인트가 있는지도 외우고 있어야 하고, 출력 결과도 직접 해석해야 했죠. 이걸 MCP 인터페이스로 감싸면, AI 에이전트가 자연어 요청을 받아서 적절한 트레이스포인트를 선택하고, 데이터를 수집하고, 결과를 사람이 읽기 쉬운 형태로 정리해서 보여줄 수 있는 거예요.

특히 흥미로운 점은 에이전트가 단순히 명령어를 대신 실행하는 게 아니라, 수집된 데이터를 맥락 안에서 해석할 수 있다는 거예요. 예를 들어 "왜 이 프로세스가 자꾸 CPU를 양보하는 거야?"라고 물으면, 스케줄러 트레이스포인트 데이터를 보고 "이 프로세스가 I/O 대기 때문에 자발적으로 스케줄링되고 있네요. 디스크 접근 패턴을 확인해보세요"라고 답할 수 있는 거죠.

업계 맥락: 관측성 + AI의 큰 흐름

이건 사실 더 큰 흐름의 일부예요. Datadog, Grafana, New Relic 같은 관측성 플랫폼들도 AI 기반 분석 기능을 빠르게 추가하고 있거든요. Datadog의 Bits AI, Grafana의 AI 어시스턴트 등이 대표적이에요. 하지만 이런 상용 플랫폼들은 대부분 애플리케이션 레벨 메트릭에 집중하는 편이에요. 커널 레벨까지 내려가서 트레이스포인트에 직접 접근하는 건 좀 다른 이야기예요.

또 하나 주목할 점은 MCP 생태계 자체의 확장이에요. MCP가 처음 나왔을 때는 주로 파일 시스템이나 데이터베이스, API 호출 같은 데 쓰였는데, 이제 커널 수준의 시스템 프로그래밍 영역까지 확장되고 있다는 건 이 프로토콜의 범용성이 실제로 검증되고 있다는 뜻이기도 해요.

eBPF(커널에서 안전하게 프로그램을 실행하는 기술) 진영에서도 비슷한 움직임이 있어요. eBPF 기반 도구들이 점점 추상화 수준을 높이면서, 전문가가 아니어도 커널 관측 데이터를 활용할 수 있게 만들려는 노력이 계속되고 있거든요. AI 에이전트와의 결합은 그 자연스러운 다음 단계라고 볼 수 있어요.

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

솔직히 말하면, 대부분의 웹 개발자에게 커널 트레이스포인트는 일상적으로 접할 일이 별로 없어요. 하지만 SRE(사이트 신뢰성 엔지니어)나 인프라 엔지니어라면 이야기가 달라져요. 장애 상황에서 원인을 빠르게 파악해야 할 때, AI 에이전트가 커널 레벨 데이터까지 뒤져서 인사이트를 주는 건 정말 실용적인 시나리오거든요.

그리고 MCP 자체를 배워두는 건 꽤 가치가 있어요. 지금 AI 에이전트 생태계에서 MCP가 빠르게 표준 위치를 잡아가고 있기 때문에, MCP 서버를 만들 줄 아는 것 자체가 하나의 기술 역량이 되어가고 있어요. 사내 도구나 모니터링 시스템에 MCP 인터페이스를 붙여서 AI 에이전트가 접근할 수 있게 만들면, 팀 전체의 생산성을 크게 올릴 수 있을 거예요.