요즘 AI 에이전트 이야기를 하면 대부분 모델 이름부터 꺼냅니다.
Claude가 낫다.GPT가 낫다.Gemini가 빨라졌다.Codex가 코드를 더 잘 짠다.
그런데 Addy Osmani의 글 Agent Harness Engineering은 질문을 바꿉니다.
“어떤 모델이 더 똑똑한가?”가 아니라,“그 모델이 일할 수 있는 구조를 우리가 제대로 만들어줬는가?”
이게 핵심입니다.
Addy는 코딩 에이전트를 단순한 LLM이 아니라 Model + Harness로 봐야 한다고 말합니다. 하네스는 시스템 프롬프트, 도구, 컨텍스트 정책, 훅, 샌드박스, 서브에이전트, 피드백 루프, 복구 경로까지 포함하는 실행 구조입니다.
1. 좋은 모델보다 중요한 것
가장 중요한 문장은 이겁니다.
“훌륭한 하네스를 가진 괜찮은 모델은, 나쁜 하네스를 가진 훌륭한 모델을 이긴다.”
이 말은 꽤 현실적입니다.
우리가 AI에게 일을 시켜보면 이런 일이 반복됩니다.
테스트를 안 돌리고 완료했다고 합니다.기존 컨벤션을 무시합니다.위험한 명령을 실행하려고 합니다.긴 작업을 하다가 중간 목표를 잃습니다.코드를 고쳤는데 문서나 타입 체크는 놓칩니다.
대부분은 “모델이 아직 부족하다”고 넘깁니다.그런데 하네스 엔지니어링 관점에서는 다르게 봅니다.
그건 모델 문제가 아니라, 실행 구조의 문제일 수 있습니다.
Addy는 에이전트가 실수할 때마다 그 실수를 다시 반복하지 않도록 구조를 고치는 태도를 하네스 엔지니어링으로 설명합니다. 예를 들어 규칙을 몰랐다면 AGENTS.md에 넣고, 위험한 명령을 실행했다면 훅으로 막고, 긴 작업에서 길을 잃는다면 planner와 executor를 나누는 식입니다.
2. 하네스는 AI의 ‘작업장’입니다
모델은 머리입니다.하지만 머리만 있다고 일이 끝나지 않습니다.
작업 공간이 있어야 합니다.도구가 있어야 합니다.기록이 남아야 합니다.검증 루프가 있어야 합니다.잘못된 행동을 막는 안전장치가 있어야 합니다.
하네스는 이 모든 것을 포함합니다.
CLAUDE.md, AGENTS.md, skill 파일, MCP 서버, 파일시스템, Git, Bash, 샌드박스, 로그, 비용/지연시간 관측, 서브에이전트 라우팅까지 전부 하네스의 일부입니다. Addy는 Claude Code, Cursor, Codex, Aider, Cline 같은 도구들도 결국 각자의 하네스라고 설명합니다. 같은 모델을 써도 결과가 달라지는 이유가 여기에 있습니다.
3. 실무자는 여기서 배워야 합니다
이 글이 중요한 이유는 단순히 “AI를 더 잘 쓰자”가 아니기 때문입니다.
핵심은 이것입니다.
반복되는 실수를 프롬프트로 부탁하지 말고, 시스템으로 막아야 합니다.
“테스트 꼭 돌려줘”라고 말하는 것은 약합니다.테스트가 실패하면 다음 단계로 못 가게 만드는 것이 강합니다.
“main 브랜치에 직접 push 하지 마”라고 말하는 것은 약합니다.훅으로 차단하는 것이 강합니다.
“위험한 명령은 조심해”라고 말하는 것은 약합니다.rm -rf, git push --force, DROP TABLE 같은 명령을 실행 전에 막는 것이 강합니다.
Addy는 훅을 “말로 지시하는 것”과 “시스템이 강제하는 것”을 가르는 계층으로 설명합니다. 훅은 도구 호출 전, 파일 수정 후, 커밋 전, 세션 시작 시점 등에 실행되며 lint, typecheck, test, 위험 명령 차단, PR 승인 요청 같은 역할을 맡을 수 있습니다.
4. 좋은 AGENTS.md는 길지 않습니다
여기서 많은 팀이 실수합니다.
AI가 실수할 때마다 규칙을 계속 추가합니다.그러다 어느 순간 AGENTS.md나 CLAUDE.md가 장문의 운영 매뉴얼이 됩니다.
하지만 긴 지침은 좋은 지침이 아닙니다.
Addy는 좋은 규칙 파일은 짧아야 하고, 모든 줄은 실제 실패 사례나 강한 외부 제약에서 나와야 한다고 말합니다. HumanLayer 사례에서는 60줄 이하를 언급합니다. 핵심은 “브레인스토밍한 규칙”이 아니라 “실패를 통해 얻은 규칙”만 남기는 것입니다.
이건 DevOps와 똑같습니다.
운영 체크리스트도 처음부터 완벽하지 않습니다.장애가 나고, 재발 방지책이 생기고, 그게 자동화되고, 파이프라인에 들어갑니다.
AI 에이전트도 마찬가지입니다.
실패 → 규칙 → 훅 → 검증 루프.이 구조가 쌓여야 팀의 AI 활용 수준이 올라갑니다.
5. 앞으로의 경쟁력은 ‘모델 선택’이 아니라 ‘하네스 설계’입니다
지금은 많은 사람이 더 좋은 모델을 기다립니다.
다음 Claude.다음 GPT.다음 Gemini.
물론 모델은 계속 좋아질 겁니다.하지만 Addy의 관점에서 중요한 것은, 모델이 좋아질수록 하네스가 사라지는 게 아니라 하네스의 위치가 바뀐다는 점입니다. 모델이 어떤 일을 스스로 잘하게 되면 기존 보조 장치는 제거해야 하고, 더 어려운 작업이 가능해지면 새로운 실패 모드에 맞는 새로운 구조가 필요해집니다.
결국 하네스는 한 번 만들어두는 설정 파일이 아닙니다.계속 조정되는 운영 시스템입니다.
결론
AI 에이전트를 잘 쓰는 팀은 프롬프트를 많이 가진 팀이 아닙니다.
실패를 기록하는 팀입니다.반복 실수를 규칙으로 바꾸는 팀입니다.중요한 규칙은 훅과 파이프라인으로 강제하는 팀입니다.검증 결과를 다시 에이전트 루프에 넣는 팀입니다.
이제 질문은 “어떤 모델을 쓸까?”에서 멈추면 안 됩니다.
우리 코드베이스에는 어떤 실패가 반복되는가.우리 팀의 컨벤션은 어디에 기록되어 있는가.AI가 하면 안 되는 행동은 시스템적으로 막혀 있는가.작업 완료 기준은 명확한가.테스트, 타입 체크, 보안 검사는 루프 안에 들어와 있는가.
여기까지 설계한 팀과 그렇지 않은 팀은 같은 모델을 써도 완전히 다른 결과를 냅니다.
AI 에이전트 시대의 진짜 격차는 모델 구독료에서 생기지 않습니다.
모델이 일할 수 있는 작업장을 누가 더 잘 설계했는가.여기서 갈립니다.
[원문]
의견을 남겨주세요