AX 노트 · 측정

'에이전트 수백 개 써도 돼'의 실제: 워크스트림 10개, 하루 59커밋, 동시 실행은 3개

코드를 고치는 에이전트는 한 번에 3개까지만 돌았습니다. 그 상한은 여유 RAM 4GB와 공용 기기 2대가 정했습니다.

작성 SugarMount 에이전트와 일하는 법 읽는 시간 8분 최종 업데이트

"에이전트 수백 개 써도 되고 시간 오래 걸려도 되니까 심층분석해서 진행해." 10월 3일 오후 4시 8분, 운영자가 화살표 매듭풀기를 300판에서 1,000판으로 늘리자며 남긴 요청입니다. 그날 저장소에는 커밋 59개가 쌓였고, 워크스트림 10개(ws0~ws9)가 각자 브랜치에서 통합 브랜치로 머지됐습니다. 그런데 코드를 쓰는 에이전트가 동시에 돈 것은 최대 3개였습니다. 메모리 13GB 가운데 여유가 4GB뿐이었거든요.

숫자는 SugarMount 게임 저장소(sugar-game)의 git 기록(한국 시간 기준 일별 집계, 머지 커밋 206881a~427cb92), 사양서 docs/09-parts-1000-spec.md와 구현 메모 docs/09b-impl-notes.md, 그리고 이 저장소에서 연 Claude Code 세션 기록의 도구 호출을 스크립트로 센 값입니다. 기준일은 2026년 10월 21일입니다.

목차 (6)
  1. 요청은 '수백 개', 동시에 코드를 쓴 에이전트는 3개였습니다
  2. 10월 3~4일의 커밋, 머지, 에이전트 수
  3. 병렬도를 정한 것은 RAM, 기기 2대, 파일 주인 표였습니다
  4. 에이전트 41개가 '실패 0'으로 끝낸 앱이 첫 실행에서 죽었습니다
  5. 다음 실험
  6. 자주 묻는 질문

요청은 '수백 개', 동시에 코드를 쓴 에이전트는 3개였습니다

요청 1분 뒤 에이전트는 설계용 Workflow를 띄웠습니다. Workflow는 Claude Code에서 서브에이전트 여러 개를 스크립트 하나로 묶어 돌리는 도구입니다. 난이도 곡선, 확대 화면, 게임 경제, 디자인, 스토어 문구, 다국어를 주제별로 나눠 에이전트 24개가 16:09부터 17:01까지 일했습니다. 코드를 건드리지 않는 일이라 첫 단계에서는 11개가 동시에 돌았습니다.

그 결과를 합친 사양서가 17:18에 커밋됐습니다(지금은 부록까지 1,327줄). 3분 뒤 시작한 구현 Workflow에서는 에이전트 41개가 구현, 적대적 리뷰, 수정, 머지를 나눠 맡아 22:27까지 5시간 6분을 돌았는데, 동시에 실행된 수는 1단계의 엔진 규칙(ws0), 레벨 생성기(ws1), 문자열과 빌드 설정(ws6) 3개가 최대였습니다. 2·3단계는 2개씩이었고, 화면 통합(ws7)과 테스트 도구(ws8)는 혼자 돌았습니다. 스토어 문안(ws9)은 Workflow 밖에서 서브에이전트 하나가 22:36에 시작해 11분 만에 끝냈습니다.

3이라는 숫자는 에이전트가 스스로 골랐습니다. 구현 직전 세션에 남긴 판단의 요지는 16코어에 RAM 13GB(여유 4GB)라 Android 빌드를 한 번에 2~3개로 묶겠다는 것이었습니다. 17:28에 한 워크스트림 에이전트가 찍은 메모리 상태도 같았습니다.

$ free -g
               total        used        free      shared  buff/cache   available
Mem:              13           8           2           0           2           4

10월 3~4일의 커밋, 머지, 에이전트 수

이틀 동안 이 저장소에서 움직인 세션은 3개(화살표 게임, 광고·출시, 한판블록)였습니다. Agent·Workflow 칸은 이 세 세션이 직접 부른 횟수이고, 마지막 칸은 Workflow 안에서 뜬 에이전트 수입니다. 동시 최대는 에이전트마다 기록의 첫 시각과 마지막 시각을 잡아 겹친 수를 셌습니다.

