Elasticsearch 입문 33편 — Kibana·ELK Stack (Discover·Dashboard·Lens·Canvas·Maps)

이 글은 Elasticsearch 입문에서 운영까지 시리즈 38편 중 33편이에요. 32편이 Spring Data Elasticsearch 로 코드에서 ES 를 어떻게 부르는가 를 잡았다면, 33편 Kibana 는 그 코드가 쌓아 놓은 데이터를 사람이 어떻게 들여다보느냐 자리예요. ES 의 눈 이라고 부르는 도구.

ES 의 눈 — Kibana 와 ELK 스택

ES 자체는 검색·집계 엔진 이지 사람이 보는 화면 이 없어요. curl -X GET 으로 JSON 던지고 JSON 받는 게 전부. 운영자·기획자·데이터 분석가가 클러스터 상태 보고·로그 검색·매출 대시보드 하나 만들려면 그 위에 시각화 레이어 가 필요해요. 그 자리를 잡는 표준이 Kibana 예요.

ELK 스택 은 세 도구 머리글자를 딴 이름. Elasticsearch (저장·검색) + Logstash (수집·가공) + Kibana (시각화) 의 묶음이에요. 여기에 Beats (가벼운 수집 에이전트) 가 합쳐져 Elastic Stack 으로 부르는 게 2026년 기준 정식 명칭. 그래도 현장에서는 ELK 라는 호칭이 압도적이라 이 시리즈도 그대로 써요.

이 세 도구의 분업이 — Beats·Logstash 가 데이터를 모아 ES 에 넣고, Kibana 가 그 ES 를 사람이 읽도록 풀어 준다. 한 줄로 외워 두면 33편 전체가 한 호흡에 잡혀요.

Kibana 개요 — 무엇을 주는 도구인가

Kibana = Elastic 사가 제공하는 ES 전용 웹 UI·시각화·관리 도구 예요. 2013년 Rashid Khan 이 만든 오픈소스에서 시작해서, 지금은 Elastic Stack 의 사실상 표준 클라이언트 자리.

핵심을 한 호흡에 요약하면 — 브라우저로 ES 클러스터에 접속해 데이터 탐색 · 시각화 · 대시보드 · 운영 관리 · 머신러닝 · 보안 모니터링 까지 한 화면에서 한다. ES 가 데이터베이스 라면 Kibana 는 대시보드 + 워크벤치 + 콘솔 을 묶은 도구예요.

버전 정책 이 중요해요. Kibana 는 ES 와 같은 메이저·마이너 버전 을 써야 합니다. ES 8.13 → Kibana 8.13. ES 7.10 → Kibana 7.10. 한 칸이라도 어긋나면 기능이 일부 안 보이거나, 시작이 거부되거나 합니다. 이건 권장이 아니라 강제 라서 운영에서는 ES 와 Kibana 를 같은 helm chart·docker-compose 로 묶어 관리 하는 게 표준.

라이선스 도 같이 따라가요. 7.11 부터 Kibana 는 SSPL + Elastic License 라이선스고, 8.x 부터는 AGPL 옵션 이 추가됐어요. OpenSearch 환경에서는 OpenSearch Dashboards 라는 fork 가 같은 자리를 잡고 있어요 (1편·35편 참조).

8.x 의 가장 큰 변화 는 security 가 기본 ON 이에요. 7.x 까지는 xpack.security.enabled: false 가 기본이라 비밀번호 없이 바로 접속이 가능했는데, 8.0 부터는 처음 시작 자체가 enrollment token 기반의 보안 절차 로 묶여 있어요. 처음 설치한 사람이 "왜 비밀번호를 묻지?" 하고 헤매는 자리가 여기. 29편(Security·RBAC) 과 연결해서 보면 좋아요.

설치는 보통 셋 중 하나예요.

• 로컬 학습 — Docker compose 한 줄로 ES + Kibana 같이 띄우는 게 표준. docker-compose.yml 에 두 서비스 박고 5601 포트로 들어가요.
• 자체 운영 — 검색용 클러스터에 Kibana 노드 1~2 대 를 따로 두고, coordinating 노드 로 연결.
• 매니지드 — Elastic Cloud 나 AWS OpenSearch Service 가 Kibana(또는 OpenSearch Dashboards) 를 자동 프로비저닝해 줘요.

Discover — 데이터 탐색 시작점

Kibana 들어가서 가장 자주 여는 자리. 왼쪽 메뉴 → Analytics → Discover. 인덱스 안의 raw 문서 를 한 줄씩 펼쳐 보는 곳이에요.

Discover 의 본질 = KQL 또는 ES Query DSL 로 인덱스를 검색하고, 결과를 시간 축 히스토그램 + 테이블로 보여 주는 도구. 운영자가 사고 났을 때 로그 인덱스 들어가서 "5분 전 error 로그 다 보여 줘" 같은 1차 진단을 여기서 합니다.

쓰려면 먼저 Data View (이전 이름 Index Pattern) 가 있어야 해요. Stack Management → Data Views → Create data view 에서 orders-* 같은 패턴을 박고, time field 로 @timestamp 같은 시간 필드를 지정해요. 이게 있어야 Discover 의 시간 슬라이더가 동작.

화면 구성은 셋이에요.

• 검색바 — KQL 또는 Lucene 문법으로 필터를 박는 자리.
• 타임 슬라이더 — 우상단 시간 범위. Last 15 minutes · Last 24 hours · Last 7 days 같은 프리셋 + 사용자 정의.
• 히스토그램 + 문서 테이블 — 시간 축 분포와 매칭된 raw 문서.

운영에서 시간 범위 누락 이 정말 자주 나는 사고예요. 기본값이 Last 15 minutes 라서 3시간 전 사고 로그를 찾는데 빈 화면을 보고 당황 하는 자리. 사고 보고서 작성하기 전에 시간 범위부터 1순위 확인.

KQL vs ES Query DSL

Discover (그리고 거의 모든 Kibana 검색바) 는 기본적으로 KQL 을 써요. KQL = Kibana Query Language — Lucene 문법보다 친절하고 사람이 읽기 쉬운 미니 언어예요.

KQL 예시 한 호흡.

status: "error"
status: "error" and message: *timeout*
status: "error" and not user_id: "test"
response_time > 1000
host.name: ("web-01" or "web-02")

ES Query DSL 예시 (같은 첫 줄을 풀어쓴 거예요).

{
  "query": {
    "bool": {
      "must": [
        { "term": { "status": "error" } }
      ]
    }
  }
}

Discover 우상단에 KQL 토글 이 있어서 Lucene 문법 으로도 쓸 수 있고, 고급 옵션 으로 ES Query DSL JSON 을 직접 박아서 bool · nested · script 같은 깊은 쿼리도 돌아가요. 다만 대부분의 일상 검색은 KQL 한 줄이면 충분 합니다.

KQL 의 자주 쓰는 패턴 한 묶음.

• 존재 체크 — field: *
• 부정 — not field: value
• 범위 — response_time >= 1000 and response_time < 5000
• 와일드카드 — host.name: web-* (필드가 keyword 또는 wildcard 타입일 때)
• 중첩 객체 — user.name: "kim"

15편(Term-level Queries) · 16편(Full-text Queries) 의 ES Query DSL 과 대응 표 로 외워 두면 운영에서 빨라요.

Dashboard·Visualize — 시각화 종류

Discover 가 날 raw 데이터를 들여다보는 자리라면, Dashboard 는 시각화된 차트를 한 화면에 모아 두는 자리예요. 왼쪽 메뉴 → Analytics → Dashboard.

대시보드 하나가 여러 panel 로 구성돼요. 각 panel 이 Lens · TSVB · Maps · Markdown · Canvas 같은 시각화 객체 하나. 운영용 대시보드의 표준 구성은 — 상단에 KPI 숫자 두세 개 → 가운데 시계열 라인 차트 → 하단에 카테고리별 bar 또는 pie → 사이드에 raw 문서 테이블 패턴.

시각화 종류 가 정말 많아요. 자주 쓰는 것만 정리.

Visualize Library 메뉴가 별도로 있어요. 재사용 가능한 시각화 객체를 저장 하고 여러 대시보드에서 공유 하는 방식. 운영 표준은 시각화는 Library 에 저장 → 대시보드는 그 Library 객체를 reference 입니다. 같은 차트를 대시보드 5개에 복붙 하면 나중에 집계 로직 바뀔 때 5개를 다 고쳐야 하니까.

TSVB (Time Series Visual Builder) 는 8.x 에서 deprecated 권장 단계 예요. Lens 가 후속이라 신규 시각화는 Lens 우선 으로 짜는 게 맞아요.

Lens — 8.x 권장 시각화 도구

Lens = Drag & Drop 으로 차트를 만드는 Kibana 의 현재 표준 시각화 도구 예요. 7.11 정식 출시 이후 Elastic 이 모든 신규 시각화는 Lens 로 라는 방향으로 밀고 있어서, 8.x 에서는 사실상 1순위.

핵심 작동 방식. 왼쪽 패널의 필드를 가운데 차트 영역으로 드래그 하면 Lens 가 데이터 모양을 보고 적절한 차트 타입을 자동 추천 해요. @timestamp 를 끌면 자동으로 시간 축 → 라인 차트. category.keyword 를 끌면 자동으로 bar 차트 + count. response_time 을 끌면 자동으로 average 같은 식.

자동 추론이 빠르지만 틀리는 자리 도 분명히 있어요.

• text 필드를 그룹 키로 끌면 — Aggregations 지원 X 라서 no data 표시. .keyword 서브필드를 끌어야 됨. 8편(Mapping Deep) 의 multi-field 와 연결.
• 자동 metric 선택이 mean 이지만 운영에서 원하는 건 p99 — 지표 클릭 → percentile 로 바꿔야 됨.
• 시간 축이 fixed bucket size 로 잡혀 — 24시간 보는데 1분 버킷이 잡혀서 너무 빽빽. time interval 을 auto 또는 1h 로 조정.

Lens 의 강점은 Suggestions 패널. 화면 하단에 "이 데이터로 만들 수 있는 다른 차트" 가 자동 추천돼서, line 으로 그렸다가 한 클릭으로 bar 로 갈아엎고, 다시 heatmap 으로 바꿀 수 있어요. 시각화 결정이 데이터를 보고 나서 정해지는 패턴이라 이게 정말 편해요.

Formula 기능도 강해요. 한 metric 안에서 서로 다른 집계의 사칙연산 을 박을 수 있어요.

(sum(revenue) - sum(cost)) / sum(revenue) * 100

이게 수익률 그래프 한 줄로 끝나요. 17편(Aggregations Metric) 의 Bucket Script Pipeline Agg 를 GUI 로 한 거라고 보면 됩니다.

Canvas — pixel-perfect 프레젠테이션

Dashboard 가 분석가용 도구 라면, Canvas 는 임원·외부 보고용 슬라이드 자리예요. 왼쪽 메뉴 → Analytics → Canvas.

특징 한 호흡. PowerPoint 처럼 자유로운 캔버스에 텍스트·이미지·차트·표를 배치 하고, 각 요소가 실시간 ES 쿼리로 갱신 돼요. 일반 Dashboard 가 격자 기반 이라면 Canvas 는 완전 자유 배치. 발표용 one pager 보고서 같은 결과물 만들 때 빛납니다.

핵심 개념이 Expression Language 예요. 각 요소가 함수형 파이프라인 으로 정의돼요.

filters
| essql
  query="SELECT category, COUNT(*) AS cnt FROM \"orders-*\" GROUP BY category"
| pointseries x="category" y="cnt"
| plot defaultStyle={seriesStyle bars=0.75}

좌→우로 데이터 소스 → 가공 → 시각화 가 흐르는 패턴. ES 의 SQL API (18편 참조) 를 그대로 부르거나, ES Query DSL 을 박거나, external API 도 호출 가능.

Canvas 는 e-commerce 의 일간 매출 요약·운영 morning report·이사회 슬라이드 같은 자리에서 강해요. 다만 분석가 일상 도구 는 아니어서 학습 곡선 이 있어요. Dashboard 가 우선, Canvas 는 보고용 으로 분업하는 게 일반.

Maps — geo 데이터 시각화

ES 의 geo_point · geo_shape 필드 (8편 참조) 를 지도 위에 띄우는 자리. 왼쪽 메뉴 → Analytics → Maps.

Layer 개념이 핵심이에요. 한 지도 위에 여러 레이어 가 겹쳐져요.

• Documents 레이어 — raw 위치 점을 그대로 표시. 주문 발생 위치·매장 좌표 같은 자리.
• Cluster 레이어 — geo_hash 또는 geo_tile 버킷으로 집계해서 점 또는 격자 로 표시. 데이터 100만 건 넘으면 raw 점은 못 그리니까 필수.
• Choropleth (단계 구분도) — 행정구역 polygon 위에 집계 값으로 색 을 채워요. 시·도별 매출 색깔 지도 같은 자리.
• Heatmap — 밀도 기반 색 그라데이션.
• EMS (Elastic Maps Service) — Elastic 이 제공하는 world / country / region 폴리곤 무료 제공.

Tooltip 도 강해요. 점·polygon 위에 마우스 올리면 집계 metric · raw 문서 일부 를 띄울 수 있어서 운영자가 지도 보면서 이상 지역만 클릭해 들어가는 패턴이 가능.

배달 앱·물류·O2O 회사에서 Maps 가 ES 채택의 결정적 이유 가 되는 자리가 많아요. PostGIS + Tableau 조합 대비 학습 곡선 낮고 실시간 갱신 강점이 있어서 시리즈 안에서는 Maps + dense_vector + RAG 까지 묶인 공간·시맨틱 검색 통합 자리 로 더 깊이 들어갑니다 (21편·22편 참조).

Dev Tools·Stack Management — 운영자 워크벤치

Dashboard·Visualize 가 데이터 사람용 도구라면, Dev Tools 와 Stack Management 는 운영자·개발자용 도구예요.

Dev Tools → Console

왼쪽 메뉴 → Management → Dev Tools → Console. curl 대신 쓰는 Kibana 내장 REST 클라이언트 예요. 운영자가 가장 자주 만지는 자리.

GET /_cluster/health

GET /orders-2026-05/_search
{
  "query": { "term": { "status": "error" } }
}

POST /orders-2026-05/_update_by_query
{
  "query": { "term": { "deleted": true } }
}

장점이 셋. 자동 완성 — 인덱스 이름·필드 이름·API path 가 다 추천돼요. JSON 포매팅 — auto-format 한 번 누르면 들여쓰기 자동. 히스토리 — 최근 100개 요청이 자동 저장됨. Postman 대신 Kibana Console 만 써도 90% 의 운영 API 호출이 끝나요.

Dev Tools → Profiler

쿼리 성능 진단 도구. 검색 한 번에 어느 샤드에서 몇 ms, 어느 쿼리 절에서 몇 ms 까지 Lucene 레벨 로 들여다보게 해 줍니다. 31편(Performance Tuning) 의 slow query 원인 파악 의 1순위 도구.

Stack Management

운영자가 가장 자주 만지는 두 번째 자리. 메뉴가 정말 많아요. 자주 만나는 것만.

• Index Management — 인덱스 목록·settings·mapping 보기, 닫기·열기·삭제, force merge·flush 같은 운영 작업.
• Index Lifecycle Policies — 6편(ILM) 의 hot·warm·cold·delete 정책을 GUI 로 박는 곳.
• Index Templates — 새 인덱스에 자동 적용될 mapping·settings 템플릿.
• Data Views — Discover·Dashboard 가 쓰는 index pattern 정의.
• Saved Objects — 대시보드·시각화·검색 등 Kibana 가 저장하는 모든 객체를 export · import 하는 자리.
• Snapshot and Restore — 28편(Snapshot Restore) 의 repo·스냅샷·정책을 GUI 로.
• Security → Users·Roles·Role mappings — 29편(Security RBAC) 의 사용자·역할 관리.
• License Management — 라이선스 키 업로드.

운영 표준은 코드로 박을 수 있는 건 IaC (37편)·터미널로, 일회성·진단성 작업은 Stack Management 로 분업하는 패턴이에요. 터미널 vs GUI 가 아닌 코드 vs 일회성 으로 가르는 게 운영에서 덜 다쳐요.

Stack Monitoring

별도 자리. 왼쪽 메뉴 → Management → Stack Monitoring. 30편(Monitoring) 의 _cluster/health · _nodes/stats · slow log 를 한 화면에 묶은 전용 모니터링 대시보드. 이걸로 클러스터 health · 노드 JVM heap · 인덱싱 rate · 검색 rate · slow query 가 한 페이지에 다 떠요. 운영 표준 셋업의 1순위 위젯.

자주 만나는 사고

사고 1 — Time Range 누락

원인 — Discover·Dashboard 의 우상단 시간 슬라이더가 기본값 Last 15 minutes 인데, 사고 시점이 3시간 전이라 결과 0건 으로 떠서 데이터가 없다고 오해.

해결 — Time Range 가 1순위 체크 포인트. 운영 표준 대시보드는 기본 시간 범위 를 Last 24 hours 로 잡아 저장해 두는 게 안전. Last 15 minutes 가 기본인 대시보드 는 신규 사용자에게 사고 위험.

사고 2 — Data View 미생성

원인 — Discover 들어갔는데 No data views 화면이 떠 있음. Kibana 자체는 살아 있는데 어느 인덱스를 볼지 매핑이 없는 상태.

해결 — Stack Management → Data Views → Create data view 로 인덱스 패턴 등록. @timestamp 같은 시간 필드 지정 필수. 신규 환경 셋업 체크리스트의 1번 항목.

사고 3 — KQL 문법 실수

원인 — status = "error" 같이 SQL 처럼 등호 박는 실수, 또는 not status: error 처럼 not 뒤에 콜론 빼먹는 실수가 흔해요.

해결 — KQL 은 콜론(:) 만 쓰고, 부정은 not field: value 형태가 표준. 검색바 우상단의 문법 도움 토글로 Lucene 또는 KQL 확인.

사고 4 — Lens 자동 추론 실패

원인 — Lens 가 text 필드를 그룹 키로 끌면 no data, @timestamp 가 없는 인덱스 에 line 차트 시도하면 시간 축 안 잡힘, 집계가 자동으로 mean 인데 운영은 p99 원함.

해결 — Multi-field 의 .keyword 서브필드 사용, Data View 의 time field 점검, 지표 클릭으로 percentile 변경. 자동 추론은 시작점일 뿐 검증 필수.

사고 5 — Field Not Indexed

원인 — Discover 사이드바 필드 옆에 경고 아이콘 이 떠 있음. 필드가 aggregatable 또는 searchable 가 아닌 상태 라 KQL 검색·시각화 그룹 키 로 못 씀.

해결 — Mapping 점검. text 필드는 aggregatable X, enabled: false 박은 필드는 searchable X. .keyword 서브필드 추가하거나 runtime field 로 우회 (8편 참조).

사고 6 — Dashboard 권한 누락

원인 — 다른 팀원이 대시보드 열었는데 panel 마다 'unauthorized' 가 떠서 빈 그래프. 역할에 인덱스 read 권한이 없거나, Kibana Space 권한이 없는 상태.

해결 — Stack Management → Security → Roles 에서 해당 인덱스 read 권한 + Kibana feature privileges (Discover·Dashboard·Visualize) 부여. 29편(Security RBAC) 의 role mapping 으로 SSO 그룹과 묶는 게 운영 표준.

사고 7 — Kibana 와 ES 버전 불일치

원인 — ES 8.13 인데 Kibana 8.11 을 띄움. 일부 기능이 gray-out 또는 startup 거부 됨.

해결 — 메이저·마이너 정확히 일치 필수. helm chart·docker-compose 에서 같은 변수 로 두 버전을 묶어 관리.

사고 8 — Saved Object 백업 누락

원인 — Kibana 가 떠 있는 노드를 재구축했는데 대시보드·시각화 수십 개가 다 사라짐. ES 안의 .kibana 시스템 인덱스가 백업 대상에서 빠져 있었음.

해결 — Stack Management → Saved Objects → Export all 로 정기 export, 또는 .kibana 인덱스를 28편(Snapshot Restore) 의 정기 스냅샷에 포함. 대시보드를 수십 개 만든 환경 일수록 1순위 점검 항목.

운영 권장 패턴

운영 들어가기 전에 Kibana 도 운영 자원 으로 다루는 자세가 필요해요. 대시보드 = 코드와 같은 자산 이라는 관점.

시각화는 Visualize Library 에. 같은 차트를 여러 대시보드에 복붙 하면 집계 로직 바뀔 때 N개 모두 손대야 해서, 처음부터 Library 에 저장 → 대시보드는 reference 패턴으로.

Saved Object Export 를 IaC 와 묶어. 운영 대시보드·시각화·data view 는 Kibana UI 에서 만들고 → export ndjson → git 에 커밋 → 다른 환경에 import 흐름이 표준. 37편(IaC) 의 Terraform·ECK 와 묶어 자동화하는 패턴.

대시보드의 기본 시간 범위는 24시간 이상. 15분 기본은 사고 보고서 화면에서 데이터가 없다는 오해 를 유발. 운영용 표준 대시보드는 24h 또는 7d 기본.

Lens 우선, TSVB·legacy Visualize 회피. 신규 시각화는 Lens 표준. TSVB·legacy Visualize 는 8.x 에서 deprecation 흐름이라 신규 자산을 거기 쌓으면 다음 메이저 업그레이드 때 마이그레이션 부담 이 됩니다.

Space 로 권한 분리. Kibana 의 Space 가 대시보드·시각화의 폴더 + 권한 단위 예요. 팀별·환경별 prod-search · prod-logs · dev 같은 Space 를 따로 두고 역할별로 다른 Space 만 보이게 분리하는 게 표준.

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

• Kibana = Elastic 사의 ES 전용 웹 UI·시각화·관리 도구.
• ELK 스택 = Elasticsearch + Logstash + Kibana. Beats 합쳐서 Elastic Stack.
• 버전 정책 = ES 와 Kibana 의 메이저·마이너 정확히 일치 필수.
• 8.x 변화 = security 기본 ON, enrollment token 기반 첫 설치.
• Discover = 인덱스 raw 데이터 탐색. KQL + 시간 슬라이더 + 문서 테이블.
• KQL = field: value, and · or · not, >= · *. ES Query DSL 보다 친절.
• Dashboard = panel 묶음. Lens · Maps · Markdown · Canvas 가 panel 단위.
• Lens = 8.x 권장 시각화. Drag & Drop · Suggestions · Formula.
• TSVB·legacy Visualize = deprecated 흐름. 신규 사용 회피.
• Canvas = pixel-perfect 프레젠테이션. Expression Language. 보고용.
• Maps = geo 데이터 시각화. Documents · Cluster · Choropleth · Heatmap · EMS.
• Dev Tools Console = curl 대신 쓰는 내장 REST 클라이언트. 자동 완성·히스토리·포맷.
• Dev Tools Profiler = 쿼리 성능 진단. Lucene 레벨까지.
• Stack Management = Index·ILM·Data View·Saved Object·Snapshot·Security 통합 GUI.
• Stack Monitoring = 30편 monitoring 의 전용 대시보드.
• 사고 8: Time Range 누락 · Data View 미생성 · KQL 문법 · Lens 자동 추론 · Field Not Indexed · Dashboard 권한 · 버전 불일치 · Saved Object 백업.
• 운영 5: Library 시각화 · IaC export · 기본 24h · Lens 우선 · Space 권한 분리.

시리즈 다른 편

• 이전 글 = 32편 Spring Data Elasticsearch — Repository·Template·POJO
• 다음 글 = 34편 Observability — APM·Logs·Metrics·Synthetics
• 1편 = 시리즈 종합 — 검색·로그·AI 한 통에 다 들어가는 분산 엔진
• 6편 = ILM·Aliases·Rollover — Stack Management 에서 보는 자리
• 8편 = Mapping Deep — keyword·multi-field·runtime field
• 17편 = Aggregations Metric — Lens Formula 의 백본
• 25편 = Logstash·Beats·Fluentd — ELK 의 L·B 쪽
• 29편 = Security·RBAC — Kibana Space·역할·SSO
• 30편 = Monitoring — Stack Monitoring 의 데이터 소스
• 37편 = IaC — Terraform·ECK 로 Kibana 자산 자동화

한 줄 정리 — Kibana = ES 의 눈. Discover 로 raw 탐색, Lens 로 시각화, Canvas 로 보고서, Maps 로 공간, Dev Tools·Stack Management 로 운영. ES 와 같은 버전 + Saved Object IaC + Space 권한 분리 가 운영 표준.