1부 2장. 에이전트의 최소 단위: 모델, 상태, 도구, 실행 루프

지난 장에서 우리는 챗봇과 에이전트를 구분했다. 챗봇이 주로 대화에 머무는 시스템이라면, 에이전트는 목표를 향해 다음 행동을 고르고 실제 일을 진행하는 시스템이었다. 그렇다면 이제 질문이 바뀐다. 도대체 무엇이 있어야 그런 행동이 가능해질까.

많은 사람이 여기서 거대한 프레임워크 이름부터 떠올린다. 화면에 복잡한 노드가 이어지고, 메모리 계층이 여러 겹으로 쌓이고, 관제 패널에는 화려한 그래프가 돌아가는 그림 말이다. 하지만 실제로는 그보다 훨씬 작게 시작할 수 있다. 아니, 오히려 작게 시작해야 제대로 이해할 수 있다.

에이전트의 가장 작은 뼈대는 네 가지로 설명할 수 있다. 모델, 상태, 도구, 실행 루프다. 이 네 가지가 모이면 에이전트는 단순한 문장 생성기를 넘어 상황을 보고, 판단하고, 행동하고, 다시 수정하는 시스템이 된다. 이 장의 목표는 바로 그 뼈대를 머릿속에 그릴 수 있게 만드는 것이다.

이미지 출처: Google DeepMind on Pexels

에이전트는 생각보다 적은 부품으로 시작한다

에이전트를 처음 접하면 모든 것이 복잡해 보인다. 하지만 한 걸음 물러나 보면 구조는 의외로 단순하다.

모델은 판단과 생성의 중심이다. 상태는 지금까지의 맥락과 작업 진행 상황을 붙잡아 둔다. 도구는 에이전트가 바깥세상과 연결되는 통로다. 실행 루프는 이 셋을 계속 엮어 다음 행동을 만들어 내는 흐름이다.

이 네 요소 가운데 하나라도 빠지면 에이전트는 금세 힘을 잃는다. 모델이 없으면 판단이 없다. 상태가 없으면 방금 한 말도 잊는다. 도구가 없으면 세상에 영향을 줄 수 없다. 실행 루프가 없으면 한 번 말하고 끝나는 챗봇에 머문다.

중요한 것은 이 네 가지가 각각 따로 빛나는 것이 아니라는 점이다. 진짜 에이전트성은 부품의 성능보다 부품 사이의 연결 방식에서 나온다. 같은 모델을 써도 상태를 잘 관리하면 훨씬 안정적으로 행동하고, 좋은 도구가 있어도 실행 루프가 엉성하면 엉뚱한 방향으로 반복한다.

에이전트를 설계한다는 것은 결국 이 네 가지를 적당한 크기로 나누고, 서로 어떻게 신호를 주고받을지 정하는 일이다.

모델: 에이전트의 두뇌이지만, 혼자서는 아무 일도 못 한다

모델은 에이전트가 생각하는 부분이다. 사용자의 요청을 해석하고, 현재 상황을 바탕으로 무엇을 해야 할지 판단하고, 도구를 쓸지 말지 결정하고, 최종 답을 만든다. 흔히 LLM이라고 부르는 언어 모델이 여기 들어간다.

하지만 모델을 너무 신비하게 보면 곤란하다. 모델은 가능성을 제시하는 데는 강하지만, 그 자체로는 현실 세계를 바꾸지 못한다. 이메일을 보내라고 말할 수는 있어도 실제 발송 버튼을 누르지는 못한다. 파일을 분석하겠다고 말할 수는 있어도, 파일 시스템에 접근할 권한이 없으면 아무것도 읽지 못한다.

또 모델은 기억력이 좋은 척할 수는 있어도, 구조화된 상태를 스스로 안정적으로 관리하지는 못한다. 긴 대화 안에서 맥락을 어느 정도 이어 갈 수는 있지만, 작업 ID, 승인 여부, 진행 단계, 실패 횟수 같은 운영 정보는 별도 구조로 잡아 주는 편이 훨씬 낫다.

그래서 모델은 에이전트의 중심이지만, 에이전트 전체는 아니다. 모델은 좋은 추론과 언어 생성 능력을 제공한다. 그러나 그 판단이 현실의 행동으로 이어지려면 상태와 도구와 루프가 필요하다. 두뇌는 중요하지만, 두뇌만 있다고 사람이 움직이지 않는 것과 비슷하다.

