◆ PART · TEAM

팀 분업 시뮬레이션

세 트랙이 「같은 이름」 으로 만나는 자리

학습 목표

  • 회원가입이 모든 프로젝트의 공통 기능 임을 안다
  • 기획 → 요구사항 → 화면 → 구현 의 한 줄기 흐름 을 그릴 수 있다
  • 팀 프로젝트가 어떻게 분업되는지 안다 (Front / Back)
  • 세 트랙이 같은 데이터 이름 으로 만난다는 원칙을 이해한다
  • 같은 데이터를 받는 화면은 디자인이 갈아끼워질 수 있다 는 것을 직접 확인한다

회원가입 — 어디에나 있는 그 기능

한 번 잘 살펴볼 가치가 있는 이유

쇼핑몰·SNS·게시판·예약·배달앱·동영상 사이트 — 서비스 모양이 달라도 회원가입 폼은 거의 똑같이 생겼습니다. 수많은 프로젝트가 같은 모양을 다시 만들고 있습니다. 그래서 한 번 제대로 들여다 보면, 다음 모든 프로젝트가 쉬워집니다.

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 쇼핑몰 │ │ SNS │ │ 게시판 │ │ 예약 │ │ 가입 폼 │ │ 가입 폼 │ │ 가입 폼 │ │ 가입 폼 │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 배달 │ │ 스트리밍 │ │ 학원관리 │ │ 은행 │ │ 가입 폼 │ │ 가입 폼 │ │ 가입 폼 │ │ 가입 폼 │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ 모두 같은 「id / pwd / nick」 약속

오늘은 「따라하기」 가 아니라 「내려다보기」

이미 v2 ~ v4 에서 회원가입을 따라하기로 한 번 완성했습니다. 코드는 동작하고 있습니다.

오늘은 그 코드가 어떻게 만들어졌는지 위에서 내려다보는 시간입니다 — 실제 프로젝트 현장이라면, 이 회원가입 한 화면이 어떤 단계를 거쳐 짜이는가?

「프로젝트의 일면 (一面)」 — 한 화면이 만들어지는 전체 모습을 한 번 비추어 봅니다.

🛠️ 도구 — 프로젝트는 이 단계로 굴러간다

기획 → 요구사항 → 유스케이스 → 화면 스케치 → 구현

실제 팀 프로젝트는 코드 짜기 전에 이 단계를 모두 지납니다. 우리는 한 차시에 압축해서 한번 훑어봅니다.

① 기획 ② 요구사항 ③ 유스케이스 ④ 화면 스케치 ⑤ 구현 ────── ───────── ────────── ─────────── ────── 뭘 만들지 무슨 데이터를 사용자가 어떻게 화면 어떻게 Front 결정 저장할지 쓸지 한 줄 그릴지 Back DB ↓ ↓ ↓ ↓ ↓ 「회원가입을 ★ id, pwd, nick "폼 입력 → 입력 3칸 폼 / 컨트롤러 만들자」 ← 데이터 약속 가입 버튼 → + 버튼 1개 / 테이블 처음 정해짐! redirect"

🛠️ 단계별 한 줄 풀어보기

단계 하는 일 회원가입 예
① 기획 기능을 만들기로 정함 "회원가입 기능을 만들자"
② 요구사항정의서 어떤 데이터를 저장할까 id, pwd, nick
③ 유스케이스 사용자가 어떻게 쓰는지 한 줄 "폼에 3칸 입력 → 가입 버튼 → 로그인 페이지"
④ 화면 스케치 디자이너가 그림으로 입력칸 3개 + 버튼 1개
⑤ 구현 Front + Back + DB JSP / Controller / mymember 테이블

👉 ② 요구사항정의서에서 「id, pwd, nick」 이 정해지는 순간 — 이후 모든 트랙이 그 약속을 따른다.

⚠️ 혼자 다 짰는데 — 팀에선 어떻게?

지금까지의 모든 작업이 한 사람 손으로
  • 회원가입 화면 HTML 도 내가 짰고
  • Controller / Service / Mapper 도 내가 짰고
  • MySQL 테이블 설계와 INSERT 도 내가 했다

그런데 팀 프로젝트는 보통 3~5 명이 같이 한다. 누가 뭘 맡고, 어떻게 동시에 일할 수 있는지가 안 보인다.

⚠️ 세 곳을 동시에 만들 수 있다고?

순서대로 짜야 하는 거 아닌가?

상식적으로는 「DB → Backend → Frontend」 순서로 짜야 할 것 같다. 그런데 실제 팀에서는 세 사람이 같은 시간에 일한다.

  • 화면 디자이너는 서버가 없는데도 폼을 만든다
  • Backend 는 DB 가 없는데도 Controller 를 짠다
  • DBA 는 화면이 없는데도 테이블을 짠다

→ 어떻게 따로 일하고 합칠 수 있을까?

🛠️ 도구 — 「같은 데이터 이름」

약속 한 가지로 충분

