[arXiv 2606.15579] Agent Genome: XEPV 시퀀스로 에이전트 행동을 분석하고 런타임에서 통제하기

Your Agent Has a Genome: Sequence-Level Behavioral Analysis and Runtime Governance of LLM-Powered Autonomous Agents

https://arxiv.org/abs/2606.15579

Sidi Deng | Independent Researcher | arXiv:2606.15579 | 2026년 6월

---

1. 서론: 에이전트의 답변보다 행동 유전자를 읽는 문제

LLM 에이전트를 운영할 때 가장 답답한 지점은 실패가 결과 화면에만 남고 과정은 금방 사라진다는 점이다. 같은 모델이 같은 도구 묶음으로 작업해도 어떤 실행은 빠르게 파일을 읽고 수정한 뒤 검증까지 마치지만, 다른 실행은 검색과 재계획 사이를 맴돌다가 토큰을 태우고 멈춘다. 이 논문은 그 차이를 자연어 추론문 전체로 분석하지 않는다. 대신 에이전트가 실제로 밟은 도구 호출 흐름을 네 글자의 짧은 알파벳으로 압축해, 행동의 반복 패턴을 통계적으로 읽어낸다.

제목의 Genome 은 은유이지만, 논문의 문제의식은 꽤 실무적이다. 에이전트가 성공했는지 실패했는지 뒤늦게 판정하는 것을 넘어, 실행 중간에 위험한 행동 패턴이 나타나는 순간 개입할 수 있어야 한다. 저자는 Explore, Execute, Plan, Verify를 각각 X, E, P, V로 두고, 에이전트의 한 작업 실행을 $S=b_1-b_2-\cdots-b_n$ 형태의 Base Sequence로 표현한다. 이 표현은 로그 전체를 읽지 않아도 n-gram, 전이행렬, 상관분석, 온라인 규칙 업데이트를 적용할 수 있을 만큼 작다.

논문이 흥미로운 이유는 단순히 “에이전트 로그를 분석하자”는 주장에 머물지 않는 데 있다. 저자는 8일 동안 생산 환경의 ReAct형 에이전트 시스템에서 수집한 347개 실행 trace를 분석하고, 그 결과를 곧바로 Governor라는 런타임 개입 시스템으로 연결한다. Governor는 별도의 LLM 호출 없이 시퀀스 수준에서 위험 패턴을 감지하고, 필요한 순간 짧은 교정 프롬프트를 삽입한다. 보고된 자연 배포 전후 비교에서는 성공률이 88.1%에서 94.3%로 오르고, 평균 토큰 사용량은 275K에서 154K로 줄어든다.

이 리뷰에서 특히 볼 지점은 세 가지다. 첫째, P-X-P라는 plan-explore-plan 진동 패턴이 전역 성공률보다 10.4%p 낮은 유일한 통계적 고위험 trigram으로 잡힌다. 둘째, Execute 이후 Verify로 이어지는 $E o V$ 전이가 2.1%에 불과해, 에이전트가 실행 결과를 체계적으로 확인하지 않는다는 결핍이 드러난다. 셋째, 저자는 DunCrew 내부 로그에서 얻은 패턴을 SWE-agent의 SWE-bench 2,000개 공개 trajectory에 맞춰 다시 인코딩해, 탐색 스파이럴과 검증 부족이라는 두 신호가 다른 시스템에서도 반복되는지 확인한다.

Figure 1: DunCrew 시스템 안에서 base classifier, Governor, trace recorder가 붙는 위치를 보여 주는 구조도.

이 그림은 Base Sequence Analysis가 별도 사후 분석 노트로 머물지 않고 에이전트 런타임의 반환 경로에 들어간다는 점을 보여 준다. 도구 호출 결과가 돌아올 때 base classifier가 X/E/P/V를 붙이고, Governor가 즉시 규칙을 평가하며, trace recorder가 전체 실행을 JSONL로 남긴다. 그래서 같은 구조 안에서 실시간 개입, 사후 provenance 분석, 규칙 threshold 재조정이 이어진다. 논문이 주장하는 거버넌스는 별도 감사 리포트를 나중에 쓰는 방식보다 실행 흐름에 가까이 붙어 있다.

기존 에이전트 평가 논문들은 종종 최종 산출물, 도구 호출 성공률, human preference, benchmark pass rate를 중심으로 논의를 구성했다. 반면 이 논문은 “성공한 실행과 실패한 실행의 행동 문자열은 어떻게 다른가”를 먼저 묻는다. 이 질문은 이전에 리뷰했던 Shepherd의 typed execution trace, TRACE의 runtime correction enforcement, provenance-aware evaluation과 맞닿는다. 다만 Shepherd가 실행을 fork/replay 가능한 기판으로 다루고 TRACE가 사용자 correction을 규칙으로 컴파일하는 쪽에 가까웠다면, Agent Genome은 도구 호출 흐름 자체를 통계적 신호로 만들고 운영 규칙을 데이터에서 끌어낸다는 점이 다르다.

2. 배경 및 관련 연구: 실행 궤적을 평가 단위로 바꾸는 흐름

2.1 ReAct 이후 에이전트 로그는 왜 다루기 어려운가

ReAct 계열 에이전트는 생각, 도구 호출, 관찰, 재시도를 섞어 장기 작업을 해결한다. 이 구조는 사람이 보기에는 그럴듯한 작업 흐름을 만들지만, 운영 관점에서는 로그가 너무 풍부해서 곧바로 통계 모델에 넣기 어렵다. 자연어 thought에는 작업 설명, 자기 점검, 오류 변명, 다음 행동의 이유가 모두 섞이고, 도구 호출에는 읽기, 검색, 쓰기, 테스트, 실행 명령이 서로 다른 입출력 형식으로 기록된다. 따라서 원본 로그만으로는 “실패 직전 어떤 행동 패턴이 반복되었는가”를 안정적으로 묻기 어렵다.

이 논문은 그 복잡도를 의도적으로 줄인다. 정보 수집은 X, 상태를 바꾸는 행동은 E, 명시적 전략·추론 턴은 P, 결과 확인은 V로 분류한다. 이렇게 하면 도구 이름이 달라도 “읽고, 쓰고, 다시 읽고, 계획하는” 큰 행동 구조는 같은 알파벳 위에서 비교할 수 있다. 생물학의 genome 분석처럼 모든 내용을 보존하지 않고, 반복 패턴과 전이 확률을 계산할 수 있는 최소 표현을 고르는 셈이다.

물론 이런 압축은 정보 손실을 만든다. 예를 들어 같은 Execute라도 단순 파일 저장과 대규모 리팩터링은 위험도가 다르고, 같은 Verify라도 테스트 전체 실행과 한 줄 grep 확인은 증거력이 다르다. 저자는 이 한계를 완전히 해결했다고 주장하지 않는다. 대신 base sequence를 1차 행동 언어로 두고, 원본 trace의 도구명, timestamp, 성공 여부, 오류 유형, 토큰 사용량 같은 metadata를 함께 묶어 co-design한다고 설명한다. 압축된 문자열은 패턴 분석에 쓰고, 세부 맥락은 해석과 규칙 조정에 남겨 두는 방식이다.

2.2 trajectory-level evaluation과 provenance-aware evaluation의 연결

내가 보기에 이 논문은 trajectory-level agent evaluation의 운영형 변형에 가깝다. trajectory-level 평가는 최종 답변만 보지 않고 도구 순서, 파일 의존성, 검증 행동, 복구 가능성까지 평가한다. Agent Genome은 이 관점을 더 짧은 시퀀스 언어로 바꿔, 평가자가 매번 전체 로그를 읽지 않아도 위험 패턴을 자동 집계할 수 있게 만든다. 특히 실패한 실행에서 P 비율이 두 배 가까이 높고 E 비율이 낮다는 결과는, 최종 산출물 채점만으로는 보이지 않는 과정 품질 신호다.

provenance-aware evaluation과의 차이도 분명하다. provenance-aware 접근은 산출물의 근거 파일, 수정 이력, 도구 호출 증거를 추적해 “무엇을 근거로 이 결과가 나왔는가”를 검증한다. Agent Genome은 그 근거 계층 위에 “어떤 행동 리듬이 성공 또는 실패를 예고하는가”를 올린다. 즉 provenance가 증거의 계보라면, base sequence는 실행의 리듬이다. 두 관점을 합치면 에이전트가 어떤 파일을 근거로 삼았는지와 어떤 행동 패턴으로 그 파일에 접근했는지를 함께 볼 수 있다.

TRACE나 Shepherd와 비교하면 위치가 더 선명해진다. TRACE는 사용자가 한 번 지적한 correction을 runtime check로 바꿔 코딩 에이전트가 같은 위반을 반복하지 않게 만든다. Shepherd는 실행 trace를 fork/replay 가능한 substrate로 만들어 supervisor나 meta-agent가 개입할 수 있게 한다. Agent Genome은 이 둘 사이에서, 개입 규칙을 사람이 직접 쓴 체크리스트보다 시퀀스 통계에서 시작하려고 한다. 따라서 “어디에 개입할 것인가”라는 질문에 대해 경험적 근거를 붙일 수 있다.

Figure 2: Base sequence 분석 대시보드. base 분포, 길이별 성공률, 월별 분포, 성공/실패 작업의 base ratio를 함께 보여 준다.

대시보드의 핵심은 시퀀스 분석이 추상적 은유에 그치지 않고 운영 지표로 바뀐다는 점이다. X와 E가 대부분을 차지하고 V가 극히 낮다는 사실, 길이가 길다고 실패가 늘지 않는다는 사실, 성공과 실패의 P/E 비율이 다르다는 사실이 한 화면에서 연결된다. 특히 대시보드는 개별 실패 사례를 읽는 수준에서 멈추지 않고, 전체 배포 로그의 행동 습관을 비교할 수 있게 만든다. 이후 Governor 규칙은 이 관찰들을 직접 반영한다. 이 화면을 먼저 보면 뒤의 표와 규칙 이름이 단절된 조각이 아니라 같은 운영 진단 흐름에서 나온다는 점을 확인할 수 있다.

2.3 자연어 reasoning trace 대신 행동 base를 쓰는 선택

