하네스 엔지니어링: 개념과 작동 방식

AI 하네스가 무엇인지, 그리고 하네스 엔지니어링이 AI 에이전트가 할 수 있는 일을 어떻게 좌우하는지 쉽게 풀어 설명하는 가이드입니다.

Diagram of an AI harness: an AI model that reads and writes text sits at the center, connected to six parts: agent loop, context management, tools, memory, permissions, and verification.

하네스 엔지니어링이란 무엇인가

하네스 엔지니어링은 AI 도구의 하네스, 즉 AI 모델을 제외한 도구의 모든 부분을 구축하는 작업입니다.

모델은 언어를 읽고 쓸 수 있도록 방대한 양의 텍스트로 학습된 AI 시스템입니다. AI 모델의 예로는 OpenAI의 GPT, Anthropic의 Claude, Google의 Gemini 등이 있습니다.

모델은 그 자체만으로는 텍스트(때로는 이미지나 오디오)를 입력받아 텍스트로 답하는 일만 할 수 있습니다. 과거 대화를 기억하거나, 최신 정보를 찾아보거나, 코드를 실행할 수 없습니다. 그래서 모델이 어떤 정보를 받는지, 어떤 앱을 사용할 수 있는지, 무엇을 할 수 있는지, 작업 결과를 어떻게 검증하는지를 관리하는 하네스가 필요합니다.

기본적인 채팅 어시스턴트에도 하네스가 필요합니다. 모델은 답변하는 즉시 주고받은 내용을 잊어버리기 때문에, 하네스가 대화 기록을 보관합니다. 누군가 파리에 대해 물은 뒤 "그곳의 인구는?"이라고 이어서 질문하면, 하네스는 두 질문을 함께 모델에 보냅니다. 그래서 모델은 "그곳"이 파리를 가리킨다는 것을 알 수 있습니다.

같은 모델을 기반으로 만든 두 도구의 성능이 크게 다를 수 있는 이유 중 하나가 바로 하네스 엔지니어링입니다. 예를 들어 한 독립적인 테스트에서 연구진이 모델(GPT5)은 그대로 두고 하네스만 바꿨더니 코딩 테스트에서 모델의 점수가 최대 11%까지 달라졌습니다.

Anthropic이나 OpenAI 같은 AI 모델 개발사는 Claude Code나 Codex 같은 자사 AI 제품을 위한 하네스를 구축합니다. 또한 AI 제품을 만드는 기업은 자신들이 선택한 기반 모델에 맞춰 하네스를 설계합니다. AI 도구를 사용하는 사람들도 하네스의 일부를 만들어 갑니다. 많은 도구에서 사용자는 상시 지침을 추가하고, 앱을 연결하고, 도구가 작업을 진행하기 전에 어떤 작업에 자신의 승인이 필요한지 선택할 수 있습니다.

AI 에이전트를 위한 하네스 엔지니어링

모든 AI 도구에는 하네스가 있지만, 하네스 엔지니어링은 AI 에이전트를 다룰 때 특히 중요해집니다. 에이전트는 경쟁사를 조사하고 그 결과를 스프레드시트에 정리하는 것처럼 여러 단계로 이루어진 작업을 스스로 처리하며, 모든 단계는 하네스가 실행합니다. 따라서 하네스가 작년 가격을 가져오는 것 같은 실수를 하면 나머지 단계에도 영향을 미치게 됩니다.

대부분의 에이전트 하네스는 여섯 가지 주요 요소로 구성됩니다.

1. 에이전트 루프

에이전트 루프는 작업이 한 번에 한 단계씩 계속 진행되도록 하는 하네스 내부의 코드입니다.

AI 모델은 작업을 완료하는 데 필요한 다음 단계를 결정하고 도구 호출을 작성합니다. 도구 호출이란 웹 검색처럼 하네스에 있는 도구의 이름과 그 도구가 수행할 일을 지정하는 짧은 요청입니다.

하네스는 이 요청을 감지해 검색을 실행하고, 그 결과를 모델이 볼 수 있는 정보에 추가합니다. 모델은 결과를 읽고 다음에 할 일을 결정합니다.

2. 컨텍스트 관리

모델은 학습 과정에서 일반 지식을 익히지만, 그 지식은 학습이 끝난 시점에 멈춰 있습니다. 회사 파일, 오늘의 뉴스, 대화 초반에 오간 내용처럼 현재 작업에 특화된 정보는 포함되어 있지 않습니다.

