프롬프트, 컨텍스트, 루프 및 그래프 엔지니어링은 모두 하나의 기계의 일부임이 밝혀졌습니다. 이 모든 것이 최종적으로 공존하는 곳이 바로 하네스입니다.
AI 를 활용한 개발의 각 단계에는 고유한 직무 명칭이 붙었습니다. 프롬프트 엔지니어링은 처음 등장했을 때, 그 기술의 핵심이 '적절한 문장 찾기'에 있던 시절부터 시작되었습니다.
그 뒤를 이어 컨텍스트 엔지니어링이 부상했는데, 이는 문장 자체보다 그 주변에 로드되는 모든 정보가 더 중요하다는 사실이 명확해지면서였습니다. 올여름에는 루프가 주목받았고, 몇 주 후에는 그래프가 화제가 되었습니다.
현재 확산되고 있는 명칭은 하네스 엔지니어링이며, 이는 앞서 언급된 다른 모든 영역을 설명할 수 있는 최초의 개념입니다.

하네스란 모델을 둘러싼 모든 것을 의미합니다: 모델이 호출할 수 있는 도구, 가장 먼저 읽는 파일, 쓰기 권한이 있는 디렉토리, 출력물이 통과해야 하는 검증 절차, 실행을 깨우는 스케줄러, 그리고 실행을 종료하는 규칙 등이 이에 해당합니다.
이전에 존재했던 각 분야는 사실 이 프레임워크의 개별 구성 요소였으며, 각각 따로 구축되어 별도의 이름을 부여받았습니다.
제가 이 주제에 주목하게 된 이유는 실용적이었습니다. 기반 모델은 계속 변화하며, 한 번의 업데이트로 리더보드 순위가 17 계단이나 오르기도 합니다. 반면 하네스는 시스템 내에서 유일하게 소유권을 유지할 수 있는 부분입니다.
1/ 일곱 가지 엔지니어링, 하나의 기계
분야
해결하는 질문
하네스 내 위치
프롬프트 엔지니어링
정확히 무엇을 요청하고 있는가
SKILL.md, 가장 먼저 로드되는 작업 사양
컨텍스트 엔지니어링
모델이 각 단계에서 무엇을 보는가
컨텍스트 어셈블러: 제약 조건, 스키마, 검색된 페이지
도구 엔지니어링
무엇에 접근할 수 있으며 어떤 형태인가
타입이 지정된 입력과 출력을 가진 도구 정의
루프 엔지니어링
실행을 시작하고 종료하는 것은 무엇인가
러너: 트리거, 중지 조건, 예산
그래프 엔지니어링
무엇을 기억하며 어떻게 연결되는가
메모리 레이어: 노드, 타입이 지정된 엣지, 별칭
평가 엔지니어링
결과가 어떻게 거부되는가
에이전트의 통제 밖에 있는 검증자
하네스 엔지니어링
위 모든 것을 하나로 묶는 것은 무엇인가
프레임워크, 권한 및 훅
표를 위에서 아래로 읽으면 역사입니다. 아래에서 위로 읽으면 아키텍처가 됩니다: 하네스 엔지니어링이란 나머지 여섯 가지가 어디에 위치할지를 결정하여, 그중 어느 것도 프롬프트 속에 숨겨지지 않도록 하는 업무입니다.
마지막 부분이 가장 중요한 포인트입니다.
프롬프트는 무언가를 넣기에 가장 쉬운 곳이기 때문에 모든 것이 그곳으로 흘러듭니다: 출력 형식, 중지 규칙, 지난주 수정 사항, 에이전트가 절대 만져서는 안 되는 목록 등. 작성 당시의 모델에서는 완벽하게 작동하지만, 다음 세대의 모델은 동일한 단락을 다르게 해석합니다.
2/ 하네스의 해부학
제가 습득한 가장 유용한 습관은 전체 하네스를 하나의 설정 파일로 기록하여 중요한 내용이 암묵적으로 남지 않도록 하는 것입니다:
1# harness.yaml2model: kimi-k3 # 한 줄. 아래 내용은 교체해도 그대로 유지됨3tools: [browser, fs, shell, search]4permissions:5 write: [./10-returns, ./20-graph, ./40-runs]6 ask_first: [send, publish, pay, delete]7context:8 always: [SKILL.md, CONSTRAINTS.md, SCHEMA.md]9 per_agent: return_schema10runner:11 trigger: cron "0 2 * * *" # 야간, 당신이 자는 동안12 stop: 40 verified nodes OR 3 passes with nothing new13 budget: { agents: 300, minutes: 45, retries: 2 }14memory:15 graph: ./20-graph16 aliases: ./aliases.csv17verify:18 - script: checks/schema.py19 - agent: reviewer, fresh context20hooks:21 pre_tool: hooks/pre_tool.sh22 post_run: append 40-runs/

