소스 의도와 실행 상태를 보존하는 터미널 작업 합성

왜 중요한가

터미널 에이전트 학습에는 실행 가능한 감독 데이터가 필요하지만, 지시문·환경·풀이·검증기가 서로 다른 가정을 가지면 작업 자체가 풀리지 않거나 올바른 풀이를 실패로 판정합니다. FACET은 원천 skill의 목표와 상태 전이를 보존하고 실제 컨테이너 상태를 모든 산출물의 공통 기준으로 삼아, 1.2K개의 성공 trajectory만으로 Qwen3.5-4B·9B·27B의 Terminal-Bench 2.1 성능을 각각 7.12·8.24·6.75포인트 높였습니다.

핵심 기여

Agent skill을 조합한 시나리오 재구성

FACET은 서로 관련된 skill을 곧바로 최종 작업으로 변환하지 않고, 각 skill의 능력·도구·입출력·전제조건·관찰 가능한 효과를 추출합니다. 이후 공통 사용자 목표를 기준으로 skill 간 의존성, 중간 산출물, 상태 전이, 절차적 제약을 복원해 정보가 풍부한 compositional scenario를 구성합니다. 이 과정은 단일 skill의 표면적 기능만 사용하는 얕은 workflow를 피하고 여러 작업이 연결된 장기 터미널 trajectory를 만드는 기반이 됩니다.

실행 상태를 기준으로 한 산출물 정렬

환경을 먼저 빌드하고 초기화한 뒤 실제 컨테이너 상태를 읽어 지시문, 기준 풀이, 검증기를 순차적으로 생성합니다. 지시문은 실제 파일과 서비스에서 요구사항을 만들고, 풀이는 같은 상태를 직접 확인하며, 검증기는 풀이 실행 전후의 관찰 가능한 상태를 바탕으로 구성합니다. 이에 따라 파일명·경로·포트·패키지·스키마가 환경 수정으로 바뀌어도 세 산출물이 서로 다른 환경 가정을 유지하는 문제가 줄어듭니다.

실패 산출물만 고치는 검증 파이프라인

FACET은 환경 빌드 성공, 초기 상태에서 검증기 미통과, 깨끗한 상태에서 기준 풀이 실행, 최종 상태에서 검증기 통과를 모두 요구합니다. 실패 trace를 라우팅해 빌드 실패는 환경, 풀이 실행 실패는 solution, 테스트 수집·assertion 문제는 verifier, 지시문과 상태의 불일치는 원인에 따라 instruction 또는 environment에 배정합니다. 환경에는 최대 세 번, 전체 task에는 최대 다섯 번의 repair iteration을 허용해 이미 유효한 구성요소를 보존합니다.

핵심 아이디어 이해하기

일반적인 터미널 에이전트 작업은 자연어 답변만 만드는 문제가 아니라, 초기 컨테이너 상태에서 명령을 실행해 파일과 서비스 상태를 바꾸고 최종 조건을 만족하는 문제입니다. 따라서 하나의 작업은 지시문, 초기 환경, 기준 풀이, 실행 검증기가 함께 맞물려야 합니다. 지시문이 요구하는 파일이 환경에 없거나 검증기가 풀이가 만들 수 없는 상태를 검사하면 개별 문장이 그럴듯해도 전체 작업은 실패합니다.

기존의 다단계 합성에서는 원천 skill을 짧은 task description으로 연속 변환하면서 목표, 의존성, 중간 상태, 입력·출력 계약이 압축될 수 있습니다. FACET은 먼저 skill 분석과 scenario 탐색을 거쳐 관련 skill이 하나의 사용자 목표에 어떻게 기여하는지 연결합니다. 그 뒤 workflow의 중간 산출물과 상태 전이를 복원하고, 구체적인 자원·형식·제약·성공 조건을 추가해 최종 시나리오의 정보량을 유지합니다.

