나는 게임 큐레이션을 그만두었다. 대신 내 포털을 운영할 AI 에이전트를 구축했다.

상상해 보세요: 당신은 게임 포털을 만들고 싶습니다. 게임을 찾아야 하고, 플레이 테스트를 하고, 카테고리를 분류하고, 설명을 작성하고, 썸네일을 추출하고, 게시해야 합니다. 이는 엄청난 병목 현상(bottleneck)입니다.

이번 달 초 minigames.world를 구축하기 시작했을 때, 저는 단순히 또 다른 디렉토리를 만들고 싶지 않았습니다. 저는 스스로 관리되는 시스템을 구축하고 싶었습니다.

제가 모든 데이터 입력을 수행하는 전통적인 CRUD 애플리케이션 대신, AI가 전체 게임 포트폴리오를 자율적으로 분석, 큐레이션 및 관리하는 에이전트 아키텍처 (agentic architecture)를 구축했습니다. 여기서는 아키텍처가 어떻게 작동하는지, 제가 선택한 기술 스택 (tech stack)은 무엇인지, 그리고 왜 AI 에이전트가 시스템 설계 (system design)를 근본적으로 바꾸고 있는지에 대해 자세히 설명하겠습니다.

문제점: 기능으로서의 AI vs 오케스트레이터 (Orchestrator)로서의 AI
대부분의 애플리케이션은 AI를 API 호출로 취급합니다. 즉, 텍스트를 보내면 텍스트를 돌려받는 방식입니다.

자율적인 플랫폼을 구축하려면 AI가 단순한 기능이어서는 안 됩니다. AI는 오케스트레이터 (orchestrator)가 되어야 합니다. 에이전트는 게임을 가져오고, 메커니즘을 분석하고, 장르를 결정하며, 품질 표준을 충족하는지 판단하고, 게시를 위한 데이터베이스 업데이트를 실행할 수 있어야 합니다.

아키텍처: 컨텍스트 (Context), 제어 (Control), 그리고 동시성 (Concurrency)

자율 에이전트를 실행하려면 대규모 동시성 (concurrency)과 결함 허용 (fault tolerance)을 처리할 수 있는 백엔드가 필요합니다. 만약 에이전트가 무거운 WebGL 게임을 분석하는 동안 멈춘다면, 시스템 전체가 다운되어서는 안 됩니다. 이 때문에 저는 Erlang과 BEAM 생태계에 크게 의존합니다. 액터 모델 (actor model)은 에이전트 워크플로우 (agentic workflows)에 독보적으로 적합합니다. 각 AI 에이전트는 격리된 경량 프로세스로 실행될 수 있습니다. 만약 에이전트가 게임의 메타데이터를 파싱하는 데 실패하거나 API 호출에서 타임아웃이 발생하더라도, 슈퍼바이저 (supervisor)가 나머지 오케스트레이션 레이어 (orchestration layer)에 영향을 주지 않고 단순히 에이전트를 재시작합니다.

다음은 에이전트가 실행하는 기본 워크플로우입니다:

1. Discovery & Ingestion (발견 및 수집): 워커 프로세스(worker process)가 소스 피드(source feed)에서 새로운 게임을 식별합니다.
2. Agent Analysis (에이전트 분석): 핵심 에이전트가 개입합니다. 제공된 메타데이터(metadata)를 평가하고, 게임의 에셋(assets)을 파싱(parse)하며, 데이터를 구조화합니다.
3. Curation Gate (큐레이션 게이트): 이것은 제어 계층(control layer)입니다. 에이전트는 일련의 품질 휴리스틱(quality heuristics)에 따라 게임을 평가합니다. 통과하면 에이전트가 이를 분류합니다.
4. Publication (발행): 에이전트가 데이터베이스(database)에 새로운 항목을 커밋(commit)합니다.

Serving it Fast: Heavy Frameworks를 뒤로하고

백엔드(backend)가 AI 에이전트의 복잡한 오케스트레이션(orchestration)을 처리하는 동안, 프론트엔드(frontend)는 공격적으로 최적화되어야 합니다. 게이머들은 즉시 클릭하고 플레이하기를 원합니다.

저는 무거운 클라이언트 사이드 JavaScript 프레임워크(client-side JavaScript frameworks)를 건너뛰었습니다. 프론트엔드는 순수한 성능을 위해 구축되었으며, Astro를 통해 사전 렌더링된 정적 구조(pre-rendered static structures)를 제공하고 HTMX를 통해 동적인 클라이언트 상호작용(dynamic client interactions)을 관리합니다. 이를 통해 상호작용 가능 시간(time-to-interactive)을 믿을 수 없을 정도로 낮게 유지하며, 플랫폼의 SEO 구조가 검색 엔진에 의해 쉽게 크롤링(crawlable)될 수 있도록 보장합니다.

Agentic System을 구축하며 배운 점

minigames.world를 구축하면서 가장 어려웠던 점은 AI 프롬프팅(prompting)이 아니라, 이를 둘러싼 아키텍처(architecture)였습니다. AI 에이전트는 작업을 오해했을 때 표준 에러(standard errors)를 던지는 대신, 자신 있게 잘못된 형식을 출력합니다. 따라서 시스템을 방어적으로 설계해야 합니다. 엄격한 데이터 검증 계층(data validation layers)을 구축하고 Erlang과 같이 견고하고 동시성을 지원하는 백엔드 기술을 활용하면, AI가 예측 불가능하게 행동하더라도 시스템의 안정성을 유지할 수 있습니다.

그 결과는 어떨까요? 제가 엔진을 개선하는 데 집중하는 동안, 스스로 포트폴리오를 큐레이션하는 게임 포털이 탄생했습니다.

에이전트가 작업한 실제 결과물을 여기에서 확인해 보세요: minigames.world. 다른 개발자들은 프로덕션(production) 환경에서 다단계 에이전트 워크플로우(multi-step agent workflows)를 어떻게 처리하고 있는지 정말 궁금합니다!