Claude Code의 dynamic workflows로 38대의 AI에게 게임을 찾게 했더니, '재미있다'는 판정만은 기계화할 수 없었다

Claude Code의 dynamic workflows를 사용하여, 수십 대의 에이전트(Agent)에게 '세계 최초의 게임 경험'을 탐색하게 했습니다. 본 기사는 실제로 작성한 정리 스크립트, 실행 시의 수치, 잘된 점과 아쉬웠던 점을 기록한 것입니다. 최종적으로 어떤 방향으로 제작을 시작했는지도 작성하겠습니다.

TL;DR

• Claude Code의 dynamic workflows를 구현이나 리뷰가 아닌 새로운 게임 아이디어 탐색에 사용했습니다. 폭넓게 안을 내고 엄격하게 좁히는 방식이 아이디어 도출에 적합하다고 생각했기 때문입니다.
• 구성한 것은 조사·발명·선별·채점·설계의 5단계 파이프라인입니다. 각 단계의 출력은 JSON Schema로 고정하였으며, 한 차례에는 에이전트 38대로 19개의 안을 좁혔고, 16개의 안이 통과되어 6개의 안을 설계 단계까지 진행했습니다.
• 가장 큰 배움은 실패로부터 얻었습니다. '객관적인 세계 최초인가'를 기계가 판정하도록 설계한 것은 통과 사례가 0건이었고, 판정 축을 '체감상 전대미문인가'로 다시 만들었습니다.
• 다중 에이전트(Multi-agent)는 안을 넓히고 기계적으로 좁히는 데는 강력했으나, 무엇을 재미있다고 느낄 것인가라는 마지막 수렴은 인간의 몫으로 남았습니다.

서론

평소에는 HD-2D 탐색 어드벤처 Anemora를 AI 중심의 개인 개발로 만들고 있습니다. 다만 Anemora는 그래픽 작업이나 HD-2D화와 같은 무거운 작업이 계속되는 국면이 많아, 시간을 들여 길게 함께해야 하는 작품이라고 생각합니다. 그 사이에 좀 더 가볍게 만들 수 있고 짧게 출시할 수 있는 작은 게임이나 앱, 툴도 병행해서 내놓을 생각이라, 우선 다음에 무엇을 만들지 찾는 것부터 AI의 도움을 받을 수 없을까 생각했습니다.

마침 Claude Code에 dynamic workflows가 도입되었기에, 한 대의 채팅으로 대화하는 것이 아니라 수십 대의 에이전트에게 서로 다른 각도에서 안을 내게 하고, 또 다른 수십 대에게 엄격하게 평가하게 하는 방식을 시도했습니다. 이는 dynamic workflows의 시험과 새로운 게임 아이디어 탐색을 겸한 사색의 기록입니다.

참고로 탐색의 인자나 에이전트에 대한 프롬프트(Prompt)에는 제 정보나 기존 프로젝트의 정보를 일절 넣지 않았습니다. 안전성 측면의 처리는 뒤쪽의 비용과 가드(Guard) 섹션에서 정리하겠습니다.

dynamic workflows란

dynamic workflows는 2026년 5월 Claude Opus 4.8과 동시에 공개된 프리뷰 버전 기능입니다. 정식 버전이 아니며, 이용을 위해서는 대응 버전의 Claude Code와 유료 플랜이 필요합니다. 프롬프트에 workflow라는 단어를 넣거나 /effort ultracode를 세션에 설정하면, Claude가 JavaScript 정리 스크립트를 그 자리에서 작성하고, 분리된 런타임(Runtime)이 백그라운드에서 에이전트를 구동합니다.

요점을 정리합니다.

• 1회 실행 시 기동할 수 있는 것은 최대 1,000대이며, 동시에 돌아가는 것은 최대 16대입니다. 이를 초과하는 분량은 슬롯이 비기를 기다렸다가 순차적으로 실행됩니다.
• 중간 결과는 스크립트의 변수에 유지되며, 최종 결과만 세션으로 돌아옵니다. 중간의 방대한 출력으로 인해 메인 컨텍스트(Context)가 오염되는 것을 방지할 수 있습니다.
• /workflows로 실행 상황을 페이즈(Phase)나 에이전트 단위까지 추적할 수 있으며, 일시 정지나 정지도 가능합니다. 토큰 소비는 일반적인 세션보다 크게 늘어납니다. 스케일을 키우기 전에 작게 돌려보며 기준을 잡는 것이 무난합니다.

적재적소의 활용이 중요합니다. LLM의 판단으로 엄격한 참/거짓이나 수치 일치를 보장해야 하는 용도, 예를 들어 바이트 열의 일치나 엄격한 계측에는 적합하지 않습니다. 확률적인 판단을 다단계로 겹치면 재현성이 떨어지기 때문입니다. 한 대의 에이전트로 충분한 작은 수정에 사용하는 것도 과합니다. 반대로, 독립된 관점에서의 리뷰나 반증 찾기, 대규모 규약 스캔, 기계적인 이행, 조사, 그리고 이번 아이디어 탐색과 같이 폭넓게 찾고 묶어서 좁히는 작업에는 매우 잘 맞습니다.

