한빛미디어

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

AI 시대는 눈 뜨면 도구 트렌드가 바뀌고, 신규 모델의 성능이 올라가면서 기존에 공들여 만든 도구들이 하룻밤 사이에 무의미해지기도 한다. 변화의 주기가 1~2년도 아니고, 불과 몇 달, 혹은 몇 주 사이에도 판도가 뒤집히는 격변의 시대다. 이런 상황에서 결국 AI를 어떻게 실무에 안정적으로 안착시킬 것일지에 대해 본질적인 고민을 하게 되는데, 이 책을 통해 단순히 모델에 국한된 것이 아닌 구조를 어떻게 가져갈 것인가에 대한 조언을 얻게 된다.

책의 전반부에서는 단일 에이전트가 가진 구조적 한계를 먼저 짚어낸다. 자신의 실수를 잘 잡지 못하는 구조라고 할 수 있는데, 한 줄로 요약하면 ‘혼자 쓴 PR을 혼자 머지하는 구조’라고 볼 수 있겠다. 책에서 언급한 리플릿(Replit)의 데이터 삭제 사례처럼 혼자 일하는 AI는 자신의 실수를 스스로 잡아내기 어렵다. 계획-작성-검증-수정의 단계를 하나의 컨텍스트 안에서 처리하기 때문에, 검토자가 없으니 초기에 누락이 있더라도 검증 단계에서도 동일한 누락이 발생할 수 있음을 설명하고 있다.

물론 모델의 성능이 올라갈수록 기존의 오케스트레이션 환경이 불필요해지는 경우도 생긴다. 최근의 흐름이라면 일전에 '하입(Hype)'을 받았던 오케스트레이션 환경을 그대로 가져다 쓰기보다, 본인의 프로젝트 도메인에 맞게 가볍게 커스텀해서 쓰는 것이 불필요한 오버헤드 없이 안정적인 결과를 얻기에 유리한 느낌이다. 실제로 최근에 기존에 사용하던 환경을 오버헤드가 생긴다는 이유로 떼어내는 추세이기도 하다.

이 지점이 바로 개발자에게 남겨진 새로운 아키텍처 설계 영역이고 그중 하나가 하네스 엔지니어링(Harness Engineering)이다. 결국 하네스라는 것은 모델의 가중치를 손대지 않고, 모델 외부에 권한(Permission), 도구 호출(Tools), 상태(State), 그리고 검증과 관측(Observability) 과정을 설계하여 에이전트가 안전하게 일할 수 있는 결정론적 환경을 구축하는 일이다. 최근에는 하네스를 넘어 루프 엔지니어링(Loop Engineering)이라는 개념이 새롭게 나오긴 했지만, 결국 본질적으로는 안쪽의 확률론적 LLM을 제어할 수 있도록 외부에 결정론적 경계선을 설계하는 일인 셈이다.

챕터 3에 이르러 본격적인 하네스 구성 요소의 책임 분리를 다룬다. 이 책의 핵심 골자는 ‘하네스는 누가(Agent), 어떻게(Skills), 언제-누구와(Orchestrator)라는 세 가지 요소로 나뉘며, 이들은 독립적으로 설계되고 실행 시점에만 맞물린다’라는 한 문장으로 요약된다.

책은 이러한 논리적인 책임 분리가 실질적으로 작동하기 위해 프로젝트 루트의 CLAUDE.md에 하네스 포인터를 등록하는 정적 규칙과 _workspace/라는 물리적인 공유 공간을 매개로 삼는 데이터 전달 프로토콜이 필수임을 말하고 있다. 확률론적 에이전트가 흔들리더라도 외부의 경계만큼은 결정론적인 파일 기반 전달 규약과 훅(Hooks)으로 묶어두어야 세션이 바뀌어도 맥락이 유실되거나 루프를 제어하는 것이 가능하기 때문이다.

