Elasticsearch 입문 2편 — Index·Document·Shard·Replica·Mapping 5대 개념 깊이

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 2편이에요. 1편(Elasticsearch 종합) 에서 다섯 개념을 한 줄씩 짚었다면, 2편은 각 개념을 따로 떼어내 깊이 들여다봅니다. 1편이 "숲을 한 번 본 글" 이라면, 2편은 "나무 다섯 그루를 하나씩 잘라 보는 글" 이에요.

이 글의 범위

1편에서 다섯 단어를 한 줄씩 짚었어요. Index = 테이블, Document = 행, Shard = 분산 단위, Replica = 복제본, Mapping = 스키마. 입문자가 외워야 할 첫 한 줄이지만, 실제로 운영에 들어가면 이 다섯 단어 각각에 "한 줄로 못 끝나는 자리"가 두세 개씩 있어요. 예를 들어 Index 는 이름 규칙 부터 alias 까지 다섯 자리가, Mapping 은 static·dynamic·templates·multi-field·runtime 다섯 종류가 따로 있어요.

이번 글은 그 다섯 자리를 H2 한 개씩 잡아 깊이 들여다봅니다. 다 읽고 나면 _cat/indices 출력의 한 행 한 행이 무슨 뜻인지 가 머리에서 그려져요. 그 다음 3편(Lucene 내부) 와 4편(Quickstart) 로 가면 "코드를 치기 전에 머리가 먼저 그림을 그려 둔 상태" 가 됩니다.

Index — 데이터의 논리적 컬렉션

Index 는 같은 종류의 문서가 모이는 컬렉션이에요. RDBMS 의 테이블 과 가장 가까운 자리지만, 차이도 있어요. RDBMS 테이블이 스키마 고정 + 행 단위 트랜잭션 이라면, Elasticsearch Index 는 JSON 유연 + 거의 실시간 색인 + 자동 샤드 분산 이라는 색이 강해요.

이름 규칙

인덱스 이름은 반드시 소문자 여야 하고, _, -, + 로 시작할 수 없고, \, /, *, ?, ", <, >, |, , ,, # 같은 문자는 못 들어가요. 한 글자라도 어기면 400 invalid_index_name_exception 에러가 떨어집니다. 길이는 255 바이트 이하.

운영 환경의 사실상 표준은 날짜 prefix 또는 suffix 패턴이에요. 가장 흔한 형태가 logs-2026.05.19 처럼 데이터 종류 + 날짜 를 묶어 일별 인덱스를 만드는 패턴. 이렇게 두면 "5월 데이터만 삭제" 같은 작업이 DROP INDEX 한 번 으로 끝나요. RDBMS 의 파티션 테이블 자리와 비슷한데, ES 에선 인덱스 자체가 파티션 이라 더 자연스러워요.

_settings vs _mappings

한 인덱스가 가진 설정은 두 갈래로 나뉘어요. _settings 는 샤드 수·replica 수·refresh 주기·analyzer 정의 같이 물리적·운영적 설정이고, _mappings 는 어떤 필드가 어떤 타입인가 같이 논리적·스키마적 정의예요.

settings 는 또 두 종류로 갈려요. static settings 는 인덱스 생성 시점에만 정할 수 있는 값 으로 number_of_shards 가 대표예요. dynamic settings 는 운영 중에도 바꿀 수 있는 값 이고 number_of_replicas, refresh_interval 같은 값들이 여기 들어가요. 이 구분을 모르면 "왜 number_of_shards 가 안 바뀌지?" 하고 한참 헤매는 사고가 잘 생겨요.

Dynamic Index

대량 로그를 받는 환경에서 자주 쓰는 패턴이 "문서가 들어오는 순간 인덱스가 없으면 자동 생성" 하는 dynamic index 동작이에요. action.auto_create_index 설정이 기본 true 라 원하지 않는 이름의 인덱스가 잔뜩 생기는 사고 도 흔해요. 운영 환경은 action.auto_create_index: "logs-*,metrics-*,-*" 처럼 허용 목록 + 금지 와일드카드 로 잠그는 게 권장.

