date
slug
author
status
tags(최대 3개)
summary
type
thumbnail
category
updatedAt
TL;DR
- 조사를 이끄는 DevOps 봇을 만들고, 계정과 저장소를 넘나드는 조회는 AWS DevOps Agent에게 맡겼습니다.
- 에이전트는 읽기만 하고, 리소스의 생성과 수정은 사람이 승인합니다.
- 요청을 가르는 판단은 판정 모델 Jev에게 먼저 묻고, 확신할 때만 그 답을 써서 분류 시간을 줄였습니다.
- AWS DevOps Agent는 직접 고칠 수 없는 관리형 서비스라, 안전 필터에 막히면 다시 묻고 스킬 파일 수 한도는 올리기 전에 검사합니다.
- 좋은 답에 필요한 건 더 많은 규칙이 아니라 팀의 노하우였습니다.
들어가며
아임웹 인프라팀은 평소 업무부터 장애 대응까지 AI를 적극적으로 활용하고 있습니다.
각자의 AI 도구가 따를 정책은 사내 AI 가드레일 저장소에 모아 관리하고, 자주 처리하는 운영 업무는 AI가 찾아 쓸 수 있도록 런북으로 정리해 두었습니다.
하지만 내부 운영 이슈, 클러스터 내부 리소스 파악, PR 리뷰, AWS Support 케이스 접수처럼 팀에 자주 들어오는 문의는 여전히 하던 일을 멈추고 직접 처리해야 했습니다. 이런 문의를 자동으로 처리해 주는 봇이 있다면, 더 본질적인 일에 집중할 수 있지 않을까 생각했습니다.
그래서 슬랙에서 문의를 받아 조사를 이끄는 DevOps 봇을 만들고, 여러 계정과 저장소를 넘나드는 조회는 AWS의 관리형 에이전트인 AWS DevOps Agent에게 맡겼습니다.
지금 DevOps 봇은 장애 원인 조사부터 PR 리뷰, AWS·Datadog 비용 질문, AWS Support 케이스 접수, 관리자 계정 잠금 해제처럼 인프라팀에 들어오는 여러 운영 업무를 맡고 있습니다.
처음 봇을 배포하고 에이전트의 답변을 받아보기까지는 하루도 걸리지 않았습니다. 하지만 팀이 봇을 신뢰하고 실사용하게 만드는 것은 전혀 다른 문제였습니다. 팀원이 봇의 답을 재차 확인하지 않고 업무에 활용하려면, 무엇보다 답을 믿을 수 있어야 했습니다.
높은 퀄리티의 답변을 원한다면 AI 에이전트에게 무엇을 줘야 할까요?
처음에는 AI를 믿지 못해 규칙과 코드를 통해 답변을 통제하려고 했지만, 그것이 오히려 좋은 답변까지 막았습니다. 그래서 더 많은 규칙보다 판단을 맡기고, 아임웹 인프라팀만의 정보와 노하우를 찾았습니다.
이번 글에서는 DevOps 봇의 두 축인 AWS DevOps Agent와 판정 모델 Jev를 중심으로, 봇을 만들며 고민했던 과정을 공유합니다.
DevOps 봇의 전체 구성
봇은 EKS에서 Pod로 동작하며, 요청을 판단할 때는 Jev에게 묻고, 조사가 필요하면 AWS DevOps Agent와 A2A로 대화합니다.
AWS DevOps Agent를 고른 이유
대개 인프라 문의는 한 번의 조사로 완료되지 않습니다.
도메인 관련 문의만 해도 DNS를 보고, 그 결과에 따라 인증서를 보고, 다시 배포 설정을 봐야 합니다. 그렇기 때문에 다음에 무엇을 볼지 스스로 정하고, 여러 시스템을 오가는 에이전트가 필요했습니다.
하지만 그러한 기능을 하는 에이전트를 직접 만들려면 무엇을 조회할지 판단하는 기능, 여러 AWS 계정을 넘나들며 조사하는 구조, PR을 검토하는 흐름까지 모두 구현해야 했습니다.
AWS DevOps Agent에는 이 세 가지가 이미 갖춰져 있었습니다.
질문을 받으면 필요한 조회 대상을 스스로 정하고, 조회 결과를 바탕으로 다음에 확인할 곳을 이어서 탐색합니다. 또, AWS 계정을 연결하면 각 계정에 에이전트가 사용할 역할이 만들어지고, PR이 배포 가능한 상태인지 검토하는 기능도 기본으로 제공했습니다.
즉, 직접 구현하려던 핵심 기능을 이미 갖춘 에이전트였습니다.
AWS DevOps Agent란?
AWS DevOps Agent는 AWS가 2026년 3월에 정식 출시한 관리형 AI 에이전트입니다. AWS는 이 에이전트를 '언제든 대기하는 운영 동료’라고 소개합니다.
이 에이전트에게 세 가지 일을 맡겼습니다.
- 장애가 나면 연결된 계정의 리소스·로그·지표와 코드 변경을 살펴 원인 찾기
- PR이 배포해도 되는 상태인지 검토하기
- AWS 환경 전반에 관한 질문에 답하기
그리고 정책을 스킬(Skill)로 올려 두면 에이전트가 그 정책에 따라 조사합니다. MCP(Model Context Protocol)와 A2A 같은 표준 프로토콜도 지원해, 인프라팀 봇처럼 다른 에이전트가 조사를 맡길 수 있습니다.
참고: 공식 문서
AWS 계정들과 GitHub 조직을 에이전트에 연결했고, 덕분에 봇에서 계정별
AssumeRole이나 권한 전환 로직을 따로 구현하지 않아도, 에이전트가 필요한 계정과 저장소를 오가며 조사할 수 있었습니다.
또한, 알림을 보내는 용도라 팀원의 질문이나 버튼 입력을 받을 수 없었기 때문에 Slack 연동은 사용하지 않았고, Slack에서 팀원과 대화하고 요청을 조율하는 역할은 DevOps 봇이 맡았습니다.
그렇다고 조사 전체를 에이전트에게 맡기지 않았습니다.
오히려 무엇을 확인하고 언제 조사를 끝낼지는 봇이 판단하고, 여러 AWS 계정과 저장소를 오가며 확인해야 하는 일은 에이전트에게 맡겼습니다.
요청에 대한 판단은 Jev에게 먼저 묻습니다
DevOps 봇은 요청을 받으면 먼저 어떻게 처리할 요청인지 판단합니다.
여러 곳을 살펴봐야 하는 질문은 AWS DevOps Agent가 조사하고, 비용처럼 조회 대상이 명확한 질문은 봇이 직접 답합니다. 리소스를 만들거나 바꾸는 요청은 승인 카드를 먼저 보여 주고, 인프라팀이 승인한 뒤에 실행합니다.
처음에는 이 판단을 Amazon Bedrock의 Claude가 모두 맡았습니다. 하지만 조사나 PR 리뷰가 필요한지 등 여러 가지 항목을 한 번에 판단하다 보니, 요청 하나를 분류하는 데 중앙값이 3초가 걸렸습니다.
그래서 앞단에 판정 전용 모델인 TypeSafe의 Jev를 도입하게 되었습니다. Jev는 답변을 생성하는 대신 필요한 항목만 빠르게 판단해, 같은 요청을 약 0.2초 만에 분류했습니다.
Jev란?
Jev는 TypeSafe가 만든 판정 전용 모델로, TypeSafe는 Jev를 첫 번째 ‘System One’ 모델이라고 소개합니다. 상태와 질문을 보내면 문장 대신 예/아니오의 확률, 고른 선택지, 점수처럼 코드에서 바로 쓸 수 있는 형태로 답합니다. 나아가 질문을 여러 개 묶어 보내도 응답 시간이 거의 늘지 않습니다.
Jev에게 세 가지 일을 맡겼습니다.
- 요청을 어느 처리 경로로 보낼지 판정하기
- 비용 질문에서 어디를 조회할지처럼 몇 개 중 하나를 고르기
- 승인 요청에서 실행을 막아야 하는지 판단하기
반대로 글을 새로 쓰거나 여러 단계를 거쳐 따져야 하는 일은 Jev에게 맡기지 않았습니다.
참고: 공식 문서
Jev를 도입하기 전에 실제 멘션 720건으로 비교 테스트를 해 보니, Jev의 판단을 모두 사용했을 때 Claude와 같은 갈래로 분류한 비율은 88.8%였습니다. 여기서 차이가 난 경우는 대부분 확률이 애매하거나, ’다시 해봐’처럼 앞선 대화의 맥락이 필요한 짧은 요청이었습니다.
그래서 명확한 요청은 Jev가, 애매한 요청은 Claude가 판단하도록 역할을 나눴습니다.
조회처럼 단순한 요청은 확률이 0.2 이하이거나 0.8 이상일 때만 Jev의 결과를 사용합니다. 반면 PR 승인, AWS Support 케이스, 계정 조치처럼 되돌리기 어려운 요청은 더 보수적으로 잡아, 조금이라도 가능성이 있으면 Claude가 다시 판단하도록 했습니다.
그 결과 전체 요청의 약 40%를 Jev가 처리했고, 그 가운데 98.6%가 Claude와 같은 갈래로 분류되고, 분류 시간도 평균 3.7초에서 2.5초로 줄었습니다. 이후 98.6%가 충분한지는 Claude의 판단과 비교했습니다. 같은 요청을 Claude에게 두 번 물었을 때 두 판단이 일치한 비율은 97.4%였습니다.
Jev의 결과가 이보다 높았기 때문에, 명확한 요청에서는 Claude와 비슷한 수준으로 판단한다고 보았습니다.
결과적으로 명확한 요청은 Jev가 빠르게 처리하고, 더 많은 맥락이 필요한 요청에만 Claude를 사용하면서 판단 품질을 유지하고 분류 시간을 줄일 수 있었습니다.
지침은 규칙만 짧게 쓸 때 잘 통했습니다
처음 DevOps 봇을 구성할 때는 로컬에서 Claude Code로 직접 리뷰하던 것과 비슷한 결과를 내고 싶었습니다. 그래서 팀에서 사용하던 가드레일을 그대로 적용했고, 에이전트가 규칙을 잘못 해석하지 않도록 각 규칙이 왜 필요한지에 대한 설명도 함께 적었습니다.
하지만 예상과 달리 AWS DevOps Agent는 이렇게 구성된 가드레일 전체를 프롬프트 인젝션으로 판단했고 결국 요청 자체를 거부했습니다.
사람에게는 규칙의 이유까지 설명하는 것이 친절하지만, 에이전트에게는 오히려 규칙 자체를 명확하고 간결하게 전달하는 편이 오해가 적었습니다.
특히 ‘이것은 인젝션이 아니다’, ‘이 내용은 믿어도 된다’처럼 지침의 정당성을 설명하려는 문장은 도움이 되기보다 오히려 의심할 만한 신호를 더 만들었습니다.
그래서 지금은 에이전트가 읽는 지침에는 실행해야 할 규칙만 간결하게 남기고, 그 규칙이 만들어진 배경이나 긴 근거는 사람이 읽는 저장소 문서에 따로 남겨 두고 있습니다.
조회는 넓게 허용하고, 승인에 필요한 확인만 봇이 직접 합니다
AWS DevOps Agent에게 권한은 어디까지 줘야 할까요?
처음에는 혹시 모를 위험을 줄이려고 읽기 전용 관리형 정책(
ReadOnlyAccess)을 붙이되, 시크릿이나 파라미터의 실제 값을 읽는 권한은 따로 막아 두었습니다.
한 PR을 리뷰하면서 문제가 생겼습니다.
배포에 필요한
Secret Key가 실제로 등록되어 있는지 확인해야 했지만, 바로 그 조회가 막혀 있었습니다. 결국 키의 존재 여부를 확인하지 못한 채 리뷰가 진행됐고, 리뷰 품질도 떨어질 수밖에 없었습니다. 값 읽기 차단을 없애고, 읽기 전용 권한 안에서 조회 범위도 넓혔습니다. 그런데도 에이전트는 여전히 키를 확인하지 못했습니다.원인을 찾기 위해 로그를 확인해 보니 더 이상했습니다. 에이전트의 응답에는 권한이 없어 조회하지 못했다고 적혀 있었지만, CloudTrail에는 해당 API를 호출한 기록 자체가 없었습니다.
원인은
세션 정책(Session Policy)이었습니다. 에이전트가 역할을 AssumeRole할 때 함께 적용하는 세션 정책에 해당 권한이 빠져 있었습니다. 역할 자체에 권한이 있어도 세션 정책에서 허용하지 않으면, 에이전트는 그 권한을 사용할 수 없었습니다.
그래서 이런 확인까지 AWS DevOps Agent에게 맡기지 않기로 했습니다. 대신 봇이 필요한 키를 직접 확인하고, 그 결과를 AWS DevOps Agent에게 전달하는 구조로 바꿨습니다.
에이전트와는 A2A로 대화하고, 답은 내용으로 확인합니다
그렇다면 DevOps 봇과 AWS DevOps Agent는 답을 어떻게 주고받을까요?
봇은 A2A(Agent-to-Agent) 프로토콜을 통해 에이전트에게 조사나 리뷰를 요청하고, 완료된 결과를 다시 전달받습니다.
A2A(Agent-to-Agent)란?
A2A는 서로 다른 AI 에이전트가 작업을 요청하고 결과를 주고받기 위한 개방형 프로토콜입니다.
사람이 API마다 요청 형식을 직접 맞추는 대신, 에이전트가 어떤 작업을 할 수 있는지 확인하고 작업을 요청한 뒤 결과를 돌려받는 과정을 공통된 방식으로 처리합니다. DevOps 봇도 A2A를 통해 AWS DevOps Agent로 조사나 리뷰 작업을 요청하고 결과를 전달받습니다.
하지만 DevOps 봇은 한 번의 조회로 결론을 내리지 않습니다. 에이전트가 여러 계정과 저장소를 확인하면, 봇이 그 결과를 보고 다음에 볼 곳을 다시 정합니다. 이런 과정을 몇 번 거치다 보니 답을 내기까지 수 분이 걸릴 수 있습니다.
처음에는 앞선 대화를 요약해 함께 전달했지만, 에이전트가 새로운 질문이나 정책 문서로 해석하는 문제가 생겼습니다.
A2A 대화에는 이전 대화의 맥락이 이미 유지되고 있었기 때문에, 봇이 이를 다시 전달할 필요가 없었습니다.
또한 에이전트가 작업을 완료했다고 알려도, 봇은 그 상태만 보고 답을 게시하지 않습니다.
마지막 문장이 ‘조회해 보겠습니다’ 같은 약속이거나 ‘시작할까요?’처럼 되묻는 답은 아직 끝난 답이 아니기 때문에 이런 답을 받으면 봇은 끝까지 진행해 달라고 다시 요청합니다.
응답의 형식은 정책에 적어둔 템플릿을 따릅니다.
예를 들어 PR 리뷰 경우, 답은 첫 줄에
BLOCK, PROCEED WITH CAUTION, SAFE TO RELEASE 가운데 하나를 적게 되고, 봇은 이 줄을 읽어 판정을 한글로 보여 주고, 자동 승인을 판단하는 데 사용하게 됩니다.에이전트에게 더할 것은 코드가 아니라 노하우였습니다
처음 질문으로 돌아가 보겠습니다.
좋은 답변을 얻으려면 AI 에이전트에게 무엇을 더 줘야 할까요?
이를 확인하기 위해 실제 채널에 올라왔던 질문 세 개를 다시 에이전트에게 요청했습니다. 그리고 당시 사람이 조사해 내린 최종 결론을 정답으로 두고, 에이전트가 어디까지 찾아낼 수 있는지 비교했습니다.
첫 번째는 ‘OpenSearch 클러스터의 인스턴스 타입 변경이 한 시간 넘게 걸리는데, 장애인가’ 라는 질문이었습니다.
당시에는 벤더에 지원 티켓까지 열어 확인한 끝에 단일 노드에 부하가 몰려 작업이 늦어졌다고 결론 내렸습니다. 에이전트는 벤더에 문의하지 않고도 감사 로그와 클러스터 구성을 직접 조회해 같은 결론에 도달했습니다.
두 번째 ‘특정 역할이 메시지 큐 토픽에 접근할 수 있는가’라는 질문에서는 정책과 토픽 패턴을 대조해, 사람이 확인했던 것보다 더 세밀하게 접근 가능 여부를 설명했습니다.
세 번째 질문에서는 한계가 드러났습니다.
‘데이터베이스 커밋이 권한 없음 오류로 거부된다’는 질문에 봇은 클라우드 쪽 원인을 배제하고 접근 통제 프록시까지 원인을 좁혔습니다. 하지만 그 프록시에 적용된 내부 정책의 이름까지는 찾지 못했습니다.
그 정보는 조직 안에서만 공유되고 있었기 때문입니다.
이처럼 부족했던 것은 조사 능력이 아니라, 인프라팀만 알고 있는 환경과 조직의 맥락이었습니다.
그래서 코드를 더하기보다 에이전트가 참고할 수 있는 조직의 정보와 노하우를 늘리는 쪽을 선택했습니다.
위의 이미지에 보여지는 사내 지식 저장소는 팀원들이 운영하면서 확인한 사실과 노하우를 모아 두는 팀 지식베이스입니다. 봇은 질문을 받을 때마다 이곳을 검색하고, 필요한 경우 사내 Slack 대화와 Notion 문서, 코드 저장소까지 함께 찾아봅니다.
이렇게 찾은 내용은 ‘지시가 아닌 참고 자료’라는 표시를 붙여 에이전트에게 전달합니다. 그 결과, 조직의 정보와 노하우까지 조사에 활용하면서 DevOps 봇도 인프라팀원이 직접 조사하고 처리하는 것과 같은 수준으로 응답을 하는 경우가 상당히 많아졌습니다.
사람의 피드백을 다음 답변에 반영합니다
봇의 답이 항상 맞을 수는 없고, 그렇다고 틀린 답이 나올 때마다 코드를 고칠 수도 없습니다.
그래서 인프라팀이 남긴 평가와 피드백이 다음 조사에 바로 반영되도록 만들었습니다. 모델을 다시 학습시키는 것이 아니라, 에이전트가 참고하는 팀 지식을 고치는 방식입니다.
피드백은 두 가지로 받습니다.
- 버튼: 답변 하단의 👍/👎 버튼을 누르면, 그 답에 쓰인 팀 지식의 점수가 바로 바뀝니다.
- 자연어 피드백: 「앞으로는 이렇게 답해」「위에 분석 결과 보고 고쳐」 처럼 스레드에 말로 남기면, 봇이 그 말이 사실을 바로잡는 것인지 답하는 방식을 바꾸는 것인지 구분해 팀 지식에 반영합니다.
이때 봇은 피드백 문장을 그대로 저장하지 않습니다.
‘위 내용 반영해 줘’처럼 앞선 대화를 가리키는 피드백이라면 스레드를 다시 읽어 정정된 내용을 뽑고, 그 근거가 실제 대화에 있는지 확인한 뒤에만 저장합니다.
이로 인해 팀원이 응답에 대해 피드백을 주면 그 내용이 다음 조사에 바로 활용됩니다. 봇을 사용하는 과정 자체가, 봇이 참고할 지식을 계속 다듬는 과정이 됩니다.
AWS DevOps Agent의 한계
안전 필터의 원인은 볼 수 없어서, 에이전트 밖의 흐름에서 다뤘습니다
에이전트의 조사 능력은 강력했지만, 관리형 서비스 형태의 에이전트에 조사를 맡기면서 분명한 한계도 확인했습니다. 바로 원인을 들여다볼 수 없다는 것입니다.
한번은 AI 가드레일을 다룬 외부 글을 공유하고 우리 환경과 대조해 달라고 요청했는데, 봇은 답 대신 ‘콘텐츠 안전 필터가 요청 처리를 차단했어’라는 메시지만 남겼습니다.
문제는 무엇이 필터에 걸렸는지 알 수 없었습니다. 탈옥이나 프롬프트 인젝션 같은 단어가 원인이라고 생각했지만, 글의 주제부터 사내 검색 결과, 팀 지식, 방어 문구까지 바꿔 가며 테스트해도 차단은 계속됐습니다.
35번의 시도에서 11번이 차단됐고, 같은 요청도 다시 보내면 통과하는 경우가 있었습니다. 이처럼 입력을 바꿔도 비슷한 비율로 발생했기 때문에 전달한 특정 내용에서 원인을 찾기는 어려웠습니다.
또한 에이전트 내부의 안전 필터는 직접 들여다보거나 고칠 수 없기에 원인을 없애는 대신, 제어할 수 있는 에이전트 밖에서 실패를 처리하기로 했습니다.
봇은 응답을 게시하기 전에 안전 필터의 차단 문구를 확인하고, 차단됐다면 같은 요청을 새 대화로 다시 보내고, 그래도 실패하면 차단됐다는 사실을 그대로 알립니다. 필터 차단, 연결 끊김, 형식 오류 같은 실패 원인도 구분해 기록해, 에이전트 문제와 봇의 문제를 나중에 구분할 수 있도록 했습니다.
이와 같이 관리형 에이전트 내부에서 해결할 수 없는 문제라면, 적어도 그 실패가 사용자에게 그대로 전달되지 않도록 바깥의 흐름은 직접 통제해야 했습니다.
스킬 하나에는 파일을 100개까지만 담을 수 있습니다
Claude Code, Codex와 봇이 인프라 팀과 같은 정책을 읽도록 구조를 통합하면서, 에이전트의 스킬에 올릴 파일도 늘어났습니다.
그러던 중 새 정책을 추가하자 AWS가 요청을 거부했습니다.
File count would exceed limit of 100 (current: 100, adding: 1, deleting: 0)
찾아보니 AWS DevOps Agent의 스킬 하나에는 파일을 최대 100개까지만 담을 수 있었습니다.
그래서 에이전트에게 허용하지 않았던 업무에 관한 런북은 제외하고, CI를 통해 새로운 정책이 추가될 때마다 최대치를 파악하는 workflow를 추가했습니다.
빠른 답이 필요한 순간에는 느립니다
가장 아쉬운 점은 속도입니다.
실제로 장애가 발생해 DevOps 봇에게 원인을 조사해 달라고 요청했을 때, 장애 대응이 모두 끝난 뒤에야 답이 도착한 적이 있습니다. 여러 계정과 저장소를 오가며 근거를 하나씩 확인한 만큼 답은 구체적이었지만, 정작 가장 필요했던 순간에는 활용하지 못했습니다.
원인은 조사 방식에 있었습니다. 근거를 하나씩 확인하는 방식은 평소에는 강점이지만, 1분이 아쉬운 장애 대응에서는 오히려 약점이 됐습니다.
지금은 진행 중인 단계와 경과 시간을 스레드에 보여 주고 있지만, 앞으로는 빠른 1차 답과 근거를 확인하는 깊은 조사를 나누는 방법도 고민하고 있습니다.
정리하며
지금까지 조사와 판단을 중심으로 이야기했지만, DevOps 봇이 하는 일은 그보다 넓습니다.
서비스 상태가 괜찮은지 물으면 지금 상태를 알려 주고, Jira 티켓이 올라오면 원인을 함께 찾아봅니다.
고객 도메인이 제대로 연결됐는지 확인하기도 하고, 네임스페이스를 만들어 달라거나 계정 잠금을 풀어 달라는 요청도 승인을 거쳐 처리합니다. 이 밖에도 팀원들이 Slack에 남기는 크고 작은 요청을 봇이 받아 처리하고 있습니다.
이처럼 반복되던 운영 업무를 봇이 나눠 맡으면서, 인프라팀은 처음 바랐던 대로 더 본질적인 일에 집중할 시간을 조금씩 되찾고 있습니다.
앞으로는 더 많은 팀의 정보와 노하우를 에이전트가 활용할 수 있게 하고, 팀원 모두가 자연스럽게 봇을 사용할 수 있도록 발전시킬 예정입니다.
이 글이 AI를 활용해 팀의 DevOps 봇을 만들려는 분들께 도움이 되면 좋겠습니다.
이호수 DevOps
같은 실수를 두 번 하지 않으려고 경험을 글로 남깁니다.
추측 대신 실측으로 EC2부터 EKS까지 안전하게 인프라를 운영합니다.