TerminalBench 65.2% 찍은 Dirac, HN이 본 핵심은 모델보다 하니스

Hacker News에서 이 글이 붙은 이유는 점수 자체보다 질문이 더 날카로웠기 때문이다. “65.2%가 진짜 모델 실력인가, 아니면 하니스 설계의 승리인가?” Show HN 작성자는 Dirac가 TerminalBench 2에서 gemini-3-flash-preview로 65.2%를 기록했고, Google 공식 기준선 47.6%와 Junie CLI 64.3%를 넘겼다고 설명했다. 여기에 벤치마크용 AGENTS.md를 끼워 넣지 않았다는 해명까지 붙으면서 토론은 바로 성능의 출처로 이동했다.

Dirac 저장소가 내세우는 차별점도 딱 그 지점에 있다. 해시 앵커 기반 편집, AST를 활용한 컨텍스트 선택, 대량 읽기·수정의 병렬화, 필요한 다음 맥락을 먼저 당겨오는 컨텍스트 큐레이션이 핵심이다. 더 큰 모델로 밀어붙이기보다 코드베이스를 어떻게 읽고 어떤 파일만 좁혀 보여주느냐로 성능과 비용을 같이 잡겠다는 접근이다.

HN 댓글도 같은 축에서 흘렀다. 가장 먼저 나온 질문은 “이게 새 모델 얘기냐, 새 하니스 얘기냐”였다. 작성자는 모델은 그대로 Gemini 3 Flash Preview이고, 성능 차이는 도구 체인에서 나왔다고 답했다. 다른 댓글들은 AST 기반 스코핑이 대형 코드베이스에서 왜 먹히는지, 단순 grep이 심볼 중복과 번들 파일 때문에 어디서 한계를 드러내는지를 두고 경험담을 보탰다. 커뮤니티 토론이 “LLM이 더 똑똑해졌다”보다 “도구가 문맥을 덜 낭비하게 만들었다”에 더 무게를 실은 셈이다.

이 스레드가 흥미로운 이유도 여기에 있다. 코딩 에이전트 성능 경쟁이 이제 모델 릴리스 속도만으로 설명되지 않는다는 점이 다시 확인됐다. 같은 모델이어도 파일 편집 방식, 검색 방식, 장시간 작업 처리 방식이 달라지면 결과가 꽤 크게 흔들린다. HN이 이 Show HN을 크게 밀어준 건 단순한 1등 자랑보다, 에이전트 성능의 병목이 어디인가라는 질문을 제대로 건드렸기 때문이다.