UI 빌더를 지탱하는 레고 블록 같은 아키텍처 만들기

대부분의 프론트엔드 개발 조직은 회사 안에서 지원 조직 형태로 존재하며, 비즈니스가 급격히 성장하면 제품과 기술이 파편화되기 시작한다. 체계화 속도보다 조직 성장 속도가 빠르면 비용이 급증하고 개발·운영이 힘들어지는데, 사람을 뽑아 해결하려 해도 팀은 무한정 늘 수 없다. 그래서 커뮤니티에서는 디자인 시스템으로 기술과 커뮤니케이션을 표준화하려는 시도가 많고 최근 이 트렌드가 UI 빌더까지 가고 있다. 발표자는 잘 정의된 블록이 있으면 조합해 더 큰 것을 만들 수 있다는 아토믹 디자인의 믿음이 "레고 블록을 조립하듯 애플리케이션을 만들고 싶다"는 상상으로 이어진다고 설명하면서도, "그런 레고는 세상에 아직 없고 나도 못 만들었다"고 솔직히 밝힌다. 대신 어떤 방향으로 나아갈지 "북극성"을 정해놓고 끊임없이 시도하면 그 근처에 다다를 수 있다며, 오늘 이야기는 꿈을 쫓는 팀의 이야기라고 말한다.

팀은 자체 프로덕트 없이 서비스의 UI 커스터마이제이션 요청을 받아 만들어 주는 "개발 대리인"으로 일해왔는데, 서비스가 많아질수록 팀을 계속 늘려야 하고 비용이 증가하며 기술이 파편화됐다. 그 문제 해결이 2021~2022년의 미션이었고, 지속 성장을 위해 "개발 대리인"이 아니라 "기술 제공자"로 변신하기로 한다. 우리는 블록을 제공하고 서비스는 그 블록을 가져다 자신들의 문제를 해결하게 한다는 방향이다. 착수는 데이터 플로우부터였는데, Undo/Redo와 향후 동시 편집의 복잡도를 낮추기 위해 타임 트래블링이 유리한 Redux를 큰 틀 그대로 가져왔다. 그리고 코어(Core)에 기본 재료를 배치한 뒤 프로덕트에서 조립해 빌더를 만드는 평범한 2-tier 아키텍처를 잡았는데, 발표자는 "누구에게나 계획은 있다, 얻어맞기 전까지는"이라며 이 계획이 세 가지 문제에 부딪혔다고 예고한다.

발표자는 세 문제가 실제로는 겹쳐 있지만 설명을 위해 발라냈다며 각각을 "증상 → 진단 → 처방" 순으로 풀어간다. 첫 번째 문제는 "너무 깐깐한 코어 로직"으로, 프로덕트 스펙을 구현하는데 자꾸 코어 계층 코드를 수정하게 되는 증상이다. 홈빌더 1.0의 템플릿 페이지를 페이지·컨테이너·컴포넌트 계층으로 바라보는 것이 팀의 UI 세계관인데, 코어의 useCase에 모아둔 훅들을 보니 AddComponentLayer 훅, AddContainerLayer 훅, AlertLayer 훅 등이 있었다.

"AddComponent"는 컴포넌트 삽입 레이어(팝업)를 제어하는 훅으로 제품 스펙의 느낌이 난다. 이 훅이 UX를 "레이어/팝업"으로 코어에서 결정해 버리면, 팝업이 아닌 다른 형태가 필요할 때나 기능이 추가될 때마다 코어 코드를 건드려야 한다. 왜 이렇게 했는지 돌아보면, 당시 팀은 헤드리스(Headless) UI처럼 "로직은 우리가 줄 테니 뷰는 만들어 쓰세요"라는 생각으로 최대한 많은 것을 해주려 했다. 그 생각 자체가 나쁜 것은 아니지만, 문제는 코어와 프로덕트의 구분이 모호해진다는 데 있다고 다음으로 넘긴다.

코어는 계층에서 파운데이션(재료) 역할인데 파운데이션이 프로덕트 스펙을 결정하면 코어의 입지가 좁아진다. 진단은 "계층이 부족하고 책임이 불분명하다"였고, 처방으로 재료 → 에디터/뷰어 → 서비스 애플리케이션으로 이어지는 공정을 그대로 계층으로 옮겨, 흩어져 보이지 않던 도메인을 끄집어내 한데 모으고 "서비스 애플리케이션 / UI 빌더 / 모듈·상태관리 / 기초 라이브러리·유틸리티"의 4계층을 구성했다. 두 번째 문제는 "너무 무거워지는 프로덕트 뷰"로, 코어에 Atom이 13개인데 프로덕트에는 46개나 있었다. 코어가 부품을 안 주니 프로덕트 개발자가 직접 만들고 다른 프로덕트도 또 만드는 식이었다. 진단은 "UI 파운데이션 부재"였고, 디자이너 없는 엔지니어링 팀이라는 제약 속에서 Chakra UI를 채택해 디자인 시스템을 만들되 상위 조직 디자인 시스템으로 교체될 가능성을 고려해 계층 바깥으로 분리했다.

세 번째 문제는 "너무 길어지는 커스텀 동선"으로, 커스텀 컴포넌트 하나를 추가하는 데 8군데를 고쳐야 했고 에러가 나도 어디서 빠뜨렸는지 찾기 어려웠다. 진단은 "사용자 관점 부재"였고, 변경을 모듈화해 동선을 최소화하기로 했다. 블록이 가져야 할 네 관심사(Model·View·Logic·Property)를 "사정을 가장 잘 아는 자에게 책임을 준다"는 원칙으로 분산해, Model·View·Logic은 블록에 모으고 일관성이 필요한 Property는 UI 빌더가 책임지되 "어떤 Property를 쓸지"는 블록이 매니페스트(Manifest) 파일에 선언적으로 정의하게 했다. 이렇게 풀다 보니 "모든 것이 플러그인이 될 수 있다"는 깨달음에 도달해, UI 레이아웃을 슬롯으로 나누고 단축키·자동 저장 같은 기능도 인터페이스를 통일해 블록·글로벌 UI 컴포넌트·프로바이더·글로벌 피처 4종의 플러그인으로 묶었다. 다만 확장성으로 얻을 비즈니스 가치가 없으면 오버엔지니어링이고 보안·최적화·버전 관리가 까다로워진다며 "공짜 점심은 없다"고도 짚는다. 마지막으로 발표자는 아래 계층일수록 재조립 비용이 크므로 DDD처럼 도메인을 격리해야 한다고 조언하고, 2023년의 도전 과제로 "한 블록에 N개의 데이터 소스 연결"과 AI(엔빌리×클로바: 스케치 사진을 웹페이지로) 결합을 제시하며 함께 성장할 동료를 찾는다는 인사로 발표를 마친다.