Frontend 담당 — 회원가입 화면 만들기

이 페이지는 Frontend 담당 학생을 위한 전용 가이드입니다. 회원가입 기능을 예시로, 화면을 만드는 사람이 무엇을 먼저 결정하고 어떻게 진행하는지 자세히 다룹니다. ← 협업 메인으로 돌아가기

한 줄 요약

먼저 약속(form name 명세), 그 다음 디자인.
서버에 무엇을 보낼지를 먼저 정한 다음, 그 필드들을 가진 화면을 여러 디자인으로 시도합니다. 디자인이 바뀌어도 form name은 절대 바뀌지 않아요.

Frontend 작업 흐름

Frontend

화면 담당 · JSP / HTML / CSS

작업 순서 — "먼저 약속, 그 다음 디자인"

  1. Step 1 — form 필드부터 확정: 화면을 그리기 전에, "백엔드에 줄 값이 무엇인지" 를 먼저 결정합니다. name 속성 목록이 그거예요. 이건 Backend에게 바로 공유.
  2. Step 2 — 그 필드들이 들어간 화면을 여러 스타일로 시도: 가로/세로 배치, 카드형, 스텝 방식 등. name 은 절대 바뀌지 않고, CSS와 HTML 구조만 달라집니다.
  3. Step 3 — 팀원들과 디자인 시안 비교 후 하나 선택.
  4. Step 4 — 선택된 디자인을 최종본으로 다듬기.

Step 1 · 공유할 form 명세를 먼저 선언

코드를 쓰기 전에 종이에 적거나 공유 문서에 올립니다. 이게 Backend가 받아야 할 "약속" 입니다.

// 이 값들이 서버로 갑니다 (name 기준)
userId          // text, 필수
password        // password, 필수
passwordConfirm // password, 필수 (서버에 보내긴 하지만 저장 안 함)
nickname        // text, 필수
email           // email, 필수
phone           // text, 선택
hobbies         // checkbox 복수 선택
favoriteColor   // radio
job             // select

action = "register", method = "post"

Step 2 · 같은 form 명세, 다른 디자인 (시안 A)

가로 배치 — 라벨이 왼쪽, input이 오른쪽에 붙는 기본 스타일.

<%-- join.jsp · 디자인 시안 A : 가로 라벨 --%>
<form action="register" method="post" class="join-form-A">
  <div class="row">
    <label>아이디</label>
    <input type="text" name="userId" required>
  </div>
  <div class="row">
    <label>비밀번호</label>
    <input type="password" name="password" required>
  </div>
  <div class="row">
    <label>비밀번호 확인</label>
    <input type="password" name="passwordConfirm" required>
  </div>
  <div class="row">
    <label>닉네임</label>
    <input type="text" name="nickname" required>
  </div>
  <div class="row">
    <label>이메일</label>
    <input type="email" name="email" required>
  </div>
  <div class="row">
    <label>연락처</label>
    <input type="text" name="phone">
  </div>
  <button type="submit">가입하기</button>
</form>
시안 A 스크린샷
시안 A · 실제 렌더링된 모습 — 가로 라벨 배치, 담백한 블루 톤

Step 2 · 다른 디자인 (시안 B) — name은 그대로!

카드형 세로 배치 — 플레이스홀더로 라벨을 대체하고, 필드끼리 세로로 넉넉히 벌림.

<%-- join.jsp · 디자인 시안 B : 카드형 세로 --%>
<form action="register" method="post" class="join-card">
  <h2>회원가입</h2>
  <input type="text"     name="userId"          placeholder="아이디"         required>
  <input type="password" name="password"        placeholder="비밀번호"       required>
  <input type="password" name="passwordConfirm" placeholder="비밀번호 확인"  required>
  <input type="text"     name="nickname"        placeholder="닉네임"         required>
  <input type="email"    name="email"           placeholder="이메일"         required>
  <input type="text"     name="phone"           placeholder="연락처 (선택)">
  <button type="submit">가입</button>
</form>
시안 B 스크린샷
시안 B · 실제 렌더링된 모습 — 카드형 + 그라데이션 배경, 칩 스타일 취미/색 선택
두 시안의 공통점: action, method, 그리고 모든 name 속성이 완전히 동일합니다. 다른 건 HTML 구조와 CSS 클래스뿐이에요. 이게 핵심이에요 — 디자인은 자유롭게 바꿔도 name 하나라도 바뀌면 백엔드가 깨집니다.

같은 데이터, 다른 UI — Frontend의 자유도

