본문으로 건너뛰기
피드

Vision Pro로 집 설계 도면을 직접 걸어보니, 이게 진짜 킬러 앱일 수도 있겠다는 이야기

frontend 약 8분
vote
0
댓글
북마크

Christian Selig은 집을 짓는 과정에서 평면도 PDF만으로는 공간감을 알기 어려워 Vision Pro용 3D walkthrough를 직접 만들었다. Fusion 360으로 벽과 바닥을 만들고, IKEA·3D Warehouse 모델을 가져와 USDZ로 내보낸 뒤, Claude와 Codex로 컨트롤러 지원 USDZ 뷰어 Prospector를 만들었다는 경험담이다.

  • 1

    평면도를 Fusion 360에서 3D 모델로 만들고 Vision Pro에서 실제 크기처럼 둘러보는 워크플로를 소개함

  • 2

    IKEA 3D 모델, 3D Warehouse, GLB/OBJ/USDZ 변환을 활용해 가구와 질감을 추가함

  • 3

    Claude와 Codex로 만든 Prospector는 컨트롤러 이동, 하늘 배경, 지형 따라가기, 현실 전환, 비행, 6배속 이동을 지원함

평면도 PDF로는 ‘공간감’이 안 온다는 문제

  • 글쓴이는 Vision Pro를 자주 쓰진 않았지만, 집 설계 과정에서 꽤 강력한 용도를 찾았다고 말함

    • 아파트 생활을 끝내고 첫 집을 짓기 시작했는데, 방 크기와 동선 같은 선택이 전부 되돌리기 어려운 결정임
    • 소프트웨어는 마음에 안 들면 기능을 고치거나 지울 수 있지만, 벽 위치는 그렇게 못 함. 아찔함
  • 평면도 PDF의 숫자만으로는 실제 느낌을 잡기 어렵다는 게 출발점임

    • “13피트 x 15피트 방”이라고 적혀 있어도, 그게 넓은지 좁은지는 몸으로 잘 안 와닿음
    • 현관에 들어섰을 때 무엇이 보이는지, 복도가 답답한지, 공간 연결이 자연스러운지도 2D 도면만으론 감이 약함

Fusion 360으로 집을 대충이라도 3D화하기

  • 해결책은 집 도면을 간단한 3D 모델로 만드는 것이었음

    • Fusion 360에서 바닥, 천장, 벽, 문 구멍 정도만 만든 기본 모델부터 시작함
    • 3D 모델링을 잘 몰라도 2D 평면도를 그리고 벽을 위로 extrude하는 식이라 첫 프로젝트로 괜찮다고 설명함
  • 빈 벽만 있는 모델은 공간감을 주긴 하지만, 실제 생활 감각은 아직 부족함

    • 빈 아파트가 처음엔 엄청 넓어 보이다가 가구 넣으면 확 좁아지는 바로 그 문제임
    • 그래서 텍스처와 가구 모델을 넣어야 방 크기와 동선이 훨씬 현실적으로 보임
  • 텍스처는 Fusion 360의 Appearance 패널에서 빠르게 붙였음

    • 나무, 돌, 페인트, 유리 같은 재질을 drag-and-drop으로 적용함
    • 창문에 유리 질감을 넣는 것만으로도 공간이 덜 밋밋해진다고 함

IKEA와 3D Warehouse로 현실감 채우기

  • 가구 모델은 IKEA가 꽤 큰 역할을 함

    • IKEA 제품 상당수에는 3D 모델이 붙어 있고, 침대·소파·책상·러그 같은 물건을 넣으면 방 크기 판단이 쉬워짐
    • 다만 모델을 바로 받기 어렵기 때문에 Tampermonkey 스크립트로 다운로드하는 우회가 필요했다고 함
  • IKEA에서 받은 GLB 파일은 Fusion 360에 바로 쓰기 애매해서 OBJ로 변환해야 했음

    • 여러 스크립트와 웹사이트를 시도한 끝에, 다소 투박하지만 잘 되는 변환 사이트를 찾았다고 함
    • Fusion 안에서는 텍스처가 안 보이는 경우가 있어도, 다시 export하면 정상적으로 나타났다고 덧붙임
  • IKEA에 없는 물건은 3D Warehouse에서 가져왔음

    • 스탠드 믹서, 밥솥, 차 같은 물건까지 찾아서 공간에 놓을 수 있음
    • iOS에서 3D Warehouse URL을 열면 AR 보기용 USDZ를 공유할 수 있고, 그걸 AirDrop으로 Mac에 보내 OBJ로 변환하는 식의 워크플로를 썼음

그냥 USDZ 보기에서 직접 만든 Vision Pro 앱으로

  • Fusion 360은 USDZ export를 지원해서 Vision Pro로 모델을 보내는 것 자체는 가능했음

    • 파일 앱에서 USDZ를 열면 어느 정도 둘러볼 수 있음
    • 하지만 실제 집 크기를 걸어 다니려면 현실 공간에 부딪힐 위험이 있고, 전체 집을 탐색하기도 불편함
  • 그래서 글쓴이는 Claude와 Codex를 섞어 반나절 정도 vibe coding으로 Prospector라는 Vision Pro용 USDZ 뷰어를 만들었음

    • 코드 품질이 완벽하진 않아도, 전통적인 방식으로 몇 주 들여 만들 생각은 안 했을 도구를 빠르게 만든 셈임
    • GitHub에 올렸지만 App Store에 낼 만큼 다듬은 상태는 아니라고 선을 그음

중요

