서버 데이터와 컴포넌트의 분리: 유지보수성을 높이는 방법

서버 데이터와 컴포넌트의 분리: 유지보수성을 높이는 방법

개발을 하다 보면 서버에서 받아온 데이터를 그대로 화면에 렌더링하는 컴포넌트를 만들게 됩니다. 그러한 경우, 서버에서 반환되는 데이터의 형식이 변경되면 컴포넌트 코드에도 영향을 미치게 되어 유지보수가 어려워지는 문제가 발생합니다. 이번 포스팅에서는 서버 데이터와 컴포넌트를 분리하여 각각의 책임을 명확히 하고, 변화하는 환경에서도 안정적으로 컴포넌트를 관리할 수 있는 방법에 대해 자세히 알아보겠습니다.

---

문제의 출발점: 서버 데이터와 컴포넌트의 강한 결합

대부분의 웹 애플리케이션은 서버에서 데이터를 받아 이를 화면에 표시하는 구조로 이루어져 있습니다. 개발 초기에는 서버에서 제공하는 데이터 형식에 맞춰 컴포넌트를 제작하는 것이 자연스러워 보입니다. 예를 들어, 아래와 같이 서버에서 반환된 데이터를 그대로 컴포넌트의 props 타입으로 사용하는 경우를 생각해 봅시다.

interface BeforeStudent {
  name: string;
  age: number;
  school: string;
  friendNumber: number;
  howToGetToSchool: string;
}

const Page = () => {
  // 서버에서 데이터를 받아오는 함수
  const studentData: BeforeStudent = getStudent();
  return <StudentComponent data={studentData} />;
};

interface StudentComponentProps {
  data: BeforeStudent;
}

const StudentComponent = ({ data }: StudentComponentProps) => {
  return (
    <div>
      <div>{`이름은 ${data.name} 입니다.`}</div>
      <div>{`나이는 ${data.age} 입니다.`}</div>
      <div>{`친한 친구의 수는 ${data.friendNumber} 입니다.`}</div>
    </div>
  );
};

export default StudentComponent;

이처럼 컴포넌트 내부에서 서버에서 받아온 데이터 전체를 그대로 사용하게 되면, 서버의 데이터 구조가 조금이라도 변경될 경우 컴포넌트 코드를 함께 수정해야 하는 문제가 발생합니다. 예를 들어, 서버에서 반환하는 데이터 형식이 아래와 같이 변경된다면 어떨까요?

interface AfterStudent {
  person: {
    name: string;
    age: number;
    school: string;
  };
  friendNumber: number;
  howToGetToSchool: string;
}

기존의 StudentComponent는 여전히 BeforeStudent 타입의 데이터를 사용하도록 작성되어 있기 때문에, 데이터 구조가 변경됨에 따라 컴포넌트 내부의 접근 방식 또한 함께 수정되어야 합니다. 즉, 단순히 서버의 데이터 변경에 맞추기 위해 컴포넌트 코드까지 변경하게 되는 상황이 발생합니다.

---

문제의 본질: 단일 책임 원칙(SRP) 위반

컴포넌트가 본연의 역할은 UI를 렌더링하는 것입니다. 그러나 위의 예시처럼 서버에서 받아온 데이터 전체를 컴포넌트가 직접 처리하게 되면, 컴포넌트는 데이터의 구조와 렌더링이라는 두 가지 역할을 동시에 가지게 됩니다. 이는 객체지향 설계의 단일 책임 원칙(Single Responsibility Principle, SRP)에 위배되는 문제점입니다.

단일 책임 원칙에 따르면, 하나의 모듈이나 컴포넌트는 하나의 역할만 수행해야 합니다. 즉, 데이터의 가공과 렌더링은 서로 다른 관심사로 분리되어야 하며, 한쪽이 변경되어도 다른 쪽에는 영향을 주지 않아야 합니다. 서버 데이터가 변경되더라도 UI를 렌더링하는 로직은 그대로 유지될 수 있도록, 데이터 가공과 UI 렌더링을 명확히 분리하는 것이 유지보수성 측면에서 매우 중요합니다.

