AI 에이전트를 만드는 것이 기본적으로 챗봇에게 프롬프트를 입력하는 것과 같다고 생각하곤 했습니다. 질문을 잘 구성하고, 모델이 답하면, 그걸로 끝이라고 말이죠. 하지만 몇 가지 애플리케이션을 실제로 출시해 보니 현실은 냉혹했습니다. LLM은 에이전트가 아닙니다. LLM은 다음 토큰을 예측할 뿐입니다. 에이전트를 만드는 것은 바로 '루프(loop)'입니다.

차를 만드는 과정을 생각해 보세요. make_tea()라는 단일 명령을 실행하고 그냥 가버리지 않습니다. 주전자에 물을 채우고, 수압이 낮다는 것을 깨닫고, 기다렸다가, 스위치를 켜고, 스위치가 고장 난 것을 발견하면 다른 버너로 옮깁니다. 김이 나는지 확인하고, 차를 따르고, 맛을 본 뒤, 찻잎이 너무 오래 우러났다면 꿀을 추가할 수도 있습니다. 목표는 변하지 않지만, 단계는 계속 변합니다. 관찰하고, 조정하고, 다시 시도합니다. AI 에이전트도 정확히 이와 같이 작동합니다.

에이전시(Agency)를 만드는 사이클

루프는 추상적인 이론이 아닙니다. 그것은 당신을 대신해 행동하는 모든 시스템의 운영적 심장 박동입니다. 실제 구현 시에는 다음과 같은 모습입니다.

  • Think (생각): 모델이 목표에 대해 추론하고 무엇이 필요한지 결정합니다. 사용자가 "내일 포틀랜드에 우산을 가져가야 할까?"라고 물으면, 모델은 일기 예보와 위치 정보가 필요하다는 것을 식별합니다.
  • Act (행동): 모델이 도구를 호출합니다. "Portland"를 해결하기 위해 지오코딩 API를 호출한 다음, 좌표를 가지고 날씨 엔드포인트에 접속할 수 있습니다.
  • Observe (관찰): 모델이 도구의 출력을 읽습니다. API가 JSON 예보를 반환했나요, 403 에러를 반환했나요, 아니면 HTML 유지보수 페이지를 반환했나요?
  • Update (업데이트): 관찰한 내용을 바탕으로 모델은 계획을 수정합니다. 만약 지오코더가 오리건주 포틀랜드 대신 메인주 포틀랜드를 반환했다면, 모델은 모호성을 해소해야 합니다. API가 다운되었다면 백업 소스로 전환하거나 사용자에게 물어볼 수 있습니다.
  • Think Again (다시 생각): 새로운 컨텍스트와 함께 사이클이 다시 시작됩니다.

이것은 한 번 작성하고 잊어버리는 다섯 개의 개별 함수가 아닙니다. 목표에 도달하거나 강제 종료가 트리거될 때까지 실행되는 연속적인 엔진입니다. 모델은 스크립트처럼 코드를 실행하는 것이 아닙니다. 세상의 상태에 대해 추론하고, 행동을 선택하고, 그 결과를 읽고, 다음에 무엇을 할지 결정하는 것입니다. 이것이 화려한 자동 완성 기능과 업무를 완수하는 에이전트 사이의 차이점입니다.

왜 프레임워크들이 모두 비슷해 보일까

LangGraph, CrewAI 또는 AutoGen을 사용해 보았다면, 이들이 서로 비슷해 보이기 시작한다는 것을 눈치챘을 것입니다. LangGraph는 흐름을 노드와 엣지로 구성된 지속적인 그래프로 모델링합니다. CrewAI는 에이전트를 역할과 크루(crew)로 조직합니다. AutoGen은 멀티 에이전트 대화를 오케스트레이션합니다. 패키징 방식은 다르지만, 뼈대는 같습니다.

이들이 비슷해 보이는 이유는 모두 동일한 루핑 원칙을 중심으로 설계되었기 때문입니다. LangGraph는 도구 호출과 모델 추론 사이의 상태 전이로서 사이클을 명시적으로 구조화합니다. CrewAI는 루프를 역할 기반 에이전트 안에 감싸지만, 각 크루 구성원은 여전히 계획, 행동, 관찰의 사이클을 거칩니다. AutoGen은 액터들 사이의 메시지를 중개하지만, 모든 턴은 여전히 생성, 실행, 성찰, 라우팅의 변형입니다.

이 프레임워크들이 루프에 집중하는 이유는 바로 그곳에 에이전시(agency)가 존재하기 때문입니다. 기반 모델이 GPT-4, Claude 또는 미세 조정된 오픈 웨이트 모델일 수는 있습니다. 루프가 없다면, 당신은 매우 비싼 문장 완성기를 갖게 될 뿐입니다. 루프가 있다면, 여러 번의 시도를 통해 목표를 향해 지속할 수 있는 시스템을 갖게 됩니다.

진짜 작업이 시작되는 시점

