Database 담당 — 쿼리 반복 실험으로 완성

이 페이지는 Database 담당 학생을 위한 전용 가이드입니다. 회원가입 기능을 위한 SQL 쿼리를 어떻게 검증하고, MyBatis Mapper로 포장해서 Backend에 넘기는지 자세히 다룹니다. ← 협업 메인으로 돌아가기

한 줄 요약

Tomcat을 띄우지 마세요. DBeaver만으로 쿼리를 완성하고, 마지막에 Mapper XML로 포장해서 넘깁니다.
"쿼리는 글로 설명하는 게 아니라 실제로 돌려보고 성공한 것만 전달" 이 원칙입니다.

Database 작업 흐름

Database

데이터 담당 · SQL 직접 실행 / MyBatis Mapper

작업 순서 — "가짜 데이터로 수십 번 넣어본다"

  1. Step 1 — 현재 테이블 구조 확인: DESC member 로 컬럼·타입 확인.
  2. Step 2 — 가짜 데이터 INSERT 해보기: DBeaver에서 직접 INSERT 문 실행. 1건, 2건, 여러 건 넣어보기.
  3. Step 3 — SELECT로 확인: 제대로 들어갔는지, 한글·이메일 형식은 괜찮은지.
  4. Step 4 — 에러 케이스 시도: 중복 PK, NULL 필수값, 길이 초과 — 에러 메시지 확인.
  5. Step 5 — 깨끗이 지우고 다시: DELETE FROM member WHERE user_id LIKE 'test_%' 로 시험 데이터 정리.
  6. Step 6 — 최종 INSERT 쿼리 확정: 여러 번 다듬은 결과를 한 줄로 정리.
  7. Step 7 — Backend에게 전달: MyBatis XML 형태로 포장해서 넘김.

Step 1 · 테이블 구조 확인

이미 만들어진 member 테이블의 컬럼·타입·제약을 먼저 확인합니다. 회원가입 기능을 위해 어떤 컬럼이 필요한지 빠뜨리지 말고 체크.

DESC member;
-- 또는
SHOW CREATE TABLE member;

Step 2 · 가짜 데이터로 여러 번 INSERT

-- DBeaver에서 직접 실행하며 반복 실험

-- 1건 넣어보기 (모든 컬럼 채우기)
INSERT INTO member (user_id, password, nickname, email, phone, hobbies, favorite_color, job)
VALUES ('test1', '1234', '테스트1', 't1@test.com', '010-1111-1111',
        '독서,운동,영화', '파랑', '학생');

-- 확인
SELECT * FROM member WHERE user_id = 'test1';
-- → 1 row, reg_date 는 자동으로 채워짐, hobbies는 CSV로 저장됨

-- 한꺼번에 여러 건 (취미 다양하게)
INSERT INTO member (user_id, password, nickname, email, phone, hobbies, favorite_color, job) VALUES
  ('test2', '1234', '테스트2', 't2@test.com', '010-2222-2222',
   '음악,게임',       '빨강', '회사원'),
  ('test3', '1234', '테스트3', 't3@test.com', NULL,
   '요리',            '초록', '자영업'),
  ('test4', 'abcd', '김철수', 'kim@test.com', '010-4444-4444',
   '',                '노랑', '기타');  -- 취미 없음 = 빈 문자열

SELECT COUNT(*) FROM member;   -- → 4

-- 취미 검색 테스트 (CSV에서 특정 취미 포함된 회원 찾기)
SELECT user_id, nickname, hobbies
  FROM member
 WHERE hobbies LIKE '%독서%';
-- → test1 · 테스트1 · '독서,운동,영화'
DBeaver에서 member 테이블 조회 결과
DBeaver에서 실행한 SELECT 결과 · hobbies 컬럼에 CSV 형태(독서,운동,음악)로 저장된 모습에 주목

Step 4 · 에러 케이스 일부러 일으켜보기

-- 에러 1 : 중복 user_id (PK 위반)
INSERT INTO member (user_id, password, nickname, email)
VALUES ('test1', 'xxx', '중복', 'dup@test.com');
-- → Error: Duplicate entry 'test1' for key 'PRIMARY' ✓ (예상대로)

