AI 에이전트 작동 방식: 모델, 도구, 메모리 및 제어 루프

AI 에이전트는 모델에 지시, 도구, 메모리 및 반복적으로 다음 행동을 결정하는 제어 루프를 결합하여 작동합니다. 모델은 판단 및 언어 능력을 제공하고, 주변 소프트웨어는 이러한 능력을 상태를 유지하는 프로세스로 전환하여 행동하고, 결과를 검사하며, 오류에서 복구하고, 종료할 수 있게 합니다.

이 아키텍처를 이해하는 것이 에이전트를 단일 지능형 객체로 보는 것보다 더 유용합니다. 대부분의 성공과 실패는 구성 요소 간 상호작용에서 비롯됩니다: 뛰어난 모델도 모호한 도구, 오래된 메모리, 과도한 권한, 혹은 완료 정의가 신뢰할 수 없는 제어 루프에 의해 약화될 수 있습니다.

AI 에이전트의 다섯 핵심 구성 요소

1. 모델

모델은 목표를 해석하고, 사용 가능한 컨텍스트를 논리적으로 검토하며, 행동을 선택합니다. 현재 많은 에이전트에서 이는 지시를 따르고 구조화된 도구 호출과 자연어를 생성할 수 있는 대형 언어 모델입니다.

가장 성능이 뛰어난 모델이 모든 단계에 자동으로 최적은 아닙니다. 시스템은 복잡한 계획을 더 강력한 모델에 전달하고, 분류에는 더 빠른 모델을 사용하며, 검증에는 결정론적 코드를 활용할 수 있습니다. 이러한 조합은 속도, 비용 및 신뢰성을 향상시킵니다.

2. 지시

지시는 에이전트의 역할, 범위, 우선순위 및 출력 요구사항을 정의합니다. 여기에는 시스템 프롬프트, 작업별 컨텍스트, 정책, 예시, 도구 설명, 종료 기준 등이 포함될 수 있습니다.

좋은 지시는 실행 가능해야 합니다. 에이전트에게 필요한 증거, 승인 요청 시점, 허용 가능한 출처, 완료를 인식하는 방법을 알려줍니다. 모호하거나 모순된 규칙은 모델이 추측하도록 만들며, 유사한 작업에서도 일관성을 잃게 합니다.

3. 도구

도구는 모델을 현재 컨텍스트 밖의 기능과 연결합니다. 도구는 웹 검색, 고객 기록 조회, 코드 실행, 데이터베이스 질의, 브라우저 제어, 일정 이벤트 생성 등을 수행할 수 있습니다.

모델은 일반적으로 직접 함수를 실행하지 않습니다. 이름이 지정된 도구를 선택하고 구조화된 인수를 제안합니다. 에이전트 런타임은 해당 요청을 검증하고, 권한을 확인하며, 작업을 실행하고 결과를 반환합니다. 이 분리는 필수적입니다: 소프트웨어가 외부에 영향을 미치기 전에 잘못되었거나 위험한 행동을 차단할 수 있게 합니다.

4. 상태와 메모리

상태는 에이전트가 현재 실행 중에 필요로 하는 정보이며: 목표, 대화, 계획, 관찰, 도구 출력 및 완료된 단계가 포함됩니다. 메모리는 이전 선호도, 반복되는 사실, 이전 작업에서 얻은 교훈 등 즉각적인 컨텍스트를 넘어 유용한 정보를 유지함으로써 이 개념을 확장합니다.

메모리가 많다고 항상 좋은 것은 아닙니다. 관련 없는 기록은 컨텍스트를 차지하고 모델을 오래된 가정으로 이끌 수 있습니다. 효과적인 메모리 시스템은 무엇을 저장할지, 어떻게 조직할지, 언제 가져올지, 그리고 충돌하거나 만료된 정보를 어떻게 처리할지 결정합니다.

5. 제어 루프

제어 루프는 프로세스를 지속시키는 오케스트레이션 레이어입니다. 현재 상태를 모델에 전달하고, 제안된 행동을 받아 승인된 도구를 실행하며, 관찰을 기록하고, 다시 모델을 호출합니다.

Anthropic은 효과적인 에이전트 구축 가이드에서 검색, 도구, 메모리와 같은 기능을 갖춘 루프에서 동작하는 확장된 언어 모델로 에이전트를 설명합니다. OpenAI도 From Model to Agent에서 모델, 도구, 환경 간의 지속적인 상호작용으로 에이전트 실행을 설명합니다.

구성 요소만큼 인터페이스도 중요합니다

