AI 에이전트의 속사정: 차세대 에이전트형 AI 핵심 가이드

에이전트형 AI 개요

오늘날 가장 뜨거운 주제 중 하나인 에이전트형 AI는 챗 인터페이스라는 안전지대를 넘어, 세계에 직접 작용하도록 생성형 AI를 확장한다. 표준 중 하나인 MCP(Model Context Protocol)가 탄생한 지 1년 남짓일 정도로 빠르게 진화하고 있으며, 개념 정의도 난립한다. 이 글은 혼선을 걷어내고 에이전트가 어떻게 구성되고 맞물려 작동하는지 큰 그림을 제시한다.

영국 개발자 스콧 윌리스턴의 간결한 정의가 유용하다. “LLM 에이전트는 목표 달성을 위해 도구를 루프(반복)로 실행한다.” 사용자는 “특정 극장 인근 레스토랑 예약” 같은 목표를 제시하고, LLM은 지도·식당 DB 등 도구를 차례로 호출해 응답을 관찰하며 다음 행동을 결정한다. 이렇게 루프를 돌며 목표에 수렴한다.

에이전트형 AI 시스템의 핵심 구성요소

실전 구현에는 공통된 퍼즐 조각이 있다: 에이전트를 쉽게 만드는 프레임워크, 실행 환경(대개 클라우드), 텍스트 기반 LLM과 도구 호출을 이어주는 메커니즘, 단기·장기 메모리, 권한 부여, 그리고 실행 추적(트레이스)이다.

에이전트 빌드: ReAct와 도구 정의

사고-행동-관찰 루프(LLM 에이전트)

LLM에게 접근 전략을 설명하게 하면 성능이 오르는 ‘사고의 사슬’ 기법이 널리 쓰인다. 에이전트형 시스템에서는 이를 확장한 ReAct(reasoning+action) 패턴을 활용한다. 에이전트는 “근처 식당을 지도에서 찾자”라는 생각을 기록하고(API 호출), 결과를 관찰한 뒤 다음 행동을 결정한다. 이 루프를 통해 점진적으로 목표를 달성한다.

도구 명세와 코드 생성

프레임워크에서는 자연어로 목표를 정의하고, 에이전트가 쓸 수 있는 도구(데이터베이스, 마이크로서비스 등)를 등록한다. 각 도구는 맥락·목적 설명과 API 시그니처를 포함한다. 필요하면 에이전트가 즉석에서 파이썬 코드를 생성해 보조 도구를 만들도록 지시할 수도 있다. 예를 들어 CSV 텍스트로 표를 받아 정렬해야 할 때, 결과를 LLM에 반복 평가시키는 비효율 대신, 정렬 코드를 직접 생성·실행하게 하는 편이 정확하고 경제적이다. 개발자는 어떤 데이터 유형에 어떤 도구/알고리즘을 쓰고, 함수 인자로 무엇을 넘길지까지 규정할 수 있다.

런타임 격리와 배포

Firecracker 마이크로VM과 세션 격리

공유 서버에서의 격리는 전통적으로 컨테이너(효율적이나 보안성이 낮음)와 VM(보안성 높으나 무겁다) 사이의 선택지였다. AWS Lambda는 2018년 Firecracker를 도입해 낮은 오버헤드의 마이크로VM을 제공했다. 에이전트는 LLM과 상태 메모리를 함께 띄워야 하므로, 함수 단위 격리보다 세션 단위 격리가 적합하다. 각 세션마다 전용 마이크로VM을 할당하고, 종료 시 LLM 상태를 장기 메모리에 저장한 뒤 마이크로VM을 파기하면 보안성과 효율을 함께 달성할 수 있다.

도구 호출과 프로토콜

MCP 기반 LLM-도구 통신

MCP는 LLM과 MCP 서버 간 1:1 연결을 맺고, 다양한 데이터 유형을 표준 형식으로 주고받으며 도구 호출을 실행한다. 현재 널리 쓰이는 방식으로, 여러 에이전트 개발 프레임워크에서 지원한다.

API가 없는 작업: UI 자동화

