파이썬 AI 에이전트 만들기 전체 과정: 메모리·RAG·멀티에이전트 정리

핵심 메시지

• 데모용이 아니라 운영 환경에서 버티는 에이전트를 만드는 데 초점을 둔, 코드를 한 줄씩 직접 작성하는 실습형 강의다.
• 프로덕션 에이전트에는 내구성·재시도·사람 개입·관찰 가능성·장시간 실행·확장성·테스트의 7가지 요건이 필요하다고 정리한다.
• 상태와 오케스트레이션은 서버가 맡고 에이전트 코드는 워커로 실행하는 구조라, 충돌해도 중단 지점부터 복구할 수 있다.
• 첫 에이전트는 도구 호출과 대화 메모리를 붙인 챗봇으로, 메모리에 사용자·어시스턴트 메시지를 저장해야 맥락을 기억한다.
• 두 번째는 Pydantic 구조화 출력과 가드레일을 갖춘 RAG형 지원 에이전트, 세 번째는 여러 에이전트를 동시에 돌리는 오케스트레이터로 확장한다.

쉽게 이해하기

이 강의는 파이썬으로 '실제 운영 환경에서 쓸 수 있는' AI 에이전트를 만드는 전체 과정을 다룬다. 진행자는 완전 초보용은 아니지만 파이썬에 익숙하면 따라올 수 있다고 전제하고, 모든 코드를 직접 작성하며 세 가지 에이전트를 단계적으로 구축한다. 사용하는 프레임워크는 무료 오픈소스인 Agent Span으로, OpenAI나 Anthropic 같은 모델에 접근할 수만 있으면 된다.

먼저 운영 환경에서 에이전트가 겪는 문제를 짚는다. 네트워크나 데이터베이스 장애로 프로세스가 죽으면 그동안의 작업이 통째로 날아가고 비용 손실로 이어진다. 또 작업 승인 같은 사람의 개입이 끼어들 수 있고, 무엇보다 에이전트가 내부에서 무엇을 하는지 보이지 않는 '관찰 가능성' 부재가 큰 문제다. 진행자는 이를 해결하기 위한 7가지 요건으로 내구성, 재시도, 사람 개입(human-in-the-loop), 관찰 가능성, 장시간 실행, 확장성, 테스트를 제시한다.

아키텍처는 '서버'와 '워커'로 나뉜다. Agent Span 서버는 여러 에이전트의 상태와 실행 기록을 추적하고 재시도·사람 개입·큐잉을 처리하며, 대시보드에서 각 단계와 입출력, 토큰, 중지 이유를 실시간으로 확인할 수 있다. 워커는 우리가 작성하는 에이전트 코드로, 로컬이든 서버든 어디서 돌리든 상태가 서버에 저장되므로 시스템이 다운돼도 다시 연결해 중단 지점부터 이어갈 수 있다. LLM API 키도 워커가 아니라 서버에 저장해 더 안전하게 관리한다.

첫 번째 에이전트는 간단한 대화형 챗봇이다. 현재 시간을 돌려주는 함수에 도구 데코레이터를 붙여 에이전트가 호출할 수 있게 하고, 대화 메모리를 추가한다. 다만 메모리를 선언만 해서는 안 되고, 매 턴마다 사용자 메시지와 어시스턴트 메시지를 메모리에 저장해야 비로소 이름 같은 이전 맥락을 기억한다는 점을 실습으로 보여 준다. 메모리에는 최대 메시지 수(예: 50개)를 둬 오래된 메시지부터 정리한다.

두 번째 에이전트는 RAG 형태의 지원 담당 에이전트로, 지식 베이스를 검색하는 도구와 가드레일을 더한다. 핵심은 Pydantic 구조화 출력으로, 무작위 문자열 대신 단계(stage)·성공 여부·메시지 같은 필드를 가진 예측 가능한 객체를 받게 해 더 결정론적인 애플리케이션을 만든다. 마지막 세 번째 에이전트는 여러 에이전트를 동시에 실행해 더 오래 걸리는 작업을 분담하는 멀티 에이전트 오케스트레이터로 확장된다.

주요 인사이트

• 에이전트를 '프로덕션 가능'하게 만드는 차이는 모델 성능이 아니라 내구성·복구·관찰 가능성 같은 운영 인프라에 있다.
• 상태를 서버에 두고 코드를 워커로 분리하면, 충돌·재시작에도 작업을 잃지 않고 배포가 단순해진다.
• 대화 메모리는 선언만으로 동작하지 않으며, 매 턴 입력·출력을 명시적으로 저장하는 코드가 있어야 맥락이 유지된다.
• Pydantic 구조화 출력은 LLM 응답을 예측 가능한 형식으로 고정해 후속 로직을 안정적으로 만든다.
• API 키를 워커 코드가 아닌 서버에 보관하는 설계는 보안과 운영 편의를 동시에 높인다.

자주 묻는 질문

관련 AI 소식