이런 정보를 얻기 위해 모델은 컨텍스트 윈도우에 의존합니다. 컨텍스트 윈도우란 하네스가 매번 응답하기 전에 모델에 제공하는 텍스트로, 지침, 쿼리, 지금까지의 대화, 검색 결과 등이 포함됩니다.

컨텍스트 윈도우에는 정해진 양의 텍스트만 담을 수 있습니다. 게다가 윈도우가 가득 차기 전이라도 모델은 긴 입력의 중간에 묻힌 정보를 놓치기도 합니다.

그래서 하네스는 컨텍스트 관리를 맡아 각 단계에 필요한 정보만 골라냅니다. 예를 들어 경쟁사 다섯 곳의 가격을 비교하는 작업이라면, 하네스는 각 회사의 웹사이트 전체가 아니라 가격 페이지만 포함할 수 있습니다. 긴 작업에서는 이전 단계의 상세 기록을 짧은 요약으로 대체해, 그간의 기록으로 윈도우가 가득 차지 않으면서도 모델이 지금까지 한 일을 파악할 수 있게 합니다.

3. 도구

도구는 모델이 요청한 작업을 수행하는 코드입니다. 각 도구는 웹 검색, 웹 페이지 열어서 읽기, 코드 실행, 파일 편집처럼 한 가지 종류의 작업을 담당합니다. 모델이 도구 호출을 작성하면 하네스는 이를 적절한 도구에 전달하고 결과를 반환합니다.

많은 하네스에는 커넥터도 포함되어 있습니다. 커넥터는 사용자가 부여한 접근 권한을 이용해 에이전트를 이메일, 캘린더, 공유 드라이브 같은 특정 앱에 연결하는 도구입니다. 예를 들어 캘린더 커넥터가 있으면 에이전트는 미팅 시간을 제안하기 전에 상대방의 일정을 확인할 수 있습니다.

4. 메모리

메모리는 한 세션에서 다음 세션으로 이어지는 저장된 정보입니다. 하네스는 세션 중에 사용자의 선호 사항이나 프로젝트 진행 상황 같은 짧은 메모를 저장합니다. 다음 세션이 시작되면 하네스는 이 메모를 컨텍스트 윈도우에 추가하므로, 모델은 새 쿼리를 읽기 전에 메모부터 읽게 됩니다. 예를 들어 에이전트가 주간 보고서를 처음부터 다시 시작하지 않고 중단했던 지점부터 이어서 작업할 수 있는 것도 이 덕분입니다.

5. 권한

권한은 에이전트가 무엇에 접근하고 무엇을 할 수 있는지에 관한 규칙입니다. 접근 규칙은 에이전트가 열 수 있는 파일, 앱, 웹사이트를 정합니다. 승인 규칙은 메시지 전송이나 구매처럼 사람의 승인을 받을 때까지 기다려야 하는 작업을 정합니다.

에이전트를 만드는 회사가 이러한 규칙 중 일부를 하네스 코드에 설정합니다. 그런 다음 조직의 관리자가 자체 규칙을 추가할 수 있고, 개별 사용자는 연결할 계정 등을 선택할 수 있습니다.

6. 검증

검증은 에이전트의 작업 결과가 사람에게 전달되기 전에 이를 확인하는 코드입니다. 검증에는 두 가지 방식이 있습니다.

  • 고정 규칙: 매번 같은 방식으로 통과 또는 실패가 판정되는 구체적인 테스트입니다. 예를 들어 보고서의 모든 수치가 에이전트가 실제로 읽은 문서에 나오는지 확인하는 것이 여기에 해당합니다.
  • 다른 AI 모델의 검토: 다른 모델이 작업 결과를 읽고 평가합니다. 중요한 내용이 빠진 요약처럼 규칙으로 만들기 어려운 문제를 잡아낼 수 있습니다.

어떤 검사도 모든 문제를 잡아낼 수는 없기 때문에, 하네스는 보통 두 방식을 함께 사용합니다. 검사에서 문제가 발견되면 하네스는 문제에 대한 설명을 모델의 컨텍스트 윈도우에 추가하고 작업을 다시 에이전트 루프로 보냅니다. 모델은 문제를 수정해 다시 시도하므로, 많은 실수가 사용자가 결과를 보기 전에 바로잡힙니다.

하네스 엔지니어링 사례

고객 미팅 준비하기

작업: 한 어카운트 매니저가 에이전트에게 내일 있을 고객 미팅을 위해 미해결 이슈와 안건 초안을 담은 브리핑 자료를 준비해 달라고 요청합니다.

