이 글을 정말 흥미롭게 읽었음. 저자는 정확히 핵심을 짚었다고 생각함
지금 존재하는 모델조차도, 우리가 에이전트 하니스(harness) 를 어떻게 설계하느냐에 따라 훨씬 더 효율적으로 만들 수 있는 여지가 많음.
나는 “AI”를 단순히 LLM 자체로 보지 않고, LLM과 하니스가 피드백 루프로 연결된 사이버네틱 시스템 전체로 보는 게 맞다고 생각함.
모델과 하니스는 서로를 강화하며 함께 진화하는 구조이므로, 둘 다 동등하게 중요함.
이런 관점은 단순한 성능 향상뿐 아니라, 생성형 AI를 신경-기호적(neurosymbolic) 프로젝트로 재해석하게 해줌
내 생각엔 지금도 GPT-4로 충분히 많은 걸 만들 수 있음.
나는 실제로 2023년 버전의 GPT-4로 코딩 에이전트를 만들었음.
오래된 모델로 작업하면 단순함을 유지해야 해서 오히려 문제를 다르게 보게 됨.
예를 들어, Python에서는 grep -r def . 같은 단순한 semantic compression이 필수적임.
Claude Code 같은 도구에 이런 간단한 훅을 추가하면 토큰 낭비 없이 코드 구조를 바로 파악할 수 있음
나는 Peen이라는 CLI를 만들고 있음. 로컬 Ollama 모델이 툴을 효율적으로 호출하도록 돕는 도구임.
단 몇 시간의 프롬프트 튜닝과 응답 처리 코드만으로도 작은 로컬 모델의 출력 품질이 놀랍게 개선됨 GitHub 링크
Claude Code와 OpenAI Codex의 하니스도 스스로 발전하고 있음.
OpenAI는 GPT-5.3-Codex 초기 버전으로 자체 훈련 프로세스를 디버깅하고 배포를 관리했음.
Claude Code는 하루에 20개 넘는 PR을 전부 자체 코드 생성으로 제출함
참고로, 내 글투가 “It’s not just X, it’s Y” 같은 구조를 자주 쓰지만, 이건 피곤해서 그런 거지 LLM이 쓴 게 아님
SWE-bench 문서를 보면, 거의 임의적인 컨텍스트 엔지니어링을 사용함.
실제로 어떤 모델이 좋은 컨텍스트 엔지니어링에 민감한지조차 잘 모름.
하지만 분명히 낮게 달린 열매(low hanging fruit) 가 많다는 점에는 동의함
이 기술은 흥미롭지만 과대평가된 느낌이 있음.
작성자는 자신이 만든 단순한 find/replace 벤치마크에서 5% 개선을 보고, 마치 전체 성능이 14포인트 오른 것처럼 말함.
실제로는 전체 토큰 효율성에서 1% 미만의 개선일 가능성이 높음.
게다가 글의 과장된 어조와 ChatGPT 특유의 문체가 신뢰를 떨어뜨림
“replace line 2:f1…” 같은 포맷이라면 실제 효율은 20%보다 훨씬 높을 수도 있을 것 같음
벤치마크에서는 토큰 사용량이 25~50% 줄었다고 하지만, 실제 사용 환경에서 그만큼 효과가 있을지는 의문임
이 글은 하니스 수준에서 얼마나 개선 여지가 큰지를 잘 보여줌.
에이전트들은 편집, 샌드박스, 툴 호출 간 데이터 전달 등에서 많은 토큰을 낭비함. 콘텐츠 기반 주소 지정 + 라인 넘버링의 조합이 실용적이고 아름다움
가장 큰 낭비는 MCP를 모든 곳에 사용하는 것일 수 있음.
초기 개발은 쉬워지지만, 불필요하게 거대한 모델을 호출하게 되어 비효율적임
ClaudeCode Superpowers 플러그인을 써봤는데, 기능은 좋지만 비용이 많이 듦.
CC에서는 /cost 명령으로 세션당 비용을 확인할 수 있는데, 이런 지표로 플러그인 효율을 평가하는 게 좋음
반대로, 더 많은 토큰을 써서 복잡한 문제를 작은 하위 문제로 분할해 해결하는 접근도 가능함
하니스의 중요성은 대부분이 생각하는 것보다 훨씬 큼.
예를 들어, Opus의 CORE 벤치마크 점수가 자체 하니스에서 Claude Code로 바꾸자 거의 두 배가 되었음 관련 링크
Pi 터미널 에이전트 제작자 Mario의 블로그 글에서도
TerminalBench 최고 점수가 Terminus 2 하니스 덕분이었다고 설명함
그래서 우리는 하니스를 자유롭게 교체하거나 직접 만들 수 있어야 함.
월 20달러 구독 때문에 특정 하니스에 묶이는 건 비합리적임
나는 tilth라는 도구를 만들어서 hash 기반 읽기/편집 방식을 구현했음.
npm과 cargo에서 설치 가능하며, Claude Code나 Cursor 같은 에디터와 연동됨 GitHub 링크
목표는 LLM이 툴을 더 효율적으로 사용하고 토큰 낭비를 줄이는 것임
마크다운에도 적용하면 좋을 듯함. 섹션 단위 주소 지정을 추가하면 버전 간 안정성이 높아짐
grep과의 벤치마크 비교도 흥미로울 듯함
나는 비슷한 방법을 독립적으로 고안했지만, 추상화 의존성 때문에 포기했음.
대신 Damerau-Levenshtein 거리를 사용해 편집 유사도를 계산하고, 일정 임계값 이상이면 수정이 통과되게 함.
이렇게 하면 모델이 교체할 소스 토큰을 명시적으로 출력하게 되어 정확도가 높아짐 코드 예시
핵심은 오류 메시지가 구체적이어야 함 — “Content mismatch. Reread the file”처럼 복구 지시를 포함한 에러 처리가 중요함.
이 방식은 4B 모델에서도 잘 작동하며, 툴콜을 지원하지 않는 모델에는 시스템 프롬프트 주입 해킹으로 대응함 관련 코드
예전 모델로도 꽤 정확한 결과를 얻을 수 있었음.
핵심은 모델을 “올바르게 다루는 것” 이었음.
이 글은 모델이 단순히 텍스트가 아니라 소스 코드의 구조적 표현(AST) 을 직접 다룰 수 있다면 더 큰 성과가 있을 것이라 시사함.
예를 들어 OpenRewrite는 코드의 타입, 포맷, 의존성 정보를 모두 포함한 Lossless Semantic Tree를 사용함.
이런 구조를 모델이 활용하면 불필요한 토큰 낭비 없이 매우 정확한 수정이 가능해짐.
결국 “Vim vs Emacs” 논쟁의 답이 “IntelliJ”인 이유와 같음 — 구조적 정보가 강력한 무기임.
만약 모델이 코드와 문서, 그리고 구문/의미 트리를 함께 학습한다면, 진정한 신경-기호적 코딩 모델이 될 것임
나는 Emacs의 gptel로 LLM을 실험하면서, LLM이 Unix patch 도구로 코드 수정을 잘 못한다는 걸 발견했음.
그래서 Emacs의 tree-sitter를 활용해 gptel용 툴을 직접 만들었음. tree_sitter_list_nodes, tree_sitter_update_nodes 같은 명령으로 AST 노드를 직접 수정하게 했더니 완벽하게 작동했음
흥미로운데, 그 코드를 공유할 수 있는지 궁금함
Codex의 apply_patch는 사실 제약된 샘플링 스키마를 사용함. 관련 코드
저자는 이를 모르고 단순 비교를 했기 때문에, 더 현실적인 벤치마크는 이 스키마를 활성화한 상태에서 해야 함
이 글의 인용구 중 특히 인상 깊었던 부분이 있음
“모델이 문제를 이해 못하는 게 아니라, 표현이 불안정한 것이다. 착륙 장치 문제를 조종사 탓으로 돌리지 말라.”
“모델은 해자(moat), 하니스는 다리(bridge)다.”
“멋진 데모와 신뢰할 수 있는 도구의 차이는 마법이 아니라 지루하지만 정교한 엔지니어링이다.”
정말 공감됨. 단순한 조언이 아니라, 저자의 사고방식을 생생히 그려낸 기술적 예술 작품 같음
Hacker News 의견들
이 글을 정말 흥미롭게 읽었음. 저자는 정확히 핵심을 짚었다고 생각함
지금 존재하는 모델조차도, 우리가 에이전트 하니스(harness) 를 어떻게 설계하느냐에 따라 훨씬 더 효율적으로 만들 수 있는 여지가 많음.
나는 “AI”를 단순히 LLM 자체로 보지 않고, LLM과 하니스가 피드백 루프로 연결된 사이버네틱 시스템 전체로 보는 게 맞다고 생각함.
모델과 하니스는 서로를 강화하며 함께 진화하는 구조이므로, 둘 다 동등하게 중요함.
이런 관점은 단순한 성능 향상뿐 아니라, 생성형 AI를 신경-기호적(neurosymbolic) 프로젝트로 재해석하게 해줌
나는 실제로 2023년 버전의 GPT-4로 코딩 에이전트를 만들었음.
오래된 모델로 작업하면 단순함을 유지해야 해서 오히려 문제를 다르게 보게 됨.
예를 들어, Python에서는
grep -r def .같은 단순한 semantic compression이 필수적임.Claude Code 같은 도구에 이런 간단한 훅을 추가하면 토큰 낭비 없이 코드 구조를 바로 파악할 수 있음
단 몇 시간의 프롬프트 튜닝과 응답 처리 코드만으로도 작은 로컬 모델의 출력 품질이 놀랍게 개선됨
GitHub 링크
OpenAI는 GPT-5.3-Codex 초기 버전으로 자체 훈련 프로세스를 디버깅하고 배포를 관리했음.
Claude Code는 하루에 20개 넘는 PR을 전부 자체 코드 생성으로 제출함
실제로 어떤 모델이 좋은 컨텍스트 엔지니어링에 민감한지조차 잘 모름.
하지만 분명히 낮게 달린 열매(low hanging fruit) 가 많다는 점에는 동의함
이 기술은 흥미롭지만 과대평가된 느낌이 있음.
작성자는 자신이 만든 단순한 find/replace 벤치마크에서 5% 개선을 보고, 마치 전체 성능이 14포인트 오른 것처럼 말함.
실제로는 전체 토큰 효율성에서 1% 미만의 개선일 가능성이 높음.
게다가 글의 과장된 어조와 ChatGPT 특유의 문체가 신뢰를 떨어뜨림
이 글은 하니스 수준에서 얼마나 개선 여지가 큰지를 잘 보여줌.
에이전트들은 편집, 샌드박스, 툴 호출 간 데이터 전달 등에서 많은 토큰을 낭비함.
콘텐츠 기반 주소 지정 + 라인 넘버링의 조합이 실용적이고 아름다움
초기 개발은 쉬워지지만, 불필요하게 거대한 모델을 호출하게 되어 비효율적임
CC에서는
/cost명령으로 세션당 비용을 확인할 수 있는데, 이런 지표로 플러그인 효율을 평가하는 게 좋음하니스의 중요성은 대부분이 생각하는 것보다 훨씬 큼.
예를 들어, Opus의 CORE 벤치마크 점수가 자체 하니스에서 Claude Code로 바꾸자 거의 두 배가 되었음
관련 링크
TerminalBench 최고 점수가 Terminus 2 하니스 덕분이었다고 설명함
월 20달러 구독 때문에 특정 하니스에 묶이는 건 비합리적임
나는 tilth라는 도구를 만들어서 hash 기반 읽기/편집 방식을 구현했음.
npm과 cargo에서 설치 가능하며, Claude Code나 Cursor 같은 에디터와 연동됨
GitHub 링크
목표는 LLM이 툴을 더 효율적으로 사용하고 토큰 낭비를 줄이는 것임
나는 비슷한 방법을 독립적으로 고안했지만, 추상화 의존성 때문에 포기했음.
대신 Damerau-Levenshtein 거리를 사용해 편집 유사도를 계산하고, 일정 임계값 이상이면 수정이 통과되게 함.
이렇게 하면 모델이 교체할 소스 토큰을 명시적으로 출력하게 되어 정확도가 높아짐
코드 예시
핵심은 오류 메시지가 구체적이어야 함 — “Content mismatch. Reread the file”처럼 복구 지시를 포함한 에러 처리가 중요함.
이 방식은 4B 모델에서도 잘 작동하며, 툴콜을 지원하지 않는 모델에는 시스템 프롬프트 주입 해킹으로 대응함
관련 코드
예전 모델로도 꽤 정확한 결과를 얻을 수 있었음.
핵심은 모델을 “올바르게 다루는 것” 이었음.
이 글은 모델이 단순히 텍스트가 아니라 소스 코드의 구조적 표현(AST) 을 직접 다룰 수 있다면 더 큰 성과가 있을 것이라 시사함.
예를 들어 OpenRewrite는 코드의 타입, 포맷, 의존성 정보를 모두 포함한 Lossless Semantic Tree를 사용함.
이런 구조를 모델이 활용하면 불필요한 토큰 낭비 없이 매우 정확한 수정이 가능해짐.
결국 “Vim vs Emacs” 논쟁의 답이 “IntelliJ”인 이유와 같음 — 구조적 정보가 강력한 무기임.
만약 모델이 코드와 문서, 그리고 구문/의미 트리를 함께 학습한다면, 진정한 신경-기호적 코딩 모델이 될 것임
나는 Emacs의 gptel로 LLM을 실험하면서, LLM이 Unix patch 도구로 코드 수정을 잘 못한다는 걸 발견했음.
그래서 Emacs의 tree-sitter를 활용해 gptel용 툴을 직접 만들었음.
tree_sitter_list_nodes,tree_sitter_update_nodes같은 명령으로 AST 노드를 직접 수정하게 했더니 완벽하게 작동했음Codex의
apply_patch는 사실 제약된 샘플링 스키마를 사용함.관련 코드
저자는 이를 모르고 단순 비교를 했기 때문에, 더 현실적인 벤치마크는 이 스키마를 활성화한 상태에서 해야 함
이 글의 인용구 중 특히 인상 깊었던 부분이 있음
“모델이 문제를 이해 못하는 게 아니라, 표현이 불안정한 것이다. 착륙 장치 문제를 조종사 탓으로 돌리지 말라.”
“모델은 해자(moat), 하니스는 다리(bridge)다.”
“멋진 데모와 신뢰할 수 있는 도구의 차이는 마법이 아니라 지루하지만 정교한 엔지니어링이다.”