---

해결책: 컴포넌트 내부 데이터 타입 정의하기

문제를 해결하는 가장 효과적인 방법은 컴포넌트가 실제로 필요한 데이터만을 별도의 타입으로 정의하고, 서버에서 받아온 데이터를 해당 타입에 맞게 가공하는 것입니다. 이렇게 하면 서버의 데이터 구조가 변경되더라도 컴포넌트 내부에서는 오직 필요한 데이터만을 사용하게 되어, 컴포넌트 코드 수정의 부담을 크게 줄일 수 있습니다.

아래는 이를 적용한 예시 코드입니다.

// 컴포넌트에서 실제로 필요한 데이터만을 명시한 타입
interface StudentComponentData {
  name: string;
  age: number;
  friendNumber: number;
}

interface AfterStudent {
  person: {
    name: string;
    age: number;
    school: string;
  };
  friendNumber: number;
  howToGetToSchool: string;
}

const Page = () => {
  // 서버에서 데이터를 받아오는 함수
  const studentData: AfterStudent = getStudent();

  // 서버 데이터에서 컴포넌트에 필요한 데이터만 추출
  const data: StudentComponentData = {
    name: studentData.person.name,
    age: studentData.person.age,
    friendNumber: studentData.friendNumber,
  };

  return <StudentComponent data={data} />;
};

interface StudentComponentProps {
  data: StudentComponentData;
}

const StudentComponent = ({ data }: StudentComponentProps) => {
  return (
    <div>
      <div>{`이름은 ${data.name} 입니다.`}</div>
      <div>{`나이는 ${data.age} 입니다.`}</div>
      <div>{`친한 친구의 수는 ${data.friendNumber} 입니다.`}</div>
    </div>
  );
};

export default StudentComponent;

위의 코드에서는 컴포넌트에서 필요한 데이터만 별도로 정의하고, 서버에서 받아온 데이터를 해당 타입에 맞게 변환합니다. 이렇게 분리하게 되면, 서버 데이터의 구조가 변경되더라도 변환 로직(여기서는 Page 컴포넌트 내부)만 수정하면 되며, 실제로 UI를 렌더링하는 StudentComponent의 코드는 그대로 유지할 수 있습니다.

---

분리의 장점: 유지보수성과 확장성의 향상

서버 데이터와 컴포넌트를 분리함으로써 얻을 수 있는 가장 큰 이점은 바로 유지보수성입니다. 구체적으로 살펴보면 다음과 같은 장점이 있습니다.

1. 단일 책임 원칙 준수
   컴포넌트는 단지 데이터를 렌더링하는 역할만 수행하고, 데이터의 가공은 별도의 로직이나 상위 컴포넌트에서 담당하게 됩니다. 이로 인해 코드의 각 부분이 명확한 책임을 가지게 되어, 어느 한 부분이 변경되더라도 다른 부분에 미치는 영향을 최소화할 수 있습니다.
2. 코드 변경 최소화
   서버의 데이터 구조가 변경되더라도, UI 컴포넌트는 전달받은 데이터만을 렌더링하므로 해당 컴포넌트의 내부 코드를 수정할 필요가 없습니다. 대신, 서버 데이터와 컴포넌트 데이터 간의 변환 로직만 수정하면 되어, 코드 변경 범위가 줄어듭니다.
3. 테스트 및 디버깅 용이
   컴포넌트의 역할이 명확하게 분리되면, 각 컴포넌트를 독립적으로 테스트하기 쉬워집니다. 데이터 가공 로직과 UI 렌더링 로직이 분리되어 있으면, 문제 발생 시 어느 부분에서 오류가 발생했는지를 신속하게 파악할 수 있습니다.
4. 재사용성 증가
   컴포넌트가 특정 데이터 형식에 의존하지 않고, 전달받은 데이터만을 렌더링하는 구조라면, 동일한 UI 컴포넌트를 다양한 데이터 소스에 재사용하기가 수월해집니다. 이는 개발 과정에서 코드 중복을 줄이고, 보다 모듈화된 구조를 만들 수 있도록 도와줍니다.

