AI끼리 반박시켰더니 난제 7개, 안티그래비티 팀워크

effidev·2026년 8월 30일

AI에게 일을 시킬 때 흔히 하는 생각이 있다. 하나로 안 되면 여러 개 붙이면 되지 않나.

그럴듯하다. 사람도 혼자 안 되는 일은 팀으로 하니까. 그래서 요즘 “멀티 에이전트”라는 말이 여기저기 붙는다. 에이전트(사람이 하나하나 지시하지 않아도 스스로 도구를 쓰고 다음 할 일을 정하는 AI)를 여러 개 띄워 놓고 같이 일을 시킨다는 뜻이다.

그런데 구글이 8월 27일에 낸 발표문은 그 상식을 정면으로 건드린다. 여러 개를 붙이면 오히려 같이 틀린다는 것이다.

이 글은 AI에게 코딩이나 조사를 시켜 본 적은 있지만, 에이전트를 여러 개 굴린다는 게 정확히 뭘 어떻게 하는 건지는 모르는 사람을 위한 것이다. 구글 안티그래비티(Google Antigravity)의 팀워크(Teamwork)라는 기능을 예로 삼아, 여러 AI를 붙일 때 실제로 무엇이 문제가 되고 어떤 장치로 그걸 막는지를 본다.

읽고 나면 “멀티 에이전트”라는 말을 들었을 때 무엇을 되물어야 하는지 알게 된다. 그게 이 글의 목표다.

발표문에 적힌 것만 쓴다. 확인 안 된 숫자와 발표문 밖 추측은 넣지 않고, 대신 구글이 이번에 말하지 않은 것도 마지막에 따로 적어 둔다.

에이전트를 여러 개 붙이면 왜 같이 틀리나

발표문이 진단을 먼저 내놓는다. 그리고 이 진단이 이 글에서 제일 중요한 문장이다.

느슨하게 조직된 에이전트들은 금세 궤도를 벗어난다. 다른 에이전트의 초기 실수에 동조하고, 결함 있는 아이디어 위에 자신 있게 쌓아 올린다.

한 번 더 읽어 볼 만하다. 문제는 에이전트가 멍청해서가 아니다. 서로 너무 잘 동의해서다.

첫 번째 에이전트가 방향을 잘못 잡는다. 두 번째 에이전트는 그 결과를 받아서 다음 단계를 만든다. 세 번째가 또 그 위에 쌓는다. 아무도 처음으로 돌아가 “그 전제가 맞나”를 묻지 않는다.

그렇게 나온 결과물은 겉으로 아주 그럴듯하다. 세 명이 합의한 것처럼 보이니까. 실제로는 한 명의 실수가 세 배로 증폭된 것인데도.

사람 팀에서도 벌어지는 일이다. 다만 사람은 회의 중에 누군가 인상을 찌푸리거나 말끝을 흐린다. 에이전트에는 그런 신호가 없다.

후보를 내는 쪽과 부수는 쪽을 갈라 놨다

구글의 해법은 협력을 늘리는 게 아니다. 반대다.

발표문은 연구와 엔지니어링 문제가 대개 같은 뼈대를 공유한다고 본다. 후보를 만들고, 스트레스 테스트로 두들겨 보고, 살아남은 것 중 좋은 조각들을 합쳐 더 나은 후보를 만든다. 팀워크는 이 반복을 구조로 못 박은 것이다.

가장 선명한 게 롱 프루프(Long Proof) 패턴에 들어간 장치다. 여러 후보 전략을 동시에 만들되, 각 후보마다 그것을 깨뜨리는 것이 유일한 임무인 에이전트를 짝지어 붙인다. 발표문은 이 역할을 팔시파이어(falsifier), 우리말로 하면 반증자라고 부른다.

여기서 한 번 더 뒤집는 부분이 있다. 반박당해 탈락한 경로를 버리지 않는다.

