Skip to content

00-overview.md

Latest commit

 

History

History
166 lines (119 loc) · 10.2 KB

00-overview.md

File metadata and controls

166 lines (119 loc) · 10.2 KB
Raw

00 · 미션 개요 & 학습 방향

JPA 전환 + 예약 대기 미션의 큰 그림. 이 문서는 큰 그림을 잡는 단계에서 작성하고, 단계가 진행되며 갱신한다. 🖊️ 가이드 블록(이 인용문들)은 초안용. 완성 시 지워도 됨.

메타

항목 값
저장소 softmoca/spring-roomescape-waiting
시작 브랜치 step2 (JdbcTemplate 방탈출 코드)
작업 브랜치 step3-jpa
단일 PR 마감 06-18(목) 18:00
JPA 설계 토론 06-19(금) 10:40~11:30, 강의장
자기점검·사후설문 마감 06-22(월) 18:00
커밋 표기 [1단계] 매핑 변환 식 단계 prefix (PR 본문 경계용)

이 미션의 본질

새 라이브러리 사용법 암기가 아니라 내 어노테이션 한 줄이 만드는 실제 SQL을 추적하는 미션. JPA가 자동화한 만큼 감춰진 SQL을, 내 JDBC 코드를 객체 그래프로 옮기며 다시 눈에 보이게 만든다. " 내가 쓴 SQL = 나가는 SQL"이던 JDBC의 투명성을 자동화와 맞바꾼 비용을 손으로 만진다.

자동으로 무엇이 일어나는지 모르면 의도와 다른 SQL이 나가도 그 사실 자체를 모른다. 무엇이 어디로 옮겨가고 무엇이 새로 생기는지 내 코드 위에서 본다.

학습 목표 (LMS)

  • JdbcTemplate ↔ JPA 표현력 차이를 내 코드 위에서 비교
  • 영속성 컨텍스트(1차 캐시·dirty checking·쓰기 지연·flush·fetch) 직접 관찰 + 발행 SQL 추적
  • 연관관계 결정(단/양방향·페치·cascade·orphanRemoval)의 근거·한계 설명
  • N+1 발견 + fetch join·@EntityGraph·JPQL 비교
  • 트랜잭션 경계·동시성 의식하며 도메인 로직(자동 승인) 위치 결정

진행 방식 & 1주 흐름

1주 미션, 별도 OT 없음. 사전학습 → 0~4단계 본인 페이스 → PR → JPA 설계 토론 → 자기점검 순.

일 활동
월 LMS·사전학습 통독 → 방탈출 코드 동작 확인 → 0단계 시작
화~목 0~4단계 본인 페이스 (커밋·푸시)
목 18:00 PR 제출 (마감)
금 JPA 설계 토론 (10:40~11:30, 강의장)
토~일 자기점검 + LMS+ 산출물 작성
다음 주 월 18:00 자기점검 + LMS+ 산출물 마감
  • 단계 권장 종료선 없음 — 가는 만큼 본다. 4단계까지 못 가도 PR 본문에 "어디까지 만들고 무엇이 남았는지" 적으면 됨.
  • 깊이·분량·양식·페이스는 자율. 운영 기본 틀은 둘뿐: ① 첫 PR 1회(목 18:00) ② 자기점검+사후설문(다음 주 월 18:00).

PR은 1회만

5단계로 나뉘지만 PR은 종료 시 1회. 단계별로 커밋·푸시([1단계]… prefix)하고 마지막에 통합 PR. PR 본문 = 0~4단계 도달 지점의 결정·SQL·한계 통합 정리. 막힘은 짧은 사이클 채널(기록·동료)에 흘려보낸다.

산출물

단계 시점 항목
사전 설문 시작 전 도달 상태·JPA 경험·목표·마친 후 모습 (↓ 내 답변)
단계별 응답 단계마다 0~4단계 자기진단·확인 과제 폼 총 16개 (도달한 단계까지)
첫 PR 1회 목 18:00 통합 PR (발행 SQL·망설인 결정·흔들린 장면이 토론 재료)
자기점검 월 18:00 4영역(매핑/설계 판단/피드백 순환/종합) — 회고용
사후 설문 자기점검 직후 사전설문과 비교하며 작성
AI 인터뷰 종료 후 별도 안내

API 명세는 고정. 명세를 바꾸면 JDBC↔JPA SQL 비교가 흐려진다.

코치가 보는 3차원 (이 docs의 설계 축)

차원 무엇을 보나 이 docs의 어디서 회수되나
A — 매핑 정확성 어노테이션 → 발행 SQL을 추적했는가 각 단계 SQL 관찰 로그 (예측 vs 실제)
B — 설계 판단 대안 비교·근거·한계를 말할 수 있는가 각 단계 결정 기록 + 06 설계 토론
C — 피드백 순환 SQL 로그·예외·테스트·리뷰·토론을 살려 썼는가 각 단계 피드백 채널 신호

🖊️ 각 단계 문서의 결정·인사이트 끝에 (A)/(B)/(C) 태그를 달아두면, 06(토론 결정 3개)·07(자기점검 4영역)·단일 PR 본문이 자동으로 조립된다. (인증인가 미션에서 06이 step 문서를 당겨왔던 그 흐름)

내 출발점

사전설문 (시작 전 기록 — 사후설문과 비교용)

Q. JPA 경험은? 토이 프로젝트에서 2년 이상.

