PDF가 워낙 상세해서 전부 읽지는 못했지만, 지금까지 공감한 부분이 몇 가지 있음. 자동차 A가 B보다 빠르거나 연비가 좋다고 해서 반드시 엔진 덕분은 아니며, 타이어·변속기·차체 무게·기능 사용성 때문일 수도 있음. 같은 모델이라도 하네스 구성에 따라 결과가 달라짐. BI용 AI 기능만 해도 ReAct 루프, 계획 후 실행, 혼합형으로 구현할 수 있고, 정확도와 분석 깊이 중 무엇을 우선하느냐에 따라 상태 유지 여부나 RAG 사용 여부를 정할 수 있음. LLM에 의도만 생성하게 하면 추론 부담이 작지만, 쿼리 자체를 생성하게 하려면 훨씬 강력한 모델이 필요함.
하네스는 모델의 기본 역량에 맞추거나 부족한 역량을 보완할 수 있음. 위 예시에서 쿼리 생성에는 모델의 MOE 역량이 필요하지만, 의도 생성에는 필요하지 않음.

하네스의 역할을 체계적으로 검증하는 연구가 더 필요함. 복잡한 하네스가 극도로 단순한 에이전트를 꾸준히 앞서는 벤치마크는 그리 많지 않다고 봄.
다만 나는 https://github.com/swe-agent/mini-swe-agent/를 만든 사람이라 편향이 있을 수 있음. 처음에는 전부 합쳐 100줄에 불과했고, 아마 가장 간소한 에이전트 중 하나일 것임. DeepSWE, terminalbench, programbench 등 여러 벤치마크에 쓰이며, TB3에서는 여전히 최상위인 듯하지만 TB4에서는 최고 성능 모델로 평가되지 않았음.

“에이전트 클래스는 Python 약 100줄이고 환경·모델·실행 스크립트가 조금 더 있다”고 소개하지만, 실제로는 100줄을 훨씬 넘음. 더는 사실이 아닌 내용을 왜 계속 홍보하는 것임?

AI 전반에서 무엇이 효과적이고 어떻게 써야 하는지 검증하는 연구가 더 보고 싶음. 과열된 기대와 빠른 변화 속에서 근거 없는 의식 같은 사용법이 자꾸 생겨나는 느낌임.
Anthropic은 agents.md에 코드의 아키텍처 개요를 넣으라고 공개적으로 권장하지만, 이를 조사한 한 연구에서는 방대한 개요보다 빌드 방법 같은 구체적인 명령이 더 효과적이라는 반대 결과가 나왔음. 내가 아는 한 공식 권장 사항은 여전히 그대로임.
벤치마크 역시 모호하고, 이런 도구를 고정된 숫자 하나로 평가하기 어렵다는 걸 다들 알면서도 계속 점수를 비교함. 스킬, superpowers, 플러그인, MCP 구성을 공유하지만 실제 효과를 입증하는 근거는 거의 없음.
그래서 요즘은 이런 연구를 더 찾아보고 있음. 최신 모델이나 최신 기법을 정확히 다루지 않더라도, 실증 연구가 없는 것보다는 훨씬 나음.

지난 1년간 Claude Code를 쓰며 얻은 결과와 상당히 일치함. 몇 달 전에도 정리했음. https://rahulmax.com/notes/how-i-keep-the-ai-bill-down/
이 연구에서는 문맥 창이 작을수록 문맥 관리 효과가 컸으며, 관리 여부에 따른 성공률 차이가 32k에서는 35.7%포인트, 128k에서는 2.7%포인트였음. 나는 가능한 한 문맥 창의 25~30%를 쓰면 진행 상태를 PROGRESS.md와 요구사항 JSON 파일에 저장하고 새 세션을 시작함. 재시작에는 30초가 걸리며, 비대해진 세션을 계속 쓴다고 비용이 줄어들지는 않음.
연구에 사용한 모델은 여기서 많은 사람이 돈을 내고 쓰는 최상위 모델이 아니라 Nemotron-3와 Mistral-Medium이라는 점도 알아둘 만함.

논문은 “bash capable”의 의미를 정의하지 않은 채 사용하는 듯함. 어떤 모델이 여기에 해당하는지 어떻게 판별할 수 있을까?
Luna는 충분히 해당할 것 같음. 그렇다면 Bash 이외의 도구를 추가할 때는 실제 가치를 더하는지 엄격하게 시험하고 검증해야 한다고 봄.

별도 도구가 필요 없을 만큼 bash를 잘 쓰는 모델이라는, 어느 정도 자기설명적인 표현 같음. 논문도 그런 모델에는 bash로 이미 할 수 있는 일을 별도 도구로 제공해도 성능이 개선되지 않는다고 함.
RAG와도 비슷한 결과임. 특정 분야가 아니라면 에이전트에 셸과 grep을 쥐여주는 것보다 나은 결과를 얻기 어려움.

단순히 LLM 토큰 스트림을 읽는 파서가 있어서, 감지한 명령 문자열로 셸 프로세스를 실행할 수 있다는 뜻이라고 생각함.

Nemotron과 Mistral만으로 수행한 연구라서, 저렴한 중국 모델과 Claude/GPT 대형 모델이 이끄는 현재 최전선에는 관련성이 크지 않음. Qwen이나 DeepSeek을 넣지 않은 건 큰 누락임.

연구의 초점은 하네스 접근법별 차이와 모델 크기에 따른 변화임. 어떤 특정 모델군을 사용했는지는 무관함.

