fenic으로 데이터프레임에 LLM 연산 붙이기

게시 2026.07.15 · 약 6분 분량

핵심 요약 fenic은 typedef.ai가 공개한 Apache-2.0 오픈소스 데이터프레임 엔진이다. PySpark 스타일 연산에 추출·분류·조인 같은 시맨틱 연산자를 더하고, 배치·재시도·비용 추적을 엔진이 처리한다.

fenic은 무엇이고 어떤 문제를 푸나

fenic은 typedef.ai가 공개한 오픈소스 데이터프레임 엔진이다. 데이터프레임은 행과 열로 이뤄진 표 형태의 데이터를 다루는 자료구조로, 파이썬에서는 pandas나 PySpark가 대표적이다. fenic은 여기에 대규모 언어 모델(LLM) 호출을 정식 연산자로 끼워 넣는다. 2026년 7월 기준 fenic GitHub 저장소의 최신 릴리스는 v0.10.0(2026년 6월 25일)이고 라이선스는 Apache-2.0이다. pip install fenic으로 설치하며, 공식 문서 기준 파이썬 3.10부터 3.12까지 지원한다. 이 글은 파이썬 개발자가 fenic의 구조와 쓰임새를 빠르게 파악하도록 돕는 데 초점을 두며, 설치 환경별 문제 해결이나 특정 모델의 프롬프트 튜닝은 다루지 않는다.

fenic 저장소 설명에 따르면, 비정형 텍스트를 다룰 때 개발자는 보통 정규식과 일회성 스크립트, 프롬프트 체인을 이어 붙인다. 이렇게 짠 코드는 다시 돌려도 같은 결과가 나오는지 장담하기 어렵고, 나중에 무엇을 왜 했는지 들여다보기도 힘들다. fenic은 이 작업을 타입이 붙은 데이터프레임 파이프라인으로 바꿔, 사람과 AI 에이전트가 함께 읽고 다시 쓸 수 있는 형태로 남기는 것을 목표로 삼는다.

시맨틱 연산자는 어떻게 쓰나

세션에 모델을 한 번 등록한 뒤, 일반 데이터프레임 연산 사이에 fc.semantic.* 연산자를 끼워 쓴다. fenic 공식 문서는 시맨틱 연산자로 extract(텍스트를 타입이 정해진 구조체로 추출), classify(정해진 분류로 라벨링), predicate(자연어 조건으로 필터링), map(행마다 템플릿 생성), reduce(그룹을 하나로 집계), join(의미 기준 조인), 그리고 analyze_sentiment와 group_by를 든다. 아래는 저장소 예시를 요약한 것으로, 고객 문의 텍스트에서 제품명과 감정을 구조화해 뽑아낸다.

import fenic as fc
from pydantic import BaseModel, Field

class Ticket(BaseModel):
  product: str = Field(description="문의 대상 제품")
  sentiment: str = Field(description="positive, neutral, negative 중 하나")

session = fc.Session.get_or_create(
  fc.SessionConfig(
    app_name="quickstart",
    semantic=fc.SemanticConfig(
      language_models={
        "mini": fc.OpenAILanguageModel(
          model_name="gpt-4o-mini", rpm=500, tpm=200_000
        )
      },
    ),
  )
)

df = session.create_dataframe([
  {"id": 1, "text": "업데이트 이후 CSV 내보내기가 계속 멈춥니다."},
])

tickets = df.select("id", fc.semantic.extract("text", Ticket).alias("t")).unnest("t")

여기서 extract는 파이단틱(Pydantic) 모델 Ticket을 스키마로 받아, 자유 텍스트를 product와 sentiment 필드가 채워진 구조체로 바꾼다. 결과가 그냥 문자열이 아니라 타입이 붙은 값이라, 뒤에 이어지는 필터나 조인에서 여느 컬럼처럼 다룰 수 있다. select·filter·join 같은 일반 연산과 시맨틱 연산이 한 파이프라인에 섞여 흐르는 셈이다.

일반 pandas·PySpark와 무엇이 다른가

가장 큰 차이는 쿼리 엔진이 LLM 추론을 전제로 설계됐다는 점이다. pandas나 PySpark에서 모델을 부르려면 요청 배치 묶기, 속도 제한, 실패 재시도, 비용 집계를 직접 코드로 얹어야 한다. fenic 공식 문서에 따르면 이런 일을 엔진이 맡는다. 파이프라인을 지연(lazy) 실행으로 쌓아 두면 fenic이 이를 컴파일한 뒤 자동 배치, 속도 제한, 재시도, 토큰과 비용 집계, 응답 캐싱을 처리한다.

모델 설정도 호출 지점마다 흩어지지 않고 세션 한 곳에 모인다. 위 예시의 OpenAILanguageModel(model_name="gpt-4o-mini", rpm=500, tpm=200_000)처럼 분당 요청 수(rpm)와 분당 토큰 수(tpm) 한도를 모델별로 선언해 두면, 엔진이 그 한도 안에서 요청 속도를 스스로 조절한다. 추출·분류·요약·임베딩이 옆에서 손으로 엮는 별도 호출이 아니라 스키마와 타입을 가진 연산자이기 때문에, 파이프라인 전체를 코드로 한눈에 검토할 수 있다.

지원하는 모델 공급자

fenic 공식 문서 기준으로 OpenAI, Anthropic, 구글(Gemini), Cohere를 지원하고 각 공급자마다 전용 클래스가 있다. 공급자별 API 키는 OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY, COHERE_API_KEY 환경 변수로 설정한다.

즉 언어 모델과 임베딩 모델을 공급자별로 골라 세션에 함께 등록하고, 파이프라인 안에서 필요한 연산마다 어떤 모델을 쓸지 이름표로 지정할 수 있다.

사람과 에이전트가 같이 쓴다는 말의 의미

fenic이 내세우는 "humans and agents"는 파이프라인을 사람도 에이전트도 읽는 자산으로 남긴다는 뜻이다. fenic 공식 문서에 따르면 테이블과 뷰를 모델 컨텍스트 프로토콜(MCP, AI 도구가 외부 데이터나 기능에 접근하도록 정한 표준 규격)의 도구로 노출하는 MCP 서버 기능을 제공한다. 또 fenic skill install 명령으로 클로드·커서·코덱스·Gemini 같은 코딩 도구에 fenic API 사용법을 심어, 에이전트가 파이프라인 코드를 더 정확히 작성하도록 돕는다. 파이썬으로 MCP 서버 자체를 만드는 흐름이 궁금하다면 FastMCP로 첫 도구를 클로드에 연결하는 과정이 참고가 된다.

언제 도입을 고려할 만한가

비정형 텍스트를 대량으로 분류·추출·요약하는 파이프라인을 반복해서 돌린다면 검토할 값어치가 있다. 특히 여러 모델을 섞어 쓰면서 속도 제한과 비용을 한곳에서 관리하고 싶을 때, 그리고 그 파이프라인을 나중에 다시 읽고 손봐야 할 때 fenic의 방식이 이점을 준다. 반대로 한 번 쓰고 버릴 프로토타입이라면 모델 API를 직접 호출하는 편이 더 가볍다. 도입을 검토한다면 fenic 공식 문서에서 최신 연산자 목록과 버전을 먼저 확인하는 편이 좋다.