요즘 AI 관련 글에서 “하네스 엔지니어링”이라는 말이 자주 보입니다. 프롬프트를 잘 쓰는 것과는 무엇이 다른지 헷갈리기 쉽습니다. 이 글에서는 하네스가 무엇인지, 왜 중요해졌는지, 업무에 어떻게 적용할 수 있는지 정리합니다.
3줄 요약
- 하네스는 AI 모델을 둘러싼 실행 구조입니다. 모델이 도구를 부르고, 결과를 받고, 다음 행동을 정하는 반복 과정을 맡습니다.
- 하네스 엔지니어링은 모델 성능이 아니라 이 구조를 설계해서 AI가 끝까지 일하게 만드는 작업입니다.
- 개발자가 아니어도 “할 일 목록, 진행 기록, 확인 절차”를 파일로 남기는 방식은 바로 따라 할 수 있습니다.
하네스란 무엇인가
하네스(harness)는 원래 말에 거는 마구, 즉 힘을 알맞은 방향으로 이끄는 장구를 뜻합니다. AI 분야에서는 모델 바깥에서 모델을 움직이는 시스템을 가리킵니다.
Anthropic은 엔지니어링 블로그에서 하네스를 “Claude를 호출하고, Claude가 요청한 도구 사용을 알맞은 인프라로 연결하는 반복 루프”라고 설명합니다. 쉽게 말해 모델은 두뇌이고, 하네스는 그 두뇌가 파일을 열고 명령을 실행하게 해 주는 손발과 작업 규칙입니다.
같은 모델이라도 하네스가 다르면 결과가 크게 달라집니다. 그래서 “어떤 모델을 쓰느냐”만큼 “어떤 환경에서 일을 시키느냐”가 중요해졌습니다.
왜 필요해졌나: 긴 작업에서 생기는 문제
Anthropic은 2025년 11월 글에서 긴 작업을 맡은 AI 에이전트(스스로 여러 단계를 처리하는 AI)의 어려움을 설명했습니다. 에이전트는 작업을 세션 단위로 나눠 진행하는데, 새 세션은 이전 세션을 기억하지 못합니다. 이 글에서 확인된 대표적인 실패 패턴은 두 가지입니다.
- 한 번에 너무 많이 만들려다 기능을 반쯤 구현하고 기록도 남기지 않는 경우
- 나중 세션의 에이전트가 이미 진행된 모습을 보고 “다 끝났다”고 판단하는 경우
사람 직원에게 인수인계 문서 없이 일을 넘기면 비슷한 일이 생깁니다. 하네스는 이 인수인계를 구조로 만드는 일입니다.
구분하기: 프롬프트, 컨텍스트, 하네스
세 개념은 서로 대체하지 않고 범위가 넓어지는 관계로 보면 이해하기 쉽습니다. 아래 구분은 이 글의 설명을 위한 정리이며, 공식 정의는 아닙니다.
| 구분 | 다루는 범위 | 업무 예시 |
|---|---|---|
| 프롬프트 엔지니어링 | 한 번의 지시문 | “표로 요약해 줘”처럼 요청 문장 다듬기 |
| 컨텍스트 엔지니어링 | 모델이 읽는 정보 전체 | 참고 문서, 이전 대화, 예시를 골라 넣기 |
| 하네스 엔지니어링 | 실행 환경과 작업 흐름 전체 | 할 일 목록, 확인 절차, 기록 방식, 허용 범위 정하기 |
Anthropic 사례로 보는 하네스 구성
Anthropic이 공개한 구성은 다음과 같습니다. 첫 세션에서는 초기화 에이전트가 환경을 준비하고, 이후 세션에서는 코딩 에이전트가 기능을 하나씩 구현합니다. 두 에이전트는 같은 시스템 프롬프트와 도구를 쓰고, 처음 받는 지시만 다릅니다.
- 기능 목록 파일(JSON): 만들어야 할 기능을 모두 적고 처음에는 전부 “미통과”로 표시합니다. 글에서는 claude.ai 복제 예제에서 200개가 넘는 기능이 나왔다고 합니다. 에이전트는 통과 여부 값만 바꿀 수 있고, 테스트 항목을 지우거나 고치면 안 됩니다.
- 진행 기록 파일: 각 세션이 한 일을 적어 다음 세션이 읽습니다.
- 실행 스크립트(init.sh): 개발 서버를 켜는 방법을 정해 두어 매번 방법을 찾는 데 힘을 쓰지 않게 합니다.
- git 기록: 변경 이력을 남겨 문제가 생기면 되돌릴 수 있게 합니다.
또 에이전트에게 브라우저 자동화 도구로 사람처럼 직접 눌러 보며 확인하도록 시켰더니 검증 품질이 크게 좋아졌다고 합니다. 다만 브라우저 기본 알림 창은 도구로 볼 수 없어 그런 기능은 오류가 더 많았다는 한계도 밝혔습니다.
하네스는 계속 고쳐야 합니다
Anthropic은 2026년 4월 글에서, 하네스에는 “모델이 혼자 못 하는 것”에 대한 가정이 들어 있다고 말합니다. 예를 들어 Claude Sonnet 4.5는 맥락 한도가 가까워지면 일을 서둘러 마무리하는 경향이 있어 중간에 맥락을 초기화하는 장치를 넣었습니다. 그런데 Claude Opus 4.5에서는 이 행동이 사라져, 그 장치는 불필요한 부담이 되었습니다.
교훈은 분명합니다. 하네스는 한 번 만들고 끝이 아닙니다. 모델이 바뀌면 필요 없는 규칙은 걷어 내야 합니다.
업무에 적용하는 방법
코드를 짜지 않아도 같은 원리를 쓸 수 있습니다. 보고서나 자료 조사처럼 긴 작업을 AI에게 맡길 때 아래 순서를 권합니다.
- 목표를 한 문장으로 적고, 완료 조건을 체크리스트로 만듭니다. 이것이 기능 목록 파일 역할을 합니다.
- AI에게 한 번에 한 항목만 처리하게 합니다.
- 항목을 끝낼 때마다 한 일, 남은 일, 막힌 점을 진행 기록 파일에 적게 합니다.
- 새 대화를 열 때는 먼저 체크리스트와 진행 기록을 읽게 합니다.
- 완료 표시는 직접 확인한 뒤에만 합니다. 수치와 출처는 사람이 검수합니다.
- 쓰지 말아야 할 자료나 바꾸면 안 되는 파일 같은 허용 범위를 처음에 적어 둡니다.
- 한두 달에 한 번, 불필요해진 규칙이 없는지 점검합니다.
직접 써 보니
실제로 결과물의 퀄리티가 높아지고 오류의 빈도도 낮아졌습니다.
자주 묻는 질문
하네스 엔지니어링은 개발자만 알면 되나요?
용어는 개발 현장에서 나왔지만, 할 일 목록과 확인 절차를 문서로 남겨 AI에게 읽히는 방식은 비개발 업무에도 적용할 수 있습니다.
프롬프트 엔지니어링은 이제 필요 없나요?
아닙니다. 지시문은 여전히 하네스의 일부입니다. 하네스는 그 바깥의 도구, 기록, 검증 절차까지 포함하는 더 넓은 개념입니다.
규칙을 많이 넣을수록 좋은가요?
그렇지 않습니다. Anthropic 사례처럼 특정 모델을 위해 넣은 규칙이 모델이 좋아지면 오히려 부담이 될 수 있어서, 주기적으로 점검하고 덜어 내야 합니다.