반박된 경로는 그 이의(objection)를 붙인 채로 과정에 남는다. 깨진 경로에도 여전히 쓸모 있는 아이디어가 들어 있을 수 있다.

틀린 답을 지우지 않고, “이 답은 이러이러해서 틀렸다”는 딱지를 붙여 보관한다는 뜻이다. 나중에 합치는 단계에서 그 조각이 다시 쓰인다.

시험지를 채점만 하고 버리는 게 아니라, 오답 노트를 팀 전체가 공유하는 쪽에 가깝다.

패턴이라는 설계도, 그 안에 실행 코드가 없는 이유

팀워크는 고정된 한 팀이 아니다. 문제 종류마다 다른 팀 구조가 필요하고, 그 구성 하나하나를 패턴(pattern) 이라고 부른다.

패턴은 청사진이다. 어떤 에이전트가 참여하는지, 각자 무슨 역할인지, 그리고 작업이 다음 단계로 넘어가려면 무엇을 만족해야 하는지를 적어 둔다. 마지막 항목이 핵심이다. 통과 기준이 없으면 에이전트는 그냥 계속 말을 만든다.

/teamwork-preview를 부르면 제미나이가 프롬프트를 읽고 알맞은 패턴을 자동으로 고른다. 사용자가 패턴 이름을 외울 필요는 없다.

지금 제공되는 패턴은 다섯 가지다.

여기서 설계상 눈여겨볼 게 하나 있다. 패턴에는 실행 코드가 없다.

발표문 표현으로는 “오케스트레이션 로직이 에이전트 설명과 분리돼 있다”. 패턴은 실행 가능한 프로그램이 아니라 명세이고, 프레임워크가 그 명세를 읽어 필요한 에이전트를 알아서 띄운다.

그래서 얻는 게 뭐냐면, 적대적 비판 루프 같은 특수 장치를 수정 없이 전혀 다른 분야로 옮길 수 있다. 수학 증명을 검증하려고 만든 구조를 코드 최적화에 그대로 쓴다는 이야기다.

몇 명을 투입할지는 실행 중에 정해진다

보통 멀티 에이전트를 쓴다고 하면 “에이전트 5개를 띄운다” 같은 식으로 수를 먼저 정한다.

팀워크는 그러지 않는다. 발표문은 패턴이 실행 시점에 적응적(adaptive at runtime) 이라고 못박는다.

• 몇 개를 띄울지는 작업 요구에 따라 프레임워크가 정한다. 미리 정해 둔 수가 아니다.
• 에이전트 수와 팀 구조가 실행 도중에 바뀔 수 있다.
• 오케스트레이터가 배치할 에이전트 수와 반복 횟수를 결정한다.

문제의 윤곽이 드러나면서 팀이 재편된다는 뜻이다. 발표문은 이걸 고정된 파이프라인이 아니라 “살아 있는 과정”이라고 표현한다.

실무자에게 이게 왜 중요하냐면, 비용을 미리 계산할 수 없다는 뜻이기도 하기 때문이다. 이 부분은 뒤에서 다시 짚는다.

난제 일곱 개, 그리고 검토자가 사람이 아니었던 한 개

여기가 이번 발표의 알맹이다. 롱 프루프 패턴으로 이론 전산학과 수학의 열린 문제(아직 아무도 풀지 못한 문제) 일곱 개를 다뤘다고 한다.

먼저 검증 이야기부터 하자. 일곱 개 중 여섯 개는 사람 전문가가 검토해 맞다고 확인했다.

나머지 하나가 예외다. 커누스의 사이클 추측(Knuth’s Cycles Conjecture) 결과인데, 여기서는 40쪽짜리 증명을 린(Lean)으로 형식 검증했다. 린은 증명을 컴퓨터가 한 줄씩 따라가며 확인할 수 있는 형태로 적는 언어다.