---

실제 개발 환경에서의 고려사항

물론, 모든 상황에서 서버 데이터와 컴포넌트를 완벽하게 분리하는 것이 항상 간단하지만은 않습니다. 실제 프로젝트에서는 다음과 같은 사항들을 고려해야 합니다.

• 데이터 변환 비용
  서버 데이터를 컴포넌트에 맞게 변환하는 로직을 추가하게 되면, 데이터 가공에 추가적인 코드가 필요해집니다. 이로 인해 코드가 다소 복잡해질 수 있으나, 유지보수성을 높이는 장기적인 이점을 고려하면 충분히 감수할 수 있는 부분입니다.
• 타입스크립트의 활용
  타입스크립트를 사용하면, 컴포넌트에서 필요한 데이터 타입과 서버에서 받아온 데이터 타입을 명확하게 정의할 수 있습니다. 이를 통해 컴파일 시점에서 타입 에러를 사전에 방지할 수 있으며, 코드의 안정성을 높일 수 있습니다.
• 협업 및 코드 리뷰
  여러 개발자가 함께 작업하는 환경에서는 데이터의 출처와 변환 로직에 대한 명확한 문서화가 필요합니다. 서버 데이터와 컴포넌트 데이터의 분리 방식을 팀 전체가 이해하고 일관성 있게 적용해야, 장기적인 프로젝트 유지보수에 큰 도움이 됩니다.

---

결론: 컴포넌트의 역할에 집중하라

서버 데이터와 컴포넌트를 분리하는 것은 단순히 코드를 나누는 문제가 아니라, 소프트웨어 설계의 근본 원칙인 단일 책임 원칙을 준수하는 중요한 방법입니다. 컴포넌트는 본래 UI를 렌더링하는 역할에 집중해야 하며, 데이터의 가공이나 구조 변경에 따른 영향을 최소화해야 합니다.

실제로 서버 데이터 형식이 변경되더라도, 컴포넌트 내부 코드를 수정할 필요가 없도록 상위 컴포넌트나 별도의 데이터 변환 로직에서 이를 처리하면, 유지보수성과 확장성을 크게 향상시킬 수 있습니다. 이는 단순히 코드 변경의 편의성뿐 아니라, 장기적인 프로젝트 관리 측면에서도 큰 장점을 제공합니다.

개발자로서 이러한 분리 원칙을 잘 이해하고 적용한다면, 미래에 발생할 수 있는 다양한 변경 사항에도 유연하게 대처할 수 있는 견고한 애플리케이션을 구축할 수 있을 것입니다.

---

마무리하며

이번 포스팅에서는 서버에서 받아온 데이터와 컴포넌트 간의 강한 결합이 어떻게 유지보수성에 악영향을 미치는지, 그리고 이를 해결하기 위해 컴포넌트 내부에서 필요한 데이터 타입만을 정의하는 방법에 대해 살펴보았습니다.
분리된 구조 덕분에 UI 컴포넌트는 오직 렌더링에만 집중할 수 있으며, 서버 데이터 형식이 변경되더라도 안정적으로 작동할 수 있게 됩니다. 이러한 설계 방식은 단일 책임 원칙에 부합하며, 개발자의 생산성을 높이고 코드의 재사용성을 증대시키는 효과적인 방법입니다.

개발 초기에는 서버 데이터와 컴포넌트를 하나로 묶어 빠르게 결과물을 내는 것이 유리해 보일 수 있으나, 프로젝트가 확장되고 복잡해질수록 이러한 결합은 오히려 부담으로 작용하게 됩니다. 따라서, 장기적인 관점에서 코드의 유지보수성과 확장성을 고려한 설계 방식을 채택하는 것이 매우 중요합니다.

앞으로도 개발 과정에서 데이터와 UI의 책임 분리를 명확히 하여, 보다 안정적이고 관리하기 쉬운 애플리케이션을 만드는 데 도움이 되시길 바랍니다.