05 · 하네스 엔지니어링 — AI가 일하는 방식을 개선하기

코딩 에이전트에 버그 수정을 맡기면, 모델은 코드를 읽고 수정할 도구를 호출합니다. 실행 시스템은 그 호출을 처리하고 결과를 모델에 돌려줍니다. 테스트가 실패하면 모델은 오류를 읽고 다시 수정을 시도합니다. 이 과정이 이어지려면 모델 외에도 도구를 실행하고, 결과를 보관하고, 다음 판단에 필요한 정보를 전달하는 프로그램이 있어야 합니다.

이처럼 모델을 둘러싸고 작업의 실행을 관리하는 시스템을 하네스(harness)라고 부릅니다. 하네스는 도구 호출과 컨텍스트뿐 아니라 작업 기록, 평가, 권한도 관리합니다. 테스트를 실행했어도 실패 내용을 다음 입력에서 빠뜨리면 모델은 수정에 필요한 근거를 얻지 못합니다. 어떤 정보를 전달하고 어떤 순서로 작업하게 하는지는 결과에 영향을 주며, 이 부분은 모델 가중치를 다시 학습하지 않고도 바꿀 수 있습니다.

Lilian Weng의 Harness Engineering for Self-Improvement(2026-07-04)를 바탕으로 쓴 한국어 요약입니다. 주요 연구는 해당 논문도 함께 확인했습니다. 도식 두 장은 개념을 설명하기 위해 새로 그렸습니다.

실행 결과가 다음 판단에 쓰이기까지

한 번의 도구 호출로 끝나지 않는 작업에서는 계획, 실행, 검사, 수정이 반복됩니다. 하네스는 도구의 출력과 오류를 받아 검사 결과를 기록하고, 다음 실행에 필요한 내용을 모델의 입력에 반영합니다. 모델은 그 정보를 바탕으로 다음 행동을 선택합니다.

작업이 길어지면 코드 변경 내역, 실험 결과, 오류 기록을 모두 매번 입력에 넣기 어렵습니다. 그래서 기록은 파일에 보관하고 필요한 때 찾아 읽게 합니다. 파일에 남긴다는 것만으로 기억 문제가 해결되지는 않습니다. 다음 판단에 어떤 기록이 필요한지 고르고, 그 기록을 다시 찾을 수 있어야 합니다.

여러 작업을 병렬로 진행할 때도 이런 관리가 필요합니다. 주 에이전트가 하위 에이전트에 조사를 맡기거나 백그라운드에서 실험을 실행했다면, 각 작업이 끝났는지 확인하고 실패한 작업의 로그를 읽어야 합니다. 결과와 상태를 파일로 남기면 중간에 실행이 끊겨도 진행 상황을 다시 파악하고, 각 작업의 결과를 모아 이어갈 수 있습니다. Weng이 정리한 하네스 설계 패턴은 이런 반복 실행, 지속적인 기록 보관, 병렬 작업 관리를 포함합니다.

경험을 지침으로 남기고, 지침을 만드는 방법을 고치기

실패한 테스트를 보고 코드를 수정하면 지금 맡은 작업이 나아집니다. 그 실패에서 얻은 교훈을 지침으로 남기면 이후의 작업에도 활용할 수 있습니다. 여기서 개선하는 대상은 현재의 답안에서 다음 작업에 전달할 정보로 넓어집니다.

ACE는 실행 결과에서 얻은 교훈을 작업 지침에 축적합니다. 에이전트가 기존 지침을 참고해 작업을 수행하면, 성공과 실패 기록에서 배울 점을 추출하고 지침의 해당 항목을 추가하거나 수정합니다. 지침 전체를 매번 짧게 다시 쓰면 특정 상황에서 필요한 세부 지식이 사라질 수 있으므로, 항목별로 갱신하는 방식을 사용합니다. 실행하고, 성찰하고, 지침을 정리하는 절차 자체는 정해져 있습니다.

