프롬프트를 아무리 잘 써도, 에이전트에게 30분짜리 작업을 맡기면 어딘가에서 반드시 삐끗한다. 파일을 엉뚱하게 건드리고, 맥락을 잃고, 같은 실수를 반복한다. 2026년 현재 이 문제를 다루는 방식에 이름이 붙었다. 하네스 엔지니어링(Harness Engineering) 이다.

이 글은 요즘 개발자 커뮤니티, 해외 아티클, 국내 블로그에서 가장 많이 언급되는 하네스 기법들을 방법론 중심으로 길게 정리한 것이다.

1. 왜 프롬프트가 아니라 '하네스'인가

지난 3년간 우리가 AI를 다루는 단위는 계속 커졌다.

• 2023년 — 프롬프트 엔지니어링: 한 번의 요청을 잘 쓰는 기술.
• 2025년 — 컨텍스트 엔지니어링: 모델이 매 순간 '무엇을 보는가'를 설계하는 기술.
• 2026년 — 하네스 엔지니어링: 에이전트가 감독 없이 수백 번의 결정을 내리며 '자율적으로 도는 환경 전체'를 설계하는 기술.

프롬프트는 단발성 출력을 좋게 만들고, 컨텍스트 엔지니어링은 모델의 시야를 관리한다. 하지만 둘 다 "에이전트가 몇 시간 동안 혼자 돌면서 벌어지는 일"은 책임지지 못한다. 그 빈틈을 메우는 게 하네스다.

하네스는 에이전트 자체(모델)가 아니다. 모델을 감싸는 작동 환경 전체 — 루프, 도구, 가드레일, 피드백 루프, 관측(observability) 레이어 — 를 말한다. 쉽게 말해 "똑똑하지만 제멋대로인 인턴"에게 붙여주는 작업 규율과 안전장치다.

2. 방법론의 핵심 한 문장

이 분야에 불을 붙인 건 2026년 2월 Mitchell Hashimoto의 글이었다. 그가 말한 원칙은 놀랍도록 단순하다.

"에이전트가 실수를 하면, 그때마다 그 실수를 다시는 못 하도록 환경 자체에 영구적인 해결책을 심어라."

프롬프트를 그때그때 손보는 게 아니라, 실수를 구조로 박제하는 것이다. 린트 규칙, 테스트, 훅(hook), 권한 제한, 문서(AGENTS.md) — 어떤 형태로든 "같은 실수가 두 번 일어나지 않는 환경"을 만들어 나간다. 하네스 엔지니어링은 결국 이 루프를 반복하며 환경을 계속 단단하게 만드는 작업이다.

3. 에이전트를 굴리는 3대 추론 패턴

하네스의 심장은 '루프'다. 어떤 루프를 쓰느냐가 첫 번째 설계 결정이다.

ReAct (Reasoning + Acting)

가장 표준적인 단일 에이전트 패턴. 생각 → 행동 → 관찰을 목표에 도달할 때까지 반복한다. 스크래치패드에 추론하고, 도구를 고르고, 결과를 보고, 다시 생각한다. 2026년 기준 "일단 이걸로 시작하라"는 기본값이다.

Plan-and-Execute

긴 호흡의 작업에 강하다. 먼저 플래너가 단계 목록을 만들고, 그다음 실행기(보통 더 싸고 빠른 모델)가 한 단계씩 밟는다. 대규모에서 비용이 싸지만, 중간에 계획을 갈아엎어야 하는 상황엔 취약하다.

Reflexion

위 둘에 자기 비판 루프를 더한다. 실패를 말로 정리해 다음 시도에 반영한다. 같은 실패가 반복되는 워크플로우라면 여기에 붙이는 게 정답이다.

실무 결론은 명확하다. ReAct를 기본으로 깔고, 반복되는 실패가 보이면 Reflexion을 얹는다. 이 조합이 프로덕션급 단일 에이전트 스택이다.

4. 컨텍스트를 다루는 4가지 실전 기법

루프를 정했다면, 그다음은 "매 호출마다 모델에게 뭘 보여줄 것인가"다. 여기서 승부가 갈린다. 토큰을 많이 넣을수록 좋아지는 게 아니라 오히려 나빠진다는 게 2026년의 공통된 교훈이다.

(1) JIT 컨텍스트 (Just-in-Time)

