Dev Notes
Web Vitals
Web Vitals
Tech Documentation

mirunamu00

개발하며 배운 것들을 기록합니다. 문제 해결 과정과 기술적 인사이트를 공유해요.

mirunamu00

Software Developer

좋은 코드와 시스템 설계에 관심이 많습니다. 배운 것을 정리하고 공유하는 것을 좋아합니다.

GitHub

Tech Stack

TypeScript
React
Next.js
Node.js
JS
Vue
Ang
Rmx
Exp
Nest

활동

GitHub 기여 내역과 개발 현황

Commit Trend

Contribution Graph

Languages

npm Packages

추천글
architecture9월 12일
읽어보기

Feature Sliced Design 아키텍처 가이드

비즈니스 도메인 중심의 프론트엔드 프로젝트 구조화 방법론

적용 환경: React, Vue, Angular 등 모든 프론트엔드 프레임워크 들어가며 프로젝트를 시작할 때 보통 components, hooks, utils 같은 폴더를 만듭니다. 처음에는 깔끔해 보이지만, 규모가 커질수록 문제가 보이기 시작합니다. components 폴더에 파일이 50개가 넘어가면, UserProfile을 수정하려고 열었다가 관련된 hook은 hooks/useUser.ts에, 타입은 types/user.ts에, API 호출은 api/userApi.ts에 흩어져 있다는 것을 깨닫게 됩니다. 하나의 기능을 고치려면 4개 폴더를 오가야 합니다. 새 팀원이 "유저 관련 코드 전체를 파악하고 싶은데요"라고 했을 때, "일단 components에서 User로 시작하는 것들 찾고, hooks에서 useUser 시리즈 보고, utils에도 좀 있고..." 이렇게 설명해야 합니다. 또 한가지 문제는 바로 의존성입니다. UserCard가 PostList를 import하고, PostList가 다시 UserAvatar를 import하는 식으로 얽히기 시작하면, 파일 하나를 수정했을 때 어디가 깨질지 예측하기 어려워집니다. "이 구조가 어떻게 되어 있어요?"라는 질문에 "그냥... 필요한 곳에서 import하면 돼요"라고밖에 답할 수 없는 상황이 됩니다. 이 문서는 "기술 종류"가 아니라 "무엇을 하는 코드인가"를 기준으로 폴더를 나누고, 명확한 의존성 규칙으로 스파게티 코드를 방지하는 Feature Sliced DesignFSD을 소개합니다. 핵심 구조: Layers, Slices, Segments FSD는 코드를 세 가지 축으로 조직합니다. | 축 | 의미 | 예시 | |||| | Layer | 코드의 영향 범위 | app, pages, features, entities, shared | | Slice | 비즈니스 도메인 | user, post, comment, cart | | Segment | 기술적 목적 | ui, model, api, lib | La

architecture2월 2일
읽어보기

함수형 프로그래밍?

Data, Calculation, Action — 코드를 읽는 함수형 프레임워크

들어가며 함수형 프로그래밍을 처음 접하면 모나드, 펑터, 모노이드, 커링 같은 개념이 먼저 눈에 들어옵니다. 수학적 정의를 읽고, 타입 시그니처를 해석하고, 하스켈 코드 예제를 들여다보다 보면 자연스럽게 드는 생각이 있습니다. "그래서 이걸 내 React 코드에 어떻게 쓰라는 건데?" 이런 경험이 반복되면 함수형 프로그래밍은 학술적이고 막연한 것, 실무와는 거리가 먼 것이라는 인상만 남게 됩니다. 하지만 함수형 프로그래밍의 핵심은 그보다 훨씬 단순한 곳에 있습니다. Grokking Simplicityhttps://www.amazon.com/GrokkingSimplicitysoftwarefunctionalthinking/dp/1617296201는 모나드 대신 하나의 질문에서 출발합니다. "이 코드는 어떤 종류의 일을 하고 있는가?" 장바구니에 상품을 추가하는 함수를 떠올려 보겠습니다. 처음에는 배열에 아이템을 넣는 것이 전부였습니다. 그런데 기획자가 "분석 이벤트도 보내야 합니다"라고 합니다. 그 다음 주에는 "새로고침해도 장바구니가 유지되어야 합니다"가 추가됩니다. 한 달 후에는 "재고가 부족하면 대기 목록에 넣어주세요"까지 들어옵니다. 어느새 하나의 함수 안에 가격 계산, API 호출, 로컬 스토리지 저장, 토스트 메시지 표시가 뒤섞여 있고, 이 함수를 테스트하려면 네트워크, 브라우저 스토리지, UI 알림 시스템을 전부 모킹해야 합니다. 문제의 본질은 코드의 양이 아닙니다. 이 함수가 본질적으로 다른 종류의 일을 섞어서 하고 있다는 점이 문제입니다. 데이터를 변환하는 코드, 외부 세계와 소통하는 코드, 단순히 사실을 표현하는 코드가 하나의 함수 안에 뒤섞여 있고, 이 세 가지를 구분하는 것이야말로 코드 품질을 결정하는 가장 근본적인 축입니다. UI = fstate: 이미 시작된 함수형 사고 흥미로운 점은, React를 사용하는 프론트엔드 개발자라면 이미 함수형 프로그래밍의 핵심 원리 위에서 코드를 작성하고 있다는 사실입니다. React 컴포넌트의 본질은 U

