JetBrains는 2026년 9월 15일 OpenTelemetry 플러그인의 Service Map 기능이 어떻게 작동하는지에 대한 기술 설명을 게시했습니다. 이 기능은 개발 환경에서 애플리케이션이 실행되는 동안 마이크로서비스 간의 실제 관계를 그립니다. 이 설명은 Rider Execution 팀과 Software Engineering Research 팀의 협업으로 Nikita Dukin과 Egor Klimov가 작성했습니다.
이 아이디어는 잘 알려진 실무 문제에서 출발합니다. 아키텍처 다이어그램은 정돈되어 보일 수 있지만 몇 달 전의 시스템 상태를 반영할 수 있고, 새 서비스나 문서가 업데이트되지 않은 메시지 큐를 보여주지 못할 수도 있습니다. JetBrains는 정적 코드 분석만으로는 항상 충분하지 않다고 봅니다. 정적 분석은 소스에서 발생할 수 있는 일을 설명할 뿐, 실행 중 서비스 간에 실제로 일어나는 일을 설명하지 않기 때문입니다.
트레이스가 지도의 원천이다
플러그인은 로그, 메트릭, 트레이스를 수집하는 OpenTelemetry 데이터를 사용합니다. 로그는 무엇이 발생했는지 설명하고 메트릭은 현상의 규모를 보여주는 반면, 트레이스는 요청이 시스템을 통과하는 경로를 드러냅니다. 각 트레이스는 spans라고 하는 작업 단위로 구성되며, OpenTelemetry는 HTTP Client 및 HTTP Server 트레이스와 같은 표준화된 의미 규칙을 제공합니다.
플러그인은 특정 프레임워크나 언어에 알고리즘을 결합하지 않고 운영 구조를 이해하기 위해 이러한 트레이스를 사용합니다. 애플리케이션과 라이브러리가 OpenTelemetry의 기대에 따라 트레이스를 전송한다면 사용된 기술과 관계없이 통신을 시각화할 수 있습니다. JetBrains는 동일한 로직이 JVM, .NET, Python, Go 애플리케이션 등에서 작동할 수 있으며 IntelliJ IDEA, GoLand, PyCharm, WebStorm, Rider에서도 사용할 수 있다고 설명합니다.
개발 환경 내부에서 지도는 어떻게 만들어지는가?
OpenTelemetry 플러그인이 활성화된 개발 환경을 실행하면 플러그인은 원격 측정 데이터를 수신하는 가벼운 로컬 서버를 시작합니다. 애플리케이션을 실행할 때 플러그인은 표준 OpenTelemetry 환경 변수를 설정하여 애플리케이션이 트레이스를 해당 로컬 서버로 전송하도록 합니다.
서버는 수신되는 트레이스를 비동기적으로 처리하고 아키텍처의 내부 모델을 구축하여 지속적으로 업데이트합니다. Service Map 탭을 열면 플러그인은 최신 구조 모델을 가져와 시각적 다이어그램으로 표시합니다. 따라서 이 지도는 수동으로 작성되는 정적인 문서가 아니라 시스템 실행 중 관찰된 통신의 직접적인 결과입니다.
어려운 점은 그리기가 아니라 데이터 해석이다
트레이스는 독립적으로 도착하며 도착 순서가 보장되지 않습니다. 자식 서비스의 트레이스가 부모 서비스의 트레이스보다 먼저 도착할 수 있고, 늦게 도착하는 트레이스가 더 이상 없음을 보장하는 최종 종료 시점도 트레이싱은 알리지 않습니다. 또한 OpenTelemetry는 각 트레이스마다 엄격하게 분리된 유형을 제공하지 않습니다. 트레이스는 작업의 의미를 설명하는 키-값 쌍의 맵을 담고 있습니다.
따라서 JetBrains는 구조 재구성을 데이터 스트림 처리 알고리즘으로 분류했습니다. 플러그인은 트레이스가 완료될 때까지 기다리지 않고 각각의 트레이스가 도착하는 즉시 검사합니다. http.request.method 및 http.response.status_code와 같은 속성을 사용해 해당 작업이 HTTP 통신인지 판단하며, 다른 속성은 데이터베이스 쿼리나 메시징 시스템과의 상호작용을 나타냅니다.
트레이스를 분류한 뒤 알고리즘은 해당 트레이스를 생성한 서비스를 식별합니다. 서비스가 새 서비스라면 지도에 추가하고, 이미 존재한다면 새 데이터를 병합하여 통계를 업데이트합니다. HTTP 통신에서는 호출 서비스에서 발생한 CLIENT 트레이스와 수신 서비스에서 생성된 SERVER 트레이스 간의 관계를 플러그인이 찾습니다. 요청과 함께 트레이싱 컨텍스트가 전달되므로 SERVER 트레이스는 CLIENT 트레이스의 자식이 됩니다. 상대편이 이미 존재하면 관계를 즉시 그리며, 존재하지 않으면 대응하는 데이터가 도착할 때까지 트레이스를 메모리에 보관합니다.
다른 의존성은 서로 다른 규칙을 사용합니다. 일반적으로 데이터베이스 호출은 단일 CLIENT 트레이스로 표현되며, 플러그인은 의미 속성을 바탕으로 데이터베이스 노드를 추론합니다. 반면 메시징 시스템은 더 큰 유연성을 필요로 합니다. 사용되는 메시징 시스템과 instrumentation 방식에 따라 생산자와 소비자의 관계가 부모-자식 관계나 트레이스 링크를 통해 나타날 수 있기 때문입니다.
이것이 실무적으로 중요한 이유는 무엇인가?
여기서 핵심 가치는 지도가 예상된 구조만이 아니라 관찰된 동작을 드러낸다는 점입니다. 개발 중 시스템이 여러 HTTP 통신이나 데이터베이스 쿼리를 수행하는 반면 하나의 통신만 예상되었다면 릴리스 전에 이를 발견할 수 있습니다. 또한 문서화되지 않았거나 시간이 지나면서 변경된 의존성을 이해하는 데도 도움이 됩니다.
그러나 결과의 정확성은 여전히 원격 측정의 품질과 관련이 있습니다. 알고리즘은 올바른 트레이스, 서비스 간 트레이싱 컨텍스트 전파, 예상되는 의미 속성의 사용을 필요로 합니다. 따라서 플러그인을 설치했다는 이유만으로 Service Map이 모든 시스템의 완전한 그림을 자동으로 제공하는 것은 아닙니다. 계측 도구가 전송하지 않거나 컨텍스트 없이 도착한 항목은 추론된 관계에 나타나지 않을 수 있습니다. 또한 이 자료는 새로운 증거가 도착함에 따라 모델이 발전하므로 지도가 아키텍처 설계에 대한 최종 판단이 아니라 지속적으로 갱신되는 운영 표현이라고 설명합니다.