AWS DevOps Agent로 Slack 인프라 조사 챗봇 만들기 – MSP 비용 도구와 Datadog까지 채널 하나로

작성자 이 정대 작성일 11월 6, 2026 조회수 7

안녕하세요. GS Neotek 이정대 입니다.
인프라를 운영하다 보면 “지금 EC2 몇 대 돌고 있어요?”, “이번 달 비용 왜 늘었어요?” 같은 질문을 하루에도 여러 번 받게 됩니다.
하나하나는 간단하지만, 그때마다 콘솔을 열고 계정과 리전을 바꿔 가며 확인하는 일은 생각보다 손이 많이 갑니다.

이번 글에서는 AWS DevOps Agent를 Slack 채널에 연결해, AWS 인프라를 조사하는 기능을 챗봇 형태로 쓰는 방법을 소개합니다.
장애 대응 같은 무거운 이야기는 빼고, 인프라 운영자 입장에서 “물어보면 바로 답해 주는 동료” 정도로 가볍게 시작할 수 있는 구성입니다.
직접 테스트해 본 화면도 함께 보여 드리겠습니다.

한눈에 보기

구성은 간단합니다

AWS DevOps Agent는 Agent Space라는 단위로 동작합니다.
에이전트가 볼 수 있는 계정과 도구를 묶어 둔 작업 공간이라고 보시면 됩니다.
구성은 이게 전부입니다.

1. Agent Space를 하나 만든다
2. 조사할 AWS 계정에 읽기 전용 Role을 만들어 연결한다
3. 필요한 도구(비용 관리 도구, Datadog)를 붙인다
4. Slack 비공개 채널에 앱을 초대한다

질의응답은 비공개 채널에서만 되니 이 점만 주의하시면 됩니다.

# 비공개 채널에 앱 초대 (서울 리전 Space 기준)
/invite @AWS DevOps Agent - Asia Pacific (Seoul)

조사 대상 계정에 만드는 IAM Role

여러 사람이 쓰는 채널에 붙이는 만큼, 에이전트가 무엇을 볼 수 있는지가 가장 중요합니다.
조사할 계정을 Agent Space에 추가하면, 콘솔이 그 계정에 만들 Role 이름과 정책을 그대로 안내해 줍니다.
이 Role은 해당 Agent Space에서만 쓸 수 있도록 묶여 있어서, 다른 Space나 사람은 사용할 수 없습니다.

대상 계정에 붙는 권한은 두 가지가 전부입니다.

생성·수정·삭제 권한은 없고, 호출한 기록은 계정 CloudTrail에 남습니다.
Lambda 코드까지 보게 하고 싶다면 lambda:GetFunction 같은 읽기 권한만 더하면 됩니다.
그리고 Role을 삭제하면 바로 접근이 끊기기 때문에, 부담 없이 시작하고 정리할 수 있습니다.

Slack에서 물어보기

채널에서 에이전트를 멘션하고 평소 말투로 질문하면 됩니다.
답은 질문 아래 스레드로 달리고, 같은 스레드에서 이어 물으면 앞의 맥락을 유지합니다.

예를 들어 “이 계정에서 비용 많이 나오는 서비스 Top 5와 실제 비용 알려줘”라고 물으면, 연결된 비용 조회 도구로 이번 달 서비스별 비용을 조회해 표로 답해 줍니다.
답변 아래에는 Ran 3 tool calls처럼 어떤 도구를 몇 번 호출했는지도 표시되어, 어디서 나온 숫자인지 확인할 수 있습니다.

“가장 필요 없어 보이는 리소스 1개 찾아줘”처럼 조금 넓은 질문도 가능합니다.
테스트해 보니 비용 데이터와 실제 리소스 상태(정지된 날짜, 태그, 연결된 EBS 볼륨)를 함께 확인해 근거와 예상 비용까지 정리해 줬습니다.
이어서 “정리해줘”라고 하면, 읽기 전용이라 직접 실행하지 않고 정리 대상과 승인이 필요한 부분만 안내합니다.

여러 사람이 같이 쓰는 채널이라, 이렇게 조회는 하되 바꾸지는 않는 동작이 오히려 안심이 됩니다.

MSP 비용 도구와 Datadog을 붙이면

MSP를 통해 AWS를 쓰는 경우의 비용 조회

MSP와 계약해 AWS를 쓰는 경우, 결제 계정이 MSP 쪽에 있어 Cost Explorer로 비용을 보기 어려운 경우가 많습니다.
권한이 막혀 있거나, 보이더라도 할인과 크레딧이 반영된 실제 청구 금액과 다를 수 있습니다.
이럴 때는 MSP가 제공하는 비용 관리 도구를 MCP 서버로 Agent Space에 연결하면 됩니다.