하네스가 하는 일:

  • 에이전트는 이메일 커넥터를 통해 매니저의 받은편지함에서 해당 고객과 주고받은 메시지를 검색합니다.
  • 권한 설정에 따라 에이전트는 이메일을 읽을 수는 있지만 보낼 수는 없습니다.
  • 컨텍스트 관리는 받은편지함 전체가 아니라 해당 고객과 최근 3개월간 주고받은 메시지만 모델에 전달합니다.
  • 에이전트 루프는 검색과 읽기를 여러 차례 반복하고, 모델은 찾은 내용을 미해결 이슈별로 정리합니다.
  • 이어서 검증 단계에서 브리핑의 모든 이슈가 실제 이메일과 연결되는지 확인합니다.

예상 결과: 매니저는 모든 항목의 출처 이메일을 추적할 수 있는 한 페이지 분량의 브리핑을 받습니다.

월간 매출 보고서 업데이트하기

작업: 한 운영 책임자가 에이전트에게 이번 달 수치로 월간 매출 보고서를 업데이트해 달라고 요청합니다.

하네스가 하는 일:

  • 메모리가 지난달 세션의 메모를 불러옵니다. 여기에는 보고서 형식과 수치를 천 단위로 반올림해 달라는 책임자의 요청이 포함되어 있습니다.
  • 파일 도구가 팀 공유 드라이브에 있는 매출 스프레드시트를 엽니다.
  • 권한 설정에 따라 에이전트는 보고서 초안은 편집할 수 있지만 원본 스프레드시트는 편집할 수 없으므로, 원래 수치가 실수로 변경되는 일이 없습니다.
  • 검증 단계에서 보고서의 합계가 스프레드시트와 일치하는지 확인합니다.

예상 결과: 사용자가 다시 설명할 필요 없이 지난달과 같은 형식으로 보고서가 완성됩니다.

공유 받은편지함 분류하기

작업: 한 지원팀이 에이전트에게 오전에 들어온 요청을 주제별로 분류하고, 자주 들어오는 요청에 대한 답장 초안을 작성해 달라고 요청합니다.

하네스가 하는 일:

  • 에이전트 루프는 받은편지함의 메시지를 하나씩 처리합니다.
  • 모델이 각 메시지에 맞는 주제 라벨을 고르면, 하네스가 이메일 커넥터를 통해 해당 라벨을 적용합니다.
  • 작업을 시작할 때 하네스는 팀에서 승인한 답장 템플릿을 가이드로 컨텍스트 윈도우에 추가하므로, 모델은 각 초안을 템플릿에 기반해 작성합니다.
  • 승인 규칙에 따라 모든 답장은 팀원이 검토하고 발송할 때까지 초안 상태로 유지됩니다.

예상 결과: 팀은 요청이 분류되어 있고 답장이 검토를 기다리는 상태로 하루를 시작합니다.

웹사이트 버그 수정하기

작업: 한 개발자가 코딩 에이전트에게 결제 버튼이 작동하지 않는 버그를 수정해 달라고 요청합니다.

하네스가 하는 일:

  • 에이전트는 샌드박스에서 작업합니다. 샌드박스는 격리된 코드 사본으로, 여기서 변경한 내용은 실제 웹사이트에 영향을 주지 않습니다.
  • 코드 도구를 통해 모델이 파일을 읽고 편집할 수 있습니다.
  • 변경할 때마다 검증 단계에서 프로젝트의 자동화된 테스트를 실행합니다.
  • 테스트가 실패하면 그 결과가 새로운 정보로 모델에 다시 전달됩니다.

예상 결과: 에이전트는 테스트를 통과할 때까지 수정 사항을 계속 조정합니다. 이후 개발자가 변경 사항을 검토한 뒤 실제 서비스에 반영합니다.

하네스 엔지니어링 vs. 프롬프트 엔지니어링 vs. 컨텍스트 엔지니어링

프롬프트 엔지니어링은 하나의 쿼리를 작성하고 최적화하는 작업입니다. 컨텍스트 엔지니어링은 모델이 보는 모든 것을 관리하는 작업입니다. 하네스 엔지니어링은 모델이 작동하는 시스템 전체를 설계하고 개선하는 과정입니다.

용어

주로 담당하는 사람

경쟁사 조사 작업의 예

프롬프트 엔지니어링

쿼리를 작성하는 모든 사람

"경쟁사별로 한 행, 가격 등급별로 한 열"을 요청하기

컨텍스트 엔지니어링

하네스를 구축하는 사람, 그리고 파일이나 템플릿을 첨부하는 사용자

모델에 각 경쟁사의 가격 페이지와 팀의 스프레드시트 템플릿 제공하기

