자동화 slecs

에이전트 컨텍스트 비용과 품질 측정 루프

목차

백그라운드 에이전트를 여러 개 띄워서 자동화 파이프라인을 짜다 보면 두 가지 의문이 생기는 시점이 온다. 하나는 "에이전트가 지금 뭘 보고 있나"이고, 다른 하나는 "잘 돌아가고 있다는 걸 어떻게 측정하나"다. 이번 주에 HN과 Google Developers에서 각각 이 두 질문에 직접 닿는 소식이 나왔다.

에이전트는 자기 전사본을 읽고 있다

HN에 올라온 gist 하나가 꽤 조용히 퍼졌다. Claude Code가 백그라운드 에이전트마다 해당 에이전트의 대화 전사본을 주기적으로 모델로 보낸다는 관찰이었다. 제목이 전부지만, 이것만으로도 생각할 게 많다.

에이전트가 장기 작업을 맡았을 때 맥락을 어떻게 유지하는가, 라는 질문에 대한 하나의 답이 "누적된 전사본을 그냥 넣어준다"인 셈이다. 구현 단순성 측면에서는 합리적인 선택이다. 별도 요약 단계나 상태 저장 로직 없이도 에이전트가 "아, 나 이전에 이걸 했구나"를 알 수 있다. 상태 관리 코드를 따로 작성하지 않아도 된다는 건 봇 개발 입장에서 매력적이다.

문제는 비용이다. 전사본이 길어질수록 매 호출마다 들어가는 토큰이 늘어난다. 발행 봇이나 수집 봇처럼 한 번 실행하고 끝나는 구조면 상관없지만, 하루 종일 돌아가는 감시 에이전트나 반복 배치 작업이라면 이야기가 다르다. 짧은 작업 단위로 에이전트를 잘게 쪼개는 게 맞는지, 아니면 긴 세션을 유지하면서 전사본을 컨텍스트로 계속 먹이는 게 나은지 - 이건 운영 비용과 직결된다.

지금 내가 돌리는 배치 봇 구조는 각 작업을 짧은 호출로 끊고 결과만 저장소에 남기는 방식이다. 에이전트가 자체적으로 전사본을 끌고 다니는 게 아니라, 외부 상태에 기록하고 다음 호출이 그 기록을 읽는 형태. 이 방식이 토큰 측면에서는 유리하지만 "에이전트가 흐름을 잃지 않고 장시간 작업을 이어가야 할 때"는 불편하다. 중간 상태를 얼마나 구조화해서 넘겨야 하는지 매번 직접 설계해야 한다.

Claude Code의 방식이 옳다 그르다의 문제가 아니라, 어느 쪽을 선택하든 비용과 복잡도 사이의 트레이드오프가 존재한다는 얘기다. 그리고 이 gist가 나오기 전까지 그 트레이드오프가 실제로 어떻게 구현돼 있는지 바깥에서는 잘 보이지 않았다. 직접 돌려보고 토큰 로그를 뜯어봐야 정확한 패턴을 알 수 있겠지만, 이런 관찰이 공개되는 것 자체가 에이전트 설계 결정에 실마리를 준다.

에이전트 품질 측정을 CI처럼

Google Developers 블로그에 Agents CLI evaluation 루프에 대한 글이 올라왔다. 요약만 봐도 익숙한 패턴이 많다. 에이전트 성능을 체계적으로 테스트하고 측정하는 루프를 만들어, 프롬프트 회귀를 감지하고, 모델 백엔드를 교체할 때 사이드바이사이드로 결과를 비교하고, nightly 스케줄로 자동 실행하면서 기준치 이하로 떨어지면 알림을 보내는 흐름이다.

이게 CI다. 코드 테스트에 쓰는 CI 패턴을 에이전트 품질 측정에 그대로 이식한 것.

