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

Service

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

My

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

Policy

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

© 2026 그알것 · What Still Matters

질문 목록Java
Java

방어적 복사에 대해 설명해 주세요.

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

면접관의 질문 의도

방어적 복사를 "복사하면 끝"으로 외워 왔는지, 아니면 얕은 복사의 한계·불변 타입과의 관계·성능 비용까지 같이 풀 수 있는지를 가른다.

큐레이션 답변

학습 자료

방어적 복사는 생성자 인자나 getter 반환값으로 가변 객체(Date·List·Map·내부 컬렉션 등)를 그대로 노출하지 않고 복사본을 만들어 참조 공유를 끊는 기법이다. 컬렉션은 복사와 함께 Collections.unmodifiableList나 List.copyOf 같은 변경 불가 뷰를 제공해 외부 수정을 막을 수 있다. 다만 얕은 복사만으로는 내부 원소가 가변일 때 같은 문제가 다시 생긴다 — 원소까지 불변이거나 deep copy를 한 경우에만 "진짜 캡슐화"가 된다. 가능하면 처음부터 불변 타입(Instant, String, Record)으로 모델링해 방어적 복사가 필요 없는 구조를 만드는 게 더 깔끔하다.

좋은 답변 구조

  1. 01방어적 복사의 목적(가변 객체를 통해 들어오는 참조 공유를 끊고 캡슐화를 지키는 것)을 한 줄로 정의한다
  2. 02생성자(들어올 때)와 getter(나갈 때) 양쪽에서 복사가 필요한 이유를 짚는다
  3. 03컬렉션은 복사 + unmodifiable 뷰 / copyOf 같은 보완을 함께 든다
  4. 04얕은 복사의 한계와 "애초에 불변 타입으로 모델링"이라는 더 나은 대안으로 마무리한다

자주 실수하는 포인트

생성자에서만 복사하고 getter는 내부 컬렉션을 그대로 노출한다
`Collections.unmodifiableList`를 "불변 컬렉션"과 같은 의미로 묶는다
얕은 복사만 하고 원소가 가변일 때 같은 문제가 다시 생기는 점을 놓친다
Record·`List.copyOf` 같은 불변 모델링 옵션을 고려하지 않고 매번 수동 복사 코드만 추가한다

실무 맥락

  • 외부에서 받은 List를 내부 컬렉션에 저장하는 도메인 엔티티 설계
  • 라이브러리·외부 모듈과 객체를 주고받는 경계(공용 API, 이벤트 페이로드)
  • 멀티스레드 환경에서 같은 객체를 여러 스레드가 공유해 상태가 의도치 않게 바뀔 위험이 있는 코드

본인 경험에 녹이는 힌트

도메인 객체의 내부 필드가 외부에서 바뀌어 사고가 났던 경험이 있다면 방어적 복사로 끊었던 사례로 풀어낼 수 있다

`unmodifiableList`로 충분하다고 생각했다가 원소 수정으로 다시 사고가 난 경험이 있다면 얕은 복사의 한계 이야기로 이어갈 수 있다

DTO·도메인 객체를 Record·불변 컬렉션 기반으로 옮기며 방어적 복사 자체가 필요 없어진 경험이 있다면 "애초에 불변 모델링" 관점으로 일반화할 수 있다

커뮤니티 인기 답변

전체 0개

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

관련 꼬리 질문

Q1얕은 복사와 깊은 복사는 어떤 기준으로 선택하나요
Q2`Collections.unmodifiableList`만으로 충분하지 않은 경우는 언제인가요
Q3복사 비용이 큰 객체에는 어떤 대안 설계를 쓰나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문