“하네스는 적을수록 좋다. 아니, 모델 회사가 하네스까지 학습시켜 버리면 그걸로 끝이다. 아니, 하네스는 그 자체로 독립적 가치가 있다.” 벤처 투자자 마틴 카사도가 최근 이 세 가지 생각 사이를 오간다고 털어놓았습니다.

AI 에이전트를 감싸는 “하네스”(모델에 지시와 도구, 맥락을 엮어 넘겨주는 틀)를 얼마나 두텁게 만들어야 하는지, 업계에서 의견이 정리되지 않고 있다는 뜻입니다. 보안 전문가이자 AI 저술가인 대니얼 미슬러는 이 질문에 답을 내놓을 수 있다고 말합니다. 하네스를 하나로 뭉뚱그려 생각하니 답이 안 나올 뿐, 실은 두 가지 완전히 다른 요소가 섞여 있다는 것입니다.
출처: The Answer to the Harness Question – Daniel Miessler 참고: Deep Agents v0.7 – LangChain
하네스의 절반은 낡고, 절반은 쌓인다
미슬러는 하네스를 “무엇을(WHAT)”과 “어떻게(HOW)”로 나눠서 봐야 한다고 설명합니다. “어떻게” 쪽은 모델에게 단계별로 방법을 가르쳐주는 부분이죠. 이 부분은 시간이 갈수록 가치가 떨어집니다. 모델이 똑똑해질수록, 사람이 일일이 짜준 절차는 오히려 성능을 깎아 먹는 군더더기가 되기 때문입니다. 리처드 서튼이 말한 “쓰라린 교훈”이 프롬프트 설계에도 그대로 적용되는 셈이죠. 하네스가 대부분 이 “어떻게”로 채워져 있다면, “하네스는 적을수록 좋다”는 첫 번째 주장이 맞습니다.
반대로 “무엇을” 쪽은 사용자가 누구인지, 무엇을 만들고 있는지, 어떤 제약과 취향을 갖고 있는지에 대한 맥락입니다. 이 부분은 시간이 갈수록 가치가 쌓이는데, 모델이 똑똑해질수록 이 맥락을 더 잘 활용하기 때문입니다. 하네스가 이 “무엇을”로 채워져 있다면, “하네스는 그 자체로 독립적 가치를 갖는다”는 세 번째 주장이 맞는 셈입니다.
모델 회사가 하네스를 통째로 흡수해버릴 거라는 두 번째 주장은 절반만 맞습니다. 모델 회사는 “실행” 능력은 계속 개선할 수 있지만, 사용자 개개인의 맥락까지 미리 학습시켜둘 수는 없죠. 그건 매번 바깥에서 모델에게 전달해줘야 하는 정보이기 때문입니다.
실제로 걷어내 보니 무슨 일이 일어났나
이 구분이 이론에 그치지 않는다는 걸 보여주는 사례가 있습니다. LangChain은 에이전트 개발 프레임워크 Deep Agents의 새 버전(v0.7)에서 기본 하네스에 들어 있던 시스템 프롬프트를 아예 들어냈죠. 내장 도구 설명문도 43% 줄였고, 계획을 세우는 투두리스트 기능도 기본값에서 빼고 필요할 때만 켜도록 바꿨습니다.
결과는 대화 한 턴당 기본 입력 토큰이 약 6,000개에서 2,000개로, 65% 줄었다는 것입니다. 그런데 성능은 거의 그대로 유지됐죠. LangChain은 코딩·데이터 분석 같은 자율 작업, 여러 차례 오가는 대화, 긴 맥락을 다루는 작업까지 세 범주로 나눠 네 개 모델에 테스트를 돌렸는데, 특히 OpenAI의 경량 모델 하나는 토큰 34%·비용 15% 감소에 오히려 성능 점수가 4% 올랐습니다.
투두리스트 기능을 기본값에서 뺀 이유도 비슷합니다. 세 범주, 세 모델에 걸쳐 실험한 결과 투두리스트를 끄는 쪽이 오히려 점수가 살짝 높고 비용은 낮았던 겁니다. 다만 여러 단계를 거치는 긴 작업이나, 상대적으로 성능이 낮은 모델, 사용자에게 진행 상황을 보여줘야 하는 경우에는 여전히 켜두는 편이 낫다고 안내합니다.
남겨야 할 것과 덜어내야 할 것을 가르는 기준
두 이야기를 겹쳐보면 기준이 선명해집니다. “이렇게 하라”는 식의 절차형 지시는 모델이 스스로 판단할 수 있을 만큼 똑똑해졌다면 걷어내는 쪽이 유리하죠. 반면 “이 프로젝트가 무엇이고, 내가 무엇을 원하는지”에 대한 맥락은 모델이 똑똑해질수록 오히려 더 정교하게 활용됩니다. LangChain이 시스템 프롬프트와 도구 설명문을 걷어낸 건 전자였고, 사용자가 직접 채워 넣는 프롬프트나 맥락은 그대로 남겨뒀습니다.
이 구분은 실무자가 직접 만드는 에이전트 워크플로우에도 그대로 적용됩니다. 스킬이나 설정 파일에 절차를 빼곡히 채워 넣기보다, 지금 쓰는 모델이 그 절차 없이도 판단할 수 있는지부터 확인해볼 만하죠. 반대로 “내가 무엇을 원하는가”를 명확히 전달하는 부분은 아무리 모델이 발전해도 대신해줄 수 없는, 계속 남겨둬야 할 영역입니다.

답글 남기기