모델을 설계할 때는 이런 질문을 먼저 던지는 것이 좋다. 이 모델은 무엇을 판단해야 하는가. 어떤 형식으로 출력을 내야 하는가. 자유롭게 장문을 쓰게 할 것인가, 아니면 도구 호출 여부와 간단한 근거만 내게 할 것인가. 좋은 에이전트 설계는 모델에게 모든 책임을 떠넘기지 않는다. 모델이 잘하는 일만 맡기고, 나머지는 구조로 보완한다.

상태: 에이전트가 길을 잃지 않게 붙들어 주는 손잡이

에이전트가 단순 챗봇과 갈라지는 지점 중 하나는 상태다. 상태는 지금까지 무슨 일이 있었는지, 현재 어디까지 왔는지, 다음에 무엇을 해야 하는지를 붙잡아 두는 정보다.

사람으로 치면 작업 메모장에 가깝다. 어떤 요청을 받았는지, 어떤 자료를 이미 읽었는지, 무엇을 아직 확인하지 못했는지, 방금 도구를 호출해 어떤 결과를 얻었는지가 적혀 있어야 한다. 이 메모장이 없으면 에이전트는 매번 같은 자리에 서 있게 된다.

상태라고 하면 흔히 대화 이력만 떠올리기 쉽다. 물론 대화 이력도 상태의 일부다. 그러나 실무에서 더 중요한 것은 작업 상태다. 예를 들어 고객 지원 에이전트라면 고객 ID, 현재 티켓 번호, 이미 확인한 주문 내역, 환불 승인 여부, 다음 대기 액션이 상태에 들어간다. 문서 작성 에이전트라면 초안 버전, 검토 의견, 남은 누락 항목, 제출 마감 시간이 상태가 된다.

상태는 두 가지 역할을 동시에 한다. 하나는 기억이다. 다른 하나는 제약이다. 기억으로서의 상태는 에이전트가 앞에서 한 일을 잊지 않게 한다. 제약으로서의 상태는 에이전트가 아무 방향으로나 뛰지 못하게 막는다. 이미 결제가 끝난 주문에 다시 결제를 시도하지 않게 하고, 승인이 없으면 발송하지 못하게 하고, 세 번 실패한 도구 호출은 사람에게 넘기게 만드는 기준이 된다.

여기서 중요한 감각이 하나 있다. 상태는 많이 저장한다고 좋은 것이 아니다. 너무 많은 상태는 오히려 혼란을 만든다. 핵심은 현재 판단에 꼭 필요한 정보만 선별해 구조화하는 것이다. 에이전트가 잘못 행동하는 이유 중 상당수는 모델이 멍청해서가 아니라, 상태가 흐릿해서다.

도구: 에이전트가 말에서 행동으로 건너가게 하는 손과 발

도구는 에이전트가 외부 세계와 연결되는 인터페이스다. 검색 API, 데이터베이스 조회, 파일 읽기, 브라우저 조작, 코드 실행, 메일 발송, 일정 등록 같은 것들이 모두 도구가 될 수 있다.

도구가 중요한 이유는 명확하다. 모델은 텍스트를 다루는 데 강하지만, 현실의 정보는 모델 바깥에 있다. 최신 재고 수량도 바깥에 있고, 고객 계약서도 바깥에 있고, 오늘 환율도 바깥에 있고, 실제 버튼을 누르는 행위도 바깥에 있다. 도구는 이 바깥과 안쪽을 연결한다.

여기서 한 가지 오해를 짚고 넘어가자. 도구가 많다고 에이전트가 강해지는 것은 아니다. 오히려 도구가 많을수록 에이전트는 더 쉽게 길을 잃는다. 마치 서랍이 너무 많은 작업대 앞에 서면 무엇부터 집어야 할지 헷갈리는 것과 비슷하다.

좋은 도구 설계는 선택지를 무작정 늘리는 대신, 목적에 맞게 좁히는 데서 시작한다. 회계 에이전트라면 회계 시스템 조회와 승인 요청 도구가 중요하지, 브라우저 전체를 자유롭게 조작할 필요는 없을 수 있다. 반대로 시장 조사 에이전트라면 검색과 문서 읽기 도구가 핵심이고, 내부 결제 API는 필요 없을 수 있다.

