AI 에이전트 기초 패턴 정리: 체인·라우팅·병렬 처리·관리자 구조·평가 루프 다섯 가지

핵심 메시지

• LLM 결과가 실망스러운 이유가 모델 한계가 아니라 다루는 방식일 수 있으며, 단계적으로 생각을 거치게 하는 기법들이 그 사이 많이 발전했다.
• 에이전트를 만들려면 거대한 프레임워크가 필요한 것이 아니라 프로그래밍 기본 문법만 알면 되고, 앤트로픽이 공개한 에이전트 제작 가이드가 출발점이 된다.
• 가장 기본은 체인이다. 한 번에 많은 것을 요구하면 정확도가 떨어지므로, 요청을 잘게 쪼개 앞선 결과를 다음 요청에 넘기는 순차 구조로 만든다.
• 라우팅은 프롬프트를 여러 개 준비해두고 어떤 것을 실행할지 AI가 판단하게 하는 방식이며, 부서별 응대 가이드를 나눠둔 고객 상담이 대표적인 예다.
• 관리자 역할과 실행 역할을 나누거나, 명확한 기준을 가진 평가자를 두고 통과할 때까지 반복시키는 구조로 스스로 판단하는 형태에 가까워질 수 있다.

쉽게 이해하기

영상은 LLM에 실망하는 사람이 많지만 그것이 모델의 한계라기보다 다루는 방식의 문제일 수 있다는 지적에서 출발한다. 문제를 주면 곧바로 답을 내게 하는 대신 사람처럼 단계를 거쳐 생각하도록 시키는 기법이 결과를 크게 바꿨고, 그런 방식을 쓰는 모델들이 코딩 테스트 같은 과제에서 높은 점수를 냈다. 다만 미리 튜닝해둔 모델의 점수만 공개된 경우도 있어 벤치마크 발표는 조금 걸러 볼 필요가 있다는 단서도 붙는다.

에이전트는 이 흐름의 연장선이다. 문제를 단계적으로 분석해 푸는 것은 같지만, AI가 스스로 판단할 여지를 주어 그냥 LLM을 호출하는 것보다 어렵고 복잡한 문제를 다룰 수 있게 만드는 것이 차이다. 만드는 방법을 모르겠다면 앤트로픽이 공개한 에이전트 제작 가이드를 참고하면 되고, 특별한 프레임워크 없이 프로그래밍 기본 문법만으로도 구현할 수 있다고 설명한다.

가장 기본이 되는 기술은 체인이다. AI에 한 번에 많은 것을 요구하면 요구 사항 일부를 빼먹기 때문에, 요청을 잘게 쪼개 순차적으로 날리고 앞 단계 결과를 다음 요청에 넘긴다. 링크가 깨진 데이터를 정제하는 것처럼 요구 사항이 여러 개인 작업에서, 한 번의 큰 요청보다 여러 번의 작은 요청이 훨씬 높은 정확도를 낸다. 라우팅은 여기서 한 걸음 더 나가 프롬프트를 여러 개 준비해두고 어떤 것을 쓸지 AI가 고르게 한다. 고객 문의가 들어오면 어느 부서 답변이 필요한지 한 단어로 판단하게 하고, 그 부서 프롬프트로 실제 요청을 보내는 식이다.

여러 요청을 동시에 날려 결과를 합치는 병렬 처리도 가능하다. 다양한 시각의 글을 써야 한다면 한 번에 다 쓰라고 하는 것보다 각각 별도 요청으로 받아 합치는 편이 결과가 좋다. 무엇을 해야 답이 나올지 불확실한 문제라면 관리자 역할과 실행 역할을 각각 만드는 방법이 있다. 게임 캐릭터를 기획해야 하는데 무엇을 적어야 할지 모를 때, 관리자 쪽에 어떤 항목을 적는 것이 좋을지 정해달라고 하고 그 목록대로 실행 쪽에서 글을 쓰게 하는 구조다. 어떤 작업을 해야 버그가 잡힐지 미리 알 수 없는 디버깅에도 같은 구조가 쓸모 있다.

품질을 끌어올리는 마지막 패턴은 평가 루프다. 번역처럼 결과가 만족스럽지 않을 때 먼저 명확한 기준을 정하고, 그 기준을 지켰는지 판단하는 평가자 쪽을 따로 만든다. 기준에 부합하지 않으면 다시 작업하게 해 통과할 때까지 돌리는 것인데, 성공 기준이 분명한 문제에 특히 적합하다. 이런 기능을 하나씩 얹어가면 사람처럼 여러 작업을 처리하는 에이전트에 가까워진다. 다만 AI가 컴퓨터 자원을 직접 쓰게 하는 방식은 안정성이 떨어지고, 웹페이지에 프롬프트를 몰래 심어두면 돌아다니던 에이전트가 그것을 읽고 실행해버리는 프롬프트 인젝션 문제도 있다. 직접 구조를 짜기 부담스러우면 가상의 팀원을 손쉽게 만들고 외부 검색 같은 편의 기능을 붙일 수 있는 프레임워크로 시작하는 선택지도 있다.

주요 인사이트

• 에이전트 설계의 출발점은 모델 선택이 아니라 요청 분할이다. 정확도가 떨어지는 원인이 대부분 '한 번에 너무 많이 요구했다'는 데 있기 때문에, 쪼개는 것만으로도 결과가 달라진다.
• 라우팅은 프롬프트 길이 문제를 우회하는 기법이기도 하다. 모든 부서의 응대 가이드를 하나의 긴 프롬프트에 몰아넣지 않고 분류 단계를 따로 두면, 각 프롬프트가 짧아져 모델이 지켜야 할 지시가 명확해진다.
• 관리자와 실행을 나누는 구조가 필요한 상황은 문제가 어려울 때가 아니라 무엇을 요구해야 할지 모를 때다. 지시를 구체적으로 쓸 수 없는 작업에서 지시 자체를 먼저 생성하게 하는 접근이다.
• 평가 루프는 성공 기준이 명확한 문제에서만 제대로 작동한다. 기준을 언어로 적을 수 없다면 통과 여부를 판정할 수 없으므로 무한 반복에 빠진다.
• 에이전트에 실제 컴퓨터 조작 권한을 줄 때 위험은 오작동만이 아니다. 웹페이지에 심어둔 지시를 에이전트가 읽고 실행할 수 있다는 프롬프트 인젝션은, 입력을 신뢰할 수 없는 환경에서 구조적으로 남는 문제다.

자주 묻는 질문

관련 AI 소식