HarnessDev: 스스로 인프라를 구축하는 LLM
ByteDance와 대학 연구진은 대규모 언어 모델(LLM)이 Agent Harnesses라고 불리는 자신만의 "에이전트 운영체제"를 작성할 수 있게 해주는 프레임워크인 HarnessDev를 출시했습니다. 연구팀은 LLM에 최소한의 스타터 키트만 제공하고 나머지는 모델이 직접 채우도록 하여, 사람이 모든 코드를 입력하지 않고도 AI가 자체적인 도구 사용 루프, 검증 단계 및 오류 처리를 실행하는 제어 계층을 어떻게 구축할 수 있는지 보여주었습니다.
자체 구축된 하네스가 중요한 이유
AI 에이전트는 단일 프롬프트 어시스턴트에서 API를 호출하고 데이터베이스를 쿼리하며 결과를 결합하는 다단계 작업자로 진화했습니다. 지금까지 개발자들은 모델에게 언제 검색 도구를 호출할지, 중간 상태를 어떻게 저장할지, 최종 답변을 어떻게 검증할지를 지시하는 오케스트레이션 코드를 직접 작성해 왔습니다. HarnessDev는 이 모델을 뒤집습니다. seed harness가 루프, 도구 선택, 상태 추적을 위한 기본 기능과 같은 최소한의 스캐폴딩(scaffolding)을 제공하면, LLM이 이를 기능이 완비된 런타임으로 확장합니다.
논문의 벤치마크에서 모델은 18개의 서로 다른 하네스를 생성했으며, 기존 시드에 17,000줄 이상의 코드를 추가했습니다. 각 하네스는 루프 실행, 적절한 도구 선택, 컨텍스트 유지, 상태 추적, 결과 검증 및 오류 복구 등 작업의 전체 라이프사이클을 관리했습니다.
연구를 통해 밝혀진 숨겨진 비용
수치상으로는 인상적이지만, 저자들은 단순한 구현이 곧 실용적인 사용을 의미하는 것은 아니라고 경고합니다.
- 사용되지 않는 구성 요소 – 생성된 코드의 상당 부분이 실제 작업 실행 중에 전혀 실행되지 않았습니다. LLM은 에이전트가 호출하지 않는 함수를 작성하여, 가치를 제공하지 못한 채 코드 베이스만 비대하게 만들었습니다.
- 모델 종속성(Model lock-in) – 하네스는 이를 생성한 특정 LLM에 맞춰 조정되는 경향이 있었습니다. 동일한 하네스를 다른 모델에 전달했을 때 성능이 눈에 띄게 저하되었는데, 이는 자동 생성된 제어 로직에 모델 특유의 특성이 포함되어 있음을 시사합니다.
- 검증 격차 – 한 테스트 하네스는 99%(100회 실행 중 99회)의 성공률을 보고했지만, 실제 정답률은 **48%**에 불과했습니다. 강력한 검증이 없다면 에이전트는 틀린 답을 자신 있게 제시할 수 있습니다.
- 토큰 오버헤드 – 연산 비용의 대리 지표인 토큰 사용량이 극적으로 차이 났습니다. 어떤 하네스는 동일한 결과를 얻기 위해 다른 하네스보다 7배 더 많은 토큰을 필요로 했으며, 이는 실제 운영 환경에서의 확장성에 대한 우려를 불러일으켰습니다.
이러한 발견은 코드가 LLM에서 생성되더라도 규율 있는 설계가 필요함을 강조합니다.
개발자가 유의해야 할 사항
- 하네스 설계를 아키텍처로 취급하십시오 – 모델이 "그냥 알아서 잘 작동할 것"이라고 기대하지 마십시오. LLM이 내용을 채우기 전에 루프 제어, 도구 선택, 상태 처리 및 검증을 위한 명확한 모듈을 정의해야 합니다.
- 강력한 검증 체계를 구축하십시오 – 에이전트의 주장을 정답(ground truth) 또는 보조 모델과 비교하는 명시적인 체크 로직을 삽입하십시오. 99%의 자가 보고 성공률에도 불구하고 48%의 정확도만 기록한 이번 연구 결과는 검증이 사후 고려 사항이 되어서는 안 된다는 것을 보여줍니다.
- 토큰 예산을 관리하십시오 – 정교한 하네스는 토큰 사용량을 급증시킬 수 있습니다. 숨겨진 비용 폭발을 방지하기 위해 초기 단계에서 다양한 하네스 변형 모델의 프로파일을 분석하십시오.
- 여러 모델에 걸쳐 테스트하십시오 – 동일한 하네스를 여러 LLM 백엔드에서 실행해 보십시오. 성능이 급격히 저하된다면, 모델에 구애받지 않는(model-agnostic) 설계가 필요하거나 모델별로 별도의 하네스를 만들어야 할 수도 있습니다.
요약: HarnessDev는 LLM이 운영체제와 유사한 제어 코드를 스스로 초안할 수 있음을 증명합니다.