하네스 엔지니어링이란?

AI 에이전트가 단순한 질답을 넘어 장기적이고 복잡한 작업을 자율적으로 수행하게 되면서, 이를 안전하게 운용하기 위한 인프라와 구조의 중요성이 커지고 있습니다. 

이것이 바로 하네스 엔지니어링(Harness Engineering)입니다.

모든 것을 모델에게 맡기는 대신 외부의 결정론적 요소를 통해 안정성을 확보하고자하는 것인데요. 최근에는 특히 에이전트가 장기적·복잡한 작업을 자율적으로 수행할 수 있도록 하는 방향에 초점이 맞춰지고 있습니다.

 

하네스의 구성 요소를 나누는 기준은 다양하지만 이 글에서는 크게 여섯 가지 구성 요소로 정리를 해보았습니다.

 

하네스의 구성 요소

1. 컨텍스트 & 메모리

에이전트가 작업에 필요한 정보를 적절한 시점에 제공받을 수 있도록 관리하는 레이어입니다. 프롬프트 외에도 프로젝트 규칙, 이전 작업 결과, 외부 문서 등을 체계적으로 관리합니다,

컨텍스트 관리가 중요한 이유 중 하나는 Context Rot입니다.

Context Rot은 장기 작업에서 오래된 정보·노이즈가 쌓여 에이전트 출력 품질이 저하되는 현상으로, 이를 방지하기 위해 주기적인 압축과 리셋, 불필요한 툴 출력 오프로딩 등의 방법이 사용됩니다.

2. 파일시스템 & 상태 관리

에이전트의 상태와 진행 상황을 컨텍스트 대신 파일로 저장합니다. 세션이 종료되거나 컨텍스트가 리셋되더라도 정보의 손실 없이 작업이 지속가능하도록 해줍니다.

3. 샌드박스 & 권한 제한

에이전트가 접근하고 실행할 수 있는 범위를 외부에서 구조적으로 제한하는 것으로 실수의 반경을 구조적으로 줄이기 위한 안전장치입니다. 인프라 변경이나 외부 API 호출처럼 되돌리기 어려운 작업일수록 중요성이 강조되는 부분입니다.

4. 툴 & MCP

에이전트가 외부 세계와 상호작용하는 인터페이스입니다. 툴과 mcp를 통해 에이전트는 파일 접근, 코드 실행, 외부 서비스 호출 등의 액션을 할 수 있습니다. 다만 툴이 많아질수록 컨텍스트를 차지하는 양도 늘어나기 때문에 필요한 시점에 필요한 툴만 주입하는 전략이 중요합니다.

5. 피드백 루프 & 자기 검증

작업 완료 여부를 모델 스스로 판단하게 하는 대신 외부의 객관적 기준으로 검증하고 실패 시 에이전트가 수정하도록 하는 구조입니다. 실제로 완료되지 않았는데 완료를 선언하거나, 원치 않는 방식으로 작업이 이루어지는 경우를 방지할 수 있습니다. 외부 기준으로는 테스트, 린터, 타입 체커 같은 결정론적 도구나 다른 에이전트를 활용할 수 있습니다.

• Ralph Wiggum Loop

  Ralph Wiggum Loop는 피드백 루프를 구현하는 대표적인 패턴입니다. 동일한 프롬프트를 에이전트에게 주고 외부 기준을 통과할 때까지 반복 실행합니다. 동시에 상태를 레포지토리에 기록하고 프롬프트 외의 컨텍스트로서 사용합니다.

6. 오케스트레이션

여러 에이전트 또는 작업 단계를 조율하는 상위 레이어입니다. 역할을 분리해 각 에이전트가 자신의 영역에 집중하게 함으로써 복잡한 문제를 풀어갑니다. 

각 에이전트가 신선한 컨텍스트로 시작하기 때문에 컨텍스트 오염을 방지할 수 있고, 실패가 발생하더라도 해당 단계만 재실행하면 된다는 이점이 있습니다.

 