왜 아이디어 도출에 다중 에이전트를 사용했는가

아이디어 도출을 한 대의 채팅으로 하면 처음에 나온 방향으로 끌려가기 쉽습니다. 다중 에이전트를 사용한 목적은 두 가지였습니다.

• 발산의 폭을 넓히는 것. 각도를 나누어 서로 다른 에이전트에게 발명을 시키면, 하나의 대화에서는 나올 수 없는 방향까지 모집단이 확장됩니다.
• 발산과 평가를 분리하는 것. 안을 내는 에이전트와 그것을 엄격하게 평가하는 에이전트를 나누면, 자신이 낸 안을 스스로 너그럽게 평가하는 유착 관계를 구조적으로 끊을 수 있습니다.

이 두 가지를 그대로 형태화하면, 다음과 같은 5단계 파이프라인이 됩니다.

구성한 파이프라인

페이즈 1: 조사와 발명을 동시에 실행

첫 번째 페이즈에서는 두 종류의 에이전트 (Agent)를 동시에 실행했습니다. 한쪽은 Web을 조사하여 현재 어떤 AI 네이티브 (AI-native) 게임이나 실험이 이미 존재하는지를 4가지 관점에서 지도로 만드는 정찰병 역할입니다. 다른 한쪽은 새로운 동사, 새로운 승리 조건, 새로운 대전 상대, 새로운 소재라는 8가지 관점에서 각각 5개씩 새로운 게임 형식을 발명하는 역할입니다.

dynamic workflows (동적 워크플로우)에는 여러 가지 구성 방식이 있지만, 여기서는 일부러 모든 결과를 기다리는 parallel()를 사용했습니다. 다음 선별 페이즈에서 모든 안건과 모든 지도를 한꺼번에 살펴볼 필요가 있기 때문입니다.