하네스 엔지니어링

AI 제품을 만드는 기업, 그리고 설정과 선호 사항을 선택하고 정보를 업로드하는 팀과 사용자

에이전트가 사용할 수 있는 도구, 승인이 필요한 작업, 작업 결과의 검증 방식 결정하기

사용자가 AI 하네스에 영향을 미치는 방법

에이전트 하네스의 대부분은 에이전트를 만드는 회사가 제공하지만, 많은 AI 제품에서는 사용자 지정 지침, 연결된 앱, 승인 같은 설정을 통해 사용자가 하네스의 일부를 조정할 수 있습니다.

사용자는 다음 네 가지 방법으로 에이전트 하네스를 조정하고 에이전트의 결과를 개선할 수 있습니다.

1. 상시 지침

상시 지침은 한 번 작성해 두면 하네스가 모든 작업을 시작할 때마다 컨텍스트 윈도우에 추가해 주는 메모입니다. 본인이 누구이고 어떤 일을 하는지, 어떤 방식의 글을 선호하는지, 또는 고객의 월간 보고서처럼 반복되는 작업의 규칙 등 쿼리마다 반복해서 입력해야 하는 내용이 있다면 설정해 둘 만합니다.

많은 AI 제품은 두 가지 수준의 상시 지침을 제공합니다. 계정 전체 지침은 맞춤법 선호처럼 모든 작업에 공통으로 적용되는 사항에 적합합니다. 프로젝트 지침은 특정 고객이나 워크플로우 하나에 적합하며, 한 프로젝트의 지침이 다른 프로젝트로 넘어가지 않습니다.

상시 지침은 채팅 어시스턴트와 에이전트에서 똑같이 작동하지만, 에이전트가 지침에 더 크게 의존합니다. 채팅에서는 AI가 답변할 때마다 사람이 바로잡을 수 있습니다. 하지만 에이전트는 누군가 작업 결과를 확인하기 전에 여러 단계를 거칠 수 있으므로, 미리 제공한 지침은 작업 도중 에이전트의 방향을 잡아 줄 수 있는 몇 안 되는 방법 중 하나입니다.

효과적인 상시 지침 작성법

  • 짧은 지침으로 시작하세요. 예: "저는 소프트웨어 회사의 마케팅 매니저입니다. 쉬운 영어로 작성하고, 요약은 200단어 이내로 유지하며, 미국식 철자를 사용해 주세요."
  • AI가 실수하면 지침을 보완하세요. 팀에 정확한 수치가 필요한데 AI가 계속 수치를 반올림한다면, 정확한 수치가 필요하다는 문장을 추가하세요.
  • 지침은 구체적으로 작성하세요. "정확하게 작성하세요"보다 "반올림하지 말고 정확한 수치를 제시하세요"가 더 효과적입니다.
  • 모든 문장이 컨텍스트 윈도우의 공간을 차지하므로, 목록은 짧게 유지하고 더 이상 유용하지 않은 문장은 삭제하세요.

2. 연결된 앱

연결된 앱은 AI 제품을 이메일, 캘린더, 공유 드라이브처럼 사용자가 이미 사용하는 도구와 연결해 줍니다. 앱을 연결하면 AI는 채팅에 붙여 넣은 내용뿐 아니라 사용자 본인의 정보를 활용해 작업할 수 있습니다.

이메일 스레드를 바탕으로 미팅 브리핑을 준비하거나 공유 드라이브의 문서를 요약하는 것처럼, 해당 앱에 있는 정보가 필요한 작업이라면 연결을 설정해 둘 만합니다.

앱을 안전하게 연결하는 방법

  • 연결이 하나 늘어날 때마다 오류가 생길 여지도 늘어나므로, 작업에 필요한 앱만 연결하세요.
  • 읽기 전용 권한이 제공된다면 이를 선택하세요. 예를 들어 미팅 브리핑을 준비하는 에이전트는 이메일을 읽기만 하면 되고 보낼 필요는 없습니다.
  • 제품에서 지원한다면 프로젝트별로 연결을 설정하세요. 예를 들어 Perplexity에서는 각 프로젝트에서 사용할 커넥터를 선택할 수 있습니다.
  • 더 이상 사용하지 않는 앱은 잊지 말고 연결을 해제하세요.

3. 승인 설정

승인 설정은 AI가 작업을 진행하기 전에 사람의 승인을 받아야 하는 작업을 정합니다. 일부 승인은 제품에 기본으로 포함되어 있으며, 일부 제품에서는 승인이 필요한 다른 작업을 사용자가 직접 선택할 수 있습니다.