설계 회의 첫 시간에 결정하는 한 가지: 이 데이터를 어떤 이름으로 부를까?

회원가입을 「세 사람의 약속 받기」 로 비유하면 — 세 사람이 같은 양식의 종이를 들고 시작합니다. 종이 위 칸 이름이 같으면, 누가 어떤 칸을 채워와도 자연스럽게 합쳐집니다.

회원 데이터 약속 id ─ 아이디 pwd ─ 비밀번호 nick ─ 닉네임

🛠️ 세 트랙의 출현 위치

트랙 어디에 등장 예시
Frontend <input name="..."> name="id", name="pwd", name="nick"
Backend DTO 필드명 private String id; private String pwd; private String nick;
DB 테이블 컬럼명 mymember(id, pwd, nick)

👉 셋이 완전히 똑같은 단어 를 쓴다. 한 글자라도 다르면 합치는 순간 깨진다.

「폼 name = DTO 필드 = 컬럼명」

브라우저 폼 자바 객체 MySQL 테이블 ────────── ───────── ──────────── name="id" ─→ String id ─→ id VARCHAR(50) name="pwd" ─→ String pwd ─→ pwd VARCHAR(100) name="nick" ─→ String nick ─→ nick VARCHAR(30) ↑ ↑ ↑ └───────────── 같은 단어 ─────────────────────┘

이 한 줄짜리 약속이 「세 사람이 동시에 일할 수 있는」 출발선.

💻 Frontend 트랙 — 디자인 폼


<!-- signup.html — Frontend 멤버가 만든 산출물 -->
<form action="/signup" method="post" class="signup-form">
  <h2>회원가입</h2>
  <input name="id"   placeholder="아이디">
  <input name="pwd"  type="password" placeholder="비밀번호">
  <input name="nick" placeholder="닉네임">
  <button>가입하기</button>
</form>

