하네스란 무엇인가

좋은 에이전트를 설명할 때 우리는 종종 모델부터 떠올린다. 어떤 모델을 썼는지, 추론 능력이 얼마나 좋은지, 코드나 문서를 얼마나 잘 다루는지를 먼저 묻는다. 물론 중요한 질문이다. 하지만 실무에서는 곧 다른 사실과 마주치게 된다. 똑같은 모델을 써도 어떤 팀의 에이전트는 믿고 맡길 수 있고, 어떤 팀의 에이전트는 시연을 넘기지 못한다는 사실이다.

이 차이를 만드는 것은 대개 모델의 지능 자체가 아니다. 모델이 일하는 방식, 즉 어떤 도구를 쓸 수 있는지, 무엇을 참고하는지, 어느 선까지 행동할 수 있는지, 실패하면 어떻게 멈추는지가 결과를 갈라놓는다. 이 장에서 말하는 하네스는 바로 그 차이를 만드는 실행 환경이다.

하네스의 원래 의미

하네스라는 단어에는 공통된 뉘앙스가 있다. 힘을 그냥 흩어 두지 않고, 목적에 맞게 연결하고, 제어하고, 안전하게 다루게 만드는 장치라는 뜻이다. 작업 현장의 안전 장비를 떠올려도 좋고, 기계를 시험하기 위한 장치를 떠올려도 좋다. 핵심은 같다. 무언가의 능력을 그대로 방치하지 않고, 사용할 수 있는 형태로 묶고, 통제 가능한 상태로 만드는 것이다.

이 감각은 AI에서도 그대로 이어진다. 모델은 능력이다. 하지만 능력만으로는 일이 되지 않는다. 능력이 실제 작업으로 바뀌려면 연결 장치가 필요하다. 어디까지 읽을 수 있는지, 어떤 명령을 실행할 수 있는지, 어떤 정보가 들어오는지, 어떤 절차를 따라야 하는지 정해져 있어야 한다. 그래야 모델의 힘이 제품의 기능으로 변한다.

쉽게 말해 모델이 엔진이라면, 하네스는 엔진을 차체와 브레이크와 계기판에 연결하는 구조다. 엔진 출력만 높다고 좋은 자동차가 되지 않는 것처럼, 모델 성능만 높다고 좋은 에이전트가 되지는 않는다.

AI에서 하네스가 의미하는 것

AI에서 하네스는 모델을 둘러싼 실행 환경 전체를 가리킨다. 여기에는 단순한 프롬프트 한 장보다 훨씬 많은 것이 들어간다. 어떤 요청을 받을지, 어떤 컨텍스트를 모아 넣을지, 어떤 도구를 노출할지, 권한을 어디까지 줄지, 실행 중간에 무엇을 기록할지, 결과를 무엇으로 검증할지가 모두 포함된다.

즉, 하네스는 모델에게 "열심히 해봐"라고 말하는 장치가 아니다. 모델이 어떤 공간에서, 어떤 규칙 아래, 어떤 절차를 따라 일할지를 정하는 구조다.

좋은 하네스 안에서 모델은 다음과 같은 방식으로 일한다.

• 해야 할 일이 분명하다.

• 참고할 정보가 정리되어 있다.

• 사용할 수 있는 도구와 사용할 수 없는 도구가 구분되어 있다.

• 위험한 행동은 막히거나 승인을 거친다.

• 중간 결과가 기록된다.

• 실패하면 재시도하거나 멈추는 조건이 있다.

• 결과를 검토하거나 검증하는 절차가 있다.

반대로 하네스가 없는 모델은 똑똑해 보여도 불안정하다. 답은 그럴듯할 수 있지만, 실제 행동은 들쭉날쭉해진다. 같은 요청에도 매번 다른 순서로 움직이고, 필요 없는 도구를 만지며, 실패 원인을 남기지 못한 채 끝나기 쉽다. 사람 입장에서는 "분명 아까는 잘했는데 왜 이번엔 이러지?"라는 답답함이 생긴다. 이 불안정함은 종종 모델의 한계처럼 보이지만, 실제로는 하네스의 부재에서 오는 경우가 많다.