architecture1월 30일
읽어보기

Monorepo 전략: Turborepo와 Nx

대규모 프론트엔드 프로젝트를 위한 모노레포 전략과 빌드 오케스트레이션 도구 비교

적용 환경: React, Vue, Angular 등 프레임워크 무관. npm/yarn/pnpm 워크스페이스 기반 들어가며 프론트엔드 팀이 성장하면서 자연스럽게 여러 애플리케이션을 운영하게 됩니다. 고객용 웹 앱, 관리자 대시보드, 모바일 웹뷰까지 — 서로 다른 제품이지만 공유해야 하는 코드가 점점 늘어납니다. 디자인 시스템의 Button 컴포넌트, API 클라이언트, 날짜 포맷팅 유틸리티처럼 동일한 로직이 여러 저장소에 복사되기 시작하면 문제가 눈에 보이기 시작합니다. 디자인 시스템 팀이 Button의 padding을 변경했다고 가정해 봅시다. 이 변경이 3개 앱에 반영되려면, 먼저 디자인 시스템 패키지의 버전을 올려 npm에 배포하고, 각 앱 저장소에서 새 버전으로 업데이트한 뒤, 각각 테스트하고 배포해야 합니다. 이 과정에서 하나의 앱이 업데이트를 놓치면 사용자는 페이지마다 다른 Button을 보게 됩니다. 단순한 padding 변경 하나에 이 정도 조율 비용이 든다면, 실질적인 기능 변경은 얼마나 복잡해질지 상상하기 어렵지 않습니다. 새 팀원이 합류했을 때 "공유 유틸리티는 어느 레포에 있나요?"라는 질문에 "uicomponents 레포에 일부 있고, sharedutils 레포에도 있고, 각 앱 레포의 lib 폴더에도 일부 복사되어 있습니다"라고 답해야 하는 상황은 팀의 생산성을 갉아먹습니다. 모노레포는 이 "코드 공유와 변경 전파" 문제에 대한 구조적 해결책입니다. 하나의 저장소에서 여러 패키지를 관리하되, 각 패키지의 경계는 명확히 유지하는 방식입니다. FeatureSliced Design/docs/architecture/featuresliceddesign이 하나의 패키지 내부를 어떻게 구조화할지 다루었다면, 모노레포는 여러 패키지를 어떻게 조직하고 관리할지에 대한 답을 제시합니다. 모노레포란 모노레포Monorepo는 여러 프로젝트의 코드를 하나의 저장소에서 관리하는 전략입니다. 흔히 모놀리스와 혼동되지만, 둘의 성격은 근본적으로 다릅니다. 모놀리

최근 글

5개 문서
react2월 5일

Next.js App Router 렌더링 전략 완전 정리

Server Component와 Client Component, SSG·SSR·ISR의 두 축으로 이해하는 Next.js 렌더링 모델

44분 읽기
react2월 4일

SSR Hydration Mismatch의 원리와 해결 패턴

React SSR에서 서버/클라이언트 렌더링 불일치가 발생하는 근본 원인과 체계적 해결 전략

react2월 4일

useEffectEvent: Effect 의존성 딜레마의 종착점

React 19.2 useEffectEvent 훅의 동작 원리, ref 트릭 대체, 실무 적용 전략

architecture2월 2일

함수형 프로그래밍?

Data, Calculation, Action — 코드를 읽는 함수형 프레임워크

web2월 2일

브라우저 가비지 컬렉션과 메모리 관리

JavaScript 메모리 구조부터 V8 가비지 컬렉터의 동작 원리, 메모리 누수 디버깅까지

0개
문서
0개
카테고리
0일
총 읽기 시간
0개
이번 달

함께성장해요

개발에 대한 인사이트와 경험을 공유합니다.

GitHub

© 2026 Park Geonwoo. Built with Next.js and Tailwind CSS.