Programming

일급 컬렉션에 대해서 설명해주세요

컬렉션을 클래스로 감싸고, 그 안에 검증·불변성·비즈니스 로직을 모두 담으면 — 컬렉션이 스스로를 책임지는 객체가 됩니다.

2026년 3월 18일 · 약 10분 읽기

Q. "일급 컬렉션이 무엇인지 설명하고, 어떤 이점이 있는지 말씀해주세요."

예상 꼬리질문

답변 가이드

"일급 컬렉션은 컬렉션 하나만을 멤버 변수로 갖는 클래스입니다. 소트웍스 앤솔러지의 객체지향 생활체조 규칙 8번에서 유래했습니다."

"생성자에 검증 로직을 모아 잘못된 상태의 객체가 만들어지는 것을 원천 차단하고, Collections.unmodifiableList()와 방어적 복사로 불변성을 보장합니다."

"List<Order> 대신 Orders라는 이름을 부여해 타입 시스템으로 의도를 전달하고, 비즈니스 규칙이 있을 때만 적용해야 오버엔지니어링을 피할 수 있습니다."

List<Order> orders를 Service 여기저기서 다루다 보면, 같은 검증 코드가 여러 곳에 흩어지고, 언제 어디서 리스트가 수정됐는지 추적하기 어려워집니다.

일급 컬렉션은 이 문제를 해결하는 간단하지만 강력한 패턴입니다. 컬렉션을 클래스로 감싸고, 그 안에 검증·불변성·비즈니스 로직을 모두 담으면 — 컬렉션이 스스로를 책임지는 객체가 됩니다.

1. 일급 컬렉션이란 무엇인가

꼬리질문: "일급 컬렉션이 무엇인지 설명해주세요"

일급 컬렉션은 컬렉션 하나만을 멤버 변수로 갖는 클래스입니다. 마틴 파울러가 편집한 소트웍스 앤솔러지의 “객체지향 생활체조” 챕터 규칙 8번에서 유래했으며, “원시값 포장(규칙 3)”과 함께 가장 실무에서 자주 언급됩니다.

핵심 제약은 단순합니다. 컬렉션을 포함하는 클래스는 그 컬렉션 외에 다른 멤버 변수를 가질 수 없습니다. 이 제약이 자연스럽게 컬렉션 관련 로직을 한 곳으로 모이게 만듭니다.

아래에서 일반 컬렉션과 일급 컬렉션의 차이를 직접 비교해 보세요.

public class Orders {
private List<Order> orders;
private String customerId; // ← 다른 멤버 변수
private int totalAmount; // ← 다른 멤버 변수
}

2. 검증 로직 캡슐화

꼬리질문: "검증 로직을 생성자에 넣으면 어떤 이점이 있나요?"

일급 컬렉션 없이 컬렉션을 사용하면, 크기 검증·중복 검증·범위 검증 같은 비즈니스 규칙이 Service, Controller, Factory 등 여러 곳에 흩어집니다. 한 곳을 수정하면 다른 곳을 잊게 되고, 버그가 숨어듭니다.

일급 컬렉션의 생성자에 모든 검증을 넣으면, 잘못된 상태의 객체는 애초에 만들어질 수 없습니다. 실패 빠르기(Fail Fast) 원칙이 자연스럽게 적용됩니다.

아래에서 검증이 분산된 코드와 캡슐화된 코드를 비교해 보세요.

6개 (정상)
345678
⬜검증 1

크기 확인

numbers.size() != 6

⬜검증 2

범위 확인

n < 1 || n > 45

⬜검증 3

중복 확인

hasDuplicate(numbers)

3. 불변성 보장

꼬리질문: "불변성을 어떻게 보장하나요?"

컬렉션을 외부에 그대로 반환하면, 받은 쪽에서 add(), remove()를 호출해 의도치 않게 내부 상태를 바꿀 수 있습니다.

일급 컬렉션은 두 가지 기법을 조합해 이를 방어합니다. 방어적 복사(Defensive Copy)는 외부에서 넘어온 리스트를 생성자에서 새로 복사합니다. unmodifiableList는 반환 시 수정 불가 뷰를 제공해 외부의 변경 시도를 차단합니다.