Agent = Model + Harness

이 책의 핵심 관점 중 하나는 아주 단순한 식으로 표현할 수 있다.

Agent = Model + Harness

이 식은 단순해 보여도 꽤 많은 오해를 바로잡아 준다. 먼저, 에이전트는 모델과 같은 말이 아니다. 모델은 언어를 이해하고 생성하고 추론하는 핵심 능력이다. 하지만 에이전트는 그 능력이 실제 환경 안에서 행동으로 이어지도록 구성된 시스템이다.

예를 들어 어떤 모델에게 "고객 문의를 정리해줘"라고 묻는 것은 모델 사용이다. 반면 고객 문의 목록을 읽고, 관련 정책 문서를 검색하고, 필요한 경우 CRM 정보를 조회하고, 답변 초안을 만들고, 발송 전에 승인을 요청하도록 설계했다면 그것은 에이전트다. 여기서 모델은 판단과 생성의 중심이고, 하네스는 그 판단이 안전하고 반복 가능하게 실행되도록 받쳐주는 구조다.

이 식이 중요한 이유는 책임 소재를 분명하게 나눠 주기 때문이다. 모델은 언어 능력과 추론 능력을 담당한다. 하네스는 작업의 경계와 절차를 담당한다. 모델이 아무리 좋아도 하네스가 약하면 위험한 자동화가 된다. 반대로 모델이 완벽하지 않아도 하네스가 좋으면 상당히 쓸 만한 제품이 된다. 작은 단계로 나누고, 검증을 붙이고, 도구 선택을 제한하고, 사람 승인 지점을 두면 모델의 약점을 시스템이 흡수할 수 있기 때문이다.

그래서 에이전트의 경쟁력은 종종 모델 그 자체보다 하네스를 얼마나 잘 설계했는가에서 갈린다. 모델은 남들도 비슷하게 쓸 수 있지만, 하네스는 팀의 업무 방식과 제품 경험을 반영하며 축적된다. 같은 모델을 써도 제품 차이가 나는 이유가 여기 있다.

하네스는 무엇으로 이루어지는가

하네스는 하나의 부품이 아니라 여러 설계 요소의 묶음이다. 이후 장들에서 각각 자세히 다루겠지만, 여기서는 큰 그림만 잡아두자.

하네스에는 보통 실행 환경, 도구 인터페이스, 권한 체계, 메모리와 상태, 컨텍스트 주입 방식, 작업 루프, 검증 절차, 로그와 관측 가능성, 실패 복구 장치가 들어간다. 이 요소들은 따로 노는 것이 아니라 서로 맞물린다. 예를 들어 도구를 준다면 권한 설계가 따라와야 하고, 반복 실행을 허용한다면 종료 조건과 로그 설계가 따라와야 한다. 메모리를 붙인다면 저장 기준과 오염 방지도 함께 생각해야 한다.

이 점이 하네스를 단순한 래퍼나 포장지와 다르게 만든다. 하네스는 모델 바깥에 덧붙인 장식이 아니라, 모델이 현실 세계에서 일할 수 있게 만드는 운영 구조다.

조금 과장해서 말하면, 모델은 직원의 두뇌에 가깝고 하네스는 회사의 업무 환경에 가깝다. 책상, 권한, 결재선, 문서함, 체크리스트, 품질 기준, 감사 로그가 없는 조직에서 유능한 직원 한 명만 던져 놓는다고 일이 굴러가지 않는 것과 같다.

모델, 워크플로, 에이전트, 하네스는 어떻게 다른가

이 네 단어는 자주 섞여 쓰이지만, 구분해 두면 설계가 훨씬 또렷해진다.