아키텍처 다이어그램은 각 구성 요소가 명확히 구분된 것처럼 보이게 할 수 있지만, 실제 신뢰성은 이들 간의 계약에 달려 있습니다. 모델은 유사한 기능을 구분할 수 있는 도구 설명이 필요하고, 런타임은 타입이 지정된 인수와 명시적인 오류 상태가 필요합니다. 메모리 검색은 출처와 최신성 정보를 요구합니다. 완료 검사기는 답변이 충분히 좋다는 막연한 느낌이 아니라 테스트 가능한 기준이 필요합니다.

예를 들어 검색 도구가 빈 리스트를 반환한다면, 이는 관련 기록이 없거나, 쿼리가 잘못되었거나, 사용자의 권한이 없거나, 서비스가 시간 초과됐음을 의미할 수 있습니다. 도구가 네 가지 상황을 동일한 출력으로 합친다면 모델은 어떤 일이 일어났는지 신뢰성 있게 추론할 수 없습니다. 잘 설계된 인터페이스는 구조화된 증거를 반환합니다: 상태, 출처, 타임스탬프, 쿼리, 결과 수, 그리고 필요 시 기계가 읽을 수 있는 오류.

이 원칙은 컨텍스트에도 적용됩니다. 지시, 권위 있는 기록, 검색된 구절, 모델이 만든 메모, 신뢰되지 않는 외부 콘텐츠를 동등한 텍스트로 취급해서는 안 됩니다. 출처와 권한을 라벨링하면 런타임이 정책을 적용하고 모델이 증거를 올바르게 평가하는 데 도움이 됩니다. 이는 실용적인 컨텍스트 엔지니어링 형태이며: 모델이 보는 정보뿐 아니라 그 정보가 어떻게 조직되고 시스템이 어떤 제어를 허용하는지를 결정하는 것입니다.

단계별 예시

에이전트가 세 개의 잠재 공급자를 비교하고 권고안을 작성하도록 요청받았다고 상상해 보세요.

1. 목표 수신: 에이전트는 결정 기준, 마감일, 예산 및 요구 출력물을 읽습니다.
2. 사용 가능한 컨텍스트 검사: 공급자 이름, 내부 요구사항 및 원본 문서가 존재하는지 확인합니다.
3. 계획 수립: 각 공급자의 가격, 보안 정보, 서비스 조건 및 고객 증거를 수집하기로 결정합니다.
4. 도구 선택: 승인된 문서 저장소를 검색하거나 외부 연구 도구를 호출합니다.
5. 관찰: 런타임은 가능한 오류나 누락된 필드를 포함한 결과를 반환합니다.
6. 상태 업데이트: 에이전트는 배운 내용을 기록하고 해결되지 않은 질문을 표시합니다.
7. 적응: 쿼리를 변경하거나 다른 소스를 참조하거나, 이용할 수 없는 문서에 대해 사람에게 요청합니다.
8. 검증: 모든 권고가 근거가 있고 비교가 동일한 기준을 사용하는지 확인합니다.
9. 중지 또는 승인 요청: 초안 권고안을 생성하지만 구매 결정은 권한이 있는 사람에게 맡깁니다.

중요한 점은 이 순서가 완전히 하드코딩된 것이 아니라는 것입니다. 시스템은 발견한 상황에 따라 단계를 선택했지만, 여전히 설계된 제한 내에서 작동했습니다.

계획이 항상 별도의 단계는 아니다

일부 에이전트는 행동하기 전에 전체 계획을 작성합니다. 다른 에이전트는 한 번에 한 단계씩 결정합니다. 많은 경우 하이브리드 방식을 사용합니다: 대략적인 계획을 만든 뒤 다음 행동을 실행하고, 관찰이 들어오면 남은 계획을 수정합니다.

길고 경직된 계획은 첫 번째 예기치 않은 결과 이후에 구식이 될 수 있습니다. 순수 반응형 에이전트는 방황하거나 작업을 반복할 수 있습니다. 실용적인 설계는 방향성을 유지하기 위해 충분한 계획을 유지하면서 환경 변화 시 재계획을 허용합니다.

ReAct 프레임워크는 추론과 행동 및 관찰을 교차시키는 기본적인 예시입니다. 그 핵심 통찰은 외부 결과가 다음 추론 단계를 수정, 정제 또는 재지시할 수 있다는 점입니다.

에이전트가 언제 중지해야 하는지 아는 방법

중지는 시스템 설계 문제입니다. 모델이 성공을 너무 일찍 선언하거나 목표 달성 후에도 다듬기를 계속하거나, 도구가 반복적으로 실패할 때 루프에 머무를 수 있습니다.

신뢰할 수 있는 에이전트는 여러 중지 메커니즘을 결합합니다:

