이 글은 BEACON (저장대학교, arXiv:2605.06078)을 자세히 읽고 시작한 장기 에이전트 설계 연재의 두 번째 글입니다.
앞선 첫 번째 글에서는 반복이 입력 측 신호인 반면 진척은 출력 측 신호이므로 반복 감지로는 정체된 에이전트를 잡을 수 없다고 주장했습니다. 이 주장은 진척을 대조해 측정할 대상이 있어야 성립합니다. 이번 글은 그 대상에 관한 이야기입니다.
질문을 올바르게 던지세요
질문은 "에이전트는 한 단계를 끝냈다는 것을 어떻게 아는가"가 아닙니다. "완료했다고 선언한 것에 그치지 않고 실제로 끝났음을 시스템은 어떻게 아는가"입니다.
계층 하나의 차이지만 신뢰도는 비교할 수 없습니다.
두 부분은 이미 있었지만 연결하지 않았습니다
자체 구현을 읽으며 놀란 부분입니다.
첫 번째 부분. 마일스톤은 이미 제품에 있습니다. 도구가 영속적인 작업 계획을 유지합니다. 긴 작업을 어떻게 나누는지와 각 단계가 대기, 진행 중, 완료, 차단 중 어떤 상태인지 기록합니다. 명시된 목적은 긴 작업에 안정적인 진척 기준점을 제공하는 것입니다. 하지만 단계가 어떻게 "완료"가 될까요? 모델이 선언합니다.
두 번째 부분. 도구 호출 후마다 호스트는 결정론적인 사실들을 기록합니다. 파일 내용의 해시가 실제 바뀌었는지, 명령 종료 코드가 무엇인지, 시간이 초과되었는지입니다. 이 정보는 호스트 측에 기록되고 모델 맥락에 들어가지 않습니다. 바로 그래서 조작할 수 없습니다.
간극은 여기에 있습니다. 한쪽은 완료했다고 말합니다. 다른 쪽은 파일 해시가 A에서 B로 바뀌었다고 말합니다. 둘을 나란히 놓은 적은 없습니다.
빠진 것은 데이터 구조도 관측 가능성도 아닙니다. 둘을 잇는 연결입니다.
논문에서 가장 유용한 것은 공식이 아닙니다
BEACON은 이중 스케일 어드밴티지로 가장 잘 알려져 있지만, 가져다 쓸 만한 부분은 탐지기 Φ를 배치하는 방식입니다.
Φ는 학습된 모델도 사람의 주석도 필요하지 않습니다. 환경 피드백에서 관측 가능한 상태 변화만 읽습니다. ALFWorld에서는 객체 상태 전이(집기 성공, 가열 완료), WebShop에서는 페이지 전환을 읽고, ScienceWorld에서는 환경이 이미 내보내는 하위 목표 신호를 그대로 사용합니다.
추가 모델도, 추가 샘플링 비용도 0입니다. 대안을 비교해 보세요. 과정 보상 모델은 비싼 주석이 필요하고 편법에 취약하며, 몬테카를로 가치 추정은 모든 의사 결정 지점에서 추가 롤아웃이 필요합니다. Φ는 그 비용을 피합니다.
에이전트 제품을 만드는 사람에게는 논문의 환경에 없는 이점이 있습니다. 도구 호출은 처음부터 구조화되어 성공과 실패가 명시적입니다. 논문은 환경에서 신호를 캐내야 했지만 우리에게는 이미 있습니다.
구현한다면 필요한 세 계층
첫 번째 계층: 결정론적 증거를 하나의 스트림으로 모으기. 의미 판단 없이 되돌릴 수 없는 검증 가능한 변화만 기계적으로 기록합니다. 파일 내용 해시가 바뀌었다. 명령이 종료 코드 0으로 끝났다. 외부 API 호출이 성공을 반환했다. 행이 커밋되었다. 모두 이미 존재합니다. 다만 흩어져 있을 뿐, 지금까지 확인한 사실을 하나의 기록으로 모은 적이 없습니다.
두 번째 계층: 두 부분 연결하기. 가장 가치가 높은 단계입니다. 모델이 한 단계의 완료를 선언하면 그대로 믿지 말고 해당 시간 구간에서 첫 번째 계층의 증거를 찾으세요. 증거가 있으면 검증된 완료로 표시하고, 없으면 선언된 완료로 표시하세요. 모델의 선언을 막는 것은 아닙니다. 근거가 있는 것과 없는 것을 구분할 뿐입니다.
세 번째 계층: 기능 유형별로 Φ 정의하기. 저자들도 Φ에는 도메인 지식이 필요하고 일반화가 어렵다고 인정하므로 만능 탐지기 하나를 기대하지 마세요. 코딩 작업은 테스트 종료 코드를 보고, 데이터 분석 작업은 출력 파일이 실제 생겼는지 보고, 메시지 작업은 API 응답을 봅니다. 이 계층은 기능 하나씩 천천히 확장합니다.
우리가 추가한 기준 하나: 중요성이 아니라 비가역성
이것은 논문에 없습니다.
BEACON의 마일스톤은 되돌릴 수 없는 상태 전이를 표시하므로 작동합니다. 열쇠를 얻고 나면 세계는 달라집니다. 따라서 기준은 이 행동이 되돌릴 수 없는 외부 부수 효과를 만들었는가여야 하며, 이 단계가 중요했는가가 아닙니다.
되돌릴 수 없는 것: 파일 쓰기, 코드 커밋, 메시지 전송, 유료 API 호출, 데이터베이스 커밋. 되돌릴 수 있는 것: 파일 읽기, 검색, 페이지 가져오기, 생각하기.
여기서 두 가지가 따라옵니다. 행동 유형으로 결정되므로 기계적으로 판단할 수 있습니다. 의미 이해가 필요 없고 "모델이 이 단계를 중요하게 여겼다"는 주관도 끼어들지 않습니다. 또한 복구 지점과 일치합니다. 되돌릴 수 있는 행동은 다시 하면 되므로 되돌릴 수 없는 경계에서 재개하는 것만이 의미 있는 재개입니다.
용기를 주는 수치와 주의를 요구하는 수치
용기를 주는 것은 성능 저하 실험입니다. 마일스톤 절반을 무작위로 누락해도 점수는 기준선 72.8 대비 82.8로 10점 높습니다. 절벽처럼 무너지지 않고 완만하게 떨어집니다. 이를 출시하는 사람에게 중요한 부분입니다. Φ가 완벽해져야 활성화할 수 있는 것이 아닙니다. 절반만 포괄해도 효과가 있습니다.
주의를 요구하는 것은 분할 방식 비교입니다.
| 분할 방식 | 점수 | 기준선(72.8) 대비 |
|---|---|---|
| 무작위 5분할 | 74.2 | +1.4 |
| 실제 마일스톤 | 91.4 | +17.2 |
첫 번째 글에서도 이 수치를 인용했지만 여기서는 의미가 더 직접적입니다. 직감으로 마일스톤을 정하면 사실상 무작위 분할에 가까워 노력이 낭비됩니다. 마일스톤은 작업의 실제 구조와 맞아떨어질 때 비로소 가치가 있습니다.
그대로 받아들이면 안 되는 부분
논문 부록 자체가 자동 마일스톤 발견을 미해결 문제로 꼽습니다. 세 벤치마크 모두 환경 응답의 패턴 일치, 페이지 전환, 환경이 직접 건네는 신호 같은 규칙에서 마일스톤을 얻습니다. 브라우저 조작, 코드베이스 리팩터링, 심층 리서치처럼 진정한 개방형 환경에는 이렇게 미리 준비된 검증 가능 전이가 없습니다.
따라서 이는 구조화된 환경 안에서 검증된 패러다임이지 통째로 가져다 쓸 수 있는 해법이 아닙니다. 에이전트 제품에 적용할 수 있게 하는 것은 논문이 이미 준 답이 아니라 도구 호출의 구조화된 경계입니다.
또 다른 함정은 세분화 수준입니다. 너무 드물면 아무것도 한 셈이 아니고, 너무 촘촘하면 구간 수준 신호가 잡음이 됩니다. 제품 관점에서는 작업 분해의 세분화 수준이며, 여기에는 논문 환경에 없는 편의가 있습니다. 계획 단계는 원래 사용자가 보는 것이므로 순수 알고리즘으로만 조정하는 대신 사람이 단계를 이해할 수 있는지에 기준을 둘 수 있습니다.
한 가지만 한다면
두 번째 계층을 구현하세요.
첫 번째 계층의 데이터가 이미 있고 두 번째 계층은 이를 모델의 선언과 연결할 뿐이므로 비용이 낮습니다. 검증된 완료와 선언된 완료의 비율 자체가 관찰할 만한 지표이므로 독립적으로 검증할 수 있습니다. 또한 나머지 모든 것의 전제 조건입니다. 검증된 마일스톤 개념이 없으면 첫 번째 글의 정체 감지와 다음 글의 압축 경계 모두 기반이 없습니다.
부담이 적은 성질도 있습니다. 출시해도 행동은 바뀌지 않습니다. 모델은 이전과 똑같이 단계를 선언하고 표시만 하나 추가됩니다. 데이터가 쌓이면 증거 없이 도착한 선언에 개입할지 결정할 수 있습니다.
다음 글에서는 맥락 압축을 다룹니다. 토큰 임계값에서 자르는 것이 안전하게 잊어도 되는 내용과 왜 거의 무관한지, 그리고 마일스톤이 검증되면 그 이전은 모두 접어도 된다는 이 글의 가장 자연스러운 확장 해석을 어떻게 바로잡아야 하는지 설명합니다.