에이전트 설계의 단위: 루프에서 그래프로의 확장

단일 목표를 반복적으로 수행하고 검증하는 '루프 엔지니어링'은 에이전트가 작업을 수행하면 외부 검증자(Verifier)가 결과를 확인하고, 실패 시 다시 작업을 수행하는 구조다. 테스트 통과와 같은 명확한 종료 조건이 있을 때 작동하며, 사람이 매번 개입해 지시하고 검토하는 부담을 줄이는 것이 핵심이다. 간단한 루프는 별도의 프레임워크 없이 프롬프트만으로도 구성할 수 있으며, 코드 작업에서 테스트가 통과할 때까지 수정과 검토를 반복하는 방식이 대표적이다.

작업의 복잡도가 높아지면 단일 루프만으로는 처리가 어려워지며, 이때 여러 루프와 작업 단계를 연결한 '그래프 엔지니어링'이 필요해진다. 예를 들어 복잡한 코드 리뷰 시스템에서는 코드 생성 에이전트가 변경 사항을 만들고, 여러 감사 에이전트가 병렬로 이를 검사하며, 검증자가 발견 사항을 모아 수정 에이전트(Fixer)에게 전달하는 흐름을 갖는다. 이는 여러 작업자가 일을 나눠 맡고 결과를 인계하며 서로 검토하는 인간 조직의 운영 방식과 유사하다.

구조적 관점에서 그래프 엔지니어링은 루프 엔지니어링을 대체하는 개념이 아니라, 여러 루프를 하나의 시스템으로 운영하기 위한 상위 오케스트레이션 계층이다. 루프가 개별 작업의 반복과 검증이라는 최소 단위라면, 그래프는 이 단위들을 연결해 병렬 브랜치와 핸드오프(Handoff)를 관리하는 전체 설계도 역할을 한다.

확률적 노드가 만든 오케스트레이션의 변화

워크플로우 엔진이나 DAG(Directed Acyclic Graph) 스케줄러, 상태 머신(State Machine) 같은 그래프 구조는 소프트웨어 공학에서 오래전부터 사용해온 방식이다. 에어플로우(Airflow) 같은 도구가 대표적인 사례다. 하지만 최근의 그래프 엔지니어링이 주목받는 이유는 그래프의 모양이 아니라, 각 노드에 배치되는 '실행자'의 성격이 변했기 때문이다.

기존 워크플로우의 각 단계는 정해진 규칙을 그대로 실행하는 결정론적 구조였다. 반면 에이전트 노드는 지시를 해석하고 스스로 판단하는 확률적인 LLM 에이전트다. 이로 인해 같은 입력에서도 실행마다 다른 결정을 내릴 수 있고, 예상치 못한 도구나 경로를 선택할 가능성이 존재한다. 즉, 고정된 규칙의 연결이 아니라 확률적인 실행자들을 어떻게 통제하고 연결할 것인가라는 새로운 설계 문제가 등장한 것이다.

이러한 변화는 설계자가 기존의 채팅 컨텍스트(Chat Context) 안에서 미뤄왔던 구체적인 제어 규칙을 명시하도록 강제한다. 어떤 작업을 병렬로 실행할지, 어떤 상태를 다음 노드에 전달할지, 누가 다른 에이전트의 결과를 거부(Veto)할 수 있는지, 그리고 실패 시 어느 단계로 되돌아갈지를 시스템 수준에서 정의해야 한다. 특히 무한 루프를 방지하기 위한 비용 제한과 반복 횟수 설정, 전체 작업의 종료 조건 명시가 오케스트레이션의 핵심 과제가 된다.

실무자를 위한 검증 전략과 도입 경로

에이전트의 수를 늘리거나 여러 에이전트가 서로 검증하게 한다고 해서 신뢰성이 자동으로 높아지지는 않는다. 동일한 모델과 잘못된 컨텍스트를 공유하는 리뷰어 에이전트들은 서로의 오류를 강화하거나, 체계적으로 정리된 잘못된 결론에 합의할 위험이 있다. 따라서 판단 구조의 분리가 필수적이다. 서로 다른 모델을 리뷰어로 사용하거나, 리뷰어에게 완전히 새로운 컨텍스트를 제공하고, 중요 변경 사항에는 사람의 검토와 거부 권한을 추가하는 설계가 필요하다.

가장 신뢰할 수 있는 검증은 에이전트 시스템 외부의 독립된 증거를 확보하는 것이다. 실제로 실행된 테스트 결과, 완료된 거래 내역, 사용자의 실제 행동, 또는 독립된 전문가의 판단과 같은 외부 신호를 최종 판단 근거로 삼아야 한다. 모든 검증을 다시 에이전트에게 맡기는 완전 자동화는 구조적 한계가 명확하기 때문이다.

실무적인 도입 순서는 유행하는 복잡한 그래프를 먼저 만드는 것이 아니라, 단순한 루프에서 시작해 점진적으로 확장하는 방식이 효율적이다. 먼저 반복 수행할 실제 작업과 이를 확인할 검증자, 사람이 확인할 수 있는 상태와 명확한 중단 조건을 갖춘 단일 루프를 구축한다. 이후 운영 과정에서 발생하는 실패 패턴을 분석하여 독립된 리뷰어, 병렬 브랜치, 보안 에이전트의 거부권, 상태 저장 및 재시도 로직을 하나씩 추가하는 것이 실제 작업 복잡성에 맞춘 최적의 경로다.