기술 요약: 컴파일 후 페이지 전환: 실행 가능한 SOP 프로그램 및 절차적 LLM 에이전트를 위한 역량 기반 런타임

1. 문제 정의

엔터프라이즈 환경(예: 은행, 클리닉)에 언어 에이전트를 배포하려면 표준 운영 절차(SOP)를 엄격히 준수해야 합니다. 이러한 SOP는 긴 호흡의 워크플로우, 조건부 분기, 안전이 중요한 거절 규칙을 특징으로 합니다. 현재의 지배적인 관행은 SOP를 비구조화된 텍스트 프롬프트("거주자 산문(resident prose)")로 취급하며, 이는 대화와 주의력을 경쟁하고 실행 가능한 구조를 제거합니다. 이는 특정 실패 모드로 이어집니다: 검증 체크 누락, 조기 행동 수행, 잘못된 거절 등이 발생합니다. SOPBench 벤치마크에서 상위 구성들조차 준수 표준을 충족하지 못하며, 오류율이 컴플라이언스 부서가 수용할 수 없는 수준에 이릅니다.

핵심 과제는 동적 대화에 필요한 유연성을 잃지 않으면서도, SOP를 정적인 텍스트에서 LLM이 따를 수 있는 실행 가능한 로직으로 변환하는 동시에, 안전 제약 조건이 모델을 하드 블로킹(사용자의 목표가 바뀔 때 복구 불가능한 오류를 유발할 수 있음)하지 않도록 보장하는 것입니다.

2. 방법론

저자들은 SOP의 **표현(representation)**과 그 **런타임 실행(runtime execution)**을 분리하는 2단계 아키텍처를 제안합니다.

2.1 오프라인 컴파일 (SOP-to-Program)

SOP를 자연어로 입력하는 대신, 오프라인의 결정론적 컴파일러(LLM-free)가 기계 판독 가능한 의존성 제약 조건을 2계층 의사코드 프로그램으로 변환합니다:

• 프로세스 함수(Process Functions): 사용자 목표당 하나의 함수.
• 규칙 서브루틴(Rule Subroutines): 각 제약 조건은 특정 검증 레시피 및 증거를 담은 반환 값 {holds, evidence}와 쌍을 이룹니다.
• 주요 변환 사항:
  • 상태 유지 서브루틴(Stateful Subroutines): 다회차(multi-turn) 제약 조건은 턴을 가로질러 지속됩니다.
  • 게이트 호이스팅(Gate Hoisting): 검증에 필요한 인증 게이트를 가드된 체크(guarded checks) 이전에 배치합니다.
  • 증거 규율(Evidence Discipline): 모든 판정은 특정 도구 증거와 연결됩니다; 증거 없이 판정을 내리지 않습니다.
  • 프레임 팩터링(Frame Factoring): 큰 그룹들을 명명된 함수로 모듈화합니다.
• 출력: 목표 행동이 실행되기 전, 요구된 결과가 거짓일 경우 fail 상태로 분기되는 구조화된 프로그램입니다.

2.2 온라인 프로그램 가이드(PG) 런타임

컴파일된 프로그램은 컨텍스트 윈도우를 관리하는 스택 기반 가상 머신에 의해 실행됩니다:

• 스택 페이징(Stack Paging): 런타임은 호출 스택, 커서 및 변수 저장소를 유지합니다. 전체 프로그램(약 10,000자) 대신 활성 프레임(active frame)(약 570자)만을 LLM의 컨텍스트로 페이징합니다.
• 실행 흐름: LLM은 의미적 실행자(semantic executor) 역할을 합니다. 대화하고, 도구 인수를 선택하며, 증거를 해석하고, 판정을 보고합니다. 심볼릭 런타임은 북키핑(스택 전환, 커서 이동, 변수 바인딩)을 처리합니다.
• 소프트 인포스먼트(Soft Enforcement): 런타임은 권한이 아닌 *주의력(attention)*을 관리합니다. 일탈은 가능하지만 스택 감사 추적(stack audit trail)을 통해 관찰 가능합니다. 이러한 유연성은 목표 변경을 허용하면서도, 모델이 로컬 프레임을 충실히 실행할 수 있는지에 의존합니다.

2.3 실험 설계

본 연구는 다양한 성능의 6개 모델에 대해 SOPBench(은행 도메인 및 기타 6개 도메인)에서 3개 암(arm) 설계를 사용합니다:

1. Offtext: 공식적으로 구절화된 SOP 텍스트 (베이스라인).
2. Flat: 모든 턴에 전체 컴파일된 프로그램 텍스트가 상주함 (표현 방식 격리).
3. PG: 스택 페이징 런타임으로 실행되는 컴파일된 프로그램 (런타임 효과 격리).
4. Full-Cursor (Ablation): 활성 프레임이 우선시되지만, 전체 프로그램이 그 아래에 유지됨 (활성 프레임의 현저성 vs 글로벌 가시성 격리).

3. 주요 기여

