CODE
코드 · 협업
기능 단위로 자른 폴더 구조와, 백엔드·프론트·디자이너가 나눠 맡는 협업 방식.
05 - FRONTEND & COLLABORATION
도메인 단위 수직 슬라이스
- 구조·백엔드 도메인과 같은 경계의 수직 슬라이스
- 흐름·계약 → 전송 → 상태 → 화면
- 계약·서버 DTO ↔ 프론트 타입 1:1
쉽게 말하면
화면 코드를 도메인(기능) 단위로 자릅니다. 여기서 도메인은 ‘카드’·‘댓글’·‘좋아요’처럼 하나의 완결된 기능 덩어리예요. 백엔드도 같은 이름·같은 경계로 나눠서, ‘카드’ 하나를 손볼 때 프론트·백엔드가 같은 폴더만 열면 됩니다.
이렇게 나누면 새 기능은 폴더 하나 추가로 끝나고, 남의 코드와 안 얽혀 여러 명이 동시에 작업하기 좋아요. 아래에서는 ① 서버 데이터가 화면까지 오는 흐름, ② 백엔드·프론트·퍼블리셔· 디자이너의 역할 분담을 보여줍니다.
한쪽이 필드를 바꾸면 타입에 반영되고, 계약 불일치는 컴파일 단계에서 검출.
역할 분담
디자이너
디자인 토큰 · 모션 프리셋 · 컴포넌트 표면Figma Tokens Studio ↔ tokens.json 단일 출처 - 색이 코드와 같은 이름으로 흐른다
웹 퍼블리셔
features/*/components (Tailwind 마크업)데이터 출처는 훅 한 줄로 확인, 마크업·스타일에 집중
프론트엔드
api · hooks (전송 · 캐싱 · 무효화)endpoints 계약을 호출로 잇고 상태를 관리
백엔드
Controller · DTO (경로 · 응답 모양)API와 DTO를 확정하면 프론트가 그대로 받아 쓰는 구조
components/common - 공통 UI 단일 출처
도메인과 무관한 공통 UI는 한 곳에 두고 모든 feature가 가져다 쓰는 공통 자산. 새 화면은 기존 컴포넌트 조립으로 구성.
ButtonInputSelectPaginationLoadingAdminTableColorBadgeSpinner
디자인 토큰 ↔ Figma - 디자이너와의 계약
디자이너가 Figma에서 정한 색·간격이 tokens.json 한 파일을 거쳐 코드까지 같은 이름으로 흐릅니다(Tokens Studio git-sync). 자세한 파이프라인 · Figma 목업 · 계약표는 디자인 시스템 → TOKENS ↔ FIGMA에 정리했어요.
06 - COMPONENT ARCHITECTURE
폴더 = 책임, 204개 파일
- 규모·204개 파일 · 14개 도메인
- 도메인·각 슬라이스 = api · components · hooks · utils
- 공통·components(공통 UI) · lib(전송·유틸) · types(DTO 대응)
쉽게 말하면
코드 폴더를 어떻게 정리했는지를 트리(tree) 형태로 시각화한 그림이에요. 핵심은 기능 하나 = 폴더 하나라, 새 기능을 추가해도 어디에 둘지 헷갈리지 않는다는 점입니다.
아래 그림은 src 폴더가 5개 큰 갈래로, 다시 도메인별 슬라이스로 어떻게 뻗어 나가는지를 보여줍니다.
app (라우팅)features (도메인 슬라이스)components (공통)lib (전송·유틸)types
새 기능 = 폴더 하나
기능을 추가할 때 파일을 여기저기 흩지 않고, features/<도메인>/ 하나를 만들어 그 안에서 api·components·hooks 를 채우면 끝.
공통 UI 재사용
도메인 무관 UI 19개(common)·모션 9개를 공통으로 두어, 모든 화면이 같은 버튼·입력·애니메이션을 재사용.
백엔드와 같은 경계
14개 feature 이름이 백엔드 도메인 패키지와 1:1. 한 도메인을 백/프론트가 나눠 맡는 협업 단위가 폴더로 드러나는 구조.