Q. 미션 목표(얻고 싶은 것)? 우테코 오기 전에는 JPA의 추상화를 전혀 의식하지 않고 "편한 스택"으로만 썼다. N+1도 "해결법을 외운" 수준이었지, 내 코드 어느 지점에서 왜 터지는지는 보지 못했다. 그렇게 쓰는 건 — 내 어노테이션 한 줄이 어떤 SQL을 던지는지조차 모른 채 '잘 돌아가니 괜찮다'고 믿는 위험한 상태다. 이번 미션에서 얻고 싶은 건 그 자동화의 비용을 직접 만져보고, 내가 작성한 매핑·연관관계 결정이 실제 어떤 SQL·동작을 만드는지 설명할 수 있는 힘, 그리고 그 SQL을 근거로 연관관계·페치 전략 결정의 한계까지 말할 수 있게 되는 것.

Q. 마친 후 바라는 모습? 어노테이션·연관관계 매핑을 볼 때 "JPA가 알아서 해준다"로 넘기지 않고 발행할 SQL의 모양이 먼저 떠오르는 상태. N+1을 "해결법을 아는 문제"가 아니라 "내 코드 어느 줄에서 터지는지 보이는 문제"로 보고, LAZY·추가 쿼리가 생기는 지점을 직접 추적. 단/양방향·EAGER vs LAZY·fetch join vs @EntityGraph·트랜잭션 경계를 관행이 아니라 **각 선택이 만들 SQL과 한계 근거로 ** 설명.

코드 상태 (step2)

  • 헥사고날 (adapter/persistence ↔ domain/repository 포트 ↔ application ↔ adapter/web)
  • member 테이블 없음 — 예약자는 name VARCHAR 컬럼 (별도 객체 아님)
  • reservation / waiting 분리 모델, UNIQUE(date, time_id, theme_id, name)
  • 조회 핵심 경로는 3중 조인 SQL 직접 박음 (reservation INNER JOIN reservation_time INNER JOIN theme)
  • waiting.order_index = FIFO 순번을 저장해 둔 materialized 파생값

0단계 — 변경/유지 경계

바꿀 것: build.gradle(jdbc→data-jpa) · adapter/persistence의 Jdbc 구현 4개(RowMapper·KeyHolder·수기 SQL 제거) · domain 객체 매핑(@Entity/@Id/@GeneratedValue/@ManyToOne, protected 기본 생성자 추가) · UPDATE 메서드(dirty checking 검토) · application.properties/DDL 설정.

유지할 것: adapter/web 컨트롤러·DTO(API 명세 고정) · application 서비스·@Transactional 경계 · exception 계층·도메인 규칙/정책 · 분리 모델 + UNIQUE 제약 · data.sql.

경계의 핵심 결정 (확정 대기): 도메인 객체에 직접 @Entity vs 순수 도메인 + 별도 JPA 엔티티 분리. → 이번 미션은 영속성 컨텍스트 관찰(1-3)을 살리기 위해 직접 매핑 쪽으로 잠정. 엔티티를 분리해 경계에서 변환하면 entity가 즉시 detach되어 dirty checking·LAZY가 가려지기 때문. (헥사고날 순수성 일부 양보 = 의도된 범위 한정, PR에 명시)

🖊️ 이 결정은 1단계 진입 시 최종 확정. 확정 후 이 문단 갱신.

대화 로드맵 (대화 단위 ↔ 산출물)

대화 산출물
학습 방향·개념 00-overview, 01-concepts
1단계 02-step1-jpa-mapping
2단계 03-step2-my-reservations
3단계 04-step3-waiting
4단계 05-step4-waiting-admin
토론 준비 06-design-discussion
자기점검·PR 07-self-check

단계 진입 시: 해당 step 문서를 먼저 열어 "전환 전(JDBC)" 확정 → 구현 → "전환 후·SQL 관찰" 채움 순으로 진행. 대화가 바뀌어도 docs를 읽고 시작하면 흐름이 안 끊긴다.

docs 구조

docs/
├── 00-overview.md              # (이 문서) 개요·학습 방향·차원 매핑·로드맵·0단계 경계
├── 01-concepts.md              # 사전학습: 영상·4질문 가설·키워드 정의·코드 다시 읽기·참조 매뉴얼
├── 02-step1-jpa-mapping.md     # 1단계: 1-1 매핑 / 1-2 연관관계 / 1-3 영속성 컨텍스트 관찰
├── 03-step2-my-reservations.md # 2단계: 내 예약 목록 (메서드 쿼리 vs JPQL)
├── 04-step3-waiting.md         # 3단계: 3-1 N+1·fetch join / 3-2 JPQL rank
├── 05-step4-waiting-admin.md   # 4단계: 어드민·자동 승인·트랜잭션 경계·flush 순서
├── 06-design-discussion.md     # JPA 설계 토론 준비 (결정 3개 + 한계)
└── 07-self-check.md            # 자기점검 4영역 + 단일 PR 본문 종합

(별도 decisions/ ADR 폴더 없음 — 결정 기록은 각 step 문서에 인라인. 인증인가 때 분리 폴더가 비어버린 교훈.)

진행 원칙

  • 도달한 만큼을 본다 — 미완은 부끄러워하지 말고 정확히 적는다(미완 정확 기록 = 핵심 신호).
  • 단일 PR — 단계별 커밋·푸시, 마지막에 통합 PR 1회.
  • API 명세 고정 — 명세를 바꾸면 JDBC↔JPA SQL 비교가 흐려진다.
  • 문서량 자랑 경계 — SQL 관찰 로그는 두껍게, 산문은 짧게.