1. SOP-to-Program 컴파일러 및 스택 페이징 런타임: 절차를 실행 가능하고 감사 가능하게 만들어, 컨텍스트 부하를 턴당 약 10k에서 약 570자로 줄이면서 논리적 구조를 보존하는 시스템.
2. 역량 기반 속성 연구(Capability-Gated Attribution Study): 6개 모델, 7개 도메인 분석을 통해 이 접근 방식의 이점이 엄격하게 역량에 의존함을 입증.
3. 메커니즘 분리: 일반적인 북키핑, 활성 프레임의 현저성, 선택적 가시성의 분리 및 상태 재구성(state reconstruction)과 주의 밀도(attention density)에 대한 진단.
4. 배포 규칙: 실무적 가이드라인: "먼저 컴파일하십시오. 모델 수준의 규율 체크를 마친 후에만 활성 프레임 페이징을 활성화하십시오."

4. 결과

4.1 표현 vs. 런타임

• 컴파일 (Flat vs. Offtext): 컴파일된 표현은 성능을 크게 저해하지 않습니다. 공식 산문이 저조한 곳에서 상당한 이득(+1로 뱅크 도메인)을 얻습니다.
• 런타임 (PG vs. Flat): 런타임 효과는 **역량에 의해 결정(capability-gated)**됩니다.
  • 강한 모델: 두 개의 강한 모델(DeepSeek-V4-Flash 및 Qwen3.7-Plus)은 7개 도메인 전반에서 독립적이고 긍정적인 이득을 보였습니다 (PG 우위의 불일치 쌍 58:19 및 75:31). 뱅크 도메인에서 DeepSeek-V4-Flash는 86.4%(Flat)에서 92.8%(PG)로 향상되었으며, 100%의 거절 정확도를 기록했습니다.
  • 약한 모델: 약한 모델(예: GPT-4o-mini, Qwen2.5-7B)은 런타임에 의해 크게 저해되어 뱅크 도메인에서 14~26포인트 하락했습니다.

4.2 메커니즘 분석

• 활성 프레임 현저성(Active-Frame Salience): 전체 프로그램을 유지하되 활성 프레임을 강조하는 절제 실험(Full-Cursor)은 강한 모델의 거절 이득 대부분을 회복했습니다. 이는 주요 이점이 글로벌 컨텍스트를 숨기는 것이 아니라 현재 지침을 현저하게 만드는 데 있음을 시사합니다.
• 상태 규율 vs. 재구성:
  • 재구성: 약한 모델을 포함한 모든 모델은 명시적으로 조사될 때 상태를 재구성할 수 있습니다 (근접 천장 점수).
  • 규율: '게이트'는 자발적인 상태 규율입니다. 약한 모델은 목표 달성 후에도 과잉 검증을 하거나 체크를 계속하는 등 실패하는 반면(post-goal calls에서의 양의 $\Delta R^2$), 강한 모델은 자연스럽게 멈춥니다.
  • 주의(Attention): 강한 모델은 활성 프레임 크기에 비례하여 주의를 할당하는 반면, 약한 모델은 활성 프레임이 더 큰 컨텍스트의 일부일 때 주의를 과소 할당합니다.

4.3 콘텐츠 vs. 포맷

• 포맷: 공식 텍스트를 코드 포맷으로 재합성하는 것은 강한 모델에게는 도움이 되지만(+14.4 포인트), 약한 모델에게는 해가 됩니다(-12.8 포인트).
• 콘텐츠: 검증 레시피와 증거 규율을 추가하는 것은 강한 모델에게는 크게 도움이 되지만, 약한 모델에게는 유의미한 이득을 보여주지 않습니다.
• 결론: "코드" 포맷은 보편적으로 유익한 것이 아니라, 이미 구조화된 지침을 따를 수 있는 규율을 갖춘 모델을 위한 도구입니다.

5. 의의 및 주장

본 논문은 신뢰할 수 있는 SOP 준수 에이전트의 주요 장벽이 정보의 부족이 아니라, **표현(representation)**과 그 표현을 실행하는 **모델의 자발적 규율(spontaneous discipline)**이라고 주장합니다.

• "더 많은 스캐폴딩이 더 좋다"는 관점의 거부: 복잡한 런타임 가이드(페이징)를 약한 모델에 추가하면 성능이 저하된다는 결과는 이를 보여줍니다.
• 역량 게이트(The Capability Gate): PG 런타임의 효과는 상태 규율을 유지하는 모델의 능력에 의해 엄격히 제한됩니다. 이 시스템은 약한 모델을 "고치는" 것이 아니라, 강한 모델의 성능을 증폭시키고 약한 모델의 한계를 드러냅니다.
• 실무적 가이드:
  1. 먼저 컴파일하라: 구조를 개선하고 컨텍스트 노이즈를 줄이기 위해 SOP를 실행 가능한 의사코드로 변환하십시오.
  2. 규율을 확인하라: 모델이 런타임의 구조적 도움 없이도 지침을 따를 수 있는지 확인한 후에만 활성 프레임 페이징(런타임 가이드)을 활성화하십시오.
  3. 소프트 인포스먼트: 시스템은 동적인 사용자 상호작용을 위한 유연성을 보존하기 위해 하드 블로킹보다는 관찰 가능성(감사 추적)에 의존합니다.

저자들은 이 접근 방식이 강한 모델에 대해 뱅크 도메인에서 92.8%의 통과율과 100%의 거절 정확도를 달s성하지만, 이것이 보편적인 해결책은 아니라고 결론짓습니다. 이를 피하기 위해서는 배포 전 "모델 수준의 규율 체크"가 필요합니다.