옥스턴님의 면접 결과

연관관계의 주인(mappedBy) 개념을 정확히 짚고, 주인이 아닌 쪽의 변경이 무시된다는 핵심 동작 원리까지 언급하신 점이 좋습니다. 다만 "join table 생성"이 어떤 상황에서 왜 발생하는지 조금 더 구체적으로 설명하셨다면 더욱 완성도 있는 답변이 됐을 것입니다(예: 양쪽 모두 @JoinColumn 없이 설정하면 JPA가 중간 조인 테이블을 자동 생성하는 문제). 한 가지 추가로 짚어드리자면, 양방향 관계에서는 주인 쪽에서만 DB에 반영되더라도 1차 캐시(영속성 컨텍스트)에는 반대편 객체가 갱신되지 않아 같은 트랜잭션 내에서 데이터 불일치가 생길 수 있으므로, 편의 메서드(연관관계 편의 메서드)를 통해 양쪽 객체를 동시에 세팅하는 패턴도 함께 언급해 두시면 실무 깊이를 보여줄 수 있습니다.

1차 캐시와 영속성 컨텍스트의 동작 원리를 연결해 핵심을 정확히 짚으셨습니다. 같은 트랜잭션 내에서 DB를 거치지 않고 1차 캐시에 올라온 객체를 그대로 참조하기 때문에, 연관관계 주인 쪽에만 값을 설정하면 반대쪽 컬렉션이 비어 있는 채로 조회된다는 점이 핵심인데, 그 맥락을 잘 파악하고 계신 것 같습니다. 한 단계 더 나아가자면, 이 문제를 해결하기 위해 양쪽 모두에 값을 설정하는 '연관관계 편의 메서드(convenience method)'를 엔티티 내부에 두는 패턴을 언급하면 실무적인 깊이를 보여줄 수 있습니다. 예를 들어 "이를 방지하기 위해 연관관계 편의 메서드를 정의해 양쪽 객체를 동시에 설정하도록 캡슐화합니다"처럼 답변을 보완해 보시면 더욱 완성도 높은 답변이 될 것입니다.

1차 캐시가 빈 값을 반환한다는 핵심 방향은 정확히 짚으셨습니다. 다만 "왜 캐시에 빈 값이 있는가"에 대한 설명이 빠져 있어 아쉽습니다. 핵심은 연관관계 주인 쪽에만 값을 설정하면 이미 영속성 컨텍스트(persistence context)에 로드된 반대쪽 엔티티 객체의 컬렉션 필드가 메모리상에서 갱신되지 않기 때문입니다. JPA는 flush 시점에 DB에 반영하지만, 그 전에 같은 트랜잭션 내에서 해당 엔티티를 조회하면 DB가 아닌 1차 캐시의 in-memory 객체를 그대로 반환하므로 컬렉션이 비어 있는 상태로 보이는 것입니다. 예를 들어 "Team 엔티티가 이미 캐시에 로드된 상태에서 member.setTeam(team)만 호출하고 team.getMembers().add(member)를 호출하지 않으면, 같은 트랜잭션 내에서 team.getMembers()를 조회할 때 빈 리스트가 반환된다"고 설명하면 훨씬 명확합니다.