하네스 엔지니어링
AI의 모델 성능을 높이는 것이 아니라, AI를 어떤 운영 체계 안에서 사용할 것인지를 설계하는 것이 핵심인 방법론
하네스 엔지니어링은 모델 자체를 변경하지 않는다. 대신 모델 외부에 권한, 도구, 검증 체계, 상태 관리, 관측(Observability), 피드백 루프 등을 설계하여 에이전트가 안정적이고 일관성 있게 동작할 수 있는 환경을 구축한다.
이게 왜 필요할까?
예를 들어보자.
윤아는 하루에 세 번, 민성에게 텍스트로 거짓말을 하는데,
어느날 구라를 치기 위해 타이핑을 하는 것이 귀찮아졌다.
그래서 자신의 말투를 흉내 내며 구라를 생성하는 프롬프트를 만들어 매일 클로드와 코덱스에게 입력하고, 본인 대신 구라를 치게 했다.
하지만 클로드와 코덱스는 종종 윤아의 말투를 잊거나, 미리 알려준 설정을 놓치거나, 이전에 했던 이야기와 모순되는 내용을 말하는 등 원하는 결과를 안정적으로 만들어내지 못했다.
컨텍스트 엔지니어링을 도입한다면
윤아의 SNS 대화 기록, 메신저 말투, 자주 사용하는 표현, 미리 정의한 설정 등을 AI에게 함께 제공하여 더 일관된 답변을 유도할 수 있다.
즉, AI에게 더 좋은 참고 자료를 제공하는 것이 컨텍스트 엔지니어링이다.
하지만 컨텍스트를 아무리 잘 구성해도 모델이 일부 정보를 놓치거나, 긴 문맥을 제대로 활용하지 못하거나, 상황에 따라 다른 결론을 내릴 가능성은 여전히 존재한다.
하네스 엔지니어링을 도입한다면
하네스 엔지니어링은 "정보를 더 넣어주는 것"이 아니라 AI가 일하는 방식을 설계하는 것에 가깝다.
예를 들어 다음과 같은 장치를 둘 수 있다.
- 답변 생성 전에 윤아의 최신 말투 데이터를 자동으로 불러온다.
- 과거에 했던 구라와 충돌하는 내용이 있는지 별도 검증 모듈이 확인한다.
- 말투 유사도가 일정 기준 이하이면 자동으로 다시 생성한다.
- 출력 결과를 다른 AI가 한 번 더 검토하여 설정 위반 여부를 검사한다.
- 모든 대화와 실패 사례를 로그로 저장하고, 반복되는 오류는 시스템 차원에서 개선한다.
이처럼 하네스 엔지니어링은 AI가 실수하더라도 안전하고 일관되게 동작하도록 주변 환경을 설계하는 접근법이다.
하네스의 구조
하네스는 보통 다음 요소들로 구성된다.
- Execution(실행): 작업 흐름과 에이전트 실행 제어
- Tools(도구): API, 데이터베이스, 파일 시스템 등 외부 기능 연결
- Context(컨텍스트): 필요한 정보와 메모리 제공
- State(상태): 작업 진행 상황과 중간 결과 관리
- Evaluation(검증): 출력 품질과 정책 준수 여부 확인
- Lifecycle & Feedback(생명주기 및 피드백): 로그 수집, 모니터링, 지속적인 개선
결국 프롬프트 엔지니어링이 "무엇을 말할지", 컨텍스트 엔지니어링이 "무엇을 보여줄지"를 고민하는 분야라면, 하네스 엔지니어링은 "AI가 어떤 규칙과 절차 안에서 안전하게 일하도록 만들지"를 고민하는 분야라고 볼 수 있다.
프롬프트 엔지니어링 vs 컨텍스트 엔지니어링 vs 하네스 엔지니어링
| 구분 | 핵심 질문 | 초점 |
|---|---|---|
| 프롬프트 엔지니어링 | AI에게 무엇을 지시할 것인가? | 지시문과 출력 형식 최적화 |
| 컨텍스트 엔지니어링 | AI에게 어떤 정보를 보여줄 것인가? | 문서, 메모리, 대화 이력, 검색 결과 등 컨텍스트 구성 |
| 하네스 엔지니어링 | AI가 어떤 환경과 규칙 안에서 일하게 할 것인가? | 권한, 도구, 상태 관리, 검증, 로그, 피드백 루프, 실행 환경 설계 |
하네스 관련 실험
Hashline 실험
주제: 하네스 엔지니어링은 모델을 바꾸지 않고도 AI의 성능을 크게 향상시킬 수 있을까?
세부내용 : 평소 AI의 작업 방식이 AI가 이해하기에 직관적이지 않았고,
좀 더 직관적으로 이해할 수 있도록 작업환경만 바꿔주었다.
결과 : 동일 벤치마크에서 Grok Code Fast 1의 성능이 6.7%에서 68.3%로 약 10배 향상.
전체 모델 평균 출력 토큰 약 20% 감소.
AI는 작업하는 환경에 의해서도 영향을 크게 받는다.
도구 사용 방식, 입력 형식, 검증 절차 등 하네스를 잘 설계하면 성능과 효율을 크게 개선할 수 있다.
openAI의 AGENTS.md 설계
주제: openAI의 AGENTS.md 설계 방식을 왜 목차형으로 바꾸었을까?
세부내용 : 작업환경을 한번에 적으면 양이 너무 방대하기 때문에 AI가 놓치는 경우가 생겼다.
해서, 현재 작업과 가까운 문서부터 차례대로 문서를 읽게 하는 목차형으로 md 설계 방식을 바꾸었다.
결과 : 에이전트가 필요한 정보를 더 정확하게 찾아 활용할 수 있게 되었고, 작업 효율을 높이는 동시에 불필요한 컨텍스트 사용을 줄일 수 있었다.
하네스 엔지니어링시 AI에게 모든 정보를 한 번에 주는 것보다 필요한 순간에 필요한 정보만 제공하는 것이 더 효과적이다.
시스터디 결론
A1
이 실험이 시사하는 바는 AI의 성능이 모델 자체뿐 아니라 작업 환경(하네스)에도 크게 영향을 받는다는 점입니다. 도구 사용 방식, 입력 형식, 검증 절차 등을 적절히 설계하면 모델을 변경하지 않고도 성능과 생산성을 크게 높일 수 있습니다.
이를 바탕으로 프로그램을 설계할 때는 AI가 수행해야 할 작업에 필요한 권한과 도구를 명확히 정의하고, 핵심 로직을 안정적으로 수행할 수 있도록 검증 체계와 피드백 루프를 포함한 하네스를 구축하겠습니다.
A2
OpenAI의 AGENTS.md 설계 방식이 초기에 실패한 이유는,
작업 환경에 대한 모든 지침을 AGENTS.md 하나에 한꺼번에 담았더니 문서의 양이 지나치게 방대해지면서 AI가 지침을 놓치는 경우가 생겨났기 때문입니다.
이를 해결하기 위해 OpenAI는 AGENTS.md를 목차형태로 구조화했습니다.
해당 사례를 통해 에이전트가 아키텍처 규칙을 반복적으로 위반하는 이유 중 하나는,
한 번에 너무 많은 정보를 입력받았기 때문이라는 것을 알 수 있었습니다.
그러니 우선 AI가 해야 할 일을 작은 단위로 나누어 순차적으로 수행하도록 하고, 필요한 정보만 적절한 시점에 제공하여 안정성과 일관성을 높여보겠습니다.
참고문서
프롬프트와 컨텍스트를 넘어, AI 에이전트를 위한 하네스 엔지니어링
기업 AI 운영 전략: 멀티 AI 시대의 AI 하네스 프레임워크
하네스 딥다이브 (함께보면 좋은 자료)
하네스 엔지니어링 도구 등을 다루는 가이드입니다.
JDC를 통해 추천 받았습니다. JDC 짱 ~ !