최근 AI safety와 agent monitoring 연구에서는 모델의 reasoning trace를 감시 표면으로 쓰는 시도가 많다. 하지만 reasoning trace는 모델 정책, 프롬프트 형식, 제공 여부에 따라 쉽게 흔들리고, 어떤 배포 환경에서는 노출되지 않는다. 이 논문이 base sequence에 집중한 이유는 그보다 낮은 계층의 행동 로그가 더 안정적으로 남기 때문이다. 도구가 호출되었는지, 읽기였는지 쓰기였는지, 결과 확인이 있었는지는 대부분의 에이전트 런타임에서 관측 가능하다.

이 선택은 특히 운영 비용 측면에서 중요하다. Governor는 high-risk pattern을 감지하기 위해 별도 LLM judge를 호출하지 않는다. 문자열 suffix, 전이 카운트, 최근 5개 base의 비율, step count 같은 값만 업데이트하면 된다. 논문이 “zero LLM overhead”라고 표현하는 지점이 여기다. 즉 감시는 모델보다 가벼운 상태 기계로 돌리고, LLM은 실제 작업에 쓰는 구조다.

3. 방법론: XEPV base sequence와 8차원 행동 특징

3.1 네 글자 알파벳의 정의

Base Sequence Framework의 가장 작은 단위는 한 step의 행동 base다. Explore(X)는 정보를 모으지만 상태를 바꾸지 않는 행동이다. 파일 읽기, 디렉터리 조회, 텍스트 검색, 웹 검색, 웹 fetch 등이 여기에 들어간다. Execute(E)는 아티팩트나 외부 상태를 바꾸는 행동이다. 파일 쓰기, append, 삭제, rename 같은 동작이 대표적이다. Verify(V)는 수행 결과를 검증하는 행동으로, write 후 read, 오류 뒤 재시도, 테스트·린트 명령 실행 같은 패턴이 포함된다. Plan(P)은 도구 호출 없이 전략을 세우거나 추론하는 턴이다.

저자가 강조하는 점은 이 분류가 도구 이름 목록에만 묶이지 않는다는 것이다. DunCrew 시스템에서는 20개 이상의 도구 범주를 base로 매핑했고, SWE-agent에서는 command-line action을 다른 기준으로 인코딩했다. 같은 “읽기”라도 시스템마다 API 이름은 다르지만, 상태를 바꾸지 않는 정보 수집이라는 역할은 유지된다. 이 역할 중심 설계가 cross-system adapter의 기반이 된다.

수식으로는 한 작업 실행을 $S=b_1-b_2-\cdots-b_n,\; b_i \in \{E,P,V,X\}$로 둔다. 여기서 n은 sequence length이며, 논문 데이터에서는 평균 8.7 step, 최대 44 step 이상이다. 이 길이는 전체 자연어 로그에 비해 매우 짧다. 그래서 n-gram pattern mining, Markov transition matrix, point-biserial correlation 같은 고전적인 통계 도구를 그대로 적용할 수 있다.

Table 1: Base sequence에서 추출하는 8차원 특징 벡터

Feature	Definition	Complexity
consecutiveX	끝부분에 연속으로 나타난 X의 개수	$O(n)$
stepCount	전체 sequence length n	$O(1)$
xRatioLast5	마지막 5개 base 안에서 X 비율	$O(1)$
switchRate	인접 base가 바뀌는 빈도	$O(n)$
pInLateHalf	후반부에 P가 등장했는지 여부	$O(n)$
lastPFollowedByV	가장 최근 P 뒤에 V가 따라왔는지 여부	$O(n)$
maxERunLength	연속 E run의 최대 길이	$O(n)$
xeRatio	X와 E 사이의 균형 정도	$O(n)$

이 특징들은 복잡한 neural representation을 쓰지 않고도 충분히 많은 운영 질문을 던지게 해 준다. 예를 들어 consecutiveX와 xRatioLast5는 정보 수집이 루프로 굳는지 잡고, switchRate는 방향 전환이 과도한지 본다. pInLateHalf는 작업 후반에 다시 계획으로 돌아가는 현상을 포착하고, lastPFollowedByV는 계획이 실제 검증으로 이어졌는지 확인한다. maxERunLength와 xeRatio는 실행을 충분히 하고 있는지, 탐색만 늘어지는지 판별하는 신호가 된다.

3.2 trace co-design과 adapter interface

논문에서 중요한 설계 원칙은 base sequence만 저장하고 끝내지 않는다는 점이다. 각 base는 원본 도구 호출, timestamp, 입력·출력 요약, 오류 여부, task success label과 연결된다. 이렇게 해야 P-X-P 같은 패턴이 발견되었을 때 실제 로그로 돌아가 어떤 상황에서 plan-explore-plan 진동이 발생했는지 해석할 수 있다. 압축된 문자열은 패턴 탐지의 색인이고, 원본 trace는 원인 분석의 증거다.

adapter interface는 이 논문을 특정 DunCrew 구현에 묶지 않으려는 장치다. 어댑터는 외부 에이전트 시스템의 action을 X/E/P/V로 매핑하고, success label과 step metadata를 맞춰 분석 파이프라인에 넘긴다. SWE-agent 적용 사례에서 이 설계의 장점과 한계가 동시에 드러난다. SWE-agent는 강제 action 구조 때문에 P가 0%로 나타나는데, 논문은 이것을 오류로 보지 않고 시스템 구조가 만들어낸 올바른 표현이라고 본다.

이 대목은 실무에서도 중요하다. 서로 다른 에이전트 프레임워크를 비교할 때 모든 내부 reasoning을 동일한 형식으로 맞추기는 어렵다. 그러나 읽기, 쓰기, 확인, 명시적 planning 같은 행동 범주는 비교적 이식 가능하다. 따라서 adapter는 모델별 benchmark 점수보다 한 단계 아래에서, 에이전트 runtime의 행동 습관을 비교하는 공통 언어로 작동한다.

Table 2: 도구 범주를 XEPV base로 매핑하는 분류표

Category	Tools
Read (X)	readFile, listDir, searchText, searchFiles
Explore (X)	webSearch, webFetch
Write (E)	writeFile, appendFile, deleteFile, renameFile
Verify (V)	write 이후 read, 오류 이후 retry, test/lint command
Plan (P)	도구 호출이 없는 LLM reasoning metadata 기반 턴

분류표만 보면 단순해 보이지만, 실제 구현에서는 경계 사례가 많다. 예를 들어 shell command 하나가 파일을 읽고 테스트를 실행하며 로그를 남길 수 있다. 저자는 이 문제를 trace metadata와 rule precedence로 다룬다. 특히 Verify는 단순 읽기와 구분되어야 한다. 실행 직후 결과를 확인하거나 오류 뒤 다시 시도하는 행동은 정보 수집보다 검증 의미가 강하기 때문이다.

3.3 feature를 운영 신호로 읽는 방법

8차원 feature의 장점은 각 값이 사람이 바로 해석할 수 있는 운영 신호라는 데 있다. consecutiveX가 높으면 에이전트가 “아직 더 찾아야 한다”는 상태에 오래 머문다는 뜻이고, xRatioLast5가 높으면 최근 행동이 거의 탐색으로 굳었다는 뜻이다. switchRate가 높으면 방향 전환이 잦아진다. 이 값은 단순히 다양성이 높다는 좋은 신호가 될 수도 있지만, 작업 목표가 명확한 코딩·자료 처리 과제에서는 한 가지 가설을 충분히 밀어붙이지 못하고 있다는 경고일 수 있다.

pInLateHalf는 특히 해석이 중요하다. 작업 초반의 planning은 전체 경로를 정리하는 역할을 할 수 있다. 그러나 작업 후반에 P가 다시 등장하면, 이미 충분한 정보를 모았거나 실행을 시작했는데도 전략을 다시 세우는 상황일 가능성이 커진다. 이때 P 뒤에 V가 붙어 검증으로 닫히면 생산적 점검이 될 수 있지만, P 뒤 X로 넘어가면 다시 자료 수집과 재계획을 반복하는 구조가 된다. 논문이 P-X-P를 위험 패턴으로 본 이유도 이 흐름과 맞닿는다.

lastPFollowedByV는 planning의 품질을 간접적으로 묻는 feature다. 계획이 단순한 자기 설명에 그치면 다음 행동은 추가 탐색이나 실행으로 흩어진다. 반면 계획이 검증 기준을 정리했다면 다음 단계에서 테스트, 재읽기, 결과 확인이 나올 수 있다. 에이전트 운영에서 좋은 planning은 긴 자연어 reasoning을 많이 쓰는 데 있지 않고, 어떤 증거로 완료를 판단할지 결정하는 데 가까워야 한다.

maxERunLength도 양면적이다. 연속 실행은 생산성을 뜻할 수 있지만, 검증이 전혀 붙지 않으면 blind edit spiral이 된다. SWE-agent 결과에서 EEEE가 unresolved trajectory와 연결되는 것은 이 점을 잘 보여 준다. DunCrew에서는 E-E-E가 95.9% 성공률로 고효율 패턴에 들어가지만, SWE-agent에서는 EEEE가 실패 방향의 4-gram으로 나타난다. 같은 E run도 시스템 구조, 작업 종류, verify 정책에 따라 의미가 달라진다.

따라서 feature를 규칙으로 바꿀 때는 절대값만 보지 말고, 주변 base와 task phase를 함께 봐야 한다. 예를 들어 X가 8번 이어졌다고 항상 나쁜 것은 아니다. 문서가 큰 작업이나 검색 중심 작업에서는 긴 탐색이 필요할 수 있다. 논문에서 x_brake threshold가 8에서 12로 조정된 것도 이런 이유다. 규칙의 목적은 특정 행동을 금지하는 데 있지 않고, 현재 prefix가 성공 trajectory에서 흔한 범위를 벗어나는지 확인하게 만드는 것이다.

이 관점은 실제 에이전트 제품의 dashboard 설계에도 유용하다. 운영자는 전체 원문 로그를 매번 읽기보다, 작업별 base string, 현재 feature vector, trigger된 규칙, 다음 행동 변화를 한 화면에서 볼 수 있다. 실패 보고서에는 “모델이 틀렸다”라는 결론보다 “후반부 P가 증가했고, E streak 뒤 V가 없었으며, switchRate가 60%를 넘었다”는 설명이 더 재현 가능하다. 이런 설명은 human reviewer가 다음 규칙을 수정하거나 프롬프트를 바꿀 때 바로 사용할 수 있다.

