Database 담당 — 쿼리 반복 실험으로 완성
이 페이지는 Database 담당 학생을 위한 전용 가이드입니다. 회원가입 기능을 위한 SQL 쿼리를 어떻게 검증하고, MyBatis Mapper로 포장해서 Backend에 넘기는지 자세히 다룹니다. ← 협업 메인으로 돌아가기
한 줄 요약
Tomcat을 띄우지 마세요. DBeaver만으로 쿼리를 완성하고, 마지막에 Mapper XML로 포장해서 넘깁니다.
"쿼리는 글로 설명하는 게 아니라 실제로 돌려보고 성공한 것만 전달" 이 원칙입니다.
"쿼리는 글로 설명하는 게 아니라 실제로 돌려보고 성공한 것만 전달" 이 원칙입니다.
Database 작업 흐름
Database
데이터 담당 · SQL 직접 실행 / MyBatis Mapper
작업 순서 — "가짜 데이터로 수십 번 넣어본다"
- Step 1 — 현재 테이블 구조 확인:
DESC member로 컬럼·타입 확인. - Step 2 — 가짜 데이터 INSERT 해보기: DBeaver에서 직접 INSERT 문 실행. 1건, 2건, 여러 건 넣어보기.
- Step 3 — SELECT로 확인: 제대로 들어갔는지, 한글·이메일 형식은 괜찮은지.
- Step 4 — 에러 케이스 시도: 중복 PK, NULL 필수값, 길이 초과 — 에러 메시지 확인.
- Step 5 — 깨끗이 지우고 다시:
DELETE FROM member WHERE user_id LIKE 'test_%'로 시험 데이터 정리. - Step 6 — 최종 INSERT 쿼리 확정: 여러 번 다듬은 결과를 한 줄로 정리.
- 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 · '독서,운동,영화'
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. 테스트 데이터를 정리 안 하고 방치. 나중에 통합 테스트할 때 이미 등록된 아이디로 가입 시도하다가 난리.
2. 쿼리 완성 전에 Backend에게 "대충 이렇게 되겠죠" 라고 추측 전달. DBeaver에서 직접 실행해서 성공한 것만 전달.
3. 테스트 데이터를 정리 안 하고 방치. 나중에 통합 테스트할 때 이미 등록된 아이디로 가입 시도하다가 난리.