FSD : Handling API Requests

안녕하세요! 웹사이트나 앱을 만들 때 가장 중요한 것 중 하나가 바로 **"서버랑 대화하기(API 요청)"**입니다.

"내 프로필 보여줘!", "이 상품 장바구니에 담아줘!"라고 서버에 부탁하는 코드를 어디에 짜야 할까요?
FSD 문서는 이 과정을 마치 **"배달 앱으로 치킨 시키기"**처럼 3단계로 나누라고 조언합니다. 고등학생 눈높이에서 아주 쉽게 설명해 드릴게요.

---

🛵 배달 앱으로 이해하는 API 요청 3단계

보통 초보자들은 "치킨 주문하기 버튼" 안에다가 "치킨집 전화번호 찾기 + 전화 걸기 + 주문 말하기 + 결제하기" 코드를 다 때려 넣습니다. 이러면 나중에 피자 시킬 때 또 처음부터 다시 코드를 짜야 해요.

FSD는 이 과정을 **도로(Shared) - 메뉴판(Entities) - 주문 버튼(Features)**으로 나눕니다.

1단계. 🛣️ Shared (기반 시설): "배달 오토바이와 도로" (shared/api)

• 역할: 서버랑 통신하기 위한 가장 기초적인 도구입니다.
• 내용:
  • "모든 요청은 https://api.myapp.com으로 보낸다." (기본 주소 설정)
  • "요청 보낼 때마다 내 신분증(토큰)을 같이 보여준다." (헤더 설정)
• 비유: 배달 오토바이 그 자체입니다. 이 오토바이는 치킨을 싣든 피자를 싣든 상관없습니다. 그냥 "A에서 B로 물건을 배달한다"는 기능만 훌륭하게 수행하면 됩니다.
  • 📂 위치: shared/api/base.ts (보통 axios나 fetch 설정을 여기서 함)

2단계. 🍗 Entities (데이터 정의): "치킨집 메뉴판" (entities/chicken/api)

• 역할: 특정 데이터(주제)에 대한 구체적인 요청 목록입니다.
• 내용:
  • getFriedChicken(): 후라이드 치킨 정보 가져오는 함수
  • updateChickenPrice(): 치킨 가격 수정하는 함수
• 비유: 가게 메뉴판입니다. 여기서는 "주문 버튼을 눌렀을 때" 같은 건 신경 안 씁니다. 오직 "우리 가게엔 양념치킨과 후라이드가 있어"라는 정보(데이터)를 가져오는 방법만 정의해 둡니다.
  • 📂 위치: entities/user/api/userApi.ts ("유저 정보 가져오는 함수들의 모임")

3단계. 🛎️ Features (사용자 행동): "주문하기 버튼" (features/order)

• 역할: 사용자가 실제로 버튼을 눌렀을 때 어떤 메뉴를 어떻게 시킬지 결정하는 곳입니다.
• 내용:
  • "사용자가 [주문] 버튼을 누르면 → 1단계 오토바이를 불러서 → 2단계 메뉴판의 후라이드 치킨을 가져와라!"
  • "만약 배달에 실패하면 '주문 실패' 창을 띄워라."
• 비유: 앱 화면의 **"결제하기 버튼"**입니다. 사용자의 행동(클릭)과 데이터(치킨)를 연결해 주는 역할을 합니다.
  • 📂 위치: features/auth/login/model/login.ts (로그인 버튼 누르면 실행될 로직)

---

💻 코드로 보는 예시

이걸 코드로 보면 대충 이런 느낌으로 정리됩니다.

1. Shared (오토바이 준비)

code JavaScript

downloadcontent_copy

expand_less

    // shared/api/client.ts
// "서버랑 대화하는 기계 준비!"
export const apiClient = axios.create({ baseURL: 'https://api.school.com' });
  

2. Entities (메뉴판 만들기)

code JavaScript

downloadcontent_copy

expand_less

    // entities/student/api.ts
// "학생 정보 가져오는 방법 정의" (아직 실행은 안 함)
import { apiClient } from 'shared/api/client';

export const getStudentInfo = (id) => {
  return apiClient.get(`/students/${id}`);
}
  

3. Features (주문 버튼 연결)

code JavaScript

downloadcontent_copy

expand_less

    // features/check-grade/ui.tsx
// "성적 확인 버튼을 눌렀을 때 실행!"
import { getStudentInfo } from 'entities/student/api';

const CheckGradeButton = () => {
  const handleClick = async () => {
    const data = await getStudentInfo(123); // 여기서 실제로 실행!
    alert(`너의 점수는: ${data.score}`);
  };

  return <button onClick={handleClick}>성적 확인</button>;
}
  

---

❓ 왜 이렇게 귀찮게 나누나요?

처음엔 귀찮아 보이지만, 나중에 **"선생님용 페이지"**를 만들 때 기적이 일어납니다.

1. Shared 재사용: 서버 주소가 바뀌면 Shared 파일 하나만 고치면 학생용/선생님용 앱이 동시에 다 고쳐집니다.
2. Entity 재사용: 선생님이 학생 정보를 볼 때도 entities/student에 만들어둔 getStudentInfo 함수를 그대로 가져다 쓰면 됩니다. 또 만들 필요가 없죠.
3. 유지보수: "로그인 버튼이 안 눌려요" 하면 Features를 보고, "학생 이름이 이상하게 나와요" 하면 Entities를 보면 됩니다.

📝 핵심 요약

"서버 통신 코드를 한곳에 섞지 말고, 도구(Shared) / 메뉴(Entities) / 주문(Features)으로 역할을 나눠라!"

이것이 FSD가 API를 다루는 핵심 철학입니다.

 

* 본 문서는 google AI studio를 통해 작성되었습니다.  ( 원문 : https://feature-sliced.github.io/documentation/docs/guides/examples/api-requests )