4. 실험 설정: DunCrew 생산 로그와 SWE-agent 공개 궤적

4.1 DunCrew 데이터셋

주 실험 데이터는 DunCrew라는 생산 ReAct agent system에서 8일 동안 수집한 347개 real-world execution trace다. 전체 success rate는 92.5%, 평균 sequence length는 8.7 step, 총 base count는 3,015개다. 도구는 20개 이상이며, 작업은 실제 운영 환경에서 자연스럽게 발생한 실행 로그로 구성된다. 논문은 이것을 controlled benchmark라기보다 natural deployment trace에 가깝게 다룬다.

Table 3: DunCrew 데이터셋 요약 통계

Metric	Value
Total traces	347
Success rate	92.5%
Mean sequence length	8.7 steps
Max sequence length	44+ steps
Total base count	3,015
Unique tools used	20+

이 데이터 규모는 아주 크지 않다. 저자도 고차 n-gram을 안정적으로 추정하기에는 부족하다고 인정한다. 그러나 2-gram과 주요 3-gram 수준에서는 실패와 성공의 행동 차이를 보기 시작할 수 있다. 특히 production trace라는 점은 장점이다. benchmark용으로 잘 정제된 태스크를 넘어 실제 에이전트가 어느 순간 어떤 루프에 빠지는지를 보여 주기 때문이다.

Figure 3: sequence length와 task duration의 관계. 성공은 초록 원, 실패는 빨간 X로 표시되며 비용 성장은 이차 곡선으로 근사된다.

산점도는 긴 실행이 곧 실패라는 직관을 약화한다. 실패는 초장기 작업보다 짧거나 중간 길이의 실행에도 몰려 있고, 긴 작업 중에도 성공 사례가 많다. 그래서 단순 step count 차단 규칙은 위험하다. 실제로 Governor의 step_fuse는 초기에는 켜졌지만, 긴 작업의 성공률이 높다는 데이터가 쌓인 뒤 비활성화된다. 이 그림은 규칙 기반 통제가 고정된 휴리스틱이 되면 안 되고, 실제 성공 궤적의 분포를 계속 반영해야 함을 보여 준다. 따라서 이 그림은 길이 제한보다 prefix 구조와 검증 전이 비율을 함께 보는 판단이 필요하다는 근거로 쓰인다.

4.2 SWE-agent cross-system validation

논문은 DunCrew 결과를 내부 사례로만 남기지 않고, 2,000개 public SWE-agent trajectory를 SWE-bench 위에서 재인코딩한다. 이 검증의 의미는 크다. DunCrew는 자체 도구와 runtime을 가진 시스템이고, SWE-agent는 command-line action 중심 구조다. 두 시스템의 action space와 control loop가 다르기 때문에 동일한 P 비율이나 동일한 trigram이 그대로 반복되기를 기대하기 어렵다. 그럼에도 탐색 스파이럴과 검증 부족이 해결 여부와 연결되는지 확인할 수 있다.

SWE-agent에서는 강제 action 구조 때문에 P가 0%로 나온다. 이 결과는 base taxonomy가 시스템 구조를 드러내는 예다. 어떤 에이전트는 planning을 명시적 메시지로 남기고, 어떤 에이전트는 항상 command action 안에서만 움직인다. 따라서 cross-system 비교에서는 base의 절대 비율만 보지 말고, 시스템이 어떤 행동을 관측 가능하게 만드는지도 함께 읽어야 한다.

Table 4: SWE-agent resolved와 unresolved trajectory의 행동 지표 비교

Metric	Resolved (n=338)	Unresolved (n=1,662)	Direction
Pr(V | E)	54.2%	28.1%	높을수록 좋음
Pr(E | E)	41.5%	63.6%	낮을수록 좋음
Pr(X | X)	74.6%	84.8%	낮을수록 좋음
Mean max X-run	4.8	11.0	낮을수록 좋음
V ratio	24.7%	15.7%	높을수록 좋음
X ratio	33.6%	44.9%	낮을수록 좋음
Mean steps	16.0	30.1	낮을수록 좋음

SWE-agent 결과는 DunCrew에서 관찰한 두 신호를 반복한다. 해결된 trajectory는 Execute 이후 Verify로 넘어갈 확률이 높고, X self-loop와 긴 X-run이 낮다. 반대로 unresolved trajectory는 탐색이 길게 이어지고 실행 뒤 검증보다 같은 실행 또는 추가 탐색으로 흐르는 경향이 강하다. 이것은 base sequence가 특정 UI나 도구 집합에만 묶이지 않고, 코딩 에이전트의 행동 품질을 보는 공통 축으로 작동할 수 있음을 시사한다.

5. 주요 실험 결과: P-X-P 위험 패턴과 검증 결핍

5.1 전체 base 분포와 성공/실패 차이

DunCrew의 전체 base 분포는 X 46.6%, E 37.5%, P 12.6%, V 3.3%다. 정보 수집과 실행이 대부분을 차지하고, 명시적 검증은 매우 작다. 이 분포만 보면 에이전트가 활발히 읽고 쓰는 것처럼 보이지만, 실제 문제는 실행 뒤 확인이 거의 붙지 않는다는 데 있다. 특히 V의 3.3%는 agentic workflow에서 결과 확인이 얼마나 소홀하게 처리되는지 보여 주는 강한 신호다.

Table 5: DunCrew 전체 base distribution

Base	Count	Ratio	Interpretation
X (Explore)	1,406	46.6%	정보 수집이 가장 큰 비중을 차지
E (Execute)	1,131	37.5%	상태를 바꾸는 실행 행동
P (Plan)	379	12.6%	명시적 추론과 전략 수립
V (Verify)	99	3.3%	검증 행동이 극히 낮음

성공과 실패를 나누면 차이가 더 선명해진다. 실패한 작업은 평균 길이가 7.1로 성공 작업의 8.8보다 짧고, E ratio가 23.4%로 성공 작업의 38.4%보다 낮다. 반대로 P ratio는 실패 23.4%, 성공 11.9%로 거의 두 배다. 이 결과는 실패가 단순히 오래 걸려서 생긴다기보다, 충분히 실행하지 못하고 계획과 탐색 사이에서 소모되는 구조와 관련 있음을 보여 준다.

Table 6: 실패 작업과 성공 작업의 base ratio 비교

Metric	Failed	Succeeded	Difference
Mean length	7.1	8.8	-1.7
E ratio	23.4%	38.4%	-15.0%p
P ratio	23.4%	11.9%	+11.5%p
V ratio	1.6%	3.4%	-1.8%p
X ratio	51.6%	46.3%	+5.3%p

여기서 P를 나쁘게만 해석하면 곤란하다. 계획은 장기 작업에 필요하다. 문제는 작업 후반부에 실행과 검증으로 닫히지 못하는 계획, 그리고 계획 뒤 다시 탐색으로 빠지는 진동이다. 논문은 바로 이 구조를 P-X-P trigram에서 잡아낸다. “생각을 많이 해서 실패했다”는 식의 결론보다, 계획이 구체적 실행으로 귀결되지 않고 추가 탐색과 재계획을 부르는 패턴이 위험하다는 해석이다.

Figure 4: 고위험 패턴과 고효율 패턴의 성공률 비교. P-X-P가 전역 평균 대비 가장 뚜렷한 하락을 보인다.

패턴 비교 그림에서 P-X-P는 단순 빈도 높은 조합을 넘어 성공률 하락과 연결된 행동 진동으로 드러난다. 반대로 V가 포함된 패턴은 표본 수가 작아 조심스럽지만 모두 100% 성공률을 보인다. 이 대비는 Governor가 “계획을 줄여라”보다 “실행 뒤 확인하라”에 가까운 개입을 설계해야 함을 말해 준다. 계획 자체를 억제하는 것보다 계획이 실행과 검증으로 닫히는지를 보는 편이 더 안정적인 운영 규칙으로 이어진다. 표본 수가 작거나 편향된 패턴은 별도 검정과 운영 로그 누적을 거쳐야 한다는 주의도 함께 남긴다.

5.2 n-gram pattern mining

n-gram 분석의 핵심 발견은 P-X-P다. 42개 작업에서 관찰된 이 trigram은 성공률 83.3%로, global baseline보다 10.4%p 낮다. 논문은 이를 plan-explore-plan oscillation으로 해석한다. 즉 에이전트가 계획을 세운 뒤 정보를 조금 더 찾고, 다시 계획으로 돌아가며 실제 실행으로 닫히지 않는 흐름이다. 다른 후보인 X-E-X는 90.5%, X-X-X는 94.4%로 나타나지만 통계적으로 P-X-P만큼 강한 고위험 신호로 잡히지는 않는다.

Table 7: 고위험 trigram 분석

Trigram	Tasks	Success	Delta vs. Global	Significance
P-X-P	42	83.3%	-10.4%p	p < 0.05
X-E-X	42	90.5%	-2.3%p	not significant
X-X-X	143	94.4%	+3.2%p	not significant

반대로 high-efficiency pattern에서는 V가 강하게 보인다. E-V는 20개 작업에서 100%, E-E-V는 10개 작업에서 100%, E-E-E는 97개 작업에서 95.9% 성공률을 보인다. 표본 수가 작은 V 패턴을 과대해석해서는 안 되지만, 실행 뒤 확인이 붙는 구조가 적어도 해로운 신호는 아니라는 점은 분명하다. 논문은 이 관찰을 Governor의 miss_verify 규칙으로 연결한다.

Table 8: 고효율 패턴과 검증 포함 패턴

Pattern	Tasks	Success	Note
E-V	20	100%	실행 후 검증
E-E-V	10	100%	실행 체인 뒤 검증
E-E-E	97	95.9%	지속 실행 패턴

Figure 5: 상위 15개 trigram의 빈도와 성공률. 빈도 높은 패턴과 위험한 패턴이 항상 일치하지 않는다.