필요한 도구에 공개 API가 없으면 웹 UI를 마우스·키보드 조작으로 다루는 컴퓨터 사용(브라우저 자동화) 서비스를 연결한다. 이때 서비스와 LLM 사이의 번역 계층이 클릭·폼 제출 같은 상호작용을 안정적으로 중계한다.

권한 부여와 보안

OAuth 위임과 서버 세션 접근

에이전트에는 이중의 권한 관리가 필요하다. 사용자는 에이전트 실행 권한이, 에이전트는 사용자를 대신해 외부 자원에 접근할 권한이 있어야 한다. OAuth 같은 접근 위임을 쓰면, 사용자는 OAuth에만 자격 증명을 입력하고 에이전트형 시스템은 토큰으로 보호 자원에 로그인한다(비밀번호 직접 노출 없음). 다른 방식으로는 사용자가 보안 세션에 로그인하고, 서버 측 자격 증명으로 보호 자원에 접근하게 할 수도 있다. 권한 정책과 알고리즘은 시나리오에 맞게 선택한다.

메모리와 트레이스

단기 메모리: 임베딩 기반 선별 입력

LLM의 문맥(Context)은 일종의 메모리지만 만능은 아니다. 예컨대 극장 인근 식당이 수십 곳이면, 전부를 컨텍스트에 밀어 넣으면 다음 단어 확률이 교란될 수 있다. 대신 전체 목록은 단기 메모리에 저장하고, 임베딩을 이용해 가격·음식 취향·거리 조건에 맞는 소수의 후보만 컨텍스트로 불러와 평가한다. 실패하면 도구를 다시 호출하기보다 단기 메모리에서 다른 후보를 꺼내 재시도한다.

장기 메모리: 요약·임베딩·청킹

세션이 끝나면 마이크로VM(컨텍스트와 단기 메모리 포함)은 파기된다. 그러나 사용자 선호나 진행 내역은 다음 세션에서도 유용하다. 따라서 세션 종료 시 내용을 추출·증류해 장기 메모리에 저장한다. 이 과정에는 요약과 임베딩(벡터 검색 대비), 문서를 주제별로 분할하는 청킹이 포함될 수 있다. 후속 세션에서 관련 주제 임베딩으로 빠르게 재검색한다.

실행 추적과 평가

시스템은 LLM 입·출력에 대응하는 API 호출과 응답을 기록한다. 이는 에이전트 성능을 사람이 리뷰·평가하고 회귀를 탐지하는 기반이 된다.

실제 적용 예시

레스토랑 예약 에이전트 설계

목표: “극장 A 인근에서 2인 저녁 7시, 예산 $$.” 에이전트는 지도/식당 DB 도구를 호출해 후보를 수집하고, 단기 메모리에 저장한 뒤 임베딩으로 가격·거리·음식 취향을 반영해 상위 후보만 LLM 컨텍스트에 투입한다. 예약 API가 있으면 직접 호출하고, 없으면 UI 자동화로 웹 예약을 완료한다. 권한은 OAuth로 사용자 계정에 위임한다. 전 과정은 트레이스로 기록되어 실패 원인을 사후 분석할 수 있다.

여행 일정 관리 에이전트

항공권 예매 세션에서 확보한 여정·날짜·선호 좌석 정보를 장기 메모리에 저장해, 다음날 호텔·렌터카 예약 세션에서 자동 회수한다. 장바구니 후보는 단기 메모리에 보관하고, 변경 요청 시 과거 결정을 트레이스에서 찾아 근거를 제시한다. 배포는 세션 단위 Firecracker 마이크로VM으로 격리해 보안과 성능을 균형 있게 달성한다.

결론

에이전트형 AI는 ReAct 루프, 안전한 런타임 격리, 표준화된 도구 호출, 권한 위임, 계층적 메모리, 실행 추적이 맞물려 돌아갈 때 현실 가치를 만든다. 개별 구성요소의 엔지니어링은 깊지만, 큰 흐름은 단순하다. 올바른 프레임워크와 클라우드 설계를 택하면 에이전트형 AI를 안전하고 확장 가능하게 운영할 수 있다.