Syshin

아티클 리뷰 - 프론트엔드와 SOLID 원칙

15 min read

Summary

이 글은 카카오엔터테인먼트 FE 개발자 임성묵(steve)님의 “프론트엔드와 SOLID 원칙” 아티클에 대한 리뷰이다. 원문은 객체지향 설계의 5가지 기본 원칙인 SOLID를 프론트엔드 관점에서 재해석하고, 실제 적용 방법을 제시한다. 특히 SOLID가 단순한 코딩 기법이 아닌 ‘원칙(Principle)‘이라는 점과 프론트엔드 특성에 맞게 이를 어떻게 적용할 수 있는지에 대한 통찰이 돋보인다. 이 리뷰에서는 아티클의 핵심 내용과 함께 SOLID 원칙이 현대 프론트엔드 개발에 가져다주는 가치, 그리고 리액트와 같은 컴포넌트 기반 개발에 어떻게 적용할 수 있는지에 대한 생각을 담았다.

Info

이 글은 항해99 1일 1아티클 챌린지 참여 글이다.

아티클 내용

들어가며

이 아티클은 카카오엔터테인먼트의 FE 개발자인 임성묵(steve)님이 객체지향 설계의 5가지 기본 원칙인 SOLID를 프론트엔드 개발 관점에서 어떻게 적용할 수 있는지 설명한 글이다. 기존에 백엔드 중심으로 설명되어 온 SOLID 원칙을 프론트엔드, 특히 React 환경에서 어떻게 적용할 수 있는지 구체적인 예시와 함께 제시하고 있다.

인상 깊었던 한 줄

“SOLID는 원칙입니다. 기법(Technique)이 아니라 원칙(Principle)이기 때문에 기법으로 접근하면 범위와 목적 설정도 어긋날 수밖에 없습니다.”

이 문구는 아티클의 핵심을 담고 있는 부분이다. 스티브님은 SOLID를 단순한 코딩 기법이 아닌 설계 원칙으로 접근해야 함을 강조하고 있다. 특히 SRP(단일책임원칙)를 ‘단일 동작’으로 오해하여 과도하게 컴포넌트를 분리하는 실수를 지적하며, 원칙의 본질을 이해하는 것의 중요성을 강조했다.

이 문장이 가장 인상 깊었던 이유는, 많은 개발자들이 SOLID를 그저 따라야 할 규칙이나 테크닉으로만 접근하는 경향이 있는데, 이 글에서는 그 본질적인 의미와 목적에 집중하고 있기 때문이다. SOLID를 원칙으로 바라보면 상황과 맥락에 따라 유연하게 적용할 수 있지만, 기법으로만 접근하면 교조적이고 기계적인 적용으로 이어질 수 있다.

“다시 얘기하지만 SOLID는 원칙입니다. 기법(Technique)이 아니라 원칙(Principle)이기 때문에 기법으로 접근하면 범위와 목적 설정도 어긋날 수밖에 없습니다. SRP(Single Responsibility Principle)를 직역하면 ‘단일책임원칙’입니다. 이를 섣불리 코딩 기법으로 접근하면 ‘책임=동작’ 공식으로 잘못 해석하게 됩니다. 즉, 단일한 ‘동작’만 가진 컴포넌트로 쪼개야 한다고 오해할 수 있습니다(대부분의 글이 이러한 잘못된 명제로 시작하고 있습니다). 동작으로 쪼개다 보면 그 기준이 애매하기도 하고 과할 정도로 자잘하게 컴포넌트가 쪼개질 수 있습니다. 컴포넌트를 너무 자잘하게 쪼개면 전체 로직을 한눈에 파악하기 어렵게 만들고 코드 네비게이션에 들어가는 공수를 늘어나게 만듭니다. 단일한 동작을 갖도록 코딩하는 것은 ‘컴포넌트’가 아니라 순수한 함수 한정이 되어야 합니다. 이는 SRP라는 원칙으로 도달할 아키텍처 영역이라기보다는 클린 코드의 영역으로 볼 수 있습니다.”

이 부분에서 스티브님은 SOLID, 특히 SRP를 단순히 ‘단일 동작’으로 오해하여 컴포넌트를 과도하게 분리하는 실수를 명확하게 지적하고 있다. 이는 많은 프론트엔드 개발자들이 SRP를 적용할 때 흔히 저지르는 오류로, 결과적으로 오히려 코드의 가독성과 유지보수성을 해치게 된다. 원칙의 본질을 이해하지 못한 채 형식적으로 적용하는 위험성을 정확히 짚어주었다.

SOLID 원칙의 프론트엔드 적용

스티브님은 SOLID의 각 원칙을 프론트엔드 맥락에서 다음과 같이 재해석한다:

  1. SRP (Single Responsibility Principle): ‘변경의 이유’가 하나여야 한다는 원칙
  2. OCP (Open-Closed Principle): 확장에는 열려있고, 수정에는 닫혀있어야 한다는 원칙
  3. LSP (Liskov Substitution Principle): 하위 타입은 상위 타입을 대체할 수 있어야 한다는 원칙
  4. ISP (Interface Segregation Principle): 클라이언트는 사용하지 않는 인터페이스에 의존하지 않아야 한다는 원칙
  5. DIP (Dependency Inversion Principle): 추상화에 의존해야 하며, 추상화는 세부사항에 의존하면 안 된다는 원칙

Conway's Law

특히 SRP를 ‘단일 책임’이 아닌 ‘변경의 이유가 하나’라는 관점에서 해석하는 부분이 인상적이었다. 스티브님은 ‘책임’을 ‘변경의 이유’로 해석할 때, 컴포넌트를 과도하게 분리하는 문제를 피할 수 있다고 설명한다.

