learn

🗺️ Design 폴더 읽기 가이드

🗺️ 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\|⑯