APM 분석, AI 자동 분석으로 쉬워지다

APM(Application Performance Management)을 10년 넘게 봐온 사람의 시각에서, 최근 1~2년간 가장 큰 변화는 새로운 기능의 등장이 아닙니다. 분석할 수 있는 사람의 범위가 바뀌었다는 점입니다.

10년 전 APM 화면을 떠올려 봅니다. 트랜잭션 상세, 스레드 덤프, 메서드별 소요 시간, GC(Garbage Collection) 그래프, 액티브 스택 같은 패널이 빽빽하게 펼쳐져 있었습니다. 이 안에서 의미 있는 결론을 끌어내려면 자바, OS, DB, 네트워크를 두루 이해하는 사람, 즉 시니어 엔지니어가 필요했습니다. 도구는 데이터를 보여줄 뿐이고, 해석은 사람의 경험과 역량에 달려 있었습니다.

AI 자동 분석이 바꾼 것은 바로 이 마지막 단계입니다. 데이터를 보여주는 데서 멈추지 않고, 데이터를 읽고 정리해 결과로 돌려주는 단계까지 나아간 것입니다.

‍

왜 APM 분석은 전문가의 영역이었을까

APM 분석이 어려웠던 이유는 도구가 부족해서가 아닙니다. 오히려 반대였습니다. 데이터가 너무 많았기 때문입니다.

20년 전 모니터링은 비교적 단순했습니다. CPU, 메모리, 디스크 사용량 그래프 몇 개와 임계치 알람이면 충분했습니다. 시스템도 단순했기 때문입니다. 모놀리식 애플리케이션 하나가 단일 서버에서 동작했고, 장애 원인 후보도 손에 꼽을 수 있었습니다.

지금은 다릅니다. 마이크로서비스, 컨테이너, 메시지 큐, 외부 API, 서비스 메시, 멀티 클라우드까지 IT 환경은 훨씬 복잡해졌습니다. 하나의 사용자 요청이 수십 개의 컴포넌트를 거치고, 하나의 트랜잭션이 수백 개의 메서드 호출과 수십 번의 DB 쿼리, 외부 호출을 만들어냅니다.

와탭 같은 APM은 이 모든 호출을 보여줄 수 있습니다. 문제는 다 보여줄 수 있다는 사실 자체가 운영자에게는 부담이 될 수 있다는 점입니다.

지난 10년간 와탭이 풀어온 문제의 본질은 “어떻게 다 보여줄까”에서 “이 많은 데이터를 어떻게 의미로 압축할까”로 이동해 왔습니다. 초기에는 이를 시각화로 풀었습니다. 트랜잭션 맵, 액티브 스택, 멀티 트랜잭션 뷰가 그 예입니다.

하지만 마지막 해석은 여전히 사람의 몫이었습니다. 차트를 본 시니어 엔지니어가 “이건 GC 영향이고, 이건 외부 API 지연이다”라고 짚어 줘야 다음 의사결정이 가능했습니다.

이 마지막 한 단계가 APM 도입 효과의 천장이었습니다. 시니어가 화면을 보지 못하는 시간 동안에는 데이터가 쌓이기만 했습니다.

‍

AI 자동 분석이 바꾸는 APM 운영 방식

자동 분석은 바로 그 한 단계를 메우는 자리에 들어왔습니다. 데이터를 사람이 해석하는 대신, 시스템이 해석한 결과를 사람에게 전달합니다.

구체적으로 바뀐 부분은 세 가지입니다.

첫째, 이상치 탐지의 자동화입니다. 예전에는 임계치를 사람이 직접 정했습니다. CPU 80% 이상, 응답 시간 3초 이상과 같은 방식입니다. 그런데 서비스마다, 시간대마다 정상 범위는 다릅니다. 트래픽이 적은 시간대의 CPU 80%와 피크 시간대의 CPU 80%는 같은 수치라도 의미가 다릅니다.

AI 기반 이상치 탐지는 서비스별, 시간대별 패턴을 학습해 “이 시점, 이 서비스 기준에서 비정상”인 상태를 짚어냅니다. 임계치 룰을 사람이 수동으로 관리하던 방식과 비교하면 운영 비용 구조 자체가 달라집니다.

둘째, 원인 후보의 자동 정리입니다. 트랜잭션이 느려졌을 때 원인 후보는 늘 여러 가지입니다. DB 쿼리, GC, 외부 호출, 락 경합, 컨테이너 리소스 부족 등이 모두 원인이 될 수 있습니다. 시니어 엔지니어는 이 후보들을 머릿속에서 빠르게 가지치기합니다. 자동 분석은 같은 과정을 데이터 기반으로 수행합니다. 특정 시점에 어떤 지표가 평소와 달랐는지, 어떤 변화가 트랜잭션 지연과 시간상 가까웠는지를 정리해 원인 후보의 우선순위로 보여줍니다.

와탭의 AI 액티브 스택 분석, AI 스레드 분석 같은 기능은 바로 이 지점에 들어와 있습니다.

셋째, 자연어 요약입니다. 차트를 읽는 부담이 줄어듭니다. 예를 들어 “지난 30분간 결제 서비스 응답 시간이 평소 대비 2배로 늘었고, 같은 시점에 외부 PG 호출 응답 시간도 함께 증가했다”와 같은 문장으로 결과를 받을 수 있습니다.

