AWS AgentCore로 첫 AI 에이전트를 만들었습니다 — 가장 어려웠던 건 AI가 아니었습니다

AI 요약

Udacity의 Future AWS Agent Engineer Nanodegree 프로젝트에서 Amazon Bedrock AgentCore와 Strands SDK를 사용해 고객 지원 에이전트를 만들었습니다. 주문 조회와 환불 처리, 상품·정책 질의, 세션 간 고객 정보 기억, 로열티 할인 계산, 실시간 웹 탐색을 구현했습니다. 처음에는 서비스 이름과 구성 요소를 한꺼번에 이해하려다 부담을 느꼈지만, 전체 구조를 외우는 대신 다음에 필요한 것부터 파악하면서 프로젝트를 진행했습니다.

서비스 목록 대신 역할을 따라가기

에이전트는 고객 요청을 파악하고 필요한 기능을 선택합니다. Amazon Nova 2 Lite는 요청을 이해하고 도구 사용을 결정하며, Strands SDK는 에이전트와 도구를 연결합니다. AgentCore Runtime은 배포한 에이전트를 실행하고, AgentCore Gateway는 에이전트와 백엔드 도구 사이를 잇습니다. 주문 관련 API는 API Gateway가 노출하고 Lambda가 실제 작업을 수행합니다.

상품·정책 정보는 Amazon Bedrock Knowledge Base에서 검색합니다. AgentCore Memory는 이전 세션에서 저장한 고객 맥락을 불러오고, Code Interpreter는 할인 계산을 코드로 처리합니다. Browser Tool은 실시간 웹페이지와 상호작용하며 CloudWatch는 실행 환경을 모니터링합니다. 각 서비스가 무엇을 해결하는지 기준으로 구조를 나누자, AWS 서비스를 단순한 목록이 아니라 요청이 흐르는 경로로 이해할 수 있었습니다.

모델의 응답과 실제 작업은 다릅니다

주문 조회는 AgentCore Gateway에서 API Gateway와 Lambda를 거쳐 실제 주문 정보를 가져오게 했습니다. 환불도 Gateway를 통해 Lambda를 호출하도록 연결했습니다. 에이전트가 “환불을 처리했습니다”라고 답하는 일과 시스템이 실제 환불 작업을 완료하는 일은 별개입니다. 작업이 성공했는지 확인하고 그 결과를 에이전트에 돌려줘야 응답이 실제 상태를 반영합니다.

상품·정책 질문에는 RAG 방식을 적용했습니다. 질문과 관련된 정보를 Knowledge Base에서 검색한 뒤 에이전트가 답변에 사용합니다. 모델이 일반 지식을 알고 있더라도 애플리케이션만의 정보를 알고 있다고 볼 수 없기 때문입니다. Memory 기능은 한 세션에서 알려준 고객 이름과 응답 선호를 다른 세션에서 다시 찾는 방식으로 시험했습니다. 실제 서비스라면 어떤 정보를 저장하고 얼마나 보관할지, 누가 접근할 수 있는지도 정해야 한다고 짚습니다.

로열티 할인 계산에서는 포인트와 금액을 잘못 다룬 계산 로직을 직접 수정했습니다. 문제는 모델이 아니라 코드에 있었습니다. 정확한 산술은 모델의 추론에 맡기기보다 Code Interpreter에서 코드로 처리하는 편이 적절하다는 점도 확인했습니다. Browser Tool은 Udacity 웹사이트를 열어 페이지 제목을 반환하도록 시험했습니다. Knowledge Base가 애플리케이션에 저장된 자료를 검색한다면, 브라우저는 실시간 웹페이지를 직접 다룹니다.

권한과 설정도 디버깅 대상입니다

기능이 동작하지 않을 때 처음에는 코드 문제를 의심하기 쉽지만, 이 프로젝트에서는 IAM 권한이 원인이 되기도 했습니다. Browser Tool을 구성했는데도 런타임이 브라우저 세션을 시작하지 못한 사례에서는 런타임에 필요한 권한을 추가한 뒤 다시 시험해 정상 동작을 확인했습니다. 리소스가 존재하는지, 올바른 리전에 있는지, 런타임 역할이 필요한 작업을 허용하는지, 도구 설정이 맞는지 확인하는 습관이 디버깅에 도움이 됐습니다.

