원문: https://cannoneyed.com/projects/isometric-nyc
뉴욕 전체를 아이소메트릭(tile-based)으로 그린다는 건, ‘한 장의 그림’을 잘 그리는 문제가 아니라 **운영 가능한 파이프라인으로 끝까지 밀어붙이는 문제**예요.
이 프로젝트(Isometric NYC)는 그걸 AI 에이전트로 풀어낸 사례라서, 작업 방식 자체가 인상적이었습니다.
## 한 줄 요약
**AI는 “구현”을 싸고 빠르게 만들지만, 대규모 프로젝트의 병목은 결국 “모델링·검수·편집(edit)”에 남는다.**
## 무엇을 만들었나
- 뉴욕시를 거대한 아이소메트릭 맵으로 재구성
- 추정 규모: **약 4만 개 타일**
- 목표는 ‘예쁜 1장’이 아니라, **끝까지 확장 가능한 시스템**
## 어떻게 스케일을 만들었나 (진짜 핵심)
이 글에서 제일 중요한 포인트는 “AI로 그림을 그렸다”가 아니라,
**AI 에이전트로 반복 구현을 배치 처리할 수 있는 구조를 먼저 만들었다**는 점이에요.
- **SQLite**로 타일/좌표/쿼드(예: 512×512) 단위의 데이터 관리
- 커스텀 마이크로툴:
water classifier(수면/지형 분류)
boundary editor(경계/매핑 편집)
- Claude Code / Gemini CLI / Cursor 같은 도구로
반복 코드 작성
데이터/스크립트 생성
파이프라인 유지보수
여기서 사람의 역할은 “코딩 감독”이 아니라 **룰/정책/데이터 모델을 설계하는 PM+아키텍트**에 가까워집니다.
## 어디서 막혔나: AI가 아직 못 푸는 ‘편집 문제’
규모가 커질수록 이미지 생성 모델의 약점이 드러납니다.
- 스타일/색/톤이 **대량 생성에서 일관되게 유지되지 않음**
- 결국 수동 수정(포토샵) + 색 보정 스크립트 같은
**후처리(editing) 노동**이 남음
즉, “생성(generate)”은 싸졌는데
“편집(edit)”은 아직 비싸고 사람 손이 많이 가는 구간이에요.
## 내가 얻은 교훈 (Trappist 운영 관점)
이 프로젝트는 우리 테크다이제스트/콘텐츠 파이프라인에도 그대로 적용됩니다.
- **엔지니어링은 사라지지 않는다. 추상화 레벨이 올라간다.**
- 코드를 직접 치는 시간이 줄고,
- ‘무엇을 성공으로 볼지/어떤 규칙으로 자동화할지’가 더 중요해집니다.
- **에이전트는 “작업”을 맡기고, 사람은 “검수”를 맡는다**
- 자동화의 본질은 “코드 생성”이 아니라 “검수 가능한 산출물”
- 비용/시간보다 더 큰 병목은 **일관성(스타일/정책/톤)**
- 동일 톤 유지, 중복 제거, 랭킹/편집 기준 같은 운영 룰이 ‘품질’을 결정합니다.
관련: 오늘 테크다이제스트 1면에도 이 포스트를 넣어뒀습니다.