에이전틱 관측성 (Agentic Observability): Dynatrace MCP를 사용하여 단 몇 분 만에 실제 앱을 연결하는 방법

모든 엔지니어링 팀은 조만간 똑같이 짜증 나는 문제에 직면하게 됩니다. 모니터링은 무언가 고장 났다는 사실을 알려주지만, 보통 거기서 끝납니다. 에러율 (Error rates)을 볼 수 있고, 지연 시간 급증 (Latency spikes)을 볼 수 있으며, 실패한 요청 (Failed requests)을 볼 수 있습니다. 하지만 장애 발생 시 정말 중요한 질문들은 여전히 답을 찾지 못한 상태로 남는 경우가 많습니다.

이 서비스의 소유자는 누구인가? 무엇이 이 서비스에 의존하고 있는가? 런북 (Runbook)은 어디에 있는가? 어떤 Slack 채널을 사용해야 하는가? 이것이 실제 장애인가, 아니면 이미 알려진 실패 모드 (Failure mode)인가?

이러한 격차 때문에 저는 이 작은 에이전틱 관측성 (Agentic Observability) 데모를 구성하게 되었습니다. 저는 아주 작은 쇼핑 앱을 만들고, 이를 OpenTelemetry로 계측 (Instrumented)한 뒤, 텔레메트리 (Telemetry) 데이터를 Dynatrace로 전송했습니다. 그리고 Port를 컨텍스트 레이어 (Context layer)로 사용하여 운영 신호 (Operational signals)를 엔지니어링 지식과 연결할 수 있도록 했습니다. 그 결과 훨씬 더 유용한 트러블슈팅 (Troubleshooting) 워크플로우가 만들어졌습니다. 대시보드를 뚫어지게 쳐다보며 추측하는 대신, 무엇이 일어나고 있는지 물어보고 실시간 상태 데이터와 인간의 컨텍스트 (Human context)를 한 곳에서 모두 받아볼 수 있게 되었습니다.

이 설정은 의도적으로 작게 구성되었지만, 실제 시스템에서 발생하는 혼란스러운 상황을 매우 잘 반영하고 있습니다. 앱에는 상품, 장바구니, 결제 흐름이 포함되어 있으며, 몇 가지 내장된 실패 시나리오가 있어 관측성 (Observability) 스토리가 실제로 흥미로운 내용을 드러낼 수 있도록 했습니다.

오늘날 관측성의 진짜 문제

전통적인 관측성 (Observability)은 탐지 (Detection)에는 능숙합니다. 서비스가 건강하지 않다거나, 응답 시간이 증가하고 있다거나, 실패가 늘어나고 있다는 것을 알려줄 수 있습니다. 물론 그것은 가치 있는 일입니다. 하지만 장애 대응 (Incident response) 과정에서 탐지는 시작점에 불과합니다.

고통스러운 부분은 그 직후부터 시작됩니다.

어느 팀이 해당 서비스를 소유하고 있는지 알아야 합니다.
서비스 티어 (Service tier)가 무엇인지, 비즈니스에 핵심적인지(Business critical) 알아야 합니다.
업스트림 (Upstream) 및 다운스트림 (Downstream) 의존성을 이해해야 합니다.
적절한 런북 (Runbook)이 필요합니다.
문제를 해결할 수 있는 사람들에게 어떻게 연락해야 하는지 알아야 합니다.
이 이상 징후 (Anomaly)가 예상된 것인지, 우발적인 것인지, 아니면 테스트의 일부인지 이해할 수 있는 충분한 컨텍스트 (Context)가 필요합니다.

이 지점에서 **에이전틱 관측성 (Agentic Observability)**이 흥미로워집니다. 목표는 단순히 텔레메트리 (Telemetry)를 수집하는 것이 아닙니다. 목표는 텔레메트리를 시스템 주변의 운영 및 조직적 컨텍스트와 연결함으로써 실행 가능한 상태 (Actionable)로 만드는 것입니다.

[

]

데모 아키텍처 개요

[

]

데모를 의도적으로 단순하게 유지했습니다. 세 가지 주요 구성 요소만 포함되어 있지만, 이들이 결합되어 단일 도구가 제공하는 것보다 훨씬 강력한 워크플로우를 생성합니다.

현실적인 사용자 행동과 장애를 시뮬레이션하는 Flask 쇼핑 앱.
트레이스 (Traces)를 수집하고 서비스 상태, 지연 시간 (Latency), 로그, 에러를 분석하는 Dynatrace.
서비스 소유권, 티어, 런북, Slack 채널 및 관련 메타데이터를 저장하는 컨텍스트 레이어 (Context layer)로서의 Port.

관측성 플랫폼과 컨텍스트 레이어 사이의 연결점은 Port의 MCP 커넥터입니다. 저는 이를 사용하여 Dynatrace MCP 서버를 연결했으며, 이를 통해 Port가 엔지니어링 컨텍스트에 기반을 두면서도 실시간 모니터링 데이터에 접근할 수 있도록 했습니다.

이러한 조합이 바로 이번 버전의 에이전틱 관측성 (Agentic Observability) 뒤에 숨겨진 핵심 아이디어입니다. Dynatrace는 기술적으로 무엇이 일어나고 있는지 알고, Port는 해당 서비스가 조직 내에서 무엇을 의미하는지 알고 있습니다.

내가 만든 것: 아주 작은 Flask 이커머스 앱

애플리케이션 자체는 의도적으로 소박하게 만들었습니다. 몇 가지 일반적인 사용자 동작을 포함하는 작은 이커머스(e-commerce) 스타일의 서비스입니다:

상품 브라우징 (Browsing products)
장바구니에 아이템 추가 (Adding items to the cart)
결제 (Checking out)
주문 내역 확인 (Viewing orders)

이것은 프로덕션급(production-grade) 커머스 소프트웨어를 목표로 한 것이 아닙니다. 실제 서비스처럼 동작하고 흥미로운 텔레메트리(telemetry)를 생성할 수 있을 만큼만 현실적일 뿐입니다.

또한 흐름 속에 가짜 트래픽과 가짜 장애를 추가했습니다. 이는 모든 것이 항상 초록색(정상)으로 유지되는 완벽한 데모를 원하지 않았기 때문에 중요했습니다. 실제 시스템은 지저분한 방식으로 실패하며, 훌륭한 에이전틱 관측성 (Agentic Observability) 설정은 그러한 혼란을 이해할 수 있도록 도와야 합니다.

어떤 결제 흐름은 성공하고, 어떤 것은 실패합니다. 일부 트래픽은 인위적으로 생성됩니다. 핵심은 도구가 탐지하고 설명할 수 있는 의미 있는 무언가가 있도록 충분한 활동을 생성하는 것입니다.

1단계: OpenTelemetry를 사용하여 앱을 자동 계측 (Auto-instrument) 하기

첫 번째 레이어는 계측 (instrumentation)입니다. 저는 Flask 앱을 OpenTelemetry로 감싸서 요청이 자동으로 트레이스 (traces)를 방출하도록 했습니다. 모든 엔드포인트(endpoint)마다 일일이 커스텀 트레이싱 로직을 작성할 필요가 없었습니다. 덕분에 설정이 더 깔끔해졌고, 실제 서비스를 빠르게 계측하고 싶은 방식에 더 가까워졌습니다.

이 설정이 완료되면, 상점을 통과하는 모든 요청은 다음과 같은 텔레메트리 (telemetry) 데이터를 생성할 수 있습니다:

요청 트레이스 (Request traces)
에러 (Errors)
지연 시간 정보 (Latency information)
애플리케이션 흐름 주변의 운영 신호 (Operational signals)

이것이 기초입니다. 이것 없이는 앱이 실제로 무엇을 하고 있는지에 대한 가시성 (visibility)이 확보되지 않습니다.

2단계: Dynatrace로 트레이스 스트리밍하기

계측 후에 트레이스는 Dynatrace로 직접 스트리밍됩니다. Dynatrace는 서비스를 자동으로 감지하고 실시간으로 애플리케이션의 상태를 추적하기 시작합니다.

이 데모를 위해, 저는 다음과 같은 것들을 빠르게 확인할 수 있었습니다:

활성 모니터링 워크로드 (monitored workload)로 나타나는 서비스
생성된 활동으로 인한 트래픽 급증 (Traffic spikes)
의도적인 체크아웃 실패 시 발생하는 에러 동작
시간에 따른 지연 시간 (Latency) 및 서비스 수준 패턴

이 부분은 전형적인 관측성 (Observability)입니다. Dynatrace는 관측성 플랫폼이 해야 할 일을 정확히 수행하고 있습니다. 즉, 신호 (signals)를 수집하고, 이를 분석하며, 비정상적인 동작을 가시화하는 것입니다.

하지만 다시 말하지만, 단순한 가시성 (visibility)만으로는 충분하지 않습니다.

3단계: Port에서 누락된 컨텍스트 (context) 추가하기

여기서부터 상황이 훨씬 더 유용해집니다.

저는 Port에서 서비스를 모델링했습니다. Port는 에이전틱 개발자 플랫폼 (agentic developer platform) 역할을 하며, 이 설정에서 Dynatrace로부터 들어오는 텔레메트리 (telemetry) 위의 컨텍스트 레이어 (context layer)로 작동합니다. 이 컨텍스트에는 엔지니어가 장애 발생 시 보통 수동으로 찾아다녀야 하는 종류의 정보들이 포함됩니다.

서비스에 대해 다음과 같은 세부 정보를 저장했습니다:

