오늘의 읽기: 동일성은 왜 프로그래밍에서 가장 어려운 문제인가

Preview: 원글

https://evan-moon.github.io/2026/08/02/why-identity-is-hard-in-programming/

동일성은 왜 프로그래밍에서 가장 어려운 문제인가

 

추천 이유 

이번 글은 공부하기 꽤 좋은 주제라서 추천드립니다. 

Java를 공부하면 어느 정도 레벨에서 equals와 == 그리고 hashmap 동작이 다르다는 점을 알게 되는데요

단순히 equals를 재정의 해야한다를 넘어서 왜 해야하는지를 생각할 수 있습니다.

그 이를 넘어 프로그래밍 언어학과 의미론적으로 "동일"하다는 의미를 어떻게 다루는지 생각해볼 수 있습니다. 

나중에 강의를 만들 때 꼭 언급하면 좋을 것 같다는 생각을 했습니다.

“같다”는 말의 차이

500원 동전 두개와 천원 지폐 하나는 같은 것일까요? 

내용이 같으면 같아도 되는지 아니면 다른 물건이니 다르게 생각해야하는지 이 두개를 나눠서 생각해야합니다. 

이를 위해 Value 와 Entity 두 개념을 따로 생각해야합니다. 

이 글은 이 각 언어별로 이 고민을 어떻게 해결하는지 잘 정리해놨습니다. 

 

자바스크립트 같은 경우는 primitive와 objetct를 나눕니다. 기본적으로 객체를 만들면 엔티티를 취급합니다. 

 

자바는 원래 equals와 hashCode를 직접 오버라이드하는 방식이었다. 사용자에게 동일성에 대한 계약 정의를 짬때린 것인데,
문제는 그 계약을 지키기가 생각보다 어렵고 실수해도 아무도 안 알려준다는 데 있다. (그냥 공감되서 발췌했습니다.)

다행히 이 부분은 record가 등장하면서 나아졌습니다. 이번에 Value Objets가 추가되며 더 나아졌습니다. 

 

동일하다는 걸 정리하면 3가지로 생각할 수 있습니다. 

무엇을 보나	부르는 이름	코드에서는
애초에 한 사람인가	참조 동일성	===로 객체를 비교할 때
생김새가 같나	구조적 동등성	JSON.stringify로 비교할 때
주민번호가 같나	도메인 동일성	id가 같은지 볼 때

 

값과 엔티티를 가르는건 시간이란 부분도 재밌었습니다. 

값은 변하지 않는 것이다. 42는 변하지 않는다. 정체성은 시간에 따라 서로 다른 값들과 결부되는 안정적인 논리적 실체다. 상태는 그 정체성이 특정 시점에 갖는 값이다.

 

또 같다는 건 알고리즘의 문제가 아닌 기준이란 이야기도 이해되었습니다. 

es-toolkit의 isEqualWith 함수가 수백 줄인 것도 그래서다. 즉, “같다”라는 것을 정의하려면 알고리즘이 복잡한 게 아니라 기준을 잡아주는 결정이 많이 필요하다.

 

공리를 어기면 자료구조가 티 안 나게 망가진다 이 부분에서 

메모이제이션도 같은 위험을 안고 있다. 캐시 키의 동등성이 추이성을 어기면 같은 입력인데도 캐시 히트가 났다 안 났다 한다. 성능 문제처럼 보이지만 사실은 정확성 문제고, 캐시된 값이 잘못 재사용되는 순간 결과 자체가 틀어진다.
같은 두 값은 반드시 같은 해시를 가져야 한다.
자바에서 equals를 오버라이드하면 hashCode도 반드시 같이 오버라이드하라고 하는 이유가 이것이다.

 

마무리 

동일성에 대한 정의를 제대로 하지 않으면 언제는 같지만 언제는 다른 경우가 펼쳐집니다

실제 운영하면서 문제를 찾고 디버깅하기 가장 어려운 부분입니다. 실제 개발할 때는 찾아내지 않을 수도 있거든요

이번 글은 동일성이 왜 각기 다른지부터 언어별로 어떤 처리를 하는지, 그리고 어떻게 다뤄야하는지를 잘 풀어쓴 글이라 추천합니다