전체 글

들어가며객체지향 프로그래밍에서 클래스를 설계할 때 우리는 종종 단순히 "어떤 속성과 메서드가 필요한가?"라는 구현 중심적 사고에 빠지곤 합니다. 하지만 좋은 클래스 설계를 위해서는 보다 체계적이고 다각도적인 접근이 필요합니다. 개념 관점 설계는 도메인 안에 존재하는 개념과 개념들 상의 관계를 표현합니다. 도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말하며 소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발됩니다. 이 관점은 사용자가 도메인을 바라보는 관점을 반영합니다. 따라서 실제 도메인 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심입니다. 명세 관점에 이르면 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨집니다. 명세 관점은 도메인의 개념이 아니라 실제..

src/├── shared/ # 공통 유틸리티, API 클라이언트, 도메인 기반 클래스│ ├── api/ # API 클라이언트, Query Client│ ├── domain/ # ValueObject 추상 클래스│ ├── libs/ # 날짜, 에러 처리 등 유틸리티│ └── ui/ # 공통 UI 컴포넌트├── entities/ # 비즈니스 엔티티│ ├── post/ # Post 도메인│ ├── comment/ # Comment 도메인│ └── user/ # User 도메인├── features/ # 애플리케이션 비즈니스 로직│ ├── post/ # 포스트 관련 기능│ └── user/ #..

들어가며프로그래밍에서 객체지향 설계의 핵심은 "책임을 어떻게 나누고, 각 객체에게 얼마나 자율성을 주느냐"에 있습니다.객체의 책임이 자율적일수록 협력이 이해하기 쉬워지고 유연하게 변경할 수 있게 됩니다. 이를 피자 만들기를 예로 들어 자세히 살펴보겠습니다.1. 자율적인 책임은 협력을 단순하게 만든다피자를 주문하는 손님(클라이언트)은 피자를 직접 만드는 방법을 알 필요가 없습니다.자율적인 책임은 의도를 명확하게 표현함으로써 협력을 단순하고 이해하기 쉽게 만듭니다. 구체적인 수행 방식을 지시하는 대신 목적(WHAT)을 선언적으로 전달합니다. 세부적인 방식은 객체 내부에서 결정하므로 외부와의 협력은 단순해집니다.interface PizzaMaker { makePizza(): string;}class Chee..

들어가며스타트업 씬에서 6년의 시간을 보냈습니다.지난 시간을 돌아보며 제가 생각하는 스타트업에 대한 생각을 정리했습니다.썸네일 이미지는 미드 워킹데드입니다. 좀비 아포칼립스 드라마로 재난 상황에서 벌어지는 생존에 대한 스토리를 다룹니다. 스타트업 조직에서 일하는 사람에게 가장 중요한 키워드가 생존이라고 생각하는 입장에서 감정 이입되는 내용이 많았습니다.스타트업은 황무지다스타트업은 기존에 잘 닦여 있는 길을 따라가는 조직이 아닙니다. 황무지 위에서 길을 찾고, 없는 길이라면 스스로 만들어내야 합니다. 초기에는 체계도, 매뉴얼도, 심지어 명확한 정답조차 없습니다.대기업에서 당연하게 여겨지는 인사 시스템, 업무 프로세스, 의사결정 체계 같은 것들이 스타트업에는 존재하지 않습니다. 모든 것을 처음부터 만들어야 ..

들어가며소프트웨어는 수많은 객체와 컴포넌트가 협력하며 동작합니다.이때 중요한 것은 각 객체가 어떻게 협력하느냐입니다.만약 협력이 구체적인 구현에 강하게 결합되어 있다면, 작은 변경에도 전체 시스템이 흔들릴 수 있습니다.반대로 협력이 메시지 중심으로 이루어진다면, 내부 구현이 달라지더라도 전체 흐름은 안정적이고 유연하게 유지됩니다.이번 글에서는 객체지향에서 말하는 메시지와 메서드의 차이, 그리고 이를 통해 만들어지는 느슨한 결합과 다형성을 두 가지 예시로 살펴봅니다.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//..