원시값과 참조값으로 보는 상태 공유 판별

문서 목적

원시값·참조값을 아는 것 자체가 목표가 아닙니다.
목표는 어떤 값이 공유되는지, 어디서부터 상태가 바뀌어야 하는지, 그리고 어떤 반영 결과가 화면에 남아야 하는지를 판단하는 것입니다. 백엔드 개발자는 개념을 이미 알고 있을 수 있지만, JavaScript에서는 같은 개념이 운영 동작에서 더 쉽게 드러납니다.

값의 성질: 복제냐 공유냐

원시값은 값을 복제해 전달하는 성격이 강합니다.
참조값은 동일한 저장소를 가리키는 공유 성격이 강합니다.
둘 모두 맞는 동작이지만, 결과 예측은 성격이 다릅니다.

공유 참조가 성능상 유리한 시점이 있지만, 소유권이 느슨해지면 상태 변경의 책임 경계가 흐려져 의도치 않은 반영이 생깁니다.

일급 함수도 공유 경계의 대상입니다

JavaScript에서 함수는 값처럼 다룰 수 있습니다.
함수는 변수에 담기고, 인자로 전달되며, 결과로 반환될 수 있습니다.
따라서 상태 공유 이슈는 데이터 객체에서만 생기는 것이 아닙니다.
함수도 값처럼 전달·보관되므로, 동일한 공유/갱신 경계 판단이 필요합니다.

상태 설계 규칙

상태 공유 지점을 줄이고, 변경 범위를 최소 단위로 한정해야 합니다.
이때 핵심은 복사 전략입니다. JavaScript에서 객체, 배열 같은 참조형 값은 최상위만 새로 만드는 얕은 복사가 자주 쓰입니다.
따라서 바깥은 새 값처럼 보여도 내부는 같은 참조를 공유할 수 있습니다. 이 경우 연쇄 반영이 발생하면 다른 경로에서 상태가 일관되지 않을 수 있습니다. 깊은 복사는 내부까지 분리해 격리는 강화되지만 비용이 커집니다.
그래서 어떤 구간에서 어느 깊이까지 복제할지 미리 합의해야 합니다.
갱신 책임이 모호하면 한 번의 변경이 여러 화면 경로에서 재해석되어 일관성이 약해집니다.

실무 점검 포인트

• 누가 변경 가능한가?
• 누가 언제 읽는가?
• 한 번 갱신 시 영향 범위는 어디까지인가?

한 줄 판단 기준은 명확합니다.
“값 자체의 동일성”과 “참조 경로의 동일성”을 구분하지 않으면 같은 데이터가 다른 경로에서 서로 다른 상태로 보일 수 있습니다.