YC가 만든 qm, AI 에이전트도 이제 '팀'으로 일합니다

AI 코딩 에이전트를 하나 돌려보신 분들은 대체로 비슷한 감상을 말합니다. “잘 하는데, 내가 계속 봐줘야 하네.” 그런데 요즘 개발자들 사이에서는 그 다음 단계 이야기가 나옵니다. 하나가 아니라 다섯 개, 열 개를 동시에 돌리면 어떻게 되느냐는 거죠. Y Combinator가 최근 공개한 qm이라는 오픈소스 도구가 딱 그 질문을 겨냥합니다. 이름은 “멀티플레이어 에이전트 하네스"인데요, 풀어 쓰면 AI 에이전트 여러 명을 한 프로젝트에 투입해서 굴리는 관제탑입니다.

먼저 솔직히 밝히고 시작하겠습니다. 이번 주제는 커뮤니티 데이터가 유난히 얇았습니다. 지난 30일간 Reddit에서 이 키워드로 잡히는 유의미한 스레드가 사실상 없었어요. 그래서 이 글은 커뮤니티 여론 분석이라기보다, 이 도구가 왜 지금 나왔고 무엇을 건드리는지를 짚는 쪽에 가깝습니다. 화제성으로 보면 아직 초기 국면이라는 뜻이기도 하고요.

‘하네스’라는 단어가 등장한 이유

하네스(harness)는 원래 말이나 개에게 채우는 마구를 뜻합니다. 소프트웨어에서는 테스트 하네스처럼 “무언가를 붙들어 매고 제어하는 틀"이라는 의미로 쓰이죠. AI 업계에서 이 단어가 부쩍 늘어난 데는 이유가 있습니다.

지난 1~2년 사이 개발자 도구 이야기의 초점이 확실히 옮겨갔거든요. 예전엔 “어떤 모델이 더 똑똑한가"가 전부였습니다. 지금은 다릅니다. 모델은 이미 충분히 똑똑한데, 그 똑똑함을 실제 결과물로 바꿔주는 바깥 껍데기가 성능을 가른다는 쪽으로 얘기가 모였습니다. 같은 모델이라도 어떤 하네스에 넣느냐에 따라 벤치마크 점수가 크게 갈린다는 건 이미 여러 번 확인됐고요.

qm이 스스로를 “에이전트"가 아니라 “하네스"라고 부르는 것도 그래서입니다. 더 똑똑한 AI를 만들었다는 말이 아니라, 이미 있는 AI를 더 잘 부리는 틀을 짰다는 말이니까요. 겸손해 보이지만 실은 더 도발적인 포지셔닝입니다.

멀티플레이어가 진짜 의미하는 것

‘멀티플레이어’라는 표현에서 게임을 떠올리셨다면 절반은 맞습니다. 다만 여기서 플레이어는 사람이 아니라 에이전트입니다.

에이전트를 여러 개 동시에 돌리는 발상 자체는 새롭지 않습니다. 이미 많은 개발자가 터미널 창을 서너 개 띄워놓고 각각 다른 브랜치에서 에이전트를 굴리고 있어요. git worktree로 작업 디렉터리를 분리해 충돌을 피하는 패턴도 꽤 퍼졌고요. 문제는 이게 수작업이라는 겁니다.

창이 세 개면 그럭저럭 관리됩니다. 다섯 개가 되면 어느 창이 뭘 하고 있었는지 헷갈리기 시작해요. 열 개가 되면 관리 자체가 본업이 됩니다. 커밋을 병합하다 충돌이 나고, 두 에이전트가 같은 파일을 반대 방향으로 고쳐놨고, 방금 끝난 작업이 어느 요청에 대한 답이었는지 기억이 안 납니다. 여러 에이전트를 실제로 굴려본 사람이라면 이 대목에서 고개를 끄덕일 겁니다.

qm이 겨냥한 지점이 바로 이 지저분한 중간 지대입니다. 병렬 작업 공간을 알아서 갈라주고, 어느 에이전트가 무슨 상태인지 한눈에 보여주고, 결과물을 합칠 때 밟을 절차를 정리해줍니다. 화려한 기능은 아니지만, 실제로 쓰는 사람 입장에서는 가장 절실한 부분입니다.