상위 trigram 그림은 단순 빈도와 위험도를 분리해서 읽어야 함을 보여 준다. X-X-X처럼 자주 등장하는 패턴이 곧바로 실패 신호가 되지는 않는다. 반면 P-X-P는 빈도만 보면 압도적이지 않아도 성공률 하락이 크다. 따라서 runtime rule은 많이 보이는 행동보다 성과와 연결된 행동에 반응해야 한다. 이 차이는 로그 분석에서 빈도표만 보고 규칙을 만들 때 생기는 함정을 줄여 주며, 규칙 후보를 outcome-conditioned pattern으로 좁히게 한다.

5.3 Markov transition과 feature correlation

전이행렬에서 가장 강한 신호는 self-loop와 검증 결핍이다. E 다음에는 E가 68.0%로 이어지고, X 다음에는 X가 57.2%로 이어진다. 이는 실행이 실행을 부르고, 탐색이 탐색을 부르는 관성이다. 더 중요한 수치는 $E o V$ 2.1%다. 상태를 바꾼 뒤 결과를 확인하는 전이가 거의 없다는 뜻이다. 이 값은 agent workflow에서 검증 행동이 설계상 선택 사항으로 밀려나 있음을 보여 준다.

Table 9: 1차 Markov transition matrix

From / To	E	P	V	X
E	68.0%	9.8%	2.1%	20.1%
P	20.7%	0.0%	22.5%	56.8%
V	19.5%	40.2%	1.1%	39.1%
X	23.0%	19.6%	0.2%	57.2%

상관분석에서는 P_ratio가 가장 강한 음의 예측 변수로 나온다. point-biserial correlation은 -0.256이고 p-value는 0.0001 미만이다. switch_rate도 -0.134로 유의하고, E_ratio는 +0.132로 유의하다. has_V는 +0.092지만 p=0.088로 통계적 유의성은 약하다. 이 조합은 “검증이 있으면 좋다”는 직관보다 더 조심스럽다. 데이터에서는 계획 비율 상승과 잦은 방향 전환이 실패와 더 뚜렷하게 연결되고, 실행 비율 상승은 성공과 연결된다.

Table 10: 성공과 base feature의 point-biserial correlation

Feature	r_pb	p-value	Significance
P_ratio	-0.256	< 0.0001	***
switch_rate	-0.134	0.013	*
E_ratio	+0.132	0.014	*
has_V	+0.092	0.088	not significant
length	+0.067	0.213	not significant
X_ratio	-0.033	0.542	not significant

Figure 6: 전체, 3월 subset, 4월 subset의 1차 Markov 전이 확률 heatmap. E와 X self-loop, 낮은 E→V가 반복된다.

전이행렬 heatmap은 월별 subset에서도 같은 구조가 유지된다는 점을 보여 준다. E와 X의 self-loop는 agent가 한 방향으로 관성 있게 흐른다는 뜻이고, E 뒤 V가 거의 없다는 신호는 특정 날짜의 우연으로 보기 어렵다. 이 안정성 때문에 Governor 규칙을 한 번의 로그 해석을 넘어 운영 정책으로 올릴 근거가 생긴다. 특히 시간 구간이 달라도 같은 전이 습관이 보이면, 규칙이 특정 배치의 노이즈에 과적합됐을 가능성이 낮아진다. 특히 verification deficit이 여러 기간에 반복된다는 사실은 단순 프롬프트 습관보다 시스템 수준 개선 과제로 읽힌다.

Figure 7: base sequence feature와 task success 사이의 point-biserial correlation. P_ratio가 가장 강한 음의 상관을 보인다.

상관 그래프는 어떤 feature를 먼저 운영 규칙으로 바꿀지 우선순위를 준다. P_ratio와 switch_rate는 실패 쪽으로, E_ratio는 성공 쪽으로 기울어진다. has_V는 방향은 좋지만 유의성이 약하므로 단독 성공 보장으로 쓰기보다, miss_verify처럼 실행 streak 뒤 확인을 요구하는 구체적 규칙으로 바꾸는 편이 더 안전하다. 이처럼 논문은 feature를 그대로 점수화하기보다, 운영자가 해석 가능한 prefix 조건과 prompt template으로 번역한다.

Figure 8: 실패 유형 분포와 월별 성공률 추세. 3월과 4월 사이 성능은 비교적 안정적으로 유지된다.

실패 분석 그림은 base sequence 신호가 월별 성능 변동 하나에 기대고 있지 않음을 보조한다. 실패 유형이 다양하고 월별 성공률이 크게 무너지지 않는 상황에서도 P 비율, switch rate, 검증 부족은 반복적으로 관찰된다. 운영 규칙을 만들 때 단일 장애 이벤트보다 누적 행동 습관을 보는 이유가 여기에 있다. 즉 Governor는 특정 장애 원인을 맞히는 분류기라기보다, 실패로 기울어지는 실행 리듬을 조기에 흔드는 장치에 가깝다. 그래서 이 패널은 실패 원인 taxonomy보다 행동 시퀀스 기반 감시가 왜 필요한지 설명하는 보조 증거가 된다.

5.4 실패를 짧은 실행으로만 설명하지 않는 이유

논문에서 눈에 띄는 결과 중 하나는 실패 작업의 평균 길이가 성공 작업보다 짧다는 점이다. 많은 운영자는 길어진 agent run을 위험 신호로 먼저 의심한다. 긴 실행은 비용이 많이 들고, 사용자가 기다리는 시간이 늘고, 외부 상태가 더 많이 바뀔 수 있기 때문이다. 그러나 이 데이터에서는 실패가 짧은 실행에서도 나타난다. 이는 실패가 “너무 오래 해서”에만 묶이지 않고 “충분히 닫지 못해서” 발생할 수 있음을 보여 준다.

짧은 실패의 대표적 구조는 탐색과 계획이 빠르게 반복된 뒤 실행으로 넘어가지 못하는 경우다. 에이전트가 몇 개의 파일을 읽고, 다시 전략을 설명하고, 다시 비슷한 자료를 찾은 다음 종료하면 sequence length는 길지 않다. 하지만 산출물은 충분히 바뀌지 않았거나 검증되지 않는다. 이때 length만 감시하면 위험을 놓친다. 반대로 P_ratio, E_ratio, V ratio를 함께 보면 “짧지만 닫히지 않은 작업”을 잡을 수 있다.

긴 성공도 마찬가지다. 복잡한 작업은 여러 파일 탐색, 단계적 수정, 반복 테스트가 필요하다. 이런 작업은 step count가 길어지지만, E와 V가 적절히 섞이면 오히려 성공률이 높을 수 있다. 논문에서 step_fuse가 비활성화된 것은 이 점을 잘 보여 준다. 길이는 비용 신호로 관리해야 하지만, 성공 위험 신호로 직접 쓰려면 task type과 base composition이 함께 필요하다.

이 분석은 자동 발행이나 코딩 에이전트 운영에도 그대로 적용된다. 작업이 오래 걸린다고 즉시 중단하면 복잡한 작업을 처리할 수 없고, 짧게 끝났다고 안전하다고 보면 미검증 산출물이 통과된다. 더 좋은 기준은 “지금까지 어떤 행동을 했고, 그 행동이 어떤 검증으로 닫혔는가”다. Base Sequence Analysis는 이 질문을 짧은 문자열과 feature vector로 표현한다.

특히 $E o V$가 2.1%라는 수치는 많은 agent workflow의 기본값이 얼마나 낙관적인지 드러낸다. 사람이 코딩할 때도 파일을 고친 뒤 테스트나 재읽기를 생략하면 오류가 남는다. 에이전트는 이 습관을 더 빠른 속도로 반복한다. miss_verify 규칙은 거창한 안전 정책 수준을 넘어, 실행한 것을 확인하라는 기본 공학 습관을 runtime에 강제로 되살리는 장치다.

한편 V가 너무 많아도 문제다. SWE-agent의 VVVV가 unresolved trajectory에만 나타난다는 결과는 test-only loop를 시사한다. 검증이 성공으로 이어지려면 확인 결과를 바탕으로 다음 실행이 바뀌어야 한다. 같은 테스트만 반복하거나, 오류 메시지를 읽고도 수정하지 않으면 V 역시 루프가 된다. 따라서 좋은 거버넌스는 V를 무작정 늘리는 데 그치지 않고, E와 V 사이의 생산적 순환을 만드는 쪽으로 설계되어야 한다.

6. 추가 분석 및 Ablation Study: Governor가 규칙을 데이터로 갱신하는 방식

6.1 Governor 아키텍처

Governor는 base sequence 분석을 런타임 개입으로 바꾸는 세 계층 시스템이다. 첫 번째 계층은 rule engine이다. 현재 sequence prefix와 8차원 feature를 보고 x_brake, switch_warn, miss_verify, explore_dom, div_collapse, late_plan 같은 규칙을 평가한다. 두 번째 계층은 statistical accumulator다. 규칙별 trigger, success, token, length를 계속 누적한다. 세 번째 계층은 chi-square 기반 threshold adaptor로, 규칙의 효과가 데이터와 맞지 않으면 임계값을 조정하거나 규칙을 비활성화한다.

중요한 점은 Governor 규칙이 사람이 직관으로 쓴 정적 휴리스틱이 되지 않도록 설계되었다는 것이다. 초기 규칙은 empirical analysis에서 출발하지만, 운영 중에 계속 성과를 본다. step_fuse가 대표 사례다. 처음에는 길이가 길어지면 실패 위험이 커질 것이라는 가정으로 step count 기준 규칙이 들어갔다. 그러나 실제 데이터는 15 step 이상 작업의 성공률이 97.4%로 높다는 쪽을 보여 주었고, Governor는 이 규칙을 비활성화했다.

Table 11: Governor의 규칙과 데이터 기반 근거

Rule	Trigger	Intervention	Empirical Basis
x_brake	consecutive X ≥ 12	탐색 중단과 다른 접근 요구	X→X self-loop 57.2%
switch_warn	switch rate > 60%	한 방향에 집중하도록 요청	switch_rate r=-0.134
miss_verify	E streak ≥ 3 with no V	즉시 검증 요청	E→V only 2.1%
explore_dom	X/(X+E) > 55%	탐색 축소와 실행 요청	X/E imbalance
div_collapse	최근 5 step이 모두 동일	루프 탈출 요청	diversity collapse
late_plan	후반부 P 등장	재계획 중단과 실행 요청	pInLateHalf negative signal
step_fuse	length ≥ 12	비활성화	긴 작업 성공률이 높다는 데이터

