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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록JPA
JPA

@OneToOne에서 Lazy Loading 설정 시 주의점은 무엇인가요?

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

면접관의 질문 의도

LAZY 옵션 문법을 아는지가 아니라, OneToOne의 소유권 구조가 실제 SQL 실행에 어떻게 묻어 나오는지 같이 보는지 가르려는 질문이다.

큐레이션 답변

학습 자료

양방향 OneToOne에서 비주인(mappedBy) 측은 외래키를 자기 테이블에 들고 있지 않기 때문에, 연관 엔티티가 존재하는지·null인지를 자기 행만 보고는 알 수 없다. JPA는 프록시를 만들지 null을 넣을지 결정해야 하니, LAZY를 걸어도 해당 필드에 접근하기 전에 존재 확인용 select를 미리 한 번 날린다. 그 결과 LAZY를 켰는데도 매 조회마다 추가 쿼리가 붙어 N+1처럼 보이는 현상이 생긴다. 해결은 단방향 OneToOne으로 모델링하거나, 주인 측에서 조회를 시작하거나, 정말 필요하면 byte-code enhancement 같은 보조 수단을 쓰는 쪽으로 잡는다.

좋은 답변 구조

  1. 01OneToOne의 주인·비주인 개념과 FK가 어느 쪽에 있는지부터 정리한다
  2. 02비주인 측에서 LAZY가 깨지는 이유를 FK 부재로 설명한다
  3. 03프록시 결정을 위한 존재 확인 쿼리가 어느 시점에 나가는지 짚는다
  4. 04단방향 모델링·조회 방향 변경·byte-code enhancement 같은 대안을 비교해 제시한다

자주 실수하는 포인트

LAZY를 걸기만 하면 항상 프록시로 지연 로딩된다고 단정한다
주인 측과 비주인 측을 똑같이 다루며 FK 소유권 차이를 빼먹는다
쿼리 로그를 켜지 않고 '느린 것 같다'는 감만으로 설계를 바꾼다

실무 맥락

  • 계정-프로필처럼 1:1 연관을 양방향으로 잡아 둔 도메인 모델
  • JPA 조회 성능 튜닝을 하며 쿼리 로그·실행 계획을 같이 봐야 하는 환경
  • N+1과 비슷해 보이지만 실제로는 OneToOne 확인 쿼리인 패턴이 의심되는 상황

본인 경험에 녹이는 힌트

쿼리 로그에서 의도치 않은 추가 select를 발견해 OneToOne 모델링을 손본 경험이 있다면 이 질문과 연결할 수 있다

양방향을 단방향으로 바꾸거나 조회 방향을 뒤집어 성능을 개선한 적이 있다면 대안 비교로 엮을 수 있다

연관관계 설계 가이드를 팀 표준으로 정리해 본 경험이 있다면 같은 함정을 반복하지 않게 만든 사례로 말할 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1OneToOne을 OneToMany+Unique로 모델링하면 어떤 장단점이 있나요
Q2Hibernate bytecode enhancement는 이 문제에 어떤 영향을 주나요
Q3fetch join과 엔티티 그래프는 언제 각각 유리한가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문