[Discussion] 클라이언트 데이터 변환 레이어 도입 제안 (BFF 제거 이후, tanstack-query 기반)

[haewonwon]

기존에는 서버 측 BFF(Backend For Frontend)에서 클라이언트 맞춤형 데이터 포맷으로 응답을 변환할 예정이었지만,
현재 BFF 서버가 제거되면서 서버 DTO를 프론트에서 직접 다루게 됩니다.

이는 다음과 같은 문제점을 발생시킵니다.
• 서버 응답 구조가 변경될 경우, 클라이언트 전역에서 수정 필요
• UI 요구사항에 맞게 데이터를 가공하는 로직이 각 컴포넌트에 분산됨
• 불필요한 중복 코드와 복잡도가 증가

💡 제안 내용
tanstack-query의 select 옵션을 활용하여,
API 호출 시 서버 DTO를 클라이언트 전용 데이터로 변환하는 클라이언트 변환 레이어 (transform layer) 를 도입합니다.

이 방식을 통해 기존 BFF의 역할 일부를 프론트에서 단순화하여 수행합니다.

// 예시
const { data } = useQuery({
  queryKey: ['user'],
  queryFn: fetchUser,
  select: (res) => ({
    id: res.user_id,
    name: res.user_name,
    profileImage: res.image_url || DEFAULT_PROFILE,
  }),
});

✅ 기대 효과
• 서버 DTO 변경의 영향 최소화
• UI 중심 데이터 구조 유지 (불필요한 null, undefined 값 정리)
• 컴포넌트 단의 가공 로직 감소로 가독성과 유지보수성 향상
• BFF 제거 이후에도 일관된 데이터 관리 가능

⚙️ 적용 방식 제안
1. 각 useQuery 훅 내부에서 select를 이용해 변환 로직 정의
2. 변환 로직을 /shared/mappers 또는 /shared/transformers 디렉토리로 분리
3. 공통 변환 함수(formatDate, toCamelCase, normalizeNull)는 /shared/utils에 정리

🧩 논의 포인트
• 변환 레이어를 hooks 내부에 둘지, 별도 model 계층으로 분리할지
• 서버 DTO 타입 정의 없이 JS 기반에서 안전하게 구조 유지하는 방법
• 에러 응답 포맷(HTTP, 서버 코드 등)도 함께 변환할지 여부

💬 코멘트 요청
• 클라이언트 단 변환 레이어 도입에 동의하시나요?
• tanstack-query의 select 방식 외에 더 나은 접근이 있을까요?
• 폴더 구조나 네이밍 관련 의견이 있다면 자유롭게 제안해주세요.

[seohyeon0219]

저는 좋은 것 같습니당
논의포인트 1은 재사용성과 책임분리 때문에 별도 계층으로 따로 분리해서 작성하는 게 좋은 것 같습니다
2는 저희가 현재 TS를 사용하고 있지 않기 때문에 방어적 프로그래밍으로 옵셔널 체이닝을 사용하는 방법은 어떨까용
3의 경우에는 에러 응답 포맷까지 함께 반환해야 추후에 에러가 생겼을 때 해결하기 좋지 않을까?? 합니당

[haewonwon]

• 폴더 구조를 조금 더 고민해 봐야겠네요. Query를 이렇게 사용하는 팀에서는 어떻게 구조를 잡는지 찾아보면 좋을 것 같네요!
• 옵셔널 체이닝은 말씀하신 대로 방어적 프로그래밍이 맞습니다. 이는 에러를 반환해야 하는 상황에서 에러를 반환하지 않고, undefined를 반환합니다. 이는 안전하기도 하지만 때때로는 위험할 수도 있습니다. 에러를 반환해야만 하는 상황이 있으니까요.
• 때문에 옵셔널 체이닝은 DTO 구조를 유지하는 방법이라고 하기엔 애매합니다. 제가 생각하기엔 Zod 같은 라이브러리를 사용해 JSON 구조를 잡는 것도 하나의 방법인 것 같습니다. 더 찾아보고 얘기 나눠도 좋을 듯 해요 : )
• 에러 응답 포맷을 통일하는 게 좋을 것 같네요. 서버에서 던져준 에러를 그대로 클라이언트에 노출하기보다는 UI/UX적으로 한 번 다듬는 게 좋을 것 같아요. 에러 메세지를 그대로 출력하는 건 보안상 좋지 않기도 하고요.