AI 에이전트 시대, 이제는 프롬프트보다 '하네스'가 중요하다

『하네스 엔지니어링 with 클로드 코드』를 읽고

AI를 업무에 활용하기 시작한 지도 어느덧 꽤 시간이 흘렀습니다.

처음에는 ChatGPT로 간단한 질문을 하는 수준이었지만, 지금은 Claude Code를 이용해 코드 작성과 리뷰를 하고, 문서를 정리하고, 블로그 초안까지 만드는 것이 일상이 되었습니다. 저 역시 하루 업무 대부분을 AI와 함께하고 있다고 해도 과언이 아닙니다.

하지만 사용할수록 한 가지 의문이 생겼습니다.

왜 같은 모델을 사용해도 어떤 사람은 놀라운 결과를 만들고, 어떤 사람은 기대 이하의 결과만 얻는 걸까?

처음에는 프롬프트 차이라고 생각했습니다. 더 자세하게 쓰고, 더 길게 쓰고, 역할을 부여하면 해결될 줄 알았습니다. 하지만 실제로 여러 프로젝트를 진행하면서 느낀 것은 프롬프트만으로는 분명한 한계가 있다는 점이었습니다.

그러던 중 읽게 된 책이 바로 **『하네스 엔지니어링 with 클로드 코드』**입니다.

이 책은 AI에게 무엇을 시킬 것인가보다 AI가 일할 환경을 어떻게 설계할 것인가에 집중합니다. 최근 읽었던 AI 관련 서적 가운데 가장 엔지니어링적인 관점을 담고 있었고, 개인적으로도 상당히 인상 깊게 읽은 책입니다.

---

모델보다 중요한 것은 '하네스'였다

이 책에서 가장 강하게 전달하는 메시지는 단 하나입니다.

모델이 아니라 하네스가 결과를 결정한다.

처음에는 다소 과감한 주장처럼 느껴졌습니다.

하지만 책을 읽어갈수록 저자의 의도가 무엇인지 이해하게 되었습니다.

우리는 흔히 더 좋은 결과가 나오지 않으면 GPT-4.1을 써볼까, Claude Opus를 써볼까, Gemini를 사용할까처럼 모델부터 바꾸려고 합니다.

하지만 저자는 전혀 다른 관점을 제시합니다.

같은 모델이라도

• 어떤 역할을 부여하는지
• 어떤 작업 순서로 진행하는지
• 누가 검토하는지
• 어떻게 피드백을 주고받는지

이런 '환경(Harness)' 이 결과를 훨씬 크게 좌우한다는 것입니다.

이 부분은 AI를 꾸준히 사용해 본 사람이라면 충분히 공감할 만한 내용이었습니다.

실제로 저 역시 하나의 AI에게 모든 일을 맡겼을 때보다, 역할을 나누고 서로 검토하도록 구성했을 때 훨씬 안정적인 결과를 경험한 적이 여러 번 있었기 때문입니다.

---

프롬프트 엔지니어링의 확장판이 아니다

책에서 가장 기억에 남는 부분 중 하나는 '하네스에 대한 세 가지 오해'를 설명하는 챕터였습니다.

많은 사람들이

프롬프트를 잘 쓰는 것이 곧 하네스 아닌가?

라고 생각합니다.

하지만 저자는 명확하게 선을 긋습니다.

프롬프트는 어디까지나 설득이고,

하네스는 구조적인 강제라는 것입니다.

예를 들어

"데이터베이스를 삭제하지 마라."

라고 프롬프트에 적어 두는 것과

아예 DELETE 권한 자체를 제거하는 것은 전혀 다른 문제입니다.

이 설명은 단순하지만 상당히 설득력이 있었습니다.

또한 LangChain이나 CrewAI 같은 프레임워크 역시 하네스 그 자체가 아니라, 하네스를 구현하기 위한 도구라고 설명하는 부분도 인상 깊었습니다.

도구와 설계를 명확히 구분하는 시각이 이 책의 가장 큰 특징이라고 생각합니다.

 

에이전트·스킬·오케스트레이터

책의 핵심은 세 가지 구성 요소입니다.

• 에이전트(Agent)
• 스킬(Skill)
• 오케스트레이터(Orchestrator)

처음에는 다소 낯선 개념처럼 보였지만, 읽다 보면 각각의 역할이 상당히 명확하게 구분되어 있습니다.

특히 좋았던 점은 책 전체가 역할 분리를 중심으로 구성되어 있다는 것입니다.

에이전트는 무엇을 담당하는지,

스킬은 어떤 절차를 수행하는지,

오케스트레이터는 누가 언제 무엇을 할지 조율하는지를 각각 독립적으로 설명합니다.

덕분에 단순히 Claude Code 사용법을 배우는 것이 아니라, AI 팀을 설계하는 방법을 익히는 느낌을 받을 수 있었습니다.

 

