현장에서 에이전트 PoC가 멈추는 지점은 비슷하다. 데모에서는 답을 잘한다. 실제 업무로 옮기면 맥락을 잃고, 같은 파일을 다시 읽고, 권한 없는 도구를 호출하고, 실패를 설명하지 못한다. 이때 문제는 모델 성능 하나가 아니다. 모델을 둘러싼 하네스가 없거나, 있어도 프롬프트 묶음에 그친다.
하네스는 프롬프트가 아니라 작업대다
하네스 엔지니어링은 모델 바깥의 작업 환경을 설계하는 일이다. 모델에게 긴 지시문을 더 붙이는 일이 아니다. 어떤 context를 넣을지, 어떤 tool을 열어줄지, 어떤 memory를 남길지, 어떤 제어 루프로 중단·재시도·승인을 걸지 정하는 일이다.
Anthropic은 2025년 11월 long-running agents 글에서 장시간 작업의 핵심 문제를 “여러 context window를 건너 일관되게 진행하는 것”으로 잡았다. 초기화 에이전트와 작업 에이전트를 나누고, 다음 세션이 이어받을 artifact를 남기는 패턴을 제시했다. 이는 하네스가 단순한 wrapper가 아니라 작업 인계 체계라는 뜻이다. (anthropic.com)
에이전트는 똑똑한 답변자가 아니라, 통제된 작업 환경 안에서 반복 실행되는 운영 단위다.
네 부품은 따로 설계해야 한다
하네스를 처음 설계할 때는 네 부품을 한 문서에 섞지 않는다. 섞는 순간 책임 경계가 사라진다.
| 부품 | 설계 질문 | 실패 징후 |
|---|---|---|
| context | 지금 판단에 꼭 필요한 업무 맥락은 무엇인가 | 긴 문서만 넣고 우선순위가 없다 |
| tool | 어떤 행위까지 모델에게 허용할 것인가 | 조회와 변경 권한이 섞인다 |
| memory | 다음 실행에 남길 사실은 무엇인가 | 로그는 많은데 재사용 가능한 기억이 없다 |
| 제어 루프 | 언제 멈추고, 묻고, 재시도할 것인가 | 실패 후 같은 행동을 반복한다 |
MCP는 tool과 data source 연결을 표준화하려는 흐름의 중심에 있다. 2025년 11월 MCP specification은 elicitation처럼 서버가 사용자 추가 정보를 요청하는 흐름도 다룬다. OpenAI도 2025년 Responses API에 remote MCP server 지원을 추가했다고 발표했다. 도구 연결은 이제 개별 커넥터 제작 문제가 아니라 권한, schema, 호출 이력, 실패 처리까지 포함한 운영 설계 문제다. (modelcontextprotocol.io)
A2A v1.0 문서도 같은 방향을 보여준다. A2A는 에이전트 간 상호운용을 위해 task, message, artifact, agent card 같은 단위를 정의한다. MCP가 에이전트와 도구의 접속면이라면, A2A는 에이전트와 에이전트의 협업면이다. 둘 다 하네스 바깥의 표준이 아니라 하네스 안으로 흡수해야 할 인터페이스다. (a2a-protocol.org)
제어 루프가 운영 품질을 결정한다
대기업 업무에서 중요한 것은 “모델이 해냈다”가 아니다. 누가 승인했고, 어떤 근거로 실행했고, 실패했을 때 어디서 멈췄는지가 남아야 한다. 그래서 하네스에는 최소한의 제어 루프가 필요하다.
- 입력 분류: 요청이 조회인지, 생성인지, 변경인지 구분한다.
- context 조립: 업무 규칙, 최근 데이터, 사용자 권한을 분리해 넣는다.
- tool 실행: 읽기·쓰기·외부전송 도구를 다른 정책으로 묶는다.
- 검증과 인계: 결과 schema, 근거, 다음 action을 artifact로 남긴다.
OpenAI는 2026년 3월 Responses API의 computer environment 글에서 중간 파일 위치, 큰 표를 prompt에 붙이는 문제, 네트워크 접근, timeout과 retry를 실제 에이전트 구축의 문제로 설명했다. 이 목록은 그대로 운영 하네스의 체크리스트다. (openai.com)
Structured Outputs 같은 기능도 여기서 의미가 있다. 형식 안정성은 보기 좋은 JSON을 받기 위한 장치가 아니다. 후속 시스템이 결과를 검증하고, 승인 화면에 올리고, 재시도 여부를 판단하게 만드는 계약이다. (platform.openai.com)
참고를 보고 작은 루프부터 고정한다
하네스 엔지니어링의 출발점은 거창한 multi-agent 설계가 아니다. 한 업무의 입력, context, tool, memory, 제어 루프를 고정하는 것이다. 그 한 루프가 안정되면 다른 업무로 복제할 수 있다. 안정되지 않은 상태에서 도구와 에이전트 수를 늘리면 장애 표면만 넓어진다.
참고:
- Anthropic, Effective harnesses for long-running agents, 2025: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Anthropic, Building agents with the Claude Agent SDK, 2025: https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk/
- OpenAI, From model to agent: Equipping the Responses API with a computer environment, 2026: https://openai.com/index/equip-responses-api-computer-environment/
- OpenAI, New tools and features in the Responses API, 2025: https://openai.com/index/new-tools-and-features-in-the-responses-api/
- Model Context Protocol Specification, 2025: https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation
- A2A Protocol Specification v1.0, 2026: https://a2a-protocol.org/dev/specification/
AX LABS는 이 루프를 PoC 산출물이 아니라 운영 단위로 설계한다. 하네스까지 포함해 에이전트를 업무에 붙이는 접근은 AX Ops 방법론 →에서 더 자세히 다룬다.