멀티 에이전트나 하네스 구조를 직접 설계하고 굴려본 개발자라면 한 번쯤 느꼈을 수 있는데, AI를 개발 프로세스에 도입한다는 건 완전히 새로운 패러다임에서 시작하는 것이 아니라, 기존의 업무 프로세스를 AI에 접목시켜 속도를 끌어올리는 행위에 가깝다. 그렇기에 기존에 익숙한 단일 책임 원칙(SRP) 아래 관심사를 분리하고 전문 에이전트를 쪼개는 설계를 자연스럽게 하게 된다. 책에서 이런 내용을 언급하고 있어 상당히 공감되는 부분이었다.

책에서 소개하는 안티 패턴들 역시 익숙하다. 에이전트 한 명이 모든 역할을 맡거나, 스킬이 팀 전체를 지휘하거나, 혹은 리더가 팀원에게 일을 시키지 않고 직접 일을 처리하면서 생기는 리더 병목 등은 개발자라면 처음 접하는 이야기가 아니다. 꼭 개발자가 아니더라도 조직이나 팀 단위로 협업해 본 사람이라면 누구나 겪어봤을 일 못하는 팀의 전형적인 안티 패턴과 닮아 있다. 결국 AI 팀을 짜는 것도 인간의 협업 구조를 흡사하게 가져온다는 점에서 이미 겪어온 익숙한 안티 패턴들이 고스란히 나올 수밖에 없다.

최근에는 Codex를 주로 쓰기도 하고, 잠깐 사이에 트렌드가 바뀌고 명확한 표준이 없는 상황에서 지금 이 책을 학습한다는 게 큰 의미가 있을까 하는 회의감이 읽는 내내 스치기도 했다. 그럼에도 불구하고 이 책이 가지는 가치는 전체 하네스 구조의 메커니즘을 한눈에 훑어볼 수 있다는 점에 있다.

예를 들어, 전반부 실습에서 공유 작업 공간인 _workspace를 구축해 에이전트들이 대화 텍스트가 아닌 '공유 파일 시스템'을 매개로 리뷰 과정을 거치게 하는 구조를 먼저 체득하면, 중반부에 들어서 이 _workspace를 통해 에이전트들이 어떻게 컨텍스트 오버헤드 없이 협업하는지 대략적인 구조를 파악할 수 있다. 더 나아가 오케스트레이터의 SendMessage 도구를 통해 에이전트들이 수평적으로 통신을 주고받으며 어떻게 리더 병목을 넘어 병렬성을 확보하는지 인지하게 되는데, 그 지점에서 이 책이 단순한 툴 사용법에 머무는 것이 아니라 온전히 아키텍처에 대해 기술하는 꽤나 탄탄한 구성임을 알 수 있었다.

결국 기술 트렌드가 하룻밤 사이에 바뀌고 더 똑똑한 모델이 나오더라도, 개발자가 현재로서 해야 할 건 에이전트가 안전하게 일할 수 있는 환경을 구축해 두는 일인 것 같다. 고급 언어가 나왔을 때도 개발자의 역할이 메모리 관리에서 비즈니스 로직 설계로 옮겨갔듯, AI 시대라고 해서 개발자의 역할이 사라진 게 아니라 모델 바깥의 경계를 설계하는 영역으로 이동했다고 느끼고 있다. 물론 기술이 발전하고 시대가 변함에 따라 어떻게 바뀔지는 모른다. 게다가 앞서 말한 것처럼 모델의 성능이 발전하거나, 모델 내부의 작동 방식이 바뀜에 따라 기존의 환경이 무용해질지도 모른다. 하지만 전반적인 구조를 알고 AI를 활용하는 것과 그렇지 않은 것에는 분명한 차이가 있다고 생각한다. 이 책은 전반적인 구조를 개괄적으로나마 이해하도록 돕고 있기 때문에, 단순히 유행하는 툴 사용법이 아니라 앞으로 어떤 모델이 나오든 빠르게 실무에 적용할 수 있는 근육을 키워주는 책이라는 생각이 들었다.

#하네스엔지니어링 #나는리뷰어다 #한빛미디어