Nested 타입 — 객체 배열의 필드가 서로 뒤섞이는 문제를 막는 법
Elasticsearch Nested 타입 및 Snapshot Lifecycle Management 공식 문서 종합 (웹 리서치, 2026) — Elastic 공식 문서(reference/elasticsearch/mapping-reference/nested, api/doc/elasticsearch/operation/operation-slm-put-lifecycle) Elastic 공식 문서 Nested field type
이 모듈을 다 읽으면
- 일반 객체 배열이 왜 필드 간 연관관계를 잃어버리는지 설명할 수 있다
- nested 타입이 이 문제를 별도의 숨은 문서로 해결하는 방식과, 그래서 왜 전용 쿼리가 필요한지 설명할 수 있다
elasticsearch-learn-03에서 다룬 매핑을 전제로, 객체 배열을 저장할 때 일반 방식으로는 겪게 되는 필드 뒤섞임 문제와, 이를 해결하기 위해 배열 원소 하나하나를 별도의 숨은 문서로 취급하는 nested 타입을 정리한다.
일반 객체 배열의 함정 — 같은 원소의 필드끼리도 뒤섞인다
Elasticsearch에는 '내부 객체'라는 개념이 없어서, 객체 배열은 내부적으로 평탄화(flatten)돼 여러 값을 가진 필드들의 목록으로 바뀐다 — 예를 들어 사용자 두 명(John Smith, Alice White)이 담긴 배열은 user.first가 ["alice", "john"], user.last가 ["smith", "white"]처럼 각각 독립된 다중값 필드로 저장된다. 문제는 이렇게 평탄화되면 원래 어떤 first가 어떤 last와 짝이었는지 정보가 사라져, 'Alice AND Smith'처럼 실제로는 존재하지 않는 조합도 쿼리가 매칭시켜버릴 수 있다는 점이다.
핵심 포인트
- 객체 배열은 내부적으로 평탄화돼 각 필드가 독립된 다중값 필드로 저장 — 같은 배열 원소끼리의 연관관계가 사라짐
- 그 결과 'Alice AND Smith'처럼 실제로 없는 조합도 매칭될 수 있는 함정 발생
nested 타입 — 배열 원소마다 별도의 숨은 문서로 색인
nested 타입은 배열의 각 원소를 평탄화하는 대신 별도의 숨은 Lucene 문서로 색인한다 — 그 결과 각 nested 객체를 서로 독립적으로 조회할 수 있게 되어, John과 Alice의 이름 조합이 뒤섞이는 일 없이 원래 데이터에 있던 필드 간 연관관계가 그대로 보존된다.
핵심 포인트
- nested 타입은 배열의 각 원소를 평탄화하지 않고 별도의 숨은 Lucene 문서로 색인 — 각 원소를 독립적으로 조회 가능
- 필드 간 연관관계가 보존돼 실제로 존재하는 조합만 정확히 매칭됨
왜 전용 nested 쿼리가 반드시 필요한가
nested 문서들은 별도의 숨은 문서로 격리돼 있어, 오직 nested 쿼리의 범위 안에서만 접근할 수 있다 — 일반 쿼리는 이 숨겨진 문서 안으로 직접 들어갈 수 없다. 그래서 nested 필드를 검색하려면 반드시 path를 지정하는 nested 쿼리 문법을 써야 하며, 이 쿼리는 배열 원소 하나 전체를 대상으로 매칭을 판단해 평탄화된 필드를 쓸 때 생기는 뒤섞임 문제를 원천적으로 피한다.
핵심 포인트
- nested 문서는 nested 쿼리의 범위 안에서만 접근 가능 — 일반 쿼리는 숨겨진 문서에 직접 접근 불가
- nested 쿼리는 path를 지정해 배열 원소 하나 전체를 대상으로 매칭 판단 — 평탄화 필드의 뒤섞임 문제를 원천적으로 회피