Alias — 가장 중요한 자리

Alias (별명) 는 하나 이상의 인덱스를 가리키는 가상 이름 이에요. 앱 코드는 절대 실제 인덱스 이름 을 직접 부르지 않고 alias 만 부르도록 짜야 해요. 이유는 재색인(reindex) 때문이에요.

매핑을 잘못 설계했거나 analyzer 를 바꿔야 할 때, 기존 인덱스를 그 자리에서 수정하는 것은 거의 불가능 해요. 새 인덱스를 만들어 reindex API 로 데이터를 복사한 다음, alias 만 새 인덱스로 원자적으로 갈아끼우는 게 ES 운영의 표준 절차예요. 이 한 가지 패턴을 모르고 운영에 들어갔다가 다운타임 수 시간 을 만드는 사고가 정말 흔해요.

POST /_aliases
{
  "actions": [
    { "remove": { "index": "products_v1", "alias": "products" } },
    { "add":    { "index": "products_v2", "alias": "products" } }
  ]
}

위 한 번의 호출이 원자적으로 실행되어서 그 사이에 들어온 요청 도 어느 한쪽 인덱스로 깔끔하게 라우팅돼요. 5편(Index 관리) 에서 alias 패턴을 더 깊이 다룹니다.

Document — JSON 한 덩어리

Document 는 인덱스에 저장되는 한 단위 레코드 예요. JSON 형식이라 중첩 객체·배열·여러 타입 이 한 문서 안에 자유롭게 들어갈 수 있고, 바로 그게 RDBMS 의 행과 결정적으로 다른 점 이에요.

_id — 자동 vs 직접 지정

_id 는 RDBMS PK 자리예요. 직접 지정 하거나 생략 하면 ES 가 Base64 UUID 를 자동 생성해 줘요. PUT /products/_doc/sku-12345 처럼 URL 에 명시하면 직접 지정, POST /products/_doc 처럼 ID 없이 POST 하면 자동 생성.

운영 권장은 비즈니스 식별자가 있으면 직접 지정 이에요. 같은 SKU 를 두 번 PUT 하면 update 가 되니까 멱등성(idempotency, 같은 요청을 여러 번 보내도 결과가 같은 성질) 이 자연스럽게 잡혀요. 반대로 자동 생성 ID 는 색인 속도가 살짝 빠르지만 재색인이 필요한 자리에서 ID 충돌이 안 나는 대신 외부 시스템과 매칭이 어려워지는 단점.

_source — 원본 JSON 그대로

_source 는 색인할 때 받은 원본 JSON 을 그대로 저장한 필드 예요. 검색 결과로 받는 hits._source 가 바로 이거예요. 기본 활성화 라서 따로 안 켜도 자동.

_source 를 끄면(_source.enabled: false) 디스크 용량이 줄지만, reindex 가 불가능 해지고 update API 도 못 써 요. 실무에선 거의 항상 켜 두고, 대신 일부 필드만 빼는 _source.excludes 패턴을 써요.

_routing — 어느 샤드로 갈지

ES 는 문서를 어느 샤드에 넣을지 를 _id 의 해시 → 샤드 번호 로 정해요. 기본 라우팅 은 _id 기반 이라서 같은 인덱스의 문서가 모든 샤드에 골고루 퍼져요.

_routing 을 명시하면 해시 입력값을 다른 키로 바꿀 수 있어요. 멀티 테넌트 (multi-tenant, 한 인스턴스에 여러 고객이 들어가는 구조) 환경에서 tenant_id 를 routing 으로 박으면 같은 고객 문서가 한 샤드에 모여서 검색이 빨라져요. 단점은 샤드 불균형 위험이 있어서, 큰 고객만 routing 으로 분리 하는 패턴이 흔해요.