왜 하필 YC가 만들었나

여기서 흥미로운 건 만든 쪽입니다. Y Combinator는 스타트업 액셀러레이터입니다. 개발 도구 회사가 아니에요. 그런 조직이 사내용으로 만든 도구를 오픈소스로 푼 것 자체가 신호입니다.

YC는 매 배치마다 수백 개 스타트업을 상대합니다. 이 회사들이 AI 에이전트를 어떻게 쓰고 어디서 막히는지를, 아마 세계에서 가장 넓게 지켜보는 자리에 있죠. 거기서 나온 결론이 “모델이 부족하다"가 아니라 “여러 개를 굴릴 도구가 없다"였다면, 시장의 병목이 어디로 옮겨갔는지 짐작할 만합니다.

도구 시장이 얼마나 빠르게 재편되는지도 같이 드러납니다. 에이전트 오케스트레이션 레이어는 지금 무주공산에 가깝습니다. 각 AI 회사가 자기 CLI를 내놓고, 스타트업들이 그 위에 관리 도구를 얹고, 이제는 액셀러레이터까지 뛰어들었어요. 아직 아무도 “이게 표준"이라고 말할 수 없는 상태라는 뜻입니다.

그래서 진짜 병목은 오케스트레이션이었을까

여기서 한 발 물러서 봅시다. 에이전트를 열 개 굴릴 수 있게 되면 생산성이 열 배가 될까요?

겪어보면 그렇지 않습니다. 이유는 오래된 소프트웨어 공학 상식에 있어요. 사람을 더 투입한다고 프로젝트가 빨라지지 않는다는 이야기, 들어보셨을 겁니다. 인원이 늘면 소통 비용이 제곱으로 늘어나기 때문이죠. 에이전트도 똑같은 함정에 빠집니다. 에이전트끼리는 소통을 안 하니까 그 비용이 전부 사람에게 넘어옵니다.

병목은 에이전트를 병렬로 돌리는 능력이 아니라, 그 결과물을 검토하고 판단하는 사람의 대역폭입니다. 코드를 짜는 속도가 아니라 코드를 읽는 속도가 한계선인 거죠. 에이전트 다섯 개가 각각 300줄짜리 PR을 던져놓으면, 그걸 다 읽고 승인할 사람은 여전히 한 명입니다.

qm 같은 도구가 이 문제를 완전히 풀어주진 못합니다. 관리 부담을 덜어서 버틸 수 있는 에이전트 수를 조금 늘려줄 뿐이죠. 그것만으로도 충분히 쓸모 있지만, “이제 AI가 팀으로 일한다"는 표현은 아직 마케팅에 가깝습니다. 정확히는 사람 한 명이 여러 AI를 동시에 감독하는 구조고, 감독자는 여전히 병목입니다.

지금 무엇을 봐야 하나

이 분야를 지켜보신다면 눈여겨볼 게 두 가지입니다.

첫째, 검토 자동화가 어디까지 오느냐입니다. 에이전트가 짠 코드를 다른 에이전트가 검토하는 구조가 쓸 만해지면, 그때 병목이 풀립니다. 지금은 검토 에이전트도 사람이 검토해야 하는 상황이라 순환에서 못 벗어났어요.

둘째, 표준화 여부입니다. 지금은 각자 자기 하네스를 만드는 춘추전국시대입니다. 어떤 형태로든 공통 규격이 자리 잡으면 도구끼리 갖다 붙일 수 있게 되고, 그때 생태계가 한 단계 점프합니다.

qm은 그 흐름 위에 찍힌 점 하나입니다. 판을 바꾸는 도구라기보다, 문제가 어디로 옮겨갔는지 알려주는 표지판에 가깝죠. 모델 성능 경쟁이 어느 정도 평준화되면서 승부처가 “AI를 얼마나 잘 부리느냐"로 넘어왔다는 것. qm이 알려주는 건 그겁니다.

지금 AI 에이전트를 몇 개까지 동시에 굴려보셨나요? 그때 힘들었던 건 에이전트의 실력이었나요, 아니면 그걸 관리하는 일이었나요? 아마 대부분 후자일 거고, 다음 몇 년간의 도구 시장도 거기에 걸려 있습니다.