에이전트 대화 기록에서 CLI 뒤에 붙는 파이프 패턴을 세어 보면 내 도구에 빠진 옵션이 보인다고 Allos AI 발표자가 설명합니다 | DAKER 커뮤니티

AI Engineer 채널에 2026년 11월 10일 올라온 발표 「Your Agent Hates Your CLI」에서 Allos AI의 Ayush Bhardwaj는 에이전트가 도구 출력 뒤에 직접 붙이는 head, tail, grep 같은 파이프가 사실상 버그 리포트라고 설명했습니다. 에이전트는 불편을 신고하지 않고 도구 바깥에 작은 프로그램을 써서 우회하기 때문에, 대화 기록에서 같은 우회가 반복되는 곳을 찾으면 도구에 무엇이 빠졌는지 알 수 있다는 주장입니다. 이 글은 발표 영상의 영어 자막을 직접 읽고 정리했으며, 숫자와 사례는 모두 발표자가 말한 내용입니다.

Claude Code, Codex, Cursor가 출력을 잘라 읽은 세 장면

발표자는 자신의 실제 대화 기록에서 세 가지 호출을 보여 주었습니다. Claude Code는 문서 페이지에서 설정 하나만 필요했는데 페이지 전체를 내려받은 뒤 40줄만 남겼습니다. Codex는 취약한 의존성이 몇 개인지 알고 싶어서 JSON 보고서 전체를 받은 뒤 합계가 있을 것으로 짐작한 마지막 40줄만 남겼습니다. Cursor는 테스트를 돌려 실패 하나를 찾은 뒤 마지막 80줄만 남겼습니다.

세 번의 자르기는 모두 답이 출력의 어디쯤 있을 것이라는 가정을 담고 있었습니다. 발표자는 파이프 한 번은 별 의미가 없지만 같은 파이프가 계속 반복되면 도구에 빠진 기능을 가리킨다고 말했습니다. 발표자가 든 사례 가운데 Claude Code 호출은 에이전트가 이 발표 자체를 검토하던 중에 나온 것이라고 합니다.

Sanity MCP 서버에는 2만 에이전트가 쓰고도 버그 리포트가 0건이었습니다

발표자는 콘텐츠 플랫폼 Sanity가 6월에 쓴 MCP 서버 회고를 인용했습니다. 출시 이후 2만 개가 넘는 에이전트가 약 300만 번 도구를 호출했는데도 버그 리포트는 한 건도 없었다고 합니다. 그래서 Sanity는 피드백을 남기는 도구를 따로 만들어 배포했고, 에이전트가 불만을 적을 곳이 생기자 무엇이 문제인지 말하기 시작했다는 설명입니다.

발표자의 요지는 피드백 도구가 없어도 시작할 수 있다는 것입니다. 피드백은 이미 대화 기록 안에 있고, 에이전트가 호출 직후에 무엇을 했는지가 가장 값싼 신호라는 이야기입니다.

대화 기록 약 2만 호출에서 센 파이프 비율

발표자는 자신의 대화 기록에서 약 2만 번의 에이전트 호출을 뽑아 분석했습니다. 표본에는 git, GitHub CLI, cargo, curl, npm, docker 등 14개의 CLI가 들어 있었습니다. 전체의 4분의 1은 출력을 head, grep, tail, python, sort, wc 같은 필터로 넘겼고, 읽기 중심 명령에서는 절반이 넘었습니다. git show와 cargo test는 각각 62%였습니다.

• 같은 CLI 하위 명령과 같은 파이프 도구 조합이 열 번 이상 나타나는 패턴에 속한 파이프가 83%였습니다. 인자는 달라도 에이전트가 계속 같은 것을 요청했다는 뜻입니다.
• 하나의 긴 세션을 통째로 열면 약 120만 자였지만, 검색에 걸린 부분 주변만 보면 약 3,000자였습니다.
• 하네스마다 편차가 있었습니다. 발표자는 Codex가 호출마다 출력 한도를 에이전트가 정하게 해서 파이프가 훨씬 적다고 설명했습니다.

발표자는 크기 제한만으로는 관련 있는 메시지를 가려내지 못하므로, 에이전트가 원하는 부분을 도구에 직접 말할 수 있는 선택 옵션이 필요하다고 말했습니다.

파이프가 실패를 숨기는 두 가지 경우

파이프 자체의 위험도 짚었습니다. 파이프 실패 옵션 없이 쓰면 파이프는 마지막 명령의 종료 코드를 돌려줍니다. 그래서 cargo test를 head로 넘기면 테스트가 실패해도 성공으로 보일 수 있습니다. 발표자는 컴파일 오류가 있는데도 초록색 점이 찍힌 화면을 예로 보여 주었고, 이 경우 에이전트가 오류 내용은 읽을 수 있었다고 설명했습니다.

