Fluent Bit vs Vector, 로그 수집기 뭘 쓸까

로그 파이프라인 재설계 얘기가 팀 내부에서 다시 나왔다. 3년 전에 Fluentd로 깔아둔 걸 언제까지 끌고 갈지, 지금 시점에서 갈아탄다면 Fluent Bit이냐 Vector냐. 두 도구 모두 몇 달씩 붙잡고 굴려봤기 때문에 이 참에 정리해두려고 한다.

결론부터 말하면 "무조건 이거"는 없다. 다만 우리 팀이 어떤 상황에서 뭘 골랐는지, 왜 그랬는지는 명확하게 얘기할 수 있다.

두 도구를 다시 보자

Fluent Bit은 C로 짜였고 CNCF 공식 프로젝트다. Kubernetes 생태계 안에서는 사실상 표준처럼 자리잡은 지 오래다. 바이너리 크기 작고, 메모리 몇십 MB로 노드마다 DaemonSet으로 깔아둬도 티가 안 난다. Kubernetes metadata filter가 안정적이고, tail input의 상태 관리(chunk, position 파일)도 오래 다듬어져서 노드 재시작 시나리오에서 로그 유실이 거의 없다.

Vector는 Rust로 짜였고 Datadog이 인수한 뒤로 개발 속도가 빨라졌다. 특징은 VRL(Vector Remap Language)이다. transform 파이프라인을 이 DSL 하나로 다 처리한다. 파싱, 리다이렉트, 마스킹, 라우팅까지 config 안에서 스크립트처럼 쓴다. 최근 VictoriaMetrics가 2026년 초에 낸 Kubernetes 로그 수집기 벤치마크에서도 Vector가 처리량 상단에 있었다.

숫자만 놓고 보면 Vector가 대체끜 우세하다. 하지만 실제 도입 결정은 숫자만으로 안 된다.

어디서 갈리나

우리 팀이 실제로 부딪혔던 지점을 몇 개 뽑아본다.

첫째, transform이 얼마나 복잡한가.

로그 필드 정제, PII 마스킹, 특정 조건으로 sink 분기 같은 걸 config에서 처리해야 한다면 Vector의 VRL이 훨씬 편하다. Fluent Bit도 Lua filter로 비슷하게 되긴 하는데, 팀원 누가 실수로 무한 루프 하나 심어놓으면 노드 CPU가 튄다. VRL은 컴파일 타임에 문법 검증하고 실행 모델이 제한돼 있어서 이런 사고가 덜 난다.

반대로 transform이 거의 없고 "그냥 노드 로그 파일 → 중앙 저장소"에 가까우면 Fluent Bit 쪽이 config가 훨씬 짧고 읽기 쉽다.

둘째, 리소스 제약이 얼마나 빡빡한가.

엣지에 가까운 워크로드나 GPU 노드처럼 CPU/메모리 아까운 노드에는 Fluent Bit이 여전히 더 어울린다. 우리 클러스터 중 GPU 노드에서 Vector를 돌려봤는데, 부하 자체는 문제없었지만 워크로드 스케줄러 관점에서 예약분을 늘려야 했다. Fluent Bit이면 그 예약분이 반 정도로 줄어든다.

셋째, sink 다양성.

Vector가 sink 종류가 훨씬 많다. Fluent Bit도 요즘 output plugin이 많이 늘긴 했는데, 예를 들어 ClickHouse에 직접 쓰거나, Loki + S3에 동시에 쓰면서 서로 다른 인코딩을 쓰거나 하는 조합은 Vector에서 config 몇 줄로 끝난다.

넷째, 관측성 자체의 관측성.

Vector가 자기 자신 상태를 노출하는 방식이 훨씬 잘 돼있다. vector top 같은 로컬 진단 커맨드도 있고, 컴포넌트별 지연/에러/버퍼 사용률이 Prometheus 형식으로 자연스럽게 나온다. Fluent Bit도 metrics endpoint가 있지만 컴포넌트 세분화가 상대적으로 얕다. 파이프라인 규모가 커질수록 이 차이가 운영에서 크게 느껴진다.

우리 팀은 어떻게 갈랐나

지금 우리는 노드에는 Fluent Bit, 집계 계층에는 Vector를 두는 구조로 굴러가고 있다. 요즘 커뮤니티에서도 이 조합을 꽤 많이 밀고 있는데, 실제로 써보니 이유가 있었다.

노드에서 로그를 뽑아내는 일은 단순하다. tail, kubernetes metadata, 대충 정리한 뒤 다음 홉으로 넘기는 것. 이 단계에서는 리소스 아끼는 게 최우선이라 Fluent Bit이 맞다. 그리고 노드 수가 수백 대인 상황에서 각 노드마다 복잡한 transform 돌리는 것 자체가 운영 리스크다.

반면 집계 계층은 노드 몇 대짜리 별도 워크로드로 격리돼 있고, 여기서 라우팅, 마스킹, 다중 sink 분기 같은 걸 다 처리한다. 이 지점에서는 VRL의 표현력이 그대로 이득으로 돌아온다. 특히 요즘 팀 요구사항으로 "특정 서비스 로그는 Loki, 특정 audit 성 로그는 S3에 즉시 archival, 일부는 SIEM로 실시간 전송" 같은 게 계속 늘고 있는데, 이걸 Fluent Bit만으로 커버하려고 하면 config가 금방 관리 불가능해진다.

그럼 하나만 골라야 한다면

정말로 하나만 골라야 한다면 나는 아직도 상황을 물어본다.

• 신규 팀, 파이프라인 처음부터 짜는 중, Kubernetes 위주 → 나는 Vector를 먼저 권한다. Fluent Bit 대비 학습 곡선은 있지만, 몇 달 지나면 VRL 하나로 얻는 표현력이 그 비용을 넘어선다.
• 이미 Fluent Bit이 잘 굴러가고 있고, 특별한 불만 없음 → 억지로 갈아탈 이유 없다. 특히 transform이 거의 없는 파이프라인이면 Vector로 옮겨봐야 얻을 게 별로 없다.
• Fluentd에서 벗어나려는 팀 → 노드 쪽만 Fluent Bit으로 옮기는 것부터 시작하는 게 안전하다. 집계는 Fluentd 그대로 두다가 나중에 Vector로 옮겨도 늦지 않다.

아직 확신이 없는 부분

Vector가 Datadog 인수 후에도 오픈소스 로드맵을 잘 유지하고 있긴 한데, 몇 년 뒤에도 이 방향이 유지될지는 솔직히 조심스럽게 지켜봐야 한다. Fluent Bit은 CNCF Graduated 프로젝트라 이런 걱정은 덜하다. 벤더 종속 관점에서 파이프라인 전면을 Vector로 몰아가는 게 정말 맞는지, 특히 규제 산업이라면 한 번 더 생각해볼 만하다.

혹시 이 조합 말고 다르게 굴리는 분 계시면 어떻게 나눴는지 궁금하다.

태그: DevOps, Kubernetes, 로그수집, FluentBit, Vector, 관측성