이성준

디자인 개편과 마이그레이션이 동시에 진행되면서 디자이너와 개발자가 재사용 기준 없이 화면을 만들면 서비스마다 구현 방식이 달라지고, 통일된 UI 체계를 세우기 어려운 상황이었습니다.

디자이너와 함께 Figma 컴포넌트를 기준으로 재사용 범위와 디자인 시스템 적용 가능성을 먼저 검증하고, 공통 UI와 브랜드별 스타일을 분리하는 구조를 설계했습니다.

TailwindCSS와 daisyUI를 채택하고 style layer로 framework 스타일을 커스터마이징했습니다. 프리미티브 UI를 조합한 Molecule/Organism 컴포넌트를 구축해 Storybook으로 화면과 개발 범위를 공유했고, 컬러·타이포그래피·breakpoint·spacing을 디자인 토큰으로 분리해 브랜드별 스타일을 앱 단위로 주입할 수 있게 설계했습니다.

Figma-Storybook-앱 구현이 같은 컴포넌트 단위로 연결되면서 디자인 일관성과 협업 생산성을 높였고, 동일 컴포넌트를 서비스별 브랜드 스타일에 맞게 재사용할 수 있는 기반을 마련했습니다.

디자인 시스템은 컴포넌트 구축 자체보다 재사용 기준과 운영 원칙을 디자이너와 먼저 합의하는 과정이 더 중요하다는 점을 확인했습니다.

기존 ASP 환경은 ASP 친화적인 개발자에게 업무가 편중되기 쉬웠고, 화면 로직과 정책이 여러 레이어에 분산돼 FE·BE 역할 경계가 모호했습니다. 또한 SP 기반 구조와 query가 함께 얽혀 있어 유지보수와 연동 방식 정리에 비효율이 있었습니다.

Next.js 마이그레이션을 계기로 FE·BE 책임 경계를 명확히 나누고, 화면 정책·연동 구조·공통 자산을 각 영역의 전문성에 맞게 관리할 수 있는 구조로 재편하고자 했습니다.

ASP 화면을 Next.js로 전환하면서 기존 SP 기반 구조와 query가 함께 얽혀 있던 연동 방식을 API 중심으로 재정리하고, Swagger 명세를 추적해 Orval로 API interface와 호출 함수를 자동화했습니다. 또한 공통 유틸리티와 UI를 모노레포 구조로 분리하고 패키지 버전까지 한곳에서 관리하도록 구성했습니다.

FE·BE 역할 경계가 명확해져 협업 효율과 유지보수성이 개선됐고, API 연동 코드와 패키지 관리가 표준화되면서 생산성을 높였습니다.

Lighthouse (dev환경 기준):

• Performance 5.3p, Best Practices 36.3p 개선
• FCP 약 16%, LCP 약 37%, TBT 약 60%, Speed Index 약 55%, TTI 약 66% 단축

마이그레이션 작업 중 API 스펙이 자주 변경돼 변경사항을 매번 공유받는 피로도가 컸고, 어떤 값이 어떻게 바뀌었는지 프론트엔드에서 빠르게 파악하기도 쉽지 않았습니다.

Swagger 결과물을 기준으로 직전 배포 대비 변경점만 비교해, 프론트엔드가 먼저 확인해야 할 API와 변경 범위를 빠르게 식별할 수 있는 자동화 구조를 만들고자 했습니다.

AI를 활용해 Docker 기반 n8n workflow를 설계·구현하고, 각 서비스의 Swagger JSON에서 METHOD + path 기준 endpoint snapshot을 생성해 직전 snapshot과 비교하는 구조를 만들었습니다. parameters, requestBody, responses만 추려 변경점을 added, changed, removed로 분류했고, $ref는 가능한 범위에서 실제 schema 기준으로 해석해 diff를 계산한 뒤 변경된 API 링크와 함께 Slack 봇으로 알림하도록 구성했습니다. 또한 닷컴·북스·컨텐츠 3개의 서비스에 대해 workflow를 운영해, 프론트에서 관리하는 서비스 전반의 API 변경을 탐지할 수 있게 했습니다.

