컬렉션

컬렉션은 여러 개를 한데 묶어 놓은 것을 가리키는 말입니다. 무엇이 묶이는지는 쓰는 자리마다 다릅니다. 그래서 이 말만으로는 무엇을 묶은 것인지가 정해지지 않습니다.

상세

세 자리에 공통으로 걸리는 것이 하나 있습니다. 여럿을 한 이름 아래 모아 둔다는 것입니다. 갈리는 자리는 둘입니다. 하나는 무엇이 모이는가입니다. 다른 하나는 그 모임이 어디에 사는가입니다.

프로그래밍 언어에서 모이는 것은 프로그램이 들고 있는 객체입니다. Java SE 21 의 Collection 인터페이스 문서는 컬렉션이 원소라 불리는 객체의 무리를 나타낸다고 적습니다. 어떤 컬렉션은 중복 원소를 허용합니다. 어떤 컬렉션은 허용하지 않습니다. 어떤 것은 순서가 있습니다. 어떤 것은 순서가 없습니다.

문서 데이터베이스에서 모이는 것은 저장된 문서입니다. MongoDB 공식 문서는 MongoDB 가 문서를 컬렉션에 저장한다고 적습니다. 그리고 컬렉션이 관계형 데이터베이스의 테이블에 해당한다고 적습니다.

API(Application Programming Interface) 설계에서 모이는 것은 주소로 부르는 리소스입니다. 구글의 API 설계 지침 AIP-121 은 리소스 지향 API 가 대체로 리소스 계층으로 모델링되어야 한다고 적습니다. 그 계층의 각 노드는 단순 리소스이거나 리소스의 컬렉션입니다.

세 문서가 적은 정의는 서로 갈아 끼울 수 없습니다. 문서 데이터베이스의 컬렉션은 객체의 무리를 나타내는 인터페이스가 아닙니다. Java 의 컬렉션은 테이블에 해당하는 저장 단위가 아닙니다. 리소스 계층의 컬렉션은 프로그램이 들고 있는 값이 아니라 URI(Uniform Resource Identifier) 경로의 한 칸입니다. 어느 뜻이 원래 뜻인지는 이 문서들이 적지 않습니다. 그래서 맥락 이름을 먼저 대야 뜻이 섭니다.

맥락별 뜻

프로그래밍 언어

Java SE 21 문서는 Collection 을 컬렉션 계층의 루트 인터페이스라고 적습니다. 컬렉션은 원소라 불리는 객체의 무리를 나타냅니다. 어떤 컬렉션은 중복 원소를 허용합니다. 어떤 컬렉션은 허용하지 않습니다. 어떤 것은 순서가 있습니다. 어떤 것은 순서가 없습니다. 그 아래로 하위 인터페이스가 갈라집니다. List · Set · Queue · Deque · SortedSet 이 그 목록에 들어 있습니다.

문서가 적은 선언은 public interface Collection<E> extends Iterable<E> 입니다. 배열로 옮기는 자리도 이 인터페이스가 갖습니다. toArray() 는 이 컬렉션의 모든 원소를 담은 배열을 돌려줍니다.

Python 은 같은 자리를 컨테이너라는 말로 부릅니다. collections 모듈 문서는 이 모듈이 dict · list · set · tuple 이라는 범용 내장 컨테이너의 대안이 되는 특수 컨테이너 자료형을 구현한다고 적습니다. deque 는 양쪽 끝에서 빠르게 붙이고 뗄 수 있는 리스트 같은 컨테이너입니다. 그리고 deque 는 담기는 것의 타입에 대해 제네릭입니다.

이 맥락에서 컬렉션은 프로그램이 들고 도는 값입니다. 그 값을 다루는 규약은 인터페이스로 서 있습니다. 원소의 타입은 타입 파라미터로 묶입니다.

문서 데이터베이스

MongoDB 공식 문서는 MongoDB 가 문서를 컬렉션에 저장한다고 적습니다. 컬렉션은 관계형 데이터베이스의 테이블에 해당합니다.

앞의 맥락과 갈리는 자리가 스키마입니다. 같은 문서는 기본적으로 한 컬렉션 안의 문서들이 스키마를 공유하지 않는다고 적습니다. 필드와 데이터 타입은 문서마다 다를 수 있습니다. Collection<E> 이 원소 타입을 타입 파라미터로 묶는 것과 대비되는 대목입니다.

