Google 개발자 블로그가 9월 2일 하니스(harness) 엔지니어링을 다룬 글을 게재했다. 필자는 Shir Meir Lador다. 이 글이 제시하는 하니스의 정의는 명료하다——LLM을 감싸는 모든 결정론적 구성 요소, 즉 오케스트레이션 레이어, 실행 샌드박스, 상태 영속화, 검증 도구가 모두 여기에 포함된다.
글은 서두에서 인상적인 수치 대비를 제시한다. OpenAI의 한 실험적 제품에서는 손으로 작성한 코드가 0줄이었고, 엔지니어 3명이 모델이 생성한 코드만으로 사내 테스트 버전을 만들어 배포했다는 것이다. 필자가 여기서 끌어내는 논점은 모델의 능력 자체가 아니라, 모델을 통제 가능한 프로세스 안에 가둬 두는 구조에 있다.
고삐, 눈가리개, 그리고 트랙
글은 경마에 빗댄 비유를 사용한다. 모델은 말이고, 하니스는 트랙과 눈가리개와 고삐로서 말이 한 방향으로 달리도록 붙잡아 준다.
"The harness is composed of all the deterministic components that wrap the LLM."
하니스란 LLM을 감싸는 모든 결정론적 구성 요소로 이루어진다.
이 정의는 그동안 '프롬프트 엔지니어링'이라는 이름 아래 뭉뚱그려졌던 작업의 위치를 바꿔 놓는다. 모델의 행동을 제약하는 방법은 결국 두 가지뿐이다. 프롬프트에 적어 넣거나, 모델 바깥의 코드에 적어 넣는 것이다. 전자는 모델이 스스로 따르는 데 의존하므로 모델이 바뀔 때마다 다시 조정해야 한다. 후자는 하드 제약이어서 모델이 세대교체를 거쳐도 그대로 작동한다. 지난 1년간 에이전트 제품을 만들어 온 팀 대부분은 두 방식을 모두 시도했고, 그 대가도 함께 치렀다. 프롬프트에 적어 둔 '테스트 파일을 수정하지 말라'는 문장도, 모델이 긴 컨텍스트 속에서 서른 번째 턴쯤 되면 그 지시를 선택적으로 못 본 척하기 시작한다.
세 가지 설계 원칙
엄격한 경계. 에이전트를 샌드박스 안에 가둬 프로덕션 데이터에 손댈 기회 자체를 주지 않는다. 글의 시연에서 에이전트는 ./sandbox 디렉터리 안에서만 파일을 쓸 수 있고, 그 경계를 벗어나는 작업은 애초에 실행되지 않는다.
복구 루프. 오류를 그대로 사람에게 던져서는 안 된다. 테스트가 실패하면 하니스는 깨끗한 로그를 모델에 되먹여 스스로 고치게 한다. ADK 2.0이 여기서 내놓은 답은 그래프 기반 워크플로다——검증 단계 자체가 그래프 안의 라우팅 노드이며, 실행이 실패하면 제어 흐름이 자동으로 생성 노드로 돌아간다. 오케스트레이션 코드에 재시도 로직을 직접 작성할 필요가 없다.
점진적으로 탐색 가능한 저장소 구조. 수천 줄짜리 설명 파일을 한 번에 에이전트에게 던져 주지 말고, 저장소를 에이전트가 한 겹씩 파고들 수 있는 구조로 만들어 필요할 때마다 맥락을 발견하게 한다.
함께 제공되는 Antigravity SDK가 담당하는 것은 로컬 환경 쪽이다——작업 공간의 경계를 정하는 동시에 메모리 영속화를 제공한다. 두 도구를 합치면 '에이전트가 어디서 실행되는가'와 '잘못됐을 때 어떻게 되돌리는가'라는 두 가지 문제를 모두 다루게 된다.
5회 상한과 그 스위치
시연에서 자가 치유 루프는 한 사이클 전체를 온전히 돌린다. 에이전트가 제한된 샌드박스 안에서 코드를 쓰고, 테스트가 자동으로 실행되고, 테스트가 실패하고, 로그가 되먹여지고, 에이전트가 수정하고, 다시 실행한다. 상한은 5회로 설정돼 있으며, 상한에 도달하면 하니스가 루프를 끊는다. 필자는 이를 킬 스위치(kill switch)라고 부른다.
이 '5'라는 숫자는 글 전체에서 가장 실용적인 숫자다. 자가 치유 루프의 전형적인 실패 패턴은 모델이 두 가지 오류 상태 사이를 오가며 매 회차마다 토큰만 태우고 수렴하지 못하는 것이다. 하드 상한을 두는 것은 모델도 고치지 못하는 경우가 있다는 사실을 미리 인정하고, 문제를 더 빨리 사람의 손으로 돌려보낸다는 뜻이다. 이 스위치가 없다면, 궤도를 벗어난 루프는 아무도 지켜보지 않는 밤사이에 예산을 모두 태워버릴 수 있다.
이를 올해 상반기에 유행한 에이전트 프레임워크들과 비교해 보면 무게중심의 이동이 뚜렷하다. 초기 프레임워크가 주로 이야기한 것은 오케스트레이션이었다——여러 에이전트를 어떻게 엮을지, 역할을 어떻게 나눌지, 메시지를 어떻게 주고받을지. 지금 이야기되는 것은 검증과 경계다——실행을 어디에 둘지, 오류를 어떻게 되돌릴지, 언제 멈출지. 전자가 푸는 문제는 '일단 돌아가는가'이고, 후자가 푸는 문제는 '실제 프로젝트에 안심하고 맡길 수 있는가'다.
중국 팀 입장에서는 ADK 2.0과 Antigravity SDK라는 구체적인 도구 자체는 그대로 쓰기 어려울 수 있지만, 세 가지 원칙만큼은 그대로 가져갈 수 있다. 샌드박스, 복구 루프, 점진적 컨텍스트는 자체 개발하는 어떤 코딩 에이전트도 피해 갈 수 없는 과제이며, 차이는 그것을 미리 설계해 두느냐, 아니면 에이전트가 테스트 파일을 한 번 지워 버린 뒤에야 뒤늦게 보완하느냐일 뿐이다.
참고 출처: Google 개발자 블로그, CocoLoop, ADK 및 Antigravity SDK 프로젝트 문서. 하니스의 정의, 세 가지 설계 원칙, 5회 상한은 원문과 대조해 확인했으며, 손코드 0줄과 엔지니어 3명이라는 수치는 원문 서술을 인용한 것이다.