2023년 11월 당시 현재 재직중인 회사에 인턴으로 입사하여 받았던 과제는 로그서비스 개발이였다.
당시엔 인턴과제에서 끝나는 것이라 생각했지만 실제 서비스 배포까지 될줄은 몰랐지..
사담은 이만하고 로그서비스에 대해서 이야기 해보겠다.
로그란?
실제 서비스에서 발생한 동작이나 상태를 기록한 데이터.
로그가 중요한 이유는 실제 특정 서비스에서 발생한 문제를 확인하고 이를 해결 하기 위해서 매우 중요하다.
물론 개발자가 찍는것이라 의미있는 로그를 적절한 타이밍에 찍는것이 매우 중요하다.
너무 없어도 안되고, 너무 많으면 성능상 영향을 미칠 수 있다.
특히 현재 재직중인 회사는 on-premis 형태로 외부 고객사 사이트 구축을 나가기에 직접 서비스를 보기 어려운 경우가 있어 로그를 잘 찍어주는 것이 매우 중요하다.
로그 서비스까지 필요한가?
내가 입사하기 전까지 진행했던 많은 프로젝트들은 해봤자 백엔드 1, 프론트1 , 인공지능 서버1.. 정도가 로그를 확인해야 할 서버의 다였다.
또한 배포까지 가더라도 실제 사용자는 적거나 거의 없다보 봐야하기에 문제 발생시 바로 로그를 볼 수 있었다.
하지만 현 회사는 백엔드, 프론트 엔드를 제외하고 게이트웨이 등 다양한 서비스까지 하여 8개 정도의 서비스 로그를 확인해야한다.
또한 .log 형태의 파일을 직접 열고, 실시간 로그를 확인하려면 직접 갱신도 하고, 각각의 서비스로그를 열어서 검색하고 확인해야 했다.
(대충 너무 너무 불편 하다는 소리.. )
그래서 당시에 사내에서 로그서비스가 필요하다는 이야기가 나왔던것 같고 인턴과제로 이를 주었던것 같다.
근데 로그 서비스는 뭔데?
로그 서비스는 위에서 말한 로그 확인의 어려움을 해결하는 기술이다.
여러 서비스의 로그를 하나의 화면에서 볼수 있고 실시간으로 보며 검색까지 편리하게 할 수 있다.
[이미지 첨부 예정]
로그서비스는 어떻게 로그를 취합할까.
로그를 저장하기 위해서 필요한것을 생각 해본다면
일단 로그를 전달하고, 로그를 저장해서 이를 시각화 해주면 된다. 정도로 생각할 수 있다.
실제로 이와 동일하다.
1. 로그 전달 부분(로그 수집기)
여기에는 크게 두 종류가 있는데
| 로그 파일 변화 확인 | 서비스가 로그 파일(.log)에 쓰고, 수집기가 해당 파일을 읽음 | 서비스 수정 없음, 안정적 | 지연 가능성, 파싱 필요 |
| 직접 로그 전송 | 애플리케이션에서 로그를 수집기로 직접 전송 (예: TCP, HTTP) | 실시간성 우수 | 로그 전송 로직 추가 필요 |
2. 로그 저장 부분 (로그 적재)
3. 로그 시각화 부분(로그 시각화)
물론 이 모든 서비스를 직접 개발할 수 도 있지만 연관된 기술이 많이 개발되어있기에.. 알려진 것들을 사용하기로 하였다.
여기서 각각의 필요서비스를 무엇을 선택하냐에 따라서 ELK, EFK, PLG 등 다양한 이름을 가진 서비스 아키텍처를 구성한다.
재직중인 회사에서는 윈도우와 리눅스에서 패키지 설치 시점에 함께 실행가능하여서
도커, 쿠버네티스에서만 사용가능한 것은 제외하고, 루비 직접 설치가 필요한것도 제외해야했다.
대표적인 로그서비스는?
그래서 위에서 말한 것들의 대표적인 기술 스택으로는 ELK, EFK, PLG가 있다
🔍 1. ELK Stack
Elasticsearch + Logstash + Kibana
윈도우 ,리눅스 모두 가능 (쿠버네티스, 도커 등 필요하지 않음)
| Elasticsearch | 로그 저장 및 검색 (NoSQL 검색 엔진) |
| Logstash | 로그 수집 및 가공 (필터링, 변환) / 파일 바라보기, 로그 전달 방식 둘다 가능 |
| Kibana | 로그 시각화 및 분석 대시보드 |
장점:
- 커스터마이징이 자유로움 (Logstash 필터 강력)
- 많은 커뮤니티와 자료
- 다양한 입력/출력 플러그인
단점:
- Logstash는 무겁고 리소스 많이 사용
- 복잡한 설정이 필요할 수 있음
여기에는 추가로 filebeat를 사용하여 보완하기도 한다. (좀 더 경량화된 서비스)
📘 Filebeat란?
Filebeat는 Elastic에서 만든 경량 로그 수집기입니다. 주로 로그 파일을 tail 하듯 읽고, 로그를 Elasticsearch나 Logstash에 전송합니다.
- 경량이고 설치가 쉬움
- 로그 파일을 직접 읽고 전송 (위에서 말한 로그 파일 변화 확인)
- 다양한 모듈을 통한 자동 파싱 제공 (예: Nginx, Apache, MySQL 등)
ELK + Filebeat 조합
- Filebeat → Logstash → Elasticsearch → Kibana
(Logstash가 필터/가공 처리) - 혹은 Filebeat → Elasticsearch → Kibana
(Logstash 생략, 단순 파이프라인)
🪵 2. EFK Stack
Elasticsearch + Fluentd + Kibana
| Elasticsearch | 로그 저장 및 검색 |
| Fluentd | 로그 수집 및 전달 (경량화된 로그 수집기) /파일 바라보기, 로그 전달 방식 둘다 가능 |
| Kibana | 로그 시각화 |
차이점: Logstash 대신 Fluentd 사용
장점:
- Fluentd는 Logstash보다 가볍고 빠름
- Kubernetes 환경과의 호환성 좋음
- 플러그인 다양 (Kubernetes에서 표준처럼 쓰임)
단점:
- 복잡한 파이프라인 구성은 Logstash만큼 자유롭지 않을 수 있음
여기에도는 추가로 filebeat과 같은 경량화된 도구로 fluentbit을 사용하여 보완하기도 한다. (좀 더 경량화된 서비스)
📘 Fluent Bit이란?
Fluent Bit은 Fluentd 팀에서 만든 초경량 로그 수집기입니다.
주로 로그 파일을 tail 하듯 읽거나, 애플리케이션에서 직접 전송된 로그를 수신해서, 다양한 출력 대상으로 전송합니다.
- 경량이고 설치가 쉬움
- 로그 파일을 직접 읽고 전송 (위에서 말한 로그 파일 변화 확인)
- HTTP 입력도 지원 (앱에서 직접 전송)
EFK + Fluent Bit 조합
- Fluent Bit → Fluentd → Elasticsearch → Kibana
(Fluentd가 복잡한 필터/가공 처리) - Fluent Bit → Elasticsearch → Kibana
(Fluent Bit 단독으로도 가능, 단순 파이프라인 구성 시)
📦 3. PLG Stack
Promtail + Loki + Grafana
| Promtail | 로그 수집기 (Loki에 맞게 로그 전송) / 파일을 바라보는 방식 |
| Loki | 로그 저장소 (Grafana Labs에서 개발) |
| Grafana | 시각화 도구 (로그 + 메트릭 + 트레이스 통합 보기 가능) |
차이점:
- Elasticsearch 대신 Loki
- Kibana 대신 Grafana 사용
- Promtail은 Fluentd보다 단순하고 가볍다
장점:
- Grafana와 자연스럽게 통합 (로그/메트릭/트레이싱 통합 관찰 가능)
- Loki는 메타데이터 기반 인덱싱 → 저장 비용 저렴
- Kubernetes 환경에서 간단하게 구성 가능
단점:
- 검색 성능은 Elasticsearch보다 약함 (특히 전체 텍스트 검색)
- 복잡한 쿼리나 파이프라인은 어려울 수 있음
이 외에도 최근에는 Vector과 같은 더욱 가벼운 기술들이 나온것 같지만 당시에 조사할때는 많이 사용되는 형태가 아니여서 해당 글에서는 제하겠다.
내가 이중 가장 먼저 선태한것은 ELK였다.
아무래도 가장 많이 사용되어서 레퍼런스도 많고 해서..
다음글에서 이어서 이야기하겠다.
댓글