Section
책방 (Chaekbang)
2024.12 — 2025.04·Frontend EngineerPrivate부산·해운대구·장산 (좌동)
Next.jsStorybookZodFSD
프로젝트 핵심 요약
문제에서 결과까지- Storybook·디자인 토큰
- 공통 UI
- 폼·API 검증 통합
- Zod
- 인증·오류 처리 일원화
- 공통 fetch
- 문제
- 관리자·선생님 화면에서 반복되는 UI와 인증·검증 처리를 일관되게 관리하고, API 변경에 대응할 수 있는 공통 구조가 필요했습니다.
- 판단
- Storybook·디자인 토큰으로 UI를 문서화하고, Zod·공통 fetch로 검증과 API 처리를 모았습니다. FSD로 기능별 코드와 재사용 코드의 경계를 정했습니다.
- 내 기여
- 관리자·선생님 화면과 공통 컴포넌트를 개발했습니다. 폼·API 데이터 검증, 인증 헤더·토큰 만료·오류·리디렉션, API Route·미들웨어 접근 제어를 구현했습니다.
- 결과
- 여러 API 응답을 Next.js 서버에서 통합·가공하고 자주 호출되는 데이터를 캐싱했습니다. 반복 구현과 요청을 줄이고 기능 변경 시 수정 범위를 좁혔습니다.
범위와 측정 기준 · 입사지원서 v9에 기술한 담당 업무 기준입니다. 감소율의 측정 근거를 최신 문서에서 확인할 수 없어 개선 내용 중심으로 표현했습니다.
Overview
관리자와 선생님이 사용하는 교육 서비스 화면을 개발했습니다. 공통 컴포넌트와 검증 스키마를 문서화하고, Next.js 서버에서 API 응답을 통합·가공하며 인증·인가와 데이터 캐싱을 구성했습니다.
Background
- ▸화면마다 반복되는 UI와 폼 검증 코드가 흩어져 있었습니다.
- ▸API 명세 변경과 토큰 만료·오류 처리를 여러 화면에 반영해야 했습니다.
- ▸기능 추가와 리팩토링 시 수정 범위를 명확하게 구분할 필요가 있었습니다.
Architecture
화면·서버 요청 경로와 디자인 시스템·FSD의 코드 의존성을 분리했습니다.
검증 근거 · 입사지원서 v9의 공통 fetch·API Route·미들웨어·BFF·FSD 설명 기준의 개념도입니다. 책방 소스 및 외부 백엔드·배포 설정은 대조하지 못했습니다.
→ 요청 · 전달⇢ 코드 의존성 (점선)→ 빌드 · 배포
화면 요청과 서버 연동
미들웨어의 라우팅 처리와 Next.js 서버의 API 통합 역할을 구분합니다.
노드 선택 · Ctrl/⌘ + 휠로 확대 · 드래그로 이동
100%
- • API Route·미들웨어의 인증·접근 제어와 Next.js 서버의 API 통합·가공·캐싱을 구현했습니다. BFF는 API 통합 역할이며 화면별 렌더링 방식·캐시 키·만료 시간은 단정하지 않았습니다.
- • 화면 라우팅의 접근 제어만으로 API 권한 검증까지 보장되지는 않습니다. 인증된 데이터의 권한·캐시 정책은 서버 구현을 별도로 확인해야 합니다.
연결 관계를 텍스트로 보기
- 브라우저 UI → Middleware · 화면 요청
- Middleware → Next.js 서버 · 라우팅
- Next.js 서버 → 백엔드 API · API 요청
- 브라우저 UI → Jotai · 상태 구독 (코드 의존성)
- 브라우저 UI → Zod 스키마 · 폼 검증 (코드 의존성)
- Next.js 서버 → Zod 스키마 · 응답 검증 (코드 의존성)
UI 개발과 코드 의존성
점선은 사용하는 코드에서 의존하는 코드로 향합니다. Storybook은 별도의 개발 환경입니다.
노드 선택 · Ctrl/⌘ + 휠로 확대 · 드래그로 이동
100%
- • FSD의 대표적인 하위 레이어 의존 방향을 표시한 개념도입니다. 전체 폴더 트리나 모든 import를 나타내지는 않습니다.
- • 공통 컴포넌트·토큰은 Shared 내부 구성을 펼친 것입니다. Storybook을 거쳐야 앱이 실행되는 구조가 아닙니다.
연결 관계를 텍스트로 보기
- 페이지 · 위젯 → Features · 사용 (코드 의존성)
- Features → Entities · 사용 (코드 의존성)
- Entities → Shared · 사용 (코드 의존성)
- Shared → 공통 컴포넌트 · UI 구성 (코드 의존성)
- Storybook → 공통 컴포넌트 · 렌더링 (코드 의존성)
- 공통 컴포넌트 → 디자인 토큰 · 스타일 참조 (코드 의존성)
Key Decisions
| 결정 | 이유 | 결과 |
|---|---|---|
| Storybook + 디자인 토큰 | 반복되는 UI의 사용 기준과 상태를 공유 | 공통 컴포넌트와 문서화된 UI 기준 |
| Zod 폼·API 데이터 검증 통합 | 변경되는 입력·응답 명세를 한곳에서 관리 | 중복 검증 로직 정리 |
| 공통 fetch와 인증·오류 처리 | 인증 헤더·토큰 만료·리디렉션 처리를 일관되게 적용 | 화면 코드에서 공통 통신 로직 분리 |
| API 통합·가공과 데이터 캐싱 | 여러 API 응답을 화면에서 쓰기 쉽게 제공 | 반복 요청과 화면별 데이터 가공 감소 |
| FSD 구조 | 기능 코드와 재사용 코드의 경계 구분 | 기능 추가·리팩토링의 수정 범위 정리 |
What I Did
- ▸관리자·선생님 화면을 개발하고 Storybook·디자인 토큰으로 공통 UI를 문서화했습니다.
- ▸Zod 스키마로 폼 입력과 API 데이터 검증을 통합했습니다.
- ▸공통 fetch에 인증 헤더, 토큰 만료, 오류와 리디렉션 처리를 구성했습니다.
- ▸API Route·미들웨어로 인증·인가와 접근 제어를 구성했습니다.
- ▸서버에서 API 응답을 통합·가공하고 자주 호출되는 데이터에 캐싱을 적용했습니다.
- ▸FSD로 기능별 코드와 재사용 코드를 구분했습니다.
Impact
- ▸화면마다 구현하던 UI·검증·인증 처리를 공통 코드로 정리했습니다.
- ▸API 응답 가공과 캐싱으로 반복 작업과 요청을 줄였습니다.
- ▸공통 UI의 사용법과 상태를 문서로 공유하고 기능별 수정 범위를 명확하게 했습니다.
Tech Stack
Frontend
TypeScriptNext.jsStorybookZodJotaiSCSSTailwind CSS
API / Access
공통 fetchAPI RouteMiddlewareREST API 연동
Service Environment
AWS LightsailNginxDocker