즉 이 한 건은 사람이 읽어서 승인한 게 아니라 기계가 통과시켰다. 40쪽이 넘는 증명을 사람이 눈으로 검토하는 일이 어떤 규모인지 생각해 보면, 이 선택 자체가 결과의 성격을 말해 준다.

일곱 개 목록은 이렇다.

FOCS와 JMLR은 이론 전산학·기계학습 쪽에서 통하는 상위 학회·저널이다. 거기에 열린 문제로 올라가 있던 것들이라는 뜻이다.

이 중 다섯 편의 논문이 arXiv에 올라와 있다. 번호가 표에 그대로 적혀 있으니 발표문을 믿지 않아도 직접 열어 볼 수 있다. 이 점이 이번 발표에서 가장 검증 가능한 부분이다.

다섯 번째 항목에는 흥미로운 단서가 붙어 있다. 인터넷 접속 없이 해답을 재발견했다는 것이다. 답을 어디서 베껴 온 게 아니라는 걸 보이려는 조건으로 읽힌다.

값싼 모델이 그중 셋을 다시 풀었다

여기에 이번 발표의 진짜 반전이 있다.

위 결과들은 제미나이 3.1 프로(Gemini 3.1 Pro) 로 얻은 것이다. 프로는 상위 등급 모델이다.

그런데 그중 세 개(1번·3번·4번 문제)를 제미나이 3.7 플래시(Gemini 3.7 Flash)로 재현했다고 적혀 있다. 플래시는 빠르고 값싼 쪽 등급이다.

발표문은 이걸 이렇게 표현한다. 올바른 오케스트레이션 프레임워크와 함께라면, 플래시 등급 모델이 이런 박사 수준 수학 연구를 만들어 낸 최초의 사례라고.

일하는 방식이 모델 등급을 어느 정도 대신할 수 있다는 주장이다. 만약 사실이라면 “좋은 결과를 원하면 비싼 모델을 쓰라”는 기본 공식이 흔들린다.

다만 발표문이 스스로 붙인 단서가 두 개 있고, 이건 옮겨 적을 필요가 있다.

• 일부 결과는 기본값보다 높은 병렬도를 사용했다.
• 안티그래비티에서 제공되는 버전은 비용과 성능의 균형을 맞춘 것이며, 같은 워크플로를 지원하되 위 실험과 같은 설정은 아니다.

즉 “플래시로 됐다”는 말과 “지금 내가 플래시로 눌러도 저게 나온다”는 말은 다르다. 이 구분을 발표문이 직접 적어 뒀다는 점은 오히려 신뢰가 가는 대목이다.

71%라는 점수가 놓인 자리

벤치마크 숫자도 하나 나온다.

TCSBench는 구글 내부에서 독립적으로 개발한 이론 전산학 문제 평가 모음이다. 열려 있고 어려운 문제들로 구성돼 있다.

여기서 롱 프루프 패턴은 제미나이 3.7 플래시와 3.1 프로를 함께 써서 71% 를 기록했다.

비교 대상은 TCSBench 논문에 보고된 67.7% 다. 그쪽은 제미나이 3.6 플래시와 3.1 프로 조합이었다. 구글은 71%가 자사 내부 테스트 중 최고 점수라고 적었다.

여기에 지금 당장은 못 쓴다는 단서가 붙는다. 롱 프루프 패턴 안에서 플래시와 프로를 조합하는 기능은 “향후 업데이트에서 제공될 예정”이다.

발표문 안에서 71%와 “곧 제공”이 나란히 붙어 있다는 것 — 숫자를 읽을 때 같이 봐야 하는 부분이다.

CPU를 처음부터 흉내 내게 시켰더니

수학만 있었으면 “그래서 내 일과 무슨 상관인가” 싶었을 텐데, 시스템 쪽 사례가 하나 더 있다. 그리고 이쪽이 개발자에게는 더 와닿는다.

제미나이 3.7 플래시로, 팀워크가 사이클 수준 비순차 실행(out-of-order) RISC-V CPU 시뮬레이터를 맨바닥에서 만들었다.