또 도구는 단순히 "무엇을 할 수 있는가"만이 아니라 "어디까지 해도 되는가"를 함께 담아야 한다. 읽기 전용인지, 쓰기까지 가능한지, 사람 승인이 필요한지, 실패 시 자동 재시도를 할지 같은 권한과 정책이 붙어야 한다. 에이전트가 똑똑하게 보이려면 도구를 많이 주는 것보다, 올바른 경계 안에서 도구를 쓰게 만드는 것이 더 중요하다.

실행 루프: 한 번 답하고 끝나지 않게 만드는 구조

모델과 상태와 도구가 있어도, 그것들을 한 번만 쓰고 끝내면 에이전트다운 느낌은 약하다. 실행 루프가 필요한 이유가 여기 있다.

실행 루프는 아주 단순하게 말하면 이런 흐름이다. 현재 상태를 보고, 다음 행동을 정하고, 필요하면 도구를 실행하고, 결과를 관찰해 상태를 업데이트하고, 목표가 끝났는지 판단한 뒤, 끝나지 않았다면 다시 반복한다.

이 반복이 바로 에이전트를 에이전트답게 만든다. 사용자 요청 하나를 받았다고 해서 곧바로 최종 답을 쓰는 대신, 중간 단계들을 오가며 목적에 가까워진다. 때로는 검색부터 하고, 때로는 파일을 읽고, 때로는 사용자에게 질문을 되묻고, 때로는 충분하다고 판단해 종료한다.

실행 루프는 겉으로 보기엔 사소하지만, 실제로는 시스템의 성격을 좌우한다. 루프가 너무 짧고 단순하면 에이전트는 챗봇처럼 보인다. 루프가 너무 길고 통제가 없으면 끝없이 맴돌거나 불필요한 도구를 남용한다. 그래서 좋은 루프는 반복을 허용하되, 종료 조건과 실패 조건도 명확해야 한다.

예를 들어 다음과 같은 기준이 흔히 들어간다.

• 목표가 충족되면 종료한다.

• 필요한 정보가 없으면 사용자에게 질문하고 대기한다.

• 같은 도구 호출이 연속으로 실패하면 중단하거나 사람에게 넘긴다.

• 최대 반복 횟수를 넘기면 더 이상 자율 실행하지 않는다.

이런 조건이 있어야 루프는 엔진이 되지, 미로가 되지 않는다.

네 요소는 어떻게 서로 물리는가

이제 중요한 장면을 보자. 모델, 상태, 도구, 실행 루프는 실제로 어떻게 맞물릴까.

예를 들어 한 에이전트가 이런 요청을 받았다고 해 보자.

"이번 달 매출이 갑자기 떨어진 원인을 찾아 요약해 줘."

이 요청을 받은 순간, 상태에는 최소한 사용자의 목표와 현재 작업 ID가 기록된다. 그리고 아직 모르는 것이 많다는 사실도 함께 적힌다. 예를 들어 어느 지역의 매출인지, 어떤 기간과 비교해야 하는지, 필요한 데이터 소스가 무엇인지가 비어 있을 수 있다.

실행 루프는 먼저 모델에게 현재 상태를 보여 주며 묻는다. 지금 가장 합리적인 다음 행동은 무엇인가. 모델은 아마 이렇게 판단할 것이다. 먼저 매출 데이터를 조회해야 하고, 전월 또는 전년 동기와 비교해야 하며, 제품군이나 채널별 분해가 필요할 수 있다.

그러면 에이전트는 매출 조회 도구를 호출한다. 도구 실행 결과가 들어오면 그 결과가 다시 상태에 저장된다. 이제 상태에는 단순한 요청만 있는 것이 아니라, 실제 수치와 패턴이 들어간다. 예를 들어 온라인 채널에서만 급락이 발생했다는 사실이 새로 추가될 수 있다.

다음 루프에서 모델은 이 상태를 보고 다시 판단한다. 원인을 좁히려면 광고 집행 데이터나 재고 부족 여부를 확인해야 한다고 생각할 수 있다. 그러면 또 다른 도구를 호출한다. 그 결과 온라인 광고 예산이 중간에 줄었다는 사실이 나오거나, 특정 상품의 품절이 겹쳤다는 정보가 추가될 수 있다.

이렇게 몇 번의 반복이 지나면 상태는 점점 풍성해지고, 모델의 판단은 점점 구체화된다. 마지막에는 "온라인 채널 매출 하락의 주된 원인은 광고 집행 감소와 주요 상품 품절의 동시 발생"이라는 식의 결론을 만들 수 있다. 그제야 에이전트는 최종 응답을 작성한다.

