뉴렐릭(New Relic)이 'New Relic Agentic Platform'이라는 노코드 기반 AI 에이전트 플랫폼과 OpenTelemetry(OTel) 관련 도구 강화를 함께 공개했습니다1. 중요한 포인트는 "에이전트를 만들기"보다 "프로덕션에서 믿고 굴리기"에 초점이 맞춰졌다는 점입니다. 이번 글에서는 Agentic Platform이 무엇을 해결하려는지, OTel 통합이 왜 실무에서 체감이 큰지, 그리고 팀이 지금 준비하면 좋은 체크리스트까지 한 번에 정리해 보겠습니다.
New Relic Agentic Platform: '관측'에서 '조치'로 넘어가는 노코드 에이전트
지금까지의 옵저버빌리티는 대체로 "문제 찾기"에서 끝나는 경우가 많았습니다. 알람이 울리고, 사람이 로그/트레이스를 뒤지고, 원인 후보를 좁혀가며 대응하죠. 뉴렐릭이 내놓은 Agentic Platform은 이 흐름을 "문제 찾기 + 다음 액션 실행"까지 확장하려는 시도에 가깝습니다.
핵심은 도메인 전문가(SRE, Ops 리드)가 코드를 많이 쓰지 않고도 에이전트와 워크플로우를 조합할 수 있게 만든 점입니다2. 즉, '개발자만 가능한 자동화'가 아니라 '운영 지식을 가진 사람이 설계하는 자동화'에 방점을 찍은 겁니다. 여기에 바로 쓸 수 있는 프리빌트 에이전트를 제공해 초반 진입장벽을 낮추고, 단일 작업 자동화부터 멀티 에이전트 오케스트레이션까지 스케일 업을 노립니다2.
또 하나 눈여겨볼 점은 "일반 목적 에이전트 플랫폼"을 표방하지 않는다는 메시지입니다. 뉴렐릭은 관측(Observability)이라는 좁지만 깊은 문제 공간에서 성과(incident 예방, MTTR 단축 등)를 내는 쪽을 선택했고, 대신 다른 도구 생태계와도 연결되는 형태를 지향합니다1. 실무 관점에선 이게 오히려 현실적입니다. 회사에는 이미 챗봇, 자동화 도구, 티켓 시스템이 있고, 새 플랫폼이 '전부 갈아타라'고 하면 도입이 막히니까요.
거버넌스와 신뢰: "에이전트에게 권한을 주기 전에" 필요한 장치들
엔터프라이즈가 에이전트를 무서워하는 지점은 성능이 아니라 권한입니다. 잘못된 조치 한 번이 장애를 키우거나, 컴플라이언스 이슈로 번질 수 있으니까요. 그래서 Agentic Platform의 '운영 기능'이 더 중요합니다.
뉴렐릭은 RBAC(역할 기반 접근 제어), 감사 로그 같은 거버넌스 요소를 전면에 두고, 에이전트의 성능을 지속적으로 시험하는 평가 엔진까지 포함했다고 밝힙니다2. 쉽게 말해 "에이전트를 만들었으면, 계속 시험하고 기록하며 통제하라"는 철학입니다. 이게 없으면 자동화는 늘 '한 번 잘 되면 멈추는 스크립트'가 되기 쉽고, 팀은 결국 사람 손으로 회귀하거든요.
여기에 MCP(Model Context Protocol) 지원도 실무적으로 큽니다. 에이전트가 외부 데이터 소스/도구에 접근할 때 통로를 표준화해 연결성을 높이려는 흐름인데, 뉴렐릭은 이를 지원하며 자사 도구들과의 통합도 강조합니다1. 정리하면 "연결은 쉽게, 권한은 촘촘히"가 이번 플랫폼의 설계 의도에 가깝습니다.
OpenTelemetry 도구 강화: OTel '수집기 운영' 부담을 줄이는 방향
OTel은 "벤더 락인 줄이면서 표준 방식으로 텔레메트리를 모으자"는 흐름의 대표 주자죠. 하지만 현장에선 이상과 현실이 자주 충돌합니다. 표준이라서 좋은데, 수집기(collector) 운영이 은근히 번거롭고, 팀마다 파이프라인이 쪼개져 데이터가 흩어지는 순간 가시성이 깨집니다.
뉴렐릭은 APM 에이전트에 OTel 기능을 붙여 OTel 데이터 스트림을 다른 소스들과 한 곳에서 다루게 하고, 특히 "OTel collector 운영이 부담"이라는 문제를 정면으로 언급했습니다1. 여기서 포인트는 기술 기능 나열이 아니라, 엔터프라이즈 도입을 막던 '파편화'를 줄이려는 방향성입니다. 한 팀은 OTel, 한 팀은 기존 에이전트, 또 다른 팀은 별도 파이프라인... 이런 상태에선 장애 때마다 "데이터는 있는데 조각나서 못 본다"가 됩니다. 운영자 입장에선 통합 뷰가 곧 대응 속도입니다.
시사점: 에이전트 도입, 지금 당장 이렇게 시작해보자
이번 뉴렐릭 발표를 한 줄로 줄이면 "AI 에이전트가 늘어날수록, 관리는 플랫폼화된다"입니다. 실제로 에이전트 플랫폼은 이미 경쟁이 붙었고, 가트너는 이를 엔터프라이즈 AI 채택을 위한 필수 인프라로 봅니다1. 다만 툴을 고르는 것보다 먼저 해야 할 일이 있습니다.
첫째, 에이전트가 할 일을 '권한 레벨'로 쪼개세요. 읽기(진단/요약)부터 쓰기(재시작/롤백)까지 단계별로 나눠야, RBAC와 승인 흐름을 설계할 수 있습니다.
둘째, "평가/회귀 테스트"를 자동화의 일부로 넣으세요. 잘 동작하던 에이전트도 서비스 구조가 바뀌면 엉뚱한 결론을 내릴 수 있습니다. 평가 엔진 같은 장치가 왜 필요한지, 운영팀이 먼저 합의해야 합니다2.
셋째, OTel은 '표준 수집'만이 아니라 '운영 단순화'까지 같이 보세요. 수집기 관리, 파이프라인 파편화, 데이터 소유권 문제를 줄이는 쪽이 장기적으로 비용을 아낍니다1.
결국 승부처는 "에이전트를 얼마나 똑똑하게 만드느냐"가 아니라 "장애 대응 체계 안에서 안전하게 굴러가게 하느냐"입니다. 뉴렐릭 Agentic Platform과 OTel 강화는 그 흐름을 꽤 노골적으로 보여준 신호로 보입니다.
참고
1New Relic launches new AI agent platform and OpenTelemetry tools
2New Relic Agentic Platform brings governance and scale to AI agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.