풀어 쓰면 이렇다. CPU가 명령을 어떤 순서로 처리하고 각 단계에서 몇 번의 박자를 쓰는지까지 소프트웨어로 흉내 내는 프로그램이다. 하드웨어 설계자들이 칩을 만들기 전에 성능을 재는 데 쓴다.

결과물이 한 일은 두 가지다.

• xv6라는 운영체제를 셸이 뜰 때까지 부팅시켰다.
• RISC-V 표준 벤치마크 100개 이상을 실행했다.

진행은 두 단계로 나눴다. 1단계는 마이크로아키텍처 기능 정확성이다. 비순차 파이프라인과 리오더 버퍼(ROB) 같은 핵심 실행 로직을 만들고, 기능 오라클(정답 역할을 하는 기준 구현)에 맞춰 상태가 맞는지 확인했다.

2단계는 사이클 수준 타이밍 검증이다. 여기서 성능 특성을 엄격한 타이밍 기준에 맞춰 정렬했다.

에이전트들은 MSHR·ROB·캐시 같은 단위를 각각 만들고 검증했다. 아키텍처 마이크로벤치마크를 돌리고, 자기가 만든 실행 추적을 스스로 분석하고, 격리된 BOOM 시뮬레이터와 최종 사이클 수 차이를 비교하는 식이다.

0.71%가 왜 만만치 않은 숫자인가

BOOM 하드웨어의 실제 실행 결과를 정답으로 놓고 비교했을 때, 처음 보는 워크로드에서 평균 사이클 정렬 오차가 0.71% 로 나왔다.

100박자 걸리는 작업에서 0.71박자쯤 어긋난다는 뜻이다. 그것도 학습에 쓰지 않은 워크로드에서.

이게 왜 어려운지는 발표문이 붙인 이름이 잘 설명한다. 조용한 실행 간극(silent execution gap) 이다.

아키텍처적 실패가 눈에 보이기 전까지, 마이크로아키텍처 상태가 조용히 어긋나 있을 수 있는 수백 사이클에 이르는 구간.

버그가 났는데 한참 뒤에야 증상이 나타난다는 뜻이다. 어디서 틀어졌는지 되짚기가 극도로 어려워진다. 테스트가 빨간불이 되는 순간과 실제로 잘못된 지점이 수백 박자 떨어져 있는 상황을 상상하면 된다.

이건 정적인 코드 번역과는 성격이 다르다. 시간이 개입하는, 그것도 비결정적인 하드웨어 시뮬레이션이기 때문이다.

컨닝을 막으려고 원본을 금고에 넣었다

여기서 구글이 한 조치가 하나 있는데, 평가 설계 관점에서 볼 만하다.

스파이크(Spike) 시뮬레이터의 소스 코드를 샌드박스로 격리했다. 발표문은 이유를 그대로 적었다 — “부정행위를 막기 위해(to prevent cheating)”.

스파이크는 RISC-V 진영의 기준 시뮬레이터다. 소스를 볼 수 있으면 에이전트가 답을 베껴 올 수 있다. 그래서 아예 못 보게 막았다.

그러면서도 정답 대조는 해야 한다. 그 방법이 에어갭(air-gapped)된 스파이크 기준 시뮬레이터와의 연속 록스텝 공동 시뮬레이션이다. 두 시뮬레이터를 한 박자씩 나란히 돌리며 계속 대조하되, 코드는 보여 주지 않는 구조다.

답은 못 보고 채점만 받는 상태에서 만들게 한 것이다. AI 성능 주장을 볼 때 평가를 어떻게 격리했는가가 숫자 자체만큼 중요한데, 이번 발표는 그 부분을 적어 뒀다.

에이전트에게 자율성을 얼마나 주고 무엇을 막을 것인가는 요즘 반복해서 돌아오는 질문이다. 오픈AI가 허깅페이스 침해 사고 보고서에서 다룬 격리 문제와 방향은 정반대지만 — 한쪽은 능력 측정, 다른 쪽은 사고 방지 — 결국 같은 설계 축을 건드린다.