const firstBatch = await parallel([
...MAP_ANGLES.map((a, i) => () =>
agent(mapPrompt(a), { label: `map:${i}`, phase: 'Map', schema: MAP_SCHEMA })),
...

정찰병을 포함시킨 이유는 후반 단계에서 기존 사례와의 충돌을 줄이기 위해 이미 존재하는 것을 알고 있을 필요가 있었기 때문입니다. 발명만 시키면 에이전트는 이미 존재하는 것을 아무렇지 않게 신발명이라고 내놓곤 합니다.

출력을 JSON Schema로 고정하기

각 페이즈의 출력은 자유 문장이 아니라 JSON Schema를 전달하여 형식을 고정했습니다. 스키마를 전달하면 에이전트는 구조화된 출력 (Structured Output)으로 반환하도록 요구받으며, 검증은 실행 환경 측에서 수행됩니다. 이로 인해 본문을 직접 파싱하며 실패를 처리해야 하는 번거로움이 사라집니다.

채점 페이즈의 스키마는 다음과 같이 구성했습니다.

const JUDGE_SCHEMA = {
type: 'object',
properties: {
...

기준을 모든 프롬프트에 주입하기

발명·선별·채점·설계의 모든 프롬프트에 동일한 기준 문자열을 서두에 삽입했습니다. 흔한 도구, 기존 장르의 변종, 챗봇, AI만 붙인 평범한 게임은 기각한다는 상당히 엄격한 기준입니다. 동일한 기준을 모든 공정에서 공유하게 함으로써 에이전트마다 평가 축이 흔들리는 것을 억제할 수 있습니다.

채점은 우선 기각을 전제로 병렬 실행

채점은 안건마다 별도의 에이전트에게 병렬로 던졌으며, 프롬프트 서두에 "우선 기각을 기본값으로 설정하라. 대부분의 것은 세계 최초도 신형식도 아니다. 그렇게 단언하라"라고 지시했습니다. 임계값 (Threshold)도 명시하여, 여러 축이 모두 높은 점수를 받았을 때만 passes를 참 (True)으로 설정했습니다.

const judged = await parallel(candidates.map((c, i) =>
() => agent(judgePrompt(c), { label: `judge:${i}`, phase: 'Judge', schema: JUDGE_SCHEMA })
.then((v) => v
...

발명 역할과 채점 역할을 분리하고 채점 역할을 엄격하게 설정한 결과, 재미있을 것 같은 분위기만 풍기는 안건들이 상당수 탈락했습니다.

설계와 누락 방지 대책

마지막으로 상위 안건만을 설계 페이즈로 넘겨, 한 명의 제작자가 이번 달부터 만들기 시작해서 첫 1주일 안에 실제로 플레이할 수 있는 최소한의 형태는 무엇인지까지 구체화하게 했습니다. 설계 에이전트가 실패하더라도 전체 프로세스가 멈추지 않도록, 실패한 프레임은 채점까지의 정보로 채우는 구조로 만들었습니다. 반환값에는 승자뿐만 아니라 차점자, 기각 이유의 예시, 발견된 공백 영역, 통계도 포함하여 나중에 인간이 다시 읽어볼 수 있는 형태로 구성했습니다.

실제로 돌려본 결과

처음으로 돌려본 것은 AI 네이티브한 새로운 표현이나 지성의 형식을 찾는 버전이었습니다. 이번 회차에서는 에이전트가 총 38대 움직였고, 제안된 안건을 19개까지 압축했으며, 그중 16개가 기준을 통과하여 상위 6개 안건이 설계 단계까지 진행되었습니다. 통과한 대표적인 사례들입니다. 모두 에이전트가 제안한 것입니다.

Provenance: 독자가 어디에서 머무르고 어디를 다시 읽었는지 관찰한 후, 이미 읽은 장을 거슬러 올라가 개정하는 소설. 연속성을 유지하면서 첫 독서 시에는 없었던 복선을 나중에 심어둠 -
Liar's Theater: 여러 에이전트가 작가조차 모르게 사적으로 공모하여 범인과 겉으로 드러낼 이야기를 결정하며, 플레이어는 며칠 분량의 대화 로그 속 모순을 찾아내 거짓을 무너뜨림 -
The Disagreement: 서로 용납할 수 없는 미학을 가진 두 존재가 하나의 캔버스를 두고 다툼. 중재도 결론도 없이, 교착 상태 그 자체가 작품이 됨

다음으로, 대상을 게임으로 좁힌 버전을 돌렸습니다. 이 제1탄에서는 8개 안 중 4개 안이 통과했지만, 여기서 제가 전부 "어딘가에서 본 것 같다"며 기각(reject)을 냈습니다. AI 형사를 심문하는 안도, 절벽 끝의 인간을 대화로 진정시키는 안도, 기존 작품의 조상을 즉시 지목할 수 있었기 때문입니다.

여기서 효과적이었던 점과 실수했던 점

도구(tool)를 구성함에 있어, 되돌아봤을 때 효과적이었던 점은 다음과 같습니다.

• 발명 역할과 채점 역할의 분리. 같은 모델이라도 역할과 프롬프트 (prompt)를 나누어 두면, 서로 유착되지 않고 자신의 안을 엄격하게 검토합니다.
• 출력 형식 (output format)의 고정. 본문을 파싱 (parsing)하지 않으므로, 집계, 정렬, 임계값 판정 (threshold判定)을 단순한 JavaScript로 작성할 수 있습니다.
• 대기 지점 (wait)은 필요한 곳으로 압축. 전체 건을 모아서 보는 선별 단계 직전에 조사와 발명을 대기시키고, 채점과 설계는 안마다 병렬로 실행하여, 탈락한 안만 놓치지 않도록 구성했습니다.

실수했던 점으로부터 얻은 배움이 더 컸습니다.

"객관적인 세계 최초"를 기계가 판정하게 하려다 헛스윙했다

도중에, 유사한 기존 작품을 하나라도 지목하면 실격이라는 별도의 버전의 탐색을, 최대 24개 관점·144개 안 규모로 돌렸습니다. 전용 조상 헌터 (ancestor hunter) 에이전트 (agent) 에게 하나하나 대조하게 했더니, 통과한 안은 제로였습니다.

이것은 설계의 오류였습니다. 모든 창작은 기존 요소의 재조합이기에, 조상이 제로인 상태는 원리적으로 달성할 수 없습니다. 바둑도 장기도 무언가의 변형이라고 말할 수 있습니다. 올바른 판정 축은 학자가 분해할 수 있느냐가 아니라, 플레이어가 체감으로서 전대미문의 것이라고 느끼느냐였습니다. 다중 에이전트 (multi-agent)에게 맡길 수 있는 것은 전자의 기계적인 대조까지이며, 후자는 별도의 평가로서 인간에게 남습니다.

언어를 커트라인 조건으로 삼으면 발상이 왜곡된다

또 다른 실패는, 제가 입 밖으로 낸 말을 추출하여 채점의 커트라인 조건으로 고정해 버린 것입니다. 예를 들어 "무한한 가능성"이라는 완만한 표현을, 에이전트가 수학적인 무한이나 숭고함 같은 딱딱한 제약으로 과도하게 해석하여, 안이 한 방향으로 왜곡되었습니다. "감동" 또한 경외나 숭고가 아니라, 사실은 충격과 환희, 남에게 보여주고 싶어지는 즐거움이었습니다.

교훈으로서, 판정 축을 언어로 꽉 묶어두지 않는 편이 결과적으로 좋은 모집단을 만들어냅니다. 이는 프롬프트 설계의 문제인 동시에, 무엇을 최적화(optimization)시키고 있는지를 오해하면 다중 에이전트는 전력을 다해 잘못된 방향으로 달려간다는 이야기이기도 합니다.

비용과 가드 (Guard)

dynamic workflows의 토큰 (token) 소비는 상당히 커집니다. Anthropic도 공식적으로 일반적인 세션보다 훨씬 많은 토큰을 사용한다고 명시하고 있습니다. 실제로 에이전트 38대로 돌린 이번 회차는, 워크플로우 실행 로그에 남는 totalTokens 값으로 총 토큰 약 100만 개였습니다. 첫 번째는 작게 돌려 기준을 잡고, 소비를 억제하는 운용 방식도 별도로 시도하고 있는 중입니다.

그리고 탐색 프롬프트에는 저의 정보나 기존 프로젝트의 정보를 일절 넣지 않는 방침을 세우고 있습니다. 한 번은 다른 조사에서 저의 컨텍스트 (context) 를 인자 (argument) 로 포함해 버렸더니, 다수의 에이전트와 웹 검색 (web search) 컨텍스트로 확산된 적이 있었습니다. 이것으로 완벽하게 누출을 막을 수 있는 것은 아니지만, 해당 단어를 포함하는 도구 호출 (tool use) 을 멈추는 보조선으로서 PreToolUse 훅 (hook) 을 넣었습니다. 탐색 자체가 일반적인 토픽 단어만으로 완결되는 설계라면, 가드에 걸리지 않고 돌아갑니다.

탐색의 출구 — 마지막 수렴은 인간에게 남았다

여기까지를 통해 알 수 있었던 것은, 다중 에이전트는 안의 모집단을 넓히고 기계적으로 압축하는 단계까지는 확실히 강력하다는 점입니다. 반면, 결국 무엇을 만들 때 자신이 재미있을 것인가라는 마지막 수렴은, 몇 번을 돌려도 인간에게 남았습니다. 판정 축을 새로 만든 것도, 기각을 낸 것도, 최종적으로 방향을 결정한 것도 인간입니다.

최종적으로 만들기 시작한 것은 에이전트가 내놓은 안 그 자체가 아니라, 탐색 도중에 제가 붙잡은 동사였습니다. "넘기다"와 "라벨"을 축으로 한 1인칭 3D 퍼즐입니다. 모든 물건에는 정체와 성질을 나타내는 숨겨진 라벨 뭉치가 있으며, 그것을 넘겨서 벗겨내고, 붙이고, 교체함으로써 세계를 물리적으로 다시 만듭니다. 내용은 LLM을 사용하지 않는, 순수한 결정론적 (deterministic) 퍼즐로 구성하고 있습니다.

다른 하나는 AI를 기구 그 자체에組み込む(組み込む, 내장하는) 시도로, 이 또한 사양을 진행 중입니다. 억울한 용의자의 시점에서 AI 형사의 심문을 버텨내는, 입장을 반전시킨 게임입니다. 진실이나 상태, 승패는 결정론적인 뼈대가 담당하고, LLM은 발화를 사실에 비추어 해석하는 역할과 대사에 맛을 입히는 역할으로만 한정하고 있습니다. 진위 판정은 어디까지나 코드가 내린다는 선은 무너뜨리지 않습니다.

둘 다, 본격적으로 만드는 Anemora와는 별개로, 틈틈이 가볍게 진행할 수 있는 작은 제작 프레임워크로 두고 있습니다.

마치며

dynamic workflows (동적 워크플로우)를 아이디어 탐색에 사용해 보면서 명확해진 것은 역할 분담이었습니다. 다중 에이전트 (Multi-agent)로 일제히 실행하는 방식은, 폭넓게 안을 내놓는 발산 (Divergence)과, 이미 나온 것을 제외하고 임계치로 걸러내는 기계적인 수렴 (Convergence)에 효과적입니다. 반대로, 무엇이 재미있는가라는 가치 판단과, 체감상 새로운가라는 신규성 (Novelty)의 평가는 도구에게 대신 시키려 할수록 왜곡되었습니다. 그 부분은 인간에게 남겨두고, 도구에는 모집단 형성(Population building)과 필터링을 맡기는 선긋기가 현재로서는 가장 적절하게 느껴집니다.

동일한 AI 중심의 개인 개발에 대해서는, 제작 지원 도구를 즉석에서 구축하는 이야기나 인간이 놓지 않았던 3가지 업무에 대해서도 작성했습니다. 이번 탐색을 통해 만들기 시작한 게임에 대해서는, 형태가 갖춰지면 다시 별도의 글로 작성할 예정입니다.

Discussion