neozest : neo+zest

최근 개인적으로 제안해서 시작된 일이 있다.

하네스 엔지니어링이라는 말이 나온지 아직 채 1년도 안되었다. 우리나라에서도 하네스 관련 책도 많이 출간되었는데, 어쩌다 보니 저자들이 아는 분들이었다. 더 재미있는 것은 세 분이 서로 다른 출판사에서 책을 펴냈다는 점.

책이란 저자의 관점이 적용된 정제된 콘텐츠다. 이 세 분의 관점을 기준으로 서로 생각하는 같은 점과 다른 점을 함께 이야기 나눌 수 있으면 독자 입장에서는 참 좋겠다 싶어서 출판사 분들과 커피를 마시다가 이 세 분을 한 곳으로 모은 북토크 이벤트 아이디어를 제안드렸다. 그래서 추진력있는 모 부장님의 주도로 지난 9월 5일 개최하기로 결정하고, 재미있는 이야기를 기대했으나 얼마전에 아예 이벤트가 취소되었다. ㅠㅠ

여기서 다시 한번 하네스나 AI 시대에 마주하는 인간의 역할을 생각해 보게 되었다.

세 저자들은 명실상부한 전문가이니 어떻게 보면 이 주제에 맞는 에이전트라 생각이 된다. 자율성을 가지고 있고, 아는 것(지식)도 많고, 언어 처리도 잘한다. 독자와 커뮤니케이션도 잘하고, 외부 환경과의 상호작용도 활발하다. 우리가 AI 에이전트에게 바라는 모든 것을 갖춘 존재인 셈이다. 물론 AI가 가지는 임의성은 없다.(아니다. 인간인 이상 감정에 의한 임의성이란 없다고 말할 수는 없겠다.)

그런데 이 세 분을 모시는 행사가 왜 엎어졌을까?

의외로 답은 단순하다고 생각한다. 세 곳의 출판사에서 전폭 지원을 했지만, 아무도 리더가 되지 않았다. 추진력 부장님 또한 행사를 출판사가 적극 지원하지만, 행사 내용은 저자 세 분이 정해서 이야기 나누는 것으로 인식했다. 그러다 보니 이른바 목표가 모호해지고, 그에 따라 정렬 문제가 발생한 것이다. 참여 플레이어는 목표에 공감이 안된 상태에서 뭔가 일/작업이 할당된 셈이다.

조금 다르게 표현하면, 정렬이 안된 이유는 리더, 그 중에서도 오케스트레이터, 조율자가 없었다는 점이다.

리더로 부터 목표를 부여받고, 각 에이전트가 최상의 성능을 낼 수 있게 이리저리 의견을 나누게 하고, 충돌이나 미비점을 조율해 주는 존재.

이렇게 보면 결국 AI로 팀을 이룬다는 개념에서 하네스 구조를 짜다보면 리더(인간) - 조율자 - 각 에이전트 구조를 많이 보게 되는데, 너무 에이전트의 자율성만 의존하다가 망한 케이스라 생각했다.

한편으로 AI 시대에 인간의 역할이 어떤 것이어야 하는지를 다시 생각하게 되는 계기가 된 것 같다.

개인적으로는 반대의 경우도 있다. 난 대학생 시절 학생운동에 적극적으로 참여했는데, 내가 속한 그룹에서는 네트워크 학생회론을 제시했었다. 대략 이야기하자면 총학생회가 코디네이터고, 각 단대/학과 학생회가 네트워크 엣지가 되어, 이슈가 생기면 연대와 교류를 통해 작은 존재들의 강결합으로 문제를 해결하는 개념으로 이해한다. 그런데 총학생회장 선거에서 당선된 우리는 정작 아무것도 할 수 없었다. 각 단대 학생회들이 다른 계열에서 당선되면서 에이전트가 전혀 될 수 없다. 그럴 경우 중앙은 쓸모없는 관제탑이 되고 만다. 손발이 없이 총학 헤드만 존재하니, 역량에 비해 업적이 크기 않았다. (업적이 크지 않았다고 생각하는게 아니라 가진 역량, Capability가 발휘안되었다는 말이다.)

적다보니 이 경우도 정렬의 문제이고, 코디네이터의 문제라는 생각이 든다.

결국 이 글의 결론은 하나로 모아지는 것 같다.

리더는 조직이 목표와 일치되도록 정렬시켜야 하고, 일을 진행시키면서 발생하는 갈등과 이벤트들의 코디네이터여야 한다는 것. 이것을 AI 시대에 활용한다면 임의성을 가질 수 밖에 없는 에이전트가 정해진 틀 속에서 자율성을 최대한 발휘하여 목표를 달성할 수 있는 틀을 제공해야 한다는 점을 시사하고, 이 틀이 하네스가 아닐까 생각해 봤다. 

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

