KCD 캐시노트페이팀의 Frontend Architecture 글을 읽다가,
내가 이전 프로젝트에서 고민했던 기능 단위 구조화와 꽤 맞닿아 있는 부분을 발견했다.
처음에는 단순히 data / domain / state / feature 같은 폴더 구조 이야기처럼 보였지만,
조금 더 들여다보니 핵심은 “폴더를 어떻게 나눌 것인가”보다
외부 데이터가 화면에 도달하기까지의 책임소재를 어디서 나눌 것 인가에 가까웠다.
특히 좋았던 표현은 다음과 같다.
책임소재를 사람에게 바로 묻지 않고,
구조 안에서 먼저 위치를 좁힌다.
API 호출 자체가 실패한 것인지,
응답은 왔지만 약속한 형태가 아닌 것인지,
응답을 프론트엔드 모델로 변환하는 과정에서 문제가 생긴 것인지,
캐싱이나 상태 갱신의 문제인지,
혹은 데이터는 정상인데 화면 표현의 문제인지.
이 질문들을 data / domain / state / components 같은 구조 안에서 먼저 좁혀볼 수 있다는 점이 인상적이었다.
다만 이 메모는 컴포넌트 설계 자체에 대한 글은 아니다.
예를 들어 다음과 같은 질문은 별도의 컴포넌트 설계 문제에 가깝다.
이 컴포넌트는 feature 안에 둘 것인가, shared로 올릴 것인가?
props는 얼마나 일반화할 것인가?
외부 UI 라이브러리 컴포넌트를 내부 컴포넌트로 어떻게 정리해 사용할 것인가?
Page, Section, Card, Form을 어떻게 나눌 것인가?
Storybook에 어떤 상태를 문서화할 것인가?
반면 이 메모의 관심사는 다음에 더 가깝다.
API 응답은 어디서 받는가?
응답이 기대한 형태인지 어디서 검증하는가?
서버 응답을 프론트엔드 모델로 어디서 변환하는가?
React Query에는 raw response를 넣을 것인가, 검증된 domain model을 넣을 것인가?
문제가 생겼을 때 data / domain / state / components 중 어디를 먼저 볼 것인가?