DATABASE

시계열 데이터베이스 InfluxDB 활용 가이드

junetapa 2026. 2. 18 업데이트 2026. 6. 6 12 min read

InfluxDB는 시계열 DB 부문에서 오랫동안 대표격으로 꼽혀온 오픈소스 솔루션이다. 2025년 4월 정식 출시된 InfluxDB 3는 엔진을 Rust로 다시 쓰고 Apache Arrow 기반 컬럼 저장으로 갈아엎으면서, 쿼리 언어의 중심도 Flux에서 표준 SQL로 옮겨갔다. 설치부터 데이터 입력, 쿼리, 그리고 TimescaleDB·Prometheus와의 비교까지 2026년 6월 기준으로 정리했다.

2026년 6월 업데이트

이 글은 InfluxDB 3 정식 출시 이후 상황을 반영해 갱신했다. 핵심 변화는 다음과 같다.

1. InfluxDB 3는 엔진을 Rust로 재작성하고 Apache Arrow·DataFusion·Parquet·Flight(FDAP) 스택 위에 올라간다. 2. 무료 오픈소스 Core와 고가용성·압축 컴팩터를 갖춘 Enterprise로 라인업이 나뉘며, Enterprise는 가정용·비상업 용도에 한해 무료로 제공된다. 3. 기본 쿼리 언어가 SQL로 바뀌었고 InfluxQL도 지원된다. 반면 Flux는 유지보수 모드로 전환되어 3.x에서는 동작하지 않는다. 4. 2026년 5월 27일부터 Docker influxdb:latest 태그가 InfluxDB 3 Core를 가리킨다.

시계열 데이터베이스란? InfluxDB를 선택한 이유

시계열 데이터의 특성

시계열 데이터는 말 그대로 시간 순서대로 기록되는 데이터다. 서버 CPU 사용률, IoT 센서 온도, 주식 가격, 웹사이트 트래픽 등이 대표적이다. 이런 데이터에는 한 가지 공통점이 있다. 한번 기록되면 거의 수정되지 않고, 시간이 지날수록 개별 포인트의 중요도가 점차 낮아진다는 점이다. 그래서 최근 데이터는 빠르게 조회하고, 오래된 데이터는 압축하거나 요약해 보관하는 전략이 잘 통한다.

기존 관계형 데이터베이스(MySQL, PostgreSQL)로도 시계열 데이터를 저장할 수 있다. 하지만 초당 수천에서 수만 건이 쏟아지는 환경에서는 쓰기 성능과 스토리지 효율이 심각한 병목이 된다. 실제로 IoT 프로젝트에서 PostgreSQL로 센서 데이터를 그대로 적재했을 때, 누적 데이터가 1억 건을 넘어가자 집계 쿼리 하나에 30초 이상 걸리기 시작했다. 인덱스를 손보고 파티셔닝을 적용해도 한계가 분명했고, 결국 전용 시계열 엔진으로 넘어가는 계기가 됐다.

왜 InfluxDB인가

InfluxDB는 시계열 DB 중에서도 가장 널리 쓰이는 오픈소스 솔루션이다. DB-Engines의 시계열 데이터베이스 부문에서 오랫동안 선두권을 지켜왔고, 커뮤니티와 문서가 두텁다. 2025년 4월 정식 출시된 InfluxDB 3는 엔진을 Rust로 다시 작성하고 Apache Arrow 기반 컬럼 포맷을 채택하면서 한 단계 더 도약했다. 이 글에서 InfluxDB를 택한 이유는 세 가지다.

  • 높은 쓰기 처리량: 초당 수십만에서 수백만 포인트까지 적재할 수 있다. IoT나 대규모 모니터링 환경에서 이 처리량은 결정적이다.
  • 컬럼 기반 압축: InfluxDB 3는 데이터를 Parquet 파일로 저장한다. 컬럼 포맷 특성상 같은 컬럼의 값이 모여 압축률이 높고, 분석 쿼리도 필요한 컬럼만 스캔해 빠르다. (2.x는 TSM 엔진을 사용했다.)
  • 표준 SQL 지원: InfluxDB 3부터 SQL이 1차 쿼리 언어가 됐다. 기존 SQL 지식을 거의 그대로 쓸 수 있어 진입 장벽이 크게 낮아졌다. InfluxQL도 함께 지원된다.

