src/├── shared/ # 공통 유틸리티, API 클라이언트, 도메인 기반 클래스│ ├── api/ # API 클라이언트, Query Client│ ├── domain/ # ValueObject 추상 클래스│ ├── libs/ # 날짜, 에러 처리 등 유틸리티│ └── ui/ # 공통 UI 컴포넌트├── entities/ # 비즈니스 엔티티│ ├── post/ # Post 도메인│ ├── comment/ # Comment 도메인│ └── user/ # User 도메인├── features/ # 애플리케이션 비즈니스 로직│ ├── post/ # 포스트 관련 기능│ └── user/ #..
react
들어가며소프트웨어는 수많은 객체와 컴포넌트가 협력하며 동작합니다.이때 중요한 것은 각 객체가 어떻게 협력하느냐입니다.만약 협력이 구체적인 구현에 강하게 결합되어 있다면, 작은 변경에도 전체 시스템이 흔들릴 수 있습니다.반대로 협력이 메시지 중심으로 이루어진다면, 내부 구현이 달라지더라도 전체 흐름은 안정적이고 유연하게 유지됩니다.이번 글에서는 객체지향에서 말하는 메시지와 메서드의 차이, 그리고 이를 통해 만들어지는 느슨한 결합과 다형성을 두 가지 예시로 살펴봅니다.TypeScript로 구현한 결제 서비스React의 실무 ErrorBoundary 다형성1. 객체지향 협력: 메시지와 메서드객체지향에서 협력은 메시지(message)를 주고받으며 이루어집니다.메시지: "이 일을 해달라"는 요청(what)메서드:..
들어가며프론트엔드 프로젝트가 커질수록 가장 어려워지는 것은 변경의 파급력입니다.한 기능을 수정했는데 예기치 못한 다른 부분이 깨지거나, 팀 간 코드 충돌로 인해 개발 속도가 점점 느려지는 경험을 누구나 해봤을 겁니다.실제로 많은 팀들이 이런 문제를 겪고 있습니다:버그 수정 하나가 3개의 다른 페이지를 망가뜨림새 기능 추가 시 기존 코드를 건드려야 해서 배포가 두려움코드 리뷰에서 "이 변경이 다른 곳에 영향 없나요?" 같은 질문이 반복됨이 문제를 해결하기 위해 최근 주목받는 아키텍처가 Feature-Sliced Design(FSD)입니다.FSD의 핵심은 단순히 폴더 구조를 바꾸는 게 아니라, 의존성과 캡슐화를 관리해 모듈의 영향 범위를 제한한다는 데 있습니다. 전통적 폴더 구조의 구체적인 문제점전통적인 구..
들어가며리액트 애플리케이션을 개발하다 보면 대부분의 기능이 API 통신과 밀접하게 연결됩니다. 사용자 정보 조회, 데이터 저장, 실시간 업데이트 등 거의 모든 인터랙션이 서버와의 통신을 필요로 하죠.하지만 API 호출 로직이 컴포넌트 곳곳에 흩어져 있으면 여러 문제가 발생합니다. 중복 코드가 늘어나고, API 스펙이 변경되면 여러 파일을 수정해야 하며, 에러 처리나 인증 로직의 일관성을 유지하기 어려워집니다.이러한 문제를 해결하는 핵심 해법이 바로 **추상화(Abstraction)**입니다. 이번 글에서는 API 통신을 추상화하는 이유와 구체적인 방법, 그리고 실무에서 필수적인 에러 처리, 토큰 관리, 상태 관리까지 종합적으로 다루겠습니다.왜 API 통신을 추상화해야 할까?1. 복잡성 감소와 중복 제거매..
URL 기반 상태 관리의 이점을 활용하면서도 타입 안전성과 중앙화를 달성하는 방법들어가며현대 웹 애플리케이션에서 상태 관리는 항상 고민거리입니다. 특히 검색, 필터링, 페이지네이션과 같은 UI 상태를 어떻게 관리할지는 사용자 경험과 개발자 경험 모두에 큰 영향을 미칩니다.이런 상황에서 URL SearchParams를 활용한 상태 관리는 매력적인 대안으로 떠오르고 있습니다. 하지만 기존 방식은 타입 안전성과 중앙화 측면에서 여러 문제점을 안고 있었죠.이 글에서는 SearchParams 기반 상태 관리의 이점과 문제점을 살펴보고, Context 기반 중앙화 솔루션과 nuqs 라이브러리를 비교 분석하여 최적의 해결책을 제시하겠습니다.🎯 SearchParams 기반 상태 관리의 이점1. 공유 가능한 URL//..
들어가며소프트웨어 개발에서 가장 중요한 개념 중 하나는 추상화(Abstraction)입니다. 우리가 매일 작성하는 코드에서 함수를 만들고, 컴포넌트를 분리하고, 모듈을 구성하는 모든 행위가 바로 추상화의 과정입니다.하지만 단순히 코드를 나누는 것만으로는 충분하지 않습니다. 적절한 추상화 수준을 유지하고, 동등한 수준의 추상화를 함께 배치해야만 읽기 쉽고 유지보수가 가능한 코드를 작성할 수 있습니다.이 글에서는 React와 TypeScript를 사용한 실제 예제를 통해 추상화의 핵심 개념들을 살펴보겠습니다.1. 추상화를 하는 이유는 무엇인가?추상화는 복잡한 시스템을 이해하고 관리하기 위한 핵심 도구입니다. 다음과 같은 이유로 추상화가 필요합니다:복잡성 관리우리의 뇌는 한 번에 처리할 수 있는 정보의 양이 ..
"하나의 컴포넌트, 여러 시나리오에서 각기 다른 인터페이스가 필요할 때 어떻게 설계해야 할까?"서론: 복잡한 컴포넌트의 딜레마프론트엔드 개발을 하다 보면 이런 상황을 자주 마주합니다:// 처음에는 단순해 보이는 컴포넌트interface ModalProps { isOpen: boolean; onClose: () => void; type?: 'confirm' | 'alert' | 'form'; // ... 더 많은 props들}하지만 실제 요구사항을 분석해보면:Confirm Modal: onConfirm, onCancel 필요, children 불필요Alert Modal: onClose만 필요, title, message 필수Form Modal: onSubmit, validationSchema 필요,..
React의 핵심 철학은 "무엇을 렌더링할지"에 집중하는 선언적 표현입니다. 하지만 컴포넌트 내부에 모든 로직을 작성하다 보면 이 철학에서 벗어나 명령형 코드로 가득 찬 컴포넌트를 만들게 됩니다. 오늘은 적절한 모듈 격리를 통해 선언적 표현을 유지하면서 유지보수성을 높이는 방법을 알아보겠습니다.서론명령형으로 변질된 컴포넌트function ProductList({ categoryId, sortBy, filterOptions }) { const [products, setProducts] = useState([]); const [loading, setLoading] = useState(false); const [filteredProducts, setFilteredProducts] = useState([]..