재구성된 시나리오는 목표, 맥락, capability, state, input/output 및 tool이라는 다섯 차원으로 분리됩니다. 이 구조는 사용자가 원하는 결과와 실행에 필요한 파일·경로·서비스를 한 workflow 안에서 연결하며, 기준 풀이에는 setup부터 중간 산출물과 상태 변화까지 기록합니다. 지시문은 시나리오와 기준 풀이에서 만들고, 이후 실제로 초기화된 컨테이너를 읽어 파일·스키마·의존성이 존재하는지 확인합니다.

검증기는 단순히 특정 명령 문자열을 비교하지 않고, 기준 풀이 실행 전후의 상태에서 요구사항이 관찰되는지를 검사합니다. 초기 상태에서는 통과하지 않고 기준 풀이가 실행된 최종 상태에서는 통과해야 하므로, 작업은 빌드 가능성·비자명한 초기 상태·실행 가능성·최종 검증을 동시에 만족해야 합니다. 이 방식은 주 workflow를 수행했지만 필드 하나나 보조 산출물 하나를 빠뜨린 near-success도 개별 검사 실패로 구분합니다.

방법론

Stage 1은 OpenClaw, ClawHub, GitHub에서 공개 skill package를 수집하고, 위험한 지시·비공개 사이트나 자원 의존·판독 불가·비실행 가능·중복 기록을 제거합니다. 보존된 skill은 설명, 필요 도구, 입력·출력, 절차 단계, 출처를 포함한 구조화 record로 정규화되며 71K개가 넘는 유효 skill을 확보합니다. 각 skill에서 가능한 적용 맥락, 사용자 목표, 초기 상태, 최종 상태를 추출하고 embedding 기반 유사도 검색과 model-based judge를 사용해 관련성·상호보완성·비중복성·터미널 workflow 실행 가능성을 갖춘 scenario–skill pair만 남깁니다.

Stage 2는 선택된 skill을 다섯 모듈로 재구성합니다. Skill analysis가 capability와 전제조건을 찾고, scenario exploration이 공통 목표에 맞는 적용 맥락을 만들며, association and filtering이 무관한 조합을 제거합니다. Evolution and recovery는 여러 capability를 workflow로 배열하면서 cross-skill dependency와 중간 상태를 복원하고, information expansion은 자원·파일 형식·제약·관찰 가능한 성공 조건을 구체화합니다.

재구성 결과는 goal, context, capability, state, io-tool의 다섯 차원으로 표현한 뒤 하나의 자연어 scenario로 통합됩니다. 기준 solution reference에는 setup action, 실행 순서, 중간 artifact, 상태 전이, 핵심 단계를 담고, instruction reference에는 목표·입력·출력·deliverable·제약을 담습니다. 두 reference 사이에서 초기 상태와 목표 결과가 같고, 지시문 요구사항이 풀이 workflow로 지원되며, 요구 효과가 최종 상태에서 관찰되는지 consistency-alignment model이 확인합니다.

Stage 3은 reconstructed specification을 바탕으로 환경 manifest를 만들고 디렉터리, 파일, 서비스, 의존성, 예상 속성을 restricted base image 안에 materialize합니다. 공개 자원은 필요한 경우 shell과 Python으로 내려받아 변환한 뒤 build context에 localize하고, fixture에는 추가 record·metadata·distractor·cross-file relation을 넣을 수 있지만 원래 schema와 task semantics는 유지합니다. 빌드나 초기화가 실패하면 failure trace와 원래 specification을 함께 사용해 최대 세 번 환경을 repair하고, 성공한 실제 상태를 읽은 뒤 instruction, solution, verifier를 순차 생성합니다.

완성된 bundle은 environment, solution, tests, instruction.md, task.toml로 패키징됩니다. 깨끗한 초기 상태에서 환경 빌드와 초기화를 수행하고, verifier가 초기 상태에서 통과하지 않는지, reference solution이 실행되는지, 최종 상태에서 verifier가 통과하는지를 차례로 검사합니다. 실패 원인을 trace에서 찾아 해당 artifact만 고친 뒤 같은 초기 상태에서 다시 평가하며, 최대 다섯 번의 task-level repair 이후에도 유효하지 않으면 후보를 버립니다.

주요 결과