모델: 생각하고 생성하는 핵심 엔진

모델은 입력을 받아 다음 출력을 만드는 계산 장치다. 질문에 답하고, 문장을 요약하고, 코드를 작성하고, 분류 기준을 제안할 수 있다. 하지만 모델 자체는 보통 바깥세계를 직접 만지지 않는다. 파일을 읽고, 메일을 보내고, 데이터베이스를 수정하는 일은 모델 혼자 하지 못한다. 그런 행동은 시스템이 연결해 줄 때만 가능하다.

즉, 모델은 가능성을 제공하지만, 행동의 책임 구조까지 스스로 만들지는 않는다.

워크플로: 정해진 순서대로 움직이는 절차

워크플로는 작업 순서가 비교적 고정된 구조다. 예를 들어 문서를 입력받아 요약하고, 요약문을 검토한 뒤, 특정 형식으로 저장하는 파이프라인은 전형적인 워크플로다. 어떤 단계 다음에 무엇이 오는지 미리 정해져 있다.

워크플로의 장점은 예측 가능성이다. 같은 입력이면 거의 같은 경로를 탄다. 그래서 반복 업무에 강하다. 다만 상황에 따라 스스로 전략을 바꾸는 유연성은 약하다. 중간에 예상 밖의 조건이 나오면 잘 흔들릴 수 있다.

에이전트: 목표를 향해 다음 행동을 선택하는 실행 주체

에이전트는 단순히 말을 생성하는 것을 넘어, 목표를 향해 다음 행동을 선택한다. 지금은 검색이 필요한지, 파일을 읽어야 하는지, 다시 질문해야 하는지, 초안을 만들고 멈춰야 하는지를 판단한다. 이 선택의 여지가 있다는 점에서 고정된 워크플로와 다르다.

하지만 여기서 중요한 오해가 하나 있다. 에이전트가 자율적이라는 말은 무제한이라는 뜻이 아니다. 좋은 에이전트일수록 아무거나 할 수 있는 것이 아니라, 할 수 있는 일과 할 수 없는 일이 선명한 상태에서 목표 지향적으로 움직인다.

하네스: 그 선택을 가능하게 하면서도 제한하는 작업장

하네스는 에이전트가 움직이는 작업장이다. 에이전트가 어떤 선택지를 볼 수 있는지, 어떤 도구가 메뉴에 나타나는지, 어디까지 접근 가능한지, 어느 순간 사람에게 넘겨야 하는지를 정한다. 다시 말해 에이전트의 자율성을 만들어 주는 동시에, 그 자율성의 울타리도 만든다.

그래서 하네스는 모델과 경쟁하는 개념이 아니라 모델을 제품으로 바꾸는 조건이다. 워크플로와 경쟁하는 개념도 아니다. 오히려 하네스 안에는 고정형 워크플로와 유연한 에이전트 루프가 함께 들어갈 수 있다.

같은 모델도 하네스에 따라 전혀 다른 에이전트가 된다

여기서 하네스의 힘이 가장 잘 드러난다. 같은 모델을 두 팀이 사용한다고 해보자.

한 팀은 모델에게 이메일 내용과 고객 정보, 환불 규정을 한 번에 넣고 "적절히 처리해줘"라고 시킨다. 모델은 답변 초안도 만들고, 때로는 상태 변경까지 시도한다. 로그는 거의 남지 않고, 실수하면 사람이 나중에 발견한다.

다른 팀은 모델에게 읽기 전용 고객 정보만 보여주고, 정책 문서는 최신 버전만 검색해 넣으며, 환불 판단은 초안까지만 작성하게 한다. 실제 환불 승인과 전송은 사람 검토 후에만 가능하다. 또한 각 단계마다 어떤 문서를 참고했는지, 어떤 판단을 했는지 기록이 남는다.

둘은 모델이 같아도 사실상 다른 에이전트다. 더 정확히 말하면, 다른 하네스를 가진 서로 다른 제품이다. 사용자 경험, 위험 수준, 운영 비용, 감사 가능성까지 모두 달라진다.

이것이 에이전트를 모델 이름으로만 설명하면 안 되는 이유다. 제품 수준에서 중요한 것은 "무슨 모델을 썼나?"만이 아니라 "그 모델을 어떤 구조 안에 넣었나?"다.

좋은 하네스의 첫 번째 조건: 능력보다 경계가 먼저다

많은 팀이 처음에는 도구를 많이 연결하는 데서 진전을 느낀다. 검색도 붙이고, 코드 실행도 붙이고, 메일도 보내고, 데이터베이스도 읽게 만든다. 그러면 에이전트가 갑자기 유능해 보인다. 문제는 그다음이다. 무엇을 할 수 있는지는 늘어났는데, 무엇을 하면 안 되는지가 설계되지 않으면 시스템은 위험해진다.

좋은 하네스는 능력을 추가하기 전에 경계를 먼저 만든다. 읽기와 쓰기를 구분하고, 되돌릴 수 있는 행동과 되돌릴 수 없는 행동을 나누고, 자동 실행과 승인 기반 실행을 구분해야 한다. 이는 에이전트를 못 믿어서가 아니라, 현실 세계의 작업이 원래 그렇기 때문이다. 사람 직원도 권한 없이 모든 시스템을 건드리게 하지 않는데, 에이전트라고 다를 이유는 없다.

좋은 하네스의 두 번째 조건: 반복 가능해야 한다

데모와 제품의 차이는 한 번 잘 되는가가 아니라, 여러 번 해도 비슷하게 되는가에 있다. 좋은 하네스는 우연한 성공에 기대지 않는다. 입력이 바뀌어도 어느 정도 일관된 절차를 유지하고, 실패했을 때 어디서 어긋났는지 추적할 수 있어야 한다.

이를 위해서는 상태 관리와 로그가 중요하다. 에이전트가 무엇을 읽었는지, 어떤 도구를 왜 호출했는지, 어디에서 멈췄는지를 남겨야 한다. 그래야 수정도 가능하고 평가도 가능하다. 기록 없는 에이전트는 실수한 뒤에 "아무튼 이상하게 됐다"는 말만 남긴다. 운영자의 입장에서는 가장 무서운 종류의 시스템이다.

좋은 하네스의 세 번째 조건: 검증 가능해야 한다

에이전트가 낸 결과가 좋아 보인다는 것과, 실제로 믿을 수 있다는 것은 다르다. 좋은 하네스는 결과를 검증할 수 있는 형태로 작업을 쪼갠다. 중간 산출물을 남기고, 확인 가능한 근거를 붙이며, 필요하면 사람의 검토를 거치게 한다.

예를 들어 보고서를 작성하는 에이전트라면 최종 문장만 멋지게 쓰게 할 것이 아니라, 어떤 자료를 읽었는지, 어떤 근거로 요약했는지, 수치가 어느 데이터에서 왔는지를 확인할 수 있어야 한다. 검증이 불가능한 자동화는 빠를 수는 있어도, 오래 운영하기 어렵다.

좋은 하네스의 네 번째 조건: 실패를 전제로 설계한다

에이전트 설계에서 가장 위험한 태도는 "잘 되겠지"다. 좋은 하네스는 실패를 예외가 아니라 정상적인 사건으로 본다. 도구 호출이 실패할 수도 있고, 외부 시스템 응답이 느릴 수도 있고, 문서가 충돌할 수도 있다. 때로는 모델이 목표를 잘못 이해하기도 한다.

그래서 하네스는 실패했을 때의 행동까지 포함해야 한다. 다시 시도할지, 다른 경로로 우회할지, 사람에게 넘길지, 즉시 멈출지를 미리 정해 두어야 한다. 잘 만든 하네스는 실패를 없애지는 못해도, 실패가 사고로 번지는 일은 막는다.

