채팅방에 에이전트를 초대하고 알게 된 것

에이전트에게 채팅 기능을 붙이고 나서 생각하지도 못한 문제가 풀렸습니다.

원래는 에이전트끼리 하는 대화를 기록으로 남겼으면 좋겠다는 생각에서 시작했습니다. 사실 이전에도 에이전트들끼리 서로 통신할 수 있는 기능은 이미 갖춰 놓은 상태였습니다. 그래서 에이전트들끼리 서로 협업을 하는 식으로는 이미 운영을 하고 있었습니다. 다만 그 대화 내역을 제가 보기는 어려웠죠.

그런데 챗 기능을 붙이게 되면서 제가 텔레그램이나 혹은 원격 접속 등을 통해서 나눠서 컨트롤했던 것들이 채팅 기능을 중심으로 통합되게 되었습니다. 그러고 나니까 새로운 문제가 풀렸습니다.

컨텍스트는 그 자체로 비용입니다

제가 에이전트들을 여러 개 굴리게 되면서 가장 문제가 되었던 부분은 바로 컨텍스트를 관리하는 부분이었습니다. 이 컨텍스트를 관리하는 것은 그 자체로 비용이니까요.

에이전트로 개발을 하거나 어떤 일을 하다 보면, 어느 날 갑자기 토큰 사용량이 확 늘어나는 경험을 한두 번씩 해보셨을 겁니다. 그것이 바로 이 컨텍스트 캐시 문제입니다.

모델을 사용한 지 일정 시간이 지나게 되면, 모델을 서빙하는 서버가 들고 있던 컨텍스트를 내려놓게 됩니다. 서버에서 메모리는 굉장히 한정된 자원이기 때문에 오랫동안 사용되지 않은 컨텍스트는 메모리에서 내려놓는 겁니다. 클로드의 경우에는 이게 5분, 길게 잡아도 1시간 정도입니다. 그러다 보니 긴 공백 뒤에 에이전트와 이어서 작업을 하려고 하면, 캐시에서 내려왔던 컨텍스트가 다시 올라가면서 그만큼 토큰을 사용하게 됩니다.

구독으로 Claude Code를 쓰면 이 시간이 1시간입니다. API 가격으로 치면, 캐시에서 읽을 때는 기본 입력 가격의 0.1배이고 캐시에 새로 올릴 때는 2배입니다. 1시간을 넘겨 돌아오면 맥락 전체를 새로 올려야 하니, 같은 맥락인데도 스무 배 가까이 차이가 나는 거죠.

핸드오프 문서가 채팅창으로 들어왔습니다

이 캐시 때문에 예전에도 적극적으로 클리어(대화를 비우고 새로 시작하는 것)를 하거나 재시작을 하는 전략을 쓰고 있었습니다. 그런데 긴 작업을 하다 보면 클리어하기에는 맥락이 너무 아쉬운 경우가 있죠. 그래서 핸드오프 문서, 그러니까 인수인계서 같은 걸 작성하고, 그 문서를 다음 세션에 넘기는 방식으로 일을 진행해왔었습니다.

그런데 채팅에 이력을 남겨 두니까 이 문제가 풀렸습니다. 채팅창에 핸드오프 문서를 자연스럽게 남기게 한 겁니다. 일을 시작할 때와 끝낼 때, 한 일과 할 일을 정리해서 적어 두는 거죠. 그러면 그 자체가 일종의 핸드오프 문서가 되더라고요.

그래서 일을 시켜 놓고 공백이 너무 길어졌다면, 저는 과감하게 에이전트를 클리어하고 해당 메시지를 가리키는 참조번호를 하나 달아서 이어서 진행합니다.

실제로 제 클로드 코드 기록을 뒤져 보니, 맥락이 10만 토큰 넘게 쌓인 대화에서 한 시간 넘게 쉬었다가 다시 말을 건 게 88번 있었습니다. 제일 컸던 건 78분 쉬고 돌아와서 던진 한 마디였는데, 그 한 마디에 65만 토큰이 캐시에 다시 올라갔습니다. 요즘 모델의 컨텍스트 윈도우가 100만 토큰이니까, 창의 3분의 2를 한 번에 다시 채운 셈이죠. 바로 앞 턴까지는 같은 맥락을 캐시에서 싸게 읽고 있었는데도요. 구독 요금제에서는 이게 돈이 아니라 사용 한도에서 나가는데, 말 한 마디에 한도가 뭉텅 깎이는 겁니다.

그리고 이 한 시간이 실제로 경계선이더라고요. 잠깐 쉬었다가 한 시간 안에 돌아와서 말을 건 577번 중에 캐시가 통째로 날아간 건 4번뿐이었는데, 한 시간을 넘긴 88번 중에서는 85번이 통째로 날아갔습니다.

반면 클리어하고 참조를 하나 달면 이야기가 달라집니다. 새 세션은 3만 5천 토큰 정도에서 시작합니다. 거기에 정리해 둔 메시지 하나와 필요한 스레드만 더 읽으면 되니까, 65만 토큰을 다시 올리는 대신 몇만 토큰으로 같은 자리에 돌아오는 거죠.

이 핸드오프 문서가 자동으로 남게 해 두면, 캐시를 붙잡아 두려고 애쓸 필요가 없어지더라고요. 에이전트가 이미 작업하고 정리해 둔 것을 메시지로 한 번 더 남기는 것뿐이라, 토큰 사용량도 크지 않습니다.

왜 다들 채팅방 모양일까

최근 들어 에이전트와 협업하는 플랫폼이 쏟아져 나오고 있는데, 이 플랫폼들이 왜 슬랙이나 디스코드 같은 채팅방 형태일까 하는 생각을 해본 적이 있습니다. 저도 비슷한 형태를 구현해 보고 나서야 이유를 알게 됐습니다.

제가 앞서서도 에이전트와 일할 때 에이전트를 사람이라고 생각하고 함께 일하는 방식을 고민해 보면 좋다고 말씀드렸는데, 우리는 협업할 때 보통 메신저를 많이 쓰잖아요. 그리고 예전에 무슨 말을 했는지, 메신저로 보냈던 파일이 뭐였는지 찾으려고 메신저 안을 뒤져 보는 일도 많습니다.

생각해 보니 그게 결국 현재 시점과 분리된 과거의 컨텍스트를 채팅방 속에서 찾는 일이더라고요. 그러니 채팅을 에이전트가 쓸 수 있는 도구로 물려주면, 우리가 사람과 일하듯이 에이전트와도 일할 수 있는 거죠. 단순히 대화하듯 일하고 싶어서 채팅창을 붙이는 게 아니었다는 겁니다.

또 이런 맥락이 채팅방에 쌓이다 보니, 다른 에이전트가 그 맥락을 가져다 기록을 남기거나 정리하는 것도 가능합니다.

한번은 제 에이전트 빅토르가 리팩토링 PR을 올리던 스레드에, 방금 클리어한 다른 에이전트 구루를 불러 검수를 맡겼습니다. 구루에게는 처음 보는 스레드였는데도, 앞의 대화를 읽고 바로 검수 결과를 올리더라고요.

채팅이라는 도구에는 다른 모듈이나 도구를 여러 가지 붙일 수 있기 때문에, 채팅방에 들어온 에이전트들이 그 도구를 함께 쓸 수 있다는 이야기도 됩니다.

에이전트를 쓰면서 채팅방을 직접 구현해 붙인 건 정말 잘한 일이라고 생각합니다. 그 과정에서 알게 된 것들을 공유하고 싶어서 이렇게 글로 남깁니다.