FACET은 약 6K개의 validated task에서 Terminus-2와 DeepSeek-V4-Pro를 이용해 rollout을 수집하고, 완전한 성공 trajectory 1.2K개를 supervised fine-tuning에 사용했습니다. 데이터셋에는 6,078개 task와 task당 평균 22.77개의 executable test가 있어 Terminal-Lego의 16.60, Nemotron-Terminal의 6.18, Tmax의 3.29보다 많은 독립 검사 지점을 갖습니다. 평균 trajectory 길이는 11.86 turns로, 1.2K trajectory라는 작은 규모에도 여러 의존 작업이 이어지는 장기 상호작용을 포함합니다.

Terminal-Bench 2.1에서 Qwen3.5-4B는 17.60에서 24.72로 7.12포인트, Qwen3.5-9B는 27.34에서 35.58로 8.24포인트, Qwen3.5-27B는 40.82에서 47.57로 6.75포인트 상승했습니다. 4B 모델의 상대 개선폭은 40.5%였고, 9B 모델의 절대 개선폭이 가장 컸습니다. Fine-tuned 27B 모델의 47.57은 같은 평가 설정의 Qwen3.5-397B 49.06보다 1.49포인트 낮아, 약 15배 작은 모델에서도 대부분의 격차를 좁혔습니다.

교사 rollout에서는 개별 verifier check의 89.40%가 충족됐지만 전체 task 성공률은 20.94%였고, 실패 rollout의 54.00%는 한두 개 검사만 실패했습니다. 이는 주 artifact나 핵심 workflow를 완료한 뒤 잘못된 field, 누락된 보조 deliverable, 제약 위반 하나 때문에 전체 task가 실패하는 경우가 많다는 뜻입니다. 같은 100개 scenario–skill pair에서 Forward 순서의 초기 유효율은 46.5%로 Reverse 24.2%와 Joint 37.5%보다 높았고, repair 후 최종 yield도 Forward 83/100, Reverse 63/100, Joint 65/100으로 가장 높았습니다.

기술 상세

FACET이 합성하는 task bundle은 instruction, environment specification, reference solution, executable verifier, runtime metadata로 구성됩니다. 환경 specification을 초기화하면 초기 상태가 만들어지고, reference solution을 실행하면 최종 상태 또는 실행 실패가 생성되며, verifier는 각 상태에서 통과 여부를 반환합니다. 최종 acceptance는 환경 빌드 성공, 초기 상태에서 verifier 미통과, reference solution 실행 성공, 최종 상태에서 verifier 통과를 모두 요구합니다.

Stage 2의 핵심은 skill 조합을 곧바로 산출물로 번역하지 않는 데 있습니다. 각 skill에서 capability, tool, input, output, precondition, observable effect를 추출한 뒤 scenario를 탐색하고, association filtering으로 실제 공통 목표에 기여하는 조합을 선택합니다. Evolution and recovery가 cross-skill dependency와 intermediate artifact를 workflow에 연결하고 information expansion이 형식·자원·제약·성공 조건을 채워 다섯 차원 representation과 완전한 scenario를 만듭니다.

Stage 3에서는 environment manifest와 asset materialization을 분리합니다. Manifest가 필요한 경로·파일·서비스·의존성을 먼저 고정하고, materialization 단계가 공개 자원을 내려받거나 변환하며 text와 binary fixture를 생성한 뒤 self-contained build context에 저장합니다. 빌드 오류, package 누락, malformed fixture, download 실패, service failure는 trace로 반환되고, repair agent는 원래 specification을 유지하면서 해당 실패를 수정합니다.

산출물 생성 순서는 environment 구축 후 instruction에서 solution으로, solution에서 verifier로 이어지는 Forward입니다. Verifier를 solution보다 먼저 생성하는 Reverse에서는 cross-artifact contract mismatch가 실패의 56.5%를 차지했지만, Forward에서는 이 유형이 37.7%였습니다. 동일한 88개 pair의 paired comparison에서 Forward가 Reverse보다 성공한 pair는 29개, 반대 방향은 9개였고 two-sided exact sign test의 p값은 0.0017로, solution을 먼저 관찰하는 순서가 solution–verifier alignment에 유리하다는 근거가 나왔습니다.

