개인 프로젝트 진행 중

창고 로봇(AMR) 텔레메트리 실시간 데이터 파이프라인

Personal Data Engineering Project · 2026 · 1명 · 4 min read 읽기

Kiva 계열 창고 자동화 로봇의 위치·배터리·작업 이벤트를 합성 데이터로 생성해, 데이터 특성별로 Kafka Topic·저장소·acks 전략을 다르게 설계하고 Grafana로 Fleet 운영 지표를 모니터링하는 파이프라인을 설계·구축 중인 개인 프로젝트입니다.

Overview

창고 내 AMR(자율이동로봇) 10대가 Pod(이동식 선반)를 들어올려 피킹 스테이션으로 운반하는 시나리오를 합성 데이터 생성기로 시뮬레이션하고, 이 데이터를 Kafka 기반 파이프라인으로 수집·적재·모니터링합니다. 위치·배터리·작업 이벤트라는 세 가지 데이터가 서로 다른 특성(빈도, 유실 허용도)을 갖는다는 점에 착안해, Topic 분리부터 저장소 선택까지 하나의 일관된 설계 기준으로 구성했습니다.

System Architecture

창고 로봇 텔레메트리 파이프라인 구성도 — 로봇 on-board Producer → Zookeeper/Kafka 클러스터 → Consumer → ELK/Burrow (점진적으로 업데이트 예정)
창고 로봇 텔레메트리 파이프라인 구성도 — 로봇 on-board Producer → Zookeeper/Kafka 클러스터 → Consumer → ELK/Burrow (점진적으로 업데이트 예정)

Constraints

  • 실제 물류 자동화 로봇(Kiva 계열) 하드웨어 없이, 합성 데이터 생성기로 현실적인 텔레메트리를 만들어야 함
  • 위치(고빈도·유실 허용) / 배터리(중빈도) / 작업 이벤트(저빈도·유실 불가)라는 서로 다른 데이터 특성을 하나의 파이프라인 안에서 각각에 맞게 처리해야 함
  • GPU 기반 로봇 시뮬레이터(Isaac Sim) 대신 가벼운 방식으로 대체하되, 도메인 신뢰도는 유지해야 함
  • 배포 인프라를 처음부터 K8s로 시작하지 않고, 학습 중인 K3s·K8s 개념을 단계적으로 반영해야 함

Tech Stack

  • Apache Kafka (Docker, 3 broker)
  • Python (합성 데이터 생성기 — 확률 모델 기반 로봇 상태 시뮬레이션)
  • TimescaleDB (PostgreSQL 확장 — 위치·배터리 시계열 데이터)
  • Elasticsearch (작업 이벤트 데이터)
  • Grafana (Fleet 가동률, Consumer Lag, 병목 구간 모니터링)
  • K3s → Kubernetes (단계적 배포 확장)
  • Apache Airflow (일일 집계 배치 — 확장 예정)
  • GitLab CI/CD

Learnings

  • 이 프로젝트는 4년 전 개인 학습 프로젝트(Kafka+ELK+Grafana, Twitter 데이터 기반)에서 겪었던 교훈 — 특히 Docker 멀티 브로커 환경에서 KAFKA_ADVERTISED_HOST_NAME을 localhost로 두면 안 된다는 것, acks=1과 acks=-1의 트레이드오프 — 을 이어받아, 이번에는 도메인과 설계 판단 자체를 중심에 두고 재구성한 결과입니다.
  • 실무 시뮬레이터(Isaac Sim)가 항상 정답은 아니라는 것을 확인했습니다. 지원 직무가 실제로 평가하는 지점이 무엇인지 먼저 판단하고, 거기에 맞춰 도구를 가볍게 대체하는 결정도 엔지니어링 판단의 일부라고 생각합니다.
  • Kafka Topic 설계를 '몇 개로 나눌까'가 아니라 '데이터가 유실되면 어떤 일이 생기는가'를 기준으로 접근하니, acks·저장소·retention 같은 이후의 모든 결정이 하나의 논리로 자연스럽게 이어졌습니다.

Problem

이전 Kafka+ELK+Grafana 프로젝트(2022)는 Twitter API 로그를 소재로 Kafka 클러스터의 고가용성·Consumer Lag 모니터링 구조를 검증하는 데 집중했습니다. 이번에는 지원 중인 데이터 엔지니어 직무(물류 자동화)와 도메인을 맞추면서, 단일 Topic에 모든 데이터를 밀어넣던 이전 방식에서 벗어나 '데이터 특성에 따라 파이프라인 설계를 어떻게 다르게 가져가야 하는가'라는 질문에 집중하고자 했습니다.

Approach

