ASCII 도시 한 파일, 경량 웹 엔진의 반격

한 파일짜리 도시는 장난감이 아니라 배포 전략이다

A Walkable ASCII Cyberpunk City in One HTML File은 제목 그대로 하나의 HTML 파일에 걷는 ASCII 사이버펑크 도시를 담은 영상이다. 영상 설명은 JavaScript와 Canvas API로 만든 작은 커스텀 엔진이며, Unity, Unreal, 3D 모델, 텍스처, 셰이더 없이 격자 도시와 도로, 건물, 나무, 자동차, 보행자를 표현한다고 설명한다. 프로토타입 페이지도 별도로 공개되어 있다.

이 실험이 AI 뉴스로 읽히는 이유는 결과물의 소재보다 제작 방식 때문이다. 코딩 에이전트와 생성형 도구가 널리 쓰일수록 웹 결과물은 점점 더 큰 의존성, 더 많은 빌드 단계, 더 복잡한 배포 파이프라인으로 흐르기 쉽다. 반대로 한 파일짜리 HTML은 수정, 복사, 검토, 저장, 실행이 모두 단순하다. AI가 코드를 많이 쓰는 시대에는 이 단순함이 오히려 품질 관리 방식이 된다.

HTML의 귀환, 자바스크립트 피로가 만든 신호는 브라우저 기본 기능을 다시 신뢰하는 흐름을 짚었다. ASCII 도시도 같은 맥락에 있다. 더 큰 프레임워크가 아니라 더 작은 실행 단위를 선택하면, 사용자는 결과물을 즉시 열어보고 코드의 전체 모양을 파악할 수 있다.

Canvas와 ASCII가 만나는 지점

ASCII 그래픽은 오래된 표현 방식이지만 웹에서는 새로운 장점이 있다. 텍스트 기반 시각 요소는 파일 크기가 작고, 스타일 변형이 쉽고, 저사양 장치에서도 빠르게 렌더링될 수 있다. 여기에 Canvas를 붙이면 텍스트처럼 보이는 장면도 매 프레임 다시 그릴 수 있다. MDN의 Canvas 튜토리얼은 2D 렌더링의 기본 구조를 설명하고, requestAnimationFrame은 브라우저 애니메이션 루프의 표준 도구다.

중요한 것은 기술의 낡고 새로움이 아니다. ASCII는 제약이 분명하기 때문에 디자인 결정을 강제한다. 텍스처를 고르는 대신 문자 밀도, 원근, 명암, 이동 속도, 입력 반응을 설계해야 한다. AI 코딩 도구가 프로젝트를 빠르게 확장하는 상황에서 이런 제약은 결과물을 작게 유지하는 안전장치가 된다.

AI 시대의 작은 엔진은 검토하기 쉽다

생성형 코딩에서 가장 어려운 일은 코드를 만드는 것이 아니라 만든 코드를 이해하고 책임지는 일이다. 작은 HTML 파일은 이 점에서 강하다. 모델이 만든 함수, 렌더 루프, 입력 처리, 좌표 계산이 한 화면의 맥락 안에 남는다. 보안 검토도 상대적으로 단순하다. 외부 패키지, 빌드 플러그인, 원격 로더가 줄어들면 공급망 위험도 줄어든다.

Soup Raiders 엔진 전환, AI 시대에도 손수 만든 기술은 남는다는 커스텀 엔진이 단순한 취향이 아니라 제작 통제권의 문제라고 봤다. ASCII 도시는 그 축소판이다. 모든 팀이 자체 엔진을 만들 필요는 없지만, 아이디어 검증 단계에서는 도구의 무게가 상상력을 누르지 않아야 한다.

웹 표준도 이 방향을 돕는다. WebGL은 더 깊은 그래픽을 가능하게 하고, WebGPU는 브라우저에서 GPU 계산을 다루는 다음 층을 연다. 하지만 이번 사례의 흥미로운 점은 최신 GPU API가 아니라 Canvas와 문자만으로도 충분히 설득력 있는 공간감을 만들 수 있다는 데 있다.

한국 개발자에게 주는 신호

한국의 개인 개발자와 소규모 스튜디오는 AI 코딩 도구를 빠르게 받아들이고 있지만, 결과물을 유지하는 비용도 함께 늘고 있다. 짧은 데모, 교육용 시뮬레이션, 사내 프로토타입, 행사 설치물이라면 Next.js 전체 앱보다 한 파일 웹앱이 더 나은 선택일 수 있다. 특히 보안 정책이 엄격한 조직에서는 외부 패키지 없는 HTML 파일이 리뷰와 반입 절차를 줄인다.

코드로 그림 그리는 AI, RL의 보상은 디자인 문제다는 코드가 이미지 생성의 중간 표현이 될 수 있다고 봤다. ASCII 도시 역시 코드를 시각 결과물로 직접 연결한다. 모델이 픽셀을 바로 만들지 않고 장면을 그리는 규칙을 만들 때, 사람은 더 쉽게 편집하고 재사용할 수 있다.

제품 관점에서는 작은 엔진을 템플릿화할 기회가 있다. 도시, 지하철, 물류창고, 데이터센터, 보드게임 맵처럼 격자와 이동 규칙이 있는 시뮬레이션은 한 파일 구조와 잘 맞는다. AI는 기본 엔진을 만들고, 사람은 도메인 규칙과 시각 언어를 다듬는 방식이다.

장난감 데모와 제품의 경계

물론 한 파일 실험은 만능이 아니다. 접근성, 모바일 입력, 저장, 성능 측정, 브라우저 호환성, 라이선스 표기, 오류 복구가 빠지면 데모에 머문다. W3C의 Web Content Accessibility Guidelines 같은 기준은 시각 실험에도 필요하다. ASCII 화면은 멋있지만 스크린 리더나 저시력 사용자에게 어떤 대체 정보를 줄지 별도로 설계해야 한다.

그래도 이 사례가 던지는 질문은 선명하다. AI로 더 많은 코드를 쓸 수 있다면, 우리는 왜 더 작은 프로그램을 만들지 않는가. 복잡한 앱을 빠르게 찍어내는 능력만큼이나, 한 파일로 충분한 문제를 한 파일로 끝내는 감각이 중요해지고 있다.

자주 묻는 질문

Q1: 이 프로젝트는 AI가 만든 것인가요?

A: 공개 설명만으로 제작 과정 전체를 단정할 수는 없다. 다만 AI 코딩 시대에 작은 웹 엔진과 검토 가능한 코드가 왜 중요한지 보여주는 사례로 볼 수 있다.

Q2: 왜 ASCII 표현이 다시 주목받나요?

A: 자산이 가볍고 규칙이 명확하며, 모델과 사람이 함께 코드를 읽고 고치기 쉽기 때문이다.

Q3: Canvas만으로 이런 장면을 만들 수 있나요?

A: 가능하다. 복잡한 3D 엔진 없이도 좌표 계산, 깊이감, 문자 밀도, 애니메이션 루프를 조합하면 공간감을 만들 수 있다.

Q4: 제품화하려면 무엇이 더 필요하나요?

A: 모바일 입력, 성능 측정, 접근성, 저장 기능, 오류 복구, 라이선스 정리가 필요하다.

Q5: 한국 팀에는 어떤 의미가 있나요?

A: 빠른 데모와 교육용 도구, 사내 시뮬레이션은 작은 HTML 단위로 만들면 배포와 보안 검토가 쉬워질 수 있다.