메타필드 (_index · _id · _version · _seq_no · _primary_term)

문서에는 사용자 필드 외에 메타필드 가 자동으로 붙어요. _index 는 어느 인덱스에 속한 문서인지, _id 는 PK, _version 은 낙관적 동시성 제어(Optimistic Concurrency Control) 용 버전 번호예요. 같은 문서를 두 클라이언트가 동시에 수정하려 할 때, 클라이언트가 가지고 있던 _version 을 같이 보내면 충돌이 감지되면 409 가 떨어져요.

ES 6.x 까지는 _type 메타필드도 있었지만 7.x 부터 제거(deprecated) 됐고, 지금은 한 인덱스 = 한 타입 이 표준이에요. 옛 자료를 보면 _type 이야기가 나오니까 "지금은 없는 자리" 라는 점만 기억해 두세요.

_seq_no 와 _primary_term 은 primary shard 가 바뀔 때의 동시성 제어 용으로, 7.x 부터 권장 패턴이 _version 대신 if_seq_no + if_primary_term 으로 바뀌었어요. 8편(매핑 깊이) 에서 다시.

Shard — 분산의 기본 단위

Shard 는 인덱스를 쪼갠 물리적 단위 예요. 각 샤드가 사실은 독립된 Lucene 인덱스 한 개 라서, 한 ES 인덱스 = N 개의 Lucene 인덱스 라는 그림이 정확해요. 3편(Lucene 내부) 에서 다시 깊이.

Primary vs Replica 차이

Primary Shard 는 원본을 들고 있는 샤드 예요. 쓰기 요청은 반드시 Primary 로 먼저 가고, Primary 가 성공하면 그 다음에 Replica 로 동기 복제 가 일어나요. Replica Shard 는 Primary 의 복제본 이고, 읽기 부하 분산 과 Primary 노드 장애 시 승격 두 역할을 해요.

가장 자주 헷갈리는 자리가 "Replica = 백업" 이라는 오해예요. Replica 는 고가용성(HA) 을 위한 실시간 동기 사본 이지 백업이 아니에요. 실수로 인덱스를 삭제하면 Replica 도 같이 사라져요. 진짜 백업은 Snapshot 으로 따로 떠야 합니다. 28편(Snapshot) 에서 깊이.

Shard 갯수 결정 가이드

운영의 가장 큰 첫 결정이 Primary Shard 갯수 예요. 한 번 만들면 변경 부담이 큰 값이고, 너무 적으면 수평 확장 한계, 너무 많으면 오버헤드 폭증 이 둘 다 사고가 돼요.

거친 가이드는 "한 샤드 크기 30~50GB, 데이터 총량 1TB 면 Primary 20~30개" 예요. 시간 데이터는 날짜별 인덱스 로 쪼개니까 인덱스 한 개당 1~3 샤드 만 잡아도 충분.

데이터노드 수보다 Primary Shard 가 적으면 모든 노드가 일을 분담받지 못해요. 반대로 Primary Shard 가 노드 수의 3배를 넘어가면 한 노드가 너무 많은 샤드를 받아서 오버헤드 가 커져요. 데이터노드 수 × 1.5 ~ 3 이 권장 비율.

Split · Shrink · Clone API

처음 정한 샤드 수를 나중에 바꾸는 API 가 세 가지 있어요.

_split 은 샤드 수를 늘리는 작업이에요. 기존 인덱스를 읽기 전용 으로 잠그고 2배·3배 식 정수배 로 늘릴 수 있어요. 즉 1 → 2, 2 → 4, 2 → 6 은 OK 지만 1 → 3 같이 분할이 깔끔하지 않은 값 은 못 해요. 그래서 초기에 6 (2·3 의 배수) 으로 잡고 시작하는 패턴이 흔해요.

