Patterns.dev
(patterns.dev)- 웹 애플리케이션 설계와 성능 최적화 패턴을 다루는 무료 온라인 자료로, JavaScript와 현대적 프레임워크 중심의 학습 콘텐츠 제공
- Vanilla JavaScript, React, Vue 각각에 특화된 디자인 패턴과 렌더링, 로딩, 성능 개선 기법을 체계적으로 정리
- 코드 재사용, 상태 관리, 렌더링 전략, 번들 최적화 등 실무 중심의 예제와 함께 CodeSandbox 실습 환경 지원
- 디자인 패턴은 지침이 아닌 참고용 도구로, 반복되는 문제 해결과 코드 공통점 이해를 돕는 방식으로 제시
- 최신 ES2017+ 문법과 React Hooks 기반 구현을 포함해, 대규모 웹앱의 구조적 확장성과 성능 향상에 초점을 둔 자료
개요
- Patterns.dev는 웹앱 아키텍처 개선을 위한 무료 온라인 리소스로, 디자인·렌더링·성능 패턴을 중심으로 구성
- Vanilla JavaScript, React, Vue.js 환경에서의 구현 예시와 함께, 각 패턴의 목적과 활용 방식을 설명
- eBook 또는 PDF 다운로드와 온라인 열람 기능 제공
JavaScript 패턴
-
기본 JavaScript 및 Node.js 중심의 패턴 모음 제공
- Singleton, Proxy, Prototype, Observer, Module, Mixin, Mediator, Flyweight, Factory 등 전통적 디자인 패턴 포함
-
성능 및 로딩 최적화 패턴 다수 수록
- Dynamic Import, Route-based Splitting, Tree Shaking, Prefetch, Preload, PRPL, Third-party 최적화 등
- View Transitions API를 활용한 페이지 전환 애니메이션, 리스트 가상화, 코드 압축 등 최신 브라우저 기능 활용
React 패턴
-
React 및 Next.js 기반의 구조적 패턴과 렌더링 전략 제공
- Container/Presentational, HOC, Render Props, Hooks, Compound 등 구성 패턴 포함
-
렌더링 방식 비교
- Client-side, Server-side, Static, Incremental Static Generation, Progressive Hydration, Streaming SSR 등
- React Server Components와 Next.js Core Web Vitals 최적화 관련 가이드 제공
- React Stack Patterns (2025/2026) 문서에서는 프레임워크, 빌드 도구, 라우팅, 상태 관리, AI 통합 등 최신 기술 스택 다룸
Vue 패턴
-
Vue.js 전용 패턴으로 컴포넌트 구조와 상태 관리 중심
- Components, Async Components, Composables, Container/Presentational, Data Provider, Dynamic Components 등
- Composition API와 <script setup> 문법을 활용한 현대적 코드 구조 제시
- Provide/Inject, Renderless Components, Render Functions 등 고급 패턴 포함
패턴 적용 철학
- Patterns.dev는 패턴을 규범이 아닌 참고용 도구로 제시
- 반복되는 문제 해결을 위한 공통 솔루션을 제공하지만, 모든 상황에 강제 적용하지 않음
- 디자인 패턴의 목적은 코드 문제의 공통점을 인간이 이해하기 쉽게 전달하는 것
- 언어나 프레임워크 특화 패턴의 중요성을 강조하며, 전통적 GoF 패턴을 넘어선 현대적 접근 제시
학습 및 실습 지원
- CodeSandbox 실습 예제를 통해 각 패턴의 실제 구현 확인 가능
- 시각적 애니메이션 자료로 개념 이해를 돕는 학습 방식 제공
- 웹 성능 패턴을 통해 코드 로딩 효율화와 사용자 경험 향상 방법 제시
핵심 특징 요약
- ES2017+ 문법 기반 구현으로 최신 JavaScript 환경에 최적화
- React 개발자 중심 최적화와 웹 성능 개선에 중점
- 디자인 패턴의 현대적 해석을 통해 복잡성보다 실용성 강조
- 대규모 웹앱 확장성과 성능 향상을 위한 실무형 가이드 제공
Hacker News 의견들
-
예전 직장에서 .NET 엔터프라이즈 앱을 개발할 때는 디자인 패턴이 정말 유용했음
여러 팀이 같은 패턴을 쓰니 코드가 익숙했고, 새 프로젝트도 일관된 구조를 가졌음
하지만 지금은 10년 넘은 JS 앱을 다루는데, Java EE 스타일의 getter/setter 남용과 복잡한 팩토리 구조 때문에 오히려 해로움
패턴을 왜 쓰는지 이해하지 못한 채 남용하면, 단순히 읽기 쉬운 코드보다 훨씬 나쁜 결과를 낳음 (YAGNI 원칙을 떠올림)- 패턴은 ‘만드는 것’이 아니라 ‘발견하는 것’이라 생각함
개발자라면 언젠가 Adapter, Builder, Iterator 같은 구조를 자연스럽게 떠올리게 됨
디자인 패턴의 진짜 가치는 이런 발견된 패턴에 공통 언어를 부여해 서로 쉽게 소통할 수 있게 하는 데 있음 - 많은 패턴은 C#이나 Java처럼 제약이 많은 언어에서만 의미가 있음
C, Go, JavaScript처럼 단순한 언어에서는 훨씬 간단하게 해결할 수 있음 - 엔터프라이즈 환경에서 온 개발자들이 JS에서도 같은 OOP 패턴을 억지로 적용하려는 걸 자주 봄
언어의 철학과 맞지 않음 - 나도 예전에 좋은 의도로 패턴을 적용했다가 유지보수 악몽을 만든 적이 있음
처음엔 깔끔해 보여도 시간이 지나면 로직이 분산되고, 새 요구사항이 들어오면 패턴이 깨지기 쉬움
결국 단순한 switch문이 그리워짐 - 패턴이 쓸모없다고 말하는 사람들 중엔 대규모 시스템 경험이 없는 경우가 많음
작은 앱만 만든 사람과 초고층 빌딩을 짓는 사람의 관점 차이 같음
- 패턴은 ‘만드는 것’이 아니라 ‘발견하는 것’이라 생각함
-
예전에 Yahoo Design Pattern Library가 있었음
UX 패턴 중심이었고, 사용자 행동(예: 평점 매기기)을 유도하는 다양한 사례를 잘 정리했음
원본 링크 / 웹 아카이브- 비슷한 오픈소스 프로젝트로 The Component Gallery가 있음
90개 이상의 디자인 시스템의 UI 컴포넌트를 모아둔 저장소로, a11y/ARIA 가이드라인 학습에도 좋음
component.gallery - “accordion”, “carousel” 같은 용어가 이 라이브러리 덕분에 표준화되었음
공통 언어가 생산성을 높였음 - 옛날 웹의 감성이 느껴져서 향수가 밀려옴
- YUI도 당시엔 시대를 앞서 있었음
- Yahoo 엔지니어링은 정말 훌륭했는데, 경영 실패로 무너진 게 아쉬움
- 비슷한 오픈소스 프로젝트로 The Component Gallery가 있음
-
좋은 자료 모음이라 북마크에 추가했음
비슷한 사이트를 공유함- deviq.com — Domain-driven design, design patterns, antipatterns
- refactoring.guru — Refactoring과 디자인 패턴
- Standard Patterns in Choice-Based Games
- 문제를 패턴에 억지로 맞추려다 시간 낭비하는 경우가 많으니 주의해야 함
- component.gallery도 UI 컴포넌트 제작에 좋은 메타 리소스임
- java-design-patterns.com도 참고할 만함
- Microsoft Cloud Design Patterns도 잘 정리되어 있음
-
Portland Pattern Repository가 원조 사이트임
Ward Cunningham이 위키를 이 목적을 위해 만들었다고 함 c2.com/ppr
-
경력이 쌓일수록 디자인 패턴 의존도가 줄어듦
주니어는 패턴을 배우면 경력 지름길이라 생각하지만, 오히려 복잡성을 키우는 경우가 많음
진짜 중요한 건 문제의 본질과 데이터 구조를 이해하는 것임
예를 들어, 두 배열의 공통 항목을 찾을 때 HashMap을 이용해 O(n) 으로 줄이는 단순한 패턴이 훨씬 유용함
이런 건 이름도 없지만 실무에선 매일 쓰는 핵심 패턴임
결국 중요한 건 원리와 맥락, 교과서적 형태가 아님- 패턴은 공통 언어로서 가치가 있음
“싱글턴을 만들었다”고 말하면 바로 이해되니까
하지만 도구를 맹신하는 건 문제임 - 위에서 말한 HashMap 활용은 DB 세계에선 hash join이라 부름
Postgres 쿼리 플래너에서도 볼 수 있음 - “팩토리” 같은 용어를 쓰는 게 부끄럽진 않음
다만 코드에 이름 붙일 때는 설명적으로 쓰는 게 좋음 - HashMap을 이용한 최적화는 동적 프로그래밍의 한 형태로 볼 수도 있음
Leetcode 연습할 때 익혀두면 좋음 - 디자인 패턴 자체보다 패턴을 어떻게 적용하느냐의 패턴이 더 중요함
기술적 패턴뿐 아니라 조직적 패턴도 다루는 책으로
Organisational Patterns (James Coplien, Neil Harrison)을 추천함
요약 링크
- 패턴은 공통 언어로서 가치가 있음
-
대학 시절 우연히 Ralph Johnson이 직접 가르친 패턴 수업을 들었는데,
인생에서 가장 유용한 수업 중 하나였음
Ralph Johnson 위키 -
“Design Patterns are a sign of missing language features”라는 말이 있음
즉, 언어가 충분히 표현력이 있었다면 패턴이 필요 없었을 수도 있음
관련 자료: C2 Wiki, Norvig 논문, Medium 글 -
이 사이트는 잘 정리된 튜토리얼 모음이지만, Christopher Alexander의 『A Pattern Language』 처럼
패턴 간의 계층적 연결 구조를 보여주지 않아 아쉬움
원래 패턴은 상위–하위 관계 속에서 의미가 생기는데, 기술 서적은 그 맥락이 빠짐
각 패턴이 어떤 문제를 해결하는지도 더 명확히 제시되면 좋겠음- 『A Pattern Language』의 예시를 보면, 각 패턴이 다른 패턴들과 유기적으로 연결되어 있음
예를 들어 “Short Passages”는 “Flow Through Rooms”, “Building Thoroughfare” 등과 이어짐
이런 구조가 패턴 언어의 진짜 힘임
- 『A Pattern Language』의 예시를 보면, 각 패턴이 다른 패턴들과 유기적으로 연결되어 있음
-
패턴을 남용하면 느리고 유지보수 어려운 코드가 됨
- 패턴은 문제 해결 과정에서 자연스럽게 발견될 때 가장 효과적임
존재하지 않는 문제를 미리 해결하려다 복잡해짐 - 결국 적절히 사용할 때만 빛남
- 패턴은 문제 해결 과정에서 자연스럽게 발견될 때 가장 효과적임
-
POSD(Principles of Software Design) 관점에서 유용한 패턴은 다음과 같음
- Module Pattern
- Factory Pattern (factory functions)
- Mediator/Middleware Pattern (function pipeline 형태)
- Hooks Pattern
- Container/Presentational Pattern
반면 Singleton, Mixin, Observer 등은 복잡도 증가나 전역 상태 의존을 유발하므로 주의해야 함 - POSD가 무엇인지 묻는 댓글이 있었음
-
이 사이트는 깊이보다 넓이 위주로 보여서 2017년 느낌이 남
진짜 중요한 건 immutable data를 다루는 기본기를 익히는 것임
for문 없이 array 메서드만으로 코드를 짜보는 연습이 큰 도움이 됨- 예전에 ClojureScript를 써봤는데, 불변 데이터 다루기에 좋았음
JS에서는Object.freeze로는 한계가 있고, ramdajs처럼 새 객체를 반환하는 접근이 현실적임
JS의 최신 문법 덕분에 ramdajs의 일부 함수만 여전히 유용함 - 이 글을 보고 나만의 패턴 문서화를 해보고 싶다는 생각이 듦
- 예전에 ClojureScript를 써봤는데, 불변 데이터 다루기에 좋았음