승인 규칙을 설정하는 방법

  • 메시지 전송, 구매, 파일 삭제처럼 되돌릴 수 없는 작업에는 승인을 필수로 설정하세요.
  • 승인이 필요한 항목은 최소한으로 유지하세요. 에이전트가 사소한 단계마다 승인을 요청하면 사람들은 내용을 제대로 읽지 않고 승인하게 됩니다.

4. 기준과 검증

대부분의 AI 제품에는 몇 가지 기준이 기본적으로 내장되어 있습니다. 예를 들어 Perplexity는 답변에 출처를 함께 제공하여 각 주장을 확인할 수 있게 합니다. 사용자가 설정한 기준은 팀이 선호하는 보고서 형식처럼 제품이 스스로 알 수 없는 부분을 보완합니다.

AI 작업의 기준을 설정하는 방법

  • 반복되는 작업에는 템플릿을 제공하여 AI가 정해진 구조에 맞춰 내용을 채울 수 있도록 하세요.
  • 팀이 만족했던 이전 작업의 예시를 공유하여 AI가 그 어조와 상세한 정도를 맞출 수 있도록 하세요.
  • 모든 수치 옆에 출처 링크를 달도록 요청하세요.
  • 초기 결과를 꼼꼼히 검토하고, 반복해서 드러나는 부족한 점은 새로운 상시 지침으로 만드세요.

Perplexity의 에이전트 하네스 접근 방식

Perplexity Computer는 특정 모델에 종속되지 않는 하네스에서 실행되며, 이 하네스는 20개 이상의 고급 모델을 하나의 시스템으로 통합합니다. 각 작업을 하위 작업으로 나누어 하위 에이전트(각각 한 부분을 맡는 별도의 에이전트)에 넘기고, 작업 하나하나를 그에 적합한 모델로 라우팅합니다.

Perplexity 프로젝트 가이드에서 지침, 파일, 커넥터를 설정하는 방법을 알아보세요.

자주 묻는 질문

하네스 엔지니어란 무엇인가요?

하네스 엔지니어는 AI 모델이 안정적으로 작업을 수행할 수 있게 해 주는 시스템을 설계하고 유지 관리합니다. 에이전트가 사용할 새 도구를 추가하거나, 에이전트가 같은 실수를 반복하는 원인을 추적하거나, 작업을 마치기 전에 실행하는 검증을 강화하는 일 등이 여기에 해당합니다. 아직 표준적인 직함은 아니지만, 앞으로 달라질 수도 있습니다. 이 업무는 대개 AI 기업이나 에이전트를 개발하는 팀의 소프트웨어 엔지니어가 맡습니다. 제조업에서는 같은 직함이 자동차와 기계 내부에 들어가는 케이블 묶음인 와이어 하네스를 설계하는 사람을 가리킵니다.

에이전트 하네스란 무엇인가요?

에이전트 하네스는 보통 AI 에이전트에서 모델 자체를 제외한 모든 것을 의미합니다. 여기에는 에이전트 루프를 실행하고, 컨텍스트를 관리하고, 도구 호출을 수행하고, 메모리를 저장하고, 권한을 적용하고, 에이전트의 작업이 사람에게 전달되기 전에 검토하는 코드가 포함됩니다.

모든 AI 도구에는 하네스가 있나요?

네. 모델은 이전 메시지를 스스로 기억하지 못하기 때문에, 기본적인 채팅 어시스턴트도 하네스에 의존해 대화 내용을 추적합니다.

개발자는 API(한 프로그램이 다른 프로그램에 요청을 보낼 수 있게 해 주는 연결)를 통해 자체 소프트웨어에서 모델에 요청을 보내는 방식으로 모델을 사용할 수도 있습니다. 이 경우에는 개발자가 직접 작성한 코드가 하네스의 역할을 합니다.

모델이 더 발전하면 하네스가 필요 없어질까요?

더 뛰어난 모델은 단계별 안내가 덜 필요할 수 있으므로, 현재 하네스가 하는 일 중 일부는 줄어들 수 있습니다. 하지만 모델은 그 자체만으로는 텍스트를 받아 텍스트를 내놓을 뿐입니다. 인터넷에 연결되어 있지도 않고 다른 앱에 접근할 수도 없습니다. 파일에 접근하고, 작업을 수행하고, 승인 규칙을 적용하는 일은 모두 모델을 둘러싼 소프트웨어에서 이루어지므로, 모델의 성능이 아무리 높아지더라도 이러한 일은 계속 하네스의 몫으로 남을 가능성이 큽니다.