LLM 에이전트의 도구 반환 가정을 RECEIPT가 시스템 콜로 고친다

무엇인가

이 논문은 LLM 에이전트가 웹 서비스 운영을 CLI로 수행할 때 암묵적으로 가정하는 반환 가정을 문제로 삼는다. 도구 호출이 제한 시간 안에 끝나고 요청한 동작까지 마쳤다고 믿는 가정인데, 많은 명령이 실제 동작 전에 확인, 암호, 편집기 입력 같은 질문을 한다. 하네스가 입력을 닫으면 프로그램은 EOF를 읽고 기본값으로 진행해 상태 0을 반환할 수 있고, 입력을 열어 두면 아무도 답하지 않아 시간 제한까지 기다린다. 저자들은 이를 거짓 반환과 거짓 성공으로 구분하고, 에이전트의 신뢰성이 LLM뿐 아니라 하네스가 무엇을 관찰하게 하는지에 달려 있다고 주장한다.

어떻게 동작하나

측정은 세 갈래다. Litmus는 77개 프로그램의 158개 질문 유발 명령을 닫힌 입력, 열린 파이프, 아무도 입력하지 않는 터미널에서 실행하고 요청 동작이 실제로 일어났는지 사후 검사한다. 닫힌 입력에서 18개, 11.5%가 요청 동작 없이 상태 0을 반환했고 docker system prune, rm -i, find -ok, tar -w 같은 명령이 동작을 건너뛰었다. 터미널에서는 거의 모든 명령이 멈췄고, 터미널이 없을 때 8개 하네스 중 7개가 입력을 닫았다. Claude Code는 GIT_EDITOR=true를 설정해 git rebase -i가 확인 없이 커밋을 합치는 사례도 보고한다.

무엇과 다른가

실제 사용 측정도 있다. 6명 개발자의 3개월 Claude Code 세션 107개에서 91,469개 도구 호출, 그중 52,953개 셸 호출을 모았고, 39,985개 주 에이전트 명령 중 16,922개가 웹 인프라 범주에 맞았다. 52,953개 셸 호출 중 81개가 시간 제한으로 끝났고, 두 주석자가 동의한 27개는 CI, 빌드, 백그라운드 작업 출력을 기다리려고 에이전트가 만든 폴링 루프였다. 에이전트는 프로세스 생존만 확인하는 명령도 2,910개 실행했다. 공개 에이전트 궤적 89,047개를 포함한 3개 코퍼스에서는 입력 대기가 1,345건 있었고 616건이 패키지 관리자나 git 같은 웹 운영 도구에서 발생했다. Corepack의 pnpm 다운로드 확인이 339건, git의 암호·호스트 키·사용자 이름·페이저 입력이 127건이었다. Terminal-Bench 2.0에서 재생한 123개 입력 대기 중 70개가 컨테이너에서 다시 대기했고, 입력을 닫으면 70개가 모두 끝나지만 41개가 상태 0을 반환했고 그중 12개는 명령의 일을 하지 않았다.

어떻게 쓰나

방법 RECEIPT는 에이전트와 프로그램을 바꾸지 않고 셸 명령을 감싼다. 1층은 입력을 열어 두되 답을 넣지 않고, 0.1초마다 프로세스 트리의 각 스레드에 대해 시스템 콜, 기다리는 디스크립터 집합, CPU 틱을 샘플링한다. read, poll, epoll_wait 같은 입력 계열 시스템 콜이 RECEIPT가 제어하는 입력 파이프나 터미널을 기다리고, 외부에서 읽을 수 있게 만들 수 있는 소켓·파이프는 기다리지 않을 때 후보로 본다. 1초 동안 출력이 없고 CPU 틱이 5 이하이면 확인된 대기로 본다. 터미널이면 line discipline과 화면 모드로 일반 입력, 에코 없는 비밀 입력, 키 단위 입력, 전체 화면 입력을 구분한다. 영수증에는 프로그램 이름, 마지막 출력을 프롬프트로, 로컬 트리를 끝냈는지, 이전 효과가 미검증인지를 담는다.

