VAC 패턴 기반 3D 에디터 아키텍처

3D 엔진 개발자분들이 만든 엔진 API가 명령형이었어요. engine.setMaterialColor(id, hex) 처럼 호출하면 뷰가 바뀌는 방식이죠. 반면 React는 선언형이라서 "상태가 이러면 화면은 이거다"가 자연스러운 사고예요. 이 두 패러다임을 그냥 섞으면 컴포넌트 안에 useEffect 가 명령형 호출로 가득 차고, 엔진 API가 한 번 바뀔 때마다 70개 컴포넌트를 다 뒤져야 하는 상황이 됩니다.

그래서 세 계층으로 책임을 나눴어요. View는 진짜로 받은 prop을 그리기만 하는 dumb 컴포넌트, Action은 엔진의 명령형 API를 선언형 훅으로 래핑하는 어댑터 레이어, Container는 Atom 상태와 Action 훅을 조합해서 "지금 사용자가 무엇을 하려는가"라는 비즈니스 로직을 담당합니다. 이렇게 분리하니까 엔진 API 스펙이 바뀌어도 어댑터 훅 한 군데만 수정하면 됐고, 70개 넘는 에디터 UI는 영향 없이 계속 동작했어요.

View는 정말로 dumb 합니다. props만 받고 JSX만 뱉어요. 컬러피커 UI라면 색상 배열과 onChange 콜백만 받고, 어떤 atom을 구독하거나 엔진을 호출하는 일은 일절 없어요. 그래서 storybook에서 prop만 바꾸면 모든 상태가 재현되고, 디자이너분들이 수정 요청을 줘도 View 파일만 보면 끝나요.

Action 레이어는 엔진의 명령형 메서드를 선언형 훅으로 감쌉니다. 단순 1:1 래핑이 아니라 의미 있는 단위로 묶어요. 예를 들어 "소재의 컬러를 바꾼다"는 동작은 엔진 입장에서는 색 적용 + 미리보기 갱신 + 히스토리 푸시 세 단계인데, Action 훅에서는 useChangeMaterialColor() 하나로 묶어서 노출합니다.

Container는 atom과 Action을 조합해서 "화면의 비즈니스 룰"만 들고 있어요. 예를 들어 "프리미엄 사용자만 컬러 시스템 X를 쓸 수 있다"는 정책은 Container 안에서 atom과 권한 데이터를 조합해 결정하고, 결과를 View에 props로 내려줍니다. 의존성 방향은 항상 Container → Action·Atom → View 단방향이어서, 역방향 의존이 생기면 ESLint 룰로 막았습니다.

가장 흔한 패턴이 "엔진을 source of truth로 두고 atom은 그걸 미러링한다"는 구조였어요. 예를 들어 useMaterialColor(matId) 라는 훅을 만들면, 내부에서 두 가지 일을 합니다.

첫째, 마운트될 때 엔진의 컬러 변경 이벤트를 구독해서 atom에 푸시해요. 그러면 다른 컴포넌트가 같은 atom을 구독하고 있다가 React 식으로 자동 리렌더링됩니다. 둘째, setter를 호출하면 atom 값을 업데이트하고 동시에 엔진 명령(engine.setMaterialColor)을 호출합니다. 그러면 엔진 이벤트가 다시 돌아와도 같은 값이라 무한 루프 없이 멈춰요.

훅 시그니처를 useState 와 똑같이 [value, setValue] 형태로 통일한 게 포인트예요. 동료 분들이 "엔진을 다룬다"는 사실을 신경 쓸 필요 없이, 그냥 useState 처럼 쓰면 화면이 바뀌고 엔진도 바뀌는 경험을 하게 만들었습니다. DX 면에서 학습 비용이 거의 0에 수렴했어요.

3D 에디터에서 소재가 많아요. 한 화면에 컬러칩이 수백 개 떠 있고, 각자 독립적으로 편집됩니다. 처음에는 단일 atom으로 Record<MaterialId, MaterialState> 같은 큰 객체를 들고 있었는데, 한 소재의 색깔만 바꿔도 객체 참조가 바뀌니까 그 atom을 구독하는 모든 컴포넌트가 리렌더됐어요. 화면 단위 frame drop이 보일 정도였습니다.

Jotai의 atomFamily는 id 같은 인자로 atom을 캐싱해서 만들어 줍니다. materialColorAtom('matA') 와 materialColorAtom('matB') 가 서로 다른 인스턴스가 되니까, matA 색을 바꾸면 matA를 구독하는 컴포넌트만 리렌더돼요. 트리 전체가 흔들리던 게 정확히 그 칩 한 개만 흔들리는 형태로 바뀌었습니다.

부수 효과로 selector 코드가 깔끔해졌어요. 기존엔 큰 객체에서 state.materials[id].color를 뽑아내는 selector를 매번 만들어야 했는데, 이제는 그냥 atom을 호출하면 되니까요.

컬러 시스템이 세 가지였는데 입력·검색·렌더링 규칙이 다 달랐어요. Picker는 RGB 슬라이더, Pantone은 코드 검색, Coloro는 5자리 숫자 코드처럼요. 처음엔 컴포넌트 내부에서 if (system === 'pantone') { … } 로 분기했는데, 새 시스템(예: HKS)을 추가할 때마다 모든 분기 지점을 찾아 수정해야 해서 부담이 컸어요.

Strategy 패턴을 적용했어요. ColorSystemStrategy 라는 공통 인터페이스를 정의하고 — search(query), parse(input), format(color), swatches() 같은 메서드 — 각 시스템을 구현체로 따로 만들었습니다. 컬러 편집 컴포넌트는 Context로 현재 strategy를 받아서 그냥 strategy.search(q)만 호출해요. 새 시스템을 추가할 때 구현체 파일 하나 만들고 Context에 등록만 하면 되고, 기존 컴포넌트 코드는 한 줄도 안 건드립니다. OCP가 그대로 만족됐어요.

이 설계 덕에 디자이너분들이 컬러 시스템을 늘리자고 제안할 때 "1주 안에 가능합니다"가 자연스럽게 나오는 환경이 됐고, 실제로 신규 시스템 추가는 평균 2~3일 안에 끝났습니다.