날짜 (KST)커밋머지 커밋Agent 호출Workflow 실행Workflow 안 에이전트 (동시 최대)
10-035911112설계 24 (11), 구현 41 (3)
10-04526143E2E 수정 10 (3), 출시 준비 조사 150 (14)

10-03의 머지 11개는 모두 ws 브랜치입니다. 시뮬레이션 담당 ws2가 생성기 재조정 때문에 두 번 들어가서 11개가 됐습니다. 10-04의 6개는 E2E 수정 브랜치 3개와 main을 받아 온 머지 3개입니다. 10-04 Workflow 3번 가운데 1번은 한판블록 조사 실행을 이어 붙인 재개 호출이고, 150은 그 실행의 기록 파일 수라 재시도분이 섞여 있습니다.

이 저장소의 세션 6개(09-30~10-17)에서 운영자는 '수십 개', '수백 개', '마음껏' 같은 말로 에이전트를 많이 띄우라고 5번 요청했습니다. 메인 세션의 Agent 호출은 다 합쳐 53번이었고, 한 세션에서 가장 많이 부른 것이 20번이었습니다. Workflow 실행은 10번이었습니다.

병렬도를 정한 것은 RAM, 기기 2대, 파일 주인 표였습니다

먼저 막힌 곳은 빌드 메모리였습니다. 구현 메모는 ./gradlew --max-workers=4를 쓰고 작업 공간 하나에서 Gradle 빌드는 한 번에 하나만 돌리라고 적었습니다. 워크스트림마다 커밋 전에 엔진·앱 단위 테스트와 디버그 빌드를 통과해야 했으니, 동시 워크스트림 수가 곧 동시 Gradle 수였습니다. 빌드를 하지 않는 조사·설계 Workflow는 사정이 다릅니다. 이 저장소에서 6번 돌았고, 동시 실행이 11~14개까지 올라갔습니다.

막대 그림: Workflow별 동시 실행 최대 수는 설계 11개, 구현 3개, E2E 수정 3개, 출시 준비 조사 14개였다.
코드를 고친 Workflow는 동시 3개가 최대였고, 빌드를 하지 않는 설계·조사는 11~14개까지 돌았습니다.

기기는 Galaxy S21과 S20 두 대였습니다. 이 둘을 화살표 게임, 광고·출시, 한판블록 세션과 다른 앱 저장소의 유틸리티 세션 2개, 모두 세션 5개가 나눠 썼습니다. 그래서 구현 메모에는 "어떤 워크스트림도 기기를 만지지 않는다, E2E는 나중에 S21에서만"이라고 적혀 있습니다. 10월 3~4일에 이 저장소 세션 세 개가 받은 세션 간 메시지는 148건이었고, 그중 114건이 S20이나 S21을 언급했습니다. 상당수가 "10분만 쓰겠다", "다 썼으니 이제 쓰셔도 된다" 같은 순서 조율이었습니다. (그날 S21은 16:14부터 17:17까지 다른 앱 세션의 한글 문서 뷰어 벤치마크에 가 있었습니다. 화살표 세션은 자기 앱 데이터와 글자 크기 같은 전역 설정을 건드리지 말라는 조건을 붙여 기기를 내줬죠.)

파일도 주인을 정했습니다. 사양서 11장의 워크스트림 표에는 "독점 소유" 열이 있습니다. 카메라 담당 ws3는 Camera.kt, BoardView.kt, CameraMathTest.kt만 고칩니다. 광고 코드와 공용 플랫폼 모듈은 다른 세션 몫이라 워크스트림은 읽기만 했습니다. 각 워크스트림은 자기 git worktree에서 커밋만 하고, 통합 브랜치에 머지하는 것은 통합 에이전트 하나뿐입니다. 워크트리로 에이전트를 나누는 방식은 AI 코딩 에이전트로 20일 만에 Android 앱 4개를 출시한 방법에서 처음 썼고, 이번에는 여기에 주인 표를 더했습니다.

에이전트 41개가 '실패 0'으로 끝낸 앱이 첫 실행에서 죽었습니다

