Loop, Graph, Harness, Model로 에이전트 문제 구분하기

에이전트가 테스트 명령을 생성해도 실행 도구나 런타임이 없으면 검사는 진행되지 않습니다. 실패 원인을 찾으려면 모델의 판단, 실제 도구 실행과 단계 이동 조건을 구분해야 합니다.

Rishi의 글은 Loop, Graph, Harness, Model로 에이전트의 구성을 구분합니다. 이 구분은 실패를 조사하기 위한 관점이며 모든 제품이 따라야 하는 표준 계층 구조는 아닙니다. 개발자는 실패를 조사할 때 반복 실행, 단계 관계, 주변 환경, 모델의 판단 중 어느 부분에 문제가 있는지 나눠 확인할 수 있습니다. 실제 제품에서는 이 역할들이 하나의 프로그램에 함께 구현될 수도 있습니다. 이 글에서는 파일 수정과 검사 작업을 예시로 각 책임을 설명합니다.

판단하는 모델과 실행하는 도구

모델은 입력을 읽고 답변이나 도구 호출을 생성합니다. 어떤 자료가 부족한지, 어느 도구를 사용할지, 결과를 어떻게 해석할지 판단합니다. 그러나 모델이 요청한 행동을 실제로 실행하는 것은 주변 프로그램과 도구입니다.

“파일을 저장했습니다”라는 답변을 받았다면 실제 파일과 도구의 실행 결과를 확인합니다. 주변 프로그램은 도구의 실행 결과를 모델에 돌려줍니다. 개발자는 중요한 완료 조건을 실제 상태와 대조하도록 실행 환경을 구성해야 합니다.

직접 작성한 책임 구분표입니다. 실패 증상을 각 조사 위치에 대응시킨 예시이며, 특정 제품의 내부 구조를 캡처한 화면은 아닙니다.

Loop의 반복과 종료

Loop는 모델의 판단, 도구 실행, 결과 전달을 반복하는 구조입니다. 개발자는 이 구조를 구현할 때 도구가 실패하면 어떤 결과를 반환할지, 언제 모델을 다시 호출할지, 언제 멈출지를 정합니다.

반복 구조에는 종료 조건이 필요합니다. 작업 완료, 사용자의 중지, 비용이나 시간 한도, 반복되는 오류를 구분할 수 있어야 합니다. 모델이 답변을 생성했다는 사실만으로 작업 완료를 처리하면 필요한 검증이 빠질 수 있습니다.

예를 들어 파일을 수정한 뒤 검사를 실행하는 작업에서는 파일 저장과 검사 성공이 서로 다른 상태입니다. 검사 실패 결과를 받아 다시 수정할 수 있어야 하고, 검사가 실행되지 않았을 때도 그 사실을 반환해야 합니다.

Graph의 단계 이동 조건

Graph로 작업을 표현할 때는 단계와 이동 조건을 명시합니다. 조사, 구현, 검증, 전달 사이에 어떤 조건이 필요한지 정할 수 있습니다. 짧은 작업은 단순한 반복 구조로 처리할 수도 있습니다.

단계의 이동 조건에는 검사 결과와 사용자가 승인한 작업 범위를 함께 명시합니다. 작업 흐름을 명시하면 외부 효과가 있는 단계를 구분하기 쉽습니다. 로컬 초안을 만드는 단계와 외부에 게시하는 단계 사이에는 대상과 승인 조건이 있을 수 있습니다. 이전 단계가 성공했다고 다음 단계의 권한까지 자동으로 생기지는 않습니다.

여러 작업자가 필요한 경우에도 단계 관계를 정해야 합니다. 결과를 기다리는 작업과 독립적으로 진행할 작업을 구분하고, 같은 파일을 동시에 수정하지 않도록 담당 범위를 정합니다.

Harness의 실행 환경

Harness는 에이전트를 실행하고 결과를 확인하는 주변 환경과 규칙의 묶음입니다. 도구 연결, 파일 접근, 작업 상태, 검사 명령, 실행 기록 등을 포함할 수 있습니다. 제품에 따라 Loop와 Graph의 일부를 함께 관리하기도 합니다.

예를 들어 코드 에이전트의 실행 환경에는 저장소 경로, 사용할 런타임, 테스트 명령, 수정 권한이 필요합니다. 경로가 잘못됐거나 의존성이 준비되지 않았다면 모델이 올바른 테스트 명령을 생성해도 검사는 실패할 수 있습니다.

증상에 맞는 조사 위치

같은 도구 호출이 끝없이 반복된다면 재시도와 종료 조건을 확인합니다. 올바른 파일을 읽지 못한다면 경로와 접근 도구를 확인합니다. 검증 전에 배포 단계로 넘어간다면 단계 조건을 확인합니다. 필요한 정보가 있는데 판단이 계속 틀린다면 입력 구성과 모델의 결과를 살펴봅니다.

검사가 실행되지 않았다면 먼저 테스트 명령과 환경을 확인합니다. 검사가 실패했는데 작업이 종료됐다면 반복 구조의 결과 처리와 종료 조건을 봅니다. 같은 “검증 미완료”에서도 실패한 위치에 따라 수정할 부분이 달라집니다.

실패 기록에는 모델이 요청한 행동, 도구가 실행한 결과와 다음 단계로 넘어간 조건을 남깁니다. 이 기록을 대조해 실행 환경의 결함과 모델의 판단 오류를 구분한 뒤 수정할 부분을 정합니다.