[Agent] 하네스 엔지니어링 — 어디까지 스스로 나아질 수 있나

Prime Agent 편에서 자기 하네스를 고치는 도구를 봤고, Continual Harness 편에서 그 근거가 되는 논문을 봤습니다.

그런데 이 둘이 전체 그림에서 어디쯤인지는 아직 흐릿했습니다. 마침 그 지형도에 해당하는 글이 있었습니다 — Lilian Weng의 Harness Engineering for Self-Improvement (2026-07-04).

이 글이 다루는 범위가 넓어서, 앞의 두 편이 이 안의 좌표로 정리됩니다. 실제로 Continual Harness 논문은 이 글에 직접 인용돼 있습니다.

하네스란 무엇인가

우리는 앞서 하네스를 “모델을 감싸는 것 전부”라고 대충 정리했는데, Weng은 훨씬 구체적으로 씁니다.

기반 모델을 둘러싸고 실행을 조율하는 시스템. 모델이 어떻게 사고하고 계획할지, 도구를 어떻게 호출하고 행동할지, 컨텍스트를 어떻게 인지하고 관리할지, 산출물을 어떻게 저장할지, 결과를 어떻게 평가할지를 결정한다.

즉 워크플로 설계, 평가 장치, 권한 통제, 영속 상태 관리까지 포함합니다. 모델 가중치를 뺀 나머지 전부라고 봐도 크게 틀리지 않습니다.

설계 패턴 세 가지

Weng은 반복해서 나타나는 패턴 셋을 꼽습니다.

패턴	내용
워크플로 자동화	계획 → 실행 → 반복의 목표 지향 루프
파일시스템을 영속 메모리로	산출물을 컨텍스트 밖에 저장해 장기 작업을 버틴다
서브에이전트와 백그라운드 작업	병렬 실행을 명시적이고 들여다볼 수 있게

여기서 재미있는 걸 발견했습니다. Prime Agent가 이 셋을 그대로 구현하고 있습니다.

Weng의 패턴	Prime Agent
워크플로 자동화	/goal, /autonomous
파일시스템을 영속 메모리로	컨텍스트를 파이썬 변수·파일로 밖에 둠
서브에이전트와 백그라운드 작업	rlm() 비동기 호출, 데몬 기반 세션

우리가 “특이한 설계”라고 봤던 것들이, 지형도에서 보면 교과서적인 사례였던 셈입니다.

자동화의 층위

글의 본론은 하네스를 누가 개선하느냐가 어떻게 옮겨가는지입니다.

사람의 손을 떠나는 순서 — 원문의 구성을 층위로 다시 그린 것입니다

맨 아래는 사람이 프롬프트와 워크플로를 직접 쓰는 단계입니다. 그 위로 올라가면서 컨텍스트 관리가 자동화되고, 워크플로 구성 자체를 탐색으로 찾고, 하네스가 자기 약점을 찾아 스스로 고치고, 마지막에는 하네스 개선과 모델 가중치 갱신이 같은 루프에 들어갑니다.

우리가 다룬 둘이 어디 있는지가 이제 분명합니다. Prime Agent의 /refine은 네 번째 층, Continual Harness는 다섯 번째 층입니다.

각 층마다 여러 연구가 붙어 있습니다. 컨텍스트 쪽에는 ACE·Meta Context Engineering, 워크플로 쪽에는 AI Scientist·ADAS·AFlow, 자기개선 쪽에는 STOP·Self-Harness, 진화 탐색 쪽에는 AlphaEvolve·Darwin Gödel Machine 같은 이름들입니다.

뿌리는 1965년

Weng은 이 흐름을 I. J. Good(1965)까지 거슬러 올립니다. 인간을 모든 지적 활동에서 능가하고 더 나은 기계를 설계할 수 있는 “초지능 기계” 개념입니다. Yudkowsky(2008)가 이를 재귀적 자기개선(RSI)으로 형식화했고요.

여기서 Weng의 관점이 나옵니다. 당장 현실적인 경로는 가중치를 직접 고쳐 쓰는 게 아니라 하네스를 개선하는 쪽이라는 것입니다.

다만 — 지능이 여전히 핵심이다

글에서 가장 중요한 단서입니다.

하네스 개선은 더 나은 활용을 가능하게 할 뿐, 기반 모델의 능력을 대체하지 못한다.

