프론트엔드에 SOLID 적용하기

1. 서론

프론트엔드는 점점 더 복잡해지고 있습니다. 단순한 화면 구성에서 벗어나 상태 기반 UI, 사용자 인터랙션 등 다양한 역할을 담당하면서, 구조적인 설계의 중요성이 커지고 있습니다.
이 글에서는 객체지향 설계 원칙인 SOLID를 프론트엔드에 어떻게 적용할 수 있을지를 설명해보려고 합니다.

---

2. SOLID란 무엇인가?

 SOLID는 객체지향 설계 원칙의 앞글자를 딴 용어로, 유지보수성과 확장성을 높이기 위한 기본적인 설계 지침입니다.

• S: 단일 책임 원칙 (Single Responsibility Principle)
  → 하나의 클래스는 하나의 책임만 가져야 하며, 변경 이유도 하나여야 합니다.
• O: 개방-폐쇄 원칙 (Open-Closed Principle)
  → 소프트웨어 구성 요소는 확장에는 열려 있고 변경에는 닫혀 있어야 합니다.
• L: 리스코프 치환 원칙 (Liskov Substitution Principle)
  → 하위 타입은 상위 타입으로 언제든지 대체할 수 있어야 합니다.
• I: 인터페이스 분리 원칙 (Interface Segregation Principle)
  → 하나의 범용 인터페이스보다 여러 개의 구체적인 인터페이스를 제공하는 것이 더 낫습니다.
• D: 의존 역전 원칙 (Dependency Inversion Principle)
  → 구체적인 구현보다 추상화에 의존해야 하며, 고수준 모듈이 저수준 모듈에 의존하지 않아야 합니다.

---

3.  왜 프론트엔드에 SOLID가 필요할까?

프론트엔드의 복잡도가 높아지면서, 다음과 같은 문제들이 자주 발생합니다

• 컴포넌트 간 의존성이 얽혀 유지보수가 어려움
• 기능 확장이 기존 코드 변경을 유발
• 하나의 클래스나 파일에 너무 많은 책임 집중
• 테스트가 어려운 구조

SOLID 원칙을 적용하면, 코드를 더 잘게 나누고 책임을 명확히 하며, 변경에 강한 구조를 만들 수 있습니다.

---

4. SOLID를 프론트엔드에 적용한 예제들

아래는 일반적인 React 프론트엔드 컴포넌트에서 SOLID 원칙을 어떻게 적용할 수 있는지를 보여주는 간단한 예제입니다.

(1) 단일 책임 원칙 (Single Responsibility Principle, SRP)

하나의 컴포넌트가 UI 렌더링, 데이터 요청, 비즈니스 로직을 모두 처리하면 유지보수가 어려워집니다. 책임을 나눠야 합니다.

      

      

      

    
    

      <javascript />
    
// ❌ 모든 책임이 하나의 컴포넌트에 집중됨
const UserProfile = () => {
  useEffect(() => { fetchUser(); }, []);
  return <div>...</div>;
};

// ✅ 책임 분리
const UserProfile = () => {
  const user = useUserData(); // 데이터 로직 분리
  return <UserInfoDisplay user={user} />; // UI 컴포넌트 분리
};

(2) 개방-폐쇄 원칙 (Open/Closed Principle, OCP)

기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있어야 합니다.

      

      

      

    
    

      <javascript />
    
// Button 컴포넌트를 확장 가능한 구조로 설계
<Button variant="primary" />
<Button variant="danger" />

(3) 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

하위 컴포넌트가 상위 타입을 대체해도 기능에 문제가 없어야 합니다.

      

      

      

    
    

      <javascript />
    
const Input = ({ value, onChange }) => <input value={value} onChange={onChange} />;
const PasswordInput = (props) => <Input {...props} type="password" />;

// PasswordInput은 Input으로 대체 가능 → OK

(4) 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

하나의 컴포넌트에 너무 많은 props를 전달하기보다는 역할에 따라 나눠야 합니다.

      

      

      

    
    

      <javascript />
    
// ❌ 너무 많은 props를 받는 컴포넌트
const Dashboard = ({ user, posts, settings, notifications }) => {};

// ✅ 필요한 props만 받는 컴포넌트로 분리
const NotificationPanel = ({ notifications }) => {};
const UserPanel = ({ user }) => {};

(5) 의존 역전 원칙 (Dependency Inversion Principle, DIP)

컴포넌트가 구체적인 구현(API 호출 등)에 직접 의존하기보다는 서비스나 추상화된 계층에 의존해야 합니다.

      

      

      

    
    

      <javascript />
    
// ❌ 직접 API 호출
useEffect(() => { axios.get('/user'); }, []);

// ✅ 추상화된 서비스에 의존
const userService = useUserService();
useEffect(() => { userService.fetch(); }, []);

이처럼 SOLID 원칙은 백엔드뿐 아니라 프론트엔드 환경에서도 충분히 적용할 수 있으며, 컴포넌트의 책임을 나누고 구조를 유연하게 만드는 데 큰 도움이 됩니다

---

5. 프론트엔드에 적용한 SOLID

프론트엔드는 빠르게 변화하고, 다양한 책임을 갖는 구조로 발전하고 있습니다. 이런 상황에서 SOLID는 복잡도를 낮추고 확장성과 유지보수성을 높이는 데 유용한 설계 원칙입니다.

꼭 모든 프로젝트에 정답처럼 적용할 필요는 없지만, 컴포넌트가 점점 비대해지거나 기능 확장이 잦은 경우, 혹은 협업 과정에서 역할 분리와 테스트 용이성이 중요해진 상황이라면, SOLID 원칙을 한 번 시도해보는 것도 좋은 선택이 될 수 있습니다.