실무 활용

공개 skill package에서 실행 가능한 터미널 학습 task를 만들 때, 환경과 산출물을 별도로 생성한 뒤 서로 맞추는 대신 실제 container state를 공통 기준으로 삼을 수 있습니다. GitHub repository와 Harbor 형식의 environment, solution, tests, instruction.md, task.toml 패키징을 함께 활용하면 실행 기반 검증과 targeted repair를 포함한 데이터 생성 pipeline으로 연결할 수 있습니다.

여러 공개 agent skill을 하나의 장기 터미널 workflow와 학습 trajectory로 조합하는 데이터 합성
Docker 기반 파일·서비스·의존성이 필요한 터미널 task의 환경 materialization과 초기화 검증
지시문·기준 풀이·검증기를 동일한 컨테이너 상태에 맞춰 생성하는 cross-artifact consistency 확보
실패 trace에 따라 환경·풀이·검증기 중 원인 artifact만 repair하는 task 품질 관리

코드 공개 여부: 공개

코드 저장소 보기

키워드

FACET(실행 가능한 터미널 작업 합성 프레임워크)Terminal Agent(터미널 에이전트)Executable Supervision(실행 가능한 감독 신호)Cross-artifact Consistency(산출물 간 일관성)Container State(컨테이너 상태)Terminal-Bench 2.1(터미널 에이전트 벤치마크)Qwen3.5(언어 모델)

용어 해설

터미널 에이전트(Terminal Agent): — 명령줄 환경에서 파일 조작, 의존성 설치, 도구 실행, 오류 복구를 수행하는 언어 모델 기반 에이전트입니다. 텍스트 응답의 plausibility가 아니라 변화하는 실행 상태를 올바르게 조작하고 최종 검증을 통과하는 능력이 핵심입니다.
실행 가능한 감독 신호(Executable Supervision): — 에이전트의 행동 결과를 실제 환경에서 실행하고 검증해 학습에 활용하는 감독 방식입니다. 성공 여부뿐 아니라 파일 상태, 서비스 동작, 출력 형식 같은 실행 가능한 조건을 신호로 제공해 터미널 작업의 장기 절차 학습을 지원합니다.
산출물 간 일관성(Cross-artifact Consistency): — 사용자 지시문, 초기 환경, 기준 풀이, 실행 검증기가 동일한 요구사항과 상태를 참조하는 성질입니다. 한 산출물이 가리키는 파일이나 스키마가 다른 산출물에 없으면 작업이 풀리지 않거나 잘못된 평가가 발생하므로 전체 작업의 유효성에 직접 영향을 줍니다.
컨테이너 상태(Container State): — 컨테이너를 빌드하고 초기화한 뒤 실제로 존재하는 파일, 서비스, 의존성, 경로, 포트, 입력 스키마의 상태입니다. FACET은 이 상태를 지시문·풀이·검증기 생성의 공통 기준으로 사용해 서로 다른 암묵적 환경 버전에서 산출물이 만들어지는 문제를 줄입니다.
실행 기반 검증(Execution-based Validation): — 환경을 깨끗한 초기 상태에서 빌드하고, 기준 풀이를 실행한 뒤, 최종 상태에서 검증기가 통과하는지 확인하는 절차입니다. 실패 trace를 바탕으로 환경·풀이·검증기·지시문 중 원인 산출물만 고쳐 유효한 구성요소의 불필요한 재생성을 피합니다.

소스 의도와 실행 상태를 보존하는 터미널 작업 합성

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

LLM 에이전트 Skill의 작동 원리와 실패 경계

Repo-To-Skill: GitHub 저장소를 AI4AI Skill로 증류하기

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

실무 활용

키워드

관련 토론

댓글

관련 기사

LLM 에이전트 Skill의 작동 원리와 실패 경계

Repo-To-Skill: GitHub 저장소를 AI4AI Skill로 증류하기