catch는 줄이고 책임은 명확하게 하기

[sunmerrr]

전부터 존재하던 코드라 깊이 들여다보지 않았던 try-catch 구조가 있었는데,
최근에 그 구조 때문에 에러 핸들링이 굉장히 애매해졌던 경험을 하면서 수정이 필요하다는 생각이 들었다.

기존 구조를 간단히 정리하면 아래와 같다:

1. apiFetch
   fetch를 감싸는 유틸 함수로, 내부에 try-catch가 있다.

     export async function apiFetch<T>(url: string): Promise<ApiResponse<T>> {
       try {
         const response = await fetch(url, options);
     
         if (response.ok === false) {
           ...
           throw error;
         }
     
         const json: ApiResponse<T> = await response.json();
         return json;
       } catch (error) {
         throw error;
       }
     }

2. apiFetchWithToken
   인증 처리용으로 위 함수를 한 번 더 감싼 형태. 이 함수에도 try-catch가 들어가 있다.

     export async function apiFetchWithToken<T>(
       url: string,
       accessToken: string,
       responseType: 'json',
     ): Promise<ApiResponse<T>> {
       if (checkToken(accessToken)) {
         ...
       }
   
       try {
         const response = await fetch(url, {
           headers: {
             ...options.headers,
             Authorization: accessToken,
           },
         });
   
         if (response.status === 401) {
           ...
         }
     
         let result = await response.json();
         return result;
       } catch (error) {
         console.error('API request failed:', error);
         throw error;
       }
     }

3. 서비스 레이어
   실제 API endpoint에 대응하는 메서드로 구성되어있다.

       public static async getData(token: string) {
         // option 또는 필요 내용 작업
         ...
         return apiFetchWithSession<ApiResponse<Data>>(`${this.apiUrl}`, token);
       }

4. 컴포넌트 호출부
   컴포넌트에서 데이터를 불러오는 부분에 try-catch를 두어 실제 에러 처리를 한다.

     useEffect(() => {
       const fetchData = async (): Promise<void> => {
         try {
           const result = await DataServices.getData(session?.accessToken);
           setData(result.data);
         } catch (err) {
           toast.error('데이터를 불러오지 못했습니다.');
           console.error('fetchData 실패:', err);
         }
       };
     fetchData();
     }, [session, isNotLoggedIn]);

catch가 여러 군데 흩어져 있으니 에러가 어디서 발생했는지 파악하기 어렵고,
정작 에러 처리를 제대로 책임지는 곳도 모호했다.

핵심은 에러를 가능한 한 위로 전파시켜서 단 하나의 책임 있는 위치에서만 처리하도록 리팩토링하는 것이었다.
특히 2번 apiFetchWithToken의 try-catch는 아무 의미 없이 로그만 찍고 다시 throw하고 있어서 제거했다.

결과적으로 지금은 다음처럼 단순화되었다:

• apiFetch (1번): 네트워크 실패에 대한 의미 있는 에러 메시지를 만들고 전달
• apiFetchWithToken (2번): 에러 핸들링 책임 없음 (catch 없음)
• 서비스 레이어: 비즈니스 로직만 담당
• 컴포넌트 (4번): 최종 사용자 피드백 (UI 토스트 등)

책임이 깔끔하게 분리되니 에러 흐름도 명확해지고, 구조적으로도 훨씬 개운해진 것 같았다.

지금은 단순히 데이터만 불러오면 되는 케이스라 이 구조로 충분하지만,
추후에는 기능적으로 전환이 필요한 에러가 있을 수 있겠다 라는 생각도 든다.. 그런 케이스가 많아지면 조금 더 맞는 구조를 생각해볼 수 있을 것 같다.