팀 내 전처리 프레임워크 dagster 도입기

채널톡 AI팀이 상담 에이전트 ALF의 RAG 문서 전처리 파이프라인을 FastAPI background tasks에서 dagster로 옮긴 과정이다. 초기에는 트래픽이 적어 문제가 없었지만 고객사가 늘면서 같은 인스턴스에서 여러 문서를 동시에 처리하다 타임아웃이 나거나 OOM으로 파드가 죽었다. 워크플로우 오케스트레이션 도구 넷을 비교한 뒤 dagster를 골랐고, 지금은 하루 1만 건이 넘는 무거운 전처리 요청을 별 이슈 없이 처리한다.

핵심 포인트

파드가 죽으면 처리 중인 모든 요청이 함께 취소되면서 불필요한 재시도 요청까지 늘어났다.
같은 파일이 어떤 때는 처리되고 어떤 때는 리소스 경합으로 실패해, 고객이 문서가 준비되는 시간을 예측할 수 없었다.
문제가 생기면 로깅 메시지를 뒤져 지점을 찾아야 했고 메시지가 없으면 로직을 추가해야 했으며, 찾아도 그 지점부터 재시도할 수 없어 처음부터 다시 해야 했다.
Airflow는 배치 특화라 이벤트 기반 구조와 안 맞았고, Temporal은 액티비티 간 페이로드 크기 제한이 큰 데이터를 주고받는 워크플로우와 안 맞았다.
Prefect는 러닝커브가 짧아 만족스러웠지만 OSS에서 RBAC을 지원하지 않아 대시보드 접근자가 워크플로우를 삭제할 위험이 있었다.

상세 정리

배경: ALF의 강점 중 하나가 고객사의 사내 규정·제품 매뉴얼·FAQ 같은 자체 지식을 활용해 답변하는 기능이고, 이를 위해 PDF·엑셀·웹사이트 등 다양한 형식을 LLM이 이해할 수 있는 형태로 저장하는 과정이 필수다.
파이프라인 흐름: 다양한 포맷에서 텍스트와 메타데이터를 읽고, 모델이 효율적으로 찾을 수 있도록 적절한 크기로 분할하고, 의미론적 검색을 위해 벡터로 변환해 벡터 DB에 저장한다.
초기 구조: FastAPI가 요청을 받아 메타데이터와 함께 background tasks에 추가하고, 백그라운드로 실행한 뒤 결과를 웹훅으로 알리는 형태였다.
dagster 선택 이유: 에셋이라는 데이터 자산 중심의 DAG 표현 방식이 문서 전처리 워크플로우와 맞았고, Prefect처럼 RBAC은 없지만 코드 로케이션 형태로 워크플로우 코드가 분리돼 있어 대시보드에서 삭제될 위험이 상대적으로 적었다.
비교표에서 짚은 각 도구의 단점: Airflow는 무겁고 복잡한 설정에 로컬 테스트가 어렵고 XCom으로 데이터를 주고받기 불편하며, dagster는 Op·Asset 같은 새 개념의 학습 곡선과 장황해질 수 있는 코드, Prefect는 1.0과 2.0 사이 호환성 이슈 이력과 대규모에서의 유료 모델, Temporal은 가장 높은 학습 난이도와 별도 클러스터 운영 복잡도를 든다.
새 구조: FastAPI 서버가 게이트웨이 역할을 해 외부 클라이언트가 dagster를 알 필요 없이 전처리 요청만 보내게 하고, 내부에서 dagster 서버로 실행 요청을 보낸 뒤 실행이 끝나면 dagster hook으로 결과를 보낸다.
실행 격리: 사내 인프라가 쿠버네티스 기반이라 K8sRunLauncher로 지정해 워크플로우 실행마다 별도 파드를 생성한다. 특정 문서가 문제를 일으켜도 그 문서만 실패하고 다른 처리에는 영향이 없다.
더 세밀한 격리가 필요하면 k8s_job_executor로 워크플로우 안의 각 에셋을 별도 파드에서 실행할 수 있다. 현재는 실행 단위 격리로 충분해 쓰지 않지만 확장을 고려해 검토 중이다.
dagster 구성: 대시보드 UI와 실행 요청을 받는 GraphQL API를 제공하는 webserver, 스케줄·센서·Run Queue를 관리하며 큐 작업을 워커에 할당하는 daemon, 실제 워크플로우 코드가 정의된 code location으로 나뉜다.
배포 전략: 상대적으로 수정이 적은 webserver와 daemon은 Helm Chart로 배포하고, 잦은 변경으로 업데이트 주기가 짧은 code location은 별도 애플리케이션으로 분리해 머지 시 GitHub Actions CI/CD로 그것만 새로 배포되게 했다.
이 분리 덕에 팀원들이 dagster 인프라 배경 없이 워크플로우 개발에만 집중할 수 있는 환경이 됐다.
기존 대응의 한계: 리소스 문제가 생길 때마다 인스턴스 스펙을 늘리는 scale-up으로 대응해 고정 비용은 오르면서도 근본 원인은 해결되지 않아 언제든 재발할 수 있었다.
안정성 확보 근거 셋: 실행 단위로 파드가 따로 떠 리소스 경합 자체가 없고, 요청이 몰려도 내부 큐에 쌓아 처리하므로 한 파드가 죽어도 다른 작업에 영향이 없으며, 스펙이 부족하면 해당 작업의 리소스 할당치만 늘리면 돼 자원 낭비가 적다.
특히 문서 크기나 포맷에 따라 리소스 할당을 유동적으로 조절할 수 있으면 대량 요청에서 비용을 크게 절약할 수 있다는 점을 이점으로 꼽는다.
관측성: 로그 메시지에만 의존하던 디버깅에서 벗어나 대시보드로 단일 또는 전체 워크플로우의 진행 상황을 한눈에 보고 각 스텝별 소요 시간과 메타데이터까지 추적할 수 있게 됐다.
남은 고민: OSS에서 RBAC이 없어 접근 권한을 세밀하게 제어하기 어렵다. 현재는 SSO로 관련 작업자만 대시보드에 접근하게 하는 최소한의 방어 장치를 뒀지만, 팀 규모가 커지거나 다른 팀으로 확장하면 권한 관리에 심도 있는 고민이 필요하다고 밝힌다. 이 선택이 최선이었는지도 더 고민해볼 문제라고 덧붙인다.