서비스 소유자 (Owner)
티어 (Tier) 또는 중요도 수준
환경 (Environment)
런북 (Runbook)
커뮤니케이션을 위한 Slack 채널
서비스와 관련된 의존성 (Dependencies)

이것이 사고 대응 (incident response)에서 누락되었던 나머지 절반입니다. 지표 (metric)가 빨간색으로 변했을 때, 저는 보물찾기를 시작하고 싶지 않습니다. 운영 신호 (operational signal)와 인적 컨텍스트 (human context)가 하나로 결합되어 있기를 원합니다.

Dynatrace MCP 서버가 워크플로에 통합되는 방식

Port MCP 커넥터 (connector)가 모든 것을 하나로 묶어주는 역할을 합니다. 저는 이를 사용하여 Dynatrace MCP 서버를 Port에 연결했습니다. 이는 Port가 필요할 때 Dynatrace에 접근하여 컨텍스트 쿼리 (contextual query)의 일부로 실시간 모니터링 데이터를 가져올 수 있음을 의미합니다.

이것이 중요한 이유는 이제 제가 머릿속으로 서로 연결되지 않은 도구들 사이를 번갈아 가며 오갈 필요가 없기 때문입니다. 대신, Port는 다음을 결합할 수 있습니다:

자체 서비스 메타데이터 (service metadata)
소유권 및 운영 세부 정보 (ownership and operational details)
Dynatrace의 실시간 상태 정보 (live health information)
에이전틱 쿼리 (agentic queries)를 통해 반환된 관련 답변

Port는 API, GitOps, 코드형 인프라 (infrastructure-as-code), 웹 통합 및 MCP 서버를 포함한 다양한 데이터 소스 패턴을 지원합니다. 이번 데모에서는 Dynatrace MCP 통합이 핵심적인 부분이었는데, 이를 통해 관측성 데이터 (observability data)와 서비스 컨텍스트 (service context)를 직접 연결할 수 있었기 때문입니다.

[

]

앱 실행 및 장애 발생시키기

쇼핑 앱이 로컬에서 실행된 후, 저는 일반적인 경로들을 테스트했습니다: 제품 탐색, 장바구니 담기, 그리고 결제 진행입니다. 또한 가짜 사용자 활동을 생성하고 결제 과정 중에 의도적으로 장애를 발생시켰습니다.

이를 통해 제가 원했던 정확한 형태의 혼합된 운영 상황이 만들어졌습니다:

정상적인 요청 (Normal requests)
확인된 주문 (Confirmed orders)
주기적인 장애 (Periodic failures)
시간에 따른 트래픽 증가 (Traffic increases over time)

[

]

주문 보기 화면에서 합성 트래픽 (synthetic traffic)과 장애가 발생함에 따라 시스템 상태가 변하는 것을 확인할 수 있었습니다. Dynatrace에서는 서비스 활동이 스파이크 (spikes)와 행동 변화로 나타났습니다. 이를 통해 전체 에이전틱 관측성 (Agentic Observability) 흐름이 실제로 무슨 일이 일어나고 있는지 설명할 수 있는지 테스트할 수 있는 충분한 신호를 얻었습니다.

에이전틱 쿼리 (agentic query) 경험은 어떤 모습인가

Dynatrace와 Port를 연결한 후, 저는 대시보드와 문서들을 일일이 수동으로 조합하는 대신 서비스에 대해 일상 언어(plain-language)로 질문할 수 있었습니다.

저는 데모 서비스에 어떤 일이 일어나고 있는지 시스템에 질의했습니다. 그러자 Port 내부의 네이티브 채팅 경험인 Port AI가 Port와 Dynatrace 양쪽 모두에서 데이터를 병렬로 수집하기 시작했습니다.

이것은 중요한 세부 사항입니다. 단순히 하나의 정적인 메타데이터 레코드에서 답변을 가져오는 것이 아니었습니다. 시스템은 두 가지 서로 다른 종류의 정보를 결합하고 있었습니다:

소유자(owner), 티어(tier), 환경(environment), 런북(runbook), 커뮤니케이션 채널(communication channel)과 같은 Port의 엔티티 컨텍스트 (Entity context)
트래픽(traffic), 최근 동작(recent behavior), 장애(failures)와 같은 Dynatrace의 상태 지표 (Health metrics)

이것이 바로 에이전틱 관측성 (Agentic Observability)의 본질입니다. 시스템은 단순히 차트를 보여주는 것에 그치지 않습니다. 차트에 대해 추론하는 데 필요한 컨텍스트를 조립하고 있는 것입니다.

답변은 빨간색 지표보다 훨씬 더 유용해집니다

쿼리가 완료되자, 저는 서비스에 대한 통합된 뷰를 얻을 수 있었습니다.
시스템은 서비스를 식별하고 다음과 같은 주요 메타데이터를 노출했습니다: