AI 하니스는 AI 모델을 둘러싸고 모델이 무엇을 입력받는지, 출력에 어떤 일이 일어나는지, 모델이 애플리케이션의 나머지 부분과 어떻게 연결되는지를 제어하는 소프트웨어입니다. 대화 기록을 관리하는 작은 코드일 수도 있고, 도구, 메모리, 권한, 재시도, 장시간 실행되는 작업을 관리하는 런타임처럼 큰 시스템일 수도 있습니다.
표준화된 정의는 없습니다. AI 하니스와 에이전트 하니스는 흔히 도구를 사용하는 모델 주변의 런타임을 의미합니다. 일부 개발자는 모델 자체를 제외한 AI 애플리케이션의 거의 모든 것을 가리키는 더 넓은 의미로 이 용어를 사용합니다.
AI 하니스의 작동 방식
모델은 입력을 받아 출력을 생성합니다. 하지만 모델만으로는 애플리케이션이 대화를 어떻게 저장할지, 요청된 작업이 허용되는지, 도구가 실패한 후 어떤 일이 일어나야 하는지를 결정하지 못합니다. 이러한 작업은 하니스가 처리합니다.
일반적인 하니스는 다음 네 단계를 반복합니다.
- 모델의 입력을 준비합니다. 하니스는 사용자의 요청에 지침과 이번 단계에 필요한 정보를 결합합니다. 대화 상태를 불러오거나, 문서를 검색하거나, 모델이 요청할 수 있는 도구를 설명할 수 있습니다.
- 모델을 호출합니다. 하니스는 해당 입력을 모델 제공업체에 보내고 텍스트 또는 구조화된 요청을 받습니다.
- 출력을 해석하고 제어합니다. 모델이 도구를 요청하면 하니스는 해당 도구가 존재하는지 확인하고, 인수를 검증하며, 권한 또는 승인 규칙을 적용합니다. 출력이 특정 형식과 일치해야 한다면 하니스가 그것도 검증합니다.
- 반환하거나, 실행하거나, 계속 진행합니다. 하니스는 최종 답변을 표시하거나, 허용된 작업을 실행하거나, 도구 결과를 모델에 전달해 다음 단계를 진행할 수 있습니다. 또한 단계 수 제한이나 시간 초과 같은 중지 조건도 적용합니다.
모든 하니스가 모든 기능을 포함하는 것은 아닙니다. 간단한 요약 서비스는 입력을 구성하고, 모델을 호출하고, 답변을 검증한 후 반환하기만 할 수 있습니다. 코딩 하니스는 파일, 명령 실행기, 영속 상태, 테스트 결과, 사람의 승인, 모든 작업의 로그까지 제공할 수도 있습니다.
핵심적인 구분은 다음과 같습니다. 모델은 출력을 제안하고, 하니스는 그 출력이 무엇을 할 수 있는지 결정합니다. 모델이 이메일을 보내 달라는 요청을 생성할 수는 있지만, 하니스의 일반 애플리케이션 코드는 사용자를 인증하고, 수신자를 확인하고, 필요한 경우 승인을 요청하고, 이메일 서비스를 호출하며, 결과를 보고합니다.
예시: 환불 도우미
고객이 “주문 4812번의 헤드폰을 환불해 주세요.”라고 쓴다고 가정해 보겠습니다.
먼저 하니스는 지침과 사용 가능한 두 도구인 get_order 및 issue_refund의 설명을 포함해 요청을 모델에 보냅니다. 모델은 주문 번호 4812를 인수로 하여 get_order를 호출해 달라고 요청합니다.
하니스는 인수가 예상된 형식인지, 고객이 해당 주문에 접근할 수 있는지 확인합니다. 그런 다음 조회를 실행하고 그 결과를 모델에 전달합니다. 결과에는 헤드폰 가격이 80달러이고 아직 환불 대상이라는 내용이 표시됩니다.
그런 다음 모델은 80달러에 대해 issue_refund를 요청합니다. 실제로 금액이 이동하기 전에 하니스는 환불 정책과 고객의 신원을 확인합니다. 회사 정책상 승인이 필요하다면 하니스는 작업을 일시 중지하고 제안된 작업을 직원에게 보여 줍니다. 승인된 후에만 하니스가 결제 시스템을 호출합니다.
모델은 단계 선택을 도왔습니다. 하지만 중요한 부분인 데이터 접근, 검증, 정책 적용, 승인, 실행, 처리 결과의 기록은 하니스가 담당했습니다.
이러한 분리는 장애 처리도 더 쉽게 만듭니다. 주문 서비스가 시간 초과되면 하니스는 한 번 재시도한 다음 명확한 오류와 함께 중지할 수 있습니다. 모델이 안전한 복구 계획을 지어내기를 기대할 필요가 없습니다.
하니스가 중요한 이유
동일한 모델도 어떤 하니스를 사용하느냐에 따라 매우 다르게 동작할 수 있습니다. 한 하니스는 명확한 도구 설명, 관련 맥락, 엄격한 권한, 유용한 오류 메시지를 제공할 수 있습니다. 다른 하니스는 관련 없는 정보로 모델에 과부하를 주고, 위험한 도구를 노출하며, 실패를 숨길 수 있습니다. 모델의 품질은 중요하지만, 그것만으로는 전체 시스템의 동작을 설명할 수 없습니다.
개발자는 하니스를 통해 단순히 규칙을 요청하는 것이 아니라 규칙을 강제할 수도 있습니다. “승인 없이 100달러를 초과해 환불하지 마세요”라는 지침은 모델에 영향을 줄 수 있지만 신뢰할 수 있는 제어 수단은 아닙니다. 결제 호출을 차단하는 코드 수준의 검사는 모델이 실수하거나 신뢰할 수 없는 텍스트가 모델의 방향을 바꾸려 할 때도 강제력을 발휘합니다.
잘 정의된 하니스는 애플리케이션을 점검하고 변경하기도 쉽게 만듭니다. 로그에는 실행에 사용된 입력, 도구 요청, 승인, 결과, 중지 이유가 표시될 수 있습니다. 모델별 프롬프트와 도구 동작은 여전히 테스트해야 하지만, 주변의 모든 통합을 다시 구축하지 않고 모델을 교체할 수 있는 경우도 있습니다.
하니스가 항상 에이전트인 것은 아닙니다
하니스는 시스템의 한 계층입니다. 에이전트는 일반적으로 모델을 사용해 하나 이상의 단계에 걸쳐 행동을 선택하는 완전한 시스템을 의미합니다.
따라서 하니스는 자율성이 거의 없는 상태로도 존재할 수 있습니다. 기본적인 채팅 인터페이스 뒤의 소프트웨어도 지침, 메시지 기록, 모델 호출, 표시할 출력을 관리합니다. 모델이 도구를 사용하거나 스스로 작업을 수행할 수 없더라도 이러한 기능은 하니스의 기능입니다.
배포된 에이전트의 경우에는 그 반대가 성립하지 않습니다. 모델은 데이터베이스에 직접 인증하거나, 승인 정책을 적용하거나, 프로세스가 재시작된 후에도 작업 상태를 보존할 수 없습니다. 개발자가 그 소프트웨어를 하니스라고 부르는지 여부와 관계없이, 모델 주변의 소프트웨어가 이러한 기능을 제공해야 합니다.
이 용어는 평가 하니스라는 표현에도 등장합니다. 이 경우 하니스는 일관된 테스트 작업 집합을 모델에 실행하고 점수를 기록합니다. 이는 테스트 시스템이며, 반드시 에이전트의 런타임인 것은 아닙니다. 어떤 의미인지 여부는 대개 문맥을 통해 알 수 있습니다.
다음에 읽을 내용
모델과 하니스가 여러 단계를 선택하고 수행하는 시스템을 어떻게 구성하는지 알아보려면 AI 에이전트란 무엇인가요?를 읽어 보세요. 하니스가 제어하는 제안, 검증, 실행, 관찰의 순환 과정은 LLM의 도구 사용이란 무엇인가요?에서 확인할 수 있습니다. 주요 계층 사이의 경계는 AI 모델 vs. 챗봇 vs. 하니스 vs. 에이전트를 참조하세요.