똑똑한 컴포넌트, 어디까지가 좋을까?

문제 제기

똑똑한 컴포넌트가 어디까지 똑똑해야 할지는 소프트웨어 개발의 중심 문제 중 하나입니다. 특히 MSA 환경에서 이 질문은 더욱 중요한데, 서비스를 가능한 잘게 쪼개는 전략이 효율적인 작업을 위한 핵심이 되기 때문입니다.

 

최소한의 컴포넌트로 기능을 분리하려는 시도는 깔끔하고 독립적인 코드베이스를 유지하는 데 도움이 됩니다. 그러나, 이러한 접근이 항상 만능은 아니라는 것을 실제 경험을 통해 깨달았습니다.

 

실전 경험

예를 들어, 사용자의 이름을 표시하는 Username 컴포넌트를 개발하는 과정에서, 각각의 컴포넌트가 자체적으로 API를 호출하도록 설계했습니다. 이론적으로는 재사용성을 극대화하는 좋은 전략처럼 보였습니다.

// Username 컴포넌트 예시
function Username({ userId }) {
  const [userName, setUserName] = useState("");

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => setUserName(data.name))
      .catch((error) => console.error('Error fetching user:', error));
  }, [userId]);

  return <span>{userName}</span>;
}

 

하지만, 테이블에 10개의 Username 컴포넌트를 배치했을 때, 각 컴포넌트가 개별적으로 API 호출을 수행하면서 성능 문제가 발생했습니다. 이는 각 컴포넌트가 너무 많은 책임을 지니며 '똑똑해진' 결과였습니다. 이 경우, 각 컴포넌트는 사용자 정보에 대한 종속성을 가지게 되어, API 호출이 중복되고, 그로 인해 페이지의 성능이 저하되었습니다.

...
 return (
    <table>
      <thead>
        <tr>
          <th>Username</th>
          {/* 기타 테이블 헤더 */}
        </tr>
      </thead>
      <tbody>
        {userIds.map(userId => (
          <tr key={userId}>
            <td><Username userId={userId} /></td>
            {/* 기타 테이블 컬럼 데이터 */}
          </tr>
        ))}
      </tbody>
    </table>
  );

 

이러한 문제를 해결하기 위해, API 호출을 상위 컴포넌트로 이동시켜 데이터를 하위 컴포넌트로 전달하는 방식을 채택했습니다. 이는 Username 컴포넌트가 필요한 곳에서 API를 호출하고, 결과 데이터만을 해당 컴포넌트로 전달하는 것입니다.

// UserData 컴포넌트 예시
function UserData({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => setUser(data))
      .catch((error) => console.error('Error fetching user data:', error));
  }, [userId]);

  return user ? <Username name={user.name} /> : <LoadingSpinner />;
}

 

이로써, 불필요한 타입 처리나 API 호출을 줄이면서, 컴포넌트가 UI 로직에만 집중할 수 있도록 만들었습니다. 이 접근법은 컴포넌트를 '멍청하게' 만들었지만, 전체적으로는 시스템의 성능과 유지보수성을 크게 향상시켰습니다.

 

마무리 생각

이 글을 읽으시면서 '이게 뭐라고 특별히 글까지 써야 하나?'라고 생각하실 수 있어요. 사실, 이 방법이 매우 당연하게 느껴질 수도 있죠. 하지만 MSA라는 새로운 구조를 도입하면서 '자, 이제 컴포넌트 간의 의존성을 없애고, 서비스에서 조합만 하는 구조로 만들어야지!'라는 목표에 사로잡혀 있었습니다. 이러한 일련의 시도와 실패, 그리고 깨달음은 제게 꽤 값진 경험이었습니다. 🤗

MSA에 도전하는 여러분, 또한 동일한 문제를 해결하려 애쓰시는 분들께, 이 글이 작은 빛이 되어 같은 고민을 반복하지 않으셨으면 해요. 때로는 컴포넌트를 '멍청하게' 유지하는 것이, 우리의 시스템을 '똑똑하게' 만드는 길이 될 수 있음을 기억해주시길 바랍니다.