더 나쁜 경우는 오류 자체가 잘리는 것입니다. 발표자는 Claude Code의 GitHub 이슈에서, 스크립트가 참조 오류와 함께 오류 코드로 끝났는데 tail이 무해한 세 줄만 보여 주어 Claude가 성공으로 보고한 사례를 들었습니다. 그래서 도구는 실패하면 확실히 실패해야 하고, 마지막 몇 줄에 짧은 요약과 전체 로그로 가는 경로를 두라는 것이 발표자의 권고입니다.

Allos AI 발표자가 자기 도구에서 고친 세 가지

발표자는 코딩 에이전트가 Claude Code, Codex, Cursor의 지난 세션을 검색하게 해 주는 작은 CLI를 만들고 있습니다. 이 도구에서 에이전트가 반복해 쓰던 파이프를 옵션으로 바꾼 사례는 세 가지입니다.

• grep으로 원하는 부분만 고르던 패턴은 읽기 명령이 일치한 메시지 주변만, 일치한 메시지만, 또는 마지막 몇 개만 크기 한도와 함께 돌려주도록 바꿨습니다.
• JSON을 파이썬으로 걸러 필드를 줄이던 패턴은 검색 결과를 한 줄에 한 건씩 보여 주는 간단 모드로 바꿨습니다. 결과는 같고 크기는 JSON의 약 6분의 1이라고 합니다.
• 여러 세션을 반복문으로 하나씩 점검하던 패턴은 한 번의 호출로 여러 세션을 묻게 바꿨습니다. 점검 호출의 약 3분의 1이 이 반복문에서 나왔다고 합니다.

발표자는 클라우드 비용 도구를 만드는 회사도 5월에 같은 발견을 글로 정리했다고 소개했습니다. 그 회사의 에이전트는 JSON 덤프에 jq와 파이썬 파이프라인을 직접 썼는데, 필터링을 CLI 안으로 옮기고 간단 포맷과 스킬을 더하자 어려운 질문 여섯 개 가운데 여섯 개를 맞혔고, 아무 장치가 없을 때는 여섯 개 중 0개였으며 벤치마크 전체 비용은 41% 줄었다고 합니다.

스킬 파일과 도움말이 곧 도구의 인터페이스입니다

발표자는 옵션을 만들었다면 스킬 파일이나 도움말 플래그로 에이전트에게 존재를 알려야 한다고 말했습니다. 에이전트는 가르친 내용을 글자 그대로 따르기 때문입니다. 실험으로 자기 도구의 한 옵션을 아무 일도 하지 않게 바꾸고, 스킬에는 그 옵션을 쓰라는 안내를 남겨 두었더니 95번의 검색이 모두 그 옵션을 넘겼습니다. 안내를 고쳐 쓴 스킬을 불러온 두 세션은 그 옵션을 한 번도 쓰지 않았고 첫 읽기부터 새 옵션을 시도했습니다.

요지는 스킬 파일, 도움말, 오류 메시지가 곧 인터페이스라는 것입니다. 낡은 문서도 에이전트가 계속 따라가므로 버그로 봐야 한다는 말입니다. 새 옵션이 에이전트에게 닿은 뒤에는 거의 모든 검색이 간단 모드를 썼고, 파이프 비율은 82%에서 약 4분의 1로 떨어졌다고 합니다.

대화 기록을 회귀 테스트로 쓰는 방법

발표자는 에이전트가 실제로 실행한 명령이 곧 테스트 사례이고, 그 직후에 에이전트가 한 행동이 대략적인 정답지라고 설명했습니다. 같은 명령을 옛 빌드와 새 빌드에 돌려 보고, 순위를 바꾸었다면 에이전트가 이어서 쓴 결과가 여전히 위쪽에 나오는지, 출력 형식을 바꾸었다면 빠진 내용이 없는지, 기본값을 바꾸었다면 어떤 명령의 동작이 달라지는지 확인하라는 순서입니다. 에이전트가 같은 호출을 다른 인자로 다시 했다면 실패 사례를 찾은 셈이라고 합니다. 다만 정답지는 에이전트가 원한 것을 대략 추정한 값이므로 일부 사례는 따로 남겨 두었다가 고친 결과를 채점하는 데 쓰라고 덧붙였습니다.

처음부터 다시 만든다면 이 순서로 만들겠다는 목록

