New Relic, 노코드 ‘Agentic Platform’ 공개…옵저버빌리티에 ‘에이전트 운영·거버넌스’ 기능 전면 배치
옵저버빌리티(Observability) 기업 뉴렐릭(New Relic)이 2월 24일(미국 시간) ‘New Relic Agentic Platform’을 공개했다. SRE·운영(Ops) 조직이 코드 작성 없이(노코드) 관측·대응 업무에 특화된 AI 에이전트를 만들고 배포·관리할 수 있도록 설계된 것이 핵심이다. 뉴렐릭은 동시에 OpenTelemetry(OTel) 관련 기능도 강화해, APM 에이전트에 OTel 기능을 결합하고 OTel 데이터 스트림을 기존 데이터와 함께 한 곳에서 운영할 수 있도록 했다고 밝혔다.
이번 발표의 포인트는 ‘에이전트를 만들 수 있다’보다 ‘에이전트를 안전하게 굴릴 수 있느냐’에 가깝다. 챗봇을 넘어 장애 조짐 탐지, 원인 추적, 티켓 분류, 런북 실행 같은 운영 업무에 에이전트를 붙이면 생산성이 오를 수 있지만, 운영 환경에서는 곧바로 가시성·권한·검증 문제가 따라온다. 예를 들어 “누가 어떤 에이전트를 어디에 붙였는지(가시성)”, “권한이 과도하지 않은지(거버넌스)”, “실제로 도움이 되는지(평가)”를 관리하지 못하면 리스크가 커질 수 있다. 뉴렐릭은 MCP(Model Context Protocol) 지원, RBAC(역할 기반 접근 제어), 감사 로그, 평가 엔진 등을 전면에 내세워 이 지점을 겨냥했다.
보스턴권(테크·바이오·핀테크 포함) 현장에서 자주 부딪히는 장애물도 ‘모델 선택’보다 ‘운영 체계’ 쪽에 몰려 있다. (가상 사례) 켄달스퀘어 인근의 한 중견 SaaS 팀이 “에이전트가 로그·트레이스를 보고 원인을 요약해준다”는 파일럿을 도입했지만, 데이터 소스가 분산돼 있고 텔레메트리 표준이 제각각이라 결과가 들쭉날쭉해지는 장면은 흔하다. 반대로 OTel로 트레이스·메트릭·로그 수집을 표준화하고, 에이전트가 참조할 ‘정답 데이터(ground truth)’를 정리한 팀은 같은 인력으로도 MTTR(복구시간) 단축 같은 개선을 기대해볼 여지가 생긴다. 즉, 성패는 ‘에이전트 자체’보다 ‘관측 데이터와 운영 규율’에 더 가까울 때가 많다.
리스크도 함께 본다. 첫째, 에이전트가 접근하는 시스템이 늘수록 권한 오남용·데이터 유출 가능성이 커질 수 있다. 둘째, 노코드 도입이 쉬울수록 현장 임의 도입(섀도우 AI)이 늘어 통제 비용이 증가할 수 있다. 셋째, OTel 도입 이후에도 컬렉터(Collector) 운영·비용·성능 튜닝이 병목이 될 수 있다. 넷째, 특정 벤더의 에이전트/플랫폼에 깊게 얽히면 전환 비용이 커질 수 있다. 그래서 “빨리 붙이고 나중에 정리” 전략은 단기 속도는 낼 수 있어도, 중장기엔 운영 부채로 돌아올 수 있다는 점을 전제로 접근하는 편이 안전하다.
보스턴권 유학생·교민 실무자가 참고할 만한 실행 항목은 다음처럼 정리된다(조직/상황에 따라 조정 필요).
- 도입 전 2주 체크(팀 단위)
- 에이전트가 사용할 데이터 소스 목록부터 만든다(로그/트레이스/메트릭/티켓/런북/DB).
- ‘접근 권한’과 ‘변경 권한’을 분리한다(가능하면 읽기 전용 에이전트부터 시작).
- 실패 시 안전장치(자동 실행 제한, 사람 승인 단계, 롤백 경로)를 먼저 합의한다.
- OTel 운영 설계(플랫폼/인프라 단위)
- 우선순위 서비스 3개만 골라 ‘끝까지 이어지는 트레이스’를 만든다.
- 컬렉터 배치(게이트웨이/사이드카/에이전트)를 한 가지 패턴으로 고정해 운영 복잡도를 줄인다.
- 수집량·샘플링·저장기간을 숫자로 합의해 비용 급증 가능성을 낮춘다.
- 에이전트 평가·운영(운영 리더 단위)
- ‘잘했다’의 기준을 지표로 정의한다(예: 알람 노이즈 감소, MTTR, 재발률).
- 대표 장애 시나리오를 만들어 릴리즈마다 재검증한다.
- 감사 로그를 남기고, 자동화 범위는 단계적으로 넓힌다.
채용 트렌드에 대해 지역 단위로 단정하긴 어렵지만, 보스턴권에서도 플랫폼/SRE/데이터 엔지니어 포지션 면접에서 “에이전트를 붙여봤다”보다 “권한·평가·비용·표준(OTel)까지 포함해 운영 가능하게 설계했다”는 설명이 설득력을 갖는 경우가 있다. 뉴렐릭의 이번 발표는 이런 ‘운영화(Operationalization)’ 요구를 제품 기능으로 전면화한 사례로 볼 수 있다. 어떤 플랫폼을 쓰든, 표준화된 텔레메트리와 거버넌스를 먼저 잡아두는 접근이 후속 시행착오를 줄이는 데 유리할 수 있다.