하네스 엔지니어링: AI 모델을 부품으로 다루는 법

에이전트가 또 엉뚱한 파일을 건드렸습니다. 이런 순간 대부분은 모델을 의심합니다. 더 좋은 모델로 갈아타거나, 프롬프트에 경고 문장을 한 줄 더 답니다. 그런데 실패의 진짜 원인이 모델인 경우는 생각보다 적습니다. 모델을 감싸고 있는 바깥 구조, 그러니까 하네스가 허술한 것입니다.

미첼 해시모토는 에이전트를 한 줄로 정리했습니다. "Agent = Model + Harness." 모델은 부품이고, 그 부품을 언제 어떻게 부를지 통제하는 나머지 전부가 하네스입니다. 실리콘밸리 개발자들 사이에서 도는 문장이 핵심을 더 날카롭게 찌릅니다. 당신이 모델이 아니라면, 당신은 하네스입니다.

프롬프트에서 컨텍스트, 그리고 하네스로

AI를 다루는 수준은 세 단계로 깊어집니다. 처음에는 프롬프트를 잘 쓰는 데 매답니다. 다음에는 어떤 맥락을 모델에 넣어 줄지를 설계합니다. 마지막 단계가 하네스 엔지니어링입니다. 모델 호출 하나를 함수처럼 보고, 그 함수를 둘러싼 상태 기계와 도구와 검증 루프를 직접 짜는 일입니다.

차이는 책임의 위치에 있습니다. 프롬프트 엔지니어링이 모델에게 잘 부탁하는 기술이라면, 하네스 엔지니어링은 모델이 실수해도 시스템이 무너지지 않도록 바깥을 설계하는 기술입니다. 여기서 한 가지 원칙이 따라옵니다. 하네스의 신뢰도가 모델 출력 신뢰도의 상한선입니다. 아무리 좋은 모델을 꽂아도, 하네스가 부실하면 결과는 그 부실함을 넘지 못합니다.

하네스는 네 개 층으로 쌓인다

잘 만든 하네스를 뜯어보면 네 개 층이 보입니다.

맨 아래에 모델이 있습니다. 똑똑하지만 자주 변덕을 부립니다. 그 위에 결정론적 상태 기계가 앉습니다. 작업을 pending에서 시작해 completed나 blocked나 error로 옮기는, 모호함이 없는 흐름 제어입니다. 다시 그 위에 도구 생태계가 붙습니다. 스킬이나 도메인 도구를 필요할 때만 불러옵니다. 가장 위에는 하네스가 자기 자신을 들여다보는 자기 진단이 놓입니다. 맥락이 제대로 주입됐는지 확인하고 비용을 잽니다.

여기서 놓치면 안 되는 사실이 있습니다. 모델은 가장 아래 칸에 있습니다. 흐름을 쥔 쪽은 상태 기계입니다. 모델이 아닙니다. 모델은 한 칸씩 일을 하고, 다음 칸으로 넘어갈지는 결정론적 코드가 정합니다.

이 구조 안에서 모델은 세 가지 역할로 나뉘어 움직입니다. 작업 단계를 설계하는 Planner, 그 계획대로 결과물을 만드는 Generator, 결과를 검증하고 틀리면 다시 시키는 Evaluator입니다. 한 모델에 전부 맡기지 않고 역할을 쪼개면, 생성과 검증이 분리되어 틀린 결과가 슬쩍 통과되는 일이 줄어듭니다.

좋은 하네스를 가르는 다섯 가지

구조만으로는 부족합니다. 실제로 굴러가는 하네스에는 반복해서 등장하는 설계 결정이 있습니다.

첫째, 모델이 상태를 직접 쓰게 합니다. 하네스가 모델 출력을 파싱해서 "아마 끝난 것 같다"고 추정하는 순간 변환 손실이 생깁니다. 모델이 상태 파일의 필드를 직접 적게 하면 그 손실 한 층이 사라집니다.

둘째, 이전 단계는 한 줄 요약만 넘깁니다. 직전 단계의 전체 출력을 다음 맥락에 그대로 쌓으면 토큰이 폭발하고 노이즈가 낍니다. 전체 출력은 디스크에 남겨 두고, 다음 단계에는 핵심 한 줄만 건넵니다.

셋째, 가드레일을 매번 자동으로 주입합니다. 지켜야 할 규칙을 설명으로만 두지 않습니다. 코딩 규칙은 물론이고 디자인 금기나 도메인 제약까지, 매 단계 머리에 코드로 밀어 넣습니다. 하네스는 결국 제품 의사결정을 코드로 박제하는 자리입니다.

넷째, 재시도에 맥락을 싣습니다. 실패하면 같은 일을 그냥 또 시키지 않습니다. 직전 에러 메시지를 다음 시도의 머리에 붙여 줍니다. 그래야 모델이 같은 실수를 반복하지 않습니다. 시도 횟수에는 상한을 둡니다.

다섯째, 막히면 멈춰서 사람을 기다립니다. API 키나 외부 인증처럼 자동화할 수 없는 상황은 blocked로 두고 대기합니다. 이걸 error로 처리해 무한 재시도에 빠지는 것이 흔한 사고입니다.

재현되지 않으면 신뢰도 없다

하네스의 신뢰는 재현성에서 나옵니다. 같은 입력을 두 번 넣으면 같은 출력이 나와야 합니다. 그래서 잘 만든 스킬은 자신을 만든 원본 프롬프트까지 파일로 남겨 둡니다. 이 산출물이 우연한 결과가 아님을, prompt에서 execution으로 이어진 결정론적 산물임을 증명하려는 장치입니다.

해시모토의 원칙 하나가 이 태도를 압축합니다. 실수할 때마다, 같은 실수를 막는 장치를 하나씩 쌓아 간다. 스킬 문서 안에 "이렇게 잘못 쓰기 쉽다"는 함정 목록을 미리 박아 두는 것도 같은 이유입니다. 미래의 다른 모델이 같은 자리에서 미끄러지지 않도록 길을 먼저 깔아 두는 셈입니다.

판단은 코드로, 설명은 모델로

신뢰가 걸린 결정은 가능하면 모델에서 떼어 냅니다. 점수를 매기거나 합의를 내는 일처럼 정확해야 하는 계산은 규칙 엔진에 맡깁니다. 모델은 그 결과를 사람이 읽을 말로 풀어 주는 역할만 맡습니다. 여러 에이전트의 의견을 모을 때도 합의 자체는 결정론적 레이어에서 계산한 뒤, 모델이 그 결론을 서술하게 합니다. 집계가 산문 속에 묻히면 어디서 틀어졌는지 되짚을 수 없기 때문입니다.

남는 것은 하네스다

모델은 계속 바뀝니다. 반년마다 더 좋은 모델이 나오고, 어제의 최선이 오늘의 기본값이 됩니다. 그 교체 속에서 살아남아 자산으로 쌓이는 쪽은 하네스입니다. 모델이 아닙니다. 더 똑똑한 모델을 기다리기 전에, 그 모델을 감쌀 구조부터 제대로 짜 두시길 권합니다. 거의 언제나 그쪽이 더 빠른 길입니다.