[🔫][W-Guardian] GPT와 Trouble Shooting

최근 CURSOR라는 코드 에디터를 활용하고 있는데 처음에는 'VSCode랑 플러그인 연동되는 점과 UI가 비슷해서 잘 적응할 수 있다는 걸 제외하면 별 이점이 없지 않나?' 생각했는데, 그랬던 나 자신 반성 중...

CURSOR IDE
코드 에디터 자체에 GPT와 자연어로 대화하면서 개발이 가능하고, 코드 에디팅 과정에 단축키를 누르면 코드 생성을 추천 받을 수 있는 AI 탑재형 IDE

이 IDE로 개발하면서 VSCode에서 코파일럿이나 ChatGPT 플러그인을 쓰던 여타 개발자 동료 분들의 희열을 체감했다. 자연어로 AI와 대화하면서 개발할 수 있는 이 편리함은 도저히 그 전으로 돌아갈 수 없는 어떤 것이었다.

게다가 ChatGPT 4.0 버전을 지원하기 때문에 퀄리티 높은 코드 지원을 받을 수 있다는 점이 특히 만족스러웠다. 물론 무료 버전은 하루에 50회로 한도가 정해져 있고, 비용을 지불하면 그보다 훨씬 많은 횟수로 AI의 코드 지원을 받을 수 있다.

하지만 무료 버전으로도 이전에 코파일럿이나 유료 ChatGPT 플러그인을 사용해본적이 없는 유저라면 충분히 필자처럼 만족할 수 있으리라 생각한다.

※ 광고 아님. 광고 환영.

🔫 TypeScript Trouble-Shooting

본격적으로 IDE와 ChatGPT의 도움을 받아 어떤 문제를 해결했는지 보자.

1. ~.ts 파일에서 error 타입을 어떻게 설정하면 좋을까?

const GetWeather = () => {
  const { loc, error: locationError } = useCurrentLocation(geolocationOptions);

  const {
    data: weatherData,
    isLoading,
    isError,
    error,
  } = useQuery(...);
               
};

문제는 Tanstack Query 훅인 useQuery()로 구조분해할당을 통해 변수에 값을 할당할 때 발생했다. ErrorLens 플러그인으로 코드 옆에 error 타입을 설정하라는 타입 경고 문구가 붉게 나타났다.

크게 문제가 되는 건 아니지만, data의 타입도 함께 경고 문구가 발생했기 때문에 함께 해결해야겠는데 나의 스승, ChatGPT에게 방법을 질문해보기로 했다.

/** ~.ts 파일에서 error 객체는 react-query의 useQuery 훅에서 반환되는 값 중 하나입니다. 
이 error 객체는 주로 네트워크 요청 실패나 데이터 처리 중 발생하는 예외를 포함할 수 있습니다. 
TypeScript에서 이러한 error 객체의 타입을 명시적으로 설정하려면, 먼저 에러가 발생할 수 있는 API 호출의 예외 유형을 파악해야 합니다. 
다음은 error 객체에 대한 타입을 설정하는 방법을 보여줍니다:
1. 에러 타입 정의: Error 인터페이스를 확장하여 커스텀 에러 타입을 정의할 수 있습니다. 예를 들어, WeatherAPIError라는 타입을 만들 수 있습니다.
**/

interface WeatherAPIError extends Error {
  response?: {
    status: number;
    data: any;
  };
}

/**
* 2. useQuery의 타입 매개변수 설정: useQuery의 제네릭 타입 매개변수를 사용하여 error의 타입을 WeatherAPIError로 설정할 수 있습니다.
**/

const {
  data: weatherData,
  isLoading,
  isError,
  error,
} = useQuery<WeatherData, WeatherAPIError>(
  ...
);

친절하게 인터페이스로 error 객체에 적용할 타입을 생성해서 어떻게 적용해야할 지 수정까지 해주셨다. 이 대답을 토대로 data에 대응시킬 WeatherData 타입까지 생성해서 제네릭으로 적용했더니 타입 에러는 사라졌다.

2. data?.name에서 name이 타입에 존재하지 않는다는 문제를 어떻게 해결할 수 있을까?

/**
* 1. 함수의 반환 타입 확인: 함수에서 반환하는 객체의 타입을 확인해야 합니다. 
이 함수가 정의된 파일을 열고, 반환 타입이 어떻게 정의되어 있는지 확인하세요.

* 2. 타입 정의 업데이트: 만약 함수의 반환 타입에 name 필드가 포함되어 있지 않다면, 해당 타입에 name 필드를 추가해야 합니다. 예를 들어, 함수가 `WeatherData` 타입의 객체를 반환한다고 가정하면, `WeatherData` 인터페이스에 name 필드를 추가할 수 있습니다.
**/