이제 차트를 직접 해석하는 능력이 부족한 사용자도 일정 수준의 결론에 도달할 수 있습니다.

여기서 핵심은 사람이 사라지는 것이 아닙니다. 자동 분석은 후보를 정리해 주고, 사람은 결정을 내립니다. 운영자, SRE, 개발자는 여전히 필요합니다. 다만 데이터를 읽는 데 쓰던 시간이 줄어들고, 그 시간은 결정과 조치에 더 많이 쓰이게 됩니다.

‍

와탭이 자동 분석을 통합 옵저버빌리티로 확장하는 방식

와탭은 단일 제품이 아니라 옵저버빌리티 전 영역에 걸친 제품군으로 문제를 풀어 왔습니다. APM, 서버, 쿠버네티스, 데이터베이스, 브라우저, URL, 로그, LLM Observability까지 다양한 영역의 데이터를 함께 다룹니다.

자동 분석은 이처럼 제품군 전체를 가로지르는 데이터 위에서 동작할 때 가장 큰 가치를 갖습니다.

APM 트랜잭션이 느려졌다고 가정해 보겠습니다. APM 데이터만 보면 “이 트랜잭션이 느렸다”는 사실까지는 알 수 있습니다. 하지만 원인을 좁히려면 같은 시점에 동일 노드의 컨테이너가 리소스 압박을 받았는지, DB에서 동일 SQL이 락 대기에 걸렸는지, 외부 URL 헬스체크에는 어떤 패턴이 있었는지를 함께 봐야 합니다.

자동 분석이 한 제품 안에만 갇혀 있다면 원인 후보의 절반은 시야 밖에 남게 됩니다.

단일 제품 관점에서는 보이지 않지만, 제품군을 가로지르면 분석의 정확도는 달라집니다. PM이 한 제품의 깊이를 본다면, TCE는 제품 간 데이터 흐름의 일관성을 봅니다. 이 자리에서 자동 분석은 단일 제품의 부가 기능이 아니라 옵저버빌리티 플랫폼 전체를 연결하는 결합 조직이 됩니다.

물론 trade-off도 있습니다. 데이터 간 상관관계를 자동으로 연결하려면 식별자, 시간 동기화, 메타데이터 일관성이 전 제품에 걸쳐 맞춰져야 합니다. 이런 통합은 한두 달 만에 완성되는 일이 아니라, 제품 설계 단계부터 쌓아온 자산에 가깝습니다.

와탭이 처음 통합 옵저버빌리티를 지향하며 내린 설계 결정은 지금 자동 분석의 정확도에 그대로 영향을 줍니다. 당시에는 단순한 데이터 모델 통일처럼 보였던 결정이, 10년 뒤 AI 기반 분석의 기반이 되는 셈입니다.

‍

APM 도입 검토 시 새롭게 봐야 할 기준

APM 도입을 검토하는 의사결정자와 아키텍트에게는 몇 가지 새로운 관점이 필요합니다.

기능 비교표만으로는 부족합니다. “AI 자동 분석 지원” 항목에 체크가 있다고 해서 모두 같은 가치를 제공하는 것은 아닙니다. 어떤 데이터 위에서 동작하는지, 어디까지 자동화되는지, 결과를 어떤 형태로 돌려주는지가 실제 도입 효과를 가릅니다.

APM 단독 데이터에서 동작하는 자동 분석과 인프라, DB, URL, 로그를 함께 보는 자동 분석은 같은 라벨을 달고 있어도 결과의 깊이가 다릅니다.

운영 인력 구조에 미치는 영향도 따져 볼 필요가 있습니다. 자동 분석이 자리 잡으면 “분석할 줄 아는 사람이 누구인가”보다 “결정할 줄 아는 사람이 누구인가”가 병목이 됩니다.

분석 결과를 받아 실제 행동으로 옮기는 조직 흐름이 준비돼 있는지, 보고·승인·롤백 절차가 자동 분석의 속도에 맞춰져 있는지 살펴보는 일이 도구 평가보다 먼저 필요할 때도 있습니다.

비즈니스 관점에서는 운영 인력 확장 부담이 줄어드는 효과가 큽니다. 기술 관점에서는 시니어 의존도가 낮아지는 만큼, 시니어 엔지니어가 더 어려운 문제에 시간을 쓸 수 있게 됩니다. 두 관점을 함께 봐야 도입 결정에 두께가 생깁니다.

‍

마치며

APM 분석이 전문가의 일에서 누구나 결과를 받아볼 수 있는 일로 이동하는 흐름은 단순한 기능 업데이트가 아닙니다. 이는 옵저버빌리티 산업 전체의 단계 변화입니다.

데이터를 보여주는 시대에서 데이터를 해석해 돌려주는 시대로의 이동이며, 이 변화는 운영자, SRE, 의사결정자가 APM과 옵저버빌리티 도구를 평가하는 기준을 바꾸고 있습니다.

와탭 APM의 자동 분석을 실제 환경에서 살펴보고 싶다면 와탭 무료 체험을 통해 확인해 볼 수 있습니다.

‍

더 읽을거리

• 와탭 공식 사이트
• 와탭 기술 문서