Build an agentic incident triage assistant with Amazon Quick and New Relic
Quick Summary
Amazon Quick, New Relic MCP Server, Asana를 연결해 단일 대화형 프롬프트로 장애 조사, RCA 요약, 업무 인계를 처리하는 인시던트 트리아지 어시스턴트를 구축하는 절차를 설명한다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Amazon Quick, New Relic MCP Server, Asana를 연결해 단일 대화형 프롬프트로 장애 조사, RCA 요약, 업무 인계를 처리하는 인시던트 트리아지 어시스턴트를 구축하는 절차를 설명한다.
📌 핵심 요약
- 글은 SRE와 지원 엔지니어가 장애 대응 중 여러 도구를 오가며 증거 수집, 사용자 영향 평가, 후속 작업 생성을 수행해야 하는 문제를 출발점으로 삼는다.
- Amazon Quick의 채팅 에이전트와 New Relic 기본 커넥터, Asana 기본 커넥터를 연결하면 하나의 프롬프트에서 조사, RCA 브리프 작성, Asana 작업 생성까지 이어지는 흐름을 만들 수 있다.
- New Relic 연동은 알림 원인, 사용자 영향 범위, 로그 오류 신호, 느린 트랜잭션, 자연어 기반 NRQL 질의 등 다섯 가지 조사 도구를 에이전트가 상황에 맞게 호출하도록 구성된다.
- 구현은 New Relic 통합 설정, Asana OAuth 통합 설정, Incident triage assistant 채팅 에이전트 생성, 테스트 프롬프트 실행, Asana 작업 생성 확인의 순서로 진행된다.
- 보안 측면에서는 New Relic과 Asana 권한을 최소화하고, Asana 작업 메모를 원시 데이터 내보내기가 아닌 인계 요약으로 제한하며, PII·자격 증명·내부 식별 정보 등을 포함하지 말 것을 강조한다.
🧩 주요 포인트
- 글은 SRE와 지원 엔지니어가 장애 대응 중 여러 도구를 오가며 증거 수집, 사용자 영향 평가, 후속 작업 생성을 수행해야 하는 문제를 출발점으로 삼는다.
- Amazon Quick의 채팅 에이전트와 New Relic 기본 커넥터, Asana 기본 커넥터를 연결하면 하나의 프롬프트에서 조사, RCA 브리프 작성, Asana 작업 생성까지 이어지는 흐름을 만들 수 있다.
- New Relic 연동은 알림 원인, 사용자 영향 범위, 로그 오류 신호, 느린 트랜잭션, 자연어 기반 NRQL 질의 등 다섯 가지 조사 도구를 에이전트가 상황에 맞게 호출하도록 구성된다.
- 구현은 New Relic 통합 설정, Asana OAuth 통합 설정, Incident triage assistant 채팅 에이전트 생성, 테스트 프롬프트 실행, Asana 작업 생성 확인의 순서로 진행된다.
- 보안 측면에서는 New Relic과 Asana 권한을 최소화하고, Asana 작업 메모를 원시 데이터 내보내기가 아닌 인계 요약으로 제한하며, PII·자격 증명·내부 식별 정보 등을 포함하지 말 것을 강조한다.
🧠 상세 정리
1. 장애 트리아지의 시간 민감성과 도구 분산 문제
원문은 인시던트 트리아지가 시간에 민감한 업무라는 점에서 시작한다. SRE와 지원 엔지니어는 장애 상황에서 증거를 모으고, 사용자에게 미치는 영향을 평가하며, 후속 작업을 만들기 위해 여러 도구를 오가야 한다. 이 과정은 대응 속도를 늦추고 교대 근무 사이에 맥락이 손실될 위험을 높일 수 있다. 글은 Amazon Quick과 New Relic을 함께 사용하면 이러한 조사와 인계 단계를 하나의 대화형 워크플로로 조정할 수 있다고 설명한다. 핵심 목표는 장애 대응자가 단일 프롬프트에서 필요한 조사를 시작하고, 근거가 포함된 RCA 브리프와 추적 가능한 후속 작업까지 만들 수 있게 하는 것이다.
2. 단일 프롬프트에서 RCA와 Asana 작업까지 이어지는 전체 패턴
이 게시물의 중심 사례는 Amazon Quick으로 만든 사용자 지정 인시던트 트리아지 어시스턴트다. 이 에이전트는 New Relic MCP Server와 Asana를 네이티브 통합으로 오케스트레이션한다. 사용자가 예를 들어 체크아웃 서비스가 느리고 서버 오류가 발생한다며 지난 24시간을 확인하고 RCA 브리프를 만들어 달라고 요청하면, 에이전트는 New Relic 조사 도구들을 호출해 장애 관련 증거를 모은다. 이어서 영향 범위, 가능성 있는 트리거, 핵심 증거 링크, 권장 후속 조치를 포함한 RCA 브리프를 구성한다. 최종적으로는 사용자의 확인을 받아 Asana의 지정 프로젝트에 업무 인계용 태스크를 생성한다.
3. Amazon Quick의 액션 커넥터와 New Relic 조사 도구
Amazon Quick의 채팅 에이전트는 연결된 액션 커넥터를 바탕으로 열린 대화 안에서 데이터를 탐색하고 작업을 실행할 수 있다. New Relic은 Amazon Quick의 기본 제공 커넥터로 소개되며, 인시던트 대응과 성능 분석에 필요한 AI 추론 도구에 접근할 수 있게 한다. Asana 역시 기본 제공 커넥터로, 작업 생성을 지원한다. 원문은 에이전트가 사용하는 New Relic 도구로 주요 알림 원인 식별, 사용자 영향 범위 산정, 로그의 오류 시그니처와 예외 분석, 느리거나 실패하는 요청 분석, 자연어 질문을 NRQL로 변환해 실행하는 기능을 제시한다. 에이전트는 사용자의 프롬프트를 바탕으로 어떤 도구를 호출할지 결정한다.
4. 구축 전 필요한 접근 권한과 사전 조건
구현에 앞서 Amazon Quick, New Relic, Asana에 필요한 접근 권한을 준비해야 한다. Amazon Quick에서는 Professional 구독이 필요하고, 통합과 채팅 에이전트를 만들려면 Author 권한 이상이 요구된다. New Relic의 경우 커넥터가 Amazon Quick에 기본 제공되며, 설정 과정에서 기존 New Relic 계정 자격으로 인증한다. Asana 쪽에서는 SRE Incident Triage라는 이름의 프로젝트가 포함된 워크스페이스가 필요하고, Asana 개발자 콘솔에서 OAuth 애플리케이션을 만들 수 있는 관리 권한도 필요하다. 이러한 준비는 단순한 연결뿐 아니라 인증, 커넥터 구성, 업무 인계 대상 설정까지 포함한다.
5. New Relic 통합 설정 절차
첫 구현 단계는 Amazon Quick 통합 콘솔에서 New Relic 액션을 설정하는 것이다. 사용자는 Integrations 메뉴의 Actions 탭으로 이동해 New Relic 타일을 찾고, 추가 아이콘을 선택해 설정을 시작한다. Create integration 대화 상자에서는 New Relic Integration의 이름과 선택적 설명을 입력하며, 연결 유형은 Public network로 유지한다. 이 단계에서는 인증 방식이 추가 자격 증명이 필요 없다고 표시되지만, 실제 New Relic 계정 인증은 이후 통합 상세 페이지에서 수행한다. 생성 후 Existing actions 패널에 통합이 Available 상태로 나타나며, 상세 페이지에서는 사용 가능한 New Relic 액션과 Base URL, Authorization URL, Token URL 같은 연결 정보를 확인한 뒤 Sign in을 눌러 인증한다.
6. Asana 통합과 채팅 에이전트 생성
두 번째 단계는 Asana 통합 설정이며, 이 커넥터는 OAuth 2.0을 사용한다. Amazon Quick에서 Asana를 구성하기 전에 Asana 개발자 콘솔에서 OAuth 애플리케이션을 만들어 Client ID와 Client Secret을 확보해야 한다. Amazon Quick의 Asana 설정에는 Asana API Base URL, Authorization URL, Amazon Quick 화면에서 복사한 Redirect URL, Asana OAuth 애플리케이션의 Client ID와 Client Secret을 입력한다. 그런 다음 Chat agents 메뉴에서 새 채팅 에이전트를 만들고 이름과 목적을 지정한다. 에이전트 빌더의 Actions 섹션에서는 앞서 만든 New Relic 통합과 Asana 통합을 기존 통합으로 연결해, 두 서비스의 액션을 에이전트가 사용할 수 있게 한다.
7. 에이전트 지침과 RCA 브리프 생성 규칙
원문은 Incident triage assistant에 넣을 구체적인 지침도 제시한다. 에이전트의 주된 역할은 온콜 엔지니어가 New Relic 추론 도구를 사용해 장애를 트리아지하도록 돕고, 조사가 끝나면 RCA 브리프가 포함된 Asana 태스크를 만드는 것이다. 응답은 간결하고 운영 중심이어야 하며, 추측하지 않고 도구 출력물을 근거로 사용해야 한다. 입력이 부족하면 서비스 또는 엔티티 이름, 환경, 시간 범위를 물어야 한다. 기본 RCA 브리프 형식은 1~2줄 요약, 영향 범위, 가능성 있는 트리거, 링크가 포함된 핵심 증거, 세 가지 권장 다음 조치로 구성된다. 또한 알림, 영향 범위, 로그, 트랜잭션, 세분화 질문에 따라 어떤 New Relic 도구를 라우팅할지도 명확히 지정한다.
8. 테스트 흐름, 보안 거버넌스, 정리
테스트 단계에서는 Incident triage assistant를 열고 체크아웃 서비스의 지연과 서버 오류를 지난 24시간 기준으로 확인해 RCA 브리프를 생성하라는 프롬프트를 보낸다. 에이전트는 New Relic 추론 도구를 순차적으로 호출한 뒤 요약, 영향 범위, 가능성 있는 트리거, New Relic로 연결되는 핵심 증거, 세 가지 권장 조치를 포함한 RCA 브리프를 만든다. 이후 Asana 프로젝트 확인을 요청하면 사용자는 SRE Incident Triage 프로젝트에 작업을 만들라고 승인한다. 보안 고려사항으로는 New Relic 읽기 전용 또는 제한된 역할 사용, Asana 태스크 생성 권한의 프로젝트 범위 제한, OAuth 범위 최소화, PII·고객 식별자·이메일·IP·토큰·자격 증명·내부 호스트명·환경 변수 등 민감 정보 제외가 제시된다. 프로토타입 후에는 채팅 에이전트, New Relic 및 Asana 커넥터, Asana OAuth 자격 증명, 테스트 자격 증명을 삭제하거나 회전해야 한다.
🧾 핵심 주장 / 시사점
- 이 글의 핵심 가치는 새로운 조사 도구 하나를 추가하는 데 있지 않고, 분산된 관측·분석·업무 인계 단계를 하나의 대화형 흐름으로 묶어 장애 대응의 표준화를 돕는 데 있다.
- 에이전트가 RCA를 작성하더라도 원문은 추측 금지, 도구 출력 근거 사용, 입력 부족 시 추가 질문, 민감 정보 제외를 반복해 강조하므로 자동화보다 운영 통제와 증거 기반 요약이 더 중요한 설계 원칙으로 제시된다.
- Asana 태스크는 원시 인시던트 데이터 저장소가 아니라 교대와 후속 조치를 위한 인계 요약으로 취급되어야 하며, 권한 최소화와 데이터 최소화가 실제 운영 배포 전 필수 조건으로 제시된다.
✅ 액션 아이템
- Amazon Quick 채팅 에이전트와 New Relic 기본 커넥터, Asana 기본 커넥터를 결합해 단일 프롬프트로 조사·RCA·인계 흐름을 구현한다.
- New Relic 연동에서 알림 원인, 사용자 영향 범위, 로그 오류 신호, 느린 트랜잭션, 자연어 NRQL 질의 다섯 도구를 상황별로 호출할 분기 규칙을 정한다.
- 보안상 New Relic과 Asana 권한은 최소화하고, 작업 메모는 원시 데이터 내보내기가 아닌 인계 요약만 남기도록 출력 규칙을 제한한다.
❓ 열린 질문
- 장애 대응 시 단일 프롬프트 안에서 증거 수집·영향 평가·후속 작업 생성을 어떤 우선순위로 배열할 것인가?
- 자연어 기반 NRQL 질의를 포함한 다섯 가지 조사 도구를 언제 어떤 조합으로 호출해야 판단 일관성이 확보될 수 있는가?
- Asana 작업 메모에서 PII·자격 증명·내부 식별 정보를 배제하려면 어떤 식별 규칙과 점검 지점을 두어야 하는가?