Fronmpt← 모든 글
블로그5분 읽기

같은 클로드 소넷, 하네스만 바꿨는데 성능이 갈렸습니다

자작 하네스에 알파는 없다는 도발로 시작된 하루짜리 논쟁을, 구글 팀의 9쪽짜리 Harness Engineering 문서가 정리했습니다. 같은 클로드 소넷에서 하네스만 바꿨더니 성능이 갈린 실험이 답이었습니다.

같은 클로드 소넷, 같은 벤치마크에서 하네스만 바꿨더니 성능이 갈렸습니다. 모델도 문제도 그대로인데, 감싸는 배선이 결과를 정한 거예요.

이 실험을 담은 게 구글 팀의 9쪽짜리 Harness Engineering 문서입니다. 이 문서를 정리한 트윗이 하루 동안 타임라인을 가른 논쟁의 심판 자리에 앉았어요.

발단은 자작 하네스에 알파는 없다는 도발이었습니다. 제드의 토어스텐 볼이 받아쳤고, 실제 비행기를 모는 개발자가 조종석 비유를 얹었죠.

프롬프트 엔지니어링의 자리를 하네스 엔지니어링이 차지하는 전환이 이 하루에 압축돼 있습니다.

자작 하네스에 알파가 없다는 도발은 무엇이었나요?

발단이 된 트윗은 조회 10만을 넘겼습니다. 주장은 단순해요. "자작 에이전트 하네스를 만드는 데 알파는 없다. 최고의 기법은 결국 발견되고, 복제되고, 오픈소스 하네스에 흡수된다."

하네스는 날 AI 모델과 쓸모 있는 결과물 사이에 놓인 전부를 가리킵니다. 프롬프트 조립, 도구 연결, 컨텍스트 관리, 실행 루프 — 모델을 감싸는 배선 전부예요.

이 주장의 논리는 이렇습니다. 어차피 좋은 기법은 공유되고 오픈소스로 수렴하니, 직접 만드는 노력은 경쟁 우위가 못 된다는 거죠. 기성 하네스를 쓰면 그만이라는 선언입니다.

에이전트를 만들어본 사람이라면 누구나 한 번쯤 부딪히는 질문이에요. 직접 짤 것인가, 남이 짠 걸 쓸 것인가. 이 질문이 지금 얼마나 많은 사람의 책상 위에 놓여 있는지를 보여준 하루였습니다.

토어스텐 볼은 어떻게 반박했나요?

제드 에디터의 토어스텐 볼이 답했습니다. "맞다. 하지만 자작 하네스를 만들면 그걸 셋으로 쪼개서 그 위에 강력한 플랫폼을 세울 수 있다. 단, CLI 전용 하네스라면? 총알이 과녁에 맞았다."

반은 수긍, 반은 반박이에요. CLI로만 도는 하네스라면 원 주장이 옳다고 인정합니다. 하지만 하네스를 분해해 플랫폼의 토대로 쓰는 순간, 이야기가 달라진다는 겁니다.

알파는 하네스라는 부품 자체가 아니라, 그 부품을 딛고 세운 제품에 있다는 관점입니다. 에디터라는 플랫폼을 만드는 제드의 입장이 그대로 묻어나는 답이에요.

"총알이 과녁에 맞았다"는 마지막 문장이 이 답의 온도를 보여줍니다. 도발을 통째로 부정하는 게 아니라, 맞는 범위를 정확히 그어주는 방식이거든요. 논쟁에서 가장 힘이 실리는 반박은 이런 모양입니다.

제트 엔진과 조종석 비유는 논쟁을 어떻게 바꿨나요?

세 번째 트윗이 논쟁의 축을 옮겼습니다. "하네스는 날 모델과 쓸모 있는 일 사이의 모든 것이다. 모델은 제트 엔진이고, 하네스는 조종석이다. 날 추력과 안전한 착륙 사이의 모든 것."

이 트윗을 쓴 사람은 실제로 비행기를 몹니다. "에어버스가 A320에 넣는 것과 같은 터보팬은 누구나 살 수 있다. 하지만 그것만으로는 승객 180명을 LA까지 못 나른다."

엔진은 범용재라는 겁니다. 추력을 비행으로 바꾸는 건 조종석이고요. 같은 엔진을 단 비행기라도 조종석의 설계가 안전한 착륙과 추락을 가릅니다.