남의 라이브러리에 코드를 밀어 넣은 기록

앞의 두 사례는 구글이 스스로 채점한 것이다. 세 번째는 성격이 다르다. 외부 사람이 받아들였다.

첫 번째는 아이겐(Eigen)이다. 구글 내부와 커뮤니티 전반에서 널리 쓰이는 C++ 선형대수 라이브러리다.

조건은 이랬다. 아이겐 마이크로벤치마크 모음을 돌리되 구현에는 아무 제한을 두지 않았고, 벤치마크 자체만 손대지 않으면 됐다.

팀워크가 찾아낸 건 이거다. 행렬이 한 행 또는 한 열뿐일 때 GeMV(행렬-벡터 곱) 연산 구현이 최적이 아니었다.

만든 해법은 그 경우 전용 빠른 경로다. 데이터에 직접 접근하고, SIMD(한 명령으로 여러 값을 동시에 처리하는 방식) 연산에 4-way 누산기 언롤링을 적용했다.

그리고 제미나이 3.6 플래시의 도움을 받아 오픈소스 코드 리뷰 절차를 끝까지 거쳐 업스트림 아이겐에 반영시켰다.

2배와 25%가 같이 나온 이유

두 번째는 팔레이해시(ParlayHash)다. 고성능 동시성 해시 테이블인데, 여기에 스위스 테이블(Swiss Table)의 최적화를 접목한 스위스 팔레이(Swiss Parlay) 아이디어에 기여했다.

기존 팔레이해시 대비 결과는 이렇다.

• 64스레드 초기 삽입에서 처리량 2배
• 단일 스레드 전체 처리량 1.5배
• 최고 수준 순차 테이블(FlatHashMap)에 근접한 성능을 내면서 원소당 메모리는 25% 절약

세 번째 줄이 눈여겨볼 대목이다. 보통 자료구조에서 속도와 메모리는 맞바꾸는 관계다. 빠르게 하려면 더 쓰고, 아끼려면 느려진다. 여기서는 속도를 따라잡으면서 메모리를 덜 썼다.

발표문은 마지막에 한 문장을 덧붙인다.

이것들은 벤치마크에서만 나온 결과가 아니다. 표준 오픈소스 코드 리뷰를 거쳐 외부 유지관리자들이 받아들인 실제 기여다.

두 변경 모두 이미 체크인됐다. 아이겐은 커밋으로, 팔레이해시는 브랜치로. 구글이 자기 저장소에 넣고 자랑한 게 아니라 남의 프로젝트 관리자가 승인했다는 게 이 사례의 무게다.

AI가 만든 결과물을 평가할 때 이 구분은 꽤 쓸모 있다. 자체 벤치마크 점수인가, 아니면 이해관계 없는 제3자가 받아들였는가.

이 발표가 조심스럽게 비켜 간 것들

여기까지가 발표문에 있는 내용이다. 이제 없는 것을 적는다. 추측이 아니라 “이 문서에 안 나온다”는 사실만이다.

비용이 없다. 팀워크는 유료 플랜에서만 쓸 수 있고, 에이전트 수는 실행 중에 프레임워크가 정한다. 그런데 한 번 돌리는 데 얼마가 드는지, 병렬도를 올리면 얼마나 늘어나는지에 대한 숫자가 없다. 앞에서 본 “기본값보다 높은 병렬도”라는 단서와 함께 놓으면 이 공백이 더 커 보인다.

걸린 시간이 없다. “수 시간에서 수일”이라는 표현은 있지만, 난제 일곱 개나 CPU 시뮬레이터에 각각 얼마가 걸렸는지는 없다.

실패한 시도 수가 없다. 일곱 개를 풀었다는 건 알겠는데, 몇 개를 시도해서 일곱 개인지는 안 나온다. 열 개 중 일곱과 백 개 중 일곱은 전혀 다른 이야기다.