이 장면에서 핵심은 한 가지다. 행동은 모델 하나에서 나오지 않는다. 상태가 모델의 판단을 바꾸고, 도구가 상태를 바꾸고, 실행 루프가 이 교환을 반복시키며, 그 결과로 행동이 생긴다. 에이전트란 결국 "판단-행동-관찰-갱신"의 순환 구조다.

최소 아키텍처를 그림 없이 머릿속에 그려 보자

복잡한 프레임워크를 잠시 잊고, 에이전트의 최소 구조를 아주 담백하게 그려 보자.

사용자가 요청을 보낸다. 시스템은 그 요청을 상태에 기록한다. 실행 루프가 시작된다. 모델은 현재 상태를 읽고, 다음 행동을 결정한다. 그 행동이 도구 호출이면 도구를 실행한다. 도구의 결과는 다시 상태에 저장된다. 모델은 갱신된 상태를 바탕으로 다음 행동을 선택한다. 충분한 결과가 모이면 최종 응답을 생성하고 루프를 종료한다.

이 한 줄짜리 설계만 제대로 이해해도, 에이전트 시스템의 절반은 이미 이해한 셈이다.

그 다음부터 붙는 것들은 대부분 확장이다. 상태를 더 오래 보존하면 메모리가 된다. 도구를 더 많이 연결하면 행동 범위가 넓어진다. 실행 루프에 검토 단계를 넣으면 자기 평가가 가능해진다. 여러 에이전트를 두면 멀티에이전트가 된다. 하지만 뿌리는 여전히 같다.

그래서 처음 설계할 때는 거대한 구조부터 고민하기보다, 이 최소 흐름이 안정적으로 돌아가는지 확인하는 편이 낫다. 작은 루프 하나가 제대로 작동하지 않는데, 그 위에 화려한 패턴을 쌓아 봐야 더 크게 흔들릴 뿐이다.

왜 프레임워크보다 뼈대 이해가 먼저인가

실무에서는 종종 이런 일이 벌어진다. 누군가 멋진 에이전트 프레임워크를 도입하고, 노드와 체인과 메모리 모듈을 잔뜩 연결한다. 그런데 막상 문제가 생기면 어디가 원인인지 모른다. 모델이 잘못 판단했는지, 상태가 꼬였는지, 도구가 이상한 값을 줬는지, 실행 루프가 같은 행동을 반복하는지 구분이 안 된다.

이럴 때 필요한 것이 바로 최소 단위에 대한 이해다. 에이전트를 네 요소로 나눠 생각하면 고장이 훨씬 잘 보인다.

응답은 그럴듯한데 행동이 틀리면 도구 권한이나 호출 조건을 의심해 볼 수 있다. 같은 질문을 반복하면 상태 갱신이 잘 안 되는 것일 수 있다. 계속 쓸데없는 검색만 한다면 실행 루프의 종료 조건이 약한 것일 수 있다. 도구 결과를 읽고도 엉뚱한 판단을 내린다면 모델에게 준 입력 형식이 나쁜 것일 수 있다.

즉, 뼈대를 이해하면 디버깅도 가능해진다. 이것이 프레임워크보다 설계 원리가 먼저인 이유다. 프레임워크는 집을 빨리 짓게 해 주지만, 기초가 어디인지 알려 주지는 않는다.

초보자가 자주 빠지는 네 가지 착각

에이전트를 처음 만들 때는 대개 비슷한 함정에 빠진다.

첫째, 모델이 똑똑하면 다 해결될 것이라고 믿는 착각이다. 좋은 모델은 분명 중요하다. 하지만 상태가 없고 도구가 엉성하고 루프가 통제되지 않으면, 좋은 모델도 허공에 대고 현명한 말만 하게 된다.

둘째, 대화 이력만 길게 넣으면 상태 관리가 끝난다고 보는 착각이다. 실제 작업에서는 대화보다 구조화된 작업 상태가 더 중요할 때가 많다. 무엇을 했고, 무엇이 남았고, 어떤 조건에서 멈춰야 하는지가 분명해야 한다.

셋째, 도구를 많이 붙일수록 에이전트가 유능해진다고 생각하는 착각이다. 현실에서는 반대인 경우가 많다. 필요한 도구만 제한적으로 주는 편이 더 안정적이고 예측 가능하다.

