42. 공부하면서 작은 테스트 환경에 ELK를 올려보며 느낀 점

정보보안과 로그 분석에 관심이 생기면서
ELK(Elasticsearch, Logstash, Kibana)를
개인적으로 공부해 보고 싶다는 생각이 들었다.

아주 깊은 운영 경험은 아니지만,
처음 시작할 때 “이 정도를 미리 알고 있었으면 좋았겠다” 싶은 점들을
가볍게 적어본다.

‘전사 로그 통합’보다, 내가 궁금한 화면부터 정하는 게 편했다

ELK를 검색해 보면
“통합 로그 플랫폼”이라는 표현이 많이 나온다.

하지만 공부하는 입장에서는
처음부터 그 수준을 따라가려다 보면
금방 지치는 것 같았다.

그래서 방향을 바꿔서,

• 웹 서버 에러 코드를 한눈에 보고 싶은지
• 로그인 실패/성공 비율을 보고 싶은지
• 특정 서비스의 응답 지연 현황을 보고 싶은지

이런 식으로 “내가 궁금한 질문”을 먼저 정해 놓고,
그 질문에 필요한 로그부터 천천히 ELK로 보내 보았다.

이렇게 하니까
작은 화면이라도 실제로 계속 보게 되는 대시보드가 생겨서
동기 유지에 도움이 됐다.

로그 필드 정리와 파싱에서 생각보다 시간이 많이 쓰였다

ELK에 로그를 넣어보면
필드가 굉장히 많고, 형식도 제각각이다.

테스트 환경이었는데도

• 타임스탬프 형식이 다르거나
• IP, 계정, 메시지 필드 이름이 제각각이고
• 어떤 값은 문자열로 들어오고, 어떤 값은 숫자로 들어오는 등

혼란스러운 부분이 꽤 많았다.

그래서 자연스럽게

• 자주 사용할 필드 이름(예: timestamp, src_ip, user, status 등)을 정해두고
• Logstash나 수집 단계에서
  가능하면 그 이름으로 맞추려고 해보고
• 거의 보지 않을 값들은 굳이 세분화하지 않는 쪽으로

생각하게 되었다.

아직 완전히 깔끔하다고 하긴 어렵지만,
필드 정리만 조금 해도 Kibana에서 쿼리를 짤 때
머리가 훨씬 덜 복잡해지는 걸 느꼈다.

꼭 실시간이 아니어도, 하루 단위부터 시작해도 괜찮았다

관제라고 하면
“실시간으로 계속 감시해야 한다”는 이미지가 강해서
ELK도 처음부터 실시간으로 수집하고 싶었다.

그런데 공부하는 입장에서는
실시간까지 욕심내기보다는
먼저 이런 식으로 단계를 나눠 보는 게 부담이 덜했다.

• 1단계: 하루에 한 번 정도 수집해서
  어제 로그를 오늘 보는 용도
• 2단계: 10~30분 단위로 수집해서
  당일 흐름을 대략 확인하는 정도
• 3단계: 정말 필요한 일부 로그만
  최대한 빠르게 수집하는 방향

이렇게 나눠 보니,
실시간은 아니어도 충분히 의미 있는 분석이 가능하다는 걸
조금씩 느끼게 됐다.

대시보드를 ‘예쁜 그래프’가 아니라 ‘질문’ 기준으로 만들기

Kibana를 켜놓고 이것저것 그래프를 만들다 보면
겉으로는 그럴듯한 화면이 금방 생긴다.

그런데 막상 “이걸 왜 보고 있지?”라고 스스로에게 물어보면
답하기 어려운 그래프도 많았다.

그래서 나중에는
대시보드를 만들기 전에 이런 질문을 먼저 적어보려고 했다.

• 이번 주와 지난 주를 비교했을 때
  오류나 이상 징후가 늘었는가
• 특정 시간대에만 문제가 집중되는 구간이 있는가
• 관리자나 특정 계정의 사용 패턴이 평소와 다른가

이 질문에 직접 답할 수 있는 그래프만 남기고
나머지는 정리해 버리니,
대시보드가 훨씬 가볍고 실용적으로 느껴졌다.

마무리

ELK를 공부용으로라도 한 번 올려보면서 느낀 건,

• 처음부터 거창한 목표를 세우기보다는
  내가 궁금한 화면부터 정하고
• 로그 필드와 파싱을 어느 정도 정리해 두고
• 실시간이 아니어도 되는 범위부터 시작하고
• 대시보드는 “예쁜 그림”보다 “답하고 싶은 질문” 위주로 만드는 것

이 네 가지만 생각해도
로그를 다루는 감각을 익히는 데 꽤 도움이 된다는 점이었다.

아직은 기초 단계라고 보는 게 맞지만,
이 경험들을 쌓아두면
나중에 실제 업무에서 로그 플랫폼을 쓸 때
조금은 덜 낯설지 않을 거라고 기대하고 있다.