생각해보면 당연한 수순이다. 에이전트가 하는 일이 복잡해질수록, "내가 어제 프롬프트를 조금 바꿨는데 오늘 결과가 왜 이상하지"라는 상황이 생기기 마련이다. 수동으로 로그를 보고 "음 좀 달라진 것 같은데"로 판단하는 건 하루 이틀은 가능하지만 봇이 여러 개가 되면 감당이 안 된다. 그때부터 측정 기준이 필요해진다.

지금 내가 쓰는 방식은 비교적 조야하다. 출력이 특정 형식을 지키는지 체크하는 단순 검증, 빈 응답이나 오류 응답을 카운트하는 것 정도. 품질의 내용적인 부분 - 요약이 잘 됐는지, 분류가 맞는지 - 은 사람이 눈으로 확인한다. 자동화 파이프라인에서 사람이 봐야 하는 부분이 남아있으면 그게 결국 병목이 된다.

Agents CLI가 실제로 어떻게 "잘 됐는지"를 판단하는지는 직접 써봐야 알 것 같다. 정답이 있는 작업은 정답 비교로 측정하면 되는데, 요약이나 생성처럼 정답이 모호한 작업을 어떻게 점수화하는지가 관건이다. 요약에 대해 모델이 다시 채점하는 방식을 쓴다면 그 채점 자체가 또 비용이고, 채점 기준이 흔들리면 신뢰할 수 없다. 이 루프를 어떻게 안정적으로 만드는지가 글의 핵심일 텐데 요약만으론 알 수 없어서 아쉽다.

nightly 스케줄 + 임계값 알림 조합은 이미 서버 모니터링에서 쓰는 패턴이라 붙이는 건 어렵지 않다. 평가 결과를 어딘가에 시계열로 쌓고, 기준치 아래로 내려가면 슬랙으로 때리면 된다. 모델을 바꾸거나 프롬프트를 건드릴 때 이전 기준과 비교할 수 있다면 훨씬 자신 있게 배포할 수 있다. 특히 외부 공개 서비스에 붙은 봇이라면 이 안전망 없이 변경 배포하는 게 점점 불안해진다.

측정 없이 돌아가는 에이전트는 결국 불안하다

두 소식을 같이 놓고 보면 방향이 보인다. 에이전트가 내부에서 어떻게 컨텍스트를 유지하는지(그게 전사본이든 다른 방식이든)를 이해하는 게 첫 번째고, 그 에이전트가 기대한 대로 작동하는지를 자동으로 측정하는 루프를 갖추는 게 두 번째다.

봇을 처음 만들 때는 "일단 돌아가면 됨"으로 시작하게 된다. 근데 그 봇이 3개, 5개, 10개가 되면 돌아가는 것과 잘 돌아가는 것의 차이가 눈에 안 보이기 시작한다. 그때부터 측정 인프라가 없으면 감각에만 의존하게 되고, 어느 날 "이거 언제부터 이랬지?"라는 상황을 맞는다.

아직 평가 루프를 제대로 갖추지 못한 봇들이 몇 개 있다. 이번 주 Google 글을 핑계 삼아 하나씩 붙여볼 생각이다.

참고한 글

그 외에 오늘 눈에 들어온 것들을 짧게만 적어두면, Mistral Large 4 가 오픈 웨이트로 공개됐고, Gemini 4 Carbon 도 발표됐다. 모델 공개 빈도가 이 정도면 "어떤 모델을 쓸까"보다 "어떻게 교체 비용을 낮출까"가 더 실질적인 질문이 되고 있다. Granite Switch 4.1.1 의 접근, 소프트웨어 패키지 업데이트처럼 모델을 갈아끼운다는 발상, 이 그 질문에 대한 한 가지 방향이다. 평가 루프를 갖추면 모델을 바꿀 때 얼마나 자신감이 달라지는지는 직접 해봐야 안다. 이번 주 안에 하나 건드려봐야겠다.

이어보기

댓글 0

첫 댓글 달아줘.