규칙 문구도 강한 명령보다 짧은 교정 prompt에 가깝다. 예를 들어 miss_verify는 “연속 실행 후 결과를 확인하지 않았다. 데이터는 $E o V$ 전이가 성공과 연결됨을 보인다. 지금 결과를 검증하라”는 식으로 들어간다. 이 메시지는 작업 목표를 바꾸지 않고, 현재 행동 리듬을 한 번 끊는다. zero LLM overhead라는 표현은 감지와 판단에 LLM을 쓰지 않는다는 뜻이지, 개입 후 에이전트가 LLM 추론을 전혀 하지 않는다는 뜻은 아니다.

Figure 9: Governor 배포 전후 성공률, 토큰 사용량, base 분포, 규칙별 trigger 빈도와 성공률을 비교한 6패널 분석.

Governor 효과 분석은 성공률과 비용을 함께 보여 준다. post-triggered group의 성공률은 96.4%이고, post 전체 평균 토큰은 pre의 275K에서 154K로 줄었다. 단순 성능 향상만 보면 intervention이 더 많은 추론을 유발했을 가능성이 있지만, 토큰 감소가 함께 나타나기 때문에 탐색·재계획 루프를 끊는 효과로 해석할 여지가 생긴다. 다만 배포 전후 비교라는 한계가 있으므로, 이 그림은 효과의 정량적 증명보다 운영 신호의 방향성을 보여 주는 근거로 읽는 편이 안전하다.

6.2 배포 전후 비교와 rule ablation

메인 결과는 natural before/after deployment 평가다. Pre-Governor 101개 trace의 성공률은 88.1%, 평균 토큰은 275K, 평균 길이는 22.2다. Post-Governor 전체 246개 trace는 성공률 94.3%, 평균 토큰 154K, 평균 길이 14.0이다. triggered group 193개는 성공률 96.4%, 평균 토큰 179K, 평균 길이 16.3으로 나타난다. not triggered group은 성공률 86.8%, 평균 토큰 65K, 평균 길이 5.6이다.

Table 12: Governor 배포 전후 메인 결과

Group	N	Success	Avg Tokens	Avg Length
Pre-Governor	101	88.1%	275K	22.2
Post-Governor (all)	246	94.3%	154K	14.0
Triggered	193	96.4%	179K	16.3
Not triggered	53	86.8%	65K	5.6

이 표는 인과 실험으로 읽기에는 조심해야 한다. 자연 배포 전후 비교라서 task mix, 모델 상태, 외부 환경이 완전히 통제되었다고 보기 어렵다. 그럼에도 success +6.2%p와 token -44%가 동시에 나타난 것은 운영적으로 무시하기 어렵다. 특히 triggered group이 post 전체보다 더 높은 성공률을 보인다는 점은, Governor가 위험한 작업에서 무작정 방해 요소로 작동하지 않았을 가능성을 보여 준다.

Table 13: Governor 규칙별 trigger 통계

Rule	Tasks	Success	Avg Tokens	Assessment
x_brake	146	98.6%	171K	가장 가치가 큰 규칙
switch_warn	88	95.5%	205K	빈도가 높고 효과적
miss_verify	54	96.3%	241K	중간 빈도
explore_dom	50	96.0%	210K	중간 빈도
late_plan	32	93.8%	228K	중간 빈도
step_fuse	43	100%	305K	비활성화 결정 검증
div_collapse	14	100%	291K	낮은 빈도, 모두 성공

규칙별 통계에서 active rule은 모두 93.8% 이상의 성공률을 보인다. 다만 이 숫자는 selection bias를 포함할 수 있다. 어떤 규칙이 trigger된 작업 자체가 더 쉬웠거나, post 기간의 task distribution이 달랐을 수 있기 때문이다. 논문이 더 강해지려면 동일한 prefix에서 intervention을 넣은 경우와 넣지 않은 경우를 무작위로 비교하는 online A/B 또는 counterfactual replay가 필요하다. 저자는 5.4절에서 counterfactual estimation을 논의하지만, 현재 핵심 증거는 자연 배포 관찰에 가깝다.

Table 14: 성공 1건당 토큰 비용

Group	Tokens per Success	Relative
Pre-Governor	313K	1.00x baseline
Post-Governor (triggered)	186K	0.59x (-41%)
Post-Governor (not triggered)	74K	0.24x

비용 관점에서는 tokens per success가 유용하다. triggered group은 성공 1건당 186K 토큰으로 pre의 313K보다 41% 낮다. 에이전트 운영에서는 단순 성공률만큼 중요한 지표가 “성공을 얻기 위해 얼마나 많은 시도와 토큰을 태웠는가”다. Governor는 실패를 줄이는 동시에 길게 늘어지는 탐색·재계획 루프를 줄여 이 비용을 낮추는 방향으로 작동한 것으로 보인다.

6.3 Reflexion과의 상호작용

논문은 Governor를 Reflexion류 오류 복구와 비교한다. No-error baseline은 성공률 97.0%, 평균 토큰 119K, 평균 step 12.4다. Reflexion only는 성공률 89.6%, 평균 토큰 270K, 평균 step 18.7로, 오류 복구 과정에서 비용이 크게 늘어난다. Governor + Reflexion은 성공률 94.3%, 평균 토큰 154K, 평균 step 14.1이다. 저자는 이를 Reflexion-only와 no-error baseline 사이 gap의 53%를 회복하고, token cost를 43% 줄인 결과로 해석한다.

Table 15: Reflexion intervention과 Governor 결합 비교

Configuration	Success	Mean Tokens	Mean Steps
No-error baseline	97.0%	119K	12.4
Reflexion only	89.6%	270K	18.7
Governor + Reflexion	94.3%	154K	14.1

이 결과는 runtime governance의 위치를 보여 준다. Reflexion은 오류가 발생한 뒤 자기반성을 통해 복구하려는 후행 메커니즘에 가깝다. Governor는 오류가 명시적으로 드러나기 전 행동 리듬이 나빠지는 순간을 잡아 intervene한다. 두 방식은 경쟁 관계라기보다 서로 다른 시간대의 제어다. 실무적으로는 오류 후 복구보다 오류 전 루프 차단이 더 싸기 때문에, Governor가 token cost를 낮추는 방향으로 작동할 수 있다.

Figure 10: Reflexion 유무와 오류 횟수에 따른 성공률, 오류 복구율, token cost와 sequence length를 비교한다.

Reflexion 분석 그림은 오류 복구 메커니즘이 항상 비용 효율적이지 않다는 점을 보여 준다. 오류가 많아질수록 reflection은 추가 step과 token을 요구하고, 성공률 회복도 제한적이다. Governor는 같은 복구 문제를 sequence prefix 수준에서 더 일찍 다룬다. 따라서 사후 반성보다 사전 행동 제어가 유리한 구간이 존재한다. 특히 이미 실패가 누적된 뒤 긴 reflection을 붙이는 방식과, 위험 prefix가 보이는 순간 짧은 교정 메시지를 넣는 방식의 비용 차이를 비교하게 만든다.

6.4 threshold evolution과 prompt injection의 실무 의미

Governor의 threshold evolution은 이 논문의 실무성을 높이는 부분이다. 초기 규칙은 연구자가 만든 가정에서 시작할 수밖에 없다. 하지만 운영 데이터가 쌓이면 그 가정은 틀릴 수 있다. consecutiveXBrake는 8에서 12로 완화되었고, exploreDomRatio는 0.70에서 0.55로 낮아졌다. step_fuse는 켜진 상태에서 비활성화로 바뀌었다. 이 변화는 규칙이 한 번 정해지면 끝나는 정책 파일로 끝나지 않고, 배포 환경에서 계속 보정되는 제어 변수임을 보여 준다.

Table 19: Governor threshold의 V1에서 V4까지 변화

Parameter	V1	V4	Rationale
consecutiveXBrake	8	12	8~12 연속 X에서 성공률 하락이 작게 관찰됨
exploreDomRatio	0.70	0.55	V1 threshold가 높아 거의 trigger되지 않음
step_fuse	enabled	disabled	15 step 초과 작업 성공률이 97.4%로 높음

이 표는 AI 운영 정책을 데이터 기반으로 관리할 때 생기는 좋은 습관을 보여 준다. 정책은 처음부터 완벽하게 맞출 수 없다. 너무 보수적인 규칙은 에이전트의 생산성을 막고, 너무 느슨한 규칙은 위험한 루프를 방치한다. 따라서 각 규칙은 trigger 빈도, trigger 뒤 성공률, token cost, intervention 이후 base 변화까지 기록해야 한다. Governor의 accumulator는 바로 이 feedback loop를 위해 존재한다.

prompt injection template도 조심해서 읽어야 한다. 여기서 injection은 공격적 prompt injection과 구분되는 runtime supervisor가 agent에게 삽입하는 교정 메시지다. 예를 들어 x_brake는 “연속 탐색이 많으니 다른 접근을 재분석하라”고 말하고, switch_warn은 “방향 전환 빈도가 높으니 한 방향에 집중하라”고 말한다. miss_verify는 연속 실행 후 검증이 없음을 지적하고 지금 검증을 요구한다. 이런 메시지는 목표 자체를 바꾸지 않고, 행동 제어의 작은 마찰을 만든다.

Table 20: Governor 규칙별 대표 교정 메시지

Rule	Representative Injection Text
x_brake	연속 탐색이 많으니 문제를 다른 접근으로 재분석하라.
switch_warn	작업 방향 전환 빈도가 높으니 한 방향에 집중하라.
miss_verify	연속 실행 뒤 검증이 없으니 지금 결과를 확인하라.
late_plan	작업 후반에 재계획이 반복되니 기존 정보로 실행을 진행하라.

실무 적용에서 메시지 톤은 생각보다 중요하다. 너무 강한 메시지는 에이전트가 원래 task instruction보다 supervisor 경고를 우선시하게 만들 수 있고, 너무 약한 메시지는 행동을 바꾸지 못한다. 논문의 template은 데이터 근거를 짧게 포함해, 왜 지금 검증하거나 탐색을 멈춰야 하는지 설명한다. 이는 사람 운영자가 나중에 intervention log를 볼 때도 도움이 된다. 어떤 규칙이 왜 trigger되었는지, 에이전트가 이후 어떤 base로 이동했는지 추적할 수 있기 때문이다.