-- 에러 2 : 필수값 누락 (nickname NOT NULL)
INSERT INTO member (user_id, password, email)
VALUES ('test5', '1234', 't5@test.com');
-- → Error: Field 'nickname' doesn't have a default value ✓

-- 에러 3 : 컬럼 길이 초과 (VARCHAR(20)에 25자)
INSERT INTO member (user_id, password, nickname, email)
VALUES ('thisIdIsWayTooLongForColumn', '1234', '아', 'a@a.com');
-- → Error: Data too long for column 'user_id' ✓
왜 에러를 일부러 일으키는가? 나중에 Backend가 통합 테스트할 때 이런 에러가 어떻게 나오는지 미리 알아두면 대응이 빨라집니다. "중복 가입 시도 → PK 위반 → MySQL 에러 코드 1062" 같은 지식을 DB 담당이 Backend에게 전달해두면 좋아요.

Step 5 · 테스트 데이터 정리

-- 시험 삼아 넣은 test_ 로 시작하는 데이터 정리
DELETE FROM member WHERE user_id LIKE 'test%';
SELECT COUNT(*) FROM member;  -- → 0

-- 또는 전체 비우기 (주의!)
-- TRUNCATE TABLE member;

Step 6 · 최종 확정된 INSERT 쿼리

-- Backend에 넘길 최종본
INSERT INTO member (user_id, password, nickname, email, phone, hobbies, favorite_color, job)
VALUES (?, ?, ?, ?, ?, ?, ?, ?);

Step 7 · MyBatis Mapper XML로 포장

물음표 자리에 #{필드명} 만 바꿔주면 그대로 MyBatis XML이 됩니다. 여기서 중요한 점: DB 컬럼명은 스네이크 케이스(favorite_color), Java 필드명은 카멜 케이스(favoriteColor) 라는 것. #{favoriteColor} 가 Java의 필드명을 가리키니까요. 이 매핑을 Day 1에 합의해둬야 합니다.

<!-- src/main/resources/mapper/MemberMapper.xml -->
<mapper namespace="com.edu.dao.MemberDao">

  <insert id="insert" parameterType="com.edu.model.Member">
    INSERT INTO member
      (user_id, password, nickname, email, phone, hobbies, favorite_color, job)
    VALUES
      (#{userId}, #{password}, #{nickname}, #{email}, #{phone},
       #{hobbies}, #{favoriteColor}, #{job})
  </insert>

</mapper>
parameterType="com.edu.model.Member" 에서 가리키는 Member 클래스가 바로 DTO입니다. Backend 담당이 만든 그릇 클래스인데, 그 안의 필드 이름들(userId, favoriteColor 등)이 여기 #{userId} 자리에 그대로 매칭됩니다. 그래서 DB 컬럼명과 DTO 필드명 매핑은 Day 1 회의의 핵심 합의 사항이에요. DTO가 무엇인지는 Backend 페이지 에서 자세히 다룹니다.

DB 담당이 Backend에게 공유하는 것

  • 최종 INSERT 쿼리 (위 Mapper XML)
  • 파라미터 이름 매핑 규칙 — "Java의 userId 는 DB의 user_id 로 들어갑니다"
  • 예상 에러 케이스 목록 — 중복 아이디·필수값 누락 시 어떤 에러가 나는지 미리 귀띔

DB 담당이 절대 하면 안 되는 것

1. 테이블 스키마를 회의 후 몰래 바꾸기. 컬럼명이나 길이 변경은 반드시 Backend에게 알려야 합니다.
2. 쿼리 완성 전에 Backend에게 "대충 이렇게 되겠죠" 라고 추측 전달. DBeaver에서 직접 실행해서 성공한 것만 전달.
3. 테스트 데이터를 정리 안 하고 방치. 나중에 통합 테스트할 때 이미 등록된 아이디로 가입 시도하다가 난리.

다른 역할의 가이드 보기