Grues in Comic: AI 에이전트가 클래식 게임을 다시 엮는 법

1980년대 텍스트 어드벤처와 1990년대 만화 채팅 클라이언트를 합치면 어떤 게임이 될까요? GeekNews에 올라온 Grues in Comic 소개 ↗는 이 질문에 꽤 멋진 답을 보여줍니다. 플레이어는 여전히 north, take lamp 같은 명령어를 입력하지만, 결과는 텍스트 스크롤이 아니라 Comic Chat 스타일의 만화 패널로 렌더링됩니다.

먼저 결론부터 말하면, 이 프로젝트의 흥미로운 지점은 “AI가 코드를 다 썼다”가 아닙니다. 오래된 원작을 직접 이식하지 않고, 임포터, IR, 엔진, 렌더러, 회귀 테스트로 나눈 구조가 있었기 때문에 AI 에이전트가 끝까지 달릴 수 있었습니다.

기준 작성 시점 2026-08-06 · GeekNews 소개 글, 제작기, historicalsource/zork1 README, microsoft/comic-chat README 스냅숏 기준입니다. Grues in Comic 저장소는 아직 비공개라고 밝히고 있으므로, 내부 구현 세부는 공개 글에 나온 범위로만 다룹니다.

Grues in Comic에서 Zork의 West of House와 Living Room 장면이 Comic Chat 스타일 만화 패널로 표시된 스크린샷

이 글에서 다루는 내용:

Zork와 Comic Chat이 왜 이상하게 잘 맞는 조합인지
Grues in Comic이 원작 이식 대신 계층 분리를 택한 이유
AI 에이전트 개발에서 검증 하네스가 어떤 역할을 하는지

두 클래식의 접점

Zork I 저장소 README ↗는 Zork I을 1980년에 Infocom이 발행한 interactive fiction 게임으로 설명합니다. 저장소에 공개된 소스는 ZIL(Zork Implementation Language)로 작성되어 있고, 연구와 교육 목적의 역사적 소스 아카이브에 가깝습니다.

반면 Comic Chat 저장소 README ↗는 Comic Chat을 1996년에 나온 IRC 클라이언트로 설명합니다. 사용자가 입력한 대화를 만화 패널, 캐릭터 포즈, 표정, 말풍선으로 자동 구성하는 것이 핵심이었습니다.

둘은 원래 연결될 이유가 없습니다. 하나는 파서 기반 텍스트 게임이고, 하나는 채팅 로그를 만화로 바꾸는 렌더러입니다. 그런데 Grues in Comic은 바로 그 차이를 이용합니다. Zork의 플레이 결과를 “대화 이벤트”처럼 보고, Comic Chat의 렌더링 문법으로 다시 보여주는 방식입니다.

프로젝트는 현재 grues.danielkimdev.com ↗에서 퍼블릭 베타로 공개되어 있습니다. 다만 저장소는 아직 비공개이므로, 이 글에서는 공개 소개 글과 제작기에 나온 구조만 기준으로 삼습니다.

flowchart TD
    A[플레이어 명령]
    B[Zork식 파서와 월드]
    C[게임 이벤트]
    D[Comic Chat식 렌더러]
    E[만화 패널]

    A --> B --> C --> D --> E

이 조합이 좋은 이유는 단순히 “옛날 것 두 개를 섞었다”가 아닙니다. 텍스트 어드벤처의 가장 강한 부분인 명령 기반 상호작용은 그대로 두고, 가장 높은 진입 장벽인 텍스트 출력만 시각화합니다.

핵심은 이식이 아니라 번역입니다

제작자는 Grues in Comic 제작기 ↗에서 원작 Zork와 Comic Chat을 브라우저에 그대로 이식하지 않았다고 밝힙니다. Zork는 ZIL, Comic Chat은 오래된 C++ 코드라서, 둘을 그대로 웹 런타임에 올리는 것이 목표가 아니었습니다.

대신 구조는 네 계층으로 나뉩니다.

계층	역할
임포터	Zork I의 ZIL 소스를 파싱해 AST로 변환
IR	ZIL이나 특정 런타임에 묶이지 않는 중간 표현
엔진	TypeScript로 IR을 실행하며 월드 상태, 파서, 전투, 저장/불러오기를 처리
렌더러	엔진 이벤트를 Comic Chat 방식의 패널, 포즈, 말풍선으로 변환

여기서 IR(Intermediate Representation, 중간 표현)이 중심입니다. 원작 소스를 직접 실행하지 않고, 원작의 동작 방식을 브라우저 친화적인 독립 계층으로 옮깁니다. 이 설계 덕분에 TypeScript 엔진은 Zork의 게임 규칙을 실행하고, 렌더러는 그 결과만 받아 만화 장면을 만들 수 있습니다.

Tip 오래된 시스템을 AI 에이전트로 다룰 때는 "그대로 포팅"보다 "관찰 가능한 중간 표현으로 번역"이 더 안정적인 출발점이 될 때가 많습니다. 에이전트가 수정할 표면을 작게 만들고, 검증할 경계를 분명히 만들기 때문입니다.

AI가 코드를 썼다는 말보다 중요한 것

Grues in Comic 소개 글은 임포터, IR, 엔진, 정합성 검증까지 전부 AI 에이전트가 작성했고, 제작자는 방향성과 요구사항을 정하고 직접 플레이하며 테스트했다고 밝힙니다. 이 문장만 떼어놓으면 “100% vibe coding으로 만든 게임”처럼 보일 수 있습니다. 물론 이는 제작자의 자기 보고이며, 저장소와 작업 로그가 공개된 상태는 아닙니다.

