이 하네스에서 qwen3.8-27b 모델 5개를 돌려, 이미 성능이 포화된 2025년 초 코딩 벤치마크에서 Fable 5와 대략 비슷한 결과를 낸 셈임. astra/6.1 sol/fable 5.1/opus 5.5와의 비교도 없고, 실제 에이전트 작업을 반영하는 벤치마크와의 비교도 없음. 요즘 모델은 에이전트 행동에 최적화되므로, 오히려 Qwen을 실제보다 나쁘게 평가할 수도 있음.
데이터셋이 2023년 5월부터 2025년 4월까지 나온 문제 1,055개로 구성됐다면 학습 데이터 오염도 사실상 확실함. 모델들이 오케스트레이션에 강하게 강화학습되는 만큼 적극적인 작업 조율은 흥미로울 수 있지만, 이 평가 방식으로는 하네스가 좋은지 알기 어려움.
Qwen에 하네스를 붙였다면, 다른 LLM에도 하네스를 붙여서 비교해야 하지 않을까?
PDF를 보면 검증자를 제외한 모든 역할이 같은 모델을 새 컨텍스트로 호출하고 디스크의 공유 작업 공간으로 협업함. /task.md는 문제, /plan.md는 관리자의 전체 계획, /tasks.json은 디버깅용 작업 목록 사본, /notes.md는 아이디어·발견·부분 증명, /solution.py는 현재 풀이를 담음. 관리자와 작업자가 주고받으며 작업자 컨텍스트를 매번 새로 만든다는데, 그 과정이나 작업자 역할 자체가 꼭 필요한지 의문임.
출시 이후 거의 Qwen 3.8 27B만 쓰는데, 내 방식도 비슷함. 작업을 설명하고 PLAN.md에 계획을, 같은 파일이나 CLI로 접근하는 이슈 추적기에 작업을, STATUS.md에 진행 상황을, GOTCHAS.md에 주의사항을 기록하게 함. 마지막 파일은 원래 메모를 좋아하는 모델이 다른 두 파일에 잡다한 내용을 쓰지 않도록 유도하는 역할도 함.
이를 주도하는 별도 하네스 없이 작업과 진행 방식을 알려주면 알아서 진행함. 한꺼번에 전부 처리하지 말라고 하는 내가 하네스 역할을 하는 셈이지만, 새 컨텍스트를 만들지는 않음. Pi의 점진적 컨텍스트 압축이 오래된 메시지만 요약하고 최근 메시지는 유지해서 거의 문제가 되지 않음.
컨테이너 안에서 CLI로 쓰는 계획 도구도 생각했지만, 지금의 파일 3개로도 같은 일을 할 수 있을 듯함. 도구가 있으면 현재 작업을 확인할 UI는 생기겠지만, 보통은 그냥 중단하고 직접 물은 뒤 계속하라고 함. 나중에 실제 작업과 비슷한 자체 벤치마크를 만들어 여러 접근을 비교하고, Qwen4 27B가 나오면 3.8보다 얼마나 나아졌는지도 확인하고 싶음.
그 동작을 구현하는 도구가 바로 하네스임. LLM 자체는 텍스트를 이어서 생성할 뿐, 혼자 뭔가를 실행할 수는 없음. 이를 실제 행동이나 채팅 인터페이스로 연결하는 것이 하네스임.
나도 비슷하게 쓰지만 작업 도중 중단시킨 적은 없음. 흐름이 흔들리거나 함수가 반쯤 작성된 채 남을까 걱정돼, 정해진 지점에서 멈추고 다음 단계로 넘어가도 되는지 묻게 함. 작업 도중 중단해도 제대로 대응하는 편인가?
모델 크기와 관계없이 나도 비슷한 절차를 쓰며, 명령 한 줄로 실행할 작업 흐름으로 만드는 게 좋다고 봄. 여러 방법이 있지만 결국 opencode의 사용자 정의 에이전트와 하위 에이전트를 마크다운으로 구성하는 쪽으로 돌아가곤 함.
27~30B급의 발전은 흥미로움. 상당히 좋아졌지만, 내 경험상 여전히 환각이나 잘못된 가정이 눈에 띄게 더 잦음.
다들 비슷한 아이디어로 수렴하지만, 새로 등장하는 여러 “소프트웨어 공장”의 구현은 그다지 깔끔하지 않음. 충분히 복잡한 것을 만들다 보면 공유된 기록을 통한 작업 조율이 자연스러운 해법이 됨.
복잡한 프로젝트에서 에이전트 간 일관성을 유지할 필요가 있어 오픈 소스 Pullboard를 만들고 있음. https://github.com/pullboard-dev/pullboard.
그냥 문제들에 과적합한 것 아닌가?
많은 모델이 끊임없이 평가 점수 극대화에만 매달리고 있음.
비용을 생각하면 상당히 인상적임. 특히 로컬 실행은 하드웨어를 한 번 구매한 뒤에는 전기료만 들기 때문임.
놀랍지 않음. Opus 5.5와 Fable 5.1이 좋다는 얘기를 듣고 4월 이후 처음 Claude Code를 다시 썼는데, 하네스 품질이 너무 나쁘고 봄보다도 퇴보한 듯해서 충격을 받음. 내가 잘못 쓰는 것일 수도 있지만, Opus/Fable이 실행을 막지 않는 하위 에이전트를 제대로 띄우려면 네다섯 번 시도해야 함. 30초 넘게 걸리는 테스트 모음 같은 작업의 완료 여부도 안정적으로 확인하지 못함.
Anthropic이 세계 최고의 모델을 갖고 있다는 게 요즘 대세인 듯하지만 내 생각은 다름. 설령 그렇더라도 주변 실행 도구가 형편없으면 모델의 지능도 소용없음.
사용 방식에 문제가 있는 듯함. 나는 여러 에이전트의 복잡한 실행 순서를 조율하고, 다른 에이전트를 감시하다 작업을 분기하거나 새 설계 주기를 시작하게 하는 구성을 일상적으로 씀.
낮에는 코드베이스마다 여러 설계 작업을 열어 각 에이전트가 다른 세션을 알게 하고, 밤에는 테스트와 병합까지 조율하는 무인 빌드를 돌림. 가끔은 8시간씩 걸리기도 함.
분명 사용 방식에 문제가 있는 듯함. 내 모든 세션에서는 늘 하위 에이전트를 쓰고, 백그라운드 작업 상태도 확인할 수 있음.
특정 제품을 편드는 건 아니지만, Claude Code를 쓰면서 그런 현상을 겪은 적은 없음. 사용 방식이나 설정 일부가 잘못됐을 수 있음. 회사에서는 Copilot CLI, 집에서는 Claude Code를 쓰는데 요즘 하네스는 모두 꽤 괜찮은 편임.
우선 모든 모델에 쓸 수 있는 하네스를 골라야 모델 문제와 하네스 문제를 분리할 수 있음. Fable을 시험하려고 Claude Code로 하네스까지 바꿔야 했다면 접근이 잘못된 것임.
모든 모델이 포그라운드와 백그라운드 하위 에이전트를 혼동하므로, 나는 하네스에서 포그라운드 하위 에이전트를 없앴음. 결과가 필요하면 세션 기록을 읽게 하면 됨.
모델이 혼란스러워할 때는 도구를 줄이는 것이 최선인 경우가 많음. 작업 방법이 하나만 남도록 도구를 좁히고, 그 하나를 최대한 강력하게 만들면 됨.
팀의 Boris임. 백그라운드 하위 에이전트가 기본값이라 꽤 의외임. 최신 버전인지 확인하고 /bug를 실행한 뒤 식별자를 여기에 올려줄 수 있을까? 무슨 일인지 함께 디버깅하고 싶음.
머지않아 오픈 소스나 검열할 수 없는 모델에서도 Mythos 수준의 사이버 위협이 가능해질 듯함. 할 수 있는 일은 핵심 기반 시설에 조금이라도 가까운 시스템과 소프트웨어 공급망의 보안 강화를 계속하는 것뿐이라고 봄.
자체 호스팅은 늘 소수에 머물고 장기적으로 추론의 95% 이상이 호스팅 서비스를 거칠 테니, 대규모 추론 제공자에게 안전장치나 분류기를 의무화하는 법을 만들 수도 있음. 다만 이는 순식간에 사상 검열 디스토피아로 변질될 수 있음.
자원이 충분한 정보기관에는 이런 허점들이 예전부터 열려 있었고 지금도 그렇다는 사실이 씁쓸함.
진짜 흥미로운 부분은 qwen flash next 결과임. 27B 밀집 모델은 최신 deepseek flash 같은 모델보다 활성 매개변수가 더 많음.
128GB 추론 장비를 가진 사람에게는 확실히 그 모델이 더 흥미로움. Strix Halo에서 27B는 몹시 느림. Qwen 3.8 Flash는 4비트로 128GB에 빠듯하게 들어가지만 밀집 모델보다 확연히 빠름. 3비트면 여유가 생기지만 지능 저하가 큼.
추론량도 조금 적고 생성 속도도 빨라 실제로 체감할 만큼 개선됨. 4비트에서도 8비트 27B보다 약간 더 똑똑하게 느껴짐.
반면 Strix Halo나 DGX Spark보다 메모리 대역폭이 높은 32GB GPU 한두 개가 있다면 밀집 모델이 확실히 나은 선택임. 일반 개발자에게는 이 구성이 더 흔할 듯함.
벤치마크 하나에서 나온 결과일 뿐임. 그 벤치마크의 실행 방식은 단발 풀이와 단발 풀이 후 수정 두 가지이고, 도구는 전혀 쓰지 않음.
그런데 이미 꽤 낡은 벤치마크의 규칙마저 무시하고, 작업 위임과 Python으로 결과를 살펴보는 기능을 통해 일종의 에이전트 반복 실행을 붙인 뒤 이겼다고 함. 벤치마크는 이렇게 하는 게 아님.