DataFlow-Harness
편집 가능한 LLM 데이터 파이프라인을 구축하는
접지형(Grounded) 코드 에이전트 플랫폼

LLM 코딩 에이전트는 자연어 요구사항을 실행 가능한 구현으로 자동 변환하는 수준에 도달했다. 그러나 산업 환경에서 높은 태스크 정확도만으로는 프로덕션 배포에 불충분하다.

산업 환경의 워크플로 산출물은 전체 생애주기에 걸쳐 가시적(visible)이고, 편집 가능(editable)하며, 재사용 가능(reusable)하고, 플랫폼 거버넌스 메커니즘과 호환되어야 한다. 반면 직접 코드 생성 에이전트는 소스 코드 형태로만 존재하는 일회용 스크립트를 생산하는 경향이 있다. 이 산출물은 그래픽 워크플로 인터페이스로 감사(audit)하기 어렵고, 사용 불가능한 오퍼레이터·낡은 플랫폼 가정·프레임워크 특화 동작에 의존하는 의존성 환각(hallucinated dependency)을 자주 일으킨다.

용어를 명확히 구분한다. 워크플로(workflow)는 의도된 데이터 처리 절차이고, 파이프라인 표현(pipeline representation)은 그 영속적 플랫폼 객체이며, DAG는 실행 의존성을 포착하는 구조다. DataFlow-Harness의 기여는 단순한 NL-to-DAG 생성이 아니라, 살아있는 워크플로 산출물에 대한 플랫폼 접지형 구축과 반복적 편집이다.

관련 연구와의 위치

DataFlow-Harness는 워크플로 합성을 DataFlow-WebUI, MCP Tools Layer, Data Pipeline Backend, DataFlow-Skills의 네 컴포넌트로 조직한다. 운영 생애주기는 대화형·시각적·프로그램적 인터페이스 전반의 단일 진실 원천(source of truth)인 Data Pipeline Backend를 중심으로 회전한다.

3.1 Data Pipeline Backend — 형식적 파이프라인 표현

백엔드는 파이프라인을 5-튜플로 표현하며 워크플로 합성의 권위 있는 진실 원천 역할을 한다.

에이전트는 자유형 코드를 생성하는 대신 타입화된 변이(오퍼레이터 추가/제거, 파라미터 갱신, 간선 연결)로 백엔드와 상호작용한다. 변이는 결과 그래프가 비순환(acyclic)이고 인접 오퍼레이터 스키마가 호환될 때만 커밋된다. 이 검사는 구조적 유효성을 확립할 뿐, 의미적 정확성·엔드포인트 가용성·출력 품질을 그 자체로 보장하지는 않는다.

3.2 DataFlow-WebUI — 동기화된 이중 모달리티

3.4 DataFlow-Skills — 두 종류의 절차적 지식

MCP Tools Layer는 오퍼레이터 메타데이터와 워크플로 상태를 노출하지만, 권장 구축 전략이나 조합 모범 사례를 인코딩하지 않는다. 그 결과 에이전트는 부적절한 오퍼레이터를 선택하거나, 전제 처리 단계를 누락하거나, 구조적으로는 유효하지만 의미적으로 틀린 워크플로를 만들 수 있다. Skills는 이를 해결하기 위해 두 부류의 지식을 주입한다.

요약하면, Skills는 에이전트의 추론을 안내하고 MCP Tools Layer는 실행을 라이브 DataFlow 환경에 접지한다.

에이전트가 제안하든 사용자가 수동으로 편집하든, 모든 파이프라인 변경은 동일한 4단계 프로토콜을 통과한다.

파이프라인 구축 능력을 6개 대표 산업 시나리오(QA 생성, 리뷰 거버넌스, 장문서 처리, 다중 필드 스코어링, 스키마 정규화, 저품질 필터링)에 걸친 12개 태스크 벤치마크로 평가한다. 각 태스크는 자연어 목표, 입력 데이터 샘플, 태스크별 수락 기준을 명세한다.

