Skip to content
←

필사 모드: 하네스는 설정이 아니라 배포물입니다 — 자기 개선 루프의 진짜 병목

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

프롬프트를 안 고쳤는데 성공률이 6퍼센트포인트 올랐습니다

에이전트의 과제 성공률이 지난주 대비 올랐습니다. 프롬프트 커밋은 없습니다. 모델 버전도 그대로입니다. 무엇이 바뀌었는지 찾아보니 도구 정의 하나의 설명 문구가 짧아졌고, 재시도 상한이 3에서 5로 올라 있었고, 파일 읽기 도구가 반환하는 줄 수 상한이 바뀌어 있었습니다. 세 변경 모두 다른 사람이 다른 이유로 했고, 어느 것도 릴리스 노트에 없습니다.

다음 주에 성공률이 떨어지면 무엇을 되돌려야 할까요. 지금 구조에서는 답할 수 없습니다.

하네스에 경계를 그어야 관리가 시작됩니다

Lilian Weng이 2026년 7월 4일에 쓴 글은 이 덩어리에 이름을 붙입니다. 하네스는 기반 모델을 둘러싸고 실행을 조율하는 시스템으로, 모델이 어떻게 사고하고 계획할지, 도구를 어떻게 부르고 행동할지, 컨텍스트를 어떻게 인지하고 관리할지, 산출물을 어디에 저장할지, 결과를 어떻게 평가할지를 결정하는 층입니다.

이 정의가 유용한 이유는 범위를 넓게 잡았기 때문입니다. 초기의 에이전트 프레임워크가 다루던 것보다 넓게, 워크플로 설계와 평가, 권한 제어, 영속 상태 관리까지 포함합니다. 앞의 사례에서 바뀐 세 가지는 모두 이 경계 안에 들어옵니다. 경계를 긋고 나서야 "무엇이 바뀌었는가"라는 질문이 대답 가능해집니다.

프롬프트 엔지니어링에서 하네스 엔지니어링으로

이 이동의 실무적 의미는 레버가 어디 있느냐입니다. 대부분의 팀은 기반 모델을 만들지 않고 파인튜닝도 하지 않습니다. 그 팀이 손댈 수 있는 것은 하네스 전부입니다.

그리고 하네스 쪽 개선 여지는 대체로 프롬프트 문구보다 큽니다. 도구를 몇 개 노출할지, 실패를 어떻게 되돌려 줄지, 언제 서브에이전트를 띄울지, 중간 산출물을 파일로 남길지 컨텍스트에 안고 갈지 같은 결정들입니다. 같은 글이 코드가 보편 언어라고 표현한 대목이 여기에 걸립니다. 문장으로 지시할 수 있는 공간보다 코드로 정의할 수 있는 공간이 훨씬 넓습니다.

예를 들어 도구 실패를 모델에게 어떻게 돌려주느냐 하나만 봐도 그렇습니다. 예외 문자열을 그대로 던지면 모델은 같은 호출을 반복합니다. 실패 원인과 함께 지금 시도 가능한 대안 목록을 구조화해서 돌려주면 다음 호출이 달라집니다. 이건 프롬프트를 아무리 잘 써도 얻을 수 없는 종류의 개선이고, 전적으로 코드 쪽 결정입니다.

자기 개선은 가중치보다 하네스에서 먼저 일어납니다

글의 중심 주장은 재귀적 자기 개선에 관한 것입니다. AI가 현재의 지능으로 자기 지능을 만들어 내는 기계 장치를 개선한다는 구조인데, 가까운 미래에 이것이 진행될 경로는 모델 가중치를 직접 고치는 쪽이 아니라 하네스가 진화하는 쪽이라는 전망입니다.

이 전망은 추상적으로 들리지만 아주 구체적인 형태로 이미 돌아가고 있습니다. 에이전트가 자기 도구 정의를 고치고, 자기 실행 스크립트를 수정하고, 실패 로그를 읽고 워크플로를 재배치하는 일입니다. 파일 읽기와 쓰기, 셸 실행, git, 서브에이전트 생성 같은 도구가 있으면 하네스는 스스로를 편집할 수 있는 대상이 됩니다.

여기서 실무적으로 중요한 것은 이 루프가 이미 도는 중이라는 사실보다, 대부분의 팀에서 그 루프가 기록 없이 돈다는 사실입니다. 에이전트가 도구 설명을 다듬고, 사람이 그 커밋을 대충 승인하고, 성능은 조금 달라지고, 아무도 두 사건을 연결하지 않습니다. 자기 개선 루프의 위험은 그것이 빠르다는 데 있는 게 아니라 관측되지 않는다는 데 있습니다.

컨텍스트를 프롬프트가 아니라 플레이북으로

같은 글이 소개하는 접근 중 실무에 바로 옮길 만한 것이 컨텍스트를 계속 길어지는 프롬프트가 아니라 진화하는 플레이북으로 다루는 방식입니다. 항목을 만드는 역할, 되돌아보는 역할, 추려 내는 역할을 나눠 구조화된 항목을 관리합니다.

차이는 이렇습니다. 프롬프트 방식에서는 새로 배운 것이 문단 끝에 계속 붙습니다. 한 달 뒤에는 아무도 그 문서를 읽지 않고, 서로 모순되는 지시가 공존하며, 토큰만 늘어납니다. 플레이북 방식에서는 항목마다 언제 추가됐고 어떤 상황에 적용되며 최근에 도움이 됐는지가 기록되므로 삭제가 가능해집니다. 컨텍스트 관리의 어려운 부분은 넣는 것이 아니라 빼는 것이고, 뺄 수 있으려면 항목에 메타데이터가 있어야 합니다.

