Datasette 기반 도구에 AI 기능을 넣을 때 개발자는 금방 갈림길에 섭니다. 플러그인 안에 특정 모델 API를 바로 박아 넣으면 당장은 빠릅니다. 하지만 두 번째 AI 기능이 생기고, 다른 팀이 다른 모델을 원하고, 운영자가 비용과 키 관리를 따지기 시작하는 순간 그 선택은 기술 부채가 됩니다.
이번에 나온 datasette-llm 0.1a7은 그 갈림길에서 "모델 호출"보다 "공통 LLM 계층" 쪽에 무게를 싣는 업데이트입니다. 이번 버전의 핵심은 특정 모델에 기본 옵션을 설정하는 메커니즘이고, 이를 통해 예를 들어 enrichment 작업은 지정한 모델과 temperature 값으로 일관되게 돌릴 수 있게 됐습니다.1 겉으로는 작은 편의 기능처럼 보이지만, 실제로는 Datasette 플러그인 생태계가 AI를 붙이는 방식을 바꾸는 신호에 가깝습니다.
플러그인마다 모델을 직접 붙이면 왜 금방 불편해지나
가장 단순한 방식은 플러그인마다 OpenAI나 Anthropic 같은 공급자 하나를 직접 호출하는 것입니다. 데모를 빨리 만들기엔 좋습니다. 문제는 이런 구조가 반복될수록 설정, 키 관리, 허용 모델, 기본 옵션이 플러그인마다 흩어진다는 점입니다.
datasette-llm은 이 문제를 정면으로 다룹니다. 이 플러그인은 다른 플러그인이 의존할 수 있는 표준 인터페이스를 제공하고, 모델 필터링, 기본 모델, 옵션, API 키 관리, 정책 훅까지 한곳에서 다루도록 설계됐습니다.2 여기에 datasette-secrets와 연동되는 키 관리까지 포함돼 있어, 모델 공급자별 키를 제각각 처리하지 않아도 됩니다.2
이게 중요한 이유는 UX보다 운영 때문입니다. 같은 Datasette 인스턴스에서 SQL 보조, 추출, 대량 enrichment가 함께 돌 때, 각 기능이 서로 다른 모델 선택 규칙과 키 해석 방식을 가지면 나중에 바꾸기가 어렵습니다. "AI 기능을 넣었다"는 사실보다 "AI를 어디서 통제하느냐"가 더 중요해지는 순간이 옵니다.
이번 0.1a7의 포인트는 모델 호출이 아니라 모델 교체 가능성이다
0.1a7에서 추가된 것은 특정 모델에 대한 기본 옵션 설정입니다.1 저장 위치는 datasette.yaml이고, 전역 기본 모델뿐 아니라 purpose별로 모델과 옵션을 다르게 둘 수 있습니다.2 예를 들어 bulk enrichment는 더 저렴한 모델에 낮은 토큰 한도로, SQL assistant는 더 강한 모델로 분리할 수 있습니다.2
여기서 핵심은 "어떤 모델이 최고인가"가 아닙니다. 더 중요한 것은 플러그인이 모델 세부사항을 몰라도 되게 만드는 구조입니다. datasette-llm에는 purpose 등록 개념이 있고, 플러그인은 extract, enrichments, sql-assistant 같은 목적 단위로 모델을 요청할 수 있습니다.32 운영자는 그 목적에 맞는 허용 모델, 차단 모델, 기본 옵션을 나중에 바꿀 수 있습니다.2
이 구조는 테스트와 배포에도 영향을 줍니다. 최소한의 예로도 llm-echo 같은 테스트용 모델 플러그인을 쓸 수 있고, 실제 운영에서는 OpenAI, Anthropic, 로컬 모델 등 llm 라이브러리가 품는 더 넓은 모델 생태계를 활용할 수 있습니다.24 즉, AI 기능을 플러그인 코드에 고정하지 않고, 교체 가능한 런타임 의존성으로 밀어낸 셈입니다.
더 나은 질문: 모델 선택은 누가 결정해야 하나
실무에서는 "gpt-5.4-mini를 쓸까, claude-sonnet-4.6을 쓸까"보다 먼저 물어야 할 것이 있습니다. 그 결정을 코드에 박을지, 운영 설정으로 뺄지, 사용자에게 노출할지입니다.
datasette-llm은 이 경계를 비교적 분명히 나눕니다. 플러그인 개발자는 목적을 정의하고, 어떤 작업 흐름에서 LLM이 필요한지만 결정합니다. 운영자는 models, blocked_models, default_model, purpose별 model과 options로 비용·품질·정책을 통제합니다.2 사용자는 그 위에서 제한된 선택지만 보게 만들 수 있습니다.
이 분리는 거버넌스 측면에서도 유용합니다. README에 따르면 이 플러그인은 사용량 추적, 정책 강제, 회계 처리를 위한 훅 확장 지점도 제공합니다.2 또 0.1a5에서는 프롬프트 체인과 도구 호출 루프까지 추적 범위가 넓어졌습니다.5 아직 이것만으로 완전한 감사를 보장한다고 말하긴 어렵지만, 적어도 "누가 어떤 목적의 모델을 어떻게 썼는지"를 한 계층에서 다룰 기반은 갖춰지는 중이라고 보는 편이 맞습니다.
반대로 한계도 분명합니다. 지금은 알파 단계이고 릴리스 이력상 0.1a1부터 0.1a7까지 빠르게 인터페이스가 다듬어지고 있습니다.5 단일 플러그인, 단일 모델, 짧은 수명의 내부 프로토타입이라면 직접 호출이 더 빠를 수 있습니다. 추상화는 항상 미래 비용을 줄이는 대신 현재 복잡도를 조금 올립니다.
마지막 판단 기준은 단순합니다. AI 기능이 하나뿐인 데모라면 굳이 공통 계층까지 세울 필요는 없습니다. 하지만 여러 플러그인이 같은 Datasette 인스턴스에서 LLM을 쓰게 될 가능성이 있거나, 모델 교체·비용 통제·키 관리·감사 가능성이 중요하다면 datasette-llm 0.1a7은 "편의 기능"이 아니라 아키텍처 선택지로 봐야 합니다. 지금 필요한 것은 최고의 모델을 고르는 감각보다, 나중에 모델을 바꿔도 덜 아프게 만드는 구조입니다.
참고
2GitHub - datasette/datasette-llm: LLM integration plugin for other plugins to depend on · GitHub
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.