모델은 뇌이고, 하네스(Harness)가 나머지 모든 것이다

AI 에이전트가 실패했을 때, 가장 먼저 나오는 반응은 보통 다음과 같습니다: "더 나은 모델이 필요해."

하지만 대부분의 경우, 문제는 모델 자체가 아닙니다. 문제는 그 주변의 모든 것입니다.

이 "주변의 모든 것"에는 이름이 있습니다: 하네스(the harness).

하네스란 무엇인가?

언어 모델 자체는 한 가지 일만 합니다: 텍스트를 입력받아 텍스트를 출력하는 것입니다. 그게 전부입니다.

파일을 열 수 없습니다. API를 호출할 수도 없습니다. 10분 전에 무슨 일이 있었는지 기억하지 못합니다. 자신의 답변이 맞는지 아닌지 전혀 알지 못합니다.

그렇다면 코딩 에이전트 같은 도구들은 어떻게 코드베이스를 읽고, 테스트를 실행하며, 버그를 수정하는 등의 일을 실제로 _수행_할 수 있을까요?

누군가 모델 주변에 시스템을 구축하여 그것이 행동할 수 있게 만듭니다. 이 시스템이 바로 하네스입니다.

기억하기 쉬운 간단한 방법은 다음과 같습니다:

에이전트 = 모델 + 하네스

모델은 뇌입니다. 하네스는 몸체, 규칙, 그리고 안전 점검 역할을 합니다.

하네스 안에는 무엇이 들어있는가?

단일 표준은 없지만, 대부분의 하네스는 동일한 구성 요소로 만들어집니다:

부분	하는 일
📋 지침(Instructions)	에이전트가 시작할 때 갖는 규칙, 목표, 그리고 컨텍스트
...
없습니다. 이들 중 어느 것도 모델 그 자체가 아닙니다. 이 모든 것이 모델의 성능을 얼마나 잘 결정하는지를 좌우합니다.

간단한 예시

에이전트에게 _"이 프로젝트에서 실패하는 테스트를 수정해 줘."_라고 요청한다고 상상해 보세요.

하네스 없이(Without a harness), 모델은 추측만 할 수 있습니다. 그럴듯하게 보이는 코드를 작성하고 최선을 바랄 뿐입니다.

하네스가 있는 경우(With a harness), 흐름은 다음과 같습니다:

**지침(instructions)**이 프로젝트 구조와 사용할 명령어를 알려줍니다.
**도구(tool)**가 테스트 파일과 테스트 중인 코드를 읽을 수 있게 합니다.
또 다른 도구가 **테스트를 실행(run the test)**하여 실제 오류를 확인하게 합니다.
코드를 편집하고, 그다음 **점검(check)**이 다시 테스트를 실행합니다.
여전히 실패하면, **루프(loop)**가 제한 횟수까지 다시 시도하도록 되돌립니다.
위험한 변경을 하기 전에, **가드레일(guardrail)**이 승인을 요청합니다.
모든 단계는 **로그(logs)**에 저장되어, 무슨 일이 정확히 일어났는지 볼 수 있습니다.

같은 모델이지만, 완전히 다른 결과입니다.

하네스(Harness)가 중요한 이유

이 내용을 읽기 시작하면서 가장 놀라웠던 점은 이것입니다: 두 팀이 완전히 동일한 모델을 사용하더라도 매우 다른 결과를 얻을 수 있다는 것입니다.

그 이유는 하네스가 다음 사항들을 제어하기 때문입니다:

모델이 무엇을 보는지. 좋은 컨텍스트(context)를 입력하면 좋은 결정이 나옵니다.
모델이 무엇을 할 수 있는지. 필요한 도구만 제공하고, 그 이상은 아닙니다.
실수가 어떻게 포착되는지. 검사 단계가 사용자에게 전달되기 전에 오류를 잡아냅니다.
언제 멈추는지. 명확한 종료 지점은 시간과 비용을 통제합니다.

모델들은 몇 달마다 더 좋아지고 비슷해지고 있습니다. 하지만 팀들이 자신들의 에이전트를 정말 돋보이게 만들 수 있는 곳은 하네스입니다.

무시했을 때 발생하는 일

만약 강력한 모델을 약한 하네스에 연결하면, 강력하지만 신뢰할 수 없는 에이전트가 탄생합니다. 흔히 발생하는 문제들은 다음과 같습니다:

❌ 무한 루프(Endless loops): 아무것도 멈추라고 지시하지 않아 에이전트가 같은 단계를 반복합니다.
❌ 컨텍스트 손실(Lost context): 긴 작업을 진행하는 도중에 이전 결정을 잊어버립니다.
❌ 검증되지 않은 오류(Unchecked errors): 아무것도 검증해주지 않아 잘못된 답변이 그대로 통과됩니다.
❌ 위험한 행동(Risky actions): 승인 단계 없이 무언가를 삭제하거나, 전송하거나, 변경합니다.
❌ 침묵하는 실패(Silent failures): 무언가 고장 나지만 로그가 없어 왜 그런지 알 수 없습니다.
❌ 증가하는 비용(Rising costs): 추가 루프가 발생할 때마다 또 다른 유료 모델 호출이 발생합니다.

더 좋은 모델은 에이전트를 더 똑똑하게 만들 수 있습니다. 하지만 신뢰성 있게 만드는 것은 오직 더 나은 하네스뿐입니다.

에이전트를 구축한다면, 여기서부터 시작하세요

시작하기 위해 복잡한 설정이 필요하지 않습니다. 스스로에게 이 다섯 가지 질문을 던져보세요:

내 에이전트가 규칙을 알고 있는가? 명확한 지침과 프로젝트 컨텍스트를 작성합니다.
필요한 도구만 가지고 있는가? 모호한 도구가 많은 것보다, 적고 잘 정의된 도구가 더 효과적입니다.
자신의 작업을 어떻게 검사하는가? 최소한 하나의 테스트 또는 검증 단계를 추가합니다.
언제 멈추는가? 단계 제한을 설정하거나 명확한 종료 조건을 지정합니다.
무엇을 했는지 볼 수 있는가? 모든 행동을 기록(log)합니다.

이것들만 제대로 갖춘다면, 더 작은 모델이라도 놀라울 정도로 잘 작동할 수 있습니다.

마지막 생각

우리는 모델을 비교하는 데 많은 시간을 보냅니다: 어떤 것이 더 똑똑하고, 빠르고, 저렴한지. 그것은 중요합니다.

하지만 다음에 에이전트가 실망시킬 때, '뇌'를 탓하기 전에 '하네스(Harness)'를 살펴보세요.

AI 에이전트를 구축하거나 사용할 때 가장 큰 문제는 무엇이었나요? 댓글로 알려주세요 👇

더 읽어볼 자료: