7장. Query DSL — 검색을 말하는 언어

SQL이 "어떤 행이 조건에 맞는가"를 묻는다면, Query DSL은 "어떤 문서가 얼마나 잘 맞는가"까지 묻습니다. 점수, 컨텍스트, bool 조합 — 검색 특유의 정신 모델을 그림으로 익힙니다.

7.1 Query Context vs Filter Context — 가장 근본적인 구분

같은 조건이라도 어느 컨텍스트에 넣느냐에 따라 동작이 완전히 달라집니다. 이 구분 하나가 ES 쿼리 운영의 80%를 좌우합니다.

7.2 term vs match — 그리고 match가 매칭되는 실제 과정

초보자가 가장 많이 헤매는 지점입니다. term은 분석하지 않고 입력 그대로 역색인을 찾습니다. text 필드의 역색인에는 이미 토큰화·소문자화된 값이 들어 있으므로, text 필드에 term을 쓰면 거의 항상 매칭에 실패합니다.

// ❌ name이 text 필드면 거의 매칭 안 됨 (역색인엔 "quick","brown","fox"가 있음)
{ "term": { "name": "Quick Brown Fox" } }

// ✅ 정확 일치가 목적이면 keyword 서브필드로
{ "term": { "name.keyword": "Quick Brown Fox" } }

// ✅ 전문 검색이 목적이면 match로 (검색어도 분석됨)
{ "match": { "name": "Quick Brown Fox" } }

그렇다면 match 쿼리는 내부에서 정확히 무슨 일을 할까요? 6장의 analyzer가 여기서 다시 등장합니다.

자주 쓰는 leaf 쿼리를 정리하면:

7.3 bool 쿼리 — 조건을 조합하는 4개의 방

실전 쿼리의 대부분은 bool로 조립됩니다. 4개의 절이 각각 다른 역할을 합니다.

GET /products/_search
{
  "query": {
    "bool": {
      "must":     [ { "match": { "name": "무선 노트북" } } ],
      "should":   [ { "match": { "tags":  "프리미엄" } },
                    { "match": { "brand": "삼성" } } ],
      "filter":   [ { "term":  { "category": "laptop" } },
                    { "range": { "price": { "lte": 2000000 } } },
                    { "term":  { "in_stock": true } } ],
      "must_not": [ { "term": { "discontinued": true } } ],
      "minimum_should_match": 1
    }
  }
}

그 밖의 컴파운드 쿼리: dis_max(여러 쿼리 중 최고 점수 채택), function_score(인기도 가산·최신성 감쇠 등 점수 커스터마이징), boosting(제외 대신 점수 감점), constant_score(filter를 점수 1.0으로 고정).

7.4 점수의 정체 — BM25

ES 5.x부터 기본 점수 알고리즘은 BM25(Okapi BM25)입니다. 직관만 잡으면 충분합니다.

• TF (term frequency) — 문서 안에 토큰이 많이 나올수록 점수↑. 단, 무한히 오르지 않고 포화됩니다 (k1, 기본 1.2가 포화 정도 조절)
• IDF (inverse document frequency) — 전체 문서에서 희귀한 토큰일수록 점수↑. "the"보다 "elasticsearch"가 강력
• 문서 길이 보정 — 평균보다 긴 문서는 점수를 깎아 공평하게 (b, 기본 0.75가 강도 조절)

// 점수가 이상할 때 첫 번째 디버깅 도구: 점수 계산 내역을 트리로 출력
GET /products/_search
{
  "explain": true,
  "query": { "match": { "name": "노트북" } }
}

7.5 페이지네이션 — from/size의 한계와 search_after

{ "from": 20, "size": 10 } 방식은 얕은 페이지에서는 문제없지만, from + size가 index.max_result_window(기본 10,000)를 넘으면 거부됩니다. 왜 이런 안전장치가 있을까요?

8.x 표준 패턴은 PIT(point-in-time) + search_after입니다. PIT는 검색 시작 시점의 인덱스 스냅샷을 고정해, 페이지를 넘기는 동안 문서가 추가·삭제되어도 결과가 일관되게 유지되도록 합니다. (scroll API는 deprecated 추세 — 새 코드에서는 쓰지 마세요.)

// 1) PIT 열기
POST /products/_pit?keep_alive=1m

// 2) 첫 페이지 — tiebreaker로 _shard_doc 권장(8.x)
POST /_search
{
  "size": 100,
  "pit":  { "id": "46To...", "keep_alive": "1m" },
  "sort": [ { "created_at": "desc" }, { "_shard_doc": "asc" } ]
}
// 응답 마지막 hit의 sort 값: [1714512345000, 42]

// 3) 다음 페이지
POST /_search
{
  "size": 100,
  "pit":  { "id": "46To...", "keep_alive": "1m" },
  "sort": [ { "created_at": "desc" }, { "_shard_doc": "asc" } ],
  "search_after": [1714512345000, 42]
}

// 4) 끝나면 PIT 닫기
DELETE /_pit
{ "id": "46To..." }

7.6 운영 팁 모음

✍️ 이해도 체크