"좋아하는 색" 이라는 하나의 데이터를 받을 때, Frontend는 여러 UI 방식 중 아무거나 선택할 수 있습니다. 중요한 건 UI가 어떻게 생겼든 서버에 전달되는 건 결국 favoriteColor=값 하나라는 점입니다. Backend는 UI가 text인지 color picker인지 radio인지 알 필요가 없어요. 이게 Frontend와 Backend가 분리되는 의미입니다.

UI 방식 1 · text input (자유 입력) — 사용자가 직접 타이핑

<input type="text" name="favoriteColor" placeholder="좋아하는 색">
// 사용자 입력 예: "파랑", "하늘색", "연두" ...  (자유 문자열)

UI 방식 2 · HTML5 color picker — 브라우저 기본 색 선택기

<input type="color" name="favoriteColor" value="#4fc3ff">
// 서버가 받는 값: "#4fc3ff" (hex 코드)

UI 방식 3 · radio buttons — 사전 정의된 옵션 중 하나

<label><input type="radio" name="favoriteColor" value="빨강">빨강</label>
<label><input type="radio" name="favoriteColor" value="파랑">파랑</label>
<label><input type="radio" name="favoriteColor" value="초록">초록</label>
// 서버가 받는 값: "빨강" 또는 "파랑" 또는 "초록" (value 중 하나)

UI 방식 4 · select dropdown — 드롭다운에서 선택

<select name="favoriteColor">
  <option value="빨강">빨강</option>
  <option value="파랑">파랑</option>
  <option value="초록">초록</option>
</select>
// 서버가 받는 값: 선택된 option의 value

서버 입장에서는 — 전부 동일

// RegisterServlet.java — UI가 뭐든 이 한 줄로 받는다
String color = req.getParameter("favoriteColor");
4가지 UI 방식 비교
네 가지 UI 방식을 나란히 비교 · 모두 name="favoriteColor", 서버 코드는 한 줄로 동일
이게 "계약"의 진짜 의미입니다. Frontend가 UI를 어떻게 바꿔도 form name과 value 형식만 지키면 Backend는 영향 없습니다. 디자인 시안에서 radio였던 걸 다음 날 color picker로 바꿔도 Controller는 한 줄도 수정 안 해요. 이게 name/value 인터페이스로 분리 의 의미입니다.
주의 — Day 1에 "value 형식"도 같이 정해야 합니다. text input이면 "파랑" (자유 문자열), color picker면 "#4fc3ff" (hex). Frontend가 중간에 UI 방식을 바꿔서 값 형식이 달라지면, DB에 이미 들어간 기존 데이터와 섞여 통계가 엉망이 됩니다. Day 1 계약서에 "favoriteColor는 '빨강·파랑·초록·노랑' 중 하나의 한글 단어" 처럼 value 형식까지 명시.

취미 입력 (checkbox 복수) — 특별한 케이스

checkbox는 한 name에 여러 값이 선택될 수 있다는 점에서 다른 타입들과 다릅니다. "취미" 는 보통 복수 선택이 자연스럽죠 (독서·운동·영화 동시에 가능).

<fieldset>
  <legend>취미 (여러 개 선택 가능)</legend>
  <label><input type="checkbox" name="hobbies" value="독서">독서</label>
  <label><input type="checkbox" name="hobbies" value="운동">운동</label>
  <label><input type="checkbox" name="hobbies" value="영화">영화</label>
  <label><input type="checkbox" name="hobbies" value="음악">음악</label>
  <label><input type="checkbox" name="hobbies" value="게임">게임</label>
  <label><input type="checkbox" name="hobbies" value="요리">요리</label>
</fieldset>

모든 checkbox가 같은 name="hobbies" 라는 점이 핵심입니다. 사용자가 "독서" 와 "운동" 을 체크하면 브라우저는 hobbies=독서&hobbies=운동 식으로 두 번 보냅니다. 이걸 서버에서 어떻게 받는지는 Backend 페이지 에서 자세히 다룹니다.

Frontend가 Backend에게 공유하는 것

  • form 필드 명세 한 장 (위의 Step 1 목록). 디자인이 바뀌어도 이 목록은 고정.
  • action URL과 method (POST /register).
  • (나중에) 실제로 완성된 join.jsp 파일. Backend가 자기 페이지 대신 이걸 쓸 수 있도록.

Frontend가 절대 하면 안 되는 것

1. form action URL을 임의로 정하기. 반드시 Day 1에 합의된 URL을 그대로 써야 합니다. Backend는 그 URL로 Servlet을 만들고 있으니까요.
2. name 속성을 임의로 짓기. name="userId" 인지 name="user_id" 인지가 안 맞으면 Backend가 파라미터를 못 받습니다.
3. checkbox/radio의 value를 회의 후 바꾸기. "빨강" 을 "red" 로 바꾸면 DB에 저장된 기존 데이터와 섞입니다.

다른 역할의 가이드 보기