이제 실제 하네스 적용 사례들을 살펴보겠습니다.

실제 적용 사례

사례 1. OpenAI Codex — 3명이 5개월동안 100만 줄 작업

    - AI 친화적 레포지토리 구조

        모든 컨텍스트가 레포지토리에 존재하도록 문서 디렉토리를 정리하고 프로젝트 진행 중에도 새로 생긴 컨텍스트들을 문서에 업데이트했습니다.
        또한 에이전트 설정 파일에 모든 내용을 포함하는 대신 목차로서 사용하고 세부 설정은 개별 파일로 분리하여 활용성을 높였습니다.

     - 외부 판단 도구

        커스텀 린터와 구조적 테스트를 생성하여 작업 완료 후 오류 여부를 테스트했습니다. 커스텀 린터의 에러 메시지에 수정 방법을 포함하도록 개발하여 오류 메시지 자체가 컨텍스트가 될 수 있도록 설계했습니다.

    - Ralph Wiggum Loop

      Ralph Wiggum Loop를 사용하여 작업 후 리뷰 에이전트의 검토를 거치고 수정 사항이 없을 때까지 작업⬝검토 루프를 반복하도록 했습니다.

    - 가비지 컬렉션

      주기적으로 코드베이스와 문서를 스캔하고 팀 컨벤션⬝설계 문서와의 불일치를 감지하면 리팩토링 PR을 자동 생성하도록 합니다. 가비지 컬렉션 에이전트를 통해 수동 정리에 엔지니어링 시간의 20%를 소모하던 것을 자동화했습니다.

    - 하네스 자가 발전

      문서 관리 에이전트가 주기적으로 오래되거나 유효하지 않은 문서의 항목을 검토하고 수정합니다. 에이전트 실패 시, 인간 운영자가 부족한 능력을 파악하고 린터 수정·문서 추가로 하네스를 개선하여 에이전트가 잘 수행하지 못할 때 모델을 바꾸는 대신 하네스를 수정하여 성능을 개선했습니다.

 

사례 2. Anthropic — Claude Agent SDK 장기 작업 연구

Anthropic팀은 Claude Agent의 장기 작업을 테스트하며 에이전트가 한 번에 너무 많은 작업을 시도하는 것과 작업이 완료되지 않았음에도 완료 선언하는 문제를 발견했습니다. 이를 해결하기 위해 아래의 방식을 적용했습니다.

    - 파일시스템 기반 상태 관리
       Initializer 에이전트가 세션 시작 시 진행 상황 파일과 git을 통해 작업 현황을 파악하고 환경을 세팅합니다. 코딩 에이전트는 작업 종료 시 git 로그와 진행 상황 파일을 업데이트하여 세션이 끊기더라도 다음 에이전트가 이어서 작업할 수 있도록 했습니다.

    - 피드백 루프

      JSON 파일로 전체 기능 목록과 각 기능의 구현 진행 상황을 관리했습니다. 각 기능은 하나의 코딩 에이전트에 할당되어 독립적으로 구현되며, 완료 여부도 해당 파일을 기준으로 판단합니다.

    - 엔드투엔드 검증

      MCP를 통해 실제 사용자처럼 브라우저를 조작하는 테스트를 수행하고 이를 작업 완료의 판단 기준으로 삼았습니다. 모델이 스스로 완료를 선언하는 대신 실제 동작 기반으로 검증하는 구조입니다.

 

