벤치 탈출! Claude Code 하네스 전략
FOMO 방지 비개발자 위한 클로드 코드 하네스 전략
클로드 만든 회사가 모델이 전부가 아니라고
몇 주 전 사람들을 들썩이게 하는 소식이 있었다.
클로드 코드 만드는 Anthropic 공식 기술 블로그에서 3월 24일 하네스 엔지니어링 설계의 중요성을 공유했기 때문이다.
복수 개의 에이전트로 에이전틱 코딩을 해나가려면 결국 하나하나의 성능을 최적화하는 것뿐 아니라 각 역할을 명확히 정의하고 좋은 팀을 구성해야 한다는 것. 그 사실을 단순히 성능 좋고 비싼 모델을 사용하는 것 (Sonnet -> Opus)만으로는 부족하다고 그 모델을 만들고 파는 회사가 밝힌 것이다.
저번 글에서 윙가디움 레비오우사~ 스킬을 제대로 구현하지 못해 홀라당 토큰을 태워먹고 FOMO 유도하던 나의 클로드가 덜 멍청해졌다. 공식 계정이 말아주는 규칙에 따라 훈련시켰더니 원하는 화면도 만들어주고 요약 뉴스도 보내주기 시작했다.
그런데 이제 똑똑하게를 넘어 동일한 모델과 시간으로 더 좋은 성능의 멀티 에이전트 바이브 코딩을 할 수 있다니! 구글 번역기의 도움을 빌려 안 읽을 수가 없었다.
클로드코드 공식 계정이 알려주는 하네스 전략
Harness 하네스란 말의 안장, 고삐 등 장비를 의미한다. 여기에서 파생된 하네스 엔지니어링 Harness Engineering이란 그럼 어떤 개발방법론인가? AI가 복잡한 업무를 안정적으로 완료할 수 있게 만드는 장비(시스템 또는 장치)이다.
AI한테 질문하고 확률적으로 좋은 결과가 나오기를 바라는 수동적인 프롬프트 엔지니어링을 넘어서는 것이다.
에이전트 팀을 구성하고, 피드백을 수집하고 적용하는 등 "AI가 일하는 방식, 환경"을 구성해 주는 능동적인 디자인 전략이고 개발 방법이다.
Harness design for long-running application development 제목의 글의 문제의식은 2가지였다. 하나, AI스럽지 않은 고품질의 프론트 디자인 만들기. 둘, 사람의 개입 없이 완벽하게 동작하는 앱 만들기. 최종 결과물은 계획자(Planner), 생성자(Generator), 평가자(Evaluator) 3가지 에이전트로 구성된 아키텍처였다.
홀로 프롬프트 엔지니어링 대비 멀티 에이전트가 잘 협업하도록 구성하는 하네스 엔지니어링은 무엇이 다른지, 동일한 앱(레트로 게임)을 만들 때 얼마나 더 좋은 결과를 얻었는지 차근차근 글에서 설명해 준다.
골든 스니치를 잡으면 좋겠지만 운칠기삼 같으니 갑자기 튀어나오는 버그(블러저) 만이라도 어떻게 좀...(RIP)
출처 : Harry Potter공식 포지션 1. 계획자 에이전트 : 승리 작전 짜는 주장
계획자는 사용자의 짧은 아이디어 1~4 문장 정도만 주면, 완전한 제품 설계 문서 (Product Spec Document)로 확장한다. 팀의 주장으로서 세세한 기술 구현 How가 아닌 어떠한 목표를 위해 Why 어떤 기능이 필요한지 큰 그림을 만들고 다른 포지션한테 이해시킬 수 있어야 한다.
그리고 그다음 포지션, 추격꾼(생성자 에이전트)이 하나하나 퀘이플을 처리할 수 있도록 작고 명확한 스프린트로 잘게 쪼개줘야 한다.
공식 포지션 2. 생성자 에이전트 : 전술 실행하는 추격꾼
생성자는 계획자의 설계와 전략에 따라, 각각의 스프린트(퀘이플)를 순차적으로 처리하는 역할이다. 무리해서 여러 퀘이플을 한 번에 처리하려다가는 영영 놓쳐버릴 수 있다. 전체 앱이 아니라 로그인 기능, 스탯 계산하기 등 명확한 범위의 작업 하나만 집중해야 한다.
컨텍스트 재설정(Context Reset) 등 방식으로 완료된 업무 결과만 전달하고 컨텍스트를 온전히 끊어야 메모리 등 리소스도 효율적으로 사용할 수 있고, 요구사항이 혼재된 상황에서 불필요한 엔지니어링이 발생하지 않는다.
공식 포지션 3. 평가자 에이전트 : 내부 심판하고 버그 잡는 몰이꾼
평가자는 생성자(추격꾼)가 계획자(주장)의 전략에 따라 임무를 잘 완수했는지 검증한다. 철저하게 생성자와 분리하여 개발이나 디자인 등 구현 작업은 하지 않고 테스트 케이스를 수행하면서 버그(블러저)를 찾아내야 한다.
생성자가 만들어둔 예시 소스코드나 화면 스크린샷 기준으로 '통과!'를 외치면 안 된다. Playwright MCP 등 사용해서 실제 사용자처럼 버튼을 클릭하고 페이지를 탐색하고 플로우를 따라가면서 검증해야 한다. 사전에 만들어둔 체크리스트에 따라 UI, API, DB, UX, 코드 품질 등 이행여부를 투명하게 피드백해야 한다.
개인기 프롬프트 VS 하네스 엔지니어링
이 글에서는 직접 레트로 비디오 게임 제작 도구를 만들 때, 프롬프트만으로 단일 AI 에이전트를 움직일 때보다 멀티 에이전트를 포함한 하네스 엔지니어링을 했을 때 더 좋은 성과를 낸다는 것을 증명했다. 단적으로 새로운 게임을 생성하는 시작화면에서, 왼쪽(단일)에 비해 오른쪽(하네스)이 좀 더 체계적인 온보딩 단계를 제공한다.
물론 에이전트 하나로 사용자-AI 소통하다 보니 비용은 9달러, 20분으로 저렴하고 또 빨랐다. 그런데 막상 겉모습은 그럴듯하지만 제대로 기능이 동작하지 않고 불필요한 레이아웃이 포함된 상황이었다.
한편, Full 즉 온전한 하네스로 구성하자 200달러가 소진되고 시간도 10배 이상 들었다. 그러나 그만큼 10번째 퀘이플(스프린트)을 통과시키고서 나온 레트로 게임 저작 도구는 보다 체계적이고 원만하게 동작했고, 레벨 디자인부터 소셜미디어 공유 기능까지 있을 건 다 있는 시스템을 만들 수 있었다고.
벤치 탈출 클로드 공식 하네스 전략 3가지 포지션 요약 그리고
1. 계획자 에이전트 : 승리 작전 짜는 주장
2. 생성자 에이전트 : 전술 실행하는 추격꾼
3. 평가자 에이전트 : 내부 심판하고 버그 잡는 몰이꾼
위와 같이 계획자, 생성자, 평가자 3가지 포지션 간에 명확한 역할 분담과 피드백이 없으면 어떻게 될까? 아무리 좋은 모델을 사용한다고 해도, 단일 에이전트로 진행하게 되면 비효율 나아가 쓰레기 코드를 양산한다.
계획자와 생성자가 혼재되어 있으니, 복잡한 프로젝트 전체에 대한 불필요한 컨텍스트 창이 차면, 장시간 작업하면서 산으로 가는 결론을 내는 경우가 있다. 생성자와 평가자가 혼재되어 있으니, 요구사항 누락하거나, 기능이 제대로 동작 안 하는데도 작업을 완료했다고 자신 있게 긍정하는 사태가 발생한다.
잘 모르겠다면? 만능열쇠 피드백 루프
결국 돌고 돌아 다시 이터레이션, 즉 실행과 피드백의 순환 루프이다. 아무리 생성자가 잘 구현했더라 하더라도 평가자의 엄격한 테스트를 거치지 않으면 확인되지 않은 정보이며, 아무리 평가자가 이런저런 오류를 잘 잡는다 하더라도 생성자가 이를 반영하고 개선하지 않으면 그뿐이다.
실제로 하네스 엔지니어링을 접하기 전에 아주 기초적인 피드백 루프를 활용해서 바이브코딩 품질을 높인 경험이 있다. 하나의 세션 종료하기 전에 각 에이전트한테 어떤 점이 실패 또는 비효율이었는지 반성(?)시키고, 필요하다면 CLAUDE.md 에 기록하도록 요청한 것이었다.
[세션 wrap 중 일부]
무엇이 실패/비효율이었는가: 지난 세션에서 버그 미발견 — 직접 실행해서 에러 확인
왜 발생했는가 (root cause): test_demo.py(샘플 데이터)로만 검증. 실제 API 호출 end-to-end 미실행
어떻게 방지할 것인가: 외부 API 연동 코드는 반드시 실제 API 호출로 검증 후 완료 선언
사실 아직도 하네스 엔지니어링을 어떻게 해야 잘하는 것인지는 모르겠다. 그래도 다음을 배웠다.
1. 개인기가 아니라 하네스 전략을 구성하여 멀티 에이전트 팀플을 이끌어야 한다는 것
2. 각 주장/추격꾼/몰이꾼 역할을 명확히 분리해야 퀘이플을 링에 통과시키고, 블러저한테 맞지 않는다는 것
3. 그리고 끊임없이 또 정교하게 피드백을 주고받다 보면 완전한 골든 스니치에 가까워질 수 있다는 것
이제 벤치 신세 탈출해서 퀴디치 게임에 나의 하네스 구단과 함께 참전해야겠다.
출처 : Harry Potter져니박 씀.