이 맥락에서 컬렉션은 프로그램이 들고 있는 값이 아니라 데이터베이스 안의 저장 단위입니다.

API 설계

AIP-121 은 리소스 지향 API 가 대체로 리소스 계층으로 모델링되어야 한다고 적습니다. 그 계층의 각 노드는 단순 리소스이거나 리소스의 컬렉션입니다. 컬렉션은 같은 타입의 리소스를 담습니다. 문서가 든 예가 발행사입니다. 발행사는 자기가 펴내는 책들의 컬렉션을 가집니다. 리소스는 대체로 필드를 가집니다. 리소스는 하위 리소스를 얼마든지 가질 수 있습니다. 그 하위 리소스는 대개 컬렉션입니다.

AIP-132 는 이 컬렉션이 주소에 어떻게 나타나는지를 적습니다. 많은 API 에서 컬렉션의 URI 에 GET 요청을 보내 리소스 목록을 받는 것이 관례입니다. 문서가 든 예가 /v1/publishers/1/books 입니다. 그 컬렉션 안에 사는 리소스들이 목록으로 돌아옵니다.

sequenceDiagram
    participant 클라이언트
    participant 서버
    클라이언트->>서버: GET /v1/publishers/1/books
    Note over 서버: books 가 컬렉션 식별자다
    서버-->>클라이언트: 그 컬렉션 안의 리소스 목록

목록으로 받는 리소스들의 컬렉션은 URI 경로에 대응되어야 합니다. 컬렉션의 부모 리소스는 parent 라 불려야 합니다. 그리고 그 부모 리소스는 URI 경로의 유일한 변수여야 합니다. 나머지 파라미터는 전부 URI 쿼리 파라미터에 대응되어야 합니다. 컬렉션 식별자는 리터럴 문자열이어야 합니다. 위 예에서는 books 가 그것입니다.

이 맥락에서 컬렉션은 메모리에 있는 값도 저장소의 단위도 아닙니다. 주소의 한 칸이자 그 칸이 가리키는 리소스 묶음입니다.

경계

가비지 컬렉션의 컬렉션도 이 컬렉션인가. 아닙니다. 묶음이 아니라 거두어들이는 일입니다.

근거는 Go 공식 문서의 가비지 컬렉터 안내에 있습니다. 이 문서는 메모리를 자동으로 재활용하는 일을 부르는 또 하나의 이름이 가비지 컬렉션이라고 적습니다. 크게 보아 가비지 컬렉터는 메모리의 어느 부분이 더는 필요하지 않은지 식별해서 애플리케이션을 대신해 메모리를 재활용하는 시스템입니다.

앞의 세 맥락에서 컬렉션은 담는 쪽(그릇)을 가리키는 이름이었습니다. 원소를 담는 것, 문서를 담는 것, 리소스를 담는 것이었습니다. 여기서는 그릇이 아닙니다. 거두어들이는 동작입니다. 그래서 가비지 컬렉션에는 담기는 것도 담는 자리도 없습니다.

관련 항목

자바에서 이것의 하위 인터페이스

List · Set · Queue · Deque · SortedSet

자바에서 이것을 규정하는 언어 개념

인터페이스 · 이터레이터 · 제네릭 · 배열

파이썬에서 이것을 가리키는 다른 이름

컨테이너 · dict · tuple

몽고DB에서 문서를 규정하는 구성 요소

문서 · 필드 · 데이터 타입 · 스키마 · 스키마 검증

몽고DB에서 이것이 놓이거나 대응하는 상위 구조

데이터베이스 · 테이블 · 관계형 데이터베이스

API 설계에서 이것을 이루는 리소스 체계

리소스 · 리소스 지향 설계 · 리소스 계층 · 하위 리소스 · 컬렉션 식별자

API 설계에서 이것에 접근하는 방식

URI · 쿼리 파라미터 · GET

이름이 같아 헷갈리는 이웃

가비지 컬렉션 · 가비지 컬렉터

이것을 실제로 구현·채택한 제품·언어

Java · Python · MongoDB · Go