좋은 하네스의 다섯 번째 조건: 사람과의 경계가 분명하다

에이전트는 사람을 완전히 대체하는 기계라기보다, 사람의 업무를 보조하거나 일부를 위임받는 실행 주체에 가깝다. 따라서 중요한 것은 사람을 제거하는 것이 아니라, 사람이 개입해야 할 지점을 명확히 두는 것이다.

어떤 일은 자동 초안 생성까지만 맡기고, 어떤 일은 승인 후 실행하게 하며, 어떤 일은 아예 읽기만 허용해야 한다. 이 구분이 없으면 에이전트는 과소활용되거나 과잉자동화된다. 전자는 늘 사람 손이 많이 가서 생산성이 안 나오고, 후자는 언젠가 큰 사고를 부른다.

좋은 하네스는 사람과 에이전트가 서로의 강점을 살리도록 역할을 나눈다. 에이전트는 빠르게 읽고 정리하고 초안을 만들고 반복 작업을 수행한다. 사람은 책임이 큰 판단, 예외 상황의 처리, 최종 승인, 정책 해석을 맡는다. 이 분업이 선명할수록 시스템은 오래 간다.

하네스는 보이지 않지만 제품 경험을 결정한다

사용자는 보통 "이 서비스의 하네스가 좋네요"라고 말하지 않는다. 대신 이렇게 말한다. "실수가 적다." "답이 일관된다." "위험한 작업은 꼭 확인을 거친다." "어디서 문제가 났는지 금방 찾을 수 있다." "쓸수록 믿음이 간다."

이런 인상은 대부분 하네스에서 나온다. 모델이 약간 더 똑똑한 것보다, 잘못된 행동을 막고, 필요한 근거를 보여 주고, 실패를 안전하게 처리하는 쪽이 실제 사용자 신뢰에 더 큰 영향을 미치는 경우가 많다. 결국 제품은 모델 성능표가 아니라 체감 가능한 경험으로 평가되기 때문이다.

그래서 하네스는 화려한 기능보다 더 본질적이다. 잘 만든 하네스는 모델의 장점을 살리고 약점을 가린다. 반대로 허술한 하네스는 좋은 모델마저도 위험한 도구로 만든다.

에이전트를 설계한다는 것은 작업장을 설계한다는 뜻이다

이제 하네스를 하나의 문장으로 정리해보자. 하네스는 모델이 안전하고 반복 가능하며 검증 가능한 방식으로 일하도록 만드는 실행 환경이다.

이 정의를 붙들고 보면, 에이전트 설계는 더 이상 프롬프트 몇 줄을 잘 쓰는 일이 아니다. 어떤 작업장을 만들 것인가의 문제다. 도구는 어디에 놓을지, 위험한 장비에는 어떤 잠금장치를 둘지, 작업 순서는 어떻게 설계할지, 품질 검사는 어디서 할지, 문제가 생기면 어떻게 멈출지를 정하는 일이다.

결국 좋은 에이전트는 똑똑한 모델에서 나오기보다, 잘 설계된 작업장 안에서 똑똑한 모델이 일할 때 나온다. 모델이 두뇌라면 하네스는 실무 감각을 가진 운영 구조다. 그리고 제품의 신뢰는 대개 이 운영 구조에서 결정된다.

다음 장부터는 이 작업장을 부품 단위로 분해해서 살펴볼 것이다. 에이전트가 실제로 일하는 공간은 어떻게 설계해야 하는가. 도구는 어떤 형태로 연결해야 하는가. 권한, 메모리, 컨텍스트, 검증, 로그는 어떻게 서로 맞물려야 하는가. 그 질문들에 답하다 보면, Agent = Model + Harness라는 식이 점점 더 현실적인 설계 원칙으로 보이기 시작할 것이다.