이 파일의 세 줄이 대부분의 역할을 수행합니다.
model: 은 의도적으로 한 줄로만 구성됩니다. 나머지 부분은 해당 줄의 내용과 상관없이 작동하도록 작성됩니다. 이것이 이동성(portability)의 핵심입니다.
permissions: 는 tools: 보다 더 중요합니다. 비록 파일 내에서 더 낮은 위치에 있더라도 말입니다. 에이전트가 변경할 수 있는 것과 사전에 확인해야 할 것을 명시하는 것은, 밤새 방치해 둘 수 있는 시스템과 눈앞에서 지켜봐야 하는 시스템을 구분짓습니다.
verify: 가 두 개의 항목을 갖는 데는 이유가 있습니다. 스크립트는 비용이 들지 않으며 기계적인 오류를 잡아냅니다. 리뷰어는 첫 번째 에이전트의 작업을 본 적 없는 두 번째 에이전트입니다. 왜냐하면 자신의 출력물을 스스로 평가하는 에이전트는 승인할 이유를 찾아내기 마련이기 때문입니다.
디스크 상에서 하네스는 하나의 폴더이며, 표에 나온 각 엔지니어링 분야는 그 안에서 고유한 주소를 가집니다.

3/ Kimi K3 가 하네스에 탑재할 엔진인 이유
하네스가 필요로 하는 것
Kimi K3 가 제공하는 것
팬아웃(fan-out) 가능한 러너
Agent Swarm: 오케스트레이터 작성 없이 하나의 문제에 대해 최대 300 개의 에이전트를 동시에 실행
자체 검증을 작성할 수 있을 정도로 강력한 코드
Frontend Code Arena 에서 1,679 점으로 1 위, Fable 5 (1,631) 및 GPT-5.6 Sol (1,618) 을 제치고 7 개 도메인 중 6 개에서 선두
사용자 밑에서 개선되는 엔진
7 월 단일 업데이트로 #18 에서 #1 로 상승
첫 번째 행은 겉보기보다 훨씬 중요합니다. 거의 모든 맞춤형 하네스는 결국 수작업으로 만든 오케스트레이터를 포함하게 되며, 이는 보통 폴더 내에서 가장 취약한 파일입니다. 스웜(Swarm) 기능을 사용하면 팬아웃은 simply 예산 항목(agents: 300)이 되어 하네스는 반환 결과만 처리하면 됩니다.
두 번째 행이 중요한 이유는 하네스의 대부분이 모델이 당신을 대신해 작성하는 코드이기 때문입니다: 훅 스크립트, 스키마 검사, 40-runs 을 읽는 작은 대시보드 등. 프론트엔드 아레나에서 선두를 달리는 엔진은 이러한 코드를 첫 시도에서 훨씬 더 자주 정확하게 생성합니다.
세 번째 행은 하네스 엔지니어링의 필요성을 보여주는 단일 데이터 포인트입니다. 모델이 하룻밤 사이에 17 계단 상승할 때, 하네스는 그 상승분을 당일 바로 활용합니다. 변경해야 하는 유일한 줄은 model 이기 때문입니다.
4/ 훅(Hooks): 반사 신경
훅이란 모델이 무엇을 하기로 결정하든 상관없이, 하네스가 고정된 시점에 실행하는 짧은 스크립트입니다. 훅은 하네스가 단순한 폴더 구조를 넘어 안전 시스템처럼 행동하기 시작하는 지점입니다.
훅
발동 시점
수행 동작
pre_tool
모든 도구 호출 전
권한 목록 외부로의 쓰기를 차단
post_tool
모든 반환 후
스키마 검사를 실행하고 형식이 잘못된 출력물을 즉시 거부
pre_send
머신 밖으로 나가기 전
당신이 승인할 때까지 대기열에 보관
on_fail
거부된 결과 후
재시도 시 실패 원인을 첨부
post_run
중지 조건 충족 시
실행 기록을 40-runs 에 추가하고 그래프와 차이(diff) 비교
첫 번째 행의 pre_tool 훅은 5 줄이면 충분합니다:
1# hooks/pre_tool.sh2case "$TARGET" in3 ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;4 *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;5esac
on_fail 훅 하나만으로도 루프의 경제성을 바꿉니다. 이전 시도의 실패 원인을 전달받는 재시도는 교정이 됩니다. 그 원인 없이는 루프가 동일한 실수를 위해 두 번째 비용을 지불하게 됩니다.
5/ 야간 작업의 모습
모든 조각을 조합하면 하네스는 규칙을 따르는 야간 근무조처럼 행동합니다. 02:00 에 트리거가 발동되고, 시작 쿼리가 작업이 필요한 모든 노드를 선택합니다. 스웜이 확장되며, 노드당 하나의 에이전트가 배정됩니다.
스키마를 충족하지 못한 반환물은 그래프에 도달하기 전에 post_tool 에 의해 거부되며, 거부된 각 노드는 실패 원인이 첨부된 상태로 한 번 재시도합니다. 한 에이전트가 폴더 외부에 쓰기를 시도하면, pre_tool 이 아무도 깨우지 않고 이를 차단합니다.
병합된 노드와 타입이 지정된 엣지는 20-graph 에 저장됩니다. 초안 이메일은 pre_send 에 도달하여 대기합니다. post_run 은 기록을 추가하고, 루프는 설정 파일의 45 분 예산 내에 여유 있게 자체 조건에 따라 중지됩니다.
07:30 에 당신은 파일을 하나 읽고 두 가지 결정을 내립니다. 이것이 루프 엔지니어링과 그래프 엔지니어링을 이런 방식으로 운영할 때 발생하는 아침 시간의 전부입니다. 이것이 바로 하네스의 핵심 목적입니다: 당신 없이 실행할 수 있는 모든 것은 이미 실행되었고, 당신의 도움이 필요한 소수의 항목들은 한 곳에 모여 기다리고 있습니다.