GS Neotek에서는 비용 관리 도구 Clipper를 MCP 서버로 이미 제공하고 있어, 별도 개발 없이 Agent Space에 바로 연결할 수 있습니다.
조회 계정이 고객사별로 분리되어 있어 해당 고객사의 비용만 조회되고, 서비스별 비용과 RI·Savings Plan 사용률까지 같은 채널에서 물어볼 수 있습니다.
“리소스는 이런데 비용은 얼마인지”를 한 번에 물어볼 수 있다는 점이 써 보면서 가장 편했던 부분입니다.

Datadog 연동

모니터링을 Datadog으로 하고 있다면 텔레메트리 기능에서 Datadog을 연결할 수 있습니다.
Datadog 쪽에서 MCP Access를 켜고 읽기 전용 키만 넣어 주면 됩니다.
연결 후 5~10분 정도 지나면 “최근 1시간 CPU 사용률 요약해줘” 같은 질문에 Datadog 데이터로 답합니다.

채널에 초대만 하면 되는 이유

이렇게 연동해 두면 인프라 담당자가 아닌 개발자도 따로 설정할 것이 없습니다.
AWS 콘솔 권한이나 Datadog 계정, 비용 도구 접근 권한을 사람마다 나눠 줄 필요 없이, Slack 채널에 초대하는 것만으로 같은 질문을 같은 방식으로 할 수 있습니다.
“이번 배포 이후 에러가 늘었나요?”, “우리 서비스 이번 달 비용은요?” 같은 질문을 인프라 담당자를 거치지 않고 바로 확인할 수 있게 됩니다.

Kiro나 Claude에 MCP를 붙이는 것과 뭐가 다른가

이미 AI 도구로 인프라를 운영하시는 분이라면 “Kiro에 MCP 붙여서 쓰면 되는 거 아닌가?”, “Claude에 도구 연결하면 똑같지 않나?”라는 생각이 드실 수 있습니다.
솔직히 말씀드리면, 분석하는 과정 자체는 큰 차이가 없습니다.
개인 도구에 직접 설정해서 쓰는 쪽이 응답 속도도 빠르고 비용도 저렴한 편입니다.

차이는 누가, 얼마나 쉽게 쓸 수 있느냐에 있습니다.

정리하면 AWS DevOps Agent를 Slack에 붙이는 방식은 더 똑똑한 분석을 위한 것이라기보다, 필요한 연동과 지침이 이미 적용된 에이전트를 조직 구성원 모두가 채널 초대만으로 쓸 수 있게 하는 범용성에 맞춰져 있습니다.
인프라 담당자 한 명이 잘 쓰는 도구를 팀 전체가 쓰는 도구로 넓히는 방법이라고 보시면 됩니다.

마무리 – 질문에 답하는 챗봇에서 먼저 조사하는 에이전트로

이번 글에서는 사람이 물어보면 답하는 챗봇까지만 가볍게 다뤘습니다.
사실 AWS DevOps Agent의 기능은 이보다 훨씬 많습니다.
조사 리포트, 후속 조사, 완화 계획, 토폴로지 같은 기능이 이미 들어 있고, 작업 역할까지 부여하면 조사에서 끝나지 않고 실제 처리까지 하도록 만들 수도 있습니다.

• 웹훅으로 자동 조사
  CloudWatch 알람이나 Datadog 모니터 같은 이벤트를 웹훅으로 받으면, 사람이 열기 전에 조사가 먼저 시작됩니다. 담당자는 도착한 리포트부터 보면 됩니다.
• 파이프라인 연동
  GitHub, GitLab 같은 저장소를 연결하면 배포 변경 이력과 장애를 엮어서 분석할 수 있습니다.
• 작업 역할로 실제 처리까지
  작업 역할을 부여하면 에이전트가 지원되는 작업을 직접 처리할 수 있습니다. 각 변경은 실행 전에 사용자 승인을 거치도록 되어 있습니다.

처음부터 모든 것을 연결할 필요는 없다고 생각합니다.
우선 Slack 채널 하나와 읽기 전용 Role로 가볍게 연동해 챗봇 형식으로 써 보면서, 팀이 어떤 질문을 많이 하는지 살펴보는 것부터 시작해 보시길 권합니다.
그다음 웹후크로 자동 조사를 붙일지, 작업 역할로 어디까지 처리를 맡길지를 실제 환경에 맞춰 하나씩 구상해 나가면 좋을 것 같습니다.

Slack 채널 하나로 시작한 인프라 조사 챗봇이, 연동을 하나씩 더할수록 알람이 오면 먼저 조사하고 승인된 조치까지 이어가는 운영 에이전트로 자라날 수 있다는 점이 AWS DevOps Agent에서 가장 기대되는 부분입니다.

읽어 주셔서 감사합니다.

참고 자료

• AWS DevOps Agent 서비스 소개
• AWS DevOps Agent 요금
• AWS DevOps Agent 사용 설명서
• 에이전트 스페이스 생성
• 여러 AWS 계정 연결
• Slack 연결
• MCP 서버 연결
• Datadog 연결
• Webhook을 통해 DevOps Agent 호출
• Best Practices for Deploying AWS DevOps Agent in Production (AWS DevOps Blog)