또 하나 중요한 점은 Governor가 모든 위험을 차단하는 hard gate와 구분되는 soft intervention이라는 점이다. 에이전트는 메시지를 받은 뒤에도 작업을 이어 간다. 따라서 시스템이 완전히 멈추는 비용은 낮고, 잘못된 trigger가 나와도 회복 가능하다. 반대로 금융 거래, 삭제, 외부 이메일 발송처럼 side effect가 큰 작업에서는 soft intervention만으로 부족할 수 있다. 이런 영역에서는 base sequence signal을 권한 gate나 human approval과 결합해야 한다.

이런 설계를 보면 Agent Genome은 “에이전트 안전”을 단일 모델의 정렬 문제로만 보지 않는다. 더 작은 runtime control loop를 여러 층으로 쌓는다. base classifier는 관측 계층, Governor는 개입 계층, accumulator와 threshold adaptor는 학습 계층이다. 이 세 층을 분리하면 모델이 바뀌어도 같은 운영 정책을 상당 부분 유지할 수 있다. 바로 이 점이 기업용 agent governance와 연결되는 실용적 가치다.

6.5 운영 배포 관점에서 본 Governor의 위치

Governor를 실제 서비스에 붙인다고 가정하면, 가장 먼저 정해야 할 것은 intervention의 권한 범위다. 이 논문의 Governor는 에이전트에게 짧은 교정 문구를 넣는 soft control에 가깝다. 파일 삭제, 외부 API 호출, 결제, 이메일 발송처럼 되돌리기 어려운 행동을 직접 막는 hard policy engine은 아니다. 따라서 production 환경에서는 base sequence signal을 risk scoring으로 쓰고, 위험도가 높은 side effect 앞에서는 별도의 approval gate로 연결하는 구성이 더 안전하다.

두 번째는 latency와 비용이다. LLM judge 기반 monitor는 설명력이 좋을 수 있지만, 매 step마다 호출하면 비용과 지연이 커진다. Base sequence Governor는 문자열과 카운터만 갱신하므로 step-level hook에 넣기 쉽다. 에이전트가 빠르게 도구를 호출하는 환경에서는 이 차이가 크다. 관측은 항상 켜 두고, 무거운 분석은 trigger가 발생한 일부 trace에만 후처리로 적용하는 계층화가 가능하다.

세 번째는 사용자 경험이다. 에이전트가 너무 자주 “검증하라”, “탐색을 멈춰라” 같은 메시지를 받으면 작업 흐름이 부자연스러워질 수 있다. 이 문제를 줄이려면 규칙마다 cooldown, severity, task phase를 분리해야 한다. 같은 miss_verify라도 간단한 파일 수정에서는 즉시 검증을 요구하고, 장기 research task에서는 몇 step 뒤 source triangulation을 요구하는 식으로 문구와 timing을 바꿀 수 있다.

네 번째는 팀 단위 학습이다. 개인 에이전트의 base sequence만 보면 사용자별 작업 습관을 알 수 있고, 조직 전체로 모으면 어떤 workflow가 자주 실패하는지 볼 수 있다. 예를 들어 특정 repository에서 X-run이 길다면 문서 구조가 나쁘거나 테스트 진입점이 불명확할 수 있다. 특정 toolchain에서 V가 낮다면 검증 명령이 너무 느리거나 실패 메시지가 해석하기 어려운 것일 수 있다. Base sequence는 에이전트 평가를 넘어 작업 환경의 마찰도 드러낸다.

다섯 번째는 rule registry의 책임 소재다. 데이터가 어떤 규칙을 만들었다고 해도, 그 규칙을 배포할지 결정하는 주체는 여전히 운영자다. 특히 규칙이 사용자 작업 방식을 제한하거나 비용을 바꾸는 경우에는 설명 가능한 changelog가 필요하다. threshold가 왜 바뀌었는지, 어떤 기간의 데이터가 근거였는지, 바뀐 뒤 success와 token cost가 어떻게 변했는지 기록해야 한다. 논문의 V1에서 V4로 이어지는 threshold 표는 이런 changelog의 초기 형태로 볼 수 있다.

여섯 번째는 실패 후 학습 루프다. Governor가 trigger되었는데도 실패한 trace는 가치가 높다. 그 trace에서는 규칙이 너무 늦게 개입했는지, 메시지가 행동을 바꾸지 못했는지, 애초에 base sequence로 잡히지 않는 외부 원인이 있었는지 확인할 수 있다. 반대로 trigger 없이 실패한 trace는 새로운 rule 후보를 찾는 데이터가 된다. 운영 시스템에서는 이 두 묶음을 자동으로 샘플링해 주간 리뷰에 올리는 방식이 유용하다.

일곱 번째는 모델 업데이트와의 관계다. LLM이 바뀌면 같은 task에서도 base distribution이 달라질 수 있다. 더 강한 모델은 V를 더 자주 수행할 수도 있고, 반대로 자신감이 높아져 검증을 생략할 수도 있다. 따라서 Governor threshold는 모델 버전과 함께 관리해야 한다. 모델을 교체한 뒤에는 일정 기간 shadow mode로 base sequence를 모아, 기존 규칙이 여전히 맞는지 확인하는 절차가 필요하다.

마지막으로, Base Sequence Analysis는 에이전트 운영의 공통 로그 포맷 후보가 될 수 있다. 지금은 각 프레임워크가 서로 다른 tool schema와 trace schema를 사용하지만, X/E/P/V 수준의 행동 요약은 비교적 쉽게 맞출 수 있다. 이 공통 요약이 있으면 benchmark 논문, 제품 telemetry, 내부 품질 대시보드가 같은 축으로 대화할 수 있다. 논문이 “genome”이라는 표현을 쓴 것도 이런 공통 행동 언어에 대한 기대를 담고 있다.

7. 한계점 및 향후 연구 방향: 작은 데이터, 자연 배포, adapter 편차

7.1 인과성의 한계

가장 큰 한계는 인과성이다. Governor 배포 전후 성공률과 토큰 사용량이 좋아졌다고 해도, 모든 차이가 Governor 때문이라고 단정할 수는 없다. task mix가 달라졌거나, 모델 호출 환경이 안정화되었거나, 사용자 입력이 쉬워졌을 수 있다. 논문은 natural before/after deployment라는 표현으로 이 점을 어느 정도 인정한다. 하지만 strong claim을 하려면 동일 task 또는 동일 prefix에서 intervention 여부를 나누는 controlled experiment가 필요하다.

P-X-P가 실패와 연결된다는 결과도 마찬가지다. P-X-P가 실패를 일으키는 원인일 수도 있지만, 이미 어려운 작업이기 때문에 에이전트가 더 자주 재계획하고 탐색했을 가능성도 있다. 즉 pattern은 원인과 증상을 모두 담을 수 있다. 운영 규칙으로는 증상만 잡아도 가치가 있지만, 연구 주장으로는 causal mediation이나 randomized intervention이 뒤따라야 한다.

7.2 데이터 규모와 n-gram order

저자는 n-gram order가 올라갈수록 필요한 trace 수가 급증한다고 정리한다. 2-gram은 16개 조합이라 약 300개 trace로도 가능하지만, 3-gram은 64개 조합이라 약 1,500개 trace가 필요하고, 4-gram은 256개 조합이라 약 5,000개 trace가 필요하다. 5-gram은 1,024개 조합으로 50,000개 수준의 community data가 필요하다고 본다. DunCrew의 347개 trace는 초기 분석에는 충분하지만, 긴 motif를 안정적으로 배우기에는 작다.

Table 16: n-gram order별 데이터 요구량

N-gram	Combinations	Estimated Traces Needed	Feasibility
2-gram	16	~300	이 논문 규모에서 가능
3-gram	64	~1,500	단일 power user 기준 수개월
4-gram	256	~5,000	단일 사용자 기준 약 1년
5-gram	1,024	~50,000	커뮤니티 데이터 필요

이 표는 Base Sequence Analysis의 다음 단계가 어디인지 알려 준다. 한 연구실이나 한 사용자 로그만으로는 고차 행동 문법을 안정적으로 학습하기 어렵다. 반대로 많은 에이전트 runtime이 동일한 adapter interface로 익명화된 base sequence와 outcome을 공유하면, task domain별 위험 motif나 모델별 행동 fingerprint를 훨씬 잘 잡을 수 있다. 다만 이때 privacy와 provenance 문제가 다시 등장한다. base sequence는 원본 텍스트보다 덜 민감하지만, 작업 길이와 행동 흐름 자체가 사용자 업무 패턴을 드러낼 수 있기 때문이다.

7.3 system-specific pathology와 일반화

SWE-agent 검증에서 재미있는 점은 EEEE와 VVVV 같은 system-specific pathology다. unresolved trajectory에서 EEEE는 평균 4.904로 높고 lift 0.17, XXXX도 평균 8.993으로 lift 0.27이다. VVVV는 test-only loop로 해석되며 resolved에서는 0.000, unresolved에서는 0.325로 나온다. DunCrew에서 P-X-P가 중요했다면, SWE-agent에서는 forced action 구조상 P가 사라지고 blind-edit spiral이나 extended exploration spiral이 더 두드러진다.

Table 17: SWE-agent의 discriminative 4-gram

4-gram	Resolved freq.	Unresolved freq.	Lift	Interpretation
XEVE	0.515	0.251	2.05	탐색-편집-검증-편집 cycle
VXXE	0.198	0.105	1.89	검증 후 표적 탐색
XXEV	0.538	0.398	1.35	탐색에서 검증된 편집으로 이동
EEEE	0.822	4.904	0.17	blind-edit spiral
XXXX	2.429	8.993	0.27	extended exploration spiral
VVVV	0.000	0.325	0.00	test-only loop

이 결과는 일반화가 “같은 패턴이 모든 시스템에 나온다”는 뜻이 아님을 잘 보여 준다. 공통되는 것은 탐색 통제와 검증 빈도의 중요성이고, 구체적인 n-gram은 시스템 구조에 따라 달라진다. 따라서 Base Sequence Analysis를 실제로 적용하려면 먼저 해당 runtime의 action grammar를 이해해야 한다. 어댑터가 올바르게 설계되지 않으면 P가 사라지거나 V가 과소 계상되는 것처럼, 행동 언어가 시스템 특성을 왜곡할 수 있다.