interface WeatherData {
  name: string; // 도시 이름
  // 기타 필요한 필드들...
}

그리고 추가적으로 API 호출 데이터가 name 필드를 반환하고 있는지 확인해보라는 것과 옵셔널 체이닝으로 반환되는 데이터가 undefined가 아닌지 확인하는 방법을 제안했다. 이 두 가지 방법은 확인 결과 데이터가 name 필드를 반환하고 있었기 때문에 제외하고 위 2가지 방법을 확인했다. 결국 타입에 필드를 추가하여 타입을 설정하는 것으로 해결했다.

3. 인터페이스로 만든 weatherData 타입을 조건부 타입 내에서 특정 타입을 추론하는 문법인 infer를 활용할 수도 있을까?

고민하다보니 워낙 API 호출 결과로 나올 필드가 많은데 모두 타입에 추가하여 적용하기는 어려울 것 같아 infer를 활용하는 고오급 타입 추론을 적용하고 싶어졌다. 어떻게 하면 좋을지 물어봤다.

TypeScript에서 infer 키워드를 사용하여 조건부 타입 내에서 특정 타입을 추론하는 것이 가능합니다. infer는 주로 제네릭 타입 매개변수의 타입을 조건부 타입 내에서 추론할 때 사용됩니다. 이를 활용하면, 복잡한 타입 구조에서 특정 부분의 타입을 동적으로 추출할 수 있습니다.
예를 들어, useQuery로부터 반환되는 데이터 타입을 추론하는 유틸리티 타입을 만들 수 있습니다. useQuery는 데이터1, 로딩 상태2, 에러3 등을 포함하는 객체를 반환합니다. 만약 useQuery의 반환 타입에서 data 필드의 타입만 추출하고 싶다면, 다음과 같이 infer를 사용할 수 있습니다.

예시 코드를 살펴보자.

type QueryReturnType<T> = T extends { data: infer D } ? D : never;

// 사용 예
type WeatherDataType = QueryReturnType<ReturnType<typeof useQuery>>;
                                                  
/**
여기서 `QueryReturnType`은 제네릭 타입 `T`를 받아, `T`가 `{ data: infer D }` 형태를 가질 경우 `D`를 반환하고, 그렇지 않을 경우 `never`를 반환합니다. 
이렇게 정의하면, `useQuery`의 반환 타입에서 `data` 필드의 타입을 `WeatherDataType`으로 추론할 수 있습니다.
**/

4. 현재 파일에서 추가로 수정할 부분이 있을까?

더이상 ErrorLens 플러그인으로 수정할 부분을 보여주는 경고 문구가 나타나진 않았지만, ChatGPT 선생님은 뭔가 보일까 싶어 질문을 던져봤다.

그러자 기본적인 기능 구현은 잘 되어있지만 개선할만한 부분들을 알려줬다.

/**
* 1. 에러 처리 개선: 현재 WeatherAPIError 인터페이스를 사용하여 에러를 처리하고 있지만, 
실제 에러 메시지를 사용자에게 보여주는 부분에서 `error.message`를 사용하고 있습니다. 
만약 API 에러 응답이 `error.response.data.message`에 포함되어 있다면, 이를 사용자에게 보여주는 것이 더 명확할 수 있습니다.
**/

if (isError)
	return <div>날씨 정보를 불러오는 데 실패했습니다: {error.response?.data.message || error.message}</div>;
                                       
/**
* 2. 타입 안정성 강화: `useQuery`에서 사용하는 `queryKey`의 타입을 좀 더 명확하게 지정할 수 있습니다. 
현재는 `queryKey`를 배열로 분해할당하고 있지만, 이 배열의 구조에 대한 명확한 타입 정의가 없습니다. 
이를 개선하여 타입 안정성을 높일 수 있습니다.
**/
                                       
const fetchWeather = async ({
     queryKey,
   }: QueryFunctionContext<[string, { lat: number; lon: number }]>) => {
     const [key, { lat, lon }] = queryKey;
     const openWeather = new OpenWeatherMap({ apiKey: apiKey });
  
const response = await openWeather.getCurrentWeatherByGeoCoordinates(
       lat,
       lon
     );
     return response;
   };                                       
                                       