컴파일러의 JIT와 같은 발상이다. 컨텍스트 창을 본문 대신 포인터로 채운다. 에이전트는 "무엇이 존재하는지"만 안다 — 스킬은 메타데이터로, 데이터는 참조로, 도구는 얇은 인덱스로. 무거운 내용은 필요한 순간에만 로드하고 곧바로 놓아준다.

(2) 서브에이전트 (컨텍스트 격리)

메인 에이전트가 웹 검색, 파일 읽기, DB 쿼리처럼 출력이 큰 도구를 쓰면 창이 순식간에 오염된다. 해법은 그 일을 독립된 컨텍스트 창을 가진 서브에이전트에게 맡기는 것. 서브에이전트는 부모의 대화 이력을 보지 못한 채 깨끗한 창에서 일하고, 최종 요약만 부모에게 돌려준다. 메인의 컨텍스트는 수십 번의 도구 호출이 아니라 그 요약 한 줄만큼만 늘어난다. 조사처럼 병렬화 가능한 읽기 작업에 특히 잘 맞는다.

(3) 컨텍스트 컴팩션 (압축)

긴 세션에서 이력이 불어나면 단계적으로 줄인다. 대표적인 참조 구현인 Claude Code는 예산 축소 → snip → 마이크로컴팩트 → 컨텍스트 붕괴 → 자동 압축의 다단계 파이프라인을 매 모델 호출 전에 돌린다. 단일 전략 하나로는 모든 종류의 컨텍스트 압박을 못 막기 때문에 여러 층으로 나눈 것이다.

(4) 스킬 & 도구 로드아웃 (온디맨드)

모든 도구 정의와 절차를 프롬프트에 미리 때려 넣지 않는다. 대신 절차는 스킬로 빼두고, 도구는 RAG에 넣어 에이전트가 지금 의도에 맞는 것만 검색해 로드한다. 2026년 5월 Microsoft가 Visual Studio에 Agent Skills를 정식 탑재하면서, 이건 사실상 업계 표준 패턴이 됐다.

5. 관측과 평가 — 하네스를 '자산'으로 만드는 층

여기까지가 에이전트를 '돌리는' 방법이라면, 마지막 한 층은 에이전트를 믿을 수 있게 만든다.

• 관측(Observability): 에이전트가 무슨 판단을 왜 했는지 추적 가능해야 한다. 로그와 트레이스가 없으면 실수를 구조로 박제할 수도 없다.
• 평가(Eval) 주도 개선: 하네스를 바꿀 때마다 "정말 나아졌는가"를 벤치로 확인한다. 감으로 프롬프트를 고치던 시절과의 결정적 차이다.
• 거버넌스/권한: 각 서브에이전트에게 그 책임에 필요한 최소 권한만 준다. 이게 안전성과 재현성을 동시에 잡는다.

정리하면, 성숙한 하네스는 대략 이런 층으로 쌓인다: 실행(루프) · 도구 · 컨텍스트 · 생명주기 · 관측 · 검증 · 거버넌스.

6. 오늘 바로 시작하는 체크리스트

거창한 프레임워크부터 도입할 필요는 없다. 작게 시작하자.

1. 루프부터: ReAct로 시작하고, 반복 실패가 보이면 Reflexion을 얹는다.
2. 컨텍스트는 비운다: 다 넣지 말고, 포인터와 JIT 로딩으로 창을 가볍게.
3. 큰 출력은 서브에이전트로 격리: 조사/검색은 따로 돌려 요약만 받는다.
4. 실수는 프롬프트가 아니라 환경에 고친다: 린트·테스트·훅·문서로 박제.
5. 바꿀 때마다 평가한다: eval 없이 하네스 개선은 자기기만이다.

마치며

2025년이 에이전트를 '만드는' 해였다면, 2026년은 에이전트를 안전하고 안정적으로 '운영하는' 구조를 설계하는 해다. 하네스 엔지니어링은 화려한 새 모델 소식은 아니지만, 실제로 에이전트를 프로덕션에서 일하게 만드는 건 결국 이 지루한 방법론 쪽이다. 모델 순위는 몇 달마다 뒤집혀도, "실수를 구조로 박제한다"는 원칙은 한동안 유효할 것이다.

여러분의 에이전트 하네스는 지금 몇 층까지 쌓여 있는가?