그런데 같은 교훈이라도 무엇을 찾아보고 어떻게 골라 전달하느냐에 따라 모델이 활용할 수 있는 정보는 달라집니다. MCE는 컨텍스트의 내용과 컨텍스트를 만드는 방법을 함께 개선 대상으로 삼습니다. 작업을 수행하는 쪽에서는 주어진 방법에 따라 컨텍스트를 다듬고, 그 방법을 개선하는 쪽에서는 어떤 정보의 검색·선택·구성 방식이 더 나은 결과를 내는지 탐색합니다. MCE에서 말하는 스킬은 이 컨텍스트 구성 방법을 담습니다. ACE가 정해진 절차에 따라 지침을 갱신한다면, MCE는 지침을 갱신하는 방법까지 바꿔 봅니다.

개선 범위는 작업 순서로도 넓어질 수 있습니다. 모델에 무엇을 알려 줄지에 더해, 언제 도구를 쓰고 어떤 결과를 받은 뒤 다음 단계로 넘어갈지를 바꾸는 것입니다. ADAS에서는 에이전트를 설계하는 메타 에이전트가 기존 설계 기록을 참고해 새 워크플로를 코드로 작성합니다. 이렇게 만든 에이전트를 평가하고 유용한 설계를 다시 기록에 남겨 다음 탐색에 활용합니다. 프롬프트, 도구, 제어 흐름을 코드로 표현하므로 이들 모두가 수정 대상이 됩니다.

새 하네스를 만들고 이전 후보와 비교하기

실행 방식 자체를 바꾸려면 수정한 하네스로 과제를 수행해 보고 결과를 비교해야 합니다. 현재 과제에서 오류를 고치는 반복과, 앞으로 과제를 수행할 시스템을 고르는 반복이 함께 생기는 것입니다. 두 과정에서 바뀌는 코드는 다릅니다. 앞의 버그 수정에서는 과제로 받은 저장소의 코드를 고치지만, 하네스 개선에서는 모델에 정보를 주고 도구를 실행하는 프로그램을 고칩니다.

Meta-Harness는 정보를 저장하고, 조회하고, 모델에 제시하는 하네스 코드를 탐색합니다. 새 하네스를 제안하는 코딩 에이전트는 이전 후보의 소스 코드, 점수, 실행 기록을 파일시스템에서 찾아봅니다. 이전 시도를 모두 하나의 프롬프트에 넣는 대신 필요한 파일을 읽고, 그 근거로 다음 후보를 작성합니다. 후보로 과제를 실행한 결과도 다시 기록되므로, 다음 수정은 앞선 성공과 실패를 참고할 수 있습니다.

이때 매번 하나의 후보만 남기면 그 설계에서 벗어난 방법을 탐색하기 어려워질 수 있습니다. Darwin Gödel Machine(DGM)은 에이전트 후보들을 보관하고, 그중 하나를 골라 하네스 코드를 수정한 뒤 코딩 벤치마크로 검사합니다. 여러 후보를 남겨 두는 것은 서로 다른 개선 경로를 이어 갈 수 있게 하기 위한 설계입니다. 이 과정에서 기반 모델의 가중치는 고정되어 있고, 모델 주변의 코드가 바뀝니다.

점수와 후보 코드만으로는 어떤 수정이 도움이 되었는지 설명하기 어려울 수 있습니다. AHE는 실행 기록에서 실패 원인을 찾고, 그 원인과 관련된 하네스 구성요소를 수정하도록 합니다. 수정할 때는 근거가 된 실패 기록과 예상 효과를 함께 명시하고, 다음 평가에서 그 예상을 확인합니다. 점수가 올랐는지와 함께 어느 변경이 어떤 실패를 줄였는지 추적하려는 방식입니다.

프로그램을 개선하는 절차도 코드로 작성되어 있다면 그 코드 역시 수정할 수 있습니다. STOP은 다른 프로그램을 수정하고 평가하는 ‘개선기’를 두고, 그 개선 절차를 개선기 자신의 코드에도 적용합니다. 한 프로그램의 답을 더 좋게 만드는 데서 나아가, 이후 여러 프로그램을 더 잘 개선할 수 있는지를 평가하는 것입니다. STOP 역시 모델 가중치를 고정한 채 이 과정을 수행합니다.

모델 학습까지 포함하면 무엇이 달라지는가