두 가지 개선안 외에도 가독성 향상, 환경 변수 사용 시 키값이 없을 때 예외처리 등에 대해서 개선안을 제안해줬다. 반영이 필요하다고 생각한 1번 이외에는 추후 수정하고 난 이후에도 필요할 지 생각해 적용하기로 했다.

🔫 React Trouble-Shooting

타입 관련 에러들을 해결하고 나니, 날씨 데이터를 반환하는 파일을 여러 컴포넌트에서 호출해서 사용하는 것이 퍼포먼스 측면에서 저해 요인이 될 것 같다는 생각이 들었다.

동시에 제대로 Tanstack Query를 활용하지 못하고 있다는 생각을 지울 수 없었다. 이럴 거면 굳이 캐싱이 되는 라이브러리를 사용할 필요가 없지 않을까?

그래서 본격적으로 이런 문제를 해결해보기로 했다.

1. ~.ts 파일에서 GetWeather 함수가 weatherData를 반환해. 이걸 temperature.tsx 파일에서 weatherData를 받아서 활용하고 싶은데 어떻게 받을 수 있을까?

이 질문에 대한 응답은 이미 구현해둔 방식과 일치하는 형식이었기 때문에 활용할 수 없었다. 제안해준 예시 코드만 한 번 보고 넘어가자.

// GetWeather 함수 데이터 반환
const GetWeather = () => {
  const weatherData = {
    main: {
      temp: 22,
      humidity: 60
    },
    wind: {
      speed: 5
    }
  };
  return weatherData;
};

export default GetWeather;


// temperature.tsx
const Temperature: React.FC = () => {
  const data = GetWeather();

  console.log(data);

  return (
    <CityTempCon>
      기온: {data?.main?.temp}°C, 습도: {data?.main?.humidity}%
    </CityTempCon>
  );
};

export default Temperature;

2. weatherData를 받는 파일이 여러 개일 경우에는 매번 GetWeather 함수를 호출하면 react-query에 데이터를 담아서 관리하고 있는데 응집도 측면에서 괜찮을까?

여러 컴포넌트에서 GetWeather() 함수를 반복적으로 호출하는 것은 비효율적일 수 있으며, 이는 네트워크 요청의 중복, 데이터 일관성 유지 문제, 리소스 낭비 등을 초래할 수 있습니다. React에서는 이러한 문제를 해결하기 위해 상태 관리 라이브러리나 데이터 페칭 라이브러리를 사용하여 데이터를 중앙에서 관리하고, 필요한 컴포넌트에만 데이터를 전달하는 방식을 권장합니다.
react-query는 서버 상태 관리를 위한 훌륭한 도구로, 데이터 캐싱, 배경 동기화, 데이터 일관성 유지 등을 자동으로 처리해 줍니다. GetWeather() 함수의 결과를 react-query를 사용하여 관리하는 것은 좋은 방법입니다. 이렇게 하면 데이터를 한 번만 가져오고, 여러 컴포넌트에서 해당 데이터를 재사용할 수 있습니다.

위와 같은 이론적인 응답을 받고 GetWeather 함수를 useQuery 훅을 사용해서 커스텀훅으로 만드는 방식을 제안해줬다.

// src/hooks/useWeather.ts
import { useQuery } from 'react-query';
import GetWeather from '@/components/weather-data';

// GetWeather 함수를 react-query의 useQuery 훅을 사용하여 호출
const useWeather = () => {
  return useQuery('weather', GetWeather);
};

export default useWeather;


// 여러 컴포넌트에서 useWeather 훅 사용
import useWeather from '@/hooks/useWeather';

const Temperature: React.FC = () => {
  const { data, isLoading, error } = useWeather();

  if (isLoading) return <div>로딩 중...</div>;
  if (error) return <div>오류 발생!</div>;

  return <div>기온: {data?.main?.temp}°C</div>;
};

export default Temperature;

/** 
이 방법을 사용하면 데이터를 중앙에서 관리하고, 
필요한 컴포넌트에서만 데이터를 조회하여 사용할 수 있으므로 
응집도가 높아지고, 코드의 중복을 줄일 수 있습니다.
**/

무릎을 탁 치며 본격적으로 수정에 들어갔다. 이 아이디어를 활용해 날씨 데이터를 가져오던 컴포넌트를 커스텀 훅으로 수정하고, 데이터가 필요한 여러 컴포넌트에서 화면에 보여주도록 만드니 이제야 뭔가 제대로 분리된 느낌이 들었다.

결과적으로 한 컴포넌트 내에서 모든 데이터 처리를 해결하려는 생각을 버리니 순차적 응집도를 달성할 수 있었다.