로컬 데모는 마법처럼 느껴집니다. 하지만 프로덕션은 그 마법이 혼돈과 맞닥뜨리는 곳입니다. 프로토타이핑 단계를 넘어서면, AI 문제를 푸는 것이 아니라 시스템 엔지니어링 문제를 풀기 시작하게 됩니다.

도구의 실패는 불가피합니다. API는 타임아웃이 발생합니다. 잘못된 형식의 JSON을 반환합니다. HTML로 감싸진 500 에러를 던지기도 합니다. 만약 루프가 모든 도구의 출력을 맹목적으로 신뢰한다면, 에이전트는 성공했다고 환각(hallucinate)을 일으키거나 혼란의 소용돌이에 빠질 것입니다. 모든 반환 페이로드에 대해 재시도 로직, 서킷 브레이커(circuit breakers), 그리고 스키마 검증이 필요합니다.

메모리가 노후화됩니다. 에이전트는 사용자의 선호 데이터베이스가 PostgreSQL이라는 것을 기억하지만, 인프라 팀은 어젯밤에 새로운 클러스터로 마이그레이션을 완료했을 수 있습니다. 컨텍스트를 새로 고치거나 만료시키는 메커니즘이 없다면, 에이전트는 죽은 엔드포인트를 향해 자신 있게 명령을 내릴 것입니다. 메모리에는 타임스탬프, 신뢰도 점수, 그리고 스스로를 무효화할 수 있는 능력이 필요합니다.

무한 루프는 소리 없는 살인자입니다. 에이전트가 웹을 검색하고, 유용한 것을 찾지 못해 쿼리를 약간 수정하고, 다시 검색하고, 또 찾지 못해 이를 반복합니다. 최대 반복 횟수 제한이나 의미론적 중복 탐지(semantic duplicate detection)가 없다면, 사용자가 기다리는 동안 토큰과 비용을 계속 태우게 됩니다. 재시도 횟수 제한, 발산 체크(divergence checks), 그리고 인간 개입 경로(human escalation paths)와 같은 가드레일을 구축해야 합니다.

무관한 데이터는 추론을 방해합니다. 검색 증강 생성(RAG) 파이프라인은 종종 모호하게 관련된 문서 수십 단락을 컨텍스트 윈도우에 쏟아붓습니다. 에이전트는 노이즈 때문에 제대로 작동하지 못하고 잘못된 도구를 선택하거나 파라미터를 환각(hallucinate)합니다. 모델이 검색된 텍스트를 보기 전에 필터링, 랭킹, 그리고 간결한 요약 과정이 반드시 필요합니다.

에이전트에게는 지능 그 이상의 것이 필요합니다. 관리되는 메모리, 명시적 상태 추적, 엄격한 가드레일, 그리고 관찰 가능한 텔레메트리를 갖춘 시스템이 필요합니다. 모델이 뛰어날수록 이를 둘러싼 시스템도 더 뛰어나야 합니다. 취약한 루프 안에 있는 강력한 모델은 그저 더 정교하게 실패할 뿐입니다.

완벽한 마무리

에이전트의 진정한 지능은 첫 번째 답변을 완벽하게 내놓는 것에 있지 않습니다. 계획대로 되지 않을 때 의도와 결과 사이의 간극을 헤쳐 나가는 능력에 있습니다. 첫 번째 시도는 쉽습니다. 누구나 해피 패스(happy path)를 스크립트로 짤 수 있습니다. 진짜 어려운 것은 네 번째 반복(iteration)입니다. 주요 API가 다운되고, 컨텍스트 윈도우는 줄어들며, 사용자는 조급해지는데, 에이전트는 여전히 유용한 결과물을 내놓아야 하는 상황 말입니다.

그러한 끈기가 데모와 제품을 가르는 차이입니다. 이는 실시간으로 모델 가중치를 업데이트하는 것이 아니라, 계획을 업데이트함으로써 매 단계에서 배우는 능력입니다. 에이전트는 전술이 바뀌는 동안에도 목표를 흔들림 없이 유지합니다. 이것이 바로 루핑 원칙(looping principle)이 작동하는 방식입니다.

그렇다면 미래는 더 거대한 모델의 것일까요, 아니면 더 나은 실행 루프의 것일까요? 규모(Scale)가 도움이 되는 것은 확실합니다. 더 유능한 모델은 각 사이클 내에서 더 나은 추론을 수행합니다. 하지만 정교하고 관찰 가능하며 탄력적인 루프 안에서 작동하는 작은 모델이, 모든 것을 단 한 번에 해결하라고 요구받는 거대 모델보다 거의 항상 더 뛰어난 성능을 발휘할 것입니다. 루프는 예측을 행동으로 바꾸는 핵심입니다. 그곳에 투자하십시오.

출처: The Looping Principle: A Simple Mental Model for Understanding AI Agents

이와 같은 더 많은 논의를 원하신다면, Telegram의 GyaanSetu 학습 커뮤니티에 참여하세요.