🗺️ Design 폴더 읽기 가이드

이 폴더는 "프로그램을 처음부터 설계하고, AI에게 구현을 맡기고, 검증하는" 전체 과정을 다룬다. 바이브 코딩에서 유지보수 가능한 개발로 넘어가기 위한 사고 프레임워크다.

읽는 순서

네 파트 + 기타로 구성된다. 순서대로 읽으면 하나의 흐름이 된다.

Part 1 — 설계하는 법

"뭘 만들지, 어떤 구조로 만들지"를 결정하는 과정

① how-to-design-a-program-from-scratch    ← 여기서 시작
   전체 설계 프로세스 6단계 개관
   
② how-to-scope-requirements
   1단계(요구사항)를 깊이 다룸
   범위와 깊이를 잡는 실전 방법
   
③ domain-modeling-vs-implementation-unit
   2단계(도메인 모델링)의 핵심 판단
   "한 번에 설계 vs 쪼개서 설계"

④ what-is-data-design
   5단계(데이터 설계)
   도메인 모델을 저장 형태로 변환

Part 2 — 기술 스택과 아키텍처

"뭘로 만들지"를 결정하는 과정

⑤ how-to-choose-tech-stack
   데이터 위치(Local/Server/Hybrid)가
   기술 스택 전체를 결정하는 구조

⑥ designing-local-app-with-server-dependency
   "기본은 로컬인데 LLM이 필요한" 현실적 케이스
   서버 의존성을 격리하는 설계

⑪ architecture-patterns-overview
   Layered, Clean, MVC, MVVM, Event-Driven,
   Microservices, Pipe and Filter 전체 지도

⑬ component-decomposition-by-architecture
   아키텍처별 컴포넌트 분해 방법
   AI에게 작업을 맡기는 단위와 순서

Part 3 — 구성요소 내부 설계

각 영역(UI, Server, AI, 보안)을 들여다봤을 때의 깊이

⑫ designing-component-internals
   UI: 디자인 시스템, 레이아웃, 상태 관리
   Server: API, 성능, 에러 전략
   AI/LLM: 기능 범위, 입출력, 실패 대응
   보안: 보호 대상, 인증, 데이터 전송 범위
   → 각 영역에서 "방향"만 정하고 구현은 AI에게

Part 4 — 검증하는 법

AI가 만든 결과물이 내 설계와 맞는지 확인하는 과정

⑦ where-humans-must-verify-in-design
   설계의 어느 지점을 인간이 검증해야 하는가
   수정 비용의 비대칭성

⑧ how-to-verify-implementation-matches-design
   구현 후 구조 검증 실전 루틴 (30분)
   import 방향, 타입 정의, 폴더 구조 체크

⑨ diagram-types-for-design-verification
   검증에 쓸 수 있는 다이어그램 종류
   상황별 선택 가이드

기타 — 특수 상황과 응용

메인 흐름에서 벗어나는 변형 케이스들

⑩ design-when-data-comes-first
   크롤링, 외부 API, 레거시 DB처럼
   데이터가 이미 정해져 있을 때의 설계 변형
   변환 계층의 필요성

⑭ design-beyond-apps
   앱이 아닌 것을 설계할 때
   프레임워크: "사용자가 개발자" — API 표면 설계
   AI 모델: "가설→실험→측정→수정" 반복 루프
   프로토콜: "양쪽 합의" — 상태 머신, 하위 호환
   → 6단계 뼈대는 유지, 각 단계의 질문이 달라짐

⑮ design-for-embedded-and-physical-ai
   소프트웨어를 넘어 물리 세계와 만나는 설계
   시간 제약, 자원 제약, 물리적 안전
   실시간 계층 분리, 시뮬→실물 검증

⑯ from-tech-design-to-career-design
   설계적 사고를 기술 너머로 확장
   취업가: 깊이 + 맥락, "왜 이렇게 만들었는가"
   연구자: 깊이 + 새로움, 연구계획서 = 설계 문서
   창업가: 넓이 + 연결, 사업계획서 = 설계 문서
   → 6단계가 연구/사업/커리어에도 동일하게 적용

전체 흐름도

빠르게 찾기

| 이런 상황이면 | 이 노트를 봐 | |---|---| | 프로젝트 시작, 뭐부터 하지? | how-to-design-a-program-from-scratch\|① | | 기능이 너무 많아서 범위를 못 정하겠다 | how-to-scope-requirements\|② | | 도메인 모델을 어디까지 한 번에 그리지? | domain-modeling-vs-implementation-unit\|③ | | DB 테이블을 어떻게 만들지? | what-is-data-design\|④ | | 프레임워크/DB를 뭘 쓰지? | how-to-choose-tech-stack\|⑤ | | 로컬 앱인데 LLM을 붙이고 싶다 | designing-local-app-with-server-dependency\|⑥ | | AI가 만든 코드를 어떻게 믿지? | where-humans-must-verify-in-design\|⑦ → how-to-verify-implementation-matches-design\|⑧ | | 검증할 때 어떤 다이어그램을 요청하지? | diagram-types-for-design-verification\|⑨ | | 크롤링/외부 API처럼 데이터가 먼저다 | design-when-data-comes-first\|⑩ | | 아키텍처 종류가 뭐가 있지? | architecture-patterns-overview\|⑪ | | UI/Server/AI/보안을 어디까지 설계하지? | designing-component-internals\|⑫ | | 아키텍처별로 파일을 어떻게 나누고 AI에게 맡기지? | component-decomposition-by-architecture\|⑬ | | 앱이 아니라 프레임워크/모델/프로토콜을 만든다 | design-beyond-apps\|⑭ | | 임베디드/로봇/Physical AI를 설계한다 | design-for-embedded-and-physical-ai\|⑮ | | 설계적 사고를 연구/사업/커리어에 적용하고 싶다 | from-tech-design-to-career-design\|⑯ |