AI 에이전트 시대, APM은 어디로 가야 할까? 제니퍼가 AI 에이전트 열풍을 바라보는 시각
AI는 반드시 도달해야 할 최종 목표가 아닙니다.— 제니퍼가 AI 에이전트 열풍을 바라보는 시각
요즘 IT 업계에서는 “AI 에이전트가 알아서 장애를 찾고, 알아서 고쳐준다”는 이야기가 넘쳐납니다. 자율형 AI 에이전트(Autonomous AI Agent)가 모든 것을 해결해 줄 것처럼 보이는 분위기 속에서, APM 도구인 제니퍼도 이 흐름 속에서 어떤 방향으로 나아가야 할까요?
결론부터 말씀드리면, 제니퍼는 현재도 모니터링 도구이며 앞으로도 그 본질은 변하지 않는다는 것입니다.
자율형 AI 에이전트는 제니퍼가 반드시 도달해야 할 최종 목표가 아닙니다. 놀라운 AI 기술이 등장했다고 해서 제니퍼가 AI 모델에 데이터를 공급하는 단순한 ‘감각 기관’으로 바뀔 이유는 없습니다. 제니퍼는 그 기술을 잘 활용해 더 좋은 모니터링 도구가 되는 것을 목표로 합니다.
“10년 뒤에도 변하지 않을 것”에 집중하기
고객이 제품을 선택하는 이유는 그 안에 담긴 최신 기술이 아니라, 그 제품이 주는 변치 않는 가치 때문입니다. 제니퍼 사용자분들은 지난 20년 동안 애플리케이션 모니터링을 위해 제니퍼를 사용해 왔습니다. 그리고 그 본질은 10년 뒤에도 바뀌지 않을 것이 있습니다.
- 애플리케이션은 여전히 존재할 것이고
- 트랜잭션 데이터는 여전히 모니터링해야 하며
- 장애는 여전히 최대한 빠르게 인지하고 대응해야 합니다
반면, 10년 뒤에 지금처럼 “자율형 AI 에이전트”를 이야기하고 있을 가능성은 낮습니다. 지금도 상상 못 했던 신기술이 계속 등장하듯, 그때는 또 다른 유행이 와 있을 것입니다. 그리고 그 신기술을 활용한 다양한 웹 애플리케이션과 수많은 서비스들이 탄생할 것이며, 수많은 LLM 서비스가 경쟁하는 지금 시기를 넘어 일상에 당연해진 AI에이전트 서비스들 또한 제니퍼로 모니터링되고 있을 것입니다.
자동화의 함정, 그래서 “무엇을 자동화할 것인가?”를 먼저 물어야 한다
AI를 도입할 때 가장 먼저 던져야 할 질문은 이것입니다. “무엇을 자동화해야 하는가?”
예를 들어 “어제 발생한 결제 장애 원인을 리포트로 만들어줘”라는 요청을 생각해 봅시다. 현장 운영자가 실제로 작성하는 사후 보고서의 핵심은 이렇습니다.
“어제 결제 장애를 이러이러한 비즈니스 로직 수정을 통해 해결했습니다.”
APM인 제니퍼는 “장애의 증상”은 누구보다 잘 압니다. 하지만 “비즈니스적으로 어떻게 해결해야 하는가”는 알 수 없습니다. 장애의 원인과 해결책은 상황과 목적에 따라 달라지기 때문에, 시스템 외부의 솔루션이 비즈니스 맥락까지 완벽히 이해하고 최종 원인을 단정 짓는 것은 애초에 불가능하고 위험한 일입니다.
그럼 “매일 아침 어제 상황을 정리한 일일 리포트”는 어떨까요?
주목할 이상 현상이라면 이미 제니퍼 이벤트로 감지되었을 테고, 이벤트를 등록하지 않을 정도라면 무시해도 될 상황일 가능성이 높습니다. 아무도 꼼꼼히 읽지 않는 보고서를 매일 자동 생성하는 건 업무를 돕는 게 아니라 오히려 방해가 되는 짐입니다.
AI를 도입했다고 해서 원래 필요하지도 않던 기능을 억지로 만들어낼 필요는 없습니다. 진짜 질문은 언제나 같습니다.
고객이 실제로 불편을 느끼는 지점이 어디일까?
AI가 진짜 빛을 발하는 곳, ‘해결사’가 아닌 ‘번역가’
그렇다면 APM에서 AI, 특히 LLM이 진정으로 유용한 역할은 무엇일까요?
바로 복잡한 데이터를 사람이 이해하기 쉬운 언어로 번역해 주는 것입니다.
장애를 최종적으로 해결하는 건 시스템 맥락을 종합적으로 이해하는 사람(운영자/개발자)의 몫입니다. AI는 그 사람이 판단을 내리기까지 거쳐야 하는 길고 지루한 탐색 시간을 단축시켜 줄 수 있습니다.
수십, 수백 줄의 스택트레이스나 복잡한 SQL 프로파일을 눈으로 일일이 읽고 해석하는 건 굉장히 고된 일입니다. 제니퍼의 스택트레이스 인사이트와 프로파일 인사이트는 바로 이 지점을 파고듭니다.
“장애 원인은 이것이다!”라고 섣불리 단정 짓는 대신, 이렇게 말해줍니다.
“이 수백 개의 호출 스택 중 가장 오래 걸린 병목 구간은 여기이고, 이 SQL 쿼리에서 인덱스 스캔이 누락되었을 가능성이 높습니다.”
단정이 아니라 번역. 이것이 제니퍼가 생각하는 AI의 올바른 역할입니다.
진짜 자동화: 애드혹(Ad-hoc) 업무의 허들 낮추기
‘뛰어난 번역가’로서의 능력을 바탕으로, 제니퍼가 구상 중인 사용자 맞춤형 보고서(AI Agent) 의 방향도 여기서 나옵니다.
운영자가 보고서가 필요한 순간은 대부분 특정한 목적을 가지고 조사를 수행하는 애드혹(Ad-hoc) 상황입니다. 그런데 제니퍼에서 원하는 데이터를 취합해 보고서로 만들려면 세 가지 허들이 있었습니다.
- 조회: 내가 원하는 데이터를 어떤 메뉴, 어떤 API로 꺼낼 수 있는가?
- 시각화: 이 데이터를 원하는 모양의 차트나 테이블로 어떻게 만드는가?
- 해석: 이 데이터를 어떻게 읽고 문장으로 표현할 것인가?
전문 도구의 특성상 이 허들은 꽤 높게 느껴졌고, 기존의 템플릿 기반 리포트나 DSL 쿼리 방식으로는 한계가 있었습니다.
LLM의 등장으로 이 허들을 크게 낮출 수 있게 되었습니다. 사용자가 자연어로 의도를 던지면, AI Agent가 제니퍼의 Open API를 통해 데이터를 가져오고, 적절히 시각화하고, 텍스트로 풀어내는 과정을 도와줍니다. 이것이 고객의 실제 업무 흐름을 돕는 진짜 의미의 맞춤형 보고서입니다.
변하지 않는 고충을, 현재 최선의 기술로
AI가 직접 시스템을 제어하고 코드를 수정하는 완전 자율 운영을 고객이 진정으로 원하고, 기술도 그 기대를 충족할 수 있다면 물론 그 방향으로 나아갈 것입니다. 하지만 지금은 아직 그 단계가 아닙니다.
대규모 엔터프라이즈 환경에서 서드파티 AI 솔루션에 시스템 통제권을 완전히 맡기기엔, 시스템 운영이 요구하는 신뢰 수준이 코드 작성보다 훨씬 높기 때문입니다.
제니퍼는 지난 20년간 유행을 좇기보다 변하지 않는 고객의 고충을 직시하고, 현재 가용한 최선의 기술로 그 문제를 해결하는 제품 개발 문화를 지켜왔습니다.
X-View가 산점도(Scatter Plot)라는 시각화로 트랜잭션 모니터링 문제를 해결했듯, 스택트레이스 인사이트는 LLM을 활용해 “스택트레이스를 읽는 고충”을 해결합니다.
만약 내일부터 AI 기술 발전이 완전히 멈춘다 해도, 스택트레이스 인사이트는 10년 뒤에도 운영자에게 꼭 필요한 기능으로 남아 있을 것입니다. 새롭게 구상하는 사용자 맞춤형 보고서 역시 마찬가지입니다. 유행을 타지 않고, 오래도록 고객의 애드혹 업무를 돕는 도구가 되기를 희망합니다. 제니퍼는 훌륭한 모니터링 도구라는 본질을 잃지 않을 것이며, AI는 그 도구를 더욱 날카롭고 쓰기 편하게 만들어주는 기술로 제품 안에 남을 것입니다.
* 제니퍼는 AI를 더 높은 차원의 목표를 달성하기 위한 방법(Means)으로 사유하며 수단이며 목적으로 대합니다. 그 너머의 궁극적 가치를 지향합니다.
* 애드혹(Ad-hoc) 은 라틴어로 “이것을 위해(for this)”라는 뜻입니다. 쉽게 말하면 “그때그때 필요에 따라 즉흥적으로 하는 일” 을 가리킵니다. 매일 정해진 시간에 자동으로 생성되는 보고서가 아니라, 운영자가 “오늘 갑자기 결제 오류가 많이 발생했는데, 원인이 뭔지 한번 파봐야겠다” 처럼 특정 목적이 생겼을 때 그 자리에서 직접 데이터를 조회하고 보고서를 만드는 상황. 즉, 정기적·반복적인 업무가 아니라 상황에 따라 비정기적으로 발생하는 일회성 조사나 작업을 뜻합니다.