> Prospector의 핵심은 “3D 파일을 보는 앱”이 아니라, 집 안을 게임처럼 이동하면서 의사결정에 필요한 공간감을 얻는 도구라는 점임.

  • Prospector에는 실제 walkthrough에 필요한 기능이 꽤 많이 들어감
    • 컨트롤러로 3D 게임처럼 이동하고 카메라도 돌릴 수 있음
    • forest 스타일 skybox를 넣어 창밖이 현실 배경으로 뚫려 보이지 않게 함
    • 지형 데이터가 있으면 D-pad로 terrain following을 켜서 땅의 높낮이를 따라 이동할 수 있음
    • 손가락 제스처로 가상 세계를 켜고 끄는 기능도 있어, 현실에서 뭔가에 부딪힐 것 같을 때 안전하게 확인 가능함
    • 트리거로 위아래 비행이 가능하고, D-pad 왼쪽을 누르면 6배 빠르게 이동할 수 있음

이게 왜 꽤 그럴듯한가

  • 건축가가 Revit으로 보여준 3D walkthrough도 있었지만, 글쓴이는 이미 Vision Pro에서 몰입형으로 본 뒤라 집을 안다고 느꼈다고 함

    • Revit walkthrough는 Google Street View처럼 클릭해서 이동하고 드래그해서 둘러보는 경험에 가까웠음
    • 반면 Vision Pro에서는 실제로 그 공간 안에 있는 것처럼 둘러볼 수 있었음
  • 결론은 꽤 단순함. 미래의 집 설계 검토는 3D 방문이 기본이 될 수 있다는 것임

    • 하드웨어가 있다면 그 미래는 이미 오늘 가능하다는 주장임
    • 특히 개발자 입장에선 3D 도구, 파일 변환, AI 코딩, Vision Pro 앱을 엮어 현실 의사결정 도구를 만든 사례라 꽤 공유할 만함

기술 맥락

  • 이 글의 기술적 선택은 평면도를 완성도 높은 건축 렌더링으로 만드는 게 아니라, 빠르게 걸어볼 수 있는 3D 공간으로 바꾸는 쪽이에요. 집 설계에서 중요한 건 예쁜 이미지보다 “이 복도가 답답한가”, “침대를 놓으면 움직일 공간이 남는가” 같은 감각이거든요.

  • Fusion 360을 고른 이유는 벽, 바닥, 천장처럼 단순한 형태를 빠르게 만들 수 있기 때문이에요. 전문 건축 툴을 처음부터 깊게 배우는 대신, 2D 도면을 그리고 extrude해서 Vision Pro에서 볼 수 있는 모델로 넘기는 현실적인 경로를 택한 거예요.

  • IKEA 모델과 3D Warehouse를 섞은 건 스케일 문제 때문이에요. 빈 방은 실제보다 넓어 보이기 쉬워서, 침대나 소파 같은 기준 물체가 들어가야 몸이 크기를 이해해요. 그래서 파일 변환이 귀찮아도 GLB, USDZ, OBJ를 오가며 가구를 채운 거죠.

  • Prospector를 직접 만든 이유는 기본 USDZ 뷰어가 “보는 것”에는 괜찮아도 “탐색하는 것”에는 부족했기 때문이에요. 컨트롤러 이동, 비행, 6배속 이동, 현실 전환 같은 기능은 집 전체를 안전하게 훑어보려는 목적에서 나온 선택이에요.

이 글의 재미는 Vision Pro 찬양보다 ‘비싼 공간 결정을 소프트웨어처럼 미리 시뮬레이션했다’는 데 있음. spatial computing이 개발자 장난감에서 실제 의사결정 도구로 넘어가는 그림이 꽤 선명함.

댓글

댓글

댓글을 불러오는 중...

frontend

데모신 툴 UI 구경기: 예쁘고 불편하고 이상하게 실용적인 화면들

데모신 문화에서 쓰이던 자체 제작 도구들의 UI를 훑는 긴 글임. Amiga 어셈블러, 음악 트래커, 디스크 복사기, 압축 도구, ANSI 편집기까지 나오는데, 당시 제약과 문화가 UI에 얼마나 직접적으로 묻어나는지 보여줌.

frontend

UI 컴포넌트 이름 헷갈릴 때, 동작 계약까지 뽑아주는 퀴즈형 도구

NameThatUI는 웹 UI 요소의 이름을 맞히는 데서 끝나지 않고, 비슷한 UI 패턴을 비교한 뒤 구현 가능한 동작 명세로 정리해주는 도구다. Tooltip, Popover, Hover Card처럼 생긴 건 비슷하지만 접근성, 포커스, 닫힘 규칙이 다른 패턴을 구분하는 데 초점을 둔다. 코딩 에이전트나 컴포넌트 라이브러리에 잘못된 이름을 던져서 엉뚱한 구현이 나오는 문제를 줄이려는 접근이다.

frontend

포럼 소프트웨어에서 React 걷어내고 HTMX로 돌아가려는 이유

Misago 프로젝트가 React.js 기반 UI 구조를 걷어내고 Django 서버 렌더링과 HTMX 조합으로 단순화하려는 이유를 설명한 글이다. 같은 화면을 Django 템플릿과 React 컴포넌트로 두 번 구현하는 문제, 중복 번역 파일, JSON 직렬화 비용, 플러그인 개발 복잡도까지 꽤 현실적인 고통이 나온다. 결론은 포럼처럼 상호작용이 특정 영역에 몰린 서비스라면 풀 React 앱보다 서버 렌더링 HTML 조각 교체가 더 맞을 수 있다는 얘기다.

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.