<style>
  .signup-form { max-width: 360px; padding: 24px; border-radius: 12px;
                 background:#fafafa; box-shadow:0 2px 8px rgba(0,0,0,.08); }
  .signup-form input { display:block; width:100%; padding:10px;
                       margin:8px 0; border:1px solid #ddd; }
  .signup-form button { width:100%; padding:12px; background:#3b82f6;
                        color:#fff; border:0; border-radius:6px; }
</style>

👉 디자인 / CSS 에 집중. 서버가 없어도 만들 수 있다. name 속성만 약속대로.

💻 Backend 트랙 — 빈 HTML + 로직


// com/smhrd/domain/Member.java — 약속한 이름으로 DTO
@Data @AllArgsConstructor @NoArgsConstructor
public class Member {
    private String id;     // ← 약속의 첫 칸
    private String pwd;    // ← 약속의 둘째 칸
    private String nick;   // ← 약속의 셋째 칸
}

// com/smhrd/controller/SignupController.java
@Controller
public class SignupController {
    @Autowired private MemberService service;

    @PostMapping("/signup")
    public String signup(Member m) {   // 폼 → DTO 자동 바인딩
        service.signup(m);
        return "redirect:/login";
    }
}

👉 화면이 없어도 빈 HTML 폼으로 시험 가능. DTO 필드명만 약속대로.

💻 DB 트랙 — 데이터가 가서 누울 자리


-- Backend 가 받은 데이터가 마지막에 들어가는 자리
CREATE TABLE mymember (
  id   VARCHAR(50)  PRIMARY KEY,
  pwd  VARCHAR(100) NOT NULL,
  nick VARCHAR(30)
);

👉 컬럼명이 약속의 마지막 자리. Front 의 폼 → Back 의 DTO → DB 의 컬럼 — 같은 단어가 끝까지 따라온다.

💻 핵심 — 폼만 갈아끼워보자

오늘의 한 가지 깨달음

같은 데이터를 받는 화면은 디자인이 갈아끼워질 수 있습니다.

name="id", name="pwd", name="nick" 만 지키면 — 화면 디자인은 무엇이든 가능합니다. 동일한 Backend, 동일한 DB, 다른 Frontend.

💻 디자인 A — 따라하기에서 만든 폼


<form action="/signup" method="post">
  <input name="id">
  <input name="pwd" type="password">
  <input name="nick">
  <button>가입</button>
</form>

단순한 폼. 동작은 한다. 「예쁜가?」 는 다른 사람이 맡는다.

💻 디자인 B — 디자이너가 새로 그려준 폼


<!-- 같은 action, 같은 name — 디자인만 풍부 -->
<form action="/signup" method="post" class="card-form">
  <h2>Welcome 👋</h2>
  <label>아이디</label>
  <input name="id"   class="rounded">
  <label>비밀번호</label>
  <input name="pwd"  class="rounded" type="password">
  <label>닉네임</label>
  <input name="nick" class="rounded">
  <button class="gradient-btn">가입하고 시작하기</button>
</form>

👉 Backend 코드 한 줄 안 바뀜. name 만 같으면 동작은 동일하다.

💻 합치기 — 세 트랙이 만나는 순간

브라우저 Controller MySQL ───────── ─────────── ───── <form action="/signup"> @PostMapping("/signup") INSERT INTO name="id" ───→ Member m { id ───→ mymember( name="pwd" ───→ pwd ───→ id, pwd, name="nick" ───→ nick }───→ nick) ... ↓ ★ 같은 이름이라 코드 한 줄도 고치지 않고 합쳐짐

세 사람의 산출물이 처음 만나는 자리. 이름이 같으니 자동 바인딩이 알아서 다리를 놓는다.

🔄 Before / After

따라하기 직후
  • HTML, Controller, DB 모두 내가 짰다
  • 「왜 그렇게 짜는지」 까지는 안 보였다
  • 화면이 바뀌면 다시 다 짜야 할 것 같다
한 번 내려다본 후
  • ① 기획 → ② 요구사항 → ③ 화면 → ④ 구현 단계가 보인다
  • 요구사항의 「id, pwd, nick」 약속이 끝까지 따라간다
  • 화면 디자인은 갈아끼울 수 있다 — Backend 는 그대로

일이 어떻게 나뉘는지 — 역할별 책임

트랙 주된 산출물 주된 도구 신경쓰는 것
Frontend HTML / CSS / JS, 디자인된 폼 VS Code, Figma, 브라우저 사용자 경험, 폼 name
Backend Controller, Service, Mapper, DTO Eclipse, Tomcat, Postman 로직 정확성, DTO 필드명
DB 테이블, 인덱스, 가데이터 MySQL Workbench 데이터 모델, 컬럼명

👉 도구도 다르고 신경쓰는 것도 다르다. 만나는 자리는 「같은 이름」 한 곳뿐.

같은 시간에 셋이 일하는 모습

시각 → 09:00 11:00 14:00 16:00 18:00 ───── ───── ───── ───── ───── Front ▣ wireframe ▣ CSS ▣ 디자인 폼 ─────┐ │ Back ▣ DTO ▣ Service ▣ Mapper ─────┼──→ ◆ 합치기 │ (이름이 DB ▣ ERD ▣ CREATE ▣ 가데이터 ─────┘ 같으니 자동 연결)

세 사람이 동시 진행. 만나는 곳은 「합치기」 단 한 지점.

만났을 때 깨지는 경우 — 이름이 달라서

사고 사례 3 가지
  • ① Front 가 name="userId", Back 이 String idid 가 null 로 들어옴 (자동 바인딩 실패)
  • ② Back 이 String password, DB 가 pwd VARCHAR(100) → MyBatis SQL 에서 NoSuchColumn 오류
  • ③ Front 가 name="nickname", Back/DB 는 nick → INSERT 는 되지만 화면에 닉네임이 안 뜬다

👉 셋 다 「코드는 컴파일되는데 동작이 이상한」 류. 이름 약속이 깨졌을 때 가장 자주 만나는 사고.

처음부터 약속을 잘 정하기

팀 프로젝트 시작 체크리스트
  1. 네이밍 약속 — 폼 name = DTO 필드 = 컬럼명. 한 표에 정리.
  2. ERD 합의 — 테이블, 컬럼명, 타입, 관계.
  3. API 명세 합의 — 어떤 URL 에 어떤 데이터가 오가는지.
  4. Git 저장소 합의 — 브랜치 전략, 커밋 메시지 규칙.
  5. 합치기 시점 합의 — 언제 처음 만나서 합쳐볼지.

👉 이 5 가지를 첫날 30 분 안에 정해놓으면, 사고의 90% 가 사라진다.

후속 과정 미리보기

오늘 한 일은 모두 한 사람이 했지만, 이 모양 그대로 세 사람이 나눠 할 수 있다는 것을 봤습니다.

  • 다음 차시부터는 같은 코드를 REST API 로 다시 작성한다 — 화면과 서버를 더 깔끔하게 분리
  • 그 다음은 Ajax 로 비동기 통신 — Front 와 Back 의 역할 분리가 더 또렷해짐
  • 그리고 후속 과정에서 실제 팀 프로젝트 출발

이게 곧 팀 프로젝트의 출발선입니다.

📊 한 그림 정리

이번 차시의 데이터 흐름

Frontend 폼
약속 (공유 이름)
Backend DTO
약속 (공유 이름)
DB 컬럼
새로 등장한 칸 — 「약속」 이 세 트랙을 잇는 다리

정리

오늘 들고 가는 3 가지

  • 회원가입은 모든 프로젝트의 공통 기능 — 한 번 살펴두면 다음이 쉽다
  • 프로젝트는 기획 → 요구사항 → 유스케이스 → 화면 → 구현 단계로 굴러간다
  • 같은 데이터 약속이면 화면 디자인은 갈아끼울 수 있다 (Backend 는 그대로)

다음: REST API v8 — 같은 걸 다시 (View 없는 컨트롤러).