하네스를 아무리 정교하게 다듬어도 모델이 못 하는 일을 하게 만들 수는 없습니다. 이 분야를 과대평가하지 않게 잡아주는 문장이라고 봅니다.

아직 안 풀린 문제 일곱

글의 후반이 오히려 더 값집니다. Weng이 미해결로 남겨둔 것들입니다.

문제	내용
약한 평가자	연구 성과에는 빠르고 정확한 검증자가 없다. “연구 감각”은 측정이 훨씬 어렵다
컨텍스트 수명주기	자율성이 커질수록 메모리 관리가 지능 자체의 문제가 된다
부정적 결과	LLM은 성공 사례를 보고하도록 편향돼 있다. 실패한 시도도 남겨야 한다
다양성 붕괴	최적화 루프가 알려진 패턴만 파고들어 획일화된다
보상 해킹	자기개선 루프가 측정의 허점을 악용한다
장기적 성공	현재 평가자는 단기 지표만 본다. 코드 건강성·호환성은 다루지 못한다
사람의 역할	사람은 제거되는 게 아니라 위층으로 올라가야 한다

보상 해킹 항목에 붙은 처방이 특히 눈에 띕니다.

평가자와 권한 통제는 루프 바깥에 있어야 할 것이다.

이게 추상적인 원칙이 아닙니다. Prime Agent가 /refine으로 하네스를 고치게 하면서도 기본 시스템 프롬프트는 절대 건드리지 않고 스냅샷 롤백을 남기는 설계가 정확히 이 처방입니다. 스스로 고치되, 고칠 수 없는 영역을 루프 밖에 둔 것입니다.

읽고 나서 — 개인적인 생각

여기부터는 제 판단입니다.

“하네스”라는 말이 자리를 잡았습니다. 며칠 사이에 본 것만 해도 Prime Agent 문서, Continual Harness 논문, TokenPilot 논문(“프레임워크 하네스”), 그리고 이 글입니다. 서로 다른 팀이 같은 단어를 같은 뜻으로 씁니다. 용어가 정착했다는 건 문제가 공유되고 있다는 뜻이라 눈여겨볼 만합니다.

실무자에게 당장 쓸모 있는 건 사다리가 아니라 일곱 가지 문제입니다. 자동화 층위는 연구 지형도지만, “평가자가 약하다”, “실패 기록이 안 남는다”, “단기 지표만 본다”는 지금 우리가 에이전트를 쓰면서 그대로 겪는 일입니다. 자기개선까지 안 가더라도 하네스를 손볼 때 체크리스트로 쓸 수 있습니다.

“사람은 위층으로 올라간다”가 가장 현실적인 결론 같습니다. 자동화 이야기는 대개 사람을 빼는 방향으로 흐르는데, Weng은 루프 안에서 빼되 더 높은 추상 수준에서 개입점을 유지하라고 합니다. 평가 기준을 정하고 권한 경계를 긋는 일은 여전히 사람 몫이라는 뜻으로 읽었습니다.

한 가지 아쉬운 건 층위 간 비용 비교가 없다는 점입니다. 위로 갈수록 좋아 보이지만 탐색 비용도 함께 오릅니다. 어느 지점이 수지가 맞는지는 이 글에서 답하지 않습니다 — 아마 아직 아무도 모를 겁니다.

정리

하네스 엔지니어링은 모델을 못 건드릴 때 남는 지렛대입니다.

가중치를 학습시킬 수 없는 대부분의 사용자에게, 성능을 끌어올릴 수 있는 유일한 영역이 하네스입니다. 그래서 이 분야가 빠르게 커지고 있고, 이제는 그 개선마저 자동화하려는 시도가 나오고 있습니다.

다만 Weng이 붙인 단서를 같이 기억하는 게 좋겠습니다. 하네스는 모델의 능력을 끌어내는 것이지 만들어내는 것이 아닙니다.

이것으로 하네스 3부작을 마칩니다 — 도구(Prime Agent), 논문(Continual Harness), 그리고 지형도.

참고

• Harness Engineering for Self-Improvement — Lilian Weng, 2026-07-04 (2026-08-12 확인). 이 글의 사실관계는 원문에서 확인했습니다
• Prime Agent 뜯어보기 — 3부작 1편, 하네스를 고치는 도구
• Continual Harness — 2편, 그 근거가 된 논문. 위 원문에도 인용돼 있습니다