배포 성공을 애플리케이션 전체의 성공으로 간주하지 않고, 배포 뒤 여섯 기능을 각각 테스트했습니다. 주문 조회, 환불, 지식 검색, 세션 간 기억, 할인 계산, 웹 탐색을 따로 확인해 거대한 단일 성공·실패 판정을 작은 검증으로 바꿨습니다. 작성자는 각 기능의 테스트 증거를 남겼고, 여섯 기능이 모두 동작하는 것을 확인했습니다.

동작하는 시스템과 운영 가능한 시스템

CloudWatch로 AgentCore Runtime을 모니터링하고 CPU 사용량 알람을 만들었습니다. 실제 서비스로 확장한다면 실패 요청, 오류율, 응답 시간, 도구 호출 실패, 리소스 사용량, 서비스 상태와 비용도 살펴야 한다고 설명합니다. 여러 관리형 서비스를 쓰면 요청량이 적을 때와 규모가 커졌을 때 비용이 달라질 수 있습니다. 프로젝트가 끝난 뒤에는 만든 AWS 리소스를 정리했습니다. 작업을 마치는 과정에는 실행 중인 리소스와 불필요한 비용을 확인하는 일도 포함된다고 강조합니다.

글의 결론은 전체 구조를 미리 완벽히 이해하려 하기보다, 사용자가 원하는 동작을 기준으로 시스템에 필요한 요소를 하나씩 파악하라는 것입니다. 모델이 포함된 애플리케이션에도 계산 오류, 설정 문제, 권한 부족 같은 일반적인 소프트웨어 문제가 남습니다. 에이전트의 도구와 백엔드가 실제로 무엇을 했는지 확인하고, 기능별로 시험하며, 운영과 정리까지 고려해야 합니다.

dev.to 반응

• @nyaomaru — 좋은 글입니다! 특히 “모델이 작업이 끝났다고 말하는 것”과 “시스템이 실제로 작업을 수행하는 것”의 차이가 인상 깊었습니다. AI 에이전트를 만들 때 가장 중요한 부분 중 하나라고 생각합니다. AI는 여러 구성 요소 가운데 하나일 뿐이고, 권한과 백엔드 작업, 모니터링, 배포, 일반적인 소프트웨어 버그도 그만큼 중요합니다. “AI 애플리케이션에도 일반적인 소프트웨어 엔지니어링 문제가 있다”는 말이 특히 기억에 남았습니다. 아직 에이전트를 만들어보진 않았지만, 처음 만들 때 이 글을 다시 찾아보겠습니다.
• @shubhradev — 모델이 작업이 끝났다고 말하는 것과 시스템이 실제로 작업을 수행하는 것에 관한 지적이 좋았습니다. 제가 만든 에이전트에서도 백엔드 호출이 완료되지 않았는데 모델이 성공했다고 보고한 적이 있습니다. 처음 에이전트를 만들 때는 확인 메시지를 믿기보다 실제 결과를 확인하는 편이 좋습니다. 반환된 상태나 실제 레코드 변경이 무엇이 일어났는지 알려줍니다. 글처럼 기능별로 시험하면 이런 실패를 훨씬 쉽게 찾을 수 있습니다.
• @aifrontierpost — 환불 부분에서 가장 실서비스와 관련된 실패 유형을 짚었습니다. 모델이 작업이 끝났다고 말하는 것과 시스템이 실제로 작업하는 것은 다릅니다. 따라서 여섯 가지 테스트는 에이전트의 최종 응답이 아니라 백엔드 레코드를 확인해야 합니다. Shubhradev의 댓글처럼 모델은 Lambda 호출이 끝나지 않았는데도 성공했다고 보고할 수 있습니다. 에이전트의 설명만으로 통과하는 테스트는 자신감 있는 말투만 검사하는 셈입니다. 운영 부분에서 언급한 여섯 가지 기능 점검은 실패 요청과 도구 오류를 정기적으로 확인하는 점검으로 이어져야 합니다. 배포 당일에 남긴 테스트 증거는 시간이 지나면 오래된 정보가 됩니다.
• @csm18 — Andrej Karpathy가 LLM이 새로운 운영체제와 비슷한 것이 될 수 있다고 말한 내용이 떠오릅니다.
  • @hemapriya_kanagala — 그 이야기는 접해본 적이 없습니다. 이제 읽어보고 싶네요. 혹시 Andrej Karpathy가 말한 내용의 링크가 있나요? 댓글을 보고 궁금해졌습니다.
  • @csm18 — 실제로는 Andrej Karpathy의 강연입니다. 제목은 “Software Is Changing (Again)”이고, 해당 발언은 9분 8초쯤 나옵니다.

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