프롬프트로 3D DEV 도서관을 만들려다 직접 레벨 에디터를 만들었습니다

AI 요약

Oniria는 DEV 글을 피드나 검색 결과 목록 대신 걸어 다니며 탐색하는 도서관으로 보여주는 프로젝트입니다. DEV API가 글·작성자·태그·검색 데이터를 제공하고, Three.js가 공간과 책, 상호작용을 렌더링합니다. Sanity는 방 구성, 공간 배치, 큐레이션, 책장 상태와 변경 이력을 저장합니다. 개발자는 꿈 기록 앱으로 시작한 프로젝트가 3D 환경과 DEV 도서관으로 바뀌기까지의 시행착오를 소개합니다.

피드에서 공간으로

도서관은 Featured, New Arrivals, Topics, Creators, Search, Archive 여섯 방으로 구성됩니다. 사용자는 책에 다가가 실제 DEV 글을 열고, 돌아오면 도서관 안의 이전 위치로 복귀합니다. 검색도 일반적인 결과 목록으로 끝나지 않습니다. Search 방의 책장이 검색어에 맞는 글로 채워집니다. 글의 저자와 태그, 인기도, 최신성 같은 관계를 공간에 배치해 탐색 경험을 만듭니다.

처음에는 글과 프로필을 공간 그래프의 노드처럼 표현했지만, 요소들이 한꺼번에 주목을 끌어 계층이 부족했습니다. 그래서 그래프 구조를 설명하는 대신 문과 책장으로 목적지를 분명하게 보여주는 여섯 방으로 단순화했습니다. 복잡한 데이터와 절차는 내부에 두고, 방문자는 익숙한 도서관을 탐색하게 했습니다.

프롬프트 대신 공간 편집 도구

개발자는 Codex와 ChatGPT를 활용해 구조 설계, UX, 디버깅, 구현을 진행했습니다. 하지만 AI가 기술적으로 요청을 따르더라도 시각적 의도를 놓치는 경우가 있었습니다. 제공한 벽면 에셋을 사용해 달라고 했는데 모델이 별도의 절차적 벽을 만들었고, 나중에는 UnrealBloomPass의 임계값이 너무 낮아 장면 전체가 빛바래는 문제도 발견했습니다. 처음 떠오른 설명만 받아들이지 않고 실제 환경을 테스트하면서 원인을 좁혔다고 합니다.

정확한 위치에 선반을 놓는 작업은 코드와 좌표, 간헐적인 스크린샷만으로 반복하기 어려웠습니다. 그래서 실행 중인 Three.js 세계를 직접 걸어 다니며 배치 지점을 표시하는 개발 전용 공간 편집 흐름을 만들었습니다. 마커에는 방 번호, 구역, x·y·z 좌표, 회전값, 너비와 깊이를 기록합니다. Sanity의 libraryLayoutMarker 문서에 위치를 저장하면 렌더러가 배치 정보를 읽습니다. 개발자가 원하는 자리에 서서 마커를 찍고, Sanity가 공간 데이터를 보존하는 방식입니다. 이 과정에서 Sanity는 단순한 CMS가 아니라 3D 환경을 편집하는 도구가 됐습니다.

위치는 유지하고 책은 교체하는 Living Shelf

Living Shelf는 물리적 책장 자리와 그 자리에 놓인 콘텐츠를 분리합니다. 각 슬롯은 고유한 정체성을 유지하며 구역, 점유 콘텐츠, 주제, 활력도, 신호 점수, 글 수, 시각, 이력을 Sanity에 저장합니다. 상태는 DORMANT에서 FORMING, ACTIVE, COOLING을 거쳐 다시 DORMANT로 바뀝니다. 예약 작업이 30분마다 최근 DEV 활동을 살펴 주제 신호를 평가하고, 성장하는 주제는 빈 슬롯에 등장시킵니다. 활동이 줄면 슬롯은 식지만 위치와 이전 기록은 남고 점유 글만 바뀝니다.

성능과 AI 협업의 피드백 루프

초기에는 수백 권의 책과 원격 표지 이미지를 배치해 깜박임, 불필요한 텍스처 처리, 과도한 기하 구조와 시각적 혼잡이 생겼습니다. 이후 상호작용이 가까운 곳에만 높은 세부 묘사를 적용했습니다. 근거리 책은 표지와 메타데이터, 개별 상호작용을 제공하고 중거리 선반은 단순화합니다. 멀리 있는 구조물은 수많은 상호작용 객체 대신 건축물의 덩어리로 표현합니다.

글쓴이는 AI가 반복적인 Three.js 작업과 리팩터링, 상태 추적, 대안 구현을 빠르게 하는 데 강했다고 설명합니다. 반면 정확한 공간 의도나 화면에서 느껴지는 규모를 판단하는 일은 약했습니다. 요청한 대로 무조건 리팩터링하기보다 기존 선반 구조를 살펴보고 실제 병목인 용량 제한을 찾아낸 사례도 소개합니다. 글쓴이가 정리한 작업 방식은 관찰하고, 문제를 정의하고, 에이전트가 구현한 결과를 직접 실행해 걸어 본 뒤 가정을 고치는 반복입니다. 자율성을 높이는 것보다 사람의 지각과 기계의 구현 사이 피드백을 짧게 만드는 편이 효과적이었다고 합니다.

dev.to 반응

• @? — 작성자가 숨긴 댓글입니다.
  • @unitbuilds — 외부 링크는 클릭하지 마세요! DEV.to는 자동 메시지에 Sloan을 사용합니다. 이건 피싱일 가능성이 높습니다.
• @contentclips_st — Living Shelf 슬롯이 이 설계에서 가장 강한 부분입니다. 물리적 위치를 안정된 정체성으로 두고 점유 콘텐츠를 DORMANT → FORMING → ACTIVE → COOLING으로 바꾸면, 세계를 고정하지 않으면서 활동 이력을 보존합니다. 위치는 유지되고 점유자는 바뀝니다. 일찍 확정해 둘 점이 하나 있습니다. 상태 전환을 기존 기록에 덮어쓰지 말고, 전환마다 이력 항목을 추가하는 방식으로 만들어야 합니다. 그래야 식은 슬롯이 ‘예전에 무엇이 있었고 왜 사라졌는지’ 답할 수 있습니다. 검색과 추천은 사라진 과거를 나중에 재구성하지 못합니다. 상호작용이 필요한 곳에만 완전한 세부 묘사를 적용하는 규칙은 검색 결과로 책장을 채우는 기능과도 잘 맞습니다. 책장 장면을 다시 만들지 않고 공유 또는 인스턴스 메시의 점유 데이터만 교체하면 결과가 많아도 비용을 낮게 유지할 수 있습니다. 프롬프트를 개선하는 대신 도구를 만드는 결론이 옳습니다. 공간 감각은 프롬프트만으로 해결할 수 없습니다.

원문: dev.to / 번역·요약: Trawling