Table 18: SWE-bench에서 모델별 base sequence profile

Model	n	X%	E%	V%	Resolved%
Llama-405B	40	34.0	39.9	26.1	42.5
Llama-70B	1,793	43.0	40.0	17.0	16.2
Llama-8B	167	44.8	38.2	17.0	18.0

모델별 profile은 “행동 fingerprint”라는 방향을 연다. Llama-405B는 표본이 작지만 V 비율이 26.1%로 높고 resolved rate도 42.5%다. 70B와 8B는 X 비율이 더 높고 V 비율은 17.0%로 낮다. 단일 benchmark 점수만 보면 모델 크기와 성능을 비교하게 되지만, base profile을 보면 큰 모델이 어떤 행동 습관을 갖는지, 작은 모델이 어디에서 더 많이 탐색하는지까지 볼 수 있다.

Figure 11: base sequence language model의 bigram surprisal, perplexity, prefix 길이에 따른 early warning AUC 등을 보여 준다.

언어 모델 분석은 XEPV 문자열을 작은 행동 언어로 취급할 수 있음을 보여 준다. bigram surprisal은 드문 전이를 강조하고, prefix length별 AUC는 실행 초반 몇 step만으로 실패 위험을 어느 정도 예고할 수 있는지 본다. 이 방향은 Governor를 규칙 집합에서 sequence model 기반 early warning으로 확장하는 출발점이 된다. 규칙이 놓치는 비정형 조합도 surprisal이나 prefix score로 포착할 수 있기 때문에, 장기적으로는 휴리스틱과 학습 기반 감시가 결합될 수 있다.

Figure 12: 8차원 feature space의 PCA projection과 anomaly score 분포, 실패와 성공의 per-feature deviation을 비교한다.

anomaly detection 그림은 실패 사례가 단일 규칙 하나로만 설명되지 않는다는 점을 보완한다. PCA 투영에서는 실패 cluster가 성공 사례와 어느 정도 분리되고, feature deviation은 어떤 축이 평균적 성공 패턴에서 벗어났는지 보여 준다. 운영에서는 규칙 기반 Governor와 anomaly score를 함께 쓰면 알려진 위험과 새로운 이상 행동을 분리할 수 있다. 예를 들어 P-X-P처럼 이미 이름 붙은 위험은 규칙으로 다루고, 낯선 조합의 급증은 anomaly score로 감시하는 식의 계층화가 가능하다.

Figure 13: bigram reward matrix, 상위·하위 trigram reward, 성공/실패 trace의 누적 reward trajectory를 시각화한다.

reward landscape는 base 전이를 성공률 편차 관점에서 다시 해석한다. 어떤 transition이 전역 baseline보다 좋은지 나쁜지, 누적 행동 보상이 성공 trace와 실패 trace에서 어떻게 갈라지는지를 보여 준다. 아직 예비 분석에 가깝지만, 장기적으로는 base-level reward shaping이나 runtime routing 정책으로 이어질 수 있는 시각화다. 다만 이 reward는 인과적 보상이 아니라 관찰된 성공률 편차에서 온 값이므로, 학습 신호로 쓰려면 과적합과 confounding을 별도로 통제해야 한다.

7.4 privacy와 운영 배포의 제약

Base sequence는 원본 로그보다 작고 덜 민감하지만, 완전히 안전한 익명 데이터는 아니다. X가 길게 이어지는 사용자는 정보 수집 중심 업무를 하고 있을 수 있고, E가 많은 사용자는 파일을 많이 수정하는 업무를 하고 있을 수 있다. 특정 시간대, 작업 길이, 실패 빈도와 결합하면 업무 패턴이 노출될 수 있다. 따라서 community-scale base sequence dataset을 만들려면 task text 제거만으로는 부족하고, 시간 bucket, user grouping, rare motif masking 같은 추가 보호가 필요하다.

또 하나의 제약은 개입 문구의 안전성이다. Governor prompt는 짧지만, 잘못 설계되면 에이전트의 목표 우선순위를 흐릴 수 있다. 예를 들어 “탐색을 멈추고 실행하라”는 규칙은 정보가 부족한 상황에서 섣부른 변경을 유도할 수 있다. 그래서 threshold adaptor가 중요하다. 규칙은 고정 교리로 머물지 않고 운영 데이터에 의해 후퇴하거나 강화되어야 한다. 이 논문에서 step_fuse가 비활성화된 사례는 그 점을 잘 보여 준다.

7.5 기존 위키 문맥과의 연결: Shepherd, TRACE, Bootstrapped Monitoring

이전에 정리한 Shepherd 논문은 agent execution trace를 typed effect stream으로 보존하고, meta-agent가 그 trace를 fork, replay, merge할 수 있게 하는 runtime substrate를 제안했다. Agent Genome은 Shepherd 같은 trace substrate 위에서 돌 수 있는 가벼운 분석 계층으로 볼 수 있다. Shepherd가 “실행을 되돌리고 여러 continuation을 시험할 수 있는 구조”를 만든다면, Base Sequence Analysis는 “어떤 continuation이 위험해 보이는지”를 빠르게 판별하는 feature를 제공한다.

TRACE 논문과의 연결도 분명하다. TRACE는 사용자의 correction을 runtime check로 컴파일해 coding agent가 같은 위반을 반복하지 않게 한다. Agent Genome은 correction의 출발점을 사용자 지시에만 의존하지 않고 행동 통계에서 찾는다. 예를 들어 사용자가 “수정 후 테스트해”라고 매번 말하기 전에, 시스템이 E streak 뒤 V 부재를 감지해 검증 prompt를 넣는다. 두 접근을 합치면 사람의 명시적 correction과 로그 기반 자동 correction이 같은 rule registry 안에 들어갈 수 있다.

Bootstrapped Monitoring과 비교하면 감시 표면이 다르다. Bootstrapped Monitoring은 transparent reasoning을 노출하는 monitor를 trusted model이 감사하는 AI control protocol에 가깝다. Agent Genome은 reasoning trace 대신 행동 trace를 본다. reasoning이 공개되지 않는 모델이나, reasoning을 공개하면 보안·프라이버시 문제가 생기는 환경에서는 행동 trace 기반 감시가 더 배포하기 쉽다. 반대로 행동 trace만으로는 의도와 의미를 충분히 알 수 없으므로, 두 감시 표면을 함께 쓰는 구성이 더 강할 수 있다.

provenance-aware evaluation은 여기서 하위 증거 계층이 된다. Base sequence가 “X-E-E-V”라고 말해도, 어떤 파일을 읽었고 어떤 patch를 썼으며 어떤 테스트가 통과했는지 없으면 평가가 공허해진다. 따라서 좋은 agent governance는 base sequence, tool metadata, artifact hash, test evidence, human approval을 함께 저장해야 한다. Base sequence는 그중에서도 빠르게 aggregate 가능한 요약 키 역할을 한다.

이 연결은 리뷰 작성이나 블로그 운영 같은 장문 자동화에도 적용된다. 초안 작성 에이전트가 자료 수집만 반복하고 본문 작성으로 넘어가지 않는지, 작성 뒤 검증을 수행했는지, 검증 실패 후 수정이 이어졌는지를 XEPV로 볼 수 있다. 현재 논문 리뷰 자동화 파이프라인에서도 Stage 1 초안, Stage 2 검증, Stage 3 발행이 분리되어 있는데, 각 단계의 tool trace를 base sequence로 남기면 실패 원인을 더 빨리 찾을 수 있다.

다만 위키 문맥과 연결할수록 privacy 요구도 커진다. Shepherd식 trace는 매우 자세하고, TRACE식 correction은 사용자 선호와 작업 규칙을 담으며, Base Sequence는 행동 리듬을 담는다. 세 정보를 모두 저장하면 운영 품질은 좋아지지만, 사용자와 조직의 업무 패턴도 더 잘 드러난다. 따라서 향후 연구는 sequence-level governance와 trace minimization을 함께 설계해야 한다. 어떤 정보는 로컬에만 두고, 어떤 정보만 집계 통계로 공유할지 정하는 정책이 필요하다.

7.6 더 강한 검증 실험을 위한 설계 제안

이 논문을 다음 단계로 밀어 올리려면 세 종류의 검증이 필요하다. 첫째는 동일 task 재실행이다. 같은 입력과 같은 도구 환경에서 Governor on/off를 나누어, 성공률과 비용 차이를 직접 비교한다. 둘째는 prefix intervention이다. P-X-P나 긴 X-run이 실제로 감지된 순간에만 randomization을 걸어, intervention이 다음 행동 분포를 바꾸는지 본다. 셋째는 cross-domain replication이다. 코딩, 리서치, 데이터 정리, 브라우저 조작처럼 서로 다른 agent task에서 어떤 base motif가 반복되는지 비교한다.

prefix intervention은 특히 중요하다. 전체 작업 단위 A/B는 task difficulty의 영향을 크게 받는다. 반면 같은 위험 prefix가 나온 순간을 기준으로 비교하면, 적어도 “이미 특정 행동 상태에 도달한 실행” 안에서 개입 효과를 볼 수 있다. outcome과 함께 다음 base가 X에서 E나 V로 이동했는지, switchRate가 낮아졌는지, token burn rate가 줄었는지도 함께 측정해야 한다. 그렇게 해야 Governor가 실제 행동을 바꿨는지 확인할 수 있다.

cross-domain replication에서는 base alphabet을 유지하면서 domain tag를 추가하는 방식이 적합해 보인다. coding task의 E는 file edit, command execution, dependency install로 나눌 수 있고, research task의 X는 search, source read, citation verification으로 나눌 수 있다. 하지만 상위 X/E/P/V를 그대로 보존하면 서로 다른 domain의 공통 신호를 잃지 않는다. 이 계층형 encoding은 고차 motif를 학습할 때도 데이터 희소성을 줄여 준다.

또 하나의 좋은 실험은 human-review alignment다. 사람이 “이 trace는 불안하다”고 판단한 실행과 base sequence 위험 점수가 얼마나 맞는지 비교할 수 있다. 사람이 보는 불안정성에는 맥락이 포함되고, base sequence는 행동 구조만 본다. 둘 사이가 어긋나는 사례는 taxonomy 개선에 도움이 된다. 예를 들어 사람이 안전하다고 보는 긴 탐색을 x_brake가 자주 막는다면, task context나 evidence coverage feature가 추가되어야 한다.