이런 논리에는 점점 질리기 시작함. LLM이 빠르게 발전하는 건 맞지만, 심층적인 실증 연구를 최신 모델이 아니라는 이유만으로 기각하면서 반례나 근거는 제시하지 않는 경우가 너무 잦음.
최신 모델에서는 결과가 달라진다면 최소한 그에 대한 증거가 필요함. 지금은 “모든 것이 늘 바뀌니 어떤 연구도 최첨단 모델에는 적용할 수 없다”는 막연한 전제만 있는 듯함.
LLM은 성능이 크게 좋아지고 창발적 특성이 나타나더라도, 핵심 작동 방식까지 근본적으로 달라지는 경우는 드묾. 에이전트 코딩에 쓸 만한 수준에 처음 도달했을 때와 같은 급격한 변화도 한동안 없었음. “내 모델은 다르다”는 막연한 느낌만으로 실증적 증거와 연구를 매번 무시하는 데 지쳤음.

직접 써봤을 때 Nemotron과 Mistral은 “현재 최전선”의 모델들과 어떻게 비교됨?

하네스 벤치마크가 더 나오는 건 반갑고, 앞으로도 더 필요함. Frontier Harness 벤치마크에서 mouse로 최고 통과율을 기록했지만, 그 결과가 실전에서 “최고의 하네스”라는 뜻으로 이어지는지는 확신하지 못함.
하네스 평가를 늘 찾고 있지만, 온갖 모델과 작업에 걸쳐 실행하다 보니 비용 때문에 파산할 지경임.

결론을 보면, 계획 수립은 약한 모델에서는 추가 비용을 들여 성공률을 높이고, 강한 모델에서는 성공률을 조금 낮추는 대신 주로 비용을 줄임. 작업을 너무 일찍 포기하는 모델은 실행을 지속하게 하고, 검증을 너무 오래 하는 모델은 반복 검증을 줄여줌.
미리 정의한 도구는 bash 제어가 약한 모델의 성공률을 높이지만, bash를 잘 쓰는 모델은 bash만 쓸 때 더 낮은 비용으로 더 높은 성공률을 보임. 특히 셸 중심 작업에서 차이가 뚜렷하며, 역량이 충분한 모델은 여러 코드 수정을 도구 호출 한 번에 묶을 수 있음. 문맥 관리는 에이전트 행동을 크게 바꾸지 않고 실행 과정을 늘려주며, 문맥 예산이 빡빡할 때 가장 유익함.
직관적으로는 꽤 당연하게 느껴짐. bash를 잘 쓰는 모델에는 bash만 쓰는 도구 구성이 좋고, 못 쓰는 모델에는 미리 정의한 도구가 좋다는 것 아닌가? 다만 하네스 구성 요소는 모델·작업·자원 예산에 맞춰 선택해야 한다는 최종 결론에는 동의함.
하네스·모델·프롬프트를 자유롭게 교체 가능한 조합으로 취급하는 경우가 많지만, 내 경험상 품질과 효율은 하네스와 모델의 궁합에 크게 좌우됨. 같은 연구소가 만든 하네스와 모델을 함께 쓰는 편이 범용 하네스보다 훨씬 나았으며, 후속 모델 학습에 자체 실행 기록을 쓰기 때문일 가능성이 큼.

“나쁜 공기가 병을 일으키는 건 누구나 안다”, “화성에 운하가 있는 건 당연하다”도 한때는 상식이었음. 당연해 보이는 것을 검증하는 일은 매우 가치 있는 과학임. 가정의 범위를 줄여 더 탄탄한 토대를 만들어주기 때문임.

비교를 잘못 이해한 것임. 결론은 bash를 잘 쓰는 동일한 모델에서 bash 전용 도구가 미리 정의한 도구보다 낫다는 것임.
달리 말하면 MCP는 모델이 bash를 잘 쓰기 전까지 조금 도움이 됐을지 몰라도, 이제는 사실상 쓸모없는 허풍이었다는 뜻임.

꼭 그렇지는 않음. 최근 Claude와 Codex를 대상으로 한 벤치마크에서는 pi agent와 각 모델의 자체 하네스 사이에 수행 능력 차이가 없었고, 오히려 pi의 작업당 비용이 더 낮았음.

당연해 보여도 모델별로 무엇을 잘하는지 체계적으로 정리한 목록이 필요하다는 뜻임. LLM 요리책처럼 모델에 더 잘 맞는 하네스를 고르거나 조정할 수 있어야 함. 원격 모델뿐 아니라 실행 방식도 중요한 로컬 모델에도 필요함.

얼마 전 변호사인 어머니를 Linux로 옮기려 했는데, 대체로 마음에 들어 하셨지만 Office 대체 제품의 호환성이 업무에 쓰기에는 부족했음.
Windows에 남아 있어야 하는 또 다른 이유는 Adobe PDF Pro임. OCR 후 내용을 편집하면 스캔 원본과 비슷한 글꼴로 텍스트를 재배치해서 원래 문서처럼 보이게 해줌. 사기를 가능하게 하는 기능 같아 꺼림칙했지만, 변호사에게는 아주 흔한 작업이라고 해서 더 싫었음.
Windows를 벗어나지 못하게 하는 두 가지 장애물 중 하나가 해결되는 건 반가움.

“Opus 4.8, Sonnet 5, Fable 5, Mythos 5 및 이후 모델에서는 할 일·작업 추적 도구인 TaskCreate/Get/Update/List, TodoWrite를 더 이상 사용할 수 없으며, CLAUDE_CODE_ENABLE_TODO_TOOLS=1 로 다시 활성화할 수 있다”고 함.
Anthropic도 최상위 모델에는 세션 내 계획 도구가 필요하지 않다는 데 동의하는 듯함. https://github.com/anthropics/claude-code/issues/80487