같은 클로드 소넷에 같은 벤치마크, 구글은 하네스만 바꿔 성능 차이를 보여줬습니다

"자작 에이전트 하네스에 알파는 없다." 사람들은 이 도발을 10만 번 넘게 봤고, 개발자들은 하루 종일 편을 나눠 다퉜습니다.

코드 에디터 제드(Zed)의 토어스텐 볼이 받아쳤고, 실제 비행기를 모는 개발자가 조종석 비유를 얹었어요. 그리고 한 사용자가 구글 팀의 9쪽짜리 Harness Engineering 문서를 정리해 올렸습니다.

구글 팀은 이 문서에서 같은 클로드 소넷, 같은 벤치마크에 하네스만 바꿔 성능 차이를 확인했습니다. 이 하루를 보면 개발자들이 프롬프트 엔지니어링에서 하네스 엔지니어링으로 넘어가는 흐름이 보여요.

자작 하네스에 알파가 없다는 도발은 무슨 주장인가요?

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

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

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

에이전트를 만들어본 사람이라면 누구나 한 번쯤 부딪히는 질문이에요. 직접 짤 것인가, 남이 짠 걸 쓸 것인가. 개발자들이 이만큼 크게 편을 나눴다는 건, 그만큼 많은 사람이 이 질문을 붙잡고 있다는 뜻입니다.

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

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

볼은 수긍과 반박을 함께 내놓습니다. CLI로만 도는 하네스라면 원 주장이 옳다고 인정합니다. 하지만 하네스를 분해해 플랫폼의 토대로 쓰면 알파를 만들 수 있다는 겁니다.

볼은 하네스라는 부품보다 그 위에 세운 제품에서 알파가 나온다고 봅니다. 에디터라는 플랫폼을 만드는 제드의 입장이 그대로 묻어나는 답이에요.

볼은 "총알이 과녁에 맞았다"는 문장으로 답을 맺습니다. 도발을 인정하면서 맞는 범위를 정확히 그어 주거든요. 저는 논쟁에서 이런 모양의 반박에 가장 힘이 실린다고 봅니다.

제트 엔진과 조종석 비유는 무엇을 바꿨나요?

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

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

엔진은 범용재라는 겁니다. 추력을 비행으로 바꾸는 건 조종석이고요. 같은 엔진을 달아도 조종석을 어떻게 설계하느냐에 따라 안전하게 내리기도, 추락하기도 합니다.

사람들은 세 트윗 중 이 트윗을 가장 적게 봤지만, 저는 논쟁의 언어를 바꾼 게 이 비유라고 봅니다. "알파가 있냐 없냐" 하는 손익 계산 언어에서, "추력을 어떻게 비행으로 바꾸냐" 하는 공학 언어로 옮겨간 거예요. 누구나 비슷한 모델을 쓸수록 모델 밖에서 승부를 본다는 얘기를, 이만큼 손에 잡히게 만든 비유는 드뭅니다.

구글 문서는 논쟁을 어떻게 정리했나요?

한 사용자는 구글 팀이 낸 9쪽짜리 Harness Engineering 문서를 정리해 이날 논쟁을 마무리했습니다.

구글 팀은 핵심 실험으로 논쟁에 답합니다. 같은 클로드 소넷, 같은 벤치마크에서 하네스만 바꿨는데도 성능 차이를 확인했습니다. 모델도 문제도 그대로 두고 배선만 바꿨으니, 팀은 배선이 결과를 정한다는 걸 확인한 셈이에요.

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

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

구글 팀은 문서에서 플레이북을 6단계로 제시합니다. 1단계는 가이드 추가예요. AGENTS.md, 규칙 파일, 제약 문서에는 팀이 과거 에이전트의 실패를 한 줄씩 규칙으로 바꿔 적어 둡니다.

프롬프트를 잘 쓰는 팀보다 실패를 배선에 새겨 두는 팀이 더 좋은 성능을 낸다는 거예요. 정리 트윗을 쓴 사용자는 이 전환을 한 문장으로 못 박습니다. "공식 하나가 프롬프트 엔지니어링을 대체했다."

구글 팀은 9쪽짜리 문서 하나로 하루 종일 이어진 알파 논쟁에 답을 냈습니다.

남는 생각

저는 이 논쟁의 세 주장이 서로 다른 층을 말한다고 봅니다.

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

그리고 구글 팀은 문서로 세 번째 층을 보여줬어요. 하네스를 팔지 않아도, 플랫폼을 만들지 않아도, 하네스를 다루는 능력이 곧 성능이라는 것. 같은 모델로 다른 결과를 내는 사람은, 남이 기법을 베껴 가도 실력을 계속 키웁니다.

개발자들은 프롬프트 엔지니어링에서 하네스 엔지니어링으로 넘어가는 중입니다. 저는 알파 논쟁보다 이 전환이 더 큰 뉴스라고 봅니다.

---