본문으로 건너뛰기

"Architecture" 태그로 연결된 7개 게시물개의 게시물이 있습니다.

소프트웨어 아키텍처 및 설계 패턴 관련 포스트

모든 태그 보기

React 개발에 SOLID 원칙 적용하기 - 리스코프 치환 원칙(LSP)

· 약 7분
방경민
방경민
Frontend Developer

이전 글에서 SOLID 원칙 중 O에 해당하는 OCP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 L에 해당하는 리스코프 치환 원칙(Liskov Substitution Principle, LSP)에 대해 이야기해보려 합니다. React 개발에서 이 원칙이 어떻게 적용될 수 있는지 함께 살펴볼게요.

React 개발에 SOLID 원칙 적용하기 - 개방-폐쇄 원칙(OCP)

· 약 7분
방경민
방경민
Frontend Developer

이전 글에서 SOLID 원칙을 간단하게 소개하고, 그 중 S에 해당하는 SRP를 충족하는 React 개발에 대해 다루었습니다. 이번에는 O에 해당하는 개방-폐쇄 원칙(Open-Closed Principle, OCP)에 대한 소개와 함께, React 개발에 어떻게 적용될 수 있는지 구체적인 예시를 통해 살펴보겠습니다.

Container 중심 구조에서 Feature-Sliced Design으로

· 약 12분
방경민
방경민
Frontend Developer

프론트엔드 아키텍처를 설계할 때 가장 어려운 점은 규모가 커졌을 때도 유지 가능한 구조를 만드는 것이라고 생각합니다.

이 글에서는 제가 사용했던 Container 중심 아키텍처의 의도와 개념, 그리고 그 구조가 확장되며 드러난 한계를 정리하고, 왜 Feature-Sliced Design(FSD)을 다음 선택지로 정하게 되었는지를 이야기해 보려고 합니다.

React 개발에 SOLID 원칙 적용하기 - 단일 책임 원칙(SRP)

· 약 14분
방경민
방경민
Frontend Developer
🔗이 글은 식스티헤르츠 기술 블로그 (2025-11-14)에 게시된 글을 옮겨온 것입니다.원글 보기 →

혹시 SOLID 원칙에 대해 들어보셨나요? 개발을 접하신 분이라면 자세히는 몰라도 한 번쯤 이름은 들어보셨을 거예요. SOLID 원칙은 객체지향 설계에서 지켜야 할 5가지 소프트웨어 개발 원칙(SRP, OCP, LSP, ISP, DIP)을 말합니다.

  • SRP(Single Responsibility Principle): 단일 책임 원칙
  • OCP(Open Closed Principle): 개방 폐쇄 원칙
  • LSP(Liskov Substitution Principle): 리스코프 치환 원칙
  • ISP(Interface Segregation Principle): 인터페이스 분리 원칙
  • DIP(Dependency Inversion Principle): 의존 역전 원칙

이런 원칙들을 지키면 좋은 객체지향 설계에 가까워질 수 있습니다. 그런데 'React에 객체지향이라니?' 하고 의아하게 생각하실 수도 있을 것 같아요. 하지만 우리는 이런 원칙들을 조금 더 넓은 시야로 바라볼 필요가 있다고 생각합니다.

React에서 BE API 변경에 강한 구조 설계하기 (feat. Adapter Pattern)

· 약 10분
방경민
방경민
Frontend Developer

Front-end 개발을 하다 보면 필연적으로 마주치는 상황이 있습니다. 바로 DB 데이터와의 연동입니다. 대부분의 프로젝트는 이 과정을 BE REST API에 의존하고 있습니다.

BE API가 완성되지 못하면 FE 프로젝트도 완성되지 못하고, 인터페이스가 변경되면 FE 프로젝트도 변경되어야 합니다. 여러분들은 이 의존성을 잘 관리하고 계신가요?

이 글에서는 BE API 의존성을 관리하면서 겪었던 시행착오와 함께, 현재 저희가 나아가고 있는 방향을 소개해드리려고 합니다.

React 합성 컴포넌트로 재사용성 극대화하기

· 약 8분
방경민
방경민
Frontend Developer
🔗이 글은 카카오엔터테인먼트 기술 블로그 (2022-07-31)에 게시된 글을 옮겨온 것입니다.원글 보기 →

프론트엔드 개발을 하다 보면 빠짐없이 등장하는 주제 중 하나는 어떤 기준으로 컴포넌트를 나눌 것인가라고 생각합니다. 마찬가지로 카카오페이지 웹 파트도 이 주제로 여러 가지 시행착오를 겪어 왔습니다. 현재는 Harry가 소개해 주신 Atomic Design Pattern을 적용해 UI 컴포넌트를 나누는 기준으로 활용하고 있습니다. (https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/)

개인적으로 이 디자인 패턴의 가장 큰 장점을 꼽아보자면 컴포넌트별 역할이 잘 분리되고 높은 재사용성을 가진다는 것입니다. 재사용성이 뛰어난 컴포넌트들을 미리 잘 준비해 놓으면 추후 화면 전체를 개발할 때 속도 향상에 큰 도움이 되는 것을 체감하고 있습니다. 그래서 현재 프로젝트의 UI 컴포넌트를 개발할 때는 재사용성에 공을 상당히 많이 들이고 있습니다.

그렇게 컴포넌트들을 만들던 도중 하루는 Dialog Modal 구현이 필요하다는 디자인 팀의 요구사항이 들어왔습니다. 첨부된 이미지처럼 제목, 확인 버튼이 있는 안내 메시지였습니다. 이 컴포넌트도 역시 재사용성이 높게 만들고 싶어졌습니다. 어떻게 구현해볼 수 있을까요?