(1) 도메인 모델링. Kiva 계열 Pod 리트리버 로봇의 실제 동작(IDLE → MOVING_TO_POD → LIFTING → MOVING_TO_STATION → WAITING_AT_STATION → RETURNING)을 상태 머신으로 정의하고, 로봇이 아닌 사람이 스테이션에서 실제 피킹을 수행한다는 점을 데이터 설계에 반영했습니다. (2) Kafka Topic 설계. 위치(robot.position)·배터리(robot.battery)·작업 이벤트(task.events) 3개 Topic으로 분리하고, 데이터 특성에 따라 파티션 수·acks·retention을 각각 다르게 설정했습니다. 특히 task.events만 acks=all + min.insync.replicas=2로 구성해 유실 불가 데이터에 대한 안전장치를 별도로 두었습니다. (3) 저장소 이원화. 시계열 데이터(위치·배터리)는 TimescaleDB, 이벤트 데이터(작업 이벤트)는 Elasticsearch로 나눠 적재해, Topic 분리 논리를 저장소 계층까지 일관되게 연장했습니다. (4) 스키마 및 배포 전략 단계화. 스키마는 JSON으로 먼저 구축한 뒤 Avro+Schema Registry로 확장하고, 배포는 Docker Compose → K3s → K8s(표준) 순서로 인프라 성숙도를 단계적으로 높여가는 방식을 채택했습니다.

Key Decisions

Isaac Sim 대신 자체 합성 데이터 생성기 채택

Reasoning:

Isaac Sim은 RTX GPU(VRAM 16GB 이상)가 필수라 로컬 Mac 환경에서 실행이 불가능했고, 클라우드 GPU로 우회하더라도 로보틱스 시뮬레이터 자체를 학습하는 데 상당한 시간이 소요됩니다. 지원 직무(Data Engineer)에서 실제로 평가받는 지점은 시뮬레이터 완성도가 아니라 파이프라인 설계 판단력이라고 보고, 확률 모델 기반 합성 데이터 생성으로 방향을 바꿔 그 시간을 Kafka·저장소·스키마 설계에 재투자했습니다.

Alternatives considered:
  • 클라우드 GPU(RunPod 등)로 Isaac Sim 그대로 사용
  • PyBullet 등 경량 물리 시뮬레이터로 대체

데이터 특성별 Kafka Topic 분리 및 acks 차등 적용

Reasoning:

위치 데이터는 고빈도이고 유실돼도 다음 값으로 금방 보정되지만, 작업 이벤트(사람 피킹 완료 등)가 유실되면 실제 물류에서 재고·배송 상태 불일치로 이어집니다. 모든 Topic을 동일한 안전장치로 다루면 불필요한 지연이 쌓이거나 반대로 중요한 데이터가 위험에 노출되므로, task.events에만 acks=all + min.insync.replicas=2를 적용하고 나머지는 acks=1로 처리량을 우선했습니다.

Alternatives considered:
  • 모든 Topic에 acks=all 일괄 적용
  • 단일 Topic에 이벤트 타입 필드만 구분해 저장

저장소를 TimescaleDB(시계열)와 Elasticsearch(이벤트)로 이원화

Reasoning:

이전 프로젝트에서 익힌 ELK 스택을 그대로 재사용할 수도 있었지만, 위치·배터리처럼 연속적으로 변화하는 시계열 데이터에는 시간 기반 파티셔닝·압축에 강한 TimescaleDB가 더 적합하다고 판단했습니다. Topic을 데이터 특성별로 나눈 논리를 저장소 선택까지 동일하게 연장해, 파이프라인 전체가 하나의 설계 기준으로 일관되게 이어지도록 구성했습니다.

Alternatives considered:
  • Elasticsearch 단일 스택으로 통일 (기존 프로젝트 스택 재사용)
  • 모든 데이터를 TimescaleDB로 통일

배포 인프라를 Docker Compose → K3s → K8s 순서로 단계화

Reasoning:

처음부터 표준 K8s로 시작하면 학습 곡선과 프로젝트 완성 시점이 함께 뒤로 밀립니다. 먼저 Docker Compose로 파이프라인 자체를 완성해 핵심 로직(Producer, Topic 설계, Consumer)을 빠르게 검증하고, 이후 K3s로 오브젝트 단위 배포를 익히며, 마지막에 표준 K8s로 확장하는 단계를 프로젝트 안에 그대로 남겨 인프라가 성장하는 과정 자체를 결과물로 삼기로 했습니다.

Alternatives considered:
  • 처음부터 표준 K8s(kubeadm)로 구축
  • K8s 없이 Docker Compose로만 완결

Result & Impact

  • Topic 3개 분리, 저장소 이원화, 스키마·배포 전략까지 전체 아키텍처 확정
    설계 단계 완료
  • Kiva 계열 실제 로봇 동작(Pod 리트리버) 기준으로 상태 머신·이벤트 스키마 재설계
    도메인 정합성 검증

아직 구현 전 설계 단계이며, 현재는 '왜 이렇게 설계했는가'라는 판단 근거를 먼저 확정하는 데 집중했습니다. 구현이 진행되면 실제 처리량, Consumer Lag 발생 시나리오, 저장소별 조회 성능 등 정량 결과를 이 섹션에 추가할 예정입니다.

전체 프로젝트
100%