AI 에이전트가 '한 마리'가 아니라 '떼'로 온다 — 스웜 시대의 모델 경제학

작년까지만 해도 AI 코딩 도구를 쓴다는 건 에이전트 하나와 대화창을 사이에 두고 씨름하는 일이었습니다. 그런데 요즘 개발자들의 화면을 보면 풍경이 달라졌습니다. 탭 하나에 에이전트 하나가 아니라, 동시에 8개, 20개가 각자 다른 브랜치에서 돌아가고 있는데요. 이 변화는 단순한 사용법의 차이가 아니라, AI 모델을 파는 쪽과 사는 쪽 모두의 계산기를 바꿔놓고 있습니다.

먼저 솔직하게 말씀드리면, 이 주제는 지난 30일간 커뮤니티에서 확인된 대규모 토론 데이터가 많지 않았습니다. 그래서 이 글은 최근 몇 달간 축적된 흐름과 업계 구조 변화를 짚는 쪽에 무게를 뒀습니다.

대화형에서 스웜형으로, 무엇이 달라졌나

기존 방식은 ‘페어 프로그래밍’에 가까웠습니다. 사람이 지시하고, 에이전트가 답하고, 사람이 확인하고, 다시 지시합니다. 이 구조에서 병목은 명확합니다. 사람의 검토 속도입니다.

스웜 방식은 이 병목을 우회합니다. 같은 문제에 에이전트 여러 개를 각각 다른 접근으로 붙이고, 결과가 나온 것 중에서 골라 씁니다. 실패한 시도는 그냥 버립니다. Cursor를 비롯한 도구들이 백그라운드 에이전트, 워크트리 격리, 병렬 실행을 밀어붙이는 이유가 여기에 있습니다.

핵심은 사고방식의 전환입니다. 예전에는 에이전트의 출력을 ‘고쳐 쓰는’ 대상으로 봤다면, 이제는 버릴 수 있는 후보로 봅니다. 10개를 돌려서 1개만 쓸 만하면 성공입니다. 나머지 9개의 비용은 그 1개를 얻기 위한 탐색 비용으로 계산됩니다.

경제학이 뒤집히는 지점

여기서 모델 가격표에 대한 감각이 완전히 달라집니다.

단일 에이전트 시대에는 ‘토큰당 얼마’가 곧 비용이었습니다. 한 번 질문하고 한 번 답받는 구조에서는 계산이 단순합니다. 그런데 스웜에서는 실제로 지불하는 값이 성공한 결과물 하나당 비용으로 바뀝니다. 20번 시도해서 1번 성공했다면, 그 코드 한 조각의 원가는 토큰 단가의 20배입니다.

이 계산식은 재미있는 결론을 만들어냅니다. 비싸지만 성공률이 높은 모델과, 싸지만 성공률이 낮은 모델 중 무엇이 유리한지가 상황에 따라 뒤집힙니다. 단가가 5배 비싸도 성공률이 10배면 이깁니다. 반대로 검증이 자동화된 영역, 예를 들어 테스트가 촘촘히 깔린 코드베이스에서는 싼 모델을 무식하게 많이 돌리는 쪽이 압도적으로 유리해집니다.

그래서 요즘 모델 선택 논의가 ‘어느 모델이 더 똑똑한가’에서 ‘내 검증 파이프라인에서 어느 모델이 단위 비용당 성공을 많이 뽑는가‘로 옮겨가고 있습니다.

속도가 지능만큼 중요해진 이유

스웜에서는 지연 시간이 새로운 의미를 갖습니다. 에이전트 하나가 3분 걸리든 6분 걸리든 사람 입장에서는 별 차이가 없어 보입니다. 커피 한 잔 마시면 되니까요.

하지만 20개를 병렬로 굴리면 이야기가 달라집니다. 사람은 가장 먼저 도착한 결과를 보고 판단을 시작합니다. 나머지가 늦게 오면 그만큼 판단이 밀립니다. 즉 스웜에서는 평균 속도가 아니라 꼬리 지연, 가장 느린 요청이 전체 흐름을 결정합니다.

여기에 또 하나의 제약이 붙습니다. 요청 한도입니다. 아무리 병렬로 돌리고 싶어도 API 제한에 걸리면 20개가 5개로 줄어듭니다. 그래서 스웜 시대의 실질적 경쟁력은 모델의 벤치마크 점수가 아니라 동시에 얼마나 많이 굴릴 수 있느냐에서 갈립니다. 추론 인프라를 크게 확보한 쪽이 유리해지는 구조입니다.

진짜 병목은 결국 사람에게 돌아온다

스웜의 아이러니는 여기에 있습니다. 생산 속도를 20배로 올리면, 검토해야 할 코드도 20배가 됩니다.

에이전트 20개가 각자 그럴듯한 PR을 하나씩 만들어놓으면, 사람은 20개를 다 읽어야 할까요? 현실적으로 불가능합니다. 그래서 스웜을 실제로 굴리는 팀들은 예외 없이 자동 검증 계층에 투자합니다. 테스트, 타입 체크, 린트, 그리고 다른 에이전트가 결과를 심사하는 구조까지 붙입니다.

여기서 재미있는 재귀가 생깁니다. 심사하는 에이전트도 모델을 소비합니다. 결과적으로 생성보다 검증에 더 많은 토큰이 들어가는 워크플로가 흔해지고 있습니다. 모델 회사 입장에서는 나쁘지 않은 소식입니다. 수요가 사람의 타이핑 속도가 아니라 기계의 처리량에 비례해 늘어나니까요.

그래서 무엇이 남나

정리하면 세 가지입니다. 첫째, AI 모델의 가치는 이제 ‘똑똑함’이 아니라 ‘버릴 수 있을 만큼 싸면서 가끔 정답을 맞히는 능력‘과 ‘비싸지만 한 번에 맞히는 능력’이라는 두 축으로 갈라지고 있습니다. 둘째, 병렬 처리량과 속도가 벤치마크 점수만큼 중요한 스펙이 됐습니다. 셋째, 검증을 자동화하지 못한 조직은 스웜을 도입해도 이득을 보기 어렵습니다.

그리고 마지막으로 던지고 싶은 질문이 있습니다. 에이전트 20개가 만든 결과 중 하나를 고르는 일은, 정말 코드를 짜는 것보다 쉬운 일일까요? 앞으로 개발자의 핵심 역량이 ‘작성’에서 ‘판별’로 옮겨간다면, 우리는 그 판별력을 어디서 길러야 할까요. 코드를 직접 써보지 않고 좋은 코드를 알아볼 수 있는 사람은 아직 본 적이 없습니다.