[멋쟁이사자처럼] 프론트엔드 18일차 정리

프로젝트 리팩토링

---

1. 백엔드 아키텍처 재정비: API와 비즈니스 로직의 분리

프로젝트의 규모가 커지면 코드의 위치와 역할에 대한 고민을 해야합니다.
Next.js의 api 폴더에 너무 많은 책임이 있었습니다.

문제점

• 핵심 비즈니스 로직이 API 라우트 핸들러와 뒤섞여 있었습니다.
• /api 폴더의 역할이 모호해지면서 네임스페이스 충돌이나 코드 파악에 어려움이 있었습니다.

개선 방향

핵심 백엔드 로직 분리 : 기존 /api 폴더에 있던 주요 백엔드 코드를 별도의 독립적인 백엔드 폴더(예: /src/backend 또는 /src/services)로 이동하기로 했습니다. 지금부터 /api 폴더는 원격 사용자와의 통신을 담당하는 '어댑터(Adaptor)' 계층의 역할만 수행합니다.

Next.js의 App Router API Route 핸들러만 남겨두고, 실제 데이터 처리 및 비즈니스 로직은 새로 만든 백엔드 폴더에서 처리하도록 구조를 변경할 예정입니다.

/api 폴더의 새 역할 : /api 폴더에는 이제 라우팅과 직접적으로 관련되거나, 업무 보조를 위한 간단한 스크립트 등 상대적으로 중요도가 낮은 코드만 남겨두기로 했습니다. 각 폴더의 책임과 역할이 명확해졌습니다.

결론 : /api는 클라이언트 요청만 받으며, /backend는 업무를 처리하는 것으로 역할을 분리하여 유지보수성과 확장성을 높였습니다.

 RESTful API 컨벤션 바로 세우기

API 경로명의 컨벤션이 일관되지 않아 개선해야 합니다. 

API의 엔드포인트는 자원(Resource)을 표현해야 합니다. 자원은 '물건'이나 '개념'이므로, '무엇을 한다'는 동사형이 아닌 '무엇'이라는 명사형으로 작성하는 것이 원칙입니다. 가장 쉬운 방법은 복수형 명사를 사용하는 것입니다.

예외적으로 단수형/동사형을 사용하는 경우
모든 경로가 복수형 명사일 필요는 없으며, 예외 규칙이 있습니다.

1. 역할자(Actor) 기반 경로: admin, user와 같이 특정 역할자의 고유한 자원을 가리킬 때는 단수형을 사용할 수 있습니다. (예: /admin/dashboard, /user/profile)
2. 구조를 위한 폴더명: 단순히 경로를 묶어주기 위한 폴더명은 자원이 아니므로 복수형으로 만들지 않습니다. (예: /api/v1/users에서 api, v1은 자원이 아닙니다.)
3. 행위명 사용: POST, GET, PUT, DELETE와 같은 HTTP Method로 표현하기 어려운 특정 '행위'가 필요할 때 예외적으로 동사형을 사용합니다. (예: /posts/{id}/publish)

페이지 경로와의 구분
프론트엔드 페이지 경로와 API 엔드포인트는 명확히 구분해야 합니다.

• 게시물 생성 페이지: .../posts/create (페이지)
• 게시물 생성 API: POST /api/posts (API)
• 게시물 수정 페이지: .../posts/{id}/edit (페이지)
• 게시물 수정 API: PUT /api/posts/{id} (API)
  
  결론: 명확하고 일관된 API 컨벤션을 통해 팀원이 API의 역할을 쉽게 예측하고 사용할 수 있도록 개선해야 합니다.

DTO, 인증, 보안

데이터의 흐름과 사용자 인증 방식에 대해서 생각해야 합니다.

 

DTO (Data Transfer Object)
API는 용도에 따라 상세하게 나누어야 합니다. 예를 들어, 게시물 목록을 불러오는 API와 게시물 상세 정보를 불러오는 API는 서로 다른 정보를 필요로 합니다. 따라서 주가 되는 API(상세 정보)와 부가 되는 API(요약 정보)를 구분하고, 각 용도에 맞는 DTO를 설계하여 필요한 데이터만 효율적으로 주고받도록 개선할 예정입니다.

로그인 토큰 저장 및 관리
로그인 성공 후 발급되는 토큰의 저장과 관리방식에 대하여 생각해야 합니다.

클라이언트 저장소
 토큰은 전역 상태 관리 라이브러리(Zustand, Redux 등)나 로컬 스토리지에 저장할 수 있습니다.

서버 주도 쿠키 방식
ID/PW와 같은 민감 정보를 로컬 스토리지에 저장하는 것은 피해야 합니다.
더 안전한 방법은 서버에서 HttpOnly 옵션을 포함한 쿠키에 토큰을 담아 클라이언트로 보내는 것 입니다.
위와 같은 방법을 이용 하면 클라이언트의 JavaScript 코드가 쿠키에 직접 접근할 수 없으므로 토큰을 안전하게 보호할 수 있습니다. 클라이언트는 이 쿠키를 읽기만 가능하며, 수정은 불가능합니다. Next.js 환경에서 서버 컴포넌트나 API Route가 다른 API 서버로 요청을 보낼 때, fetch 함수의 credentials: 'include' 옵션을 사용하면 브라우저의 쿠키를 함께 전송할 수 있습니다.

인증 및 접근 제어
사용자 인증 정보는 커스텀 훅(예: useUser)을 만들어 최상위 Layout 컴포넌트에 적용하면 좋습니다. 이를 통해 모든 하위 페이지와 컴포넌트에서 일관되게 사용자 로그인 상태를 확인하고, 역할에 따른 접근 권한을 효과적으로 제어할 수 있습니다.

 

---

정리

 프로젝트의 뼈대를 더 튼튼하게 만들기 위하여 고민해야 합니다.  좋은 아키텍처와 컨벤션이 당장의 개발 속도보다 장기적인 프로젝트의 건강과 확장성에 중요합니다.