AWS 한도 중 실제로 현재 값은 무엇일까요? 32·5·16을 검증하는 에이전트

AI 요약

AWS 한도 정보는 공식 문서, Service Quotas 콘솔, 가격 페이지에서 서로 다르게 나타날 수 있습니다. 글쓴이는 문서 하나를 검색해 얻은 숫자를 그대로 쓰면 오래된 값이 운영 환경에 들어갈 수 있다고 설명합니다. 이를 해결하려고 출처별 AWS 정보를 구조화해 저장하고, 어떤 값이 우선하는지 규칙으로 정한 뒤, 실시간 AWS API를 읽기 전용으로 조회해 기록과 실제 환경의 차이까지 보여주는 에이전트를 만들었습니다.

키워드 검색은 오래된 값을 고릅니다

예시는 EBS 범용 SSD 볼륨의 최대 IOPS입니다. 현재 gp3 한도는 80,000 IOPS지만, 오래된 gp2 안내서에는 16,000 IOPS가 남아 있습니다. 오래된 문서에는 사용자가 검색창에 넣을 법한 표현이 그대로 들어 있어 TF-IDF 검색 점수가 더 높게 나옵니다. 실제 비교에서 오래된 16,000 값은 0.8626, 현재 80,000 값은 0.2026을 얻었습니다. 키워드 검색은 더 높은 점수를 받은 낡은 수치를 정답처럼 내놓습니다.

구조화한 출처와 결정론적 규칙

각 정보는 Sanity 데이터셋의 awsFact 문서로 저장합니다. 서비스, 정보 유형, 리전, 값, 단위, 적용일, 출처 이름과 종류를 필드로 둡니다. 값이 충돌하면 출처 우선순위를 먼저 적용합니다. Service Quotas 콘솔과 가격 페이지가 변경 기록보다 앞서고, 변경 기록은 공식 문서보다, 공식 문서는 블로그보다 앞섭니다. 같은 우선순위라면 적용일이 더 최근인 값을 선택합니다. 글쓴이는 일반 문장만으로는 이 규칙을 적용하기 어렵고, 구조화된 스키마가 선택 기준을 명확하게 만든다고 설명합니다.

Sanity Context Knowledge Base는 이 자료를 색인하고, Context MCP의 knowledge_base_search와 knowledge_base_read 도구로 관련 항목을 찾습니다. 모델은 검색 결과를 설명하는 문장을 작성하지만 값의 승자를 고르지는 않습니다. 일반 함수가 우선순위와 날짜에 따라 값을 결정하고, 별도 가드가 모델 응답과 그 값을 대조합니다. 둘이 다르면 모델 문장을 버리고 결정론적 결과를 내보냅니다. 글쓴이는 한 실행에서 모델이 값을 잘못 표현했지만 가드가 이를 잡아 올바른 답으로 교체했다고 적었습니다.

기록과 실제 AWS 상태를 따로 표시합니다

에이전트는 조정된 기록을 얻은 뒤 Service Quotas, Price List API, EC2, RDS 등을 읽기 전용으로 조회합니다. 데모에서 EC2 On-Demand Standard vCPU 한도는 오래된 사용자 가이드의 32, 조정된 기록의 5, 실시간 계정 값의 16으로 나뉘었습니다. 시스템은 하나를 숨기지 않고 세 값과 출처를 나란히 보여주며 DRIFT로 표시합니다. 글쓴이는 이를 시스템 실패로 감추지 않습니다. 기록과 실제 환경이 달라졌다는 점 자체가 답이라고 설명합니다.