6/ 교체 테스트
모든 에이전트 설정에 대한 가장 빠른 감사 방법: 모델 줄을 변경하고 다시 실행해 보세요. 고장 나는 부분은 하네스가 잘못된 위치에 있다는 증거입니다.
교체 후 고장 나는 것
숨겨진 위치
원래 위치
출력 형식이 벗어남
프롬프트 내 "항상 JSON 으로 답변하라"
반환 스키마 + 기타 내용을 거부하는 스크립트
실행이 자동으로 끝나지 않음
"철저히 될 때까지 계속하라"
카운트로 구성된 중지 조건
지난주의 수정 사항이 사라짐
채팅 기록
CONSTRAINTS.md, 매 실행마다 로드됨
동일한 회사가 세 번 나타남
모델의 판단
aliases.csv, 병합 전 체크
쓰면 안 되는 곳에 씀
프롬프트 내 정중한 문장
권한 목록 및 pre_tool 훅
교체 테스트를 통과하는 설정은 이식성이 있으며, 이식성은 가치를 창출합니다.

비용과 수익
기업들은 내부 에이전트 플랫폼에 분기 전체를 투자합니다. 작동하는 하네스는 폴더 하나, 설정 파일 하나, 짧은 스크립트 다섯 개로 구성되며 Kimi 구독료만으로 실행됩니다. 이 격차가 기회입니다.
채널
수익
필요한 준비물
소규모 팀을 위한 하네스 구축
그들의 워크플로우에 맞춘 설정, 훅 및 검증자를 위해 네 자리 수의 일시금 청구
스케줄에 따라 실행 중인 당신만의 하네스
출시일 리테이너
주요 모델 릴리스마다 교체 테스트를 실행하고 팀을 선두 주자로 전환하기 위한 월간 요금
이미 40-runs 에 로그를 남기는 클라이언트
니치 하네스 템플릿
하나의 산업(연구, 채용, 컴플라이언스)에 맞춰 패키징된 폴더와 yaml
두 개의 서로 다른 시장에서 검증된 동일한 하네스
두 번째 채널이 제가 가장 먼저 구축할 채널입니다. 주요 릴리스마다 리더보드가 재편성되며, K3 만 해도 한 업데이트로 17 계단 상승했습니다. 하네스를 보유한 모든 팀은 출시일에 교체 테스트를 실행할 전문가가 필요합니다.
요약
프롬프트, 컨텍스트, 도구, 루프, 그래프 및 평가 엔지니어링은 모두 하나의 기계의 구성 요소임이 밝혀졌으며, 하네스 엔지니어링은 각 구성 요소가 어디에 위치할지를 결정하는 것입니다.
모델을 한 줄 뒤에 배치하고, 도구보다 권한을 우선시하며, 검증자를 에이전트 밖에 두세요. 그러면 다음 리더보드 급등은 재구축이 아닌 설정 변경으로 해결됩니다.

유익하셨다면:
- 이 기사를 북마크하세요. 링크는 바뀌고 새로운 저장소는 매주 생겨나므로 참조용으로 필요할 것입니다.
- AI 아키텍처, 퀀트 트레이딩 및 에이전트 경제에 대한 주간 심층 분석을 보려면 저를 팔로우하세요: @polydao
- TG 채널 가입: Buzzoni Notes - 여기서 저는 X 에 올리기엔 너무 이른 원본 프롬프트, 맞춤형 스킬 및 알파 정보를 공유합니다.





