2분반-인테리
프로젝트 개요
기술개발 과제
국문 : WebGPU 기반 고품질 인테리어 조명 시뮬레이터 개발
영문 : Development of a High-Quality WebGPU-based Interior Lighting Simulator
과제 팀명
인테리(Intery)
지도교수
김민호 교수님
개발기간
2025년 09월 ～ 2025년 12월(총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 20229200** 오*민(팀장)
서울시립대학교 컴퓨터과학부 20229200** 류*화
서울시립대학교 컴퓨터과학부 20229200** 배*연
서울시립대학교 물리학과 20195500** 한*민
서론
개발 과제의 개요
개발 과제 요약
본 과제는 웹 환경에서 방 안에 다양한 전등을 배치하고, 조명의 밝기·색온도·조명각·위치를 실시간으로 조절하며 그 결과를 직관적으로 확인할 수 있는 인테리어 조명 시뮬레이터를 개발하는 것을 목표로 한다. 사용자는 복잡한 전문 지식 없이도 조명 설정을 변경하면서 공간 분위기의 변화를 즉시 확인할 수 있으며, 이를 통해 실제 설치 환경과 유사한 시뮬레이션 경험을 제공받는다. 특히 화면 품질과 계산 속도를 동시에 확보하기 위해 빛 샘플링을 효율적으로 처리하는 최신 기술인 ReSTIR을 적용하여, 다수의 전등이 존재하는 장면에서도 고품질의 렌더링을 실시간으로 구현한다. 이러한 기능을 통해 조명 제품 구매 전 시뮬레이션을 제공함으로써 구매 전환율을 높이고, 반품을 줄이며, 인테리어 디자인 제안의 신뢰성을 강화하는 비즈니스적 효과를 기대할 수 있다.
개발 과제의 배경
기존의 웹 기반 인테리어 시뮬레이터는 대부분 단순한 PBR(물리 기반 렌더링) 수준에 머물러 있어, 전등의 개수가 증가할수록 화면이 거칠어지고 성능이 급격히 저하되는 한계를 가지고 있다. 그러나 실제 소비자는 조명 배치, 색온도, 밝기 변화에 따라 공간 분위기가 어떻게 달라지는지를 구매 이전 단계에서 정확히 확인하고자 한다. 현재의 상용 서비스들은 이러한 요구를 사실적으로 충족시키지 못하고 있으며, 이는 사용자 경험의 한계로 이어진다. 본 과제는 이러한 문제를 해결하기 위해 최신 조명 샘플링 기법인 ReSTIR을 웹 환경에 적용하여, 제한된 연산 자원에서도 고품질의 실시간 조명 시뮬레이션을 가능하게 함으로써 기존 웹 인테리어 서비스의 기술적 한계를 극복하고자 한다.
개발 과제의 목표 및 내용
본 과제의 기술적 목표는 RTX 3060급 GPU 환경에서 (1024*768) 해상도 기준 60FPS의 실시간 성능을 안정적으로 달성하는 것이다. 이를 위해 전등이 최대 32개 수준으로 배치된 장면에서도 조명 노이즈와 깜빡임 현상을 눈에 띄게 줄이고, 사용자 상호작용 시에도 시각적 품질이 유지되도록 한다. 사용자는 웹 인터페이스를 통해 전등을 자유롭게 배치하고, 밝기, 색온도, 빔 각도뿐만 아니라 시간대(아침·저녁 등)에 따른 자연광 변화까지 설정할 수 있다. 또한 시뮬레이션 결과를 저장하고 다른 사용자와 공유할 수 있는 기능을 제공함으로써, 개인 사용뿐만 아니라 협업 및 디자인 제안 도구로도 활용 가능하도록 구성한다.
관련 기술의 현황
관련 기술의 현황 및 분석(State of art)
- NVIDIA ReSTIR
NVIDIA ReSTIR는 실시간 레이 트레이싱에서 다수(수천~수백만)의 동적 광원을 다루는 직접조명(Direct Illumination) 문제를 해결하기 위해 제안된 대표적인 최신 샘플링 기술이다. 핵심 아이디어는 픽셀마다 여러 후보 광원 샘플을 생성한 뒤, 이 중 좋은 샘플을 저장소(Reservoir) 구조에 압축해 유지하고, 이를 시간(Temporal)과 공간(Spatial) 방향으로 재사용(resampling)함으로써 적은 샘플 수로도 높은 품질의 조명과 그림자를 얻는 것이다. 이 접근은 복잡한 가속 구조나 광원 선택 자료구조를 유지하지 않고도 조명 복잡도 증가에 따른 성능 저하를 완화하며, 결과적으로 조명이 많아질수록 느려지는 전통적 방식의 병목을 줄여 실시간 품질/성능의 균형을 크게 개선했다. ReSTIR는 원래 동적 직접조명에 초점을 맞춰 제안되었고(일명 ReSTIR DI), 이후 동일한 “재표본화 기반의 샘플 재사용” 철학을 확장하여 간접조명(GI) 및 경로 추적(Path Tracing)으로까지 발전하는 흐름을 만들었다.
- WebGPU
WebGPU는 웹 환경에서 고성능 그래픽스 및 범용 GPU 연산(GPGPU)을 가능하게 하기 위해 제안된 최신 웹 표준 API로, 기존 WebGL이 가지던 구조적·성능적 한계를 근본적으로 개선하는 것을 목표로 한다. WebGPU는 Vulkan, DirectX 12, Metal과 같은 현대적인 저수준 그래픽 API의 설계 철학을 계승하여, 명시적인 리소스 관리, 파이프라인 상태 객체 기반 렌더링, 그리고 컴퓨트 셰이더 중심의 연산 모델을 웹으로 확장하였다. 이를 통해 개발자는 GPU 메모리, 동기화, 바인딩 구조를 보다 세밀하게 제어할 수 있으며, 복잡한 렌더링 파이프라인과 대규모 병렬 연산을 효율적으로 구현할 수 있다. 특히 WebGPU는 Compute Shader를 1급 시민(first-class feature)으로 지원함으로써, 단순한 래스터라이징 기반 그래픽스를 넘어 물리 시뮬레이션, 이미지 처리, 머신러닝 추론, 그리고 실시간 레이 트레이싱 전처리·후처리와 같은 고급 GPU 연산을 웹에서 직접 수행할 수 있게 한다. 이는 WebGL의 프래그먼트 셰이더 기반 GPGPU 기법보다 훨씬 명확하고 안정적인 연산 모델을 제공하며, 복잡한 알고리즘을 구현하는 데 있어 코드 구조와 성능 예측성을 크게 향상시킨다. 최근에는 주요 브라우저(Chrome, Edge 등)에서 WebGPU가 안정적으로 지원되기 시작하면서, 연구 및 산업 전반에서 WebGPU를 활용한 고급 렌더링 및 시뮬레이션 사례가 빠르게 증가하고 있다. 특히 실시간 경로 추적(Path Tracing), 물리 기반 시뮬레이션, 대규모 파티클 시스템 등 기존에는 네이티브 애플리케이션에서만 가능했던 작업들이 웹 환경에서도 실험·구현되고 있다. 이러한 흐름은 WebGPU가 단순한 차세대 WebGL을 넘어, 웹을 하나의 범용 고성능 시뮬레이션 플랫폼으로 확장시키는 핵심 기술로 자리 잡고 있음을 보여준다.
- Three.js
Three.js는 웹 환경에서 3차원 그래픽스를 손쉽게 구현할 수 있도록 설계된 대표적인 JavaScript 기반 3D 렌더링 라이브러리로, WebGL을 추상화하여 복잡한 그래픽 파이프라인을 비교적 간단한 API로 제공한다. 카메라, 조명, 메시, 머티리얼, 씬(Scene) 관리 등 3D 그래픽스의 핵심 요소를 고수준 인터페이스로 캡슐화함으로써, 그래픽스 전문 지식이 없는 개발자도 웹에서 인터랙티브한 3D 콘텐츠를 제작할 수 있도록 지원해 왔다. 이러한 접근성 덕분에 Three.js는 웹 기반 제품 시각화, 교육 콘텐츠, 게임, 메타버스, 인테리어 시뮬레이터 등 다양한 분야에서 사실상의 표준 라이브러리로 자리 잡았다. 기술적으로 Three.js는 물리 기반 렌더링(PBR)을 지원하는 표준 머티리얼(MeshStandardMaterial, MeshPhysicalMaterial)을 제공하며, 환경 맵, 그림자 매핑, HDR 조명 등 현대적인 실시간 그래픽스 기능을 폭넓게 포함하고 있다. 이를 통해 비교적 적은 구현 비용으로 그럴듯한 시각적 결과를 얻을 수 있으나, 내부적으로는 여전히 래스터라이징 중심의 렌더링 구조에 의존하고 있어, 광원이 많아질수록 조명 계산 비용이 증가하고 노이즈 없는 고품질 글로벌 일루미네이션을 구현하는 데에는 구조적 한계가 존재한다. 특히 다수의 전등이 배치된 실내 환경에서는 그림자 품질 저하, 조명 정확도 부족, 성능 저하 문제가 쉽게 발생한다. 최근 Three.js는 WebGPU 백엔드(Renderer) 도입을 통해 기술적 확장을 시도하고 있다. 실험적 WebGPURenderer는 기존 WebGLRenderer 대비 더 명시적인 리소스 관리와 컴퓨트 셰이더 활용 가능성을 제공하며, 장기적으로는 경로 추적(Path Tracing) 및 고급 조명 기법과의 결합 가능성을 열어두고 있다. 그러나 현재 시점에서 Three.js의 WebGPU 지원은 아직 완전한 대체 단계에 이르지 않았으며, 고급 실시간 조명 기법(ReSTIR, 실시간 Path Tracing 등)을 직접적으로 제공하기보다는, 여전히 고수준 장면 관리 및 인터랙션 레이어로서의 역할이 중심이다. 이러한 특성으로 인해 Three.js는 최신 웹 그래픽 파이프라인에서 렌더링 코어보다는 UI·씬 관리·상호작용 계층으로 활용되는 방향으로 진화하고 있다.
- React
React는 사용자 인터페이스(UI) 구축을 위해 설계된 대표적인 JavaScript 라이브러리로, 선언적 컴포넌트 기반 구조와 상태 중심의 렌더링 모델을 통해 복잡한 웹 애플리케이션을 체계적으로 관리할 수 있도록 한다. UI를 독립적인 컴포넌트 단위로 분리하고, 각 컴포넌트가 상태(State) 변화에 따라 자동으로 화면을 갱신하는 방식은 대규모 인터랙티브 웹 서비스에서 높은 유지보수성과 확장성을 제공한다. 이러한 특성으로 인해 React는 현재 웹 프론트엔드 분야에서 사실상의 표준 프레임워크로 자리 잡았으며, 다양한 산업 영역에서 복잡한 사용자 상호작용을 처리하는 핵심 기술로 활용되고 있다. 기술적으로 React는 Virtual DOM 기반의 변경 감지(diffing) 메커니즘을 통해 UI 업데이트 비용을 최소화하고, 데이터 흐름을 단방향으로 제한함으로써 애플리케이션 상태 변화를 예측 가능하게 만든다. 이는 실시간으로 다수의 입력과 시각적 변화를 처리해야 하는 인터랙티브 시뮬레이션 환경에서 특히 중요한 장점으로 작용한다. 예를 들어 사용자가 조명 밝기나 색온도를 조절할 때, React는 해당 상태 변경을 즉시 UI에 반영하면서도 불필요한 DOM 조작을 줄여 안정적인 사용자 경험을 제공한다. 이러한 구조는 복잡한 설정 패널, 실시간 파라미터 조정 UI, 상태 기반 제어 로직을 구현하는 데 적합하다. 최근 React 생태계는 단순한 UI 라이브러리를 넘어, 대규모 애플리케이션 아키텍처를 지원하는 방향으로 발전하고 있다. Hooks, Context API, Suspense 등은 상태 관리와 비동기 로직을 보다 명확하게 구조화할 수 있도록 하며, WebGPU·Three.js와 같은 저수준 그래픽 시스템과 결합할 때에도 UI 계층과 렌더링 코어를 분리하는 역할을 수행한다. 이러한 특성으로 인해 React는 고성능 그래픽 연산 자체를 담당하기보다는, 복잡한 시뮬레이션 시스템을 제어·조작·시각적으로 표현하는 상위 인터페이스 계층으로서의 역할에 최적화된 최신 웹 UI 기술로 평가된다.
시장상황에 대한 분석
- 경쟁제품 조사 비교
- 인테리어 웹·앱 서비스(예: 오늘의집 등)
- 대중적인 인테리어 서비스는 사용자가 웹이나 앱에서 손쉽게 방 구조를 설정하고 가구를 배치하도록 지원한다. 카탈로그 기반의 가구 배치, 간단한 치수 감각 제공, 이미지 중심의 레퍼런스 탐색에 강점을 가진다. 그러나 렌더링은 대체로 실시간 반응성을 우선하는 간단한 표현에 머무르며, 간접광(반사·확산)이나 다중 광원 상호작용과 같은 글로벌 일루미네이션 효과는 제한적으로 처리된다. 그 결과 조명 변경에 따른 공간 분위기 변화가 ‘밝아짐/어두워짐’ 수준으로 단순화되기 쉽고, 그림자·빛샘(창문 유입광)·면광원 확산 등 현실감을 좌우하는 요소의 재현이 어렵다. 즉 배치 설계에는 유용하지만 조명 시뮬레이션을 근거로 의사결정을 내리기에는 표현력이 부족한 경우가 많다.
- 건축 조명 설계 전문 툴(DIALux, Relux, Radiance 등)
- 조명 설계 분야의 전문 툴은 조도(lux), 휘도, 눈부심 지수, 주광(daylighting)등 공학적 지표를 중심으로 물리 기반 계산을 수행한다. 예컨대 Radiance 계열은 주광과 인공조명을 함께 고려하는 고정밀 계산이 가능해 설계 검증 및 규정 대응에 강점을 가진다. 다만 이러한 도구는 입력 데이터(재질 물성, 광원 배광, 측정 포인트, 센서 그리드, 계산 파라미터 등)의 정의가 복잡하고, 작업 흐름이 전문가의 설계 프로세스(도면 기반 모델링 → 계산 설정 → 결과 해석)에 맞춰져 있어 비전문가에게 진입장벽이 높다. 또한 결과 산출이 배치 처리(batch)에 가까워 즉각적인 상호작용(가구 위치를 움직이며 조명 변화 확인, 시간대를 드래그하며 주광 변화 확인 등)이 어렵고, 웹 서비스 형태의 접근성·공유성도 제한적이다.
- AR 기반 가구 배치 앱(IKEA Place 등)
- AR 앱은 실제 공간 위에 가구를 합성하여 크기감과 배치를 빠르게 체험하게 한다. 사용자는 측정·배치 과정이 직관적이며, 현실 공간 맥락을 그대로 활용할 수 있다는 장점을 얻는다. 그러나 핵심 목표가 ‘배치 체험’에 맞춰져 있어 조명과 재질 표현은 대체로 단순화된다. AR로 배치한 가구가 실제 방의 조명 조건(광원의 위치·색온도·차광 상태, 창문 유입광, 반사 환경)을 정확히 반영하지 못하는 경우가 많고, 추가 광원 설치나 설정 변경에 따른 분위기 변화 역시 물리적으로 일관된 방식으로 예측하기 어렵다. 따라서 “현실 위에 놓아보기”에는 적합하지만 조명 설계의 결과를 비교·검토하기에는 한계가 존재한다.
- 요약
- 현재 시장에는 인테리어 구상을 돕는 웹·앱 도구와, 고정밀 조명 검증을 위한 전문가용 툴, 그리고 AR 기반의 배치 체험 도구가 각각 존재한다. 그러나 가구를 자유롭게 편집할 수 있는 사용자 친화적 워크스페이스와 물리 기반의 사실적인 조명(자연광·다중 광원·간접광) 시뮬레이션, 그리고 웹 기반 접근성과 공유성을 동시에 만족시키는 솔루션은 드물다. 본 과제는 이 간극을 목표로 설정하고, Three.js 기반 편집 워크스페이스와 WebGPU 기반 Path Tracing 렌더링 워크스페이스를 결합하여 일반 사용자와 전문가 모두가 활용 가능한 조명·인테리어 시뮬레이션 도구를 지향한다.
- 마케팅 전략 제시
1. SWOT 분석
1. Strength (강점)
본 서비스는 WebGPU 기반 Path Tracing과 ReSTIR-like 샘플링 기법을 적용하여
별도의 프로그램 설치 없이도 웹 브라우저 환경에서 고품질 조명 시뮬레이션을 제공한다.
자연광과 다중 광원에 따른 간접광 효과를 실시간으로 확인할 수 있어
기존 웹 기반 인테리어 서비스 대비 시각적 사실성이 높다.
2. Weakness (약점)
고품질 렌더링 특성상 사용자의 GPU 성능에 따라 체감 성능이 달라질 수 있으며
저사양 환경에서는 기능 제약이 발생할 가능성이 있다.
또한 최신 그래픽스 기술 활용으로 초기 개발 난이도와 유지보수 비용이 높다.
3. Opportunity (기회)
온라인 인테리어 및 조명 커머스 시장은 지속적으로 성장하고 있으며
구매 이전 단계에서 공간과 제품을 미리 체험하려는 수요가 증가하고 있다.
별도 장비 없이 웹에서 고품질 시뮬레이션을 제공하는 서비스는
접근성과 실용성 측면에서 경쟁력을 가진다.
4. Threat (위협)
이케아, 아마존 등 대형 가구·커머스 기업이
자체 인테리어 시뮬레이션 기술을 빠르게 도입할 가능성이 존재한다.
2. 주요 타겟 고객층
1. 일반 소비자 (홈오너 및 셀프 인테리어 사용자)
조명과 가구 배치에 관심은 있으나 전문 설계 도구 사용에는 부담을 느끼는 사용자로,
구매 전 공간 분위기를 미리 확인할 수 있는 체험 도구로 활용 가능하다.
2. 인테리어 디자이너 및 건축 업계 전문가
설계 초기 단계에서 조명·가구 배치에 따른 분위기 변화를 빠르게 검토하고
클라이언트와의 커뮤니케이션 수단으로 활용 가능하다.
3. 가구 및 조명 제조·판매업체
제품을 실제 공간에 적용했을 때의 효과를 시뮬레이션하여
온라인 쇼룸 및 마케팅 도구로 확장 활용할 수 있다.
개발과제의 기대효과
기술적 기대효과
본 과제를 통해 웹 환경에서도 고급 오프라인 렌더링 기법에 준하는 조명 품질을 실시간으로 제공할 수 있는 기술적 기반을 확보할 수 있다. 특히 ReSTIR 기반의 효율적인 조명 샘플링 기법을 적용함으로써, 다수의 광원이 존재하는 복잡한 실내 환경에서도 성능 저하 없이 안정적인 렌더링이 가능해진다. 이는 기존 웹 그래픽 기술의 한계를 확장하는 사례가 될 수 있으며, 향후 다양한 WebGPU 기반 시뮬레이션 및 시각화 서비스로의 확장 가능성을 제공한다. 더 나아가 웹에서도 고품질 조명 시뮬레이션이 가능함을 입증함으로써, 차세대 웹 그래픽 기술 활용에 대한 기술적 신뢰도를 높이는 효과를 기대할 수 있다.
경제적, 사회적 기대 및 파급효과
본 과제의 결과물은 조명 및 인테리어 산업 전반에서 실질적인 경제적 효과를 창출할 수 있다. 소비자는 실제 설치 전 조명 효과를 미리 확인함으로써 구매 실패 가능성을 줄일 수 있고, 기업은 반품 및 고객 불만 감소를 통해 비용 절감 효과를 기대할 수 있다. 또한 온라인 기반의 조명 시뮬레이션 서비스는 오프라인 전시장 방문이 어려운 사용자에게도 동일한 수준의 경험을 제공하여 접근성을 향상시킨다. 사회적으로는 디지털 기술을 활용한 합리적인 소비 문화 확산에 기여할 수 있으며, 중소 인테리어·조명 업체에도 고급 시뮬레이션 도구를 제공함으로써 산업 전반의 경쟁력 강화에 긍정적인 영향을 미칠 것으로 기대된다.
기술개발 일정 및 추진체계
개발 일정
단계별 세부 개발 내용
| 단계별 세부 개발 내용 | 담당자 | 9월 | 10월 | 11월 | 12월 | 비고 |
|---|---|---|---|---|---|---|
| 프로젝트 환경 구축 및 기본 구조 설계 | 팀원 전체 | O | ||||
| 개발 환경 세팅, 기술 스택 확정 전체 시스템 아키텍처 설계 |
팀원 전체 | O | O | - | ||
| 렌더링 코어 초기 구조 수립 | 류*화, 한*민 | O | O | WebGPU 기반 Path Tracing 파이프라인 | ||
| 광원 라이브러리 설계 및 UI 구현 | 류*화, 한*민 | O | O | Directional / Point / Rect Light | ||
| 사용자 조작 기능 구현 | 오*민 | O | 카메라 이동, Scene 인터랙션 | |||
| ReSTIR-like 직접광 샘플링 구현 | 류*화, 한*민 | O | O | O | MCPT 대비 노이즈 감소 | |
| Backend 기능 구현 | 오*민 | O | Scene 저장·불러오기, 상태 관리 | |||
| 1차 품질 개선 | 팀원 전체 | O | O | 수렴 속도·노이즈 개선 | ||
| 성능 최적화 및 안정성 시험 | 팀원 전체 | O | GPU 부하·메모리 관리 | |||
| 통합 테스트 및 최종 검증 | 팀원 전체 | O | 시연 시나리오 기반 검증 |
구성원 및 추진체계
오*민 (Web Full Stack / 시스템 통합)
- Spring Boot 기반 백엔드 API 서버 설계 및 구현
- Scene·광원 데이터 저장/불러오기 API 및 상태 관리 로직 개발
- React 프론트엔드와 백엔드 간 데이터 연동 및 통신 구조 설계
- 서버 인프라 및 배포 환경 구성 (AWS 기반 서비스 배포, CDN 연계)
- 전체 웹 서비스 흐름 (Frontend–Backend–Renderer) 통합 및 안정화 담당
배*연 (프론트엔드 담당)
- React 기반 사용자 인터페이스(UI) 설계 및 구현
- 전등 배치·조절·비교 기능을 위한 사용자 조작 UI 개발
- 사용자 편의 기능 (Scene 저장·불러오기, 화면 캡처 등) 구현
- 그래픽스 결과를 직관적으로 표현하기 위한 UI/UX 개선
한*민 (그래픽스 담당)
- WebGPU 기반 Path Tracing 렌더링 파이프라인 설계
- ReSTIR-like 직접광 샘플링 기법 구현 (Temporal / Spatial Reuse 중심)
- 다중 광원 환경에서의 노이즈 감소 및 수렴 속도 개선
- 실시간 렌더링 품질 향상을 위한 알고리즘 연구 및 적용
류*화 (그래픽스 담당)
- 광원 모델링 및 GPU 연산 구조 설계
- 렌더링 성능 분석 (FPS 중심) 및 최적화 로직 개발
- 장시간 실행 안정성 시험 및 고품질 렌더링 기능 보강
설계
시스템 요구사항 명세서
시스템 개요
본 시스템은 웹 환경에서 사실적인 조명을 재현하는 인테리어 도구이다. Path Tracing을 실시간으로 수행하기 위해 ResTIR(Reservoir-based Spatio-Temporal Importance Resampling) 알고리즘을 구현하여 활용한다.
기능 요구사항 (Functional Requirements)
- FR-1
- 사용자 인증 및 계정 관리
- FR-1.1 : 사용자는 아이디 / 비밀번호 / 이메일 / 닉네임을 사용하여 회원가입 할 수 있어야 함
- FR-1.2 : 사용자는 로그인 / 로그아웃 할 수 있어야 함
- FR-1.3 : JWT 토큰 기반 인증을 지원해야 함
- FR-2
- 3D Scene 관리
- FR-2.1 : 사용자는 새로운 Scene을 생성할 수 있어야 함
- FR-2.2 : 사용자는 자신의 Scene 목록을 조회할 수 있어야 함
- FR-2.3 : 사용자는 Scene을 수정하고 저장할 수 있어야 함
- FR-2.4 : 사용자는 Scene을 삭제할 수 있어야 함
- FR-2.5 : Scene 구성 데이터는 JSON 형식으로 직렬화 / 역직렬화 되어야 함
- FR-3
- 조명 제어
- FR-3.1 : 사용자는 방향성 조명 (Directional Light)을 추가 / 제거할 수 있어야 함
- FR-3.2 : 사용자는 점 조명 (Point Light)을 추가 / 제거할 수 있어야 함
- FR-3.3 : 사용자는 면 조명 (Rect Light)을 추가 / 제거할 수 있어야 함
- FR-3.4 : 각 조명의 속성 (밝기, 색상, 위치, 방향, 각도)을 조정할 수 있어야 함
- FR-3.5 : 시간에 따른 태양 빛의 변화를 지원해야 함
- FR-4
- 가구 및 오브젝트 배치
- FR-4.1 : 사용자는 미리 정의된 가구 모델을 씬에 추가할 수 있어야 함
- FR-4.2 : 사용자는 가구의 위치, 회전, 크기를 조정할 수 있어야 함
- FR-4.3 : 사용자는 배치된 가구를 제거할 수 있어야 함
- FR-4.4 : 사용자는 FR-4.1 ~ FR-4.3의 동작을 마우스 / 키보드를 통해 수행할 수 있어야 함
- FR-5
- 실시간 렌더링
- FR-5.1 : 사용자가 정의한 Scene을 GPU가 정확히 그려야 함
- FR-5.2 : Path Tracing에 기반한 물리적으로 올바른 화면이 나타나야 함
- FR-5.3 : 사용자와의 Real-Time Interaction이 가능해야 함
- FR-6
- 카메라 제어
- FR-6.1 : 사용자는 마우스 / 키보드를 통해 카메라를 조작할 수 있어야 함
- FR-6.2 : 카메라 위치 정보를 표시해야 함
- FR-6.3 : 카메라 이동 시 렌더링이 자동으로 리셋되어야 함
비기능 요구사항 (Non-Functional Requirements)
- NFR-1
- 성능
- NFR-1.1 : 1024×768 해상도에서 최소 30FPS 이상 유지
- NFR-1.2 : Scene Data 로딩 시간은 5초 이내
- NFR-1.3 : RTX 2070 이상 환경에서 부드러운 렌더링 (30FPS) 제공
- NFR-2
- 호환성
- NFR-2.1 : WebGPU를 지원하는 모든 브라우저에서 동작 (Chrome 113+, Edge 113+)
- NFR-2.2 : Windows, macOS 운영체제 지원 (모바일 미지원)
- NFR-2.3 : 반응형 UI 제공 (최소 해상도: 1280×720)
- NFR-3
- 사용성
- NFR-3.1 : 직관적인 UI/UX로 비전문가도 5분 내 기본 기능 사용 가능
- NFR-3.2 : 실시간 시각적 피드백 제공
- NFR-3.3 : 한국어 언어 지원
- NFR-4
- 보안
- NFR-4.1 : 모든 비밀번호는 암호화되어 저장
- NFR-4.2 : JWT 토큰을 통한 인증 지원
- NFR-4.3 : SQL Injection 방지를 위한 JPA 사용
- NFR-5
- 유지보수성
- NFR-5.1 : TypeScript / Java 기반 타입 안정성 보장
- NFR-5.2 : ESLint / Checkstyle을 통한 코드 품질 관리
제약사항 (Constraints)
- C-1 : WebGPU 미지원 브라우저에서는 동작하지 않음
- C-2 : Ray Tracing 제약으로 인한 Scene 복잡도 제한 (가구 최대 10개)
- C-3 : 모바일 Web 환경에서는 이용 불가
- C-4 : 내장 그래픽 환경에서는 성능을 보장하지 않음
사용자 스토리 (User Stories)
- US-1 : 인테리어 디자이너로서 고객에게 다양한 조명을 시뮬레이션하여 보여주고 싶다
- US-2 : 가구 판매자로서 제품이 실제 공간에서 어떻게 보이는지 고객에게 시연하고 싶다
- US-3 : 방을 꾸미고 싶어하는 소비자로서 조명을 포함한 내 방을 시뮬레이션 하고 싶다
전체 시스템 구조도
이 시스템 구조는 클라이언트 중심의 WebGPU 렌더링 SPA + 서버 기반 씬/계정 관리 백엔드로 역할을 명확히 분리한 웹 서비스 아키텍처이다. 사용자는 Chrome/Edge 브라우저를 통해 HTTPS로 접속하며, Frontend는 React 기반 SPA로 동작해 조명·가구·카메라 등의 UI 컨트롤을 제공한다. 프론트엔드 내부에는 WebGPU Graphics Engine(Three.js + WebGPU)가 포함되어 있으며, React 상태와 연동되어 World·Camera·SceneManager를 관리하고, ReSTIR 기반 Renderer와 WGSL Compute Shader를 통해 고품질 Path Tracing 조명 결과를 실시간으로 계산한다. 개발 환경에서는 5173 포트에서 실행되고, 배포 시에는 정적 파일로 호스팅된다. 프론트엔드는 씬 저장·불러오기 및 인증을 위해 JSON 기반 REST API로 백엔드와 통신하며, 모든 보호된 요청은 JWT Bearer 토큰을 사용해 인증된다. 백엔드는 Spring Boot로 구성된 전형적인 계층형 구조로, Controller(Auth/Scene) → Service(비즈니스 로직) → Repository(JPA) 흐름을 따르며, 사용자 인증, 씬 메타데이터 관리, 자산 JSON 저장을 담당한다. 데이터는 PostgreSQL에 JDBC를 통해 영속화되며, users·scenes 테이블에 사용자 정보와 씬 설정, 썸네일 및 타임스탬프를 저장한다. 이 구조를 통해 연산 집약적인 렌더링은 클라이언트 GPU에서 수행하고, 서버는 상태·데이터 관리에 집중함으로써 확장성과 성능을 동시에 확보한다.
기술 스택 요약
| 계층 | 기술 | 버전 |
|---|---|---|
| Frontend Framework | React | 19.1.1 |
| Frontend Language | TypeScript | 5.9.3 |
| Build Tool | Vite | 7.1.7 |
| Graphics API | WebGPU | Native |
| 3D Library | Three.js | 0.180.0 |
| Math Library | wgpu-matrix | 3.4.0 |
| Backend Framework | Spring Boot | 3.2.0 |
| Backend Language | Java | 17 |
| ORM | JPA / Hibernate | - |
| Database | PostgreSQL | 14+ |
| Authentication | JWT | 0.12.3 |
| API Documentation | Swagger | - |
프론트엔드 아키텍처
Frontend 주요 클래스
프론트엔드 렌더링 시스템은 WebGPU 기반 그래픽 엔진을 중심으로 여러 핵심 객체들이 역할을 분담하는 구조로 설계되어 있다. 먼저 WebGPUEngine는 프론트엔드 렌더링의 진입점이자 중재자로서, WebGPU 디바이스와 큐를 초기화하고 렌더 루프의 시작과 종료를 관리하며, React UI로부터 전달되는 입력과 상태 변화를 하위 렌더링 객체에 전달한다. 이를 통해 UI 계층은 GPU 세부 구현을 직접 다루지 않고도 렌더링을 제어할 수 있다.
Camera 객체는 시점과 투영을 담당하는 수학적 상태 객체로, 위치·회전·시야각·종횡비 정보를 기반으로 View Matrix와 Projection Matrix를 생성한다. 사용자 입력과 시간 변화에 따라 카메라 이동과 회전을 업데이트하며, 이 정보는 모든 렌더링 패스에서 공통으로 사용되어 일관된 시점을 보장한다.
실제 GPU 연산의 중심에는 Renderer가 있으며, GPU Buffer와 Texture를 생성하고 Render Pipeline과 Compute Pipeline을 정의하며, WGSL 셰이더를 바인딩해 프레임 단위의 렌더링을 수행한다. ReSTIR 기반 Path Tracing의 경우 샘플링, 누적, 최종 결과 출력까지의 전 과정을 Renderer가 책임진다.
씬 상태 관리는 SceneManager가 담당하며, 가구 인스턴스와 조명 정보로 구성된 World 데이터를 유지하고, 백엔드로부터 전달된 Scene JSON을 파싱해 렌더러가 이해할 수 있는 형태로 변환한다. World 객체는 실제 렌더링 대상인 인스턴스와 라이트들의 집합을 표현하는 순수 데이터 컨테이너로, 프레임마다 Renderer에 전달된다.
마지막으로 WGSL Shader 모듈은 Compute Shader와 Vertex/Fragment Shader로 구성되어, Compute 단계에서는 ReSTIR 샘플링과 조명 누적 계산을 수행하고, 출력된 GPU Texture를 화면에 시각적으로 표현한다. 이러한 객체 분리는 복잡한 WebGPU 렌더링 파이프라인을 안정적으로 관리하고, 기능 확장과 유지보수를 용이하게 만드는 핵심 설계 요소이다.
WebGPU 렌더링 엔진 계층 구조
이 WebGPU 렌더링 구조는 UI → 엔진 중재자 → 렌더링 코어 → 씬 데이터 → GPU 셰이더로 단계적으로 책임을 분리한 계층형 아키텍처이다.
최상단의 React Component (UI Layer)는 LightingSimulator.tsx와 WebGPURenderer.tsx를 통해 사용자 입력과 화면 표시를 담당하며, 실제 GPU 제어는 직접 수행하지 않고 props와 callback 형태로 하위 계층에 전달한다.
그 아래의 WebGPUEngine 객체는 전체 렌더링 흐름의 중재자로서 WebGPU 디바이스 초기화, 입력 처리, 렌더러 인터페이스 제공, 렌더 루프 관리(onFrameTimeUpdate, onCameraUpdate)를 맡아 UI와 렌더링 코어를 느슨하게 결합한다.
핵심 렌더링 로직은 Renderer 클래스에 집중되어 있으며, GPU 리소스(Buffer, Texture) 생성, Render/Compute Pipeline 정의 및 생성, 파이프라인에 필요한 리소스와 WGSL 셰이더 바인딩을 담당한다.
씬 데이터는 SceneManager를 통해 관리되며, 내부적으로 World(인스턴스, 라이트 정보)를 유지하고, 백엔드 API로부터 전달받은 Scene Data(JSON)를 파싱하여 렌더러가 사용할 수 있는 형태로 변환한다.
최하단의 GPU Shaders (WGSL) 계층에서는 Compute Shader가 ReSTIR 기반 샘플링과 누적 계산을 수행해 GPU Texture에 결과를 기록하고, Vertex/Fragment Shader가 해당 결과를 화면에 출력함으로써 고품질 Path Tracing 기반 조명 시뮬레이션을 완성한다. 이 구조는 UI·엔진·렌더링·데이터·셰이더의 역할을 명확히 분리해 복잡한 WebGPU 렌더링 파이프라인을 확장 가능하게 설계한 것이 특징이다.
렌더링 작동 구조
GPU Resources
- UniformBuffer : 전역 변수 저장
- SceneBuffer / GeometryBuffer / AccelBuffer : 직렬화된 World 데이터 저장
- ReservoirBuffer : ReSTIR Path Tracing에 사용되는 Reservoir 데이터 저장
- MotionVectorBuffer : 이전 프레임과 현재 프레임 간 위치 변화 저장
- G-Buffer : 각 픽셀의 TraceRay() 결과 정보 저장
- SceneTexture : FrameCount=0부터 누적된 FrameColor의 산술 평균 저장
- ResultTexture : 현재 프레임에 출력할 색상 저장
Compute Pass
- Pass 01 : G-Buffer
- 각 픽셀마다 Camera Ray를 발사하여 Ray Tracing 결과를 G-Buffer에 기록
- Pass 02 : Motion Vector
- 각 픽셀별 Motion Vector를 계산하여 MotionVectorBuffer에 기록
- Pass 03 : Initialize
- Monte Carlo Path Tracer를 이용해 Path Tree 생성, 모든 Candidate Path를 Reservoir에 삽입
- Pass 04 : Temporal Reuse
- Motion Vector를 이용해 이전 프레임 Reservoir에서 유효 샘플을 추출하고 현재 Reservoir와 RIS 수행
- Pass 05 : Spatial Reuse
- 인접 픽셀의 Reservoir를 추출하여 현재 픽셀 Reservoir와 RIS 수행
- Pass 06 : Final Shading
- 최종 선택된 Sample의 색상을 결정하여 ResultTexture에 기록
백엔드 아키텍처
계층형 Architecture
백엔드 시스템은 Spring Boot 기반의 전형적인 계층형 아키텍처로 구성되어 있으며, 각 계층이 명확한 책임을 가지도록 분리되어 있다. 최상단의 Controller Layer는 HTTP 요청과 응답을 처리하는 진입점으로, 클라이언트로부터 전달된 REST 요청을 수신하고 DTO 검증을 수행한다. 인증 관련 요청은 AuthController, 씬 관리 요청은 SceneController에서 각각 담당하며, 이 계층은 비즈니스 로직을 직접 처리하지 않고 요청을 적절한 서비스 계층으로 위임하는 역할에 집중한다.
그 아래의 Service Layer는 애플리케이션의 핵심 비즈니스 로직이 구현되는 계층으로, 사용자 인증·인가 처리, 씬 저장 및 조회와 같은 도메인 로직을 수행한다. 이 계층에서는 트랜잭션 경계를 관리하여 데이터 정합성을 보장하며, AuthService와 SceneService는 하나의 유의미한 작업 단위를 구성하기 위해 여러 Repository를 조합해 사용한다.
Repository Layer는 JPA를 이용해 데이터베이스 접근을 추상화한 계층으로, UserRepository와 SceneRepository를 통해 CRUD 작업을 수행한다. 이를 통해 SQL 쿼리나 데이터 저장 방식에 대한 세부사항을 상위 계층으로부터 분리하고, 도메인 로직이 데이터 접근 기술에 종속되지 않도록 설계되어 있다.
최하단의 PostgreSQL Database는 users와 scenes 테이블을 통해 사용자 정보와 씬 메타데이터를 영속적으로 저장한다. JDBC 기반의 연결을 통해 안정적인 데이터 접근을 제공하며, 백엔드 시스템의 영속성 계층을 담당한다.
이와 같은 계층 분리는 관심사의 분리를 명확히 하여 유지보수성과 테스트 용이성을 높이고, 프론트엔드 및 렌더링 로직과 독립적으로 백엔드 시스템을 확장할 수 있도록 한다.
데이터베이스 설계
ERD 및 테이블 관계
이 데이터베이스 구조는 사용자(User)와 씬(Scene) 간의 소유 관계를 명확히 표현한 ERD로, 웹 기반 렌더링 서비스의 계정·콘텐츠 관리 요구사항을 반영한다.
Users 테이블은 서비스 이용자를 나타내며, id를 기본키(PK)로 사용하고 username, password, created_at 컬럼을 가진다. 이때 password는 보안 강화를 위해 평문이 아닌 BCrypt 해시 방식으로 암호화되어 저장되며, 이를 통해 비밀번호 유출 시에도 원문 복원이 불가능하도록 설계되어 있다.
Scenes 테이블은 사용자가 생성·저장한 렌더링 씬을 나타내는 테이블로, id를 기본키로 하고 name, description, assets(JSON), created_at, updated_at 등의 메타데이터를 포함한다. 특히 user_id 컬럼은 외래키(FK)로서 Users 테이블의 id를 참조하며, 하나의 사용자가 여러 개의 씬을 소유할 수 있는 1:N 관계 (Users 1 → Scenes N)를 형성한다.
assets 컬럼은 JSON 형태로 저장되어, 가구 배치 정보, 조명 파라미터, 카메라 설정 등 구조화된 씬 데이터를 유연하게 담을 수 있도록 한다. 이를 통해 씬 데이터 구조 변경 시에도 데이터베이스 스키마 수정 없이 확장이 가능하다.
이러한 설계는 사용자 단위의 씬 관리와 접근 제어를 용이하게 하며, 인증된 사용자만 자신의 씬을 생성·조회·수정할 수 있도록 백엔드 인증·인가 로직과 자연스럽게 연동된다.