한빛미디어에서 운영중인 리뷰어 프로그램을 통해 읽게된 책이다. 평소 AI를 업무에 활용하고 있고, 이와 관련된 코드를 직접 작성해서 사용하기도 한다. 사용하면서 큰 불만은 없었지만, 한편으로는 '프롬프트 엔지니어링', '컨텍스트 엔지니어링' 같은 용어들이 계속 등장하는 것이 마음에 걸렸다. 본질적으로 무엇이 다른 것인지, 또 하나의 마케팅용 유행어인지가 궁금했다. 그 의문에서 이 책을 펼쳤다.

이 책에서 프롬프트 엔지니어링은 AI에게 질문을 잘하는 법이고, 컨텍스트 엔지니어링은 AI에게 풍부한 자료를 쥐여주는 법이라 설명한다. 나는 컨텍스트 엔지니어링이란 특별한 기술이라기 보다는 AI를 이용하여 원하는 결과를 얻어내기 위한 접근 방식으로 진일보한 것으로 이해하게 되었다. 이전에는 컨텍스트를 정보를 검색하기 위한 참고 자료처럼 생각했는데, 책을 읽은 이후에는 검색, 메모리, 도구 호출, 상태 관리 등 LLM 모델이 활용할 수 있는 맥락 전체를 기술적인 이해를 바탕으로 설계하는 접근 방식으로 바라보게 되었다.

이 관점에서 보면  컨텍스트 엔지니어링은 나의 업무 데이터를 완벽히 이해하는 전문가 동료, 즉 에이전트를 만들기 위한 구조로 이어진다. 에이전트가 단발성 응답을 넘어 자율적으로 동작하려면 지속적으로 상태를 유지하고, 외부 데이터를 검색하고, 필요하면 도구도 호출하고, 그 결과를 응축해서 다시 정리하는 흐름이 필요하다. 책은 AI를 단순한 LLM 호출, 즉 상태없는 함수로 사용할 것이 아니라 상태를 가진 객체를 사용하는 것으로 진화시켜야 한다고 이야기한다. 

최근 나오는 LLM 모델들의 컨텍스트 윈도우가 함께 확장되었지만, 단순히 많은 정보를 넣는다고 해서 결과가 좋아지지는 않는다.  책에서는 컨텍스트 윈도우가 여전히 한정된 자원임을 분명히 한다. 불필요한 정보가 섞이면 오히려 판단이 흐려지면서 비용과 응답 지연도 발생한다. 결국 중요한 것은 양적 확장이 아니라 질을 높이는 설계다. 결국 컨텍스트 엔지니어링은 정보를 쥐여주는 것이 아니라 적절한 정보를 선택하고 이를 압축하여 알맹이만 전달하는 기술이어야 한다는 생각이 들었다.

이 책은 크게  4부로 구성된다.

1부: 컨텍스트의 개념과 컨텍스트 엔지니어링의 핵심 요소

2부: 기본 에이전트 구현

3부: 더 발전된 에이전트의 구조와 설계

4부: 에이전트 디버깅 및 평가, 지속적인 개선방법

2부와 3부에서는 LangChain을 기반으로 실제 에이전트를 파이썬으로 구현한다. 코드 자체는 읽기 수월한 편이다. LangChain 프레임워크가 워낙 워크 플로와 객체를 잘 추상화해두었기 때문에 책 내용을 코드로 이해하는데 어렵지 않다.다만 혹시나 LangChain이 익숙하지 않다면 부록B를 먼저 읽고 본 내용을 보는 것이 이해에 도움이 될 것이다.

특히 재미있게 읽은 부분은 9장에서 설명하는 컨텍스트 합성기이다. 어떤 맥락을 어떻게 조합하여 모델에 전달하는 구조를 만들 것인지를 다룬다. 이 부분을 읽으면서 최근 등장한 여러 에이전트간 상호 작용 개념(A2A 등)이 왜 필요해졌는지 자연스럽게 연결되어 이해되었다.

디버깅을 다룬 4부의 내용도 실무적으로 유용하다. 에이전트가 오작동할 때 막연히 LLM의 문제라고 보기보다는 판단(LLM)의 문제인지, 감지(검색/RAG)의 문제인지, 기억(memory)의 문제인지를 구분하여 접근한다. 이 프레임이 현업에서도 도움이 될 것 같다. 다만 책이 컨텍스트 엔지니어링을 다루는 책이므로 LangSmith 도구와 관련 컬럼만 소개할 뿐 자세히 다루지는 않는다. 이 부분은 따로 살펴봐야겠다.

이 책은 에이전트를 처음 만들어 보려는 개발자 뿐만 아니라 이미 구축된 RAG 시스템이나 내부 업무용 AI 도구를 개발한 사람들에게 도움이 있다. 단순 구현을 넘어 어떤 식으로 개선할 것인지를 다루고 있다. 개발업무에 적용하는 에어전트, CRM/CS업무에 활용할 수 있는 에이전트, 학습을 돕거나 학습하는 에이전트(법률/의료/교육/창작)를 만들고 이를 개선시키는 과정 속에서 저자가 고민해 온 에이전트의 설계 구조와 개선 방향을 엿볼 수 있었다. 나도 지금 만들고 있는 에이전트가 하나 있었는데, 여기에 책에서 언급된 고민들을 적용해 볼 생각이다.