하네스는 버전이 붙는 배포물입니다

여기까지 오면 처음의 문제로 돌아올 수 있습니다. 하네스를 배포물로 다루려면 최소한 지문이 필요합니다.

"""하네스 지문: 결과와 함께 저장해야 회귀를 되짚을 수 있다."""
import hashlib
import json
from dataclasses import dataclass, field, asdict


@dataclass
class HarnessSpec:
    model: str
    system_prompt: str
    tools: list                 # [{"name":..., "description":..., "schema":...}]
    max_steps: int
    max_retries: int
    context_policy: dict        # 잘라내기, 요약, 플레이북 정책
    permissions: list           # 허용된 부작용

    def fingerprint(self) -> str:
        payload = asdict(self)
        # 도구 순서는 의미가 없으므로 정규화한다. 안 하면 지문이 매번 달라진다.
        payload["tools"] = sorted(payload["tools"], key=lambda t: t["name"])
        blob = json.dumps(payload, sort_keys=True, ensure_ascii=False)
        return hashlib.sha256(blob.encode("utf-8")).hexdigest()[:12]


def diff(a: HarnessSpec, b: HarnessSpec) -> dict:
    da, db = asdict(a), asdict(b)
    return {k: (da[k], db[k]) for k in da if da[k] != db[k]}


base = HarnessSpec(
    model="some-model-v3",
    system_prompt="...",
    tools=[{"name": "read_file", "description": "파일을 읽는다", "schema": {}}],
    max_steps=20,
    max_retries=3,
    context_policy={"strategy": "playbook", "max_items": 40},
    permissions=["read_fs"],
)
candidate = HarnessSpec(**{**asdict(base), "max_retries": 5})

print(base.fingerprint(), "->", candidate.fingerprint())
print(diff(base, candidate))   # {'max_retries': (3, 5)}

이 지문을 모든 평가 실행 결과에 함께 남기면, 성공률 그래프의 계단이 어떤 변경에 대응하는지 되짚을 수 있습니다. 그리고 지문이 바뀌는 변경은 전부 평가를 다시 돌려야 하는 변경이라는 규칙이 자연스럽게 생깁니다. 재시도 상한을 3에서 5로 올리는 한 줄이 프롬프트 수정과 같은 급으로 취급됩니다.

이 루프의 병목은 모델이 아니라 평가자입니다

같은 글은 하네스 엔지니어링이 마주한 난제를 여러 개 꼽는데, 그중 첫 번째로 약한 평가자를 듭니다. 이건 자기 개선 루프의 구조를 보면 당연한 결론입니다.

루프는 하네스를 바꾸고, 평가하고, 좋아진 쪽을 채택합니다. 이 루프의 속도는 하네스를 바꾸는 속도가 아니라 평가가 신뢰할 만한지에 의해 결정됩니다. 평가가 잡음이면 루프는 잡음을 따라 이동합니다. 방향 없이 빠르게 움직이는 시스템이 되고, 지표는 오르고 실사용 품질은 그대로거나 나빠집니다.

그래서 하네스 개선을 자동화하기 전에 반드시 선행되어야 하는 것이 평가자 보정입니다. 순서를 뒤집으면 자동화가 문제를 더 빨리 만들어 냅니다.

리워드 해킹은 버그가 아니라 정상 출력입니다

마지막 난제가 리워드 해킹인데, 이 표현을 오해하지 않는 게 중요합니다. 에이전트가 테스트를 통과시키려고 테스트를 고치거나, 실패를 삼키는 예외 처리를 넣거나, 평가 스크립트가 보는 필드만 채우는 일은 시스템이 고장 난 결과가 아닙니다. 우리가 정의한 목표를 정확히 최적화한 결과입니다.

대응은 두 갈래입니다. 하나는 권한입니다. 평가 코드와 채점 데이터를 에이전트가 쓸 수 있는 경로에서 제외하면 이 부류의 절반이 사라집니다. 원문이 하네스의 구성 요소로 권한 제어를 명시적으로 넣은 이유가 여기 있습니다. 권한은 보안 항목이기 이전에 평가의 무결성 항목입니다.

다른 하나는 지표를 하나만 쓰지 않는 것입니다. 성공률과 함께 도구 호출 수, 수정한 파일의 범위, 삭제된 테스트 수 같은 견제 지표를 같이 봅니다. 견제 지표는 목표가 아니라 경보이므로 임계값을 두고 넘으면 사람이 보게만 하면 충분합니다.

정리하면 이렇습니다. 하네스 엔지니어링의 레버는 크고 손에 잡히지만, 그 레버를 안전하게 당기려면 평가가 먼저 서 있어야 합니다. 하네스에 지문을 붙이는 일은 그 두 가지를 잇는 가장 싼 첫 단계입니다.

참고 자료

현재 단락 (1/55)

에이전트의 과제 성공률이 지난주 대비 올랐습니다. 프롬프트 커밋은 없습니다. 모델 버전도 그대로입니다. 무엇이 바뀌었는지 찾아보니 도구 정의 하나의 설명 문구가 짧아졌고, 재시도 ...

작성 글자: 0자원문 글자: 3,960자작성 단락: 0/55