LLM 작업을 데이터프레임 쿼리로 다루는 fenic

LLM 작업을 데이터프레임 쿼리로 다루는 fenic

fenic 시맨틱 데이터프레임 썸네일

문서 분류나 요약을 LLM에 맡기다 보면 데이터 처리 코드와 모델 호출 코드가 금세 뒤섞여요. 오픈소스 프로젝트 fenic은 이 작업을 데이터프레임 쿼리 안으로 가져와요. 익숙한 SQL식 연산과 의미 기반 연산을 한 파이프라인에서 실행하고, 결과가 나온 과정과 비용도 다시 확인할 수 있게 만들었어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
쿼리 모델	일반 데이터 연산과 LLM 기반 연산을 함께 작성해요	데이터 전처리와 모델 호출을 따로 이어 붙이는 코드를 줄일 수 있어요
타입과 스키마	비정형 텍스트를 Pydantic 스키마에 맞춘 컬럼으로 바꿔요	모델 출력이 다음 처리 단계에서 어떤 형태여야 하는지 명시할 수 있어요
실행 관리	배칭, 재시도, 캐싱, 비용 추적을 실행 계층에서 맡아요	운영 코드마다 같은 제어 로직을 반복해서 만들 필요가 줄어요
에이전트 연결	완성한 파이프라인을 MCP 도구로 노출할 수 있어요	사람이 검사한 데이터 작업을 에이전트도 같은 방식으로 재사용할 수 있어요

1. LLM 연산도 데이터 쿼리의 한 단계로 만들어요

fenic의 출발점은 데이터프레임이에요. `select`, `filter`, `join`, `group_by`, `agg`처럼 PySpark나 SQL 사용자에게 익숙한 연산을 제공해요. 여기에 `extract`, `classify`, `summarize`, `embed`와 의미 기반 조인을 같은 쿼리 모델의 연산자로 넣었어요. 별도의 모델 호출 스크립트를 중간마다 붙이는 대신, 어떤 입력에서 어떤 결과 컬럼을 만들지 파이프라인에 적는 방식이에요. 2

예를 들어 고객 문의를 처리한다면 먼저 날짜와 제품군으로 행을 좁힐 수 있어요. 그다음 남은 문의만 의미에 따라 분류하고 요약해요. 일반 필터가 먼저 실행되면 LLM으로 보내는 행이 줄어요. 모델 호출 횟수와 비용을 줄이는 데 직접 도움이 되는 구조예요.

728x90

의미 기반 조인도 눈에 띄어요. 전통적인 조인은 양쪽 데이터에 같은 키가 있어야 편해요. 실제 문서에는 제품명 표기나 표현이 자주 달라요. fenic은 문장의 의미를 기준으로 관련 행을 연결하는 연산을 제공해요. 정확한 키가 없는 문서, 상담 기록, 티켓을 정형 데이터와 묶을 때 쓸 수 있어요.

자유 형식 출력 대신 스키마를 먼저 정해요

LLM 응답을 긴 문자열로만 받으면 후속 코드가 불안정해져요. fenic은 비정형 텍스트에서 필요한 값을 뽑아 Pydantic 스키마에 맞춘 구조화 컬럼으로 돌려줄 수 있어요. 필드 이름과 타입을 미리 정하니 결과를 집계하거나 다른 테이블과 연결하기 쉬워져요.

Markdown, HTML, JSON, 대화 기록, 임베딩도 논리 타입으로 다뤄요. PDF 파싱과 S3·Hugging Face의 CSV 및 Parquet 읽기도 지원해요. 문서마다 별도 파서를 붙이는 부담을 줄이고, 데이터가 들어온 뒤의 처리 방식을 한 쿼리로 모으려는 설계예요.

모델 호출의 운영 문제를 실행 계층으로 내려요

LLM을 대량 호출하면 레이트 리밋, 타임아웃, 재시도, 캐시를 처리해야 해요. 호출마다 토큰 수와 비용도 달라져요. fenic은 비동기 실행과 자동 배칭, 백오프 재시도, 캐싱을 제공해요. 일반 데이터 연산은 Polars와 DuckDB를 활용하고, 데이터 교환에는 Apache Arrow를 써요.

지연 실행을 적용하므로 쿼리를 선언한 뒤 실제 실행 계획을 만들 수 있어요. `explain`으로 계획을 확인하고, 행 단위 계보와 쿼리별 토큰·비용 지표도 볼 수 있어요. 결과만 남기지 않고 어떤 연산과 모델 호출을 거쳤는지 추적할 수 있다는 점이 실험용 스크립트와 달라요.

완성한 파이프라인을 에이전트 도구로 연결해요

파이프라인은 명명된 테이블이나 뷰로 저장할 수 있어요. 카탈로그에 등록한 뒤 MCP 도구로 노출하는 흐름도 지원해요. 데이터 정제와 분류 규칙을 도구 내부에 넣어 두면 에이전트는 원본 데이터에 임의 쿼리를 반복하는 대신, 정해진 입력과 출력 타입을 가진 작업을 호출할 수 있어요.

코딩 도구를 위한 설치 명령과 정적 검사 기능도 마련돼 있어요. 프로젝트 소개에는 `fenic skill install`과 `fenic check`가 안내돼요. 사람이 만든 파이프라인을 에이전트가 읽고 실행하는 데서 끝나지 않고, 같은 구조를 작성하고 검사하는 사용 방식까지 염두에 둔 셈이에요.

왜 중요한가요

LLM 데이터 작업에서 어려운 부분은 첫 번째 호출보다 반복 실행이에요. 같은 입력을 다시 처리하지 않아야 하고, 실패한 행만 재시도해야 해요. 출력 형태가 바뀌면 다음 단계가 깨질 수도 있어요. 모델 비용을 어느 단계에서 썼는지도 알아야 해요. fenic은 이런 문제를 개별 애플리케이션 코드가 아니라 데이터 쿼리 엔진의 책임으로 묶어요.

데이터팀에는 기존 SQL·데이터프레임 작업 방식과 LLM 처리를 연결하는 선택지가 생겨요. 에이전트 개발팀에는 검증한 데이터 파이프라인을 타입이 있는 MCP 도구로 제공하는 방법이 생겨요. 특히 수천 건의 문서, 로그, 평가 기록을 반복해서 분류하거나 추출하는 작업에 잘 맞아요.

다만 모든 LLM 워크플로를 데이터프레임으로 표현할 수 있는 것은 아니에요. 여러 도구를 오가며 상태를 바꾸는 장시간 작업이나 사람의 승인을 자주 받는 흐름은 별도 오케스트레이션이 더 자연스러울 수 있어요. fenic은 입력 행을 변환하고 집계하는 배치형 추론에서 강점이 분명해 보여요. 도입 전에는 사용하는 모델 제공자, 지원 연산자, 캐시 정책이 현재 운영 환경과 맞는지 저장소 문서와 예제로 확인하는 편이 좋아요.

fenic은 Apache 2.0 라이선스로 공개돼 있어요. 로컬에서 작은 데이터셋으로 실행 계획과 비용 지표를 확인한 뒤, 기존 파이프라인 일부를 옮겨 보는 식으로 검토할 수 있어요. 2

참고 자료

1. fenic - 사람과 에이전트를 위한 시맨틱 데이터프레임 — GeekNews
2. typedef-ai/fenic: Semantic DataFrames for humans and agents — GitHub