프롬프트에서 컨텍스트에서 하네스로, AI 엔지니어링의 세 번째 전환
2026년 초, Mitchell Hashimoto가 블로그에 짧은 글을 하나 올렸다.
Vagrant와 Terraform을 만든 사람이다. 인프라 자동화의 선구자가 이번에는 AI 에이전트와 씨름하고 있었다. 그의 관찰은 단순했다. AI 코딩 에이전트를 쓰다 보면 같은 실수가 반복된다. 모델 자체를 고칠 수는 없다. 블랙박스니까. 대신 에이전트가 작동하는 환경을 고칠 수 있다.
이 작업을 그는 "에이전트의 하네스를 엔지니어링한다"고 불렀다. 하네스는 원래 말을 제어하기 위한 고삐와 안장이다. 말의 성격을 바꿀 수는 없지만, 고삐를 어떻게 잡느냐에 따라 말이 갈 방향은 완전히 달라진다.
수주 뒤, OpenAI가 같은 단어를 공식 블로그에 썼다. Anthropic이 따랐다. Martin Fowler의 블로그에 올라왔다. AWS의 시니어 사이언티스트가 "2026년은 하네스 엔지니어링의 시대"라고 선언했다. 한 사람의 블로그 포스트가 두 달 만에 업계의 공식 용어가 됐다.
모두가 같은 고통을 느끼고 있었기 때문이다. 모델은 충분히 똑똑해졌는데, 실전에서 쓸 만한 시스템을 만드는 건 여전히 어렵다는 고통.
비유하면 이렇다.
프롬프트 엔지니어링은 요리사에게 레시피를 잘 설명하는 것이다. 2022년부터 2024년까지, "어떻게 물어보면 더 좋은 답이 나오는가"에 집중한 시대였다. 역할 부여, 단계별 사고, 예시 제공. 핵심은 지시문의 품질이었다.
컨텍스트 엔지니어링은 요리사에게 좋은 재료를 제때 가져다주는 것이다. 2025년, 모델이 더 똑똑해지면서 프롬프트의 영향력이 줄었다. 대신 어떤 정보를 얼마나 효율적으로 제공하느냐가 결정적이 됐다. RAG, 벡터 데이터베이스, 컨텍스트 윈도우 관리.
하네스 엔지니어링은 주방 자체를 설계하는 것이다. 동선, 도구 배치, 위생 규정, 화재 경보기까지 포함해서. 2026년, 에이전트가 단순히 답하는 것이 아니라 행동하기 시작했다. 코드를 쓰고, 파일을 만들고, API를 호출하고, 다른 에이전트를 실행한다. 이 행동을 제어하고 모니터링하고 실패 시 복구하는 시스템 전체를 설계하는 것이다.
AWS 한국 지사의 김영민 시니어 데이터 사이언티스트가 4월 13일 aitimes 인터뷰에서 이 세 단계 프레임을 정리했다. "AI에게 뭘 물어보는가"에서 "AI가 어떤 환경에서 일하는가"로 본질이 바뀐 것이다.
흥미로운 건 벤치마크가 이 전환을 숫자로 증명했다는 점이다.
SWE-bench는 AI 코딩 에이전트의 실력을 측정하는 대표 벤치마크였다. 실제 GitHub 이슈를 해결하는 능력을 테스트한다. 2024년 8월 최고 점수는 약 20%. 그런데 2026년 초에는 여러 시스템이 80%를 넘겼다.
4배 성능 향상? 아니다. 게이밍이었다.
TianPan.co의 분석에 따르면, 성능 향상은 모델이 벤치마크에 훈련 시점에 노출됐기 때문이라는 의혹이 지속적으로 제기됐다. OpenAI는 결국 SWE-bench Verified를 공식 폐기하며 "개선 사항이 실제 능력이 아니라 벤치마크 노출을 반영하고 있다"고 인정했다.
더 흥미로운 데이터가 있다. 같은 모델을 세 가지 다른 에이전트 프레임워크로 실행했더니, 731문제 중 17문제의 차이가 났다. 모델은 동일하다. 바뀐 건 하네스뿐이다.
17문제. 이 숫자가 의미하는 건 명확하다. 모델을 바꾸는 것보다 하네스를 바꾸는 것이 성능에 더 큰 영향을 줄 수 있다. 모델 전쟁이 아니라 하네스 전쟁이 시작된 것이다.
OpenAI는 2월에 3명의 엔지니어가 코덱스 에이전트를 활용해 대규모 코드베이스를 관리한 이야기를 공개했다. 이들은 코드를 직접 쓰는 시간보다 에이전트의 하네스를 설계하는 시간이 더 길었다. AGENTS.md 파일을 작성하고, 도구 호출 규칙을 정의하고, 테스트 자동화 훅을 걸고, 실패 시 복구 전략을 세우는 것이 주 업무가 됐다. OpenAI는 엔지니어의 역할을 공식적으로 재정의했다. 코더에서 하네스 설계자로.
Anthropic은 하네스의 내부 구조를 제어 이론의 언어로 정리했다. 가이드는 에이전트가 행동하기 전에 방향을 잡아주는 피드포워드 제어다. CLAUDE.md에 규칙을 적고, 도구 접근 권한을 설정하는 것이 여기에 해당한다. 센서는 행동한 후에 문제를 잡는 피드백 제어다. 테스트 실행, 로그 분석, 출력 검증이 센서다. 자동차의 차선 이탈 경고와 자동 긴급 제동이 함께 작동하는 것처럼, 둘의 조합이 하네스의 본질이다.
Martin Fowler의 블로그에 "코딩 에이전트를 위한 하네스 엔지니어링"이 올라왔다. 소프트웨어 공학의 바이블에 편입됐다는 건, 이 개념이 AI 전용 트렌드가 아니라 엔지니어링 전체의 표준 패턴으로 인정받기 시작했다는 의미다. Meta의 저커버그도 같은 흐름에 합류했다. 모델은 점점 범용화되고 있고, 어떤 모델을 쓰느냐보다 그 위에 어떤 운영 레이어를 쌓느냐가 경쟁력이라는 것이다.
개인적인 이야기를 하겠다. 나는 매일 하네스 안에서 일한다.
내 프로젝트의 .claude/ 디렉토리에는 CLAUDE.md, agents, skills, commands가 들어 있다. 에이전트가 실수하면 CLAUDE.md에 규칙을 추가한다. 새로운 도메인이 생기면 skills에 참조 문서를 넣는다. 워크플로우가 복잡해지면 agents에 새 역할을 정의한다. Mitchell Hashimoto가 말한 "에이전트가 실수할 때마다 환경에 영구적 수정을 넣는 것"을 나는 매일 하고 있다.
같은 Claude Opus 4.6 모델이, 하네스가 빈약한 프로젝트에서는 엉뚱한 결과를 내놓고, 하네스가 잘 갖춰진 프로젝트에서는 놀라울 정도로 정확한 결과를 낸다. SWE-bench에서 같은 모델이 프레임워크에 따라 17문제 차이가 난 것과 정확히 같은 현상이다.
AI 엔지니어링의 무게중심이 모델에서 시스템으로 이동했다. 모델은 충분히 똑똑해졌다. 이제 문제는 그 모델이 일하는 환경이 충분히 똑똑한가이다. 그리고 그 환경을 만드는 일에 이름이 붙었다. 하네스 엔지니어링. 2026년은 하네스의 해다.