• 완료 기준: 필수 필드, 통과된 테스트, 검증된 인용 등 명시적 조건.
• 예산: 단계, 시간, 모델 토큰, 도구 호출 또는 비용에 대한 제한.
• 오류 임계값: 반복 실패 또는 낮은 신뢰도 관찰 후 에스컬레이션.
• 승인 게이트: 높은 영향력이나 되돌릴 수 없는 행동 전에 일시 중지.
• 외부 평가자: 출력이 작업을 만족하는지 판단하는 결정론적 검사 또는 별도 모델.

일반적인 에이전트 아키텍처

단일 에이전트 루프는 가장 단순한 설계입니다: 하나의 모델이 도구를 반복적으로 사용하여 작업을 마칩니다. 디버깅이 용이하고 종종 충분합니다.

라우터는 요청을 분류하고 이를 특화된 프롬프트, 도구 세트 또는 모델에 전달합니다. 라우팅은 관련 없는 선택을 줄이고 작업별로 다른 정책을 적용할 수 있습니다.

오케스트레이터-워커 아키텍처는 주 에이전트가 하위 작업을 생성하고 워커에게 할당한 뒤 결과를 종합하도록 합니다. 작업을 병렬로 수행하거나 서로 다른 전문 분야가 필요할 때 유용하지만, 토큰 사용량과 조정 실패 가능성이 증가합니다.

평가자-최적화자 루프는 생성과 비판을 분리합니다. 한 구성 요소가 답변을 생성하고, 다른 구성 요소가 정의된 기준에 따라 검증하며, 첫 번째가 이를 수정합니다. 품질을 측정 가능하고 반복을 통한 개선이 추가 비용을 정당화할 때 효과적입니다.

보통 발생하는 문제점

• 도구 설명 부실: 모델이 잘못된 기능을 선택하거나 잘못된 인수를 제공합니다.
• 제한 없는 컨텍스트: 긴 전사본이 관련 없는 세부 정보를 채우고 결정적인 정보를 가립니다.
• 무음 도구 오류: 빈 결과나 부분 결과가 유효한 관찰로 오인됩니다.
• 약한 근거: 에이전트가 기록 시스템을 확인하지 않고 가정에 따라 행동합니다.
• 과도한 자율성: 에이전트가 적절한 검토 경계 없이 중요한 행동을 취할 수 있습니다.
• 경로 평가 부재: 팀이 최종 답변만 평가하고 에이전트가 어떻게 도출했는지는 검토하지 않습니다.

신뢰할 수 있는 에이전트를 위한 설계 원칙

작업을 해결할 수 있는 가장 작은 아키텍처부터 시작하십시오. 결정론적 워크플로는 알려진 단계를 처리하고, 모델의 재량은 실제로 해석이 필요한 결정에만 남겨두세요. 각 도구에 좁은 목적, 타입이 지정된 입력, 명시적 오류 상태 및 최소 권한 접근을 부여합니다.

상태를 가시화하십시오. 진단에 필요한 모든 도구 호출, 결과, 재시도, 승인 및 모델 결정을 기록합니다. 오래된 컨텍스트를 무한히 추가하기보다 압축하고, 권위 있는 데이터를 모델이 만든 요약과 별도로 보존합니다.

런타임을 설계하여 실패가 명시적이도록 하세요. 도구는 “레코드 없음”과 “요청 실패”를 구분하고, 상태 저장소는 검증된 사실과 모델이 만든 요약을 구분해야 합니다. 그렇지 않으면 모델이 타임아웃으로 인한 부재를 무언가 존재하지 않는 증거로 오인할 수 있습니다.

마지막으로 전체 시스템을 평가하십시오. 동일한 작업을 여러 번 실행하고 성공률과 자원 사용량을 측정하며, 정책 위반이나 취약한 단축 경로가 있는지 경로를 검토합니다. Anthropic의 에이전트 평가 가이드는 에이전트에 작업, 반복 가능한 실험, 전사본 및 평가자가 필요하다고 강조합니다—몇 개의 인상적인 데모가 아니라.

AI 에이전트 작동 방식에 대해 기억해야 할 점

AI 에이전트는 단순히 똑똑한 모델이 아니라 설계된 루프입니다. 모델이 결정을 내리고, 도구가 실행하며, 메모리가 상태를 전달하고, 환경이 증거를 반환하며, 제어 루프가 다음에 일어날 일을 결정합니다.

이러한 구성 요소가 명확한 인터페이스와 경계를 가질 때, 에이전트는 기존 자동화가 예측하지 못하는 개방형 작업을 처리할 수 있습니다. 그렇지 않으면 자율성이 모호성을 증폭시킵니다. 따라서 에이전트의 품질은 기본 모델뿐만 아니라 시스템 설계, 권한 및 평가에도 크게 좌우됩니다.