코딩 에이전트 128개 병렬 운영법: 검증 가능한 과제, 심사 에이전트, 컨텍스트 압축

핵심 메시지

• 베이스텐 연구진은 하나의 연구 주제에 64~128개 에이전트를 붙여 돌린다. 사람이 직접 대화하는 것은 소수이고, 나머지는 대표 에이전트가 작업을 나눠 맡기는 구조다.
• 에이전트가 스스로 '할 만큼 했다'고 멈추는 자기기만을 막으려면, 완료 여부를 판정하는 별도의 심사 에이전트를 두고 계속 되돌려보내는 훅이 필요하다.
• 검증이 명확한 과제는 에이전트가 밤새 성능을 올리며 스스로 오르막을 탄다. 반대로 좋은 평가셋을 설계하는 일처럼 '좋음'을 규정하기 어려운 과제에서는 사람의 취향이 병목으로 남는다.
• 구현과 리뷰에 서로 다른 모델 계열을 쓰면 오류가 상쇄된다. 프런티어 모델들은 한계 지점에서 서로 상관없는 실수를 하기 때문에, 참가자는 이를 '모델의 랜덤 포레스트'라고 표현했다.
• 컨텍스트 창을 늘리는 것보다 KV 캐시 압축이 더 중요한 과제로 떠올랐다. 모델이 남은 토큰을 실존적 제약처럼 다루며 코드를 끝까지 읽지 않고 추측부터 시도하는 습관도 함께 지적됐다.

쉽게 이해하기

커서의 클라우드 에이전트 팀 엔지니어가 베이스텐의 두 연구자와 나눈 대담은 '에이전트를 몇 개까지 동시에 돌릴 수 있는가'라는 질문에서 출발한다. 이들은 KV 캐시 압축으로 컨텍스트 창을 늘리는 연구를 하면서 상시 64~128개의 에이전트를 운용한다고 말했다. 실제로 대화하는 것은 몇 개뿐이고, 주 에이전트에게 나머지에게 일을 시키라고 지시하는 방식이다. 각 에이전트에 힐베르트, 가우스처럼 수학자 이름을 붙여두고 '오늘 푸앵카레는 어떻게 지내냐'고 묻는다는 대목은 농담처럼 들리지만, 여러 작업 흐름을 사람이 기억 가능한 단위로 쪼개는 실용적 장치이기도 하다.

규모가 커지면 실패 양상도 달라진다. 오래 돌리다 보면 에이전트가 그냥 일을 멈춰버리기 때문에, 확인할 항목을 나열한 알림 메시지를 주기적으로 주입하는 루프를 따로 만들어 둔다. 더 중요한 것은 완료 판정이다. 스스로 판단하게 두면 '최선을 다했으니 이만 멈추겠다'는 식으로 자기기만에 빠지므로, 별도의 심사 에이전트가 계속 '아직 안 끝났다'고 되돌려 보내야 한다. 그래서 시작 단계의 프롬프트와 '완료를 어떻게 검증할 것인가'를 정의하는 데 공을 들이면, 작업이 며칠씩 이어져도 궤도를 유지한다는 것이다.

그럼에도 사람이 남는 자리는 뚜렷하다. 참가자들은 지난 몇 년이 추상화 사다리를 한 칸씩 올라온 과정이었다고 정리한다. 처음에는 아주 좁고 잘 정의된 과제만 맡길 수 있었고, 지금은 여러 하위 과제를 대표 에이전트가 조율하게 할 수 있다. 하지만 어떤 문제를 풀 것인지 고르는 일, 그리고 검증이 어려운 영역에서 탐색 공간을 좁혀주는 취향의 주입은 여전히 사람 몫이다. 한 참가자는 '모델은 코드를 대신 써줄 수 있지만 코드를 대신 읽어주지는 못한다'며, 결국 무슨 일이 벌어지는지는 직접 이해해야 한다고 말했다.

모델 활용법에 대한 관찰도 구체적이다. 구현과 리뷰를 서로 다른 모델 계열에 맡기면 오류가 평균화된다는 것이 대표적이다. 한쪽 계열은 지시가 모호할 때 빈칸을 스스로 채우는 성향이 강해 사람 동료처럼 느껴지고, 다른 쪽은 시키는 대로만 하는 도구처럼 느껴진다는 비교도 나왔다. 커서 내부에서는 이런 교차 검토를 '서모뉴클리어 리뷰'라는 이름의 사내 스킬로 정착시켰고, 반복해서 쓰는 프롬프트와 워크플로를 스킬로 묶어 사내에 공유하는 문화를 만들고 있다고 소개했다.

미래 전망에서 두 팀의 관심사는 갈렸다. 베이스텐 측은 오픈소스 모델의 기본 성능이 임계점을 넘으면서, 이제 보조 에이전트뿐 아니라 제품의 핵심을 담당하는 주 에이전트까지 특화 학습할 수 있게 됐다고 봤다. 범용 모델에 배어 있는 '바닐라 아이스크림 같은 평균적 행동'은 특정 제품 환경에서는 최적이 아니라는 논리다. 커서 측은 반대로 모델을 둘러싼 제품 표면, 즉 코드 리뷰와 QA, 모니터링, 배포 파이프라인처럼 코드가 프로덕션에 닿기까지의 과정을 매끄럽게 만드는 데 힘을 쏟고 있다고 답했다. 한 사람은 오늘의 모델 성능이 그대로 멈춘다 해도 우리는 아직 그 가치의 5% 정도만 쓰고 있을 것이라고 말했다.

주요 인사이트

• 에이전트를 여럿 돌리는 일의 병목은 모델 성능이 아니라 조율이다. 서로에게 메시지를 넣어주는 간단한 스크립트를 붙이자 에이전트들이 서로의 작업에 반응하기 시작했다는 일화가 이를 잘 보여준다.
• 다른 사람의 에이전트와 내 에이전트가 대화하는 상황은 곧바로 보안 문제가 된다. 실제로 한쪽이 상대 에이전트에게 파일 삭제를 유도하는 프롬프트 인젝션을 시도했지만 거절당했고, 메시지 자체를 신뢰하지 않는 반응도 나왔다.
• 모델은 토큰을 아끼도록 학습된 탓에 코드를 끝까지 읽는 대신 가설을 하나씩 던져보는 디버깅을 선호한다. 50만 토큰을 먼저 읽는 편이 결과적으로 더 빠른 경우가 많다는 지적은 현재 학습 방식의 빈틈을 드러낸다.
• 명세를 20%만 더 정교하게 써도 결과가 크게 달라진다는 관찰은, 계획 모드에서 마크다운 문서로 합의를 만든 뒤 실행에 들어가는 습관과 직접 이어진다.
• '프롬프트 엔지니어'라는 직함이 조롱받던 시기를 떠올리며, 앞으로는 사람 엔지니어가 아니라 남의 에이전트 팀까지 관리하는 '에이전트 매니저' 같은 직무가 생길 것이라는 전망도 나왔다.

자주 묻는 질문

관련 AI 소식