하네스 엔지니어링은 무엇인가
LLM 모델 성능은 이미 충분히 높아졌습니다. Claude, GPT, Gemini 모두 일정 수준 이상의 결과를 안정적으로 만들어냅니다. 그런데도 엔터프라이즈 환경에서는 동일한 문제들이 반복됩니다.
- 데모에서는 잘 작동하던 에이전트가 프로덕션 환경에서 작동하지 않습니다.
- 작업이 길어질수록 결과물의 일관성이 깨집니다.
- 검증되지 않은 결과가 그대로 반영됩니다.
이처럼 아무리 강력한 모델이더라도 방향을 잡아주는 구조 없이는 제대로 사용할 수 없습니다.
말(馬)의 강력한 힘을 인간의 의도대로 제어하기 위해 고삐(Harness)가 필요했듯, AI 에이전트에게도 그 힘을 통제하고 방향을 잡아주는 구조가 필요합니다. 바로 여기에서 Harness Engineering이라는 개념이 등장했습니다.
프롬프트에서 하네스로, AI 엔지니어링의 범위 확장
AI가 처음 활용되기 시작했을 때, 프롬프트 엔지니어링(Prompt Engineering)에 대한 관심도가 매우 뜨거웠습니다. 바로 LLM 모델에게 어떻게 질문하느냐가 결과의 질을 결정한다는 개념이었습니다.
이메일 작성이나 텍스트 요약처럼 한 번의 요청으로 끝나거나 단순한 작업에서는 프롬프트 엔지니어링을 잘 하는 것만으로도 충분했습니다. 그러나 기업체 단위의 복잡하고 긴 작업에서는 프롬프트 엔지니어링의 한계가 드러났습니다.
- 하나의 요청으로는 작업을 안정적으로 수행하기 어렵습니다.
- AI는 자신이 만든 결과물을 스스로 평가할 때 관대해지는 경향이 있습니다.
- 여러 단계를 한 번에 처리하려고 하면 품질을 안정적으로 유지하기 어렵습니다.
그러면서 컨텍스트 엔지니어링(Context Engineering)이 등장했습니다. 컨텍스트 엔지니어링은 모델이 작업하는 시점에 필요한 정보(메모리, 도구 정의, 작업 이력, 외부 데이터)를 적절하게 구성하는 구조적 접근 방식입니다.
프롬프트 엔지니어링과 컨텍스트 엔지니어링은 모두 제품 안에서 작동하는 엔지니어링입니다. AI 서비스나 에이전트의 성능을 높이기 위해 모델에게 전달되는 입력과 정보를 최적화하는 방식입니다.
Harness Engineering은 작동하는 위치가 다릅니다. 제품 안의 모델 성능을 다루는 것이 아니라, 제품 바깥에서 에이전트가 코드를 작성하고 검증하고 개선하는 개발 환경 전체를 설계하는 일입니다. AI로 제품을 만드는 방식 자체를 구조화하는 기술입니다.
- 프롬프트 엔지니어링: 모델에게 무엇을 어떻게 질문하는가
- 컨텍스트 엔지니어링: 모델이 어떤 정보를 기반으로 판단하도록 설정하는가
- 하네스 엔지니어링: 에이전트가 일할 수 있는 전체 시스템을 어떻게 설계하는가
3명이 100만 줄의 코드를 만들었다. 직접 작성한 코드는 없었다.
2026년 2월, OpenAI는 Harness Engineering 개념을 실제 사례로 보여주는 글을 공개했습니다.
OpenAI의 엔지니어팀은 단 3명으로 시작해 5개월 만에 약 100만 줄의 코드를 완성했습니다. 사람이 직접 작성한 코드는 단 한 줄도 없었습니다. 모든 코드는 Codex 에이전트가 작성했고, 코드 리뷰 역시 에이전트가 수행했습니다.
이 프로젝트에서 엔지니어들의 역할은 코드를 작성하는 것이 아니었습니다. 에이전트가 일할 수 있는 환경과 구조를 설계하는 것이었습니다. 결과적으로 팀은 엔지니어 1인당 하루 평균 3.5개의 PR을 머지했고, 팀 규모가 증가해도 생산성은 유지되었습니다.
이 실험을 통해 우리는 AI 시대의 엔지니어링이 빠르게 변화되고 있음을 알 수 있습니다.
에이전트는 자신이 접근 가능한 컨텍스트 안에서만 작동한다
OpenAI 실험에서 중요한 구조 중 하나는 AGENTS.md 파일입니다. 이 파일은 에이전트가 작업 방식을 이해할 수 있도록 정의된 실행 규칙 문서입니다. 바로 GitHub 레포지토리 안에 위치하며, 에이전트가 어떻게 작업해야 하는지를 기계가 읽을 수 있는 형식으로 정의한 문서입니다. 어떤 명령어를 실행해야 하는지, 어떤 컨벤션을 따라야 하는지, 어떤 패턴을 사용해야 하는지가 담겨 있습니다.
에이전트의 관점에서, 컨텍스트 안에서 접근할 수 없는 것은 존재하지 않는 것과 같습니다. Slack 스레드에 있는 논의, Google Docs에 있는 결정 사항, 담당자의 머릿속에 있는 지식은 에이전트에게 보이지 않습니다.
따라서 에이전트가 접근할 수 있었던 GitHub 레포지토리 안에는 문서, 아키텍처 규칙, 품질 기준, 실행 계획이 모두 포함되며, 에이전트가 읽을 수 있는 형태로 유지되어야 합니다.
하네스의 주요 구성 요소
Harness Engineering의 구조는 도메인과 팀의 상황에 따라 다르게 설계됩니다. 다만 실무에서 반복적으로 등장하는 공통 레이어가 있으며, 주로 아래 다섯 가지를 중심으로 구성되는 경향이 있습니다. 오픈소스 구현체에서도 작업 분해, 역할 분리, 검증 구조가 핵심 패턴으로 반복 등장합니다.
제약이 많을수록 결과는 안정된다
Aakash Gupta의 분석은 하네스 구조의 효과를 수치로 보여줍니다. 하네스를 적용하면 초기 비용은 증가하지만, 결과 품질과 유지 가능성은 크게 개선된다고 합니다. 그 결과, 하네스는 선택적인 설계가 아니라 결과 품질과 운영 안정성을 확보하기 위한 필수 구조로 인식되기 시작했습니다.
엔지니어의 역할은 구조를 설계하는 방향으로 바뀌고 있습니다
하네스 엔지니어링이 도입된 팀에서 엔지니어의 하루는 다르게 시작됩니다. 코드를 직접 작성하는 대신, AGENTS.md를 업데이트하거나 검증 게이트에 새로운 테스트를 추가하거나, 어젯밤 에이전트가 반복한 실패 패턴을 분석해 린트 규칙으로 인코딩하는 작업이 하루의 주요 업무가 됩니다.
팀 조직 구조도 달라집니다. 하네스 기반 멀티 에이전트 구조에서는 역할이 분리됩니다. 하네스 설계와 아키텍처 제약을 주도하는 역할, 지식 베이스와 컨텍스트 품질을 관리하는 역할, 검증 기준과 피드백 루프를 정의하는 역할이 나뉘면서, AI 시스템 운용이 개인의 역량에서 팀 단위의 엔지니어링 과제로 이동합니다. 협업의 중심도 코드 리뷰에서 하네스 설계 리뷰로 옮겨가고 있습니다.
결과적으로 하네스 엔지니어링은 개인의 기술 스택을 바꾸는 것을 넘어, 팀이 AI와 협업하는 방식 전체를 재설계하는 과제입니다. 코드를 빠르게 작성하는 능력보다, 에이전트가 신뢰할 수 있는 환경을 만드는 능력이 팀의 실질적인 경쟁력이 되고 있습니다.
그렇다면 Enhans는 하네스 엔지니어링을 어떻게 적용하는가
그렇다면 Enhans는 실제 개발 현장에서 하네스를 어떻게 설계하고 있을까요? 개발의 최전선에서 업무를 하고 있는 어느 한 엔지니어분의 사례를 소개하겠습니다.
이 엔지니어는 여러 레포지토리를 동시에 관리합니다. 이 프로젝트는 테스트를 먼저 돌려야 하고, 저 프로젝트는 API 변경 시 문서를 먼저 고쳐야 하고, 또 다른 프로젝트는 특정 브랜치 전략을 따라야 합니다. 이런 노하우는 개발자의 머릿속에만 있습니다. AI 에이전트에게 작업을 맡길 때마다 매번 말로 전달하는 방식은 작업의 규모가 커질수록 적합하지 않습니다.
Enhans의 한 엔지니어는 워크스페이스 오케스트레이터를 통해 이 문제를 풀고 있습니다. 개발자 한 명이 여럿의 에이전트로 분화되어, 한 명은 코드를 짜고, 한 명은 리뷰하고, 한 명은 버그를 추적하고, 한 명은 설계를 정리합니다. 이 분화된 역할들을 개발자가 직접 조종하는 것이 아니라, 레포지토리 별로 축적된 규칙을 파일로 정의해두어 에이전트가 그 규칙 안에서 작동하게 만드는 것입니다.
세 계층 구조
워크스페이스 오케스트레이터 시스템은 세 계층으로 구성됩니다.
사용자는 방향을 잡고 승인만 합니다. 오케스트레이터 계층이 하네스 역할을 맡습니다. 사용자의 요청을 받아 의도를 파악하고, 계획을 세우고, 에이전트에게 위임하고, 결과를 감시하고, 문제가 있으면 교정합니다. 이 오케스트레이터는 직접 코드를 작성하지 않습니다. 실제 작업은 4개의 에이전트가 수행합니다.
각 에이전트는 역할 정의 파일을 갖고 있으며, 해서는 안 되는 일이 명확하게 규정되어 있습니다.
규칙 체계
에이전트를 통제하는 것은 두 종류의 규칙 파일입니다.
- 행동 규범(norms): 에이전트의 판단 기준이 되는 원칙들입니다. 예를 들어 "코드에서 확인 가능한 사실은 되묻지 말고 판단하라", "사용자의 의견에 순응하지 마라, 논리적 문제가 있으면 근거를 들어 반론하라", "구현 완료 후 배포 전에 규범을 다시 읽고 자체 점검하라" 등이 포함됩니다.
- 금지 사항(guardrails): 에이전트가 넘어서는 안 되는 하드 바운더리입니다. "코드 바깥의 맥락은 코드만 보고 단정하지 마라", "재검토 요청 시 이전 결론에 끌려가지 말고 처음부터 다시 확인하라" 등이 여기에 해당합니다.
이 워크플로우의 핵심 원칙은 바로 승인된 계획 없이 구현을 시작할 수 없다는 것입니다. 모든 진행 상황은 프로젝트별 스레드 문서에 기록됩니다.
피드백 루프: 실패에서 규칙이 만들어진다
이 시스템에서 가장 주목할 부분은 자동 학습 회로입니다. 사용자가 "하지마", "그거 말고", "왜 자꾸"처럼 교정 신호를 보내면, hooks가 이를 감지해 버퍼 파일에 기록합니다. 이후 컨텍스트 압축이 발생할 때 이 신호를 에이전트 컨텍스트에 재주입합니다.
에이전트는 이 신호를 받아 실제 행동 교정이 필요한지 판단하고, 필요하다면 사례 파일로 기록하거나 규범과 가드레일 업데이트를 제안합니다. 컨텍스트가 초기화되어도 교정 신호는 살아남고, 반복되는 실패는 구조 개선으로 이어집니다.
이 전체 시스템에 애플리케이션 코드는 없습니다. 마크다운 파일, JSON 설정 하나, 셸 스크립트 두 개가 전부입니다. 에이전트의 네이티브 기능 조합만으로 행동을 구조화하고 실패에서 학습시킬 수 있다는 점을 보여주는 실제 사례입니다.
마치며
1. 구조 설계가 점차 중요해집니다.
아무리 강력한 AI 모델도 방향을 잡아주는 구조 없이는 엔터프라이즈 환경에서 성공할 수 없습니다. 데모에서는 잘 작동하던 에이전트가 프로덕션에서 무너지는 이유는 적절한 설계 구조의 부재이기 때문입니다.
2. 엔지니어링의 관점이 확장하고 있습니다.
프롬프트 엔지니어링은 단일 작업에 유효했습니다. 컨텍스트 엔지니어링은 다단계 작업으로 확장했습니다. 하네스 엔지니어링은 엔터프라이즈 규모의 복잡한 자동화 전체를 다룹니다.
3. Harness, 지금부터 시작하는 것이 빠릅니다.
Claude, GPT, Gemini 등 모델 성능의 간극은 빠르게 줄어들고 있습니다. 지금부터 경쟁 우위를 만드는 것은 에이전트가 일할 수 있는 구조를 얼마나 잘 설계했느냐가 될 것입니다.
in solving your problems with Enhans!
We'll contact you shortly!