오케스트레이터 챕터가 특히 인상적이었다

개인적으로 가장 재미있게 읽은 부분은 Chapter 06 오케스트레이터였습니다.

책에서는

리더가 모든 메시지를 전달하는 구조를

'우체국'

이라고 표현합니다.

처음에는 별것 아닌 비유처럼 보였는데, 읽다 보니 정말 공감이 되었습니다.

팀원이 두 명일 때는 문제가 없습니다.

하지만 세 명, 네 명으로 늘어나면 모든 메시지가 리더를 거치게 되고 결국 병목이 발생합니다.

그래서 책에서는

TeamCreate

TaskCreate

SendMessage

를 이용해 팀원들이 직접 협업하도록 구성하는 방식을 설명합니다.

리더는 더 이상 모든 일을 처리하는 관리자가 아니라

이벤트를 받아 필요한 시점에만 개입하는 조율자가 됩니다.

이 부분은 단순히 Claude Code 이야기라기보다, 실제 소프트웨어 설계 철학과도 연결되어 있어 특히 흥미롭게 읽었습니다.

---

메타스킬이라는 발상이 흥미롭다

또 하나 기억에 남는 부분은 메타스킬(Meta Skill)입니다.

스킬이 작업을 수행하는 절차라면,

메타스킬은 스킬 자체를 만드는 스킬입니다.

처음에는 다소 추상적으로 느껴졌지만,

여섯 번째 팀을 만들면서 반복되는 작업을 자동화한다는 설명을 읽고 바로 이해할 수 있었습니다.

개인적으로도 반복되는 프로젝트를 진행하면서

비슷한 폴더,

비슷한 역할,

비슷한 프롬프트,

비슷한 규칙을 계속 만들고 있었는데,

저자는 이 반복 자체를 자동화 대상으로 바라봅니다.

'자동화를 자동화한다'는 관점이 상당히 신선했습니다.

 

---

부록이 의외의 보물이었다

보통은 부록을 가볍게 훑어보는 편인데,

이 책은 오히려 부록에서 오래 머물렀습니다.

특히

• Trigger Miss
• Cross-Reference Drift
• Verify-Generate Deadlock
• Over-Orchestration

같은 안티패턴을 정리한 부분은 실무 체크리스트로 활용해도 좋겠다는 생각이 들었습니다.

또한

MCP 사용 시 주의할 점,

도구를 너무 많이 연결했을 때 발생하는 문제,

인터페이스 설계,

에러 메시지 작성 방법까지 다루고 있어 단순한 부록 이상의 가치가 있었습니다.

AI를 조금이라도 실무에 활용하는 사람이라면 한 번쯤은 체크해 볼 내용들이 많았습니다.

---

실제 사례가 있어서 더 설득력이 있다

이 책이 좋았던 이유는 이론만 설명하지 않는다는 점입니다.

코드 리뷰 자동화,

풀스택 개발,

레거시 마이그레이션,

디버깅과 RCA까지

실제 팀 구성을 예제로 보여주고,

에이전트 정의 파일과 오케스트레이터 흐름까지 함께 설명합니다.

덕분에 개념을 읽고 끝나는 것이 아니라

'이렇게 구현하면 되는구나.'

라는 감각을 자연스럽게 얻을 수 있었습니다.

특히 코드 리뷰 팀 사례는 실제 프로젝트에 응용해 보고 싶다는 생각이 들 정도로 구체적이었습니다.

---

이런 분들에게 추천합니다

이 책은 AI 입문자를 위한 책은 아닙니다.

오히려

• Claude Code를 이미 사용하고 있는 개발자
• Cursor나 Copilot을 넘어 AI 에이전트 활용을 고민하는 개발자
• 반복 업무를 자동화하고 싶은 엔지니어
• AI 팀 구조를 설계하고 싶은 리드 개발자

에게 훨씬 잘 맞는 책입니다.

반대로 프롬프트 작성법이나 ChatGPT 사용법을 기대한다면 다소 어렵게 느껴질 수도 있습니다.

---

마무리

책을 덮고 나서 가장 오래 기억에 남은 문장은 역시 이것이었습니다.

모델이 아니라 하네스가 결과를 결정한다.

AI 모델은 앞으로도 계속 발전할 것입니다.

하지만 결국 업무의 품질을 결정하는 것은 모델 자체보다 그 모델이 어떤 환경에서, 어떤 역할을 맡고, 어떤 절차를 통해 협업하도록 설계했는가일지도 모르겠습니다.

『하네스 엔지니어링 with 클로드 코드』는 Claude Code를 잘 사용하는 방법을 알려주는 책이라기보다, AI 에이전트 시대에 일을 설계하는 방법을 이야기하는 책에 가깝습니다.

AI를 단순한 도구가 아닌 함께 일하는 동료로 활용하고 싶다면, 한 번쯤 꼭 읽어볼 만한 책이라고 생각합니다.

 

 

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."