_shrink 는 샤드 수를 줄이는 작업이에요. 모든 샤드가 같은 노드 에 모여 있어야 하고 읽기 전용 + Replica 0 같은 조건이 까다로워서 드물게 쓰여요. 시간 데이터 인덱스 를 콜드 단계 로 옮길 때 5 샤드 → 1 샤드 로 줄이는 자리가 대표 사용처.

_clone 은 같은 샤드 수의 새 인덱스 를 만드는 작업이에요. 보통 매핑 변경 없이 인덱스 이름만 바꿀 때 쓰여요. 이 셋은 모두 비용이 큰 작업 이라서 실제 운영에서는 alias 와 reindex 조합 으로 푸는 게 더 흔해요.

Replica — 고가용성과 부하 분산

Replica 는 Primary Shard 의 동기 복제본 이에요. 기본값이 Replica = 1 이라서 데이터가 두 벌 로 유지돼요. 이 한 줄이 갖는 의미를 풀어 봅니다.

Replica = 1 의 의미

Replica = 1 은 각 Primary 마다 Replica 가 1개 라는 뜻이지 전체 Replica 갯수가 1 이라는 뜻이 아니에요. Primary 5개, Replica 1 설정이면 Replica Shard 도 5개 → 총 샤드 10개 가 되는 거예요.

데이터노드가 최소 2개 있어야 Replica 가 다른 노드에 배치 돼요. 1노드 환경이면 Replica 가 unassigned 상태 로 남고 클러스터 health 가 yellow 가 됩니다. 개발 환경에서 처음 ES 를 띄우면 거의 항상 yellow 가 떠 보이는 이유.

In-Sync Replica · Recovery

In-Sync Replica 는 Primary 와 완전히 동기화된 상태의 Replica 를 말해요. ES 는 모든 in-sync replica 에 쓰기가 성공해야 쓰기 응답을 클라이언트에 돌려줘요. 이게 sync replication 보장 의 핵심이에요. Kafka 의 ISR 과 같은 이름 같은 개념 이라서 이전 시리즈(Kafka) 를 본 분이라면 자연스럽게 잡혀요.

노드가 죽었다가 살아나면 해당 노드의 샤드는 stale (오래된) 상태 가 돼요. ES 가 Primary 와 비교해 차이분만 전송 하는 peer recovery 를 자동으로 돌려서 다시 in-sync 로 만들어요. 이 과정이 네트워크 대역 + 디스크 IO 를 많이 쓰니까 대형 운영에서는 recovery 속도 제한 (indices.recovery.max_bytes_per_sec) 을 잡아 두는 게 표준.

Replica 수를 늘릴 때 vs 줄일 때

Replica 는 dynamic setting 이라 운영 중에도 갱신 가능 해요. 읽기 트래픽이 폭증하면 Replica 를 2~3 으로 올려서 부하 분산, 디스크가 빠듯하면 Replica 를 0 으로 잠시 내려서 reindex 가속 같은 식으로 지렛대 처럼 씁니다.

단 Replica 를 늘리면 디스크 사용량이 그만큼 늘어요. Replica = 2 이면 데이터가 세 벌 이라 디스크가 3배 필요해요. 비용·내구성·읽기 부하 셋을 같이 봐서 정해야 하는 자리.

동기 vs 비동기

ES 8.x 기준 기본은 동기 복제 예요. 즉 Primary 가 모든 in-sync replica 에 복제를 마쳐야 클라이언트에 응답 이라서 데이터 손실 위험이 매우 낮음. 옛 자료에서 "비동기 복제 모드" 가 나오는데, 7.x 부터 사라진 옵션 이니 무시해도 OK.

다만 write quorum 개념은 살아있어요. wait_for_active_shards 옵션으로 몇 개의 활성 샤드에 쓰기가 성공해야 OK 를 정할 수 있어요. 기본 1 (= Primary 만), 권장은 quorum (= (primary + replicas)/2 + 1) 또는 all.

Mapping — 5분류 정리

