"어드민스튜디오" 웹 에디터 설계하기: 스키마 기반 렌더링, 데이터 연동과 인프라까지 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#react#domain-specific-language#indexeddb#openapi#web-editor#content-addressable-storage

AI 요약

우선순위와 유지보수의 사각지대에 놓인 사내 admin을, 누구나 표준화된 형태로 만들 수 있도록 editor·viewer·server로 구성한 Admin Studio의 전체 아키텍처를 소개한다. 개별 admin을 하나하나 개발하는 대신 규칙이 내장된 editor를 제공해 일관성과 유지보수성을 확보한다는 목표에서 출발한다.

핵심 포인트

Studio DSL은 project·block·property·handler 관계를 JSON으로 정의해 변경 시 재빌드가 필요 없고, block renderer가 DSL을 해석해 API data를 가져오고 string handler를 실제 동작에 연결
편집 UI를 rendering code에 섞으면 editor·viewer 일치와 성능이 깨지므로 preview와 selection·drag interaction을 별도 layer로 분리, Ref·MutationObserver·position cache로 위치를 추적하고 event bus로 module 결합을 느슨하게 함
제각각인 backend API 대신 OpenAPI Specification을 유일한 계약으로 삼아 fetch·parse·validation·DSL 변환 pipeline을 구축, data manager가 DSL을 single source of truth로 두고 IndexedDB autosave로 새로고침·crash 복구
server 저장은 Git에서 착안해 immutable definition과 version snapshot을 분리하고 SHA-256 content-addressed storage로 중복을 제거, CloudFront alternate domain과 단일 viewer로 admin마다 infra를 새로 만들지 않고 다중 domain 제공

왜 읽나schema 기반 사내 툴/노코드 에디터를 설계하는 프론트엔드 개발자에게, DSL 렌더링·interaction 분리·OAS 연동·version 저장·배포를 관통하는 아키텍처 레퍼런스.

챕터별 상세

012:00 – 7:24

개별 개발 대신 표준화된 admin editor

내부 admin은 product 기능보다 우선순위가 낮아 개선이 늦고 화면마다 사용성이 달랐으며, frontend developer가 개입하지 않은 project는 기술 최신화와 보안 대응에서도 사각지대가 됐다. 팀은 admin 하나하나를 개발하는 대신 규칙이 내장된 editor를 제공해 누구나 빠르게 표준 화면을 만들고, 공통 design system과 기반 code로 유지보수성과 일관성을 확보한다는 목표를 세웠다.

Studio DSL은 admin project, block, property와 handler 관계를 JSON으로 정의하는 domain-specific language라서 정의를 바꿀 때 application을 다시 build하지 않아도 된다. Block renderer는 DSL을 해석해 필요한 API data를 가져오고 string으로 선언된 event handler를 실제 동작에 연결한 뒤 component를 render하므로, 화면 정의와 구현 code를 분리하면서도 feature를 조합할 수 있다.

편집용 UI를 실제 rendering code 안에 섞으면 editor와 viewer가 같은 화면을 보장하기 어렵고 복잡한 page의 performance도 떨어지므로, preview rendering과 selection·drag 같은 interaction을 별도 layer로 분리했다. Ref, MutationObserver와 position cache로 block 위치를 추적하고 event bus가 toolbar·panel·canvas module의 직접 참조를 제거해, 느슨하게 결합된 module들이 선택과 변경 event를 주고받도록 구성했다.

형태가 제각각인 장기간의 backend API를 직접 지원하는 대신 OpenAPI Specification을 유일한 계약으로 삼아 fetch, parse, validation, Studio DSL 변환과 역변환 pipeline을 구축했다. Data manager는 DSL을 single source of truth로 보관하고 필요한 subscriber만 갱신하며, TanStack adapter 뒤의 IndexedDB에 autosave해 새로고침과 browser crash에도 작업을 복구하고 향후 server storage로 바꿀 수 있게 했다.

Server 저장은 Git에서 착안해 immutable definition과 project 전체를 가리키는 version snapshot을 분리하고, SHA-256 hash를 identifier로 사용하는 content-addressed storage로 같은 내용을 중복 저장하지 않는다. 배포 시 선택한 version을 viewer가 불러오며, CloudFront alternate domain과 하나의 viewer application을 조합해 admin마다 frontend infra를 새로 만들지 않고도 여러 domain을 동일한 runtime에서 제공한다.