하네스라는 말이
너무 쉬워졌다

"하네스는 에이전트 팀 이름표가 아니다. 하네스는 LLM이 grep으로 찾고, bash로 실행하고, loop로 고치고, cron이나 trigger로 다시 돌고, verifier로 검증하고, trace로 증거를 남기게 만드는 실행 통제 구조다."

요즘 AI 업계에서 "하네스 엔지니어링"이라는 말이 부쩍 자주 보인다. 그런데 막상 내용을 열어보면 이상하다. 하네스라기보다 플러그인 설치, 스킬 조합, 에이전트 역할 분담, 오케스트레이터 구성에 가까운 경우가 대부분이다.

물론 그런 구성도 유용하다. 에이전트에게 역할을 나누고, 스킬을 정의하고, 작업 순서를 설계하는 일은 분명 중요하다. 하지만 그것만으로 하네스라고 부르기에는 한참 부족하다.

하네스(harness)는 원래 무언가를 붙잡고, 연결하고, 제어하고, 안전하게 작동하도록 만드는 구조다. 등산용 안전벨트가 그렇고, 마구(馬具)가 그렇다. 힘을 흘려보내되, 통제 안에서 흐르게 한다.

AI 작업에서의 하네스도 다르지 않다. 모델이 말만 하는 것을 넘어서 실제 파일을 읽고, 명령을 실행하고, 결과를 만들고, 검증하고, 실패하면 다시 돌고, 실행 기록을 남기게 만드는 운영 계층이어야 한다.

01하네스가 아닌 것들

먼저 무엇이 하네스가 아닌지부터 분명히 해두자.

하네스는 단순한 프롬프트 묶음이 아니다.
하네스는 단순한 에이전트 팀이 아니다.
하네스는 단순한 스킬 폴더가 아니다.
하네스는 단순한 플러그인 설치법이 아니다.

이것들은 하네스의 재료일 수는 있어도, 하네스 그 자체는 아니다. 재료를 쌓아놓는다고 구조가 되지는 않는다.

02진짜 하네스에는 실행성이 있다

진짜 하네스의 핵심은 실행성이다. 말로 끝나지 않고 실제 환경에 손을 대는 능력. 구체적으로는 다음 다섯 가지 기능이 있어야 한다.

파일을 찾는 기능. grep, 검색 인덱스, AST 분석, 벡터 검색 — AI가 작업 대상을 실제로 찾아낼 수 있어야 한다.

반복 실행 구조. loop, retry, self-check, refine cycle — 한 번에 끝나지 않는 일을 돌려가며 고칠 수 있어야 한다.

시간·조건 기반 재실행. cron, scheduler, webhook, event trigger — 사람이 매번 누르지 않아도 다시 돌아가는 구조가 있어야 한다.

실제 환경을 건드리는 실행 계층. bash, shell command, filesystem API, browser automation, database query, API call — 판단을 행동으로 바꿀 수 있어야 한다.

그리고 무엇보다, 검증. 파일이 실제로 만들어졌는지, 테스트가 통과했는지, 결과가 비어 있지는 않은지, 이전 단계의 오류가 다음 단계로 전파되지는 않았는지 — 이것을 확인해야 한다.

이것이 없으면 하네스가 아니라 "그럴듯한 에이전트 설정집"이다.

03오케스트레이션과 하네스는 다르다

요즘 일부 자료들은 하네스를 너무 쉽게 말한다. 에이전트 몇 개 만들고, 역할을 나누고, 스킬을 붙이고, 오케스트레이터가 순서대로 실행한다고 해서 곧바로 하네스가 되는 것은 아니다.

그것은 에이전트 오케스트레이션이다. 그 자체로 충분히 가치 있는 개념이지만, 거기에 "하네스"라는 이름을 붙이는 순간 초점이 흐려진다.

하네스의 핵심은 "누가 무슨 역할을 맡느냐"가 아니다. 핵심은 "AI의 판단이 실제 실행 환경과 어떻게 안전하게 연결되는가"다.

그래서 하네스인지 아닌지는 다음 질문들로 판별된다.

AI가 파일을 읽는가?
AI가 필요한 도구를 선택하는가?
도구 호출의 입력과 출력이 기록되는가?
중간 산출물이 남는가?
검증 결과가 다음 판단에 반영되는가?
실패했을 때 멈추는가, 되돌리는가, 다시 시도하는가?
이 모든 과정이 재현 가능한 로그로 남는가?

이 질문에 답하지 못한다면, 그것은 하네스라고 부르기 어렵다.

04하네스는 이름이 아니라 흔적이다

이제 우리는 하네스 개념의 홍수에서 벗어날 필요가 있다. 새로운 용어를 더 많이 만드는 것이 중요한 게 아니다.

기존의 프롬프트, 플러그인, 스킬, 에이전트, 워크플로우, 자동화 스크립트를 전부 하네스라고 부르기 시작하면, 정작 하네스가 필요한 이유 자체가 사라진다. 모든 것이 하네스가 되는 순간, 하네스라는 말은 아무 의미도 갖지 못한다.

하네스는 이름이 아니라 구조다.
하네스는 멋진 다이어그램이 아니라 실행 흔적이다.
하네스는 AI가 "할 수 있다"고 말하는 것이 아니라, 실제로 "했다"는 기록이다.

좋은 하네스는 다음을 남긴다.

이런 것들이 있어야 AI 작업은 말에서 실행으로 넘어간다.

05내가 말하는 하네스 아키텍처

그래서 내가 말하는 하네스 아키텍처는 에이전트 역할표가 아니다. 프롬프트 모음집도, 스킬 폴더 구조도 아니다.

내가 말하는 하네스 아키텍처는 LLM과 실제 작업 환경 사이에 놓이는 실행 통제층이다.

이 구분이 무너지면 모든 것이 하네스가 되고, 모든 것이 하네스가 되면 하네스는 사라진다.

정리하며필요한 것은 유행어가 아니라 작동하는 구조다

이제 필요한 것은 "하네스"라는 유행어가 아니다. 필요한 것은 작동하는 구조다.

말하는 AI에서 실행하는 AI로 넘어가려면, 에이전트 이름을 늘리는 것이 아니라 실행 · 검증 · 반복 · 기록의 구조를 만들어야 한다. 그게 진짜 하네스다.

마지막으로, 오해를 막기 위해 한 가지만 덧붙인다. grep, bash, cron이 반드시 그 이름 그대로 들어가야 하는 것은 아니다. 하지만 검색, 명령 실행, 반복, 예약·트리거, 검증, 로그에 해당하는 기능이 없다면, 그것은 하네스라기보다 에이전트 오케스트레이션 또는 스킬 조합에 가깝다.

하네스는 이름이 아니라 구조다. 멋진 다이어그램이 아니라 실행 흔적이다. 그리고 "할 수 있다"가 아니라 "했다"는 기록이다.