에이전트가 판단하고, 컨테이너가 실행한다

일기

10월 20일 새벽 4시, Agentic Azure Insights의 첫 라이브 행사에서 영어 발표를 한다.

Peter De Tender와 함께 첫 라이브 행사의 발표자로 참여하게 되었고, 내가 준비한 주제는 "Agents Decide, Containers Execute: Building Agentic Workloads with Azure Container Apps Jobs"다.

이번 발표를 준비하면서 계속 붙잡고 있는 질문이 하나 있다.

에이전트가 잘못된 데이터를 사용하거나, 내가 정한 범위를 넘어 행동하는 일을 어떻게 줄일 수 있을까?

에이전트가 필요한 일을 판단하고 바로 실행하게 만들 수도 있다. 하지만 에이전트가 코드를 실행하거나 외부 환경을 바꾸기 시작하면, 판단하는 부분과 실제 작업을 수행하는 환경 사이에 조금 더 분명한 경계가 필요하다고 생각했다.

그래서 이번에 준비하고 있는 구조는 비교적 단순하다. 필요한 작업은 에이전트가 판단하고, 실제 실행은 별도의 컨테이너 환경에 맡긴다.

Foundry Routines가 특정 시간이나 반복 일정, 이벤트에 맞춰 에이전트를 시작한다. Microsoft Foundry Agent Service에서 실행되는 에이전트는 어떤 검사가 필요한지 판단한다. Python tool은 입력을 확인한 뒤 승인된 작업만 Azure Queue Storage에 넣는다. Azure Container Apps Jobs는 Queue에 들어온 작업을 가져와 검사를 실행하고, 결과를 Azure Blob Storage에 저장한다.

데모에서는 같은 작업을 필요할 때 직접 실행하거나, 정해진 일정과 Queue 이벤트에 맞춰 실행하는 과정도 보여 줄 예정이다.

Foundry Routines와 Agent Service에서 Python 검증, Azure Queue Storage, Azure Container Apps Jobs, Blob Storage로 이어지는 흐름

슬라이드 한 장으로 정리하면 흐름이 단순해 보인다. 하지만 이 과정을 라이브 데모에서 처음부터 끝까지 보여 주는 것은 또 다른 문제다.

처음에는 녹화 세션으로 진행할 수도 있었지만, 이번에는 주최 측의 제안으로 전체 세션을 라이브로 진행하게 되었다. 첫 라이브 행사에 함께할 수 있어 기쁘면서도, 한국 시간 새벽 4시 발표라 벌써 조금 막막하다.

다음 주에는 LG유플러스 Power Automate 교육 일정도 있다. 강의와 발표 자료, 데모를 한꺼번에 준비하다 보니 요즘은 여러 가지를 동시에 붙잡고 지내고 있다.

아직 아키텍처와 데모를 계속 다듬고 있다. 에이전트의 판단과 안전한 실행 사이에 어떤 경계를 두어야 하는지 완전한 답을 찾은 것은 아니다. 이번 발표에서는 그 경계를 눈에 보이게 만들고 직접 확인할 수 있는 한 가지 방법을 보여 주고 싶다.

지금은 우선 데모가 그림의 마지막 상자까지 별문제 없이 도착하도록 만드는 중이다.

댓글