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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록Java
Java

equals와 hashCode는 왜 함께 재정의해야 할까요?

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

면접관의 질문 의도

equals/hashCode를 IDE 자동 생성 정도로 알고 있는지, 해시 컬렉션의 탐색 흐름과 묶어서 왜 두 메서드가 같이 가야 하는지 설명할 수 있는지를 가르는 질문이다.

큐레이션 답변

학습 자료

논리적으로 같은 객체는 같은 해시값을 가져야 한다 — 이게 자바가 정한 동등성 계약이다. HashMap·HashSet은 먼저 hashCode로 버킷을 찾고 같은 버킷 안에서 equals로 최종 비교한다. equals만 재정의하고 hashCode를 빼면 같은 의미의 두 객체가 서로 다른 버킷에 흩어져 컬렉션이 중복을 허용하거나 조회를 실패한다. 그래서 동등성 기준 필드를 잡았으면 두 메서드를 묶어서 함께 재정의한다.

좋은 답변 구조

  1. 01동등성 계약과 두 메서드가 각각 맡는 역할을 먼저 정의한다
  2. 02HashMap/HashSet이 객체를 찾는 단계 — 해시값으로 버킷 → 버킷 내 equals 비교 — 를 순서대로 설명한다
  3. 03hashCode만 빠졌을 때 어떤 단계에서 어긋나 중복·조회 실패로 드러나는지 구체 증상으로 짚는다
  4. 04가변 필드, JPA 엔티티 같은 설계 시 함정과 주의점을 덧붙인다

자주 실수하는 포인트

equals만 재정의하면 충분하다고 답하고 hashCode 누락 시 어떤 단계가 깨지는지 설명하지 못한다
두 메서드 코드를 외워서 보여주긴 하지만 해시 컬렉션 탐색 단계와 연결해 왜 같이 가야 하는지 답하지 못한다
가변 필드를 동등성 기준에 넣고서 객체 상태가 바뀐 뒤 컬렉션에서 찾지 못하는 패턴을 인지하지 못한다

실무 맥락

  • HashSet/HashMap을 도메인 객체 키로 직접 쓰는 백엔드 코드
  • JPA 엔티티의 동등성을 정의해 영속성 컨텍스트·연관관계 컬렉션과 함께 다루는 환경
  • 값 객체(VO)나 DTO를 캐싱 키, Set 멤버십 검사 용도로 쓰는 모듈

본인 경험에 녹이는 힌트

도메인 객체에 equals/hashCode를 직접 짜본 적이 있다면 어떤 필드를 동등성 기준으로 골랐고 왜 그 필드였는지로 풀 수 있다

Set에 중복이 들어가거나 Map 조회가 의도와 다르게 동작해 디버깅한 경험이 있다면 두 메서드 불일치를 발견하기까지의 추적 과정을 말할 수 있다

JPA 엔티티에서 ID 기반 동등성과 비즈니스 키 기반 동등성 중 무엇으로 갈지 팀과 합의한 경험이 있다면 그 트레이드오프를 설명할 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1equals/hashCode 계약을 테스트로 어떻게 검증하나요
Q2불변 필드만 동등성 기준으로 삼아야 하는 이유는 무엇인가요
Q3JPA 엔티티에서 equals/hashCode 설계 시 주의점은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문