학습 목표
- 회원가입이 모든 프로젝트의 공통 기능임을 안다
- 기획 → 요구사항 → 유스케이스 → 화면 → 구현 의 한 줄기 흐름을 그릴 수 있다
- 같은 데이터 약속이면 화면 디자인은 갈아끼울 수 있음을 직접 확인한다
오늘 들고 가는 3 가지
- 회원가입은 모든 프로젝트의 공통 기능 — 한 번 살펴두면 다음이 쉽다.
- 프로젝트는 기획 → 요구사항 → 유스케이스 → 화면 → 구현 단계로 굴러간다.
- 같은 데이터 약속이면 화면 디자인은 갈아끼울 수 있다 — Backend 는 그대로.
0. 회원가입 — 어디에나 있는 그 기능
쇼핑몰·SNS·게시판·예약·배달앱·동영상 사이트 — 어떤 서비스든 회원가입 폼은 거의 똑같이 생겼다. 입력칸 몇 개와 가입 버튼. 흔한 화면이지만 한 번 제대로 들여다 보면, 다음 모든 프로젝트가 쉬워진다. 이미 v2~v4 에서 따라하기로 코드를 완성했으므로, 오늘은 그 코드가 「어떻게 만들어지는지」 위에서 내려다본다.
1. 프로젝트의 단계 — 기획에서 구현까지
① 기획 ② 요구사항정의서 ③ 유스케이스 ④ 화면 스케치 ⑤ 구현
"가입 만들자" ★ id, pwd, nick "폼 입력→가입→이동" 3칸 + 버튼 1개 Front+Back+DB
↑
데이터 약속이 처음 정해지는 자리 — 이후 모든 트랙이 이걸 따른다
| 단계 | 하는 일 | 회원가입 예 |
|---|
| ① 기획 | 기능을 만들기로 정함 | "회원가입 기능을 만들자" |
| ② 요구사항정의서 | 어떤 데이터를 저장할까 | id, pwd, nick |
| ③ 유스케이스 | 사용자가 어떻게 쓰는지 한 줄 | "폼 3칸 입력 → 가입 → 로그인 페이지로" |
| ④ 화면 스케치 | 디자이너가 그림으로 | 입력칸 3개 + 버튼 1개 |
| ⑤ 구현 | Front + Back + DB | JSP / Controller / mymember |
2. 3 트랙 한눈에
| 트랙 | 주된 산출물 | 주된 도구 | 핵심 약속 |
|---|
| Frontend |
HTML / CSS / JS, 디자인된 폼 |
VS Code, Figma, 브라우저 |
<input name="..."> 의 이름 |
| Backend |
Controller, Service, Mapper, DTO |
Eclipse, Tomcat, Postman |
DTO 필드명 |
| DB |
테이블, 인덱스, 가데이터 |
MySQL Workbench |
테이블 컬럼명 |
시각 → 09:00 11:00 14:00 16:00
Front ▣ wireframe ▣ CSS ▣ 디자인 폼 ─────┐
Back ▣ DTO ▣ Service ▣ Mapper ─────┼──→ ◆ 합치기
DB ▣ ERD ▣ CREATE ▣ 가데이터 ─────┘ (이름이 같아 자연 합쳐짐)
3. 「같은 이름」 매핑 표 (회원가입 예시)
| 의미 | 약속한 이름 | Front (form name) | Back (DTO 필드) | DB (컬럼명) |
|---|
| 아이디 | id | name="id" | String id | id VARCHAR(50) |
| 비밀번호 | pwd | name="pwd" | String pwd | pwd VARCHAR(100) |
| 닉네임 | nick | name="nick" | String nick | nick VARCHAR(30) |
한 줄 원칙: 같은 데이터에 같은 이름을 쓰면, 세 사람이 동시에 일해도 시스템이 합쳐진다.
브라우저 폼 자바 객체 MySQL 테이블
name="id" ─→ String id ─→ id VARCHAR(50)
name="pwd" ─→ String pwd ─→ pwd VARCHAR(100)
name="nick" ─→ String nick ─→ nick VARCHAR(30)
↑
★ 한 글자라도 다르면 합치는 순간 깨짐
4. 폼만 갈아끼우기 — 같은 데이터, 다른 디자인
같은 데이터를 받는 화면은 디자인이 갈아끼워질 수 있다. action, method, name 만 약속대로면 화면은 무엇이든 가능 — Backend 는 한 줄도 안 바뀐다.
[디자인 A] 단순 폼 [디자인 B] 카드 + 그래디언트
<input name="id"> <input name="id">
<input name="pwd"> <input name="pwd">
<input name="nick"> <input name="nick">
↓ ↓
└────── 같은 Controller ───────┘
@PostMapping("/signup") public String signup(Member m)
5. 약속이 깨졌을 때 발생하는 3 가지 사고
사고 ① null 바인딩 — 폼 name 과 DTO 필드명 불일치
<input name="userId"> ←→ private String id;
↓
콘솔: Member(id=null, pwd=*, nick=*)
^^^^^^^ 자동 바인딩 실패 — 에러 안 남, 데이터만 비어있음
가장 자주 나는 사고. 화면도 서버도 안 죽기 때문에 발견까지 시간이 걸린다.
사고 ② NoSuchColumn — DTO 필드명과 컬럼명 불일치
private String password; ←→ DB 컬럼: pwd
↓
SQLException: Unknown column 'password' in 'field list'
DB 가 즉시 거부하므로 차라리 빨리 잡힌다. INSERT/SELECT 모두에서 발생.
사고 ③ 화면-DB 불일치 — 화면이 다른 이름으로 참조
JSP: ${m.nickname} ←→ DTO: String nick
↓
INSERT 는 정상, 그러나 화면의 닉네임 자리가 모두 빈 칸. 에러도 안 남.
6. 팀 프로젝트 시작 체크리스트
첫 회의 30 분 안에 합의할 5 가지
- ① 네이밍 약속 — 폼
name = DTO 필드 = 컬럼명. 한 표로 정리.
- ② ERD 합의 — 테이블 / 컬럼명 / 타입 / 관계.
- ③ API 명세 합의 — 어떤 URL 에 어떤 데이터가 오가는지.
- ④ Git 저장소 합의 — 브랜치 전략, 커밋 메시지 규칙.
- ⑤ 합치기 시점 합의 — 처음 셋이 만나는 날.
이 5 가지를 첫날에 정해놓으면 사고의 90% 가 사라진다.
7. Before / After
따라하기 직후
회원가입 코드는 동작한다. 그러나 「왜 그렇게 짜는지」 와 「화면이 바뀌면 어떻게 되는지」 는 안 보였다.
한 번 내려다본 후
기획→요구사항→화면→구현 단계가 보이고, 데이터 약속이 모든 트랙을 잇는다. 화면 디자인은 갈아끼울 수 있다.
학습 확인 체크리스트
- 회원가입이 어디에나 있는 보편 기능임을 안다
- 기획 → 요구사항 → 유스케이스 → 화면 → 구현 단계를 그릴 수 있다
- 요구사항의 데이터 약속이 모든 트랙을 통과함을 안다
- 같은 데이터 약속이면 화면 디자인은 갈아끼울 수 있음을 안다
- 약속이 깨졌을 때 나는 3 가지 사고 모양을 안다