Mapping 은 인덱스 안의 필드가 어떤 타입인가 를 정의하는 스키마 자리예요. 그런데 ES 의 매핑이 헷갈리는 이유는 한 단어 안에 다섯 종류의 사용 패턴이 묶여 있어서 예요. 다섯 종류를 정확히 구분해 두면 8편(Mapping Deep) 가 훨씬 부드러워요.

(1) Static Mapping

가장 명시적인 패턴이에요. 인덱스를 만들 때 모든 필드의 타입을 미리 정의 하고, 그 외의 필드는 거부 하는 방식. dynamic: strict 옵션이 핵심이에요.

PUT /products
{
  "mappings": {
    "dynamic": "strict",
    "properties": {
      "name":  { "type": "text", "analyzer": "nori" },
      "price": { "type": "integer" },
      "tags":  { "type": "keyword" }
    }
  }
}

운영 인덱스의 95% 는 이 패턴이 되어야 해요. Mapping Explosion 사고를 막는 가장 확실한 방법.

(2) Dynamic Mapping

ES 의 기본 동작 이에요. 처음 보는 필드가 들어오면 자동으로 타입을 추론 해서 매핑에 추가하는 방식. 개발 환경·프로토타입에선 편리하지만 임의의 JSON 키가 들어오는 운영 환경 에선 필드 수 폭증 → 메모리 폭증 사고 직행.

세 가지 모드가 있어요. dynamic: true (기본) 는 자동 추가, dynamic: false 는 새 필드를 색인은 안 하지만 _source 에는 보존, dynamic: strict 는 새 필드가 오면 거부 + 에러. 운영은 거의 항상 strict 또는 false.

(3) Dynamic Templates

"필드 이름 또는 타입 패턴에 따라 자동으로 매핑을 박는" 패턴이에요. *_id 로 끝나는 필드는 모두 keyword 로, *_at 으로 끝나면 모두 date 로 같은 규칙을 미리 정의해 두는 거예요. 완전 strict 까지는 못 가지만 임의의 필드를 통제 하고 싶을 때 쓰는 중간 단계.

"dynamic_templates": [
  {
    "ids_as_keyword": {
      "match": "*_id",
      "mapping": { "type": "keyword" }
    }
  }
]

로그성 데이터처럼 완전 통제는 어렵지만 패턴은 있는 자리에 자주 쓰여요.

(4) Multi-field

한 필드를 여러 방식으로 색인 하는 패턴이에요. 가장 흔한 자리가 상품명 이에요. 풀텍스트 검색용 text 분석 과 정확 매칭·집계용 keyword 미분석 을 둘 다 필요 한 경우.

"name": {
  "type": "text",
  "analyzer": "nori",
  "fields": {
    "keyword": { "type": "keyword", "ignore_above": 256 },
    "english": { "type": "text", "analyzer": "english" }
  }
}

이렇게 두면 name 으로 한국어 풀텍스트, name.keyword 로 정확 매칭·집계, name.english 로 영어 분석 셋이 다 돼요. 색인 시 디스크와 메모리는 그만큼 더 쓰지만 유연성이 압도적 이라서 e-commerce 상품명·사용자 이름 같은 자리는 거의 항상 multi-field.

(5) Runtime Field

7.11 부터 들어온 비교적 새 기능이에요. 색인 시점이 아니라 검색 시점에 즉시 계산되는 필드. 매핑을 바꾸지 않고도 새 필드를 추가할 수 있어서 재색인을 피하는 자리에 강력해요.

"runtime": {
  "price_with_tax": {
    "type": "double",
    "script": {
      "source": "emit(doc['price'].value * 1.1)"
    }
  }
}

장점은 유연성·재색인 불필요, 단점은 검색 시 매번 계산이라 느림 + 캐싱 X. 대량 데이터에 자주 검색되는 필드 는 runtime 으로 두지 말고 static 으로 색인 해야 해요. 임시 분석·일회성 쿼리 자리에 어울리는 도구.