모든 실험은 추론 모델을 고정하기 위해 Claude Opus 4.7을 기저 LLM으로 사용한다. 에이전트 행동과 LLM 생성의 확률성을 고려하여 각 태스크를 설정마다 10회 실행하며, 방법당 총 120회의 태스크 실행이 이루어진다.

평가 지표

E2E Pass는 생성된 워크플로가 성공적으로 실행되고 태스크별 수락 기준을 만족하는 출력을 산출할 것을 요구한다(합성·구성·실행 정확성·최종 출력 유효성 포괄). 효율 지표로는 토큰 소비량(입출력 총합), 공식 가격 기준 비용, 태스크 제출부터 유효 산출물 생산까지의 생성 지연(wall-clock)을 측정한다.

RQ1 — 워크플로 합성 효과성

바닐라 생성(91.7%)에 실행 컨텍스트를 더하면(Context-Aware CC, 94.2%) 복잡한 데이터 처리에서 절차적 컨텍스트의 중요성이 드러난다. 그러나 두 접근 모두 플랫폼 네이티브 워크플로 추상화와 분리된 모놀리식 스크립트를 산출한다.

스크립트 생성에서 구조화된 DAG 합성으로 전환하면 상당한 난이도가 추가된다. 오퍼레이터 명세만 사용하는 MCP-only는 통과율이 83.3%로 하락하며, 워크플로 제약만으로도 모델에 상당한 추론 부담이 부과됨을 보인다. 이는 명확한 NL2Pipeline 갭의 실증이다. 즉 배포 가능한 워크플로의 직접 생성은 실행 가능한 스크립트 생성보다 실질적으로 어렵다.

RQ2 — 효율과 시스템 비용

Vanilla CC 대비 비용 72.5% 절감($0.950 → $0.261)과 지연 49.9% 감소(190.7s → 95.5s)를 달성하면서 통과율도 더 높다. 효율 우위는 더 강한 Context-Aware CC 베이스라인에 대해서도 유지된다. E2E 성능이 거의 동일함에도 비용 42.8% 절감, 지연 17.6% 감소로 실질적으로 더 유리한 효율–성능 트레이드오프를 보인다.

개선은 주로 낮은 토큰 소비에 의해 견인된다. MCP-only는 Context-Aware CC 대비 입력 토큰을 거의 절반으로 줄이고, DataFlow-Harness는 MCP-only 대비 총 토큰 소비를 25.5% 추가 절감한다. 워크플로 표현이 실행 코드보다 훨씬 압축적이며, 절차 안내가 제약된 오퍼레이터 공간 내 구축을 더욱 간결하게 만든다는 해석이 가능하다.

이질적 교육 문서(장문 교과서, 해설집, 시험 답안지)로부터 QA 쌍을 구축하는 고난도 추출 태스크로 시스템을 추가 평가한다. 이 설정은 (i) 질문–답 간 장거리 의존성, (ii) 그림·표에 대한 시각적 접지 추론, (iii) 국소적 텍스트 연속성을 깨는 고도로 비선형적인 문서 레이아웃 때문에 특히 어렵다.

평가는 FlipVQA-Miner의 설정을 따르며, 추출된 QA 쌍의 정확성을 재는 Precision과 소스 문서에서 추출 가능한 QA 쌍의 회수 비율을 재는 Coverage Rate를 보고한다.

DataFlow-Harness가 정밀도(97.2%)와 커버리지(87.3%) 양쪽에서 우위를 보인다. 절대 개선 폭이 가장 큰 지표는 커버리지로, 이는 프레임워크가 출력을 보수적으로 필터링하는 것이 아니라 더 완전한 워크플로를 구축함을 시사한다. 다만 논문은 이 결과의 일반성 확인에는 반복 실행과 완전히 명세된 어노테이션 프로토콜이 필요하다고 명시한다.

태스크별 10회 독립 시행의 통과 횟수를 분석하면 세 가지 일관된 패턴이 드러난다. Skills의 기여는 균일하지 않고, 암묵적 도메인 지식에 성공이 의존하는 태스크에 집중된다.

