운영 에이전트는 조사 대상 시스템을 실제로 볼 수 있을 때만 유용합니다.
AWS DevOps Agent는 팀에게 클라우드 운영 작업을 위한 자연어 진입점을 제공합니다. TrueWatch MCP Server는 이 에이전트가 로그, 메트릭, 트레이스, RUM 데이터, 대시보드, 모니터 및 관련 조사 컨텍스트 등 관측 가능성 데이터를 거버넌스가 적용된 방식으로 조회할 수 있게 해줍니다. 두 가지를 함께 사용하면 엔지니어는 "이 오류 급증 시점에 무엇이 변경되었는가?"와 같은 프로덕션 질문에서 시작할 수 있고, 에이전트는 프롬프트 컨텍스트만으로 추측하는 대신 범위가 지정된 도구를 통해 증거를 수집할 수 있습니다.
이 가이드는 실제 연결 흐름을 단계별로 설명합니다. 이를 권한 모델이 아니라 통합 패턴으로 받아들이시기 바랍니다. MCP는 인터페이스 문제, 즉 에이전트가 올바른 관측 가능성 도구를 호출할 수 있는가에 답합니다. 프로덕션 배포에는 여전히 워크스페이스 범위, 최소 권한 키, 읽기 전용 기본값, 부작용이 있는 작업에 대한 승인, 도구 호출 감사 기록이 필요합니다.
AWS DevOps Agent가 제공하는 것
AWS DevOps Agent는 AWS에서 제공하는 AI 운영 어시스턴트로, 사용자가 자연어 상호작용을 통해 클라우드 리소스를 다루고, 문제를 해결하고, 인프라 관련 결과물을 생성할 수 있도록 설계된 AI DevOps 에이전트입니다.
관측 가능성 작업에서 중요한 것은 채팅 인터페이스 자체가 아닙니다. 가치는 에이전트를 최신 프로덕션 신호에 연결하고 그 접근 범위를 제한된 상태로 유지하는 데서 나옵니다. 이러한 연결이 없으면 에이전트는 있음직한 장애 패턴을 설명하는 데 그칩니다. 범위가 지정된 MCP 연결이 있으면 에이전트는 현재 텔레메트리를 직접 확인하고 사용한 증거를 인용할 수 있습니다.
TrueWatch MCP Server가 제공하는 것
TrueWatch는 최신 프로덕션 시스템을 운영하는 엔지니어를 위한 관측 가능성 플랫폼입니다. 인프라 모니터링, 애플리케이션 성능 모니터링(APM), 로그 관리, 분산 트레이스, RUM, 대시보드, 알림, 클라우드 리소스 데이터를 하나의 공유된 조사 컨텍스트로 통합합니다.
TrueWatch MCP Server는 선별된 TrueWatch 기능을 MCP 호환 클라이언트에 노출합니다. 이 글에서는 AWS DevOps Agent가 TrueWatch MCP Server에 연결하여 다음과 같은 읽기 중심 도구 세트를 제공받습니다:
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
먼저 읽기 전용 도구부터 시작하십시오. 프로덕션 시스템을 변경하는 워크플로로 접근 권한을 확장하기 전에, 에이전트가 증거를 조회하고 요약하며 다음 단계를 제안하도록 하십시오.
통합 경로
통합 흐름은 다음과 같습니다:
AWS DevOps Agent -> MCP Server registration -> TrueWatch MCP Server -> TrueWatch observability data정확한 AWS UI는 변경될 수 있습니다. 하지만 운영상의 흐름은 다음과 같이 익숙한 형태로 유지됩니다: MCP 서버 등록, 엔드포인트 및 인증 정보 추가, Agent Space에 서버 연결, 허용할 도구 선택, 경로 검증을 위한 읽기 전용 조사 실행.
1. MCP 서버 등록 항목 열기
AWS DevOps Agent 콘솔을 엽니다. 기능 메뉴에서 Setting으로 이동한 다음 Register를 선택합니다. 등록 페이지에는 GitLab, ServiceNow, Slack, MCP Server 등 타사 통합 항목이 나열됩니다. TrueWatch MCP Server 등록 흐름을 시작하려면 MCP Server를 선택합니다.
연결 흐름이 성공적으로 시작되면 페이지에 다음과 유사한 메시지가 표시됩니다:
AWS DevOps Agent MCP Server associated successfully2. TrueWatch MCP Server 엔드포인트 구성
MCP 서버 세부 정보 페이지에서 핵심 구성을 완료합니다.
전송 프로토콜 확인
MCP 서버는 Streamable HTTP 전송을 지원해야 합니다. 엔드포인트를 추가하기 전에 이를 확인하십시오.
인증 흐름 선택
Authorization 구성을 열고 TrueWatch MCP Server 설정에 맞는 인증 방식을 선택합니다.
서버 이름 지정
Name에는 다음과 같이 명확한 이름을 사용하십시오:
TrueWatch MCP Server여러 워크스페이스를 운영하는 경우 환경을 설명하는 이름을 사용하십시오. 예를 들어 TrueWatch MCP Server - Production Read Only와 같이 지정합니다.
엔드포인트 URL 추가
Endpoint URL에는 해당 워크스페이스의 TrueWatch MCP Server 엔드포인트를 추가합니다.
대상 형식 예시:
https://toby-ai.truewatch.com/toby_ai_mcp/mcp이 가이드를 게시하거나 공유하기 전에 최신 TrueWatch 문서에서 최종 엔드포인트를 확인하십시오. 이 URL은 AWS CloudTrail 로그에도 나타날 수 있으므로 엔드포인트 자체에 비밀 정보를 포함하지 마십시오.
페이지에 Description 항목이 있다면 다음과 같이 간단한 운영 메모를 추가하십시오:
프로덕션 조사를 위한 읽기 전용 관측 가능성 도구.보안 정책에 부합하는 경우에만 Dynamic Client Registration을 활성화하십시오. 이 옵션을 사용하면 설정 흐름 중에 DevOps Agent가 MCP 인증 서버에 등록할 수 있습니다.
엔드포인트 구성을 마치면 Next를 클릭합니다.
3. API Key 인증 사용
AWS DevOps Agent는 OAuth Client Credentials, OAuth 3LO, API Key 등의 인증 흐름을 지원합니다. 원본 설정에서는 TrueWatch MCP Server에 API Key 인증을 사용합니다.
이 흐름은 브라우저 리디렉션 단계를 거치지 않고 호출 애플리케이션에 직접적인 인증 경로를 제공합니다. 프로덕션 환경에서는 이 에이전트 연결 전용 키를 사용하고, 필요한 최소한의 데이터와 도구로 범위를 제한하십시오.
헤더 구성
고정 헤더 이름을 다음과 같이 설정합니다:
AuthorizationAPI Key 값 구성
TrueWatch MCP Server 문서에서 정의한 API 키 및 사이트 키 형식을 사용하십시오. 원본 설정에서는 다음과 같은 결합된 값을 사용합니다:
<TRUEWATCH_API_KEY>-<SITE_KEY>여기서:
- <TRUEWATCH_API_KEY>는 TrueWatch 워크스페이스에서 생성한 API 키입니다.
- <SITE_KEY>는 TrueWatch 배포 지역 또는 사이트를 식별합니다.
API Key 생성 또는 검토
TrueWatch 콘솔에서 System Settings를 열고 API Keys로 이동합니다. 이 통합을 위한 키를 새로 생성하거나 기존 키를 검토합니다.
운영 에이전트의 경우 다음과 같이 시작하는 것이 더 안전합니다:
- 읽기 전용 액세스
- 워크스페이스 범위로 제한된 권한
- 광범위한 관리자 역할 부여 금지
- 개발, 스테이징, 프로덕션 환경별 별도 키 사용
- 교체(로테이션) 정책 및 담당자 정보
사이트 키 매핑
TrueWatch 배포 지역은 서로 다른 OpenAPI 엔드포인트에 매핑됩니다. 프로덕션에 사용하기 전에 현재 유효한 매핑을 확인하십시오. 영문 블로그 버전에서는 내부 배포 세부 정보를 노출하지 않고 패턴만 보여줄 수 있습니다:
const SITE_KEY_MAP = { us1: 'https://us1-openapi.truewatch.com', eu1: 'https://eu1-openapi.truewatch.com', ap1: 'https://ap1-openapi.truewatch.com',};구성을 검토한 후, 이전 설정을 확인해야 한다면 Previous를 클릭하십시오. 그런 다음 Next를 클릭하여 제출합니다. 설정이 성공하면 MCP 서버 연결 메시지가 표시됩니다.
4. Agent Space에 MCP 서버 연결
AWS DevOps Agent 메인 페이지로 돌아가 Agent Spaces를 엽니다.
Agent Spaces는 DevOps Agent의 접근 범위, 기능 경계, 운영 범위를 제어합니다. 팀, 환경, 위험 수준을 분리해야 하는 경우 별도의 스페이스를 사용하십시오.
대상 Agent Space를 열고 View details를 클릭한 다음 MCP Server를 찾습니다.
5. MCP 도구 추가 및 구성 저장
MCP 서버 도구 페이지에서 AWS DevOps Agent가 호출할 수 있도록 허용할 도구를 선택합니다.
원본 설정에서는 7개의 TrueWatch MCP 도구를 추가합니다:
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
기본적으로 모든 도구를 에이전트에 제공하지 마십시오. 프로덕션 시스템에서는 데이터를 읽기만 하는 도구부터 시작하십시오. 별도의 승인 절차가 마련되어 있지 않다면 프로덕션 동작을 수정, 삭제, 쓰기, 롤백, 스케일링, 무음 처리하는 도구는 피하십시오.
허용할 도구를 선택한 후 Save를 클릭합니다.
6. 읽기 전용 조사 시작
MCP Server와 도구 권한 구성을 마쳤다면 Agent Space 세부 정보 페이지를 열고 Operator access를 선택합니다.
이 영역에는 토폴로지, 기능, 웹 애플리케이션 액세스와 같은 운영 뷰가 포함되어 있습니다. 첫 테스트에서는 작업 범위를 좁게, 읽기 전용으로 유지하십시오.
Start investigation을 클릭합니다. Investigation starting point에 구체적인 조사 요청을 입력합니다. 첫 테스트로 적합한 예시는 다음과 같습니다:
지난 15분간의 오류 로그를 분석하고 서비스 및 오류 유형별로 그룹화하십시오.또는:
최근 트레이스 오류가 발생한 서비스를 찾아 각 발견 사항의 근거를 요약하십시오.프롬프트에는 에이전트가 어떤 증거를 조회하고 어떻게 요약해야 하는지를 명시해야 합니다.
페이지에 Fetching data 또는 Investigating과 같은 상태가 표시되고 출력에 MCP 도구의 결과가 포함되어 있다면 연결 경로가 정상적으로 작동하는 것입니다.
데모: 지난 15분간의 오류 로그 분석
원본 데모에서는 다음과 같은 간단한 요청을 사용합니다:
지난 15분간의 오류 로그를 분석하십시오.AWS DevOps Agent는 요청을 해석하고, 조사 계획을 수립하고, TrueWatch MCP 도구를 호출한 다음 반환된 데이터를 요약합니다.
원본 흐름에서 에이전트는 다음을 수행했습니다:
- 최근 오류 데이터를 조회했습니다
- 오류를 유형별로 그룹화했습니다
- 영향을 받은 서비스를 식별했습니다
- 원본 로그 샘플을 포함했습니다
- 주요 발견 사항을 요약했습니다
3개의 서비스, 3가지 서로 다른 장애 양상 — 이것이 실제 마이크로서비스 모니터링의 모습입니다. 오류를 하나의 일반적인 인시던트로 뭉뚱그리지 않고, 특정 서비스와 시간 구간에 연결지어 파악하는 것입니다.
결과 예시 형태
데모 시간 구간에서 조사를 통해 세 가지 범주의 오류가 식별되었습니다.
구성을 찾을 수 없음
- 오류 유형: forethought.utils.exceptions.APIException
- 오류 코드: ftLogackupCfgNoExists
- 서비스: inner-api
- 설명: 데이터 전달 구성을 찾을 수 없습니다
쿼리 타임아웃
- 오류 유형: errors.errorString
- 서비스: kodo-inner
- 설명: 쿼리 타임아웃으로 인한 내부 서버 오류
알 수 없는 API 오류
- 오류 유형: forethought.utils.exceptions.APIException
- 오류 코드: ft.CloudCareApiError
- 서비스: front-api
- 설명: 알 수 없는 API 오류
중요한 점은 에이전트가 문단을 하나 생성했다는 것이 아닙니다. 중요한 점은 그 답변을 도구 호출, 시간 구간, 서비스, 로그 샘플, 쿼리 결과로 거슬러 추적할 수 있다는 것입니다.
자주 묻는 질문
Q: AWS DevOps Agent가 TrueWatch 데이터에 쓰기 권한을 가져야 합니까? A: 아니요, 처음에는 그렇지 않습니다. 읽기 ���용 도구만으로 시작하십시오. 프로덕션 동작을 수정, 삭제, 롤백하는 도구로의 확장은 별도의 사람 승인 절차가 마련된 이후에만 진행하십시오.
Q: 이 통합을 위해 API 키를 설정하는 가장 안전한 방법은 무엇입니까? A: 공유 키나 관리자 수준 키가 아니라, 이 에이전트 연결에만 범위를 제한한 전용 키를 사용하십시오. 모범 사례는 워크스페이스 범위로 제한된 권한, 광범위한 관리자 역할 배제, 환경별(개발/스테이징/프로덕션) 별도 키 사용, 그리고 담당자가 지정된 교체(로테이션) 정책을 갖추는 것입니다.
Q: 이 통합을 프로덕션에서 실제로 안전하게 실행할 수 있는지 어떻게 확인합니까? A: 첫 조사 이후 다음 세 가지를 확인하십시오: 데이터 범위(에이전트가 의도한 워크스페이스/환경/시간 범위만 조회했는가), 도구 범위(활성화된 모든 도구가 실제로 사용되었는가 — 사용되지 않은 도구는 제거), 증거 품질(엔지니어가 답변을 특정 서비스, 시간 구간, 오류 유형, 쿼리 경로로 거슬러 추적할 수 있는가).
Q: TrueWatch MCP Server와 Toby AI Agents의 차이는 무엇입니까? A: MCP Server는 인터페이스 계층으로, AI 클라이언트가 TrueWatch의 관측 가능성 도구를 호출할 수 있게 해줍니다. Toby AI Agents는 그 위에 구축된 완전한 운영 모델로, 트러블슈팅 방법론, 권한 경계, 증거 추적, 승인 흐름, 역할 기반 동작, 조치 이후 검증을 포함합니다. MCP는 "에이전트가 데이터를 볼 수 있는가?"에 답하고, Toby AI Agents는 "에이전트가 조치를 취해야 하는가, 그리고 이를 어떻게 통제할 것인가?"에 답합니다. 이것이 바로 프로덕션에 적합한 AI 에이전트 관측 가능성에 실제로 요구되는 것입니다.
Q: 이 설정에서 피해야 할 것은 무엇입니까? A: 기본적으로 사용 가능한 모든 도구를 에이전트에 제공하지 마십시오. 엔드포인트 URL에 비밀 정보를 포함하지 마십시오(AWS CloudTrail 로그에 노출될 수 있습니다). 프로덕션 상태를 변경하는 작업에 대해 사람의 승인을 생략하지 마십시오. 첫 테스트를 프로덕션 Agent Space에서 실행하지 말고, 먼저 비프로덕션 워크스페이스를 사용하십시오.