22:27 구현 Workflow는 "41개 모두 완료, 실패 없음"으로 끝났습니다. Workflow 안의 워크스트림은 시뮬레이션(ws2)만 빼고 모두 적대적 리뷰를 한 번 이상 거쳤고, 마지막 머지 에이전트가 전체 JVM 테스트와 디버그 빌드를 통과시킨 상태였습니다. 1분 뒤 S21에 설치하자 앱이 실행 직후 죽었습니다. 원인은 레벨 파일 이름이었습니다. Android 빌드 도구(aapt)가 에셋 이름 끝의 .gz를 떼어 내는 바람에, 코드가 찾는 파일이 APK 안에 없었죠. 22:31 커밋 4d46413이 레벨 파일을 압축하지 않은 채로 넣고, 에셋 이름이 .gz로 끝나면 실패하는 회귀 테스트를 붙였습니다.

33개 항목짜리 세부 E2E는 00:36부터 01:41까지 S21 한 대를 혼자 썼습니다. 31개가 통과하고 1개(큰 판 패닝 끊김)가 실패했으며, 1개는 디버그 빌드에서 확인할 수 없어 건너뛰었습니다. 버그와 디자인 문제는 10건이 나왔습니다. 이를 고친 Workflow도 에이전트 10개에 동시 3개였고, 02:23에 수정 브랜치 3개가 머지됐습니다.

타임라인: 10월 3일 16:08 요청, 22:27 에이전트 41개 완료와 실패 없음, 1분 뒤 S21 크래시, 22:31 커밋 4d46413, 00:36~01:41 E2E 33개 중 31개 통과, 02:23 수정 브랜치 3개 머지.
에이전트 41개가 '실패 없음'으로 끝낸 1분 뒤 앱이 S21에서 죽었고, 기기에서만 드러나는 결함은 맨 끝 E2E에서 나왔습니다.

에이전트가 틀린 것은 '완료'의 정의였습니다. 기기를 못 쓰게 한 규칙 자체는 맞았습니다. 그 대가로 41개의 '완료'는 JVM 테스트와 컴파일 통과만 뜻하게 됐고, 기기에서만 드러나는 결함은 전부 맨 끝의 한 줄짜리 대기열로 밀렸습니다. 이걸 잡은 것은 운영자가 첫 요청에 넣은 한 구절 "S21에 설치해서 E2E 테스트까지"였습니다. 01:43에는 운영자가 "S20에서 E2E 진행해도 괜찮다"며 기기 한 대를 더 내줬습니다. 그 덕에 출시 빌드 무작위 입력 3,000회×3 검사가 S20에서 수정 Workflow와 나란히 돌았습니다(크래시 0건).

에이전트를 몇 개 띄울지 정하기 전에, 동시에 돌릴 수 있는 빌드 수와 기기 수부터 세십시오.

다음 실험

자주 묻는 질문

Claude Code 서브에이전트는 몇 개까지 병렬로 돌릴 수 있나요?

이 저장소 기록에서는 빌드를 하지 않는 조사용 Workflow가 동시 14개까지 돌았습니다. Gradle 빌드를 하는 구현 에이전트는 여유 RAM 4GB에 맞춰 3개로 묶었습니다.

에이전트마다 git worktree를 따로 주면 충돌이 사라지나요?

git 충돌은 줄지만 기기와 메모리를 두고 벌어지는 다툼은 남습니다. 이번에는 워크스트림별 독점 파일 표와 통합 에이전트 한 명만 머지하는 규칙으로 git 쪽을 막았고, 기기 두 대의 순서는 세션 간 메시지로 맞췄습니다.

워크스트림 10개를 하루에 어떻게 합쳤나요?

의존 순서대로 단계를 나누고, 단계가 끝날 때마다 통합 에이전트가 브랜치를 --no-ff로 차례로 머지한 뒤 단위 테스트와 디버그 빌드를 돌렸습니다. 10월 3일 19:10부터 22:47까지 머지 커밋 11개가 이렇게 생겼습니다.

이 글은 SugarMount가 직접 측정한 값으로 쓰고, 초안 작성에 AI 코딩 에이전트를 썼습니다.

에이전트와 일하는 법 글 전체 보기 · AX 노트 전체 보기