"코드 정리해달라고 했더니 AI가 물어봐요. '어떻게 정리할까요?' 저도 모르겠어서 '알아서 해줘'라고 했더니 매번 다른 방식으로 짜요. 나중에 보면 스타일이 제각각이라 뭐가 뭔지..."
맞아요. AI한테 "정리해줘"만 하면 그때그때 다르게 만들어요. 어떤 건 파일 하나에 다 넣고, 어떤 건 파일 10개로 쪼개고... 일관성이 없으니까 나중에 코드 보면 헷갈리는 거예요.
왜 이런 일이 생길까요?
"어떻게 정리할지" 기준을 안 줘서 그래요. 같은 문제인데도 AI가 매번 다른 방식으로 해결하면, 코드가 통일성 없이 뒤죽박죽 돼요.
근데 이게 비단 여러분만의 문제는 아니에요.
2024년부터 AI가 프로젝트 전체를 만들 수 있게 됐어요. 처음엔 신기했죠. "와, 정말 뭔가 나오네?"
근데 여기서 멈추는 사람이 대부분이에요.
처음엔 뭔가 나와요. 근데 기능 추가하려니까 꼬여요. 매번 다르게 짜니까, 나중에 수정하려면 어디를 고쳐야 할지 모르겠는 거죠.
차이를 만드는 건 AI가 아니라 "어떻게 시키느냐"예요.
이걸 해결하는 게 **디자인 패턴(Design Pattern)**이에요. "이런 상황에선 이렇게 짜라"는 검증된 해결책이죠.
디자인 패턴을 알면 AI한테 **"이 컴포넌트는 Container-Presenter 패턴으로 분리해줘"**라고 정확히 말할 수 있어요. 그러면 AI가 일관된 방식으로 코드를 짜줘요.
중요한 건, AI가 만들어주면 끝이 아니에요.
기능 단위로 직접 확인해야 해요. 버튼 만들었으면 눌러보고, 저장 기능 만들었으면 저장해보고. 이 "확인 → 피드백" 과정이 없으면 나중에 다 꼬여요.
이 글을 읽고 나면
- 디자인 패턴이 뭔지, 왜 필요한지 알 수 있어요
- 자주 쓰는 디자인 패턴 5가지를 구분할 수 있어요
- 상황에 맞는 패턴을 선택할 수 있어요
- AI한테 "이 패턴으로 해줘"라고 말할 수 있어요
디자인 패턴이 뭔가요?
디자인 패턴은 반복되는 문제를 해결하는 검증된 방법이에요.
🍳 요리 비유
- 볶음밥 만들기: 재료 준비 → 볶기 → 간 맞추기
- 찌개 끓이기: 육수 내기 → 재료 넣기 → 끓이기
→ 매번 새로 고민 안 해도 됨
💻 코드 작성
- 로그인 기능: 싱글톤 패턴으로
- 버튼 생성: 팩토리 패턴으로
- 상태 변화 알림: 옵저버 패턴으로
→ 매번 구조 고민 안 해도 됨
💡 왜 중요해요?
- 같은 문제를 일관되게 해결해요
- AI한테 정확한 지시가 가능해요
- 코드 스타일이 통일돼요
- 나중에 다른 사람이 봐도 이해가 빨라요 PART 4 복습: 아키텍처에서 디자인 패턴으로
17편에서 코드를 어떻게 구조화할지를 배웠죠?
| 레이어드 | MVC | 클린 |
|---|---|---|
| 층으로 나누기 | 역할 3개로 | 동심원으로 |
| API/Service | Model/View | 핵심/구현 분리 |
| /Repository | /Controller |
오늘 배울 것은: 그 안에서 코드를 어떻게 짤지
- 17편: 전체 구조를 어떻게? → 레이어드 / MVC / 클린
- 18편(오늘): 세부 코드를 어떻게? → 싱글톤 / 팩토리 / 옵저버
비유하면:
- 아키텍처 = 집 설계도 (방을 어떻게 배치할까?)
- 디자인 패턴 = 가구 배치법 (침대는 어떻게 놓을까?)
왜 디자인 패턴이 필요한가요?
패턴 없이 코드를 짜면 이런 일이 생겨요.
❌ 패턴 없을 때 (일관성 없는 코드)
- 같은 기능인데 파일마다 다르게 구현됨
- AI한테 "정리해줘" 하면 매번 다른 방식
- 나중에 수정할 때 "이건 왜 이렇게 했지?" 헷갈림
- 팀원마다 다르게 짜서 스타일 통일 안 됨
✅ 패턴 있을 때 (일관된 코드)
- 같은 문제는 같은 방식으로 해결
- AI한테 "싱글톤으로 해줘" 하면 항상 그 방식
- 코드 보면 "아, 이 패턴이구나" 바로 이해
- 팀 전체가 같은 패턴 쓰면 협업 쉬움
💡 핵심: 검증된 방법을 쓰면 고민할 게 줄어요 아키텍처 vs 디자인 패턴
헷갈릴 수 있으니 정리해볼게요.
🏢 아키텍처 (Architecture) - 17편
- 전체 구조를 어떻게?
- 폴더와 파일을 어떻게 나눌까?
- 프로젝트 전체 규모
- 예: "레이어드 아키텍처로 가자"
🔧 디자인 패턴 (Design Pattern) - 18편
- 세부 코드를 어떻게?
- 이 기능을 어떻게 구현할까?
- 함수/클래스 단위 규모
- 예: "로그인은 싱글톤 패턴으로"
💡 둘 다 알아야 AI한테 정확히 지시할 수 있어요
"레이어드 아키텍처로 가되, 인증은 싱글톤 패턴으로" 바이브 코더가 알아야 할 디자인 패턴 5가지
실무에서 자주 쓰이는 패턴만 알면 돼요. 너무 많이 알 필요 없어요.
1. 싱글톤 (Singleton)
하나만 만들기 - 인증, 설정 등
→ 로그인 상태는 앱 전체에서 하나만
2. 팩토리 (Factory)
찍어내기 - 비슷한 객체 여러 개
→ 버튼, 카드 컴포넌트 찍어내기
3. 옵저버 (Observer)
구독하기 - 상태 변화 알림
→ 로그인하면 여러 화면 동시에 업데이트
4. 전략 (Strategy)
방법 바꾸기 - 상황에 따라 다른 방법
→ 결제: 카드/계좌이체/간편결제
5. Container-Presenter
역할 나누기 - 로직 / UI 분리
→ 데이터 가져오기 / 화면 그리기
💡 처음엔 싱글톤, Container-Presenter만 알아도 돼요 1. 싱글톤: 하나만 만들기
싱글톤 패턴은 객체를 딱 하나만 만드는 패턴이에요.
🏛️ 대통령 비유
- 대통령은 나라에 한 명만 있음
- 여러 명 만들면 안 됨
→ 같은 사람을 계속 참조
💻 코드 예시
- 로그인 상태 관리
- 앱 설정 (다크모드 등)
- DB 연결
→ 앱 전체에서 하나만 있어야 하는 것들
✅ 특징
- 처음 만들 때 하나 생성
- 그 다음부터는 이미 만든 거 재사용
- 어디서 접근해도 같은 객체
💡 언제 쓰나요?
- 로그인 상태 (여러 개 있으면 안 됨)
- 앱 전역 설정
- API 클라이언트 (연결 하나로 통일) 싱글톤 패턴 예시: 로그인 상태
페이지 A: 로그인 상태 객체 1개 만듦 페이지 B: 로그인 상태 객체 1개 더 만듦 → 두 개가 따로 놀아서 동기화 안 됨 → A에서 로그아웃해도 B는 로그인 상태 ✅ 싱글톤으로 해결 앱 전체: 로그인 상태 객체 딱 1개만 페이지 A: 그 객체 참조 페이지 B: 같은 객체 참조 → 하나만 있으니까 항상 동기화됨 → A에서 로그아웃하면 B도 바로 반영
2. 팩토리: 찍어내기
팩토리 패턴은 비슷한 객체를 찍어내는 패턴이에요.
🏭 공장 비유
- 붕어빵 틀: 틀은 하나, 붕어빵은 여러 개
- 레고 블록: 같은 규격으로 찍어냄
→ 일관된 방식으로 생성
💻 코드 예시
- 버튼 컴포넌트 (크기/색만 다름)
- 상품 카드 (내용만 다름)
- 알림 메시지 (타입만 다름)
→ 비슷한데 조금씩 다른 것들
✅ 특징
- 생성 로직을 한 곳에 모음
- 파라미터만 바꿔서 찍어냄
- 나중에 생성 방식 바꾸기 쉬움
💡 언제 쓰나요?
- 버튼 여러 개 (주요/보조/위험 등)
- 카드 여러 개 (상품/리뷰/프로필 등)
- 알림 여러 개 (성공/경고/에러 등) 팩토리 패턴 예시: 버튼 컴포넌트
주요 버튼 코드: 크기, 색, 클릭 처리
보조 버튼 코드: 크기, 색, 클릭 처리
위험 버튼 코드: 크기, 색, 릭 처리
→ 비슷한 코드 3번 작성. 수정하려면 3곳
✅ 팩토리로 해결
createButton(type) {
if (type === 'primary') → 주요 버튼
if (type === 'secondary') → 보조 버튼
if (type === 'danger') → 위험 버튼
}
→ 생성 로직 한 곳에. 수정도 한 곳만 3. 옵저버: 구독하기
옵저버 패턴은 상태 변화를 여러 곳에 알리는 패턴이에요.
📺 유튜브 구독 비유
- 크리에이터가 영상 업로드
- 구독자 전체한테 알림 감
→ 일일이 알릴 필요 없음
💻 코드 예시
- 로그인하면 → 헤더, 사이드바, 메인 업데이트
- 장바구니 담으면 → 아이콘 숫자, 총액 업데이트
- 다크모드 켜면 → 모든 컴포넌트 색상 변경
→ 한 번 바뀌면 관련된 것들 자동 업데이트
✅ 특징
- 상태 변화를 "발행" (publish)
- 관심 있는 곳에서 "구독" (subscribe)
- 상태 바뀌면 구독자 전체한테 자동 알림
💡 언제 쓰나요?
- 로그인/로그아웃 (여러 화면 동시 업데이트)
- 장바구니 (아이콘, 목록, 총액 동기화)
- 실시간 알림 (새 메시지, 좋아요 등) 옵저버 패턴 예시: 로그인 상태
로그인 버튼 클릭 → 헤더 업데이트 함수 호출 → 사이드바 업데이트 함수 호출 → 메인 업데이트 함수 호출 → 하나라도 빠뜨리면 동기화 안 됨 ✅ 옵저버로 해결 로그인 버튼 클릭 → 로그인 상태 변경 (상태 변화 발행) → 헤더 (구독자) 자동 업데이트 → 사이드바 (구독자) 자동 업데이트 → 메인 (구독자) 자동 업데이트 → 빠뜨릴 일 없음. 자동으로 동기화
4. 전략: 방법 바꾸기
전략 패턴은 상황에 따라 다른 방법을 쓰는 패턴이에요.
🚗 내비게이션 비유
- 목적지는 같은데 방법이 다름
- 최단 거리 / 빠른 길 / 무료 도로
→ 상황에 맞게 선택
💻 코드 예시
- 결제: 카드 / 계좌이체 / 간편결제
- 정렬: 이름순 / 날짜순 / 인기순
- 알림: 이메일 / SMS / 푸시
→ 같은 목적, 다른 방법
✅ 특징
- 여러 방법을 인터페이스로 통일
- 상황에 따라 방법만 교체
- 새 방법 추가해도 기존 코드 안 건드림
💡 언제 쓰나요?
- 결제 수단 여러 개
- 정렬 기준 여러 개
- 로그인 방법 여러 개 (이메일/구글/카카오) 전략 패턴 예시: 결제
if (결제수단 === '카드') {
카드 결제 처리...
} else if (결제수단 === '계좌') {
계좌 결제 처리...
} else if (결제수단 === '간편') {
간편결제 처리...
}
→ 결제 수단 추가할 때마다 if 추가
✅ 전략으로 해결
결제 전략 인터페이스:
- 카드 전략
- 계좌 전략
- 간편 전략
pay(전략) {
전략.execute()
}
→ 새 결제 수단? 새 전략만 추가 5. Container-Presenter: 역할 나누기
Container-Presenter 패턴은 로직과 화면을 분리하는 패턴이에요.
| 🎬 영화 비유 | |
| - 감독 (Container): 연출, 데이터 준비 | |
| - 배우 (Presenter): 대사, 연기 | |
| → 역할 분담하면 효율적 | |
| 💻 코드 예시 | |
| ┌─────────────────┐ | |
| Container | ← 데이터 가져오기 |
| - API 호출 | 상태 관리 |
| - 상태 관리 | 로직 처리 |
| └────────┬────────┘ | |
| ↓ (데이터 전달) | |
| ┌─────────────────┐ | |
| Presenter | ← 화면 그리기만 |
| - UI만 담당 | 데이터 표시 |
| └─────────────────┘ | |
| ✅ 특징 | |
| - Container: 똑똑한 컴포넌트 (로직 O, UI X) | |
| - Presenter: 멍청한 컴포넌트 (로직 X, UI O) | |
| - 재사용하기 쉬움 (Presenter만 여기저기 씀) | |
| 💡 언제 쓰나요? | |
| - 같은 데이터를 다르게 보여줄 때 | |
| - UI 테스트하기 쉽게 만들 때 | |
| - 프론트엔드 컴포넌트 대부분 |
Container-Presenter 예시: 상품 목록
ProductList.tsx {
API 호출 코드
로딩 상태 관리
에러 처리
화면 그리기
}
→ 로직과 UI가 섞여서 수정하기 어려움
✅ Container-Presenter로 분리
ProductListContainer.tsx {
API 호출
로딩/에러 상태 관리
→ 데이터를 Presenter한테 전달
}
ProductListPresenter.tsx {
받은 데이터로 화면만 그림
버튼, 카드 레이아웃만
}
→ UI 바꿀 때 Presenter만 건드림
→ 로직 바꿀 때 Container만 건드림 패턴 조합하기: 실전 예시
실제로는 여러 패턴을 조합해서 써요.
1️⃣ 싱글톤: 장바구니 상태
앱 전체에서 장바구니는 하나만
2️⃣ 옵저버: 장바구니 변화 알림
상품 담으면 → 아이콘, 목록, 총액 자동 업데이트
3️⃣ Container-Presenter: 장바구니 화면
- Container: 장바구니 데이터 가져오기
- Presenter: 화면에 리스트 그리기
4️⃣ 전략: 결제 수단
카드 / 계좌 / 간편 중 선택
💡 한 기능에 여러 패턴 조합 AI한테 이렇게 요청하세요
패턴을 알면 AI한테 어떻게 짤지 정확히 말할 수 있어요.
상황 1: 장바구니 상태 관리
❌ 나쁜 예 (패턴 언급 없음)
나: "장바구니 기능 만들어줘"
→ AI가 알아서 만드는데, 페이지마다 상태가 따로 생겨서 동기화 안 될 수 있어요.
✅ 좋은 예 (싱글톤 + 옵저버)
나: "Next.js 앱에서 장바구니 상태 관리할 건데,
싱글톤 패턴으로 앱 전체에서 하나만 만들어줘.
그리고 옵저버 패턴으로 장바구니 변경되면
헤더의 장바구니 아이콘, 장바구니 페이지, 결제 페이지가
자동으로 업데이트되게 해줘.
React Context나 zustand 같은 걸로 구현해줘."
→ AI가 싱글톤으로 상태 하나 만들고, 옵저버로 자동 업데이트 구현해요.
상황 2: 상품 카드 컴포넌트
❌ 나쁜 예
나: "상품 카드 만들어줘"
✅ 좋은 예 (팩토리 + Container-Presenter)
나: "상품 카드 컴포넌트 만들 건데, 두 가지 패턴 써줘.
1. 팩토리 패턴으로 카드 타입별 생성
- 일반 상품 카드
- 할인 상품 카드
- 품절 상품 카드
2. Container-Presenter로 분리
- ProductCardContainer: API에서 상품 데이터 가져오기
- ProductCardPresenter: 받은 데이터로 화면만 그리기
나중에 카드 디자인 바꿀 때 Presenter만 수정하면 되게."
상황 3: 결제 기능
❌ 나쁜 예
na: "결제 기능 만들어줘"
✅ 좋은 예 (전략 패턴)
나: "결제 기능 만들 건데, 전략 패턴으로 해줘.
결제 수단:
- 카드 결제 (Bootpay)
- 계좌이체 (Bootpay)
- 간편결제 (카카오페이)
나중에 네이버페이 추가할 수도 있으니까
새 전략만 추가하면 되게 구조 잡아줘.
PaymentStrategy 인터페이스 만들고,
각 결제 수단별로 구현체 만들어줘."
실제 대화 예시
AI랑 패턴 정하면서 대화할 때 이렇게 해요.
┌───────────────────────────────────────────────────────────────────────┐ │ 1단계: 기술 스택과 패턴 결정 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ 나: "할 일 관리 앱 만들 건데, Next.js + Supabase 쓸 거야." │ │ │ │ AI: "할 일 목록 컴포넌트 어떻게 만들까요?" │ │ │ │ 나: "Container-Presenter 패턴으로 분리해줘. │ │ │ │ TodoListContainer: │ │ - Supabase에서 할 일 목록 가져오기 │ │ - 추가/삭제/완료 처리 │ │ - 로딩/에러 상태 관리 │ │ │ │ TodoListPresenter: │ │ - 받은 데이터로 리스트 렌더링만 │ │ - 버튼 클릭하면 Container 함수 호출 │ │ │ │ 나중에 UI만 바꿀 수 있게." │ │ │ └───────────────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────────────┐ │ 2단계: 세부 구조 협의 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ AI: "알겠어요. 그럼 할 일 추가 버튼은 여러 개 만들 건가요? │ │ 메인 화면, 상세 화면, 퀵 추가 버튼..." │ │ │ │ 나: "맞아. 팩토리 패턴으로 버튼 타입별로 만들어줘. │ │ createButton(type)으로 주요/보조/작은 버튼 찍어내게." │ │ │ │ AI: "네, 그럼 구조 제안합니다: │ │ │ │ components/ │ │ - TodoListContainer.tsx (데이터 + 로직) │ │ - TodoListPresenter.tsx (UI만) │ │ - buttonFactory.ts (버튼 생성 로직) │ │ │ │ hooks/ │ │ - useTodos.ts (할 일 상태 관리) │ │ │ │ useTodos는 싱글톤처럼 앱 전체에서 하나만 쓰고, │ │ 옵저버 패턴으로 할 일 바뀌면 자동 업데이트할게요." │ │ │ │ 나: "좋아. 그렇게 만들어줘." │ │ │ └───────────────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────────────┐ │ 3단계: 구현 및 기능 단위 확인 │ ├───────────────────────────────────────────────────────────────────────┤ │ │ │ AI: "기본 구조 만들었어요. 확인해보세요." │ │ │ │ [기능 단위로 직접 확인] │ │ 1. 할 일 추가 버튼 클릭 │ │ → 입력 폼 잘 뜸 ✅ │ │ │ │ 2. 할 일 입력 후 저장 │ │ → 리스트에 바로 추가됨 ✅ │ │ │ │ 3. 새로고침 │ │ → DB에서 다시 가져옴 ✅ │ │ │ │ 4. 완료 체크박스 클릭 │ │ → 어? 체크는 되는데 리스트 갱신이 안 되네? │ │ │ │ 나: "완료 처리하면 리스트가 자동으로 갱신되게 해줘." │ │ │ │ AI: "useTodos에 옵저버 패턴 추가할게요. │ │ 완료 상태 바뀌면 구독 중인 컴포넌트들이 자동 업데이트돼요." │ │ │ │ [다시 확인] │ │ - 완료 체크 → 리스트 자동 업데이트 ✅ │ │ - 버튼 3종류 스타일 일관성 ✅ │ │ - 새로고침해도 데이터 유지 ✅ │ │ │ │ 💡 여기서 뭐가 중요했나요? │ │ - 패턴 이름을 정확히 말함 (Container-Presenter, 팩토리) │ │ - 왜 그 패턴을 쓰는지 이유 제시 ("나중에 UI만 바꿀 수 있게") │ │ - AI가 제안하면 확인 후 진행 │ │ - 기능 단위로 직접 확인하고 피드백 (가장 중요!) │ │ │ └───────────────────────────────────────────────────────────────────────┘
패턴 선택 가이드
어떤 상황에 어떤 패턴을 쓸까요?
🎯 앱 전체에서 하나만 있어야 할 때
→ 싱글톤
예: 로그인 상태, 앱 설정, DB 연결
🎯 비슷한 걸 여러 개 만들 때
→ 팩토리
예: 버튼, 카드, 알림
🎯 하나 바뀌면 여러 곳 업데이트될 때
→ 옵저버
예: 로그인, 장바구니, 실시간 알림
🎯 같은 목적인데 방법이 여러 개일 때
→ 전략
예: 결제 수단, 정렬 기준, 로그인 방법
🎯 로직과 화면 분리하고 싶을 때
→ Container-Presenter
예: 대부분의 프론트엔드 컴포넌트
💡 헷갈리면 일단 Container-Presenter부터
프론트엔드는 거의 다 이 패턴으로 시작 코드 문법 몰라도 돼요
💡 잠깐, 저는 코드를 못 짜는데요?
괜찮아요. 패턴 개념만 알면 돼요.
여러분이 알아야 할 것:
✅ 싱글톤 = 하나만 만들기 (로그인 상태)
✅ 팩토리 = 찍어내기 (버튼 여러 개)
✅ 옵저버 = 구독하기 (상태 변화 알림)
✅ 전략 = 방법 바꾸기 (결제 수단)
✅ Container-Presenter = 로직/UI 분리
여러분이 몰라도 되는 것:
❌ 패턴을 코드로 어떻게 구현하는지
❌ 클래스, 인터페이스 문법
❌ GoF 디자인 패턴 23개
→ AI한테 "싱글톤으로 해줘"라고 말만 하면 돼요.
→ AI가 패턴대로 코드 짜줘요.
주의사항: 패턴이 정답은 아니에요
⚠️ 모든 걸 패턴으로 짤 필요는 없어요
❌ 비현실적 (패턴 남용)
모든 코드를 패턴으로 짜야 한다고 생각
→ 오버엔지니어링. 간단한 것도 복잡해짐.
✅ 현실적 (필요할 때만)
필요한 곳에만 패턴 적용
→ 간단한 건 그냥 짜고, 복잡해지면 패턴 도입
💡 핵심 원칙:
- 처음엔 간단하게 시작
- 같은 문제가 반복되면 그때 패턴 적용
- "이 패턴 써야지" 보다 "이 문제 어떻게 풀지?" 먼저
- AI한테 물어보고 추천받는 것도 방법 근데 이것만은 지키세요:
- 프론트엔드는 Container-Presenter로 시작 (로직/UI 분리)
- 앱 전역 상태는 싱글톤으로 (로그인, 설정 등)
- 비슷한 컴포넌트 3개 이상이면 팩토리 고려
- 여러 곳 업데이트 필요하면 옵저버 고려
다음 단계: 상태 관리
패턴을 알았으면 이제 상태를 어떻게 관리할지 정하는게 중요해요.
오늘 배운 것: 코드를 어떻게 짤지
→ 싱글톤, 팩토리, 옵저버, 전략, Container-Presenter
다음 편: 데이터(상태)를 어디에 둘지
→ 전역 상태 vs 로컬 상태
→ "로그인 상태는 전역, 폼 데이터는 로컬"
오늘의 핵심 정리
→ 같은 문제는 같은 방식으로 해결 → 코드 일관성
✅ 바이브 코더가 알아야 할 패턴 5가지
→ 싱글톤: 하나만 만들기 (로그인 상태)
→ 팩토리: 찍어내기 (버튼, 카드)
→ 옵저버: 구독하기 (상태 변화 알림)
→ 전략: 방법 바꾸기 (결제 수단)
→ Container-Presenter: 로직/UI 분리
✅ 아키텍처 vs 디자인 패턴
→ 아키텍처: 전체 구조 (레이어드, MVC)
→ 디자인 패턴: 세부 코드 (싱글톤, 팩토리)
→ 둘 다 알아야 AI한테 정확히 지시 가능
✅ AI한테 요청할 때:
"로그인 상태 관리해줘" (X)
"로그인 상태를 싱글톤 패턴으로 앱 전체에서 하나만 만들어줘.
옵저버 패턴으로 상태 바뀌면 헤더, 사이드바가 자동 업데이트되게." (O)
✅ 코드 문법 몰라도 돼요
→ 개념만 알고 AI한테 "이 패턴으로 해줘"라고 말하면 됨셀프체크
이 글을 이해했다면 아래 질문에 답할 수 있어요:
- 로그인 상태를 관리할 때 어떤 패턴을 쓰면 좋을까요? (하나만 있어야 함)
- 주요/보조/위험 버튼 3종류를 만들 때 어떤 패턴이 좋을까요?
- 할 일 목록 컴포넌트를 로직과 UI로 분리하려면 어떤 패턴을 쓰면 되나요?
정답 보기
- 싱글톤 패턴 (앱 전체에서 하나의 로그인 상태만 유지)
- 팩토리 패턴 (createButton(type)으로 타입별 버튼 찍어내기)
- Container-Presenter 패턴 (Container는 데이터, Presenter는 UI)
다음 글 예고
오늘은 디자인 패턴을 배웠어요. 싱글톤, 팩토리, 옵저버 같은 코드 작성 패턴이요.
근데 패턴만 알면 부족해요. "데이터(상태)를 어디에 둘지"도 중요해요.
다음 글에서는 상태 관리 개념을 알아볼게요.
19편: 상태 관리 개념
- "로그인 상태는 어디에? 폼 데이터는 어디에?"
- 전역 상태 vs 로컬 상태
- "로그인 상태는 전역으로, 폼 데이터는 로컬로 관리해줘"
패턴으로 코드 짜는 법을 배웠으면, 이제 상태를 어떻게 관리할지 배워요.
이 시리즈 로드맵
PART 4: 기술 개념 - 설계
[ 16편 ] 자료구조 개념 ✅
↓
[ 17편 ] 아키텍처 개념 ✅
↓
[ 18편 ] 디자인 패턴 개념 (지금 여기!)
↓
[ 19편 ] 상태 관리 개념
↓
[ 20편 ] AI한테 설계 지시하는 법
↓
...
궁금한 점이나 다뤘으면 하는 주제가 있으면 댓글로 남겨주세요!