사례 3. IBM CUGA — 작업 정확도 33% → 87%

    - 에이전트 상태 관리

      계획 에이전트가 작업을 하위 단계로 분해하고 실행 상태를 장부로 기록하며, 실패 시 동적으로 재계획을 수행합니다. 성공적인 실행의 계획·코드·궤적을 저장해두고 유사한 작업 시에 재사용하여 반복 작업의 효율을 높였습니다.

    - 정책 기반 거버넌스 & 샌드박스

      Policy-as-Code 엔진을 통해 모델 프롬프트와 완전히 독립적으로 작동하는 하네스 레이어에서 의도 가드(Intent Guard), 도구 가이드, 출력 포맷터 등의 정책을 강제합니다. 파일 삭제·민감 데이터 접근 등 고위험 작업에는 인간 운영자의 검토와 승인이 필요하도록 Human-in-the-loop 구조를 도입했습니다. 또한 에이전트는 고객 전용 가상 네트워크의 격리된 임시 컨테이너에서 작동하도록 하여 데이터 주권을 보장합니다.

    - 피드백 루프

       실패 탐지 도구와 루트 원인 분석 모듈을 통해 실시간으로 오류를 감지하고 수정안을 제시합니다. 이러한 하네스 구조 개선만으로 작업 정확도를 33%에서 87%까지 끌어올렸습니다.

 

하네스 엔지니어링 적용

랩큐에서는 현재 시민들이 민원 관련 질문을 쉽고 빠르게 해결할 수 있도록 지원하는 민원 챗봇 AI 보좌관의 개발 프로젝트를 진행하고 있습니다.

현재 AI 보좌관은 체인 기반의 구조를 가지고 있습니다. 하지만 추후 단순 민원 답변 이상의 작업을 처리하기 위해서는 동적으로 흐름을 조절할 수 있는 에이전트 전환이 필요하고 이에 따라 안정적인 작업을 수행하기 위해 하네스 엔지니어링이 도입되어야합니다. 

 

에이전트 전환

기존의 체인 기반 구조를 에이전트 구조로 전환하는 작업이 선행되어야 합니다. 

에이전트는 주어진 상황을 스스로 판단해 필요한 도구와 흐름을 동적으로 선택할 수 있어 보다 유연한 대응이 가능합니다. 또한 각 기능을 독립적인 에이전트로 분리하고 유기적으로 연결하는 멀티 에이전트 구조를 통해 각 에이전트가 맡은 역할에 집중하면서도 서로 협력하는 구조를 만들 수 있습니다. 이러한 형태는 이후 기능 추가나 변경 시에도 해당 에이전트만 수정하면 되기 때문에 확장도 용이합니다.

  

검토 에이전트

검토 에이전트는 작성 에이전트가 생성한 답변을 검토하고 피드백을 작성하여 작성 에이전트로 반환합니다. 

만약 누락된 정보가 있거나 확신도가 낮다고 판단되면 재검색을 수행하고 그 결과를 다시 작성 에이전트로 전달해 답변을 보완하는 구조입니다.

검토 에이전트는 다음 세 가지 기준을 바탕으로 답변을 전체적으로 검토합니다.

    - 정보 정확성: 검색 결과와 답변 내용을 대조해 할루시네이션 및 오류 여부를 확인합니다.

    - 답변 완결성: 사용자의 질의에 필요한 정보가 모두 포함되어 있는지 확인합니다

    - 스타일: 말투, 톤, 답변 형식이 적절한지 확인합니다.

 

룰 에이전트

검토 에이전트가 개별 답변의 품질을 검증하는 역할이라면, 룰 업데이트 에이전트는 반복적으로 발생하는 오류 패턴을 분석해 시스템 자체를 개선하는 역할입니다. 사용자 부정 피드백과 반복 오답 패턴을 수집·분석하고 문제의 원인을 파악해 에이전트가 참조하는 규칙 문서를 자동으로 수정합니다. 

OpenAI Codex 사례의 하네스 자가 발전 구조와 유사하게 운용 과정에서 쌓이는 데이터를 바탕으로 시스템이 스스로 나아지는 구조입니다.

 

이외에도 룰 에이전트에서 더 나아가 사용자의 사용 패턴을 파악하여 맞춤 답변을 제공하는 개인화 에이전트 등을 추가로 적용하고 있으며, 민원 챗봇이 단순 질의응답을 넘어 더 지능적인 서비스로 발전할 수 있도록 구조를 계속 고도화해 나갈 예정입니다.