실제 적용 사례

스티브님은 React 컴포넌트에 SOLID 원칙을 적용하는 방법을 코드 예시와 함께 상세히 설명한다:

SRP 적용 예시:

  • 상태 관리와 UI 렌더링을 분리
  • 커스텀 훅을 활용한 로직의 분리

![SRP 적용 예시 코드 위치]

OCP 적용 예시:

  • 확장 가능한 컴포넌트 설계
  • props와 컴포지션을 활용한 유연한 구조

DIP와 IoC 컨테이너:

  • 의존성 주입(Dependency Injection)을 통한 모듈간 결합도 낮추기
  • 테스트 용이성 향상

개인적인 공감 포인트

  1. 원칙과 실천의 균형: 스티브님이 강조한 “원칙으로서의 SOLID”라는 관점이 매우 공감된다. 개발 원칙은 상황과 맥락에 맞게 유연하게 적용되어야 하며, 교조적인 접근은 오히려 더 나쁜 결과를 낳을 수 있다. 프론트엔드 개발을 하면서 이론적 원칙과 실무적 적용 사이의 균형을 찾는 것이 중요하다고 생각한다.

  2. 과도한 분리의 함정: 컴포넌트를 과도하게 분리하면 오히려 코드 흐름을 파악하기 어렵다는 지적이 와닿았다. React로 개발하면서 “단일 책임”을 오해하여 모든 것을 작은 컴포넌트로 분리했다가, 나중에 전체 흐름을 이해하기 어려워진 경험이 있다. SRP를 ‘변경의 이유’로 해석하는 관점은 이런 문제를 해결하는 좋은 지침이 된다.

  3. 맥락에 맞는 적용: 백엔드 중심의 SOLID 원칙을 프론트엔드 맥락에 맞게 재해석한 점이 인상적이었다. 특히 React의 훅, 컨텍스트 API, 컴포지션 등을 활용해 원칙을 구현하는 방식은 실제 프로젝트에 바로 적용해볼 수 있을 것 같다.

프론트엔드 아키텍처에 대한 생각

스티브님의 글을 읽으며, 프론트엔드 아키텍처의 중요성에 대해 다시 한번 생각하게 되었다. 프론트엔드 개발은 빠르게 진화하고 있으며, 단순한 UI 구현을 넘어 복잡한 상태 관리와 비즈니스 로직을 다루는 영역으로 확장되고 있다.

이러한 상황에서 SOLID와 같은 설계 원칙은 더욱 중요해지고 있다. 그러나 프론트엔드의 특성(선언적 UI, 컴포넌트 기반 구조, 비동기 처리 등)을 고려한 적절한 해석과 적용이 필요하다.

특히 최근 React Query, SWR 같은 데이터 페칭 라이브러리나 Zustand, Jotai 같은 상태 관리 도구들의 등장은 SOLID 원칙을 더 효과적으로 적용할 수 있는 기반을 마련해주고 있다. 이러한 도구들은 관심사 분리와 의존성 역전 같은 원칙을 자연스럽게 구현할 수 있도록 도와준다.

SOLID의 가치와 한계

SOLID 원칙은 코드의 유지보수성, 확장성, 테스트 용이성을 향상시키는 데 큰 도움이 된다. 그러나 스티브님이 지적했듯이, 이를 기계적으로 적용하면 오히려 코드를 복잡하게 만들 수 있다.

모든 원칙이 그렇듯, SOLID도 상황과 맥락에 맞게 적용되어야 한다. 특히 다음 사항을 고려해야 한다:

  1. 팀의 규모와 경험: 큰 팀이나 경험이 다양한 개발자들이 있는 환경에서는 더 엄격한 원칙 적용이 필요할 수 있다.
  2. 프로젝트의 수명: 장기적으로 유지보수될 프로젝트일수록 SOLID 같은 설계 원칙의 가치가 높아진다.
  3. 도메인의 복잡성: 복잡한 비즈니스 로직을 다루는 애플리케이션일수록 체계적인 설계가 중요하다.

핵심 요약

  • 원칙으로서의 SOLID: SOLID는 단순한 코딩 기법이 아닌 설계 원칙으로 접근해야 한다. 상황과 맥락에 맞게 유연하게 적용하는 것이 중요하다.

  • SRP의 올바른 해석: 단일 책임 원칙은 ‘단일 동작’이 아닌 ‘변경의 이유가 하나’라는 관점에서 이해해야 한다. 이를 통해 과도한 컴포넌트 분리를 피할 수 있다.

  • 실용적 적용: React의 훅, 컨텍스트 API, 컴포지션 등을 활용해 SOLID 원칙을 실제 코드에 적용하는 방법을 배울 수 있다.

결론

스티브님의 “프론트엔드와 SOLID 원칙” 아티클은 백엔드 중심으로 설명되어 온 객체지향 설계 원칙을 프론트엔드 맥락에서 재해석하고 적용하는 방법을 제시한 귀중한 자료이다.

특히 SOLID를 ‘원칙’으로 접근하고, 교조적인 적용을 경계하는 관점은 많은 프론트엔드 개발자들에게 새로운 시각을 제공한다. 원칙의 본질을 이해하고 상황에 맞게 유연하게 적용하는 것이 진정한 SOLID의 가치를 실현하는 방법임을 깨닫게 해준다.

프론트엔드 개발이 더욱 복잡해지고 있는 현 시점에서, 이러한 설계 원칙에 대한 깊이 있는 이해와 적용은 더욱 중요해지고 있다. 스티브님의 글을 통해 SOLID 원칙을 단순한 규칙이 아닌, 더 나은 코드를 작성하기 위한 사고방식으로 접근할 수 있게 되었다.

Graph View

Backlinks