API 변경사항을 수동으로 공유하는 부담을 줄였고, 프론트엔드가 확인해야 할 endpoint와 변경 범위를 빠르게 파악할 수 있게 해 마이그레이션 대응 속도와 협업 효율을 높였습니다.

전시 페이지와 이벤트성 모집 페이지는 목적과 트래픽 특성이 달랐고, 특히 선착순 모집 페이지는 짧은 시간에 사용자가 집중돼 일반적인 방식으로 운영하면 서버 부하와 사용자 대기 경험 저하가 발생할 수 있었습니다.

페이지 목적에 따라 SSR/CSR 렌더링 전략을 분리하고, 모집 페이지는 서버 부담을 줄이면서도 대기 상태를 명확히 인지할 수 있도록 캐싱 전략과 로딩 UX를 함께 설계했습니다.

전시·성적 조회 등 서버 렌더링이 필요한 화면은 SSR로 유지하고, 모집·이벤트 페이지는 CSR + S3 기반으로 구성했습니다. 선착순 모집 페이지에는 TTL 기반 캐싱을 적용하고, 실제 응답 대기 구간에 맞춘 로딩 화면을 구현했습니다.

동시 접속 16,000명 규모의 모집 페이지를 안정적으로 운영하며 서버 리소스 부담을 낮췄고, 페이지 특성별 렌더링 전략 기준을 정리해 신규 페이지 개발과 수정 시 판단 기준을 명확히 만들었습니다.

트래픽 대응은 기능 완성보다 병목 지점을 먼저 분리하는 설계가 핵심이었고, 렌더링 전략 기준을 초기부터 더 명확히 문서화했다면 운영 중 의사결정 비용을 더 줄일 수 있었겠다고 판단했습니다.

디자인이 확정되지 않은 상태에서 개발을 병행해야 했고, 특히 전시 페이지마다 자사 상품의 테마가 달라 화면 변경 범위와 재작업 비용이 커질 수 있었습니다.

디자인 변경에 유연하게 대응할 수 있도록 필요에 따라 조립하여 사용할 수 있는 구조를 우선했습니다.

컴파운드 패턴 기반의 재사용 컴포넌트를 정의해 화면마다 필요한 요소를 조합해 사용할 수 있도록 했고, 로직은 관심사별 컴포지션으로 분리해 필요한 기능을 조립하는 방식으로 설계하고 구현했습니다.

공통 UI와 반응형 유틸리티를 정비해 이후 화면 유지보수 속도와 일관성을 개선했습니다.

진행 중이던 프로젝트는 있었지만 기존 팀이 사라진 상태에서, 서비스를 안정적으로 오픈하고 운영해야 하는 문제가 발생했습니다.

빠른 운영 대응과 협업 일관성을 위해 코드 품질 규칙과 커밋 규칙을 표준화하고, 작업 히스토리를 추적할 수 있는 기준을 함께 정리했습니다.

Nuxt.js 기반 JavaScript 프로젝트에 TypeScript 설정을 확장하고 API interface를 생성했으며, 페이지 interface와 매핑하는 mapper layer를 도입했습니다. 또한 일관된 코드 품질 유지를 위해 ESLint를 적용하고 git commit formatter 를 개발·도입했습니다.

JavaScript 기반 코드에 TypeScript를 확장해 타입 안정성과 협업 생산성을 높였고, mapper layer 도입으로 API 응답값 정규화와 페이지 모델 변환 책임을 분리했습니다. 이를 통해 API 스펙 변경 시 페이지 컴포넌트 전체를 수정하지 않고 변환 계층만 조정할 수 있게 해 유지보수성과 대응 속도를 개선했습니다. 또한 작업 중인 Jira를 커밋에 자동 기입해 작업 히스토리와 코드 추적 용이성을 높였습니다.

인수인계 문서는 주기적으로 최신화해야 하고, 그렇지 못한 경우에는 함수 호출부나 컴포저블 수준에서 코드의 의도와 목적을 드러내야 한다고 느꼈습니다. 또한 복잡한 워크플로우는 선언형 코드와 주석, Jira·Confluence 링크를 함께 남겨 히스토리를 추적할 수 있게 해야 정보가 부족한 상황에서도 빠르게 맥락을 복원할 수 있다고 판단했습니다.