아래에서 방어적 복사와 unmodifiableList의 동작을 확인해 보세요.

메모리 구조

외부 List

[1, 5, 12, 23, 34, 45]

외부에서 add(99) 시도

방어적 복사

new ArrayList<>()

Orders 내부

orders (복사본)

[1, 5, 12, 23, 34, 45]

unmodifiable 뷰

getAll() 반환

4. 비즈니스 로직 응집과 이름 부여

꼬리질문: "Tell, Don't Ask 원칙이 무엇인가요?"

List<Order>는 타입만 보면 어떤 주문들인지, 어떤 상태인지 알 수 없습니다. Orders, CompletedOrders처럼 이름을 붙이면 코드 자체가 의도를 설명합니다.

이를 객체지향의 핵심 원칙인 Tell, Don't Ask라고 합니다. 데이터를 꺼내서 외부에서 처리하는 대신, 컬렉션 객체에게 직접 일을 시키는 방식입니다.

아래에서 Ask 방식과 Tell 방식의 코드 차이를 비교해 보세요.

⚠️ 컬렉션 데이터를 꺼내 외부(Service)에서 처리 — 로직이 분산되고 중복됩니다
// OrderService.java — 로직이 외부에 흩어짐
List<Order> completed = orders.getAll()
.stream()
.filter(Order::isCompleted)
.collect(Collectors.toList());
 
int total = orders.getAll()
.stream()
.mapToInt(Order::getAmount)
.sum();
 
Order best = orders.getAll()
.stream()
.max(Comparator.comparing(Order::getAmount))
.orElseThrow();

코드 품질 지표

응집도 (Cohesion) — 높을수록 좋음40% — 낮음 (나쁨)
결합도 (Coupling) — 낮을수록 좋음80% — 높음 (나쁨)

5. 언제 써야 하고 언제 쓰지 말아야 하는가

꼬리질문: "일급 컬렉션을 언제 써야 하고 언제 쓰지 말아야 하나요?"

일급 컬렉션이 항상 좋은 것은 아닙니다. 비즈니스 규칙이 없는 단순한 컬렉션에 클래스를 추가하는 건 오버엔지니어링입니다.

반면 검증 규칙이 있거나 여러 곳에서 같은 처리 로직이 중복된다면, 일급 컬렉션이 명확한 해법이 됩니다. 적용 기준은 간단합니다: “이 컬렉션에 비즈니스 규칙이 있는가?” — 있으면 일급 컬렉션, 없으면 그냥 List.

아래에서 사용 판단 가이드를 확인해 보세요.

해당 조건에 체크하세요 (0/4)

📋 단순 List 사용

비즈니스 규칙이 없는 컬렉션에 클래스를 추가하면 오버엔지니어링이 됩니다. 그냥 List를 사용하세요.

✅ 적용 시 장점

  • •검증 로직 단일화
  • •불변성 보장
  • •응집도 향상
  • •테스트 용이성
  • •의미론적 명확성

⚠️ 주의사항

  • •클래스 수 증가
  • •Jackson 직렬화 설정 필요
  • •팀 학습 비용
  • •단순 케이스엔 과잉 설계

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 일급 컬렉션 질문은 준비 완료입니다.

  • - 일급 컬렉션: 컬렉션 하나만을 멤버로 갖는 클래스로, 검증·불변성·비즈니스 로직을 캡슐화한다
  • - 검증 캡슐화: 생성자에서 검증해 잘못된 상태를 원천 차단, Fail Fast 원칙 적용
  • - 불변성: 방어적 복사 + unmodifiableList로 외부 변경 차단
  • - 이름 부여: List<Order> 대신 Orders로 의도를 타입으로 표현, Tell Don't Ask
  • - 적용 기준: 비즈니스 규칙이 있을 때만 사용 — 단순 컬렉션에는 오버엔지니어링

참고 자료

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.

0 / 1000