K-Contents IP Market

swiper/react는 클라이언트 JS가 있어야 슬라이드 DOM·높이가 잡힙니다. SSR에서 빈 영역으로 두거나 하이드레이션 때 갑자기 Swiper를 끼우면 레이아웃이 밀리며 CLS가 납니다.

BannerSwiper는 useEffect로 isClient를 true로 올린 뒤에만 <Swiper>를 렌더합니다. 그 전에는 max-w-[689px]와 aspect-[12/5] 스켈레톤(또는 고정 width/height 이미지)으로 같은 자리를 미리 채웁니다.

로딩 중에도 동일 비율 플레이스홀더를 유지해, 데이터 도착·Swiper 마운트 사이 레이아웃 이동을 줄였고 CLS 0.1을 확보했습니다.

콘텐츠 카테고리가 10개이고 등록 단계(기본/판매/홍보)마다 필드가 달라, 페이지를 카테고리마다 두거나 거대 분기를 두면 유지보수가 어렵습니다.

src/features/submission에서 FormSchema(섹션→필드그룹→필드→아이템)를 카테고리·경로별로 고르고, FormRenderer → SectionRenderer → FieldGroupRenderer → FieldRenderer → ItemRenderer가 type별 입력을 그립니다. buildSchema는 readonlySubmissionStatus를 하위로 전파합니다.

renderCondition/disableCondition은 useEvaluator가 OR-of-AND로 평가하고, map 섹션은 판매·계약 유형 배열만큼 같은 필드를 반복합니다. useValidator·useTransformer·usePopulator가 같은 스키마로 검증·DTO 변환·초기화를 맞춰, 필드 추가·수정은 스키마 파일 변경으로 끝납니다.

픽셀 단위 수정 요청이 잦아, 프로덕션 배포를 기다리거나 자리를 옮겨 화면을 보여주거나 캡처만 공유하는 방식이 병목이었습니다.

로컬 Next.js HMR 개발 서버를 ngrok으로 터널링해 URL을 디자이너에게 전달했습니다. 수정이 저장되는 즉시 디자이너 자리에서 같은 화면을 확인할 수 있어 검수 왕복 시간을 줄였습니다.

도구 자체보다 협업 프로세스 개선에 가깝지만, 프론트 작업 속도와 디자인 QA 품질에 직접 영향을 준 사례로 남겼습니다.