핵심 내용
GeekNews 최신 글에서 새로 올라온 개발도구 가운데 Filament를 원본 GitHub 저장소까지 확인했다. Filament는 Go 기반의 pluggable data replication engine으로, 데이터베이스·SaaS 등 source의 데이터를 다른 database, warehouse, object storage 등 sink로 옮길 때 full replication, incremental replication, CDC(change data capture)를 지원한다.
프로젝트가 강조하는 차별점은 단순 데이터 이동보다 checkpointing, batching, integrity event를 기본 설계로 둔 것이다. 데이터를 bounded batch로 읽어 sink에 쓴 뒤 양쪽에서 batch를 검증하고, 성공했을 때만 durable checkpoint를 기록해 장애가 발생해도 마지막 성공 지점부터 안전하게 재개할 수 있다. source, sink, state storage, event transport는 교체 가능한 interface로 설계돼 있고, 별도 서비스·API·Web UI 형태로 배포하거나 Go 애플리케이션에 engine을 직접 embed할 수도 있다.
프로젝트 문서는 production 환경에서는 Kubernetes와 Helm 배포를 권장하며, 기본 구조에서는 PostgreSQL을 durable state store, NATS JetStream을 event transport로 사용할 수 있다고 설명한다. 아직 대규모 상용환경에서의 독립적인 안정성 데이터는 충분히 축적되지 않았으므로 기존 Debezium, Airbyte, Kafka Connect 같은 도구를 즉시 대체한다고 보기보다 새로운 설계대안으로 평가하는 편이 적절하다.
배경
Agent·AI SaaS가 늘수록 운영 DB, CRM, 결제, 분석warehouse, vector store 사이에 같은 데이터를 지속적으로 옮겨야 하는 요구도 커진다. 단순 ETL보다 실시간 CDC와 재시작 가능성, 중복쓰기 방지, 데이터 무결성을 코드 수준에서 명확히 다루는 것이 중요해지고 있다. 특히 Agent가 source와 sink 양쪽을 수정하는 환경에서는 데이터 이동 실패가 곧 자동화 오류로 이어질 수 있다.
산업·시장에 미치는 영향
데이터 파이프라인 시장은 관리형 SaaS와 대규모 Kafka 중심 stack 사이에 self-host 가능한 경량 replication engine 수요가 커지고 있다. Filament처럼 state와 event transport를 교체할 수 있는 구조는 민감데이터를 외부 SaaS로 보내기 어려운 기업이나 작은 팀에 매력적일 수 있다. 다만 connector 범위와 schema evolution, exactly-once semantics, 장애복구 품질이 실제 경쟁력을 결정한다.
실무에서 바로 활용할 수 있는 시사점
PostgreSQL 등 운영 DB에서 warehouse나 별도 AI 데이터계층으로 변경분을 복제해야 한다면 작은 테이블부터 POC해볼 가치가 있다. 테스트에서는 정상 throughput보다 중간 장애 후 resume, 중복 이벤트, schema change, sink write 실패, checkpoint 손상 같은 실패 시나리오를 먼저 검증해야 한다. 기존 pipeline을 전면 교체하기보다 비핵심 데이터 동기화부터 shadow run으로 비교하는 것이 안전하다.