하지만 이 사례를 그렇게만 읽으면 중요한 부분을 놓칩니다. 실제로는 사람이 코드 한 줄을 직접 작성하지 않았다는 사실보다, 사람이 검증 가능한 구조를 정했다는 사실이 더 중요합니다.

제작기 ↗에 따르면 원작과의 정합성은 frotz 인터프리터로 뽑은 Zork 플레이 공략을 기준 데이터로 삼아, 엔진 실행 결과를 한 줄씩 비교하는 방식으로 확인했습니다. 게임 결말인 스톤 배로우까지 도달하는 전체 플레이 시나리오도 회귀 테스트로 고정했다고 설명합니다.

flowchart TD
    A[Zork 소스]
    B[임포터]
    C[IR]
    D[TypeScript 엔진]
    E[엔진 출력]
    F[frotz 기준 출력]
    G{비교}
    H[통과]
    I[수정 루프]

    A --> B --> C --> D --> E --> G
    F --> G
    G -->|일치| H
    G -->|불일치| I --> D

이 흐름은 제가 이전에 다룬 AI 엔지니어링의 5계층 중 하네스와 평가 계층에 가깝습니다. 또 장시간 앱 개발용 하네스 설계에서 본 generator-evaluator 루프와도 닮아 있습니다. 모델이 코드를 쓰더라도, 무엇이 맞는지 판단하는 기준은 바깥에서 만들어야 합니다.

왜 이 사례가 개발자에게 의미 있나

Grues in Comic은 큰 회사의 제품 발표가 아니라 개인 사이드 프로젝트입니다. 그런데 오히려 그래서 개발자에게 더 실감나는 사례입니다. 팀이나 예산보다 중요한 것은 “문제를 에이전트가 풀 수 있는 형태로 바꾸는 능력”이라는 점을 보여주기 때문입니다.

여기서 사람의 역할은 세 가지로 바뀝니다.

첫째, 아이디어를 연결합니다. GeekNews의 관련 글 추천에서 Zork와 Comic Chat을 나란히 보고, 서로 다른 시대의 두 프로젝트 사이에 인터페이스를 상상했습니다.

둘째, 경계를 나눕니다. 임포터, IR, 엔진, 렌더러라는 계층은 에이전트가 작업을 나눠 처리할 수 있는 단위입니다. 이 구조가 없었다면 “Zork를 Comic Chat처럼 보여줘”라는 요청은 너무 흐릿했을 겁니다.

셋째, 검증 기준을 만듭니다. frotz 기준 출력과 전체 플레이 회귀 테스트는 에이전트가 만든 코드가 원작 동작을 깨뜨렸는지 확인하는 기준선입니다.

주의 이 사례를 "코드를 몰라도 복잡한 게임을 만들 수 있다"로 일반화하면 위험합니다. 공개 글에서 확인되는 성공 요인은 코드 작성의 부재가 아니라, 원작 분석, 계층 분리, 기준 데이터, 직접 플레이 테스트가 함께 있었다는 점입니다.

에이전트 시대의 사이드 프로젝트 문법

이 프로젝트가 특히 재미있는 이유는 AI 에이전트가 새 아이디어를 무에서 만들었다기보다, 이미 공개된 문화적/기술적 자산을 새 인터페이스로 다시 엮었다는 점입니다. Zork I 저장소 ↗는 역사적 소스 코드를 연구할 수 있게 열어두고, Comic Chat 저장소 ↗는 만화 패널 렌더링이라는 독특한 UI 실험을 다시 볼 수 있게 합니다. Grues in Comic은 그 사이에 새 실행 계층을 끼워 넣었습니다.

이런 프로젝트에서 AI 에이전트는 “작업자”에 가깝습니다. 사람이 연결할 재료를 고르고, 계층을 나누고, 통과 기준을 정하면 에이전트가 많은 구현 시도를 빠르게 밀어붙입니다. 이 관점은 Claude Code Dynamic Workflows에서 다뤘던 병렬 실행과 검증의 방향과도 이어집니다. 차이는 규모입니다. 대규모 마이그레이션이 아니라 개인 베타 게임에서도 같은 사고방식이 작동합니다.

저는 이 흐름이 앞으로 사이드 프로젝트의 문법을 바꿀 거라고 봅니다. “내가 직접 다 구현할 수 있는가?”보다 “내가 이 아이디어를 검증 가능한 작은 시스템으로 쪼갤 수 있는가?”가 더 중요한 질문이 됩니다.

마무리

Grues in Comic은 Zork와 Comic Chat이라는 두 클래식을 합친 브라우저 게임입니다. 하지만 개발 관점에서 보면 더 큰 메시지가 있습니다. AI 에이전트 시대의 개발은 코드 타이핑을 줄이는 이야기가 아니라, 문제를 계층화하고, 실행 결과를 검증하고, 루프를 설계하는 이야기로 이동하고 있습니다.

코드는 에이전트가 많이 쓸 수 있습니다. 그러나 어떤 경계로 나눌지, 무엇을 기준으로 맞다고 할지, 어떤 경험으로 보여줄지는 여전히 사람이 정해야 합니다. 이 프로젝트가 좋은 사례인 이유가 바로 거기에 있습니다.

참고 자료

GeekNews: Grues in Comic 소개 ↗ — 프로젝트 개요와 제작 방식
Zork와 Comic Chat, 두 개의 클래식 오픈소스 프로젝트를 하나의 게임으로 ↗ — 제작자의 상세 베타 공개 글
historicalsource/zork1 ↗ — Zork I 역사적 소스 코드 저장소
microsoft/comic-chat ↗ — Microsoft Comic Chat 소스 코드 저장소