Display Lab 개발 여정: 빈 공간을 채우기 위한 기술 의사결정들
수천만 원대 전문 도구와 단순 계산기 사이의 빈자리를 채우기 위해 Display Lab을 어떻게 만들었는지, 기술 선택과 개발 과정을 솔직하게 공유합니다.
디스플레이 분야에 오래 있다 보면 이런 불편함을 반복적으로 경험하게 됩니다. 동료가 보내온 측정 데이터를 분석하려면 수천만 원짜리 소프트웨어 라이선스가 있어야 하고, 그게 없으면 파이썬 스크립트를 직접 짜거나 아니면 그냥 포기합니다.
Display Lab은 그 불편함에서 시작했습니다. 하지만 "좋은 도구가 필요하다"는 생각만으로는 부족했습니다. 실제로 만들기까지 수십 개의 기술 의사결정을 해야 했고, 그 결정들이 지금의 Display Lab을 만들었습니다. 이 글은 그 결정들에 대한 이야기입니다.
왜 만들었나 — 시장의 빈 공간
Display Lab을 기획할 때 처음 그린 그림은 단순했습니다.
| 도구 유형 | 예시 | 가격 | 문제점 | |-----------|------|------|--------| | 전문 데스크탑 SW | Fluxim Setfos, CalMAN, ColourSpace | 수천만 원/년 | 개인·소규모 팀 접근 불가 | | 파이썬 라이브러리 | colour-science | 무료 | 코딩 필수, 시각화 따로 구현 | | 단순 웹 계산기 | Bruce Lindbloom, 개인 블로그 | 무료 | 단일 기능, 구형 UI | | Display Lab | - | 무료 | 빈 공간 |
이 표의 세 번째 행과 네 번째 행 사이에는 아무것도 없었습니다. 전문가가 코딩 없이 브라우저에서 바로 쓸 수 있는, 그러면서도 색과학적으로 정확한 도구. 그게 우리가 채우려 한 자리였습니다.
특히 시야각 분석(Viewing Angle Analysis) 분야는 웹 기반 도구가 전무했습니다. 고니오미터로 측정한 CSV 데이터를 업로드하면 극좌표 플롯과 색차 히트맵을 바로 보여주는 도구 — 이건 완전한 블루오션이었습니다.
ISCV 기술 자산 재활용 — 시행착오 없이 시작하는 법
Display Lab 개발을 시작하기 전에 우리에게는 이미 쓸 수 있는 것들이 있었습니다. 바로 자사의 이전 프로젝트인 **ISCV (Interactive Spectrum & Chromaticity Visualizer)**입니다.
ISCV는 스펙트럼 데이터를 CIE 다이어그램 위에 시각화하는 단일 목적 도구였습니다. 이 프로젝트에서 우리는 다음 것들을 만들었습니다.
- CIE 1931/1976 색도 다이어그램 렌더링 (D3.js 기반)
- 스펙트럼 Locus의 Cubic Spline 보간 (C2 연속성 보장)
- CSV 파싱 및 스펙트럼 데이터 처리 파이프라인
- sRGB, DCI-P3, BT.2020 색역 오버레이
이 코드들은 Display Lab의 핵심이 될 수 있었습니다. 하지만 단순히 복사-붙여넣기로는 충분하지 않았습니다.
재활용 전략: Fork → 모듈화 → 공유 라이브러리
우리가 선택한 접근법은 단계적 전략이었습니다.
MVP 단계 (현재): ISCV에서 필요한 모듈을 추출해 Display Lab에 직접 포함. 빠른 개발이 우선이었고, 코드 중복을 기술 부채로 인식하고 등록해두었습니다.
Phase 2 (예정): 공통 로직(CIE 계산, 색역, D3 다이어그램)을 @sidequestlab/color-science로 추출해 두 프로젝트가 동일한 라이브러리를 참조하도록 전환.
이 결정 덕분에 MVP-A(색역 분석기 + 색과학 계산기)는 하루 만에 배포할 수 있었습니다. D3.js CIE 다이어그램 렌더링만 해도 새로 만들면 2-3일이 걸리는 작업인데, 검증된 코드를 가져와 쓸 수 있었으니까요.
기술 의사결정 — 왜 그 선택을 했는가
Vite + React (Next.js 대신)
Display Lab을 기획할 때 처음 떠오른 선택지는 Next.js였습니다. SidequestLab의 다른 프로젝트들도 대부분 Next.js를 씁니다. 그런데 Display Lab에는 Next.js를 쓰지 않았습니다.
핵심 이유는 하나였습니다. Display Lab의 계산 로직은 100% 클라이언트 사이드입니다.
사용자가 업로드하는 CSV 측정 데이터는 서버로 전송되지 않습니다. 모든 CIE 계산, ΔE 연산, D3 렌더링이 브라우저 안에서 일어납니다. 이건 단순한 구현 디테일이 아니라 프라이버시 정책의 핵심이기도 합니다. "Your data never leaves your browser." 이 문장을 지키려면 서버 사이드 렌더링이 필요 없었습니다.
또 다른 이유는 ISCV와 동일한 스택 유지입니다. D3.js와 Vite의 조합은 HMR(Hot Module Replacement)이 빠르고, 복잡한 SVG 조작 디버깅에 유리합니다. CIE 다이어그램처럼 수백 개의 SVG 엘리먼트를 다루는 작업에서 이 차이는 체감됩니다.
D3.js 기반 시각화
색도 다이어그램을 렌더링하는 방법은 여러 가지가 있습니다. Canvas API로 직접 그리거나, WebGL을 쓰거나, SVG를 직접 조작하거나.
우리가 D3.js를 선택한 이유는 색과학 커뮤니티의 관습 때문입니다. CIE 1931 다이어그램의 Spectral Locus는 단순한 폴리라인이 아닙니다. 380nm~780nm 구간의 표준 관찰자 데이터를 기반으로, Cubic Spline 보간을 통해 C2 연속성을 보장하는 부드러운 곡선이어야 합니다. D3.js의 d3.line().curve(d3.curveCatmullRom) 계열은 이런 요구사항에 자연스럽게 대응합니다.
D3.js 기반 시각화의 실제 도전은 성능이었습니다. 시야각 히트맵처럼 데이터 포인트가 많은 경우 DOM 조작이 병목이 됩니다. 이 문제는 D3 static/dynamic 레이어 분리로 해결했습니다. 기준이 되는 Locus와 색역 표시는 정적 SVG 레이어에, 사용자 데이터 오버레이는 동적 레이어에 렌더링해 불필요한 재계산을 피했습니다.
자체 i18n 구현 — react-i18next 미사용
Phase 2-B에서 영문/한국어 듀얼 언어를 추가할 때 가장 먼저 고려한 것은 react-i18next였습니다. 업계 표준이고, 기능도 풍부합니다.
그런데 Display Lab의 다국어 요구사항을 분석해보니 상황이 단순했습니다. UI 문자열 두 언어 지원, 숫자 포맷은 공통(색좌표는 소수점 표기 공통), 날짜 포맷 없음. 전체 번역 문자열은 200개 미만.
react-i18next를 도입하면 번들 사이즈가 늘어나고, 복잡한 설정이 필요하며, SPA 초기 로딩에 i18n 초기화 오버헤드가 생깁니다. 전문가 도구에서 초기 로딩 속도는 중요합니다.
결국 useContext 기반의 자체 i18n 훅을 구현했습니다. 코드는 100줄 미만이고, 번들 추가 없이 언어 전환이 동작합니다. 복잡한 요구사항(복수형, 날짜 포맷, RTL)이 생기면 그때 라이브러리를 도입하기로 했습니다.
카카오 애드핏 수익화 통합
전문가 대상 도구에 광고를 넣는 것은 항상 조심스러운 결정입니다. 사용자 경험을 해치면 오히려 역효과입니다.
Display Lab의 광고 정책은 두 가지 원칙으로 정리했습니다. 첫째, 분석 인터페이스를 방해하지 않는 위치. 둘째, 환경변수 기반 관리로 테스트 환경에서는 광고 비활성화.
기술적으로는 Graceful Fallback을 구현했습니다. 광고 SDK 로딩이 실패하거나 광고 슬롯이 비어있을 때 레이아웃이 깨지지 않도록, 광고 컴포넌트는 빈 공간을 fallback으로 처리합니다. PC용 728x90 배너와 모바일용 320x100 배너를 분기해서 표시합니다.
개발 속도 — MVP-A/B를 하루 만에, 8모듈을 이틀 만에
가장 자주 받는 질문 중 하나가 "어떻게 그렇게 빨리 만들었냐"입니다.
MVP-A와 MVP-B는 각각 하루 만에 배포되었습니다. Phase 2-A/B를 합쳐도 이틀이 채 걸리지 않아 8개 모듈로 확장되었습니다.
이 속도의 비결은 두 가지입니다.
첫째, 기술 자산 재활용. ISCV에서 검증된 D3.js CIE 다이어그램 코드는 Display Lab의 Color Gamut Analyzer와 Viewing Angle Analyzer 모두에서 재사용되었습니다. 새로 만드는 게 아니라 기존 코드를 확장하는 방식이었습니다.
둘째, 정확도 검증 우선 전략. 계산 로직을 먼저 단위 테스트로 검증하고 UI를 붙이는 방식을 택했습니다. ΔE2000 계산은 Sharma et al. (2005) 논문의 33쌍 테스트 데이터로, CIE 좌표 변환은 CIE 15:2004 표준 예제로 검증했습니다. 배포 후 "계산이 틀렸다"는 피드백을 받는 상황을 사전에 차단했고, 전문가 사용자에게 신뢰를 얻는 핵심이었습니다.
물론 속도와 함께 QA 파이프라인도 함께 돌렸습니다. MVP-A에서 QA 버그 4건, MVP-B에서 2건을 수정한 후 배포했습니다. "빠르게"와 "검증 없이"는 다른 말입니다.
배운 점과 다음 단계
이 프로젝트에서 얻은 가장 중요한 교훈 세 가지입니다.
1. 기술 자산은 진짜 자산이다. ISCV 프로젝트가 없었다면 Display Lab의 개발 속도는 절반 이하였을 겁니다. 프로젝트 간 기술 재활용은 코드 복붙이 아니라, 검증된 구현을 확장하는 것입니다.
2. 정확도가 신뢰의 기반이다. 전문가 도구에서 "대략 맞다"는 통하지 않습니다. CIE 표준 기반 검증 배지 하나가 마케팅 문구 열 개보다 효과적입니다. 시간을 들여 검증 테스트를 구축한 것이 옳은 결정이었습니다.
3. 라이브러리 도입은 필요할 때 하는 것이다. i18n을 자체 구현한 것처럼, 현재 요구사항에 맞지 않는 도구를 미리 도입하면 불필요한 복잡성이 생깁니다. 단순하게 시작하고, 필요할 때 확장하는 원칙을 지켰습니다.
다음 단계 — Phase 2-C에서는 세 가지 기능을 추가할 예정입니다.
- 분석 결과를 저장하고 이력 관리가 가능한 데이터베이스 연동
- 전문적인 보고서 형태로 내보낼 수 있는 PDF 리포트 생성
- 외부 시스템 연동을 위한 RESTful API 제공
Display Lab은 여전히 진화 중입니다. 디스플레이 엔지니어링 현장에서 실제로 겪는 불편함이 있다면 알려주세요. 그게 다음 기능이 될 수 있습니다.
SidequestLab 드림