[하네스 엔지니어링 입문] 1. 등장 배경

1. AI 코딩 시대의 흐름

단계	핵심 용어	AI의 역할	개발자의 역할	핵심 질문
1	Prompt Engineering	질문에 답변	원하는 작업을 명확하게 지시	어떻게 잘 지시할 것인가?
2	Context Engineering	제공된 맥락을 바탕으로 작업	파일·구조·규칙 등 필요한 정보 제공	무엇을 알려줄 것인가?
3	Harness Engineering	에이전트가 스스로 탐색·수정·테스트·실행	에이전트가 일할 환경과 제약 설계	어떻게 올바르게 일하게 만들 것인가?

 

2. 시대별 변화

구분	프롬프트	컨텍스트	하네스
범위	1회 요청	작업·세션	프로젝트 전체
지속성	거의 없음	세션 중심	프로젝트에 지속적으로 적용
개발자 역할	지시	안내	환경 설계
규칙 전달	매번 설명	필요한 맥락 제공	문서·도구·제약으로 구조화
실수 대응	다시 요청	다시 설명	자동 검증·구조적 방지
핵심 기술	Prompt Engineering	Context Engineering	Harness Engineering

 

3. 왜 하네스가 필요한가?

• 에이전트는 하나의 요청에 대해 여러 단계를 스스로 수행할 수 있음
• ⚠️ 사람이 알고있는 프로젝트의 규칙과 설계 의도는 모두 알고 있지 않음
• ➡️ 에이전트의 자율성이 증가할수록 잘못된 판단이 실제 코드베이스에 반영될 가능성도 함께 증가함

 

발생할 수 있는 문제

문제	설명	결과
Convention Drift	네이밍·패키지·파일 구조 등 팀 규칙이 작업마다 달라짐	코드 일관성 저하
Architecture Drift	정해진 계층이나 모듈 경계를 무시한 의존성 발생	구조 복잡도 증가
같은 실수 반복	이전에 수정했던 문제를 다시 발생시킴	반복적인 리뷰·수정 비용
불필요한 파일 생성	기존 코드를 수정하지 않고 새로운 Helper·Utils 등을 계속 생성	코드베이스 복잡도 증가
검증 누락	테스트·예외 처리·정적 분석 등을 생략한 채 작업 완료	결함 발생 가능성 증가
작업 미완료	일부 작업을 TODO로 남기거나 중간 상태에서 완료 판단	사람의 추가 작업 필요

 

하네스의 필요성

• 에이전트의 실수를 프롬프트나 컨텍스트 추가만으로 해결하면, 동일한 규칙을 반복해서 설명해야 함
• ⚠️ 사람이 계속 에이전트를 관리해야 함
• ➡️ 반복되는 실수의 원인을 규칙/도구/검증 체계로 구조화하여 시스템적으로 해결함

 

예시) 반복적인 실수를 하네스로 해결하기

• 기존 방식: 에이전트 실수 → 사람이 수정 지시 → 에이전트 수정 → 이후 비슷한 실수 재발
• Harness 방식: 에이전트 실수 → 원인 파악 → 규칙 / 테스트 / CI 등에 반영 → 이후 작업에서 자동 예방·검출

 

 

출처 

• Wiki Docs - 하네스 엔지니어링 입문