InfluxDB 설치부터 첫 번째 데이터 입력까지

설치 방법 (InfluxDB 3 Core 기준)

InfluxDB 3는 Docker로 띄우는 게 가장 간편하다. 2026년 5월 27일부터 latest 태그가 InfluxDB 3 Core를 가리키므로, 버전을 못 박지 않으면 자동으로 3.x가 받아진다. 의도를 분명히 하려면 태그를 고정해 두는 편이 안전하다.

bash — InfluxDB 3 Core 실행 docker run -d --name influxdb3 -p 8181:8181 \
  -v $PWD/influxdb3-data:/var/lib/influxdb3 \
  influxdb:3-core \
  influxdb3 serve --node-id node0 \
  --object-store file --data-dir /var/lib/influxdb3

InfluxDB 3는 HTTP API 포트로 8181을 쓴다. (2.x의 8086과 다르다.) 서버가 뜨면 토큰을 먼저 만든다. 이후 모든 쓰기·쿼리 요청에 이 토큰을 Bearer 인증으로 붙인다.

bash — 관리 토큰 생성 docker exec influxdb3 influxdb3 create token --admin

참고로 가정용·비상업 용도라면 고가용성과 압축 컴팩터를 갖춘 Enterprise를 무료로 쓸 수 있다. 이미지 태그만 influxdb:3-enterprise로 바꾸고 라이선스 이메일을 등록하면 된다.

Line Protocol로 데이터 쓰기

InfluxDB에 데이터를 입력하는 기본 형식은 여전히 Line Protocol이다. 이 부분은 버전이 바뀌어도 그대로다. 구조는 다음과 같다.

measurement,tag_key=tag_value field_key=field_value timestamp

실제 예시를 보면 훨씬 이해가 빠르다. CLI로 한 줄을 그대로 적재해 보자.

bash — Line Protocol 쓰기 docker exec influxdb3 influxdb3 write \
  --database iot \
  --token YOUR_ADMIN_TOKEN \
  'temperature,location=seoul,device=sensor01 value=23.5'

여기서 temperature는 측정 항목(테이블명과 비슷), locationdevice는 태그(인덱싱되는 메타데이터), value는 실제 필드값이다. 타임스탬프를 생략하면 서버가 수신 시각을 나노초 단위로 자동 부여한다. 직접 지정하려면 줄 끝에 나노초 Unix 타임스탬프를 붙이면 된다. InfluxDB 3에서는 데이터베이스가 곧 버킷·테이블의 상위 개념이며, 처음 쓰는 데이터베이스는 자동으로 생성된다.

Python 클라이언트로 자동 수집하기

실무에서는 클라이언트 라이브러리를 쓴다. InfluxDB 3 전용 Python 클라이언트(influxdb3-python)는 내부적으로 Arrow Flight를 사용해 쓰기와 쿼리를 모두 처리한다.

bash pip install influxdb3-python
python — IoT 센서 데이터 배치 적재 from influxdb_client_3 import InfluxDBClient3, Point

client = InfluxDBClient3(
    host="http://localhost:8181",
    token="YOUR_ADMIN_TOKEN",
    database="iot",
)

points = [
    Point("temperature")
      .tag("location", "seoul")
      .tag("device", f"sensor{i:02d}")
      .field("value", 23.0 + i * 0.1)
    for i in range(100)
]

client.write(points)  # 100개 포인트를 한 번에 배치 전송
client.close()

배치로 모아 보내면 네트워크 왕복이 줄어 수백 대의 디바이스에서 동시에 데이터가 들어와도 안정적으로 처리된다. 운영 환경이라면 토큰은 코드에 박지 말고 환경 변수나 시크릿 매니저로 분리하는 것이 기본이다.

InfluxQL과 SQL, 그리고 저물어가는 Flux

쿼리 언어 지형이 바뀌었다

InfluxDB 2.x 시절의 주력 쿼리 언어는 함수형 스크립트 Flux였다. 그런데 InfluxDB 3로 넘어오면서 무게중심이 완전히 이동했다. 공식 입장은 명확하다. Flux는 유지보수 모드로 전환됐고, InfluxDB 3 제품군에서는 동작하지 않는다. 1.x·2.x에서는 기존 Flux 코드를 그대로 계속 쓸 수 있지만, 3로 마이그레이션하면 Flux 태스크는 SQL이나 외부 도구로 다시 작성해야 한다.

