이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
JPA로 도메인 모델링을 처음 할 때 DB 스키마를 그대로 엔티티로 옮기는 함정에 빠졌습니다. 외래키 관계를 전부 @OneToMany로 연결했더니 N+1 쿼리 문제가 여기저기서 터졌습니다. Lazy Loading을 기본으로 설정하고 필요한 경우만 @EntityGraph나 fetch join을 쓰는 방식으로 바꿨습니다. 도메인 경계도 처음엔 하나의 엔티티에 너무 많은 책임을 넣었는데, 애그리거트 개념을 공부한 뒤 불변식을 지키는 단위로 엔티티 경계를 나누는 방식이 더 명확하다는 걸 알게 됐습니다. ORM은 DB 접근을 편하게 만들어주지만 쿼리를 의식하지 않으면 오히려 성능 문제를 숨기는 경향이 있습니다.
ORM 모델링에서 처음에는 모든 도메인 개념을 단순 필드로 표현했는데 문제가 생겼습니다. 금액이나 주소 같은 개념을 Long이나 String 필드로 뒀더니, 유효성 검사 로직이 여러 곳에 흩어지는 문제가 생겼습니다. 값 객체(Value Object) 개념을 적용해서, 금액은 Money 클래스로 감쌌습니다.
생성 시점에 유효성을 검사하도록 구현하니, 잘못된 값이 DB에 들어가는 것을 DB 제약 이전에 막을 수 있었습니다. 금액 계산 로직이 Money 클래스 안에 모이니 관련 코드를 찾는 것이 쉬워졌고, @Embeddable로 값 객체를 같은 테이블에 매핑해 DB 구조를 바꾸지 않아도 됐습니다.
ORM을 쓰면서 조회 로직이 복잡해질수록 ORM이 방해가 되는 경우가 생겼습니다. 여러 테이블을 조인해서 집계 결과를 가져오는 쿼리에서 ORM이 생성한 SQL이 비효율적으로 작동하는 것을 확인했습니다. 쿼리를 최적화하려면 ORM 설정을 복잡하게 만들어야 했습니다. 명령(삽입·수정·삭제)은 ORM으로, 조회는 네이티브 쿼리로 분리하는 방식을 팀에 제안했습니다.
QueryDSL을 조회 전용으로 도입해 타입 안전하면서도 복잡한 조인을 명확하게 표현하는 것이 가능해졌습니다. ORM은 도메인 모델링에는 강하지만 복잡한 읽기 쿼리에는 맞지 않는 경우가 있다는 것을 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.