세 트윗 중 가장 적은 사람이 본 트윗이었지만, 논쟁의 언어를 바꾼 건 이 비유였습니다. "알파가 있냐 없냐" 하는 손익 계산 언어가, "추력을 어떻게 비행으로 바꾸냐" 하는 공학 언어로 옮겨간 거예요. 모델이 상향 평준화될수록 차이는 모델 밖에서 난다는 얘기를, 이만큼 손에 잡히게 만든 비유는 드뭅니다.

구글의 Harness Engineering 문서는 무엇을 보여줬나요?

구글 팀이 낸 9쪽짜리 Harness Engineering 문서를 정리한 트윗이 이날 논쟁을 마무리했습니다.

핵심 실험이 논쟁의 답입니다. 같은 클로드 소넷, 같은 벤치마크에서 하네스만 바꿨더니 성능이 갈렸습니다. 모델도 문제도 그대로인데, 감싸는 배선이 결과를 정한 거예요.

공식은 한 줄입니다. 에이전트 = 모델 + 하네스.

흐름도 의미심장합니다. 도발도 반박도 아닌 정리 트윗에 가장 많은 사람이 몰렸어요. 논쟁보다 답을 보러 사람이 몰린 겁니다.

문서는 플레이북을 6단계로 제시합니다. 1단계는 가이드 추가예요. AGENTS.md, 규칙 파일, 제약 문서 — 한 줄 한 줄이 과거 에이전트의 실패를 규칙으로 바꾼 결과물입니다. 프롬프트를 잘 쓰는 기술이 아니라, 실패를 배선에 새기는 기술이 성능을 정한다는 거예요.

정리 트윗의 표현이 이 전환을 한 문장으로 못 박습니다. "공식 하나가 프롬프트 엔지니어링을 대체했다." 9쪽짜리 문서 하나가, 하루 종일 이어진 알파 논쟁의 심판 자리에 앉은 겁니다.

남는 생각

저는 이 논쟁에서 세 주장이 서로 다른 층을 말하고 있다고 봅니다.

"알파 없다"는 도발은 하네스를 팔 물건으로 보면 맞는 말입니다. 좋은 기법은 실제로 복제되고 오픈소스로 수렴해요. 하지만 토어스텐 볼이 반박한대로, 하네스를 딛고 플랫폼을 세우는 쪽에는 여전히 알파가 남습니다.

그리고 구글 문서가 보여준 건 세 번째 층이에요. 하네스를 팔지 않아도, 플랫폼을 만들지 않아도, 하네스를 다루는 능력 자체가 성능이 된다는 것. 같은 모델로 다른 결과를 내는 기술이라면, 그건 사라지는 알파가 아니라 축적되는 실력입니다.

프롬프트 엔지니어링이 앉던 자리에 하네스 엔지니어링이 앉는 중입니다. 저는 알파가 있냐 없냐보다 이 자리 교체가 더 큰 뉴스라고 봅니다.

원문·소스

FAQ

자주 묻는 질문

자작 하네스에 알파가 없다는 도발은 무엇이었나요?
자작 에이전트 하네스를 만드는 데 알파는 없다는 주장입니다. 최고의 기법은 결국 발견되고 복제돼 오픈소스 하네스에 흡수되니, 기성 하네스를 쓰면 그만이라는 선언이었어요.
토어스텐 볼은 어떻게 반박했나요?
CLI 전용 하네스라면 원 주장이 옳다고 절반은 수긍했습니다. 하지만 하네스를 셋으로 쪼개 그 위에 플랫폼을 세우면 이야기가 달라진다고, 알파는 부품이 아니라 그 위의 제품에 있다고 답했습니다.
제트 엔진과 조종석 비유는 논쟁을 어떻게 바꿨나요?
모델은 제트 엔진이고 하네스는 조종석이라는 비유로 논쟁의 축을 옮겼습니다. 알파가 있냐 없냐 하는 손익 계산 언어가, 추력을 어떻게 비행으로 바꾸냐 하는 공학 언어로 바뀌었어요.
구글의 Harness Engineering 문서는 무엇을 보여줬나요?
같은 클로드 소넷, 같은 벤치마크에서 하네스만 바꿨더니 성능이 갈린 실험을 담았습니다. 공식은 에이전트 = 모델 + 하네스 한 줄이고, 6단계 플레이북의 1단계는 가이드 추가입니다.