하네스 엔지니어링에 대해서 쉽게 설명해본 글 (루프엔지니어링에 대한 오해)
주말마다 잉크버드(Encbird) 를 만들고 있는 1인 개발자입니다.
SaaS 게시판에도 서비스 소개 글을 하나 올렸는데 너무 AI 관련된 이야기를 깊이 올리기에는 SaaS 에 관련된 내용과 어긋나는거 같아서, 기술 이야기는 여기다 올려봅니다.
요새 루프 엔지니어링이라는 이야기가 많은데, 하네스 엔지니어링이 루프 엔지니어링의 개념을 다 포함하고 있다고 생각합니다.
에이전트 = 컨텍스트 + 모델(LLM) + 도구 (Tool, MCP, Skill) 인 어플리케이션이고 이건 트랜스포머 기반의 모든 에이전트는 다 똑같다고 보시면 됩니다.
그리고 모든 모델은 블랙박스이기 때문에, 에이전트 입장에서 동적으로 건드릴 수 있는건 컨텍스트 와 도구 뿐입니다.
앤트로픽, openai, google 등은 블랙박스의 동작을 직접 제어할 수 있는 유일한 회사들이기 때문에, 도구를 만들때 다른 회사들은 가질 수 없는 유리한 이점이 있습니다.
하네스 = 도구 + 피드백 루프(컨텍스트 포함) + 가드레일 로 되어 있는 워크플로우라고 보시면 됩니다.
에이전트는 프롬프트를 주면 중간 단계가 여러번 있을뿐 결국 EOS 를 보내면서 종료하게 되어 있고, 그 결과가 어떤지는 사람이 평가해서 다시 시도하든, 수정시도를 하든 해야합니다.
피드백 루프는 스스로의 작업을 평가해서 스스로 컨텍스트를 수집해서 원래 비즈니스 의도를 반영할 수 있도록, 자동화 하는것에 목표가 있습니다.
가드레일은 피드백 루프가 모델의 불확정성을 기반으로 한 평가방식을 보완하기 위해서 결정적인(deterministic) 방식들로 전환하는 기법입니다. 어렵게보이지만 결국 커스텀 린트, CLI 도구 등을 통해서 LLM 이 개입되지 않는 방식으로 작업을 평가하겠다는 이야깁니다.
따라서,
컨텍스트 엔지니어링은 어떠한 작업의 결과물이 비즈니스 의도를 잘 반영하도록 하는 것이 목표이고,
하네스 엔지니어링은 에이전트의 실행결과가 비즈니스 의도를 잘 반영하는 과정을 자동화하는 것이 목표입니다.
또한 하네스 엔지니어링은 에이전트 + 하네스 이기 때문에, 당연히 컨텍스트 엔지니어링을 상당부분 포함합니다.
그래서 하네스 엔지니어링을 처음 접했을때, 컨텍스트 엔지니어링과 헷갈린다거나 하는 경우가 많은게 이런 이유 때문이죠.
결국 루프 엔지니어링 글들은 하네스 엔지니어링의 일부를 부르고 있는 경우가 많기 때문에,
당분간 별로 신경안쓰고 하네스 엔지니어링에 붙어 있어도 충분한 거 같습니다.
글이 길어서 전문 링크는 아래에서 보실 수 있습니다.
https://haandol.github.io/2026/03/15/harness-engineering-beyond-context-engineering.html
https://haandol.github.io/2026/06/16/harness-engineering-in-practice.html