대신 InfluxDB 3는 표준 SQL을 1차 언어로 삼고, 익숙한 InfluxQL도 함께 지원한다. SQL 실행은 Apache DataFusion 엔진이, 결과 전송은 Arrow Flight SQL이 담당한다. 즉, 이미 SQL을 아는 사람이라면 별도 학습 없이 곧장 시계열 데이터를 다룰 수 있다.

SQL로 다운샘플링하기

1분 단위 원본을 1시간 평균으로 요약하는 다운샘플링은 시계열 운영의 기본기다. InfluxDB 3에서는 표준 SQL의 시간 함수로 깔끔하게 표현된다.

sql — 1시간 단위 평균 다운샘플링 SELECT
  date_bin(INTERVAL '1 hour', time) AS bucket,
  location,
  avg(value) AS avg_temp
FROM temperature
WHERE time >= now() - INTERVAL '7 days'
GROUP BY bucket, location
ORDER BY bucket

date_bin으로 시간 축을 일정 간격의 버킷으로 자르고, 그 안에서 평균을 집계하는 흐름이다. PostgreSQL을 써봤다면 거의 동일한 문법이라 곧바로 손에 익는다.

Grafana 연동

대시보드는 여전히 Grafana 조합이 가장 무난하다. Grafana는 InfluxDB 데이터소스를 공식 지원하며, InfluxDB 3에서는 SQL(FlightSQL) 또는 InfluxQL로 질의하도록 설정할 수 있다. 데이터소스에 호스트(8181 포트), 토큰, 데이터베이스명을 넣고 위의 다운샘플링 SQL을 패널 쿼리로 붙이면 시계열 그래프가 바로 그려진다.

InfluxDB vs TimescaleDB vs Prometheus

시계열 DB를 고를 때 가장 자주 비교되는 세 가지다. 정답은 없고, 워크로드 성격에 따라 갈린다.

항목InfluxDB 3TimescaleDBPrometheus
기반Rust · Apache ArrowPostgreSQL 확장자체 TSDB
쿼리 언어SQL · InfluxQL표준 SQLPromQL
데이터 수집Push (쓰기 API)Push (INSERT)Pull (스크레이핑)
강점고처리량 쓰기, IoT·장기 보관관계형 데이터와 조인, 복합 분석경량 모니터링·알림
고카디널리티양호매우 강함부담
선택 가이드

IoT 텔레메트리와 장기 보관이 핵심이고 쓰기 처리량이 관건이라면 InfluxDB 3가 잘 맞는다.

시계열을 기존 관계형 테이블과 조인해 복합 분석을 돌려야 하고 PostgreSQL 생태계를 그대로 쓰고 싶다면 TimescaleDB가 유리하다. 고카디널리티(디바이스 수가 매우 많은) 환경에서도 강하다.

쿠버네티스·서버 운영 메트릭 모니터링과 알림이 목적이고 보관 기간이 짧다면 Prometheus가 가장 가볍고 운영 부담이 적다.

마무리: 2026년의 InfluxDB

InfluxDB 3는 단순한 버전 업이 아니라 엔진을 통째로 다시 쓴 세대 교체에 가깝다. Rust와 Apache Arrow 기반으로 컬럼 저장·압축·분석 성능을 끌어올렸고, 쿼리 언어를 표준 SQL 중심으로 재편해 진입 장벽을 크게 낮췄다. 무료 Core와 가정용 무료 Enterprise라는 선택지가 생긴 것도 개인 개발자에게는 반가운 변화다.

한편 2.x에서 Flux로 짠 태스크가 많다면 3로의 이전은 곧 쿼리·태스크 재작성을 의미한다는 점을 미리 염두에 둬야 한다. 운영 중인 2.x 환경을 당장 갈아엎을 필요는 없지만, 새로 시작하는 시계열 프로젝트라면 SQL 기반의 InfluxDB 3에서 출발하는 편이 장기적으로 합리적이다. 데이터의 성격, 카디널리티, 보관 정책을 먼저 따져보고 InfluxDB·TimescaleDB·Prometheus 중에서 골라보자.

InfluxDB 시계열 DB IoT Flux Grafana 모니터링
junetapa
junetapa
AI 도구를 직접 써보고 솔직한 경험을 공유하는 개발자.
Twitter Facebook URL 복사