다섯 종류를 한 줄로 묶으면 — Static (운영 권장) · Dynamic (개발) · Templates (중간) · Multi-field (유연성) · Runtime (임시). 8편에서 각각의 실제 쿼리·analyzer 옵션 까지 깊이.

자주 만나는 사고

사고 1 — Routing 키 잘못 잡아 샤드 불균형

원인 — 멀티 테넌트 환경에서 큰 고객 = 한 샤드 패턴을 무리하게 적용하면 대형 고객 한 명이 한 샤드에 몰빵 돼서 디스크가 80% 를 넘어가요.

해결 — 큰 고객만 routing 분리, 작은 고객은 기본 라우팅 으로 가는 하이브리드 패턴 이 권장. _cat/shards 로 샤드별 doc 갯수 를 주기적으로 모니터링해야 해요.

사고 2 — Alias 안 쓰고 인덱스 직접 부르기

원인 — 앱 코드에 실제 인덱스 이름 products_v1 이 박혀 있으면 재색인할 때 다운타임 이 발생해요.

해결 — 처음부터 alias products 로 부르도록 강제. 인덱스가 1개여도 alias 를 박아 두는 게 표준.

사고 3 — Replica = 0 으로 운영

원인 — 비용 절감 이라며 Replica 0 으로 운영하면 노드 한 대가 죽는 순간 데이터 손실 이에요.

해결 — 최소 Replica = 1, 데이터노드 2개 이상. 백업은 Snapshot 으로 별도 가 비용 측면에서도 더 합리적.

사고 4 — _source 끄고 reindex 못 함

원인 — 디스크 절약 이라며 _source.enabled: false 로 잡으면, 나중에 매핑 변경 → reindex 가 원천적으로 불가능 해요.

해결 — 기본값 true 유지. 정 절약하고 싶으면 _source.excludes 로 큰 필드만 제외. 8편에서 자세히.

사고 5 — Dynamic Mapping 켠 채 로그 받기

원인 — 다양한 JSON 키가 들어오는 로그 인덱스 에 dynamic: true 가 켜져 있으면 몇 시간 만에 필드 수 5,000+ 가 돼서 클러스터가 OOM.

해결 — dynamic: strict 또는 dynamic: false + Dynamic Templates 조합. index.mapping.total_fields.limit 도 1,000 정도로 박아 안전망.

사고 6 — Multi-field 남발

원인 — "혹시 모르니까" 라며 모든 필드를 text + keyword + 다국어 analyzer 로 multi-field 잡으면 색인 시간 3배 + 디스크 2~3배.

해결 — 실제 쿼리 패턴 을 먼저 파악하고 정말 필요한 필드만 multi-field. 대부분의 필드는 text 또는 keyword 하나만으로 충분.

사고 7 — Runtime Field 를 자주 쓰는 검색에 사용

원인 — 운영 자주 검색되는 필드를 runtime 으로 잡으면 매 검색마다 스크립트 실행 → 지연 폭증.

해결 — 일회성·분석용만 runtime, 반복 쿼리는 static 으로 색인. 또는 runtime 으로 검증 후 → static 매핑으로 옮겨 reindex 하는 2단계 패턴.

운영 권장 패턴

운영 시작 전에 Index · Document · Shard · Replica · Mapping 다섯 자리 에 대해 각각 기본 설계 한 줄 을 적어 두는 게 권장이에요. "우리 회사 표준 — Mapping 은 strict, Replica 1, Shard 6 (1·2·3·6 배수 유연), Alias 필수, _id 는 비즈니스 키" 같은 식.

색인 이름은 데이터 종류 + 날짜 패턴으로 표준화해요. <도메인>-<타입>-YYYY.MM.DD 가 가장 흔한 포맷이고, 이 한 줄을 정해 두면 ILM (Index Lifecycle Management, 인덱스 자동 회전) 적용이 자연스럽게 따라와요. 6편(ILM) 에서 깊이.