STOP과 DGM에서 모델이 더 나은 결과를 내도록 바뀌는 것은 주변 프로그램입니다. 모델 가중치도 함께 갱신한다면 개선 범위에 학습이 추가됩니다. 어느 쪽을 바꾼 결과인지 구분하는 일도 그만큼 복잡해집니다.

SIA는 하네스 개선과 모델 가중치 갱신을 하나의 과정에 결합한 초기 연구입니다. 하네스를 제안하는 메타 에이전트, 그 하네스로 작업을 수행하는 에이전트, 실행 기록을 보고 다음 갱신을 결정하는 피드백 에이전트를 둡니다. 피드백 에이전트는 최근 기록을 바탕으로 하네스를 바꿀지 모델 가중치를 갱신할지 선택합니다.

Weng은 이 연구의 근거를 잠정적으로 봅니다. 작업을 수행하는 모델보다 설계와 피드백에 쓰는 모델의 능력이 높고, 비교 대상으로 둔 시스템도 약해 결과를 해석하기 어렵기 때문입니다. 하네스와 가중치를 함께 개선하는 방향을 제시했다는 점과 그 효과를 충분히 입증했다는 판단은 구분해야 합니다. 원문: 가중치와의 공동 최적화

Weng은 단기적으로 하네스를 개선하는 방식에서 재귀적 자기개선(RSI)이 진전될 것으로 전망합니다. AI가 자신의 결과물을 만드는 절차를 고치고, 개선된 절차를 다시 다음 개선에 활용하는 경로입니다. 이는 저자의 전망이며, 앞선 연구들이 지속적인 자기개선의 가능성까지 입증했다는 뜻은 아닙니다.

평가가 놓치는 것은 개선 과정도 놓칠 수 있다

하네스 후보를 고르는 과정은 무엇을 성공으로 평가하는지에 의존합니다. 테스트 결과처럼 빠르고 명확하게 확인할 수 있는 기준이 있으면 후보를 반복해서 비교하기 쉽습니다. 그러나 연구의 새로움이나 장기적인 가치는 그런 방식으로 채점하기 어렵습니다. 평가 기준이 실제로 원하는 성과를 충분히 담지 못하면, 점수가 오른 하네스가 더 유용한 일을 한다고 판단하기도 어렵습니다.

기억을 유지하는 문제도 개선 과정 전체에 걸쳐 있습니다. 실행 기록이 늘어날수록 중요한 맥락을 오래 보존하고 다시 찾을 수 있어야 합니다. 성공한 시도만 남기면 이미 실패한 방법을 되풀이할 수 있으므로, 부정적 결과 역시 다음 판단에 쓸 수 있는 기록으로 남겨야 합니다. 여러 후보를 보관하더라도 현재 점수가 높은 해법만 계속 선택하면 비슷한 설계에 탐색이 몰릴 수 있습니다. 나중에 유용해질 방법이 처음부터 높은 점수를 받는다고 보장할 수 없기 때문입니다.

평가 점수를 올리는 방식이 평가의 허점을 이용하는 것일 수도 있습니다. 테스트에만 맞추거나 평가 모델의 약점을 공략하는 보상 해킹이 그 예입니다. 또한 당장의 테스트를 통과한 코드라도 유지보수하기 쉬운지는 별도로 확인해야 합니다. 짧은 실행에서 얻은 점수만으로 여러 개발자가 오래 관리할 저장소의 상태까지 판단할 수는 없습니다.

이 때문에 Weng은 평가기와 권한 통제를 하네스가 스스로 수정하는 범위 밖에 둘 것을 제안합니다. 하네스를 개선하는 프로그램이 자기 점수를 매기는 기준이나 허용된 행동의 범위까지 바꾸게 두면, 성능 향상과 기준 우회를 구분하기 어려워집니다. 개선에 사용하지 않은 별도 과제로 검사하고 실행 기록도 검토해야 합니다. 이런 검증을 얼마나 자동화할 수 있는지는 여전히 남은 과제입니다. 원문: 남은 과제

에이전트의 구성 요소와 용어는 03 에이전트 개념 정리에서, 화면 조작에 적용된 실행 구조는 04 Computer Use Agent에서 이어 볼 수 있습니다.