왜 프롬프트 엔지니어링 다음이 하네스인가
질문과 답변만 주고받던 시절의 AI 활용법은 프롬프트를 다듬고 RAG로 컨텍스트를 잘 넣어주는 것이었습니다. 모델이 약했기 때문에 입력을 정성껏 포장해야 좋은 답이 나왔습니다. 지금의 모델은 다릅니다. 똑똑하고 할 수 있는 일도 많지만, 자유롭게 풀어놓으면 엉뚱한 방향으로 달립니다.
그래서 초점이 입력의 포장에서 행동의 설계로 옮겨갔습니다. 에이전트에 어떤 도구(파일 읽기·수정, 웹 검색, 터미널 실행)를 허용할지, 어떤 순서로 일하게 할지, 무엇을 금지할지를 정하는 일. 이것이 하네스 엔지니어링이고, 프롬프트 엔지니어링의 다음 단계로 자리 잡고 있습니다.
같은 모델, 다른 성능 — 하네스가 가르는 것
흥미로운 사실은 모델을 바꾸지 않아도 하네스만으로 성능이 달라진다는 점입니다. 한 오픈소스 에이전트는 AI가 코드 수정안을 출력하는 형식을 바꾸는 것만으로 코딩 성능을 눈에 띄게 끌어올렸습니다. 에이전트가 수정 위치를 찾는 방식, 결과를 검증하는 방식 같은 작동 구조가 모델의 지능만큼이나 결과를 좌우합니다.
이는 비용 관점에서도 의미가 큽니다. 더 비싼 모델로 갈아타는 것은 가장 쉬운 선택이지만, 하네스를 손보는 것이 더 싸고 효과적인 경우가 많습니다. "AI 써 봤는데 별로던데요"라는 평가의 상당수는 모델의 한계가 아니라 하네스의 부재에서 나옵니다.
비개발자도 가능한 하네스 엔지니어링
에이전트 코드를 직접 고치는 것은 개발 지식이 필요하지만, 진입로는 그보다 훨씬 낮은 곳에 있습니다. AGENTS.md나 SKILL.md 같은 마크다운 파일에 "이건 하지 마라", "이 프로젝트 구조는 이렇다", "이 형식으로 출력하라"를 적어두는 것도 엄연한 하네스 엔지니어링입니다. 에이전트는 작업 전에 이 문서들을 읽고 그대로 따릅니다.
반려견 훈련과 비슷합니다. 좋은 개를 데려오는 것보다 훈련 방법이 결과를 가릅니다. 다만 명령이 길고 복잡해지면 알아듣지 못하는 것도 비슷하므로, 규칙은 짧고 명확하게 쪼개서 문서화하는 것이 좋습니다.
AX 관점: 도구 도입보다 규칙의 문서화가 먼저다
SH Consulting이 AX(AI Transformation) 교육에서 하네스 엔지니어링을 비중 있게 다루는 이유도 여기에 있습니다. 조직에 필요한 것은 새 도구의 도입이 아니라, 우리 업무의 규칙·금기·판단 기준을 AI가 읽을 수 있는 문서로 옮기는 습관입니다. 그 문서가 쌓이면 어떤 에이전트를 붙여도 조직의 방식대로 일하게 만들 수 있습니다.