쓰기 트래픽이 큰 인덱스는 refresh_interval 을 1초 → 30초 로 늘리는 게 권장 시작점이에요. ES 기본값 1초는 near real-time 검색 을 위한 값인데, 로그성 데이터 는 30초 지연이 허용 되니까 색인 처리량이 30~50% 더 나옵니다.

Mapping 변경이 필요할 땐 항상 reindex + alias swap 패턴으로 가세요. 기존 인덱스를 그 자리에서 수정하는 마법은 없어요. 5편(Index 관리) 의 한 페이지 전체가 이 패턴이에요.

시험 직전 한 번 더 — 압축 노트

• Index = 같은 종류 문서 컬렉션, RDBMS 테이블 자리. 이름은 소문자·날짜 prefix 표준.
• _settings = 물리적·운영적, _mappings = 논리적·스키마적. settings 는 static (생성시만) vs dynamic (운영중 가능).
• Alias 는 재색인의 핵심. 앱은 절대 인덱스 이름 직접 호출 X.
• Document = JSON 한 덩어리. _id 자동 vs 직접 지정, 운영은 비즈니스 식별자 직접 지정 권장.
• _source = 원본 JSON 보존, 기본 활성 유지. 끄면 reindex·update X.
• _routing = 샤드 결정 키. 멀티 테넌트 환경에서 대형 고객만 분리 가 표준.
• 메타필드: _index · _id · _version · _seq_no · _primary_term. _type 은 7.x 부터 사라진 자리.
• Shard = 인덱스 쪼갠 단위 = 독립 Lucene 인덱스.
• Primary (원본) vs Replica (동기 복제본). Replica 는 백업 아님, 백업은 Snapshot 별도.
• Primary Shard 갯수 가이드: 데이터 1TB ≈ Primary 20~30, 데이터노드 수 × 1.5~3.
• Split (정수배 증가) · Shrink (1 또는 약수로 감소) · Clone (동일 갯수 복제).
• In-Sync Replica = Primary 와 완전 동기, 모든 ISR 에 쓰기 성공해야 응답.
• Replica = 1 의미 = 각 Primary 마다 1개 → 데이터 두 벌. dynamic setting 이라 운영 중 조정 가능.
• Mapping 5종: Static (운영 권장) · Dynamic (개발) · Templates (중간) · Multi-field (유연) · Runtime (임시).
• Dynamic Mapping 세 모드: true (자동) · false (_source 보존만) · strict (거부). 운영은 strict.
• Multi-field 의 가장 흔한 자리 = text + keyword (풀텍스트 + 정확 매칭).
• Runtime Field = 검색 시 즉시 계산, 재색인 회피. 자주 쓰는 검색엔 비추.
• 7대 사고: routing 불균형 · alias 미사용 · Replica 0 · _source 비활성 · dynamic 로그 · multi-field 남발 · runtime 남용.
• 운영 표준: Mapping strict · Replica 1 · Shard 6 · Alias 필수 · _id 비즈니스 키.

시리즈 다른 편

• 이전 글 = 1편 Elasticsearch 종합 — 분산 검색·분석·AI 플랫폼
• 다음 글 = 3편 Lucene 내부 — Segment·Inverted Index·Posting List
• 4편 = Quickstart — Docker·curl·Kibana 첫 화면
• 5편 = Index 관리 — Create·Settings·Alias·Reindex
• 6편 = ILM — Hot·Warm·Cold·Frozen·Delete
• 8편 = Mapping Deep — Static·Dynamic·Multi-field·Runtime

한 줄 정리 — Index (테이블) · Document (JSON 행) · Shard (분산 단위) · Replica (동기 복제) · Mapping (스키마) 다섯 단어가 ES 의 뼈대. 입문은 한 줄로, 운영은 각 단어마다 다섯 자리 로 펼쳐서 본다.