종합하면, DataFlow-Skills의 기여는 오퍼레이터 명세만으로 복원하기 어려운 절차 지식의 주입에 있다. 이득은 모호하고 절차적으로 복잡한 태스크에서 가장 크고, 구축이 자명하거나 기저 모델이 병목인 경우 소멸한다. 이 어블레이션은 MCP-only와 전체 시스템의 비교이므로 검증(validation) 컴포넌트의 기여를 별도로 식별하지는 못한다.

거버넌스 가능성과 실행 신뢰도를 넘어, 하네스가 에이전트로 하여금 더 나은 파이프라인 — 즉 산출 데이터가 다운스트림에서 더 유용한 파이프라인 — 을 저작하게 하는지를 결과 기반 프로토콜로 평가한다. 에이전트가 전체 데이터 합성 파이프라인을 구축하고, 파이프라인을 실행해 학습셋을 합성하고, 그 데이터로 모델을 파인튜닝한 뒤 벤치마크 정확도를 측정한다.

각 시나리오에서 두 구성은 정확히 한 가지만 다르다. Vanilla CC는 자연어 태스크 설명만 받고 파라메트릭 지식으로 파이프라인을 작성한다. DataFlow-Harness는 동일 에이전트가 동일 프롬프트를 받되 Skills와 MCP 오퍼레이터 레지스트리로 DataFlow 환경에 추가 접지된다. 파이프라인 구축 이후의 모든 것(합성 LLM·API 설정·샘플 수·기저 모델·파인튜닝 레시피·평가 하네스)은 양쪽에 고정된다.

시나리오 1 — 수학 추론 파이프라인 (Qwen2.5-32B-Instruct + LIMO 레시피)

검증·필터링, 부적절 문항 폐기, 시드 문항당 2개 합성 문항 확장, 추론 트레이스 생성, n-gram 중복 제거로 구성된 수학 데이터 정제·합성 파이프라인을 구축하게 한다.

두 구성 모두 기저 모델을 크게 끌어올려, Claude Code가 도움 없이도 기능적 합성 파이프라인을 저작할 수 있음을 확인한다. 그러나 모든 매칭된 에폭에서 하네스 데이터가 더 높은 평균을 산출한다(1 epoch: 49.9→51.6, 2 epochs: 54.5→55.7). 이득은 가장 어렵고 오염 민감한 벤치마크에 집중된다. 1 epoch 기준 AIME24@32 25.1→35.9, AIME25@32 21.6→34.5다. 이 패턴은 접지된 파이프라인이 더 효과적인 검증·필터링·중복 제거를 적용하여, 단순히 양이 많은 것이 아니라 더 깨끗하고 도전적인 추론 트레이스를 생산한다는 해석과 일관된다.

시나리오 2 — 시드 없는 범용 SFT 파이프라인 (Qwen2.5-7B-Base · 10K pairs)

시드 데이터셋 없이 API 호출만으로 End-to-End 데이터를 생성하는 더 까다로운 설정이다. 파이프라인은 지식 택소노미·난이도 조건부 명령–응답 생성 → 비평-후-재작성(critique-then-rewrite) 정제 → LLM-as-judge 스코어링 필터의 3단계로 구성된다.

지식 성능은 거의 동일하고(MMLU 74.2 vs 74.4) 수학 벤치마크는 승패가 엇갈린다. 가장 뚜렷한 차이는 코드에서 나타나며, 하네스 파이프라인이 4개 벤치마크 전부에서 강하고 특히 MBPP 격차(75.4 vs 64.6)가 크다. 이 코드 이득이 9개 벤치마크 평균을 2.3점(63.8 vs 61.5) 끌어올린다. 접지된 비평-재작성·심판 단계가 더 실행 가능하고 잘 구조화된 코딩 응답을 생산한다는 해석과 일관된다.

DataFlow-Harness는 절차적 Skills, 라이브 MCP 접지, 타입화된 변이, 구조 검증, 동기화된 대화·시각 편집을 결합하여 NL2Pipeline 갭에 대응한다. 12태스크 벤치마크에서 관측된 E2E 통과율은 스크립트 생성 베이스라인에 근접하면서, 측정된 구축 비용과 지연은 더 낮다.