• 측정한 파이프라인의 55%가 head, tail, sed만 썼으므로, 다른 기능보다 범위와 개수 제한을 먼저 넣습니다.
• 옵션은 에이전트가 손을 뻗어야 쓸모가 있습니다. GitHub CLI의 목록 명령은 개수 제한 옵션이 있고 에이전트가 81% 썼습니다. 반대로 cargo test의 간단 출력 모드는 약 열 번에 한 번만 쓰였고 나머지는 파이프로 처리했습니다. 그래서 도움말과 스킬에 가르쳐야 합니다.
• 큰 출력은 기본값을 짧게 하고 더 보는 방법을 알려 줍니다. 300건 중 20건을 보여 준다면 다음 쪽을 보는 오프셋 옵션을 함께 안내하는 식입니다.
• 에이전트 모드를 둘 수 있습니다. Claude Code 같은 에이전트는 셸에 환경 변수를 설정해 호출자가 에이전트임을 알 수 있게 합니다. 발표자는 한 데이터베이스 CLI(자막에는 Doug DB로 적혀 있습니다)가 사람에게는 표를, 에이전트에게는 몇 행이 빠졌고 어떻게 더 보는지 알려 주는 단순한 표를 주며, 오류는 JSON으로 돌려준다고 소개했습니다.

발표자는 이 변경으로 모델이 읽는 출력이 59% 줄었지만 모델이 읽은 전체 토큰에서 절약된 비중은 약 0.5%여서 비용과 실행 시간은 좋아지지 않았다고 말했습니다. 그래서 토큰만 보지 말고 턴 수와 정답 여부를 함께 재라는 것이 권고입니다.

에이전트에게 도구 설계까지 맡기면 생기는 문제

발표자는 에이전트에게 에이전트용 도구를 만들게 하면 사람을 떠올리고 에이전트를 덧붙이는 식으로 설계해서 흔한 패턴을 베끼게 된다고 말했습니다. 근거로 공식 MCP 서버 연구는 대부분이 기존 API를 그대로 옮겨 놓았다고 했고, 실제 MCP 서버의 도구 설명을 점검한 다른 조사에서는 97%에서 문제가 지적되었다고 인용했습니다. 취리히 연방공대 연구진이 에이전트가 쓴 컨텍스트 파일을 시험했더니 작업 성공에 도움이 되지 않았고 비용은 더 들었으며 사람이 쓴 파일보다 성적이 나빴다는 인용도 있었습니다.

반대로 에이전트는 대화 기록 하나와 돌려 볼 수 있는 테스트가 주어지면 무엇이 잘못되었는지 찾고 도구를 개선하는 데 강하다고 합니다. 발표자는 도구가 무엇이어야 하는지는 사람이 정하고, 실제로 일어난 일에 맞는지 확인하는 일을 에이전트에게 맡기라고 정리했습니다. 이 부분은 발표자가 다른 연구와 보고를 인용한 것이므로 이 글에서 원문을 따로 확인하지는 않았습니다.

오늘 할 일

1. 가장 먼저 에이전트 대화 기록을 백업합니다. 발표자는 Claude Code가 30일이 지난 비활성 기록을 지울 수 있다고 경고했습니다.
2. 내가 만든 도구나 자주 쓰는 CLI의 이름 뒤에 파이프가 붙은 호출을 대화 기록에서 검색합니다. MCP 서버를 운영한다면 같은 도구를 다른 인자로 곧바로 다시 부른 호출을 찾습니다.
3. 가장 많이 반복된 파이프 세 가지를 골라 도구의 옵션으로 옮깁니다. 범위, 개수 제한, 간단 출력이 우선이라는 것이 발표자의 순서입니다.
4. 도움말과 스킬 파일에 새 옵션을 적고, 낡은 안내를 지웁니다. 그다음 에이전트가 실제로 쓰는지 대화 기록으로 확인합니다.
5. 실패하면 종료 코드로 알리고, 출력 마지막 줄에는 짧은 요약과 전체 로그 위치를 남깁니다.

이 글의 근거와 한계

이 글은 AI Engineer 채널의 발표 「Your Agent Hates Your CLI」(Ayush Bhardwaj, Allos AI, 2026년 11월 10일 게시)의 영어 자동 자막을 읽고 정리한 것입니다. 자막에는 제품 이름의 오탈자가 있어 불확실한 이름은 자막 표기를 그대로 밝히거나 일반 명칭으로 적었습니다. 수치는 발표자가 자신의 대화 기록과 다른 글을 근거로 말한 것이며, 이 글에서 별도로 재현하거나 검증하지 않았습니다. 해커톤이나 프로젝트에서 에이전트 도구를 만든다면 DAKER 커뮤니티에서 어떤 파이프가 가장 자주 반복되었는지 경험을 나눠 주시기 바랍니다.