마지막으로 공개 dataset 설계가 필요하다. 원본 trace를 그대로 공개하기 어렵다면, base sequence, task category, anonymized outcome, length bucket, token bucket, intervention flag 정도만 공유하는 경량 benchmark를 만들 수 있다. 이 데이터는 고차 n-gram의 통계력을 높이고, 모델별 행동 fingerprint를 비교하는 데 쓸 수 있다. 다만 사용자 업무 패턴 노출을 막기 위해 rare sequence suppression과 time aggregation은 기본으로 들어가야 한다.

7.7 base sequence를 평가 지표로 쓸 때의 주의점

Base sequence를 새로운 leaderboard 지표로 바로 쓰는 것도 조심해야 한다. 어떤 시스템은 설계상 P를 노출하지 않고, 어떤 시스템은 모든 shell command를 E로 기록하며, 어떤 시스템은 테스트 명령을 V로 분리하지 못할 수 있다. 이런 차이를 무시하면 모델 성능 차이와 runtime instrumentation 차이가 섞인다. 따라서 공개 비교에서는 adapter specification, base classification precedence, ambiguous action 처리 규칙을 함께 제출해야 한다.

또한 base sequence는 outcome label의 품질에 민감하다. 성공과 실패가 자동 judge로 판정되면 judge 오류가 pattern mining에 그대로 들어간다. 특히 부분 성공, 사용자가 수동으로 보정한 성공, 외부 API 장애로 인한 실패는 같은 binary label 안에 섞일 수 있다. 논문이 제안한 방식이 더 넓게 쓰이려면 success label을 task completion, artifact validity, user acceptance, post-hoc verification으로 나눠 기록하는 편이 좋다.

마지막으로 좋은 행동 패턴은 task difficulty와 함께 해석되어야 한다. 쉬운 작업은 짧은 E-V로 끝나고, 어려운 작업은 긴 X-E-V 순환을 요구한다. 따라서 Governor는 전역 threshold만으로 완성되기 어렵다. task type, expected artifact count, allowed side effect, 검증 명령의 비용을 함께 넣으면 같은 XEPV 문자열도 더 정확히 읽을 수 있다. 이 방향은 단순한 sequence mining을 작업 맥락이 있는 runtime governance로 확장하는 단계다.

8. 내 해석: 약점과 후속 제안

나는 이 논문에서 가장 설득력 있는 부분이 행동 로그를 작은 언어로 압축한 뒤 운영 규칙으로 되돌리는 루프라고 본다. 특히 Shepherd의 typed effect execution trace가 실행을 fork/replay 가능한 구조로 만든다면, Agent Genome의 Base Sequence는 그 trace 위에서 빠르게 계산 가능한 행동 요약을 제공한다. TRACE가 사용자 correction을 runtime enforcement로 컴파일했던 흐름과도 연결된다. 다만 약점도 여기에서 나온다. 현재 논문은 P-X-P와 낮은 $E o V$를 강한 운영 신호로 제시하지만, 자연 배포 전후 비교와 상관분석만으로는 개입의 인과 효과를 충분히 분리하지 못한다. 어려운 작업이 P-X-P를 만들었는지, P-X-P가 작업을 실패로 밀었는지, Governor가 실제로 위험 prefix를 바꿨는지는 더 촘촘한 counterfactual 설계가 필요하다.

내가 이 연구를 확장한다면 먼저 prefix-level randomized intervention을 붙일 것 같다. 동일한 위험 prefix가 감지되었을 때 일부 실행에는 Governor prompt를 넣고, 일부 실행에는 넣지 않거나 약한 중립 메시지만 넣는다. 그리고 success와 함께 다음 3~5 base의 분포가 어떻게 바뀌는지, token cost가 어디서 줄었는지, 최종 산출물 품질이 유지되는지 함께 본다. 이렇게 하면 Governor가 단지 쉬운 작업에 더 자주 trigger된 것인지, 실제로 P-X-P나 긴 X-run을 E/V 쪽으로 밀어낸 것인지 분리할 수 있다. 더 나아가 Shepherd식 replay substrate와 결합하면 같은 prefix에서 여러 intervention prompt를 branch로 돌려 보고, 가장 비용 대비 효과가 큰 규칙을 선택하는 실험도 가능하다.

또 하나 주목할 점은 이 논문이 “에이전트 거버넌스”를 고수준 정책 문서로 끝나지 않고 실행 중 상태 변수의 문제로 낮춘다는 점이다. 많은 조직은 에이전트 사용 정책을 권한, 승인, 감사 로그, 금지 행동 목록으로 작성한다. Agent Genome은 그 아래 계층에서 에이전트가 지금 탐색 루프에 빠졌는지, 검증 없이 실행만 반복하는지, 뒤늦게 재계획을 남발하는지를 감지한다. 이 레이어가 실제 제품에 붙으면 사람 검수자는 모든 로그를 읽는 대신 “왜 이 실행이 중단되었고 어떤 행동 신호가 누적되었는가”를 볼 수 있다. 그 설명 가능성이 provenance-aware evaluation과 만나는 지점이다.

후속 연구에서는 base alphabet을 무작정 늘리기보다, 현재 4글자 체계 위에 task domain별 보조 속성을 얹는 방식이 좋아 보인다. 예를 들어 coding agent에서는 E를 edit, install, run command로 세분화하고, research agent에서는 X를 retrieval, source validation, citation check로 나눌 수 있다. 하지만 기본 X/E/P/V를 유지하면 시스템 간 비교 가능성을 잃지 않는다. 내가 운영 시스템에 적용한다면, 기본 base sequence를 모든 에이전트에서 공통으로 저장하고, domain-specific tag는 별도 column으로 붙여 causal analysis와 privacy masking을 모두 쉽게 만들 것 같다.

9. 결론: 에이전트 운영을 sequence governance로 옮기는 시도

Your Agent Has a Genome은 에이전트 평가와 운영 통제 사이의 간격을 좁히는 논문이다. 저자는 LLM-powered autonomous agent의 실행을 X/E/P/V 문자열로 압축하고, 이 문자열에서 실패와 연결된 n-gram, 전이 확률, feature correlation을 찾아낸다. 가장 중요한 발견은 P-X-P가 전역 성공률보다 10.4%p 낮은 고위험 패턴이고, P_ratio가 가장 강한 음의 예측 변수이며, $E o V$ 전이가 2.1%에 불과하다는 점이다.

이 분석은 Governor라는 런타임 개입 시스템으로 이어진다. Governor는 rule engine, statistical accumulator, chi-square threshold adaptor를 결합해 탐색 루프, 과도한 방향 전환, 검증 누락, 후반 재계획 같은 행동 신호에 반응한다. 자연 배포 전후 비교에서는 성공률 +6.2%p, 평균 토큰 -44%라는 결과를 보고한다. 인과성은 아직 조심스럽지만, 에이전트 runtime에 매우 가벼운 sequence-level governor를 붙이는 방식이 비용과 성공률을 동시에 다룰 수 있음을 보여 준다.

SWE-agent 검증은 논문의 일반화 주장을 어느 정도 지지한다. DunCrew에서 보인 P-X-P 자체가 그대로 반복되지는 않지만, 해결된 SWE-agent trajectory는 실행 뒤 검증 전이가 높고 탐색 self-loop가 낮다. 즉 구체적인 motif는 시스템마다 달라져도, 탐색 통제와 검증 빈도는 여러 agent framework에서 중요한 행동 축으로 보인다. 이 점은 앞으로 agent benchmark가 final answer score와 pass rate를 넘어, 실행 문자열과 행동 fingerprint를 함께 보고해야 함을 시사한다.

종합하면 이 논문은 에이전트 안전과 효율을 모델 내부 해석만으로 풀기보다, 런타임 행동의 압축 표현에서 시작한다. 그 접근은 구현하기 쉽고, 비용이 낮으며, 기존 로그 인프라와 잘 맞는다. 한계는 데이터 규모, 자연 배포 비교의 인과성, adapter 설계 편차다. 하지만 trace를 남기고, base sequence를 계산하고, 위험 prefix에서 가벼운 교정 prompt를 넣는 전체 흐름은 실제 에이전트 제품에 곧바로 실험해 볼 만한 구체성을 갖고 있다.

10. 요약 정리: Base Sequence Analysis가 남기는 체크포인트

• Base Sequence Analysis는 에이전트 실행을 Explore(X), Execute(E), Plan(P), Verify(V)의 네 글자 문자열로 압축해 n-gram과 전이 확률을 계산한다.
• DunCrew 347개 production trace에서 전체 base 분포는 X 46.6%, E 37.5%, P 12.6%, V 3.3%로, 검증 행동이 매우 낮게 관찰된다.
• P-X-P는 성공률 83.3%로 전역 기준보다 10.4%p 낮은 유일한 통계적 고위험 trigram으로 보고된다.
• $E o V$ 전이 확률은 2.1%에 불과해, 실행 뒤 결과 확인이 agent workflow에서 체계적으로 부족하다는 신호를 준다.
• Governor는 rule engine, statistical accumulator, chi-square threshold adaptor를 결합해 위험 prefix에서 zero LLM overhead로 교정 prompt를 삽입한다.
• 자연 배포 전후 비교에서 Governor는 성공률을 88.1%에서 94.3%로 높이고 평균 토큰 사용량을 275K에서 154K로 줄였다고 보고한다.
• SWE-agent 2,000개 trajectory 검증에서는 해결된 작업이 더 높은 Verify ratio와 낮은 exploration spiral을 보이며, 일부 행동 신호가 시스템을 넘어 반복됨을 보여 준다.
• 가장 큰 한계는 자연 배포 비교의 인과성, 작은 DunCrew trace 규모, adapter별 행동 분류 편차이며, 후속 연구에는 prefix-level randomized intervention이 필요하다.
• 이전의 Shepherd, TRACE, provenance-aware evaluation 흐름과 연결하면, Base Sequence는 실행 증거 위에 올라가는 경량 행동 거버넌스 계층으로 볼 수 있다.