에이전트는 모델의 출력을 다음 행동 선택에 이용하고 결과를 다시 입력으로 받아 작업을 이어가는 시스템입니다. 도구를 호출하는 모델과 그 도구를 실제로 실행하는 프로그램의 역할을 구분해야 합니다.
1. 상태를 가진 실행 루프
목표와 현재 결과를 입력하고, 허용한 도구에서 다음 행동을 선택하게 합니다. 프로그램은 도구 입력을 검증하고 실행 결과 또는 오류를 상태에 기록합니다. 이후 모델이 그 결과를 이용해 다음 행동을 선택합니다. ReAct는 추론과 행동의 상호작용을 연구한 접근이며 모든 프레임워크가 같은 구현을 사용하는 것은 아닙니다.
2. 제한을 모델의 문장에만 맡기지 않기
실행 횟수와 시간·비용 제한, 재시도와 중단 조건을 프로그램에 둡니다. 외부 쓰기 작업의 권한과 승인은 도구 실행 단계에서도 확인합니다. 도구 결과에 적힌 문장이 시스템의 권한을 바꾸게 하지 않습니다. 여러 에이전트를 쓰더라도 책임과 공유 상태가 자동으로 정리되는 것은 아닙니다.
3. 작은 예제로 평가하기
읽기 전용 자료 검색부터 시작해 정상 입력, 도구 실패와 답이 없는 사례를 준비합니다. 선택한 도구와 입력, 결과와 최종 답변을 기록하면 잘못된 판단과 실행 오류를 구분할 수 있습니다. LangGraph 같은 상태 기반 프레임워크의 구체 API는 채택한 버전의 공식 문서에 맞춰 확인하며, 이 글은 재현하지 않은 벤치마크를 제시하지 않습니다.
4. 자료 조사 작업을 상태 전이로 나누기
가상의 에이전트가 세 문서에서 서비스 장애의 원인을 정리한다고 합시다. 처음 상태에는 질문과 읽을 수 있는 문서 목록이 있습니다. 검색 도구가 반환한 문서 식별자와 관련 구간을 저장하고, 누락한 정보가 있으면 추가 검색을 선택합니다. 근거가 충분하면 답변을 작성하고, 제한에 도달했는데 원인이 확정되지 않으면 확인한 사실과 남은 불확실성을 반환합니다. 성공 문장 하나만 만들어야 한다고 요구하면 불충분한 근거에서 결론을 꾸밀 수 있습니다.
상태에는 최종 답변뿐 아니라 이미 수행한 행동도 필요합니다. 같은 문서를 같은 검색어로 계속 찾는다면 새 정보가 늘지 않았다는 것을 확인할 수 있어야 합니다. 도구 호출 횟수, 마지막 진행 시점, 해결하지 못한 질문과 오류 유형을 저장하면 중단 조건을 코드로 만들기 쉽습니다. 모든 내부 텍스트를 무제한으로 쌓기보다 실행을 이어 가고 검토하는 데 필요한 항목을 구조화합니다.
전이의 예는 “검색 필요 → 검색 실행 → 결과 검토 → 추가 검색 또는 종료”입니다. 모델은 추가 검색이 필요하다는 제안을 할 수 있지만 프로그램은 남은 예산과 허용 도구를 확인한 뒤 실행합니다. 모델의 출력이 곧 실행 허가가 되지 않도록 경계를 둡니다. 이런 구조는 복잡한 프레임워크 없이도 만들 수 있으며, 프레임워크를 사용해도 상태와 전이의 의미를 설계자가 정해야 합니다.
5. 재시도와 중복 실행의 차이
읽기 도구의 일시적인 실패는 제한된 재시도로 해결할 수 있습니다. 반면 주문 생성이나 파일 제출처럼 외부 상태를 바꾸는 도구는 응답이 끊겼다는 이유로 무조건 다시 실행하면 같은 작업이 중복될 수 있습니다. 요청 식별자로 중복을 막거나 실행 결과를 조회한 뒤 재시도하는 방식을 도구 수준에서 제공해야 합니다. “다시 시도할 때 주의하라”는 프롬프트만으로 이미 전송된 요청의 상태를 알 수는 없습니다.
오류도 종류를 나눕니다. 입력 형식이 틀렸다면 매개변수를 수정해야 하고, 권한이 없으면 다른 표현으로 같은 요청을 반복해도 해결되지 않습니다. 서비스가 잠시 중단되었다면 대기 후 다시 시도할 수 있지만 시간 제한을 넘기지 않아야 합니다. 문서에 답이 없는 경우는 도구 장애가 아닙니다. 답이 없다는 결과를 새 검색어로 끝없이 반복하지 않고 사용자에게 반환할 수 있어야 합니다.
승인이 필요한 동작은 사람이 무엇을 검토하는지 구체적으로 보여 줍니다. 예를 들어 문서를 외부로 공유한다면 받는 사람, 공유할 문서와 접근 범위를 실행 전에 확정합니다. 승인한 내용이 이후 모델의 판단으로 달라졌다면 같은 승인으로 볼 수 없습니다. 승인 상태와 실행 대상을 함께 저장해야 사람이 확인한 작업과 실제 수행한 작업의 대응을 검토할 수 있습니다.
6. 여러 에이전트를 쓰는 이유를 먼저 정하기
조사자와 검토자를 나누면 서로 다른 기준으로 결과를 살필 수 있지만 같은 모델과 같은 자료를 사용하면 같은 오류를 반복할 수도 있습니다. 검토자의 역할은 막연히 “더 꼼꼼히 확인”하는 것이 아니라 각 주장에 근거가 있는지, 시행일이 맞는지 같은 확인 항목으로 정의하는 편이 좋습니다. 에이전트 수를 늘렸다는 사실만으로 답변이 더 정확해지는 것은 아닙니다.
병렬 작업에서는 공유 상태의 충돌을 고려합니다. 두 조사자가 같은 문서의 다른 버전을 읽을 수 있고, 한쪽이 지운 결론을 다른 쪽이 되살릴 수 있습니다. 결과에 문서 버전과 작업 식별자를 연결하고 누가 최종 결론을 합치는지 정합니다. 동시에 수정할 필요가 없다면 읽기와 제안을 병렬화하고 실제 변경은 한 지점에서 순서대로 처리할 수도 있습니다. 분업의 이득과 조정 비용을 함께 봅니다.
평가에는 정상적인 성공 외에 중단이 잘 되는 경우를 넣습니다. 도구가 계속 실패할 때 제한 안에서 멈추는지, 권한 없는 요청을 다른 도구로 우회하지 않는지, 근거가 부족할 때 확인되지 않았다고 말하는지 확인합니다. 최종 답변이 맞았더라도 중간에 허용하지 않은 문서를 읽었다면 실행 전체가 적절했다고 평가할 수 없습니다. 과정의 제약과 결과의 품질을 분리해 기록합니다.
관찰 기록은 모델의 장황한 설명을 그대로 믿기 위한 자료가 아닙니다. 실제 호출한 도구 이름과 검증한 인수, 성공·실패 결과, 상태 변화와 종료 사유가 핵심입니다. 민감한 문서 원문을 기록에 복제할 필요가 있는지는 별도로 검토합니다. 오류를 재현할 식별자와 최소한의 정보만 남겨도 운영에 필요한 근거를 확보할 수 있습니다.
작은 자동화가 정해진 순서대로만 동작한다면 모든 단계를 모델이 고르게 만들 필요는 없습니다. 고정된 조회와 검사는 코드로 처리하고, 문서 해석이나 검색어 선택처럼 판단이 필요한 지점에 모델을 사용할 수 있습니다. 자율성의 범위를 작업에 맞추면 종료 조건과 책임이 분명해집니다. 에이전트 실행 루프의 완성도는 스스로 오래 움직이는 능력보다 주어진 권한과 근거 안에서 필요한 일을 끝내는 능력으로 살펴보세요.
실행을 저장했다가 이어 가는 기능도 외부 작업의 중복 방지와 같지 않습니다. 상태를 저장한 직후 전송 요청이 성공했지만 성공 기록을 쓰기 전에 프로세스가 종료될 수 있습니다. 다시 시작할 때는 저장된 상태만으로 실제 외부 결과를 확정하지 말고 요청 식별자나 조회 도구를 이용해 확인해야 합니다. 장기 실행 프레임워크를 도입했더라도 이런 경계의 의미는 도구 설계에 남습니다. 복구 시나리오를 한 번 직접 재현하면 저장, 실행과 확인이 만나는 지점을 검토하기 쉽습니다.