플래시·프로 조합은 아직 못 쓴다. 71%를 만든 그 구성은 “향후 업데이트” 대상이다.

7번 문제의 범위가 좁혀져 있다. 커누스 사이클 추측 전체가 아니라 “짝수 정수 경우의 더 단순한 구성 두 개에 대한 최초 증명”이다. 발표문이 정확하게 적어 둔 것이고, 옮길 때 잘리기 쉬운 종류의 단서다.

이런 공백이 있다고 결과가 가짜라는 뜻은 아니다. 다만 “AI가 난제를 풀었다”는 한 줄로 옮기면 원문보다 훨씬 센 주장이 된다. arXiv 번호와 깃허브 링크를 같이 낸 발표문 쪽이 오히려 조심스럽다.

지금 내 손으로 확인해 볼 수 있는 것

오늘 이 기능을 처음 들었다면, 순서는 이렇다.

첫째, 가장 값싼 검증부터 한다. 표에 적힌 arXiv 번호 다섯 개를 그냥 열어 보면 된다. 구글 발표문을 믿을지 말지 고민할 필요 없이, 논문이 실제로 거기 있는지부터 확인되는 것이다. 이런 종류의 발표에서 이 정도로 대조 가능한 근거를 내놓는 경우는 흔치 않다.

둘째, 쓸 거라면 조건을 확인한다. /teamwork-preview는 안티그래비티 유료 플랜에서 제공된다. 앞에서 본 대로 비용 정보가 발표문에 없으므로, 큰 작업을 던지기 전에 작은 것부터 돌려 보고 소모량을 직접 재는 편이 안전하다.

셋째, 이 구조를 지금 쓰는 도구에 옮겨 본다. 이게 사실 가장 실속 있다. 팀워크를 안 써도 오늘 바로 할 수 있는 게 있다.

AI에게 답을 받은 다음, 같은 AI에게 그 답을 깨뜨려 보라고 시키는 것이다. “검토해 줘”가 아니라 “이게 틀렸다고 가정하고 근거를 찾아라”에 가깝게. 팀워크의 반증자가 하는 일이 정확히 그거고, 이 발표문 전체가 기대는 원리도 그거다.

한 번 더 물어보는 것만으로 초기 실수 위에 계속 쌓아 올리는 패턴은 상당 부분 끊긴다.

넷째, “멀티 에이전트”라는 말을 들으면 하나만 되물어 본다. 에이전트가 몇 개인지가 아니라, 누가 누구의 결과를 부수는 역할인지. 이 질문에 답이 없으면 그건 그냥 여러 개를 띄운 것이고, 발표문이 경고한 그 상태다.

모델 등급 이야기도 같은 맥락에서 볼 수 있다. 가중치를 공개하는 쪽이든 API로 파는 쪽이든, 요즘 성능 발표에서 반복되는 건 모델 크기를 안 키우고도 특정 능력만 끌어올리는 방식이다. 이번엔 그 자리에 오케스트레이션이 들어왔다. 무엇이 성능을 만들었는지가 갈수록 모델 바깥으로 옮겨 가고 있다.

발표문 마지막 문단이 이 기능의 성격을 정확히 요약한다. 열린 수학 추측, 성능이 중요한 라이브러리 코드, 하드웨어 시뮬레이션 — 전통적으로 깊은 전문가가 몇 달에 걸쳐 하던 일들이다. 팀워크는 그 반복 주기를 압축하되, 방향 설정과 최종 승인은 전문가에게 남겨 둔다.

여기서 “최종 승인은 사람”이라는 조건은 마케팅 문구가 아니라 설계의 일부다. 난제 일곱 개 중 여섯 개를 사람이 검토했다는 사실이 그 증거다.

그리고 나머지 하나는, 사람이 검토하기엔 증명이 너무 길어서 기계에 맡겼다.