다른 데모 결과로 EBS gp3 최대 IOPS는 기록상 80,000이며 오래된 안내서 값은 16,000입니다. 일치하는 실시간 한도가 없어 확인 불가로 표시합니다. S3 Standard 가격은 기록과 실시간 값이 모두 GB·월당 0.023달러로 일치합니다. RDS PostgreSQL의 가장 오래된 주요 버전은 기록상 13, 실시간 확인은 11로 차이가 납니다. Lambda 동시 실행 한도는 1,000으로 기록됐지만 실시간 대응 항목은 없습니다. Graviton4 R8g 가용성은 기록과 조회 결과 모두 사용 가능으로 나옵니다. 실시간 값은 계정에 따라 달라질 수 있으며, 실시간 조회가 불가능한 항목에는 확인한 척하지 않고 unavailable이라고 표시합니다.

구현 과정과 실행 방법

구성은 Amazon Nova Pro, Bedrock, Python용 Strands Agents, Sanity Context Knowledge Base와 읽기 전용 AWS 조회입니다. AWS 자격 증명 없이도 공개 데이터셋을 익명 GROQ로 읽고 로컬에서 값을 조정한 뒤 실시간 조회를 실행하는 경로를 제공합니다. 전체 LLM 경로에는 Bedrock 리전과 Sanity Context Viewer 토큰이 필요합니다. JSON 출력 모드도 제공해 다른 프로그램에서 결과를 이어서 쓸 수 있습니다.

글쓴이는 구현 중 모델이 조회 결과 대신 빈 문자열을 조정 함수에 전달해 값이 사라진 문제를 겪었습니다. 이를 막으려고 서버에 마지막으로 가져온 실제 조회 결과를 보관했습니다. 또 모델이 정보 유형을 잘못 추측해 실제 항목을 놓치는 경우에는, 유형까지 적용한 조회가 비었을 때 서비스와 리전만으로 다시 조회하도록 바꿨습니다. 이 글의 설계는 AWS에만 한정되지 않습니다. API 버전, 가격, 규정, 의존성 버전처럼 출처마다 값이 다르고 현재 값을 판별해야 하는 자료에도 같은 구조를 적용할 수 있다고 제안합니다.

dev.to 반응

• @sinarezaei — 단순해 보이지만 실제로 답을 믿어야 하는 순간 어려워지는 문제를 잘 다룬 접근입니다. 어떤 숫자가 맞는지 모델이 결정하지 못하게 한 점이 특히 좋습니다. 구조화된 사실, 출처 우선순위, 결정론적 조정, 모델 응답, 가드, 실시간 AWS 확인으로 이어지는 흐름이 훨씬 흥미롭습니다. 32와 5와 16 사례도 요점을 잘 보여줍니다. 충돌을 감추고 자신만만한 숫자 하나를 반환하는 대신, 불일치를 드러내고 조정된 값이 실시간 환경에서 달라졌는지 확인합니다. API 버전, 가격, 규정, 의존성 버전, 사내 정책처럼 실제 질문이 ‘현재 값이 무엇인가요?’인 분야에도 이 구조를 쓸 수 있겠습니다. 제게 가장 인상적인 부분은 AI 에이전트 자체가 아닙니다. AI가 주장할 수 있는 내용을 제한하는 주변 아키텍처입니다. 신뢰할 수 있는 AI 시스템을 만드는 데 훨씬 실용적인 방식입니다.
• @salman_khan_c31307505285e — AI를 훨씬 더 나은 방식으로 활용했고, 한계도 더 잘 정리했습니다.
  • @sarvar_04 — 바로 그 점입니다 💯
• @micheypico — 모델 라우팅 계층을 운영하면서 보는 모습과 같습니다. 저희는 heypico.ai에서 하나의 키로 32개 모델을 다룹니다. LLM 주변의 결정론적 기반이 다중 모델 구성을 실용적으로 만듭니다. 작업 도중 제공업체가 요청을 제한하면 상태 머신이 재시도할지, 다른 제공업체로 넘길지, 오류를 낼지 결정합니다. LLM은 그 결정을 안정적으로 내리지 못합니다. ‘불안정한 에이전트’를 디버깅하다 보면, 괜찮은 모델 주변에 상태 머신이 빠져 있는 문제인 경우가 많습니다.

원문: dev.to / 번역·요약: Trawling