📅 2026-05-08 (금)
✍️ 공부한 내용
프로젝트의 기획과 설계
기획과 설계는 다르다 — "무엇을"과 "어떻게"의 차이
기획 vs 설계
| 기획 (Planning) | 설계 (Design) | |
|---|---|---|
| 핵심 질문 | 무엇을 만들 것인가 | 어떻게 만들 것인가 |
| 내용 | 누구의 어떤 문제를 해결할지 정의 | 어떤 기술·구조로 만들지 결정 |
둘 다 단순한 문서 작업이 아니라, 프로젝트 전체를 이끄는 핵심 과정이다.
기획·설계가 명확하지 않으면 개발 과정에서 혼란이 생긴다.
좋은 문제 정의에서 시작한다
기획의 출발점은 사용자의 진짜 불편함이어야 한다.
| 나쁜 출발점 ❌ | 좋은 출발점 ✅ |
|---|---|
| "AI 챗봇 만들고 싶어요" | "취준생이 새벽 3시에 자소서 첨삭받을 곳이 없다" |
| "지도 API 써보고 싶어요" | "원룸 매물을 사이트마다 같은 걸 5번씩 본다" |
우리 팀의 타겟은 [누구] 이고,
그들이 겪는 불편은 [어떤 불편] 이며,
우리는 [무엇으로] 이 문제를 해결한다.
좋은 문제 정의는 위처럼 한 문장으로 정의될 수 있어야 한다.
기획의 6단계 흐름
- 문제 정의 — 사용자의 진짜 불편함이 무엇인가
- 아이디어 구상 및 콘셉트 정의 — 그 불편을 어떤 방식으로 해결할 것인가
- 타당성 검토 — 기술적/데이터/경제적으로 현실 가능한가
- 요구사항 수집 및 분석 — 구체적으로 어떤 기능이 필요한가
- 요구사항 명세서 작성 — 팀원 모두가 같은 그림을 보도록
- 이해관계자 검증 — 팀과 합의된 그림인가
MoSCoW로 요구사항 우선순위 매기기
진짜 실력은 "무엇을 안 만들 것인지" 를 정하는 것이다.
| 분류 | 의미 | 역할 |
|---|---|---|
| Must have | 없으면 서비스가 아님 | 발표 전 무조건 완성 |
| Should have | 있어야 정상이지만 일단 없어도 됨 | 1차 완성 후 추가 |
| Could have | 있으면 좋지만 우선순위 낮음 | 시간 남으면 진행 |
| Won't have | 이번 프로젝트엔 안 함 | 발표에서 "추후 계획"으로 언급 |
좋은 UI/UX의 5원칙
- 시각적 위계 — 가장 중요한 버튼은 가장 눈에 띄어야 한다
- 즉각적 피드백 — 클릭·입력에 즉시 반응 (로딩 표시, 실시간 검증)
- 점진적 공개 — 한 화면에 한 가지 결정만 (One Thing Per Page)
- 친절한 에러 — "ERROR_500" 대신 사람의 언어로 안내
- 목적과 일치 — 무한스크롤 vs 페이지네이션, 콘텐츠 성격에 맞게 선택
마무리
- 와이어프레임이 곧 코드다. 와이어프레임을 잘 만들면
urls.py를 거의 받아쓸 수 있다. - ERD에서 명사 → 엔티티, 동사 → 관계. 기획서를 잘 쓰면 DB 설계가 자연스럽게 따라온다.
- 좋은 아이디어 ≠ 만들 수 있는 아이디어. 타당성 검토는 선택이 아닌 필수다.
뭘봐