그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록JPA
JPA

JPA에서 ID 생성 전략에 대해 설명해주세요.

실무4/5
설계4/5
인간4/5
기초3/5

면접관의 질문 의도

IDENTITY를 기본값처럼 쓰고 마는지, 아니면 배치 인서트·DB 종속성·시퀀스 캐시까지 보고 전략을 고를 줄 아는지를 가른다.

큐레이션 답변

학습 자료

JPA는 식별자를 직접 할당하거나 자동 생성에 맡길 수 있고, 자동 생성은 IDENTITY·SEQUENCE·TABLE·AUTO 중에서 고른다. IDENTITY는 INSERT를 DB에 위임하는 대신 영속화 시점에 쿼리가 즉시 나가서 쓰기 지연·배치 인서트와 잘 맞지 않는다. SEQUENCE는 시퀀스에서 ID를 미리 받아오기 때문에 배치에 강하지만 시퀀스를 지원하는 DB가 있어야 하고, TABLE은 전용 테이블로 시퀀스를 흉내내 호환성은 넓지만 락과 추가 쿼리 비용이 붙는다. AUTO는 방언에 따라 위 셋 중 하나로 풀리므로 'DB 바꿔도 안전한 옵션'이 아니다. 결국 DB 종류와 쓰기 패턴을 같이 보고 골라야 한다.

좋은 답변 구조

  1. 01자동 생성 전략 네 가지의 동작 방식을 한 줄씩 정리한다
  2. 02IDENTITY가 영속화 시점에 INSERT를 강제하는 점과 배치 인서트 제약을 짚는다
  3. 03SEQUENCE와 TABLE의 호환성·오버헤드 트레이드오프를 비교한다
  4. 04DB 종류와 쓰기 패턴을 기준으로 어떤 상황에 무엇을 고를지 결론을 낸다

자주 실수하는 포인트

IDENTITY가 배치 인서트와 충돌한다는 점을 모르고 대용량 적재에 그대로 가져간다
SEQUENCE를 쓰면 무조건 빠르다고 단정하고 allocationSize·시퀀스 캐시를 같이 보지 않는다
AUTO를 'DB 바꿔도 안전한 옵션'으로 오해하고 방언에 따라 실제 전략이 바뀐다는 사실을 놓친다
TABLE 전략의 락 비용을 가볍게 보고 호환성만 보고 고른다

실무 맥락

  • MySQL 기반 서비스에 대량 데이터 적재 배치가 같이 들어와 있는 환경
  • PostgreSQL·Oracle을 쓰며 시퀀스 캐시와 allocationSize를 운영 단에서 조정하는 환경
  • 샤딩이나 복제 구조 때문에 단일 시퀀스에 의존하기 어려운 환경

본인 경험에 녹이는 힌트

JPA로 대량 적재 작업을 짜다 INSERT가 한 건씩 나가서 느렸던 경험이 있다면 IDENTITY의 한계와 연결할 수 있다

DB 마이그레이션이나 듀얼 라이트를 겪어봤다면 AUTO·SEQUENCE의 DB 종속성 판단을 자기 사례로 풀어낼 수 있다

시퀀스 캐시·allocationSize를 운영 중에 튜닝해본 적이 있다면 처리량 변화 수치를 들어 SEQUENCE 최적화를 설명할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1IDENTITY 전략에서 배치 인서트가 어려운 이유는 무엇인가요
Q2SEQUENCE의 allocationSize는 어떤 기준으로 잡나요
Q3DB를 교체할 가능성이 있을 때 AUTO 전략을 그대로 두는 게 안전한가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문