하네스 엔지니어링 - 컨텍스트 엔지니어링을 넘어 에이전트 환경을 설계하다
2026년 03월 15일 작성TL;DR
- 프롬프트 엔지니어링은 모델에게 “무엇을 물어볼까”를, 컨텍스트 엔지니어링은 “무엇을 보여줄까”를, 하네스 엔지니어링은 “전체 환경을 어떻게 설계할까”를 다룬다.
- 하네스(harness)는 에이전트를 감싸는 스캐폴딩과 피드백 루프가 구축된 전체 운영 환경이다. CI, 린터, 권한, 실행 루프, 메모리, 아키텍처 제약 등이 모두 포함된다.
- 컨텍스트 엔지니어링은 하네스의 한 부분이다. 하네스가 없으면 아무리 좋은 컨텍스트를 줘도 에이전트는 궤도를 이탈한다.
- 2026년, 엔지니어의 역할은 코드를 직접 짜는 것에서 에이전트가 잘 동작하는 환경을 설계하는 것으로 이동하고 있다.
시작하며
이전 글에서 컨텍스트 엔지니어링1과 비즈니스 맥락을 코드에 녹이는 방법2에 대해 이야기한 적이 있다. 에이전트에게 좋은 정적 컨텍스트를 주고, 코드 자체가 비즈니스를 잘 설명하면, 에이전트가 더 안정적으로 동작한다는 이야기였다.
그런데 실제로 에이전트를 프로덕션 수준에서 운영하다 보면 컨텍스트만으로는 해결되지 않는 문제들이 생긴다. 에이전트가 린트 규칙을 무시하거나, 아키텍처 원칙에서 벗어나거나, 이미 해결된 실수를 반복하거나. 좋은 프롬프트와 좋은 컨텍스트를 줬는데도 결과가 불안정한 경험을 해본 적이 있을 것이다.
2026년 2월, Mitchell Hashimoto3와 OpenAI4가 이 영역에 이름을 붙였다. 하네스 엔지니어링(Harness Engineering)이다.
1. 하네스란 무엇인가
하네스(harness)는 원래 말을 제어하기 위한 고삐와 안장 등의 장치를 뜻한다. AI 에이전트 맥락에서의 하네스는 에이전트가 안정적으로 작업을 수행할 수 있도록 감싸는 스캐폴딩(scaffolding)이자 피드백 루프(feedback loop)가 구축된 전체 환경을 의미한다.
구체적으로 하네스에 포함되는 것들은 다음과 같다.
- 저장소 구조: 디렉토리 컨벤션, 모노레포/멀티레포 구조, 파일 명명 규칙
- CI/CD 파이프라인: 자동 테스트, 빌드, 배포 프로세스
- 린터와 포매터: 코드 스타일의 기계적 강제
- 아키텍처 제약: 커스텀 린트 규칙, 구조적 테스트
- 프로젝트 지시 파일: CLAUDE.md, AGENTS.md, .cursorrules 같은 에이전트용 지침서
- 툴 연결: MCP 서버, 외부 API, 관찰 도구
- 권한과 승인 흐름: 에이전트의 행동 범위 제한
- 실행 루프: 재시도, 에러 처리, 타임아웃
- 엔트로피 관리: 주기적으로 코드베이스의 일관성을 점검하는 가비지 컬렉션 에이전트
핵심은 이것들이 에이전트 바깥에서 동작하면서 에이전트의 행동을 제약하고 피드백을 주는 시스템이라는 점이다.
2. 프롬프트, 컨텍스트, 하네스의 관계
세 개념은 에이전트를 설계할 때 초점을 맞추는 영역이 다르다.
| 구분 | 핵심 질문 | 설계 대상 |
|---|---|---|
| 프롬프트 엔지니어링 | “무엇을 물어볼까?” | LLM에 전달하는 지시문 |
| 컨텍스트 엔지니어링 | “무엇을 보여줄까?” | LLM이 추론 시점에 보는 모든 토큰 |
| 하네스 엔지니어링 | “전체 환경을 어떻게 설계할까?” | 에이전트 바깥의 제약, 피드백, 운영 시스템 |
직관적으로는 하네스 > 컨텍스트 > 프롬프트 의 포함 관계로 볼 수 있다.
비유하자면, 프롬프트 엔지니어링이 말에게 “오른쪽으로 돌아”라고 음성으로 지시하는 것이라면, 컨텍스트 엔지니어링은 말에게 보여주는 지도와 이정표다. 하네스 엔지니어링은 고삐, 안장, 울타리, 도로 정비까지 합쳐서 말 열 마리를 동시에 안전하게 달리게 만드는 전체 설계에 해당한다.
다만, 반드시 포함 관계로만 볼 필요는 없다. Martin Fowler의 정리5에서도 언급되었듯이 “컨텍스트 엔지니어링은 모델이 잘 생각하게 돕고, 하네스 엔지니어링은 시스템이 궤도를 이탈하지 않게 막는다”는 상호 보완적 관점도 존재한다. 실무에서 중요한 것은 프레이밍이 아니라, 컨텍스트 설계만으로는 다루지 못하는 영역이 존재한다는 인식이다.
3. 컨텍스트만으로 부족한 이유
컨텍스트 엔지니어링은 에이전트가 매 순간 보게 되는 입력 정보 자체를 설계하는 것이다. 시스템 프롬프트, 작업 지시, 첨부 문서, 메모리 주입, 요약, 검색 결과, 상태 전달, 토큰 압축 등이 여기에 해당한다.
하지만 에이전트가 프로덕션 환경에서 자율적으로 동작할 때, 입력만 잘 제어한다고 해서 결과가 안정되지 않는다. 몇 가지 예를 들어보자.
에이전트가 같은 실수를 반복한다. 컨텍스트에 “이런 패턴을 따라라”고 적어줘도, 에이전트는 가끔 무시한다. 하지만 린터 규칙으로 강제하면 에이전트는 CI에서 실패 피드백을 받고 스스로 수정한다. 이것은 컨텍스트가 아니라 하네스의 영역이다.
아키텍처가 서서히 무너진다. 에이전트가 코드를 많이 생성할수록 아키텍처 일관성이 깨지는 엔트로피가 발생한다. OpenAI는 이를 “가비지 컬렉션”이라고 불렀다. 주기적으로 문서 불일치나 아키텍처 위반을 찾아 수정하는 별도의 에이전트를 돌리는 것이다. 이 역시 하네스의 영역이다.
에이전트의 행동 범위를 제한해야 한다. 특정 디렉토리만 수정하게 하거나, 프로덕션 데이터에 접근하지 못하게 하거나, PR 머지는 사람의 승인을 거치게 하는 것. 이런 권한과 승인 흐름은 컨텍스트 윈도우에 넣는 것이 아니라 실행 환경에서 강제하는 것이다.
Mitchell Hashimoto는 이를 한 문장으로 정리했다. “에이전트가 실수를 하면, 에이전트가 그 실수를 다시는 하지 못하도록 환경을 엔지니어링하라.”3 희망이 아니라 기계적 강제(mechanical enforcement)로 문제를 해결하는 것이다.
4. OpenAI의 실험이 보여준 것
OpenAI는 2026년 2월, 5개월간의 내부 실험 결과를 공개했다4. 소규모 팀이 Codex 에이전트만을 사용하여, 수동으로 작성된 코드 없이 백만 줄이 넘는 프로덕션 소프트웨어를 완성했다는 내용이다.
이 실험에서 엔지니어들이 한 일은 코드를 짜는 게 아니었다. 하네스를 설계하는 것이었다. OpenAI는 하네스의 구성요소를 크게 세 가지로 분류했다.
- 컨텍스트 엔지니어링: 코드베이스 내의 지식 베이스를 지속적으로 향상시키고, 관찰 데이터나 브라우저 탐색 같은 동적 컨텍스트에 에이전트가 접근할 수 있게 하는 것
- 아키텍처 제약: LLM 기반 에이전트뿐 아니라 결정론적인 커스텀 린터와 구조적 테스트로도 모니터링하는 것
- 가비지 컬렉션: 주기적으로 문서 불일치나 아키텍처 위반을 찾아내는 에이전트를 돌려 엔트로피와 부패에 맞서는 것
여기서 주목할 점은 컨텍스트 엔지니어링이 하네스의 한 부분으로 들어가 있다는 것이다. 좋은 컨텍스트를 주는 것은 필요하지만, 그것만으로는 충분하지 않다. 아키텍처 제약과 지속적인 엔트로피 관리가 함께 갖춰져야 에이전트가 프로덕션 수준의 코드를 안정적으로 생산할 수 있다.
5. 시기별 흐름으로 보는 진화
세 개념이 순서대로 등장한 데는 AI 활용 방식의 변화가 있다.
2023~2024년, 프롬프트 엔지니어링의 시대. ChatGPT에 질문 하나를 던지고 답변 하나를 받는 구조였다. 역할을 부여하고, 단계별로 시키고, 예시를 넣는 것만으로 원하는 결과를 끌어낼 수 있었다. 모델과의 상호작용이 일회성이었기 때문에, 지시문 자체를 최적화하는 것이 핵심이었다.
2025년, 컨텍스트 엔지니어링의 부상. 에이전트가 등장하면서, 단일 프롬프트가 아니라 RAG, MCP, 메모리, 검색 결과 등 시스템 수준의 맥락을 설계하는 것이 중요해졌다. Andrej Karpathy가 “프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로” 전환을 이야기하면서 용어가 널리 퍼졌다.
2026년 초, 하네스 엔지니어링의 등장. 에이전트가 더 자율적으로, 더 오래, 더 큰 범위의 작업을 수행하게 되면서, 입력 제어만으로는 부족한 영역이 드러났다. Mitchell Hashimoto가 2026년 2월 5일 자신의 AI 도입 여정을 공유하며 “harness engineering”이라는 용어를 처음 사용했고, 일주일 뒤 OpenAI가 Codex 실험 보고서에서 이를 공식화했다.
6. 실무에서의 의미
이 글에서 하네스 엔지니어링의 구체적인 실천법을 다루기에는 범위가 너무 넓다. 하지만 핵심 원칙은 명확하다.
희망 대신 기계적 강제를 택하라. 에이전트에게 “이렇게 해줘”라고 부탁하는 것이 아니라, 그렇게 하지 않으면 실패하도록 환경을 만들어라. 린터, CI, 구조적 테스트가 그 역할을 한다.
피드백 루프를 짧게 만들어라. 에이전트가 실수를 하면 빠르게 알 수 있어야 한다. 실패 피드백이 빠를수록 에이전트는 스스로 수정할 기회를 더 많이 얻는다.
엔트로피와 싸워라. 에이전트가 많은 코드를 생성할수록 일관성은 떨어진다. 주기적으로 코드베이스를 점검하고, 문서와 코드의 불일치를 찾아내는 프로세스가 필요하다.
컨텍스트와 하네스를 함께 설계하라. 좋은 컨텍스트 없이 하네스만 있으면 에이전트가 무엇을 해야 하는지 모른다. 좋은 하네스 없이 컨텍스트만 있으면 에이전트가 궤도를 이탈한다. 둘은 상호 보완적이다.
마치며
프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로, 다시 하네스 엔지니어링으로. 이 흐름은 AI 활용의 단위가 “한 번의 질문”에서 “한 세션의 작업”으로, 다시 “자율적인 시스템 운영”으로 확장되는 과정과 맞닿아 있다.
엔지니어의 역할도 함께 변하고 있다. 코드를 직접 짜는 사람에서, 에이전트가 좋은 코드를 짜도록 환경을 설계하는 사람으로. OpenAI의 표현을 빌리자면, 엔지니어는 “환경을 설계하고, 의도를 명확히 지정하며, 피드백 루프를 구축하는” 역할로 재정의되고 있다.
물론 하네스 엔지니어링도 아직 초기 단계다. 용어 자체가 등장한 지 한 달밖에 되지 않았고, 도구와 방법론은 계속 진화하고 있다. 하지만 에이전트를 실무에 투입해본 사람이라면, 프롬프트와 컨텍스트만으로는 해결되지 않는 문제가 있다는 것을 이미 경험으로 알고 있을 것이다. 하네스 엔지니어링은 그 경험에 이름을 붙여준 것이다.