넷째, 루프를 길게 돌리면 더 잘할 것이라는 착각이다. 반복은 품질을 높일 수도 있지만, 동시에 비용과 지연과 실패 확률도 키운다. 루프는 오래 도는 것이 아니라, 적절한 순간에 멈추는 것이 중요하다.

이 네 가지 착각을 일찍 버리면 설계가 훨씬 단단해진다. 에이전트는 무한한 자유에서 강해지는 시스템이 아니라, 잘 설계된 제한 속에서 강해지는 시스템이다.

좋은 최소 설계는 어떤 모양인가

좋은 최소 설계는 놀랄 만큼 소박하다. 모델은 현재 목표와 상태를 읽고 다음 행동을 선택한다. 상태는 작업 진행 상황을 짧고 분명하게 담는다. 도구는 꼭 필요한 몇 개만 제공한다. 실행 루프는 목표 충족, 추가 정보 필요, 실패, 최대 반복 횟수 같은 종료 조건을 가진다.

이 정도만 갖춰도 꽤 많은 문제를 풀 수 있다. 예를 들어 사내 문서 검색 에이전트, 간단한 리서치 보조 에이전트, 보고서 초안 생성 에이전트, 고객 문의 분류 및 응답 준비 에이전트 정도는 이 뼈대 위에서 충분히 만들 수 있다.

반대로 이 최소 설계가 불안정하면, 더 큰 구조는 거의 반드시 문제를 일으킨다. 여러 작업자를 두는 구조나 자기 평가 루프나 장기 메모리는 모두 그다음 문제다. 먼저 단일 루프 안에서 모델, 상태, 도구가 건강하게 상호작용하는지 확인해야 한다.

설계 회의에서 아주 실용적인 질문은 이것이다. "이 에이전트는 현재 상태를 한 문단으로 요약할 수 있는가?" 만약 그게 불가능하다면 상태가 너무 흐리거나 구조가 과도하게 복잡할 가능성이 높다. 또 이런 질문도 좋다. "이 에이전트는 도구 없이도 어떤 판단까지는 할 수 있는가?" 이 질문은 모델의 역할과 도구의 역할을 깔끔하게 나누는 데 도움이 된다.

스스로 뼈대를 그릴 수 있어야 한다

이 장에서 정말 가져가야 할 것은 정의가 아니라 감각이다. 에이전트는 거대한 상자가 아니다. 모델이 판단하고, 상태가 맥락을 붙들고, 도구가 외부와 연결되며, 실행 루프가 이 모든 것을 반복시킨다. 이 네 가지를 머릿속에서 분해할 수 있으면, 어떤 에이전트 시스템을 보더라도 대충 어디에 해당하는지 읽어 낼 수 있다.

더 나아가 직접 설계할 때도 도움이 된다. 새로운 요구사항을 만나면 먼저 이렇게 묻게 된다. 이 문제에서 모델이 해야 할 판단은 무엇인가. 상태로 저장해야 할 핵심 정보는 무엇인가. 어떤 도구가 진짜 필요한가. 루프는 언제 시작하고, 언제 멈추는가.

이 질문들에 답할 수 있으면, 아직 코드를 한 줄도 쓰지 않았더라도 이미 절반은 설계한 것이다. 에이전트 개발의 출발점은 멋진 데모가 아니라, 이런 뼈대 그리기다.

이제 에이전트를 평가할 준비가 된다

앞 장에서 우리는 에이전트가 무엇인지 구분했다. 이번 장에서는 그 에이전트가 어떤 최소 부품으로 이루어지는지 봤다. 이제부터는 조금 더 까다로운 질문을 던질 수 있다. 같은 네 가지 부품을 쓴다 해도, 왜 어떤 에이전트는 믿을 만하고 어떤 에이전트는 답답할까. 왜 어떤 시스템은 과하게 도구를 남용하고, 어떤 시스템은 필요한 순간에도 움직이지 못할까.

그 차이는 결국 설계의 품질에서 나온다. 같은 부품으로도 좋은 에이전트가 될 수 있고, 나쁜 에이전트가 될 수 있다.

다음 장에서는 바로 그 문제를 다룬다. 좋은 에이전트와 나쁜 에이전트는 무엇이 다른가. 똑같이 움직이는 것처럼 보여도, 어떤 설계는 사용자를 돕고 어떤 설계는 사용자를 지치게 만든다.