전제와 한계

2층은 영속 터미널에서 입력, 중단, 보고의 순서를 고정한다. 송신자는 에이전트가 발행된 영수증을 모두 읽고, 막힌 판독기의 질문을 봤을 때만 키 입력을 보낸다. 질문이 아직 보이지 않으면 키 입력을 보류하고 질문과 함께 발행해 질문이 답보다 먼저 에이전트에 도달하게 한다. 관찰자는 전송 중인 입력이 없을 때만 중단하고, 확인된 대기라도 배치에 추가 입력이 예정돼 있지 않고 시스템 콜을 재확인한 뒤에만 신호를 보낸다. 3층은 이 규칙을 유한 상태 탐색기와 TLA+ TLC로 검증한다. 규칙이 없으면 7개 속성 중 5개가 깨지고, 규칙이 있으면 위반이 없으며 실제 tmux와 프로세스, LLM 없는 Docker 테스트 17건에서 금지된 순서 4개를 재현하고 규칙으로 통과시킨다.

평가는 Tripwire 25개 작업 쌍으로 한다. 각 쌍은 작업 문장과 검증기가 같고, 트랩 변형에서만 명령 옵션, 별칭, 설정 파일, git 편집기 중 하나가 달라져 질문이 요청 동작을 가로막는다. mini-SWE-agent는 15쌍, Terminus 2는 25쌍을 실행한다. RECEIPT 없이 닫힌 입력을 쓰는 mini-SWE-agent는 5개 LLM에서 거짓 성공이 가장 많았고, 사후 궤적 분류기는 10% 플래그 비율에서 34개 중 6개만 잡았다. 질문이 답을 받지 못하면 일반 터미널에서 토큰 사용이 통제군의 2.9배, 실행 시간이 2.6배가 됐다. 입력 연결은 8개 LLM 순위도 바꿔 Llama-3.3-70B가 닫힌 입력에서 7위, 일반 터미널에서 3위가 됐고 두 순위의 Kendall τb는 0.47이었다.

RECEIPT를 mini-SWE-agent에 끼우면 성공이 153에서 176으로 늘고 거짓 성공이 34에서 9로 줄었으며, 일반 터미널보다 토큰을 24.4% 덜 썼다. Litmus의 로컬 실행 가능한 리눅스 120개 대기 명령에서 보고율 85.0%, 거짓 양성 없이 중앙 보고 지연 1.1초를 기록했고, 텍스트 기반 베이스라인은 66.7%와 68.3%였다. 1초 워치독은 속도는 같지만 119개 통제군 중 82개를 종료했고 RECEIPT는 0개를 종료했다. Terminus 2에서는 25개 트랩 작업을 모두 완료했고, 네이티브는 17개, 영수증 없이 중단만 하는 변형은 20개를 완료했다. 상용 런타임에서는 셸 호출당 중앙값 0.54ms 이하로 검사했다.

개발자에게 의미는 분명하다. 에이전트가 docker prune, rm -i, git rebase -i, openssl passphrase처럼 질문을 던지는 CLI를 실행할 때 하네스의 입력 연결과 시간 제한이 성공 판정과 LLM 순위를 바꾼다. 벤치마크 운영자는 입력 연결을 고정하고 보고해야 하며, 에이전트 빌더는 LLM 교체 전에 도구 호출이 무엇을 했는지 관찰하게 해야 한다. 한계도 저자들이 밝힌 범위 안에 있다. RECEIPT는 셸 명령을 감싸 로컬 프로세스 트리를 관찰하고 중단도 로컬 트리에만 하며, 배포에서는 중단 없이 보고만 하는 모드가 있다. Litmus 보고율 85.0%는 15%의 대기를 놓칠 수 있음을 뜻하고, 검증은 25개 작업 쌍과 5~8개 LLM, 6명 개발자의 생산 로그에 한정된다. 입력 대기를 실행 전에 예측하는 WaitAtlas 실험도 평균 정밀도 0.477과 0.395에 그쳐 런타임 감지가 필요하다는 전제를 남긴다.