datasette-llm 0.1a10, 제외된 모델을 다시 복원하던 버그 수정

datasette-llm 0.1a10은 모델 필터링 과정에서 운영자가 이미 제외한 선택지를 다시 복원할 수 있던 버그를 수정한다. Simon Willison은 2026년 11월 4일 이 업데이트를 공개했다. 릴리스 노트는 애플리케이션이 허용하는 모델을 정의하는 목록인 기존 모델 허용 목록에 대한 수정 사항을 설명한다.

문제의 핵심은 운영자의 구성과 애플리케이션이 실제로 허용하는 선택지 사이의 긴장에 있다. 다른 구성 요소가 나중에 제한 목록을 확장할 수 있다면 모델 제한 목록은 큰 의미가 없다. 즉각적인 영향은 동일한 배포 환경에서 모델 액세스, 회계, 에이전트 인터페이스를 결합하는 개발자에게 미친다.

AI 제공업체에 대한 액세스를 중개하는 게이트웨이인 LiteLLM은 애플리케이션이 이러한 제어를 어디에 두는지 비교하는 데 유용한 사례다. 여기서 보고된 문제는 Datasette 플러그인 통합 내부의 필터와 관련됐다. 이 릴리스는 특정한 조합 오류를 해결하지만, 배포 소유자는 여전히 자체 조합을 점검해야 한다.

datasette-llm 0.1a10의 변경 사항

이 업데이트는 모델 필터가 함께 작동할 때 제외 설정을 유지한다. 따라서 이번 릴리스는 새 모델, 벤치마크 개선, 확장된 제공업체 카탈로그가 아니라 애플리케이션 동작에 관한 업데이트다.

프로젝트의 필터 조합 수정은 실패 원인을 설명한다. 사용 가능한 선택지를 수정하는 확장 함수인 각 필터링 훅은 동일한 초기 모델 목록을 받았다. 반환된 목록은 누적된 결과를 대체했다. 회계 플러그인이 활성화된 경우 가격 필터가 제외된 모델을 다시 복원할 수 있었다.

풀 리퀘스트는 Datasette Agent가 해당 모델을 제공하고 대화를 생성할 때 이를 수락했다고도 밝힌다. 이 세부 사항은 예상보다 넓은 메뉴 범위를 넘어 문제에 실질적인 의미를 부여한다. 프로젝트에 따르면, 이 불일치는 애플리케이션의 대화 생성 동작까지 영향을 미쳤다.

수정 사항은 모델 식별자를 기준으로 결과를 교집합 처리해 적용 가능한 필터를 모두 통과한 모델을 유지한다. 프로젝트는 75개의 통과 테스트와 회계 및 에이전트 플러그인을 사용하는 통합 점검을 보고했다. 이 점검에서 제외된 모델은 오류 응답인 HTTP 400을 받았고, 허용된 모델은 성공 응답인 HTTP 200을 받았다.

이 결과는 유지보수자가 보고한 검증 결과다. 이는 명시된 수정 사항을 뒷받침하지만, 모든 배포 환경이나 타사 플러그인 조합이 동일하게 작동한다는 점을 입증하지는 않는다. 또한 운영자가 자신의 설치 환경과 비교할 수 있는 구체적인 동작을 제공한다.

이번 릴리스는 제한 간의 관계를 바꾼다. 구성 요소가 특정 모델을 회계 처리할 수 있는지 판단하더라도, 다른 구성 요소의 모델 제외 결정을 조용히 취소해서는 안 된다. 그렇지 않으면 운영 기능을 추가하는 행위가 운영자가 요청하지 않은 방식으로 액세스를 변경하게 된다.

이 구분은 업데이트 범위를 평가할 때 중요하다. 새로 사용 가능한 모델은 의도적인 구성 변경일 수 있다. 반면 다른 필터가 나중에 실행됐다는 이유로 이전에 제외된 모델이 다시 나타나는 것은 애플리케이션이 계속 작동하더라도 다른 결과다.

릴리스를 지켜보는 독자에게 기억할 만한 사실은 상호작용이다. 오류는 각각 유용한 구성 요소가 답변을 결합하는 지점에서 나타났다. 각 구성 요소의 출력을 최종 답변으로 취급하면, 이후의 결정이 이전 제한을 대체할 수 있었다.

이는 확장 가능한 AI 소프트웨어를 사용하는 팀이 좁은 범위의 유지보수 릴리스에도 주목해야 하는 이유를 설명한다. 설치가 성공하고 생성이 성공했다는 사실만으로 제한이 그 사이의 과정에서 유지됐음을 보장하지는 않는다. 보고된 수정은 바로 그 과정에 관한 것이다.

실질적인 의미는 명확하다. 애플리케이션이 선택하는 시점의 모델 가용성은 적용 가능한 모든 제한을 반영해야 한다. 구성 파일은 의도를 표현하지만, 실행 중인 조합이 사용자가 실제로 경험하는지 결정한다.

운영자는 구성된 액세스와 실제 액세스 사이의 격차에 직면한다

의도한 제한과 실제 액세스가 다를 때 그 결과는 배포 소유자가 감당한다. 개발자는 통합을 정의하지만, 운영자는 노출할 준비가 된 모델을 선택한다.

Datasette의 플러그인 구성은 일반적으로 구성 파일의 플러그인 항목 아래에 위치한다. 이 구조는 운영자가 설정을 표현할 수 있는 익숙한 위치를 제공한다. 그러나 이것만으로 모든 확장이 실행 중에 이러한 설정을 어떻게 결합하는지 입증되지는 않는다.

이 구분은 익숙한 운영 문제와 닮아 있다. 문서는 정책을 정확히 설명할 수 있지만 소프트웨어는 이를 잘못 구현할 수 있다. 문서를 검토하면 무엇이 요청됐는지 확인할 수 있다. 애플리케이션 동작을 관찰하면 요청이 실제로 반영됐는지 확인할 수 있다.

공개 데모에서 제한된 선택지는 의도된 경험을 정의할 수 있다. 방문자는 소유자가 선택한 옵션을 접해야 한다. 관련 없는 플러그인 동작이 그 선택 범위를 확장하면, 데모는 소유자가 명시한 운영 가정과 더 이상 일치하지 않는다.

내부 애플리케이션에서는 이러한 논리가 승인된 제공업체와 지원되는 워크플로로 확장된다. 조직은 팀이 평가한 모델로 선택지를 의도적으로 제한할 수 있다. 예상치 못한 가용성이 발견되면 실제 정책 위반 여부를 판단하기 전에 조사가 필요하다.

이는 잠재적 결과이지, 이번 릴리스에서 보고된 결과는 아니다. 공개된 수정 사항만으로 금전적 손실, 민감한 정보 노출, 무단 제공업체 사용이 발생했다고 확정할 수는 없다. 그러한 결론에는 요청, 자격 증명, 영향을 받은 배포 환경에 관한 증거가 필요하다.

그럼에도 운영자의 즉각적인 질문은 달라진다. 수정 전에는 설명된 플러그인 상호작용 아래에서 좁은 구성이 더 넓은 실제 선택지와 공존할 수 있었다. 업그레이드 후 운영자는 실행 중인 애플리케이션이 이제 의도한 제한과 일치한다는 증거가 필요하다.

그 증거는 설치된 조합을 반영해야 한다. 개발자의 격리된 테스트는 회계 확장이나 다른 애플리케이션 구성 요소가 도입한 동작을 놓칠 수 있다. 관련 시스템에는 실제 요청에 참여하는 구성 요소가 포함된다.

조직적 부담도 팀 경계를 넘는다. 구성을 유지하는 사람이 모델 선택 인터페이스를 유지하지 않을 수 있다. 회계를 추가하는 사람은 회계가 액세스를 넓힐 수 없다고 합리적으로 가정할 수 있다. 이 결함은 그 가정을 명시적으로 만드는 일의 중요성을 드러낸다.

따라서 애플리케이션 소유자에게는 승인된 모델 선택에 대한 공동의 정의가 필요하다. 승인은 인터페이스에 표시되는 항목, 요청이 지정할 수 있는 항목, 혹은 궁극적으로 프롬프트를 받는 항목 중 무엇에 관한 것인가? 이 질문들은 관련은 있지만 서로 다른 관찰 대상을 설명한다.

명확한 답은 팀이 서로 다른 증거를 근거로 논쟁하는 일을 피하게 한다. 인터페이스 소유자는 제한된 메뉴를 보여줄 수 있고, 다른 개발자는 그 메뉴 밖의 요청이 수락된다는 사실을 발견할 수 있다. 두 관찰은 모두 정확할 수 있지만, 이들을 함께 봐야만 실제 경계를 설명할 수 있다.

영향은 해당 배포 환경에는 즉각적이며, 플러그인 작성자에게는 더 오래 지속된다. 운영자에게는 검증된 수정이 필요하다. 개발자에게는 다른 확장이 애플리케이션에 추가돼도 이해하기 쉬운 조합 규칙이 필요하다.

필터 결합에는 명시적인 규칙이 필요한 이유

필터링 시스템은 구성 요소가 선택지를 좁힐 수 있는지, 확장할 수 있는지, 또는 둘 다 가능한지를 정의해야 한다. 이 규칙이 없으면 “필터”라는 단어에는 중요한 모호성이 남는다.

모델 필터링 변경 사항은 교집합 방식을 구현한다. 쉽게 말해 후보 모델은 참여하는 제한을 모두 통과해야 한다. 이후 결과가 단순히 이전의 제한된 결과를 더 넓은 컬렉션으로 대체할 수는 없다.

승인된 모델과 제외된 모델이 있는 가상의 애플리케이션을 생각해 보자. 정책 구성 요소는 승인된 선택지만 허용한다. 별도의 회계 구성 요소는 두 선택지 모두의 사용량을 측정하는 방법을 알고 있으므로 두 모델을 인식한다.

회계의 답은 다른 질문에 답한다. 모델 사용량을 측정할 수 있다는 사실이 그 사용을 승인하는 것은 아니다. 애플리케이션이 그 답을 정책의 대체물로 취급하면, 회계가 의도치 않게 액세스 결정 역할을 하게 된다.

제한을 결합하면 이러한 구분이 유지된다. 관련 구성 요소가 해당 모델이 계속 사용 가능하다는 데 동의할 때에만 애플리케이션은 모델을 선택할 수 있다. 회계 구성 요소는 운영자의 제외 설정을 되돌리지 않으면서 유용한 정보를 제공한다.

이 예시는 수정의 논리를 보여 주는 것이며, 추가로 보고된 사고는 아니다. 또한 겉보기에 무해한 확장이 애플리케이션 동작을 바꿀 수 있는 이유도 설명한다. 문제는 구성 요소의 악의적 의도를 전제하지 않고, 답변이 결합되는 방식에 있다.

교집합 규칙은 보수적인 기대를 만든다. 또 다른 제한적 필터를 추가하면 기존 제외 설정은 유지되거나 가용성이 더 줄어들어야 한다. 다른 적용 가능한 필터가 제거한 선택지를 다시 복원해서는 안 된다.

그러나 보수적인 조합에는 자체적인 운영상 질문도 따른다. 필터가 너무 완전히 불일치하면 사용할 수 있는 모델이 하나도 남지 않을 수 있다. 특히 사용자가 대화를 시작하려 할 때, 애플리케이션은 이 결과에 대해 이해하기 쉬운 동작을 제공해야 한다.

빈 결과가 나오면 관련 제한을 조사해야 한다. 제한을 보수적으로 결합하는 이유를 무너뜨릴 수 있으므로, 제한 없는 모델을 조용히 대체해서는 안 된다. 이는 아키텍처적 함의이지, 이번 릴리스가 특정 폴백 정책을 추가했다는 주장은 아니다.

설계를 평가할 때 순서도 중요하다. 플러그인 등록 순서를 바꿨을 때 제한된 모델의 가용성이 달라진다면, 운영자는 의도하지 않았던 설치 세부 사항에 따라 불안정한 정책을 마주하게 된다. 제한은 운영자가 권한 설정으로 생각하지 않았던 설치 세부 사항에 의존해서는 안 된다.

더 넓은 분석적 요점은 책임에 관한 것이다. 탐색은 소프트웨어가 어떤 모델을 알고 있는지 답한다. 회계는 구성 요소가 어떤 모델을 측정할 수 있는지 답한다. 권한 부여는 특정 애플리케이션이 어떤 선택지를 허용하는지 답한다.

이러한 책임은 서로 바꿔 쓸 수 없으면서도 구현 기반을 공유할 수 있다. 한 책임을 위해 생성된 출력이 다른 책임에 대해 조용히 권위 있는 결과가 될 때 문제가 발생한다. 명시적인 조합 규칙은 이러한 이전을 가시화하고 검토 가능하게 만든다.

따라서 확장 가능한 AI 애플리케이션에서 이 수정의 가치는 모델 목록의 문법을 넘어선다. 이는 기여 구성 요소가 변경할 수 있는 범위를 명확히 한다. 그것이 모든 상호작용을 처음부터 다시 재구성하지 않고도 향후 조합을 추론하는 기반이다.

모델 제어는 서로 다른 애플리케이션 계층에 위치한다

비슷한 도구는 유사한 운영자 우려를 드러내지만, 시스템의 서로 다른 부분에 강제를 배치한다. 따라서 기능 체크리스트보다 아키텍처가 더 유용한 비교 기준이 된다.

현재 datasette-llm 모델 관리 문서는 전역 모델 목록, 차단된 모델, 기본값, 용도별 구성을 설명한다. 또한 필터링 및 사용량 처리 확장 지점도 문서화한다. 이는 현재 개발 문서이므로, 이전의 모든 릴리스에 대한 역사적 사양으로 자동 적용해서는 안 된다.

LiteLLM의 virtual keys는 대조적인 방식을 제공한다. 해당 문서는 클라이언트와 제공업체 사이에 위치하는 프록시를 통해 발급된 자격 증명과 관련된 모델 접근 제어 및 사용량 추적을 설명한다.

비교에는 한계가 있다. 이들 자료는 동등한 보장, 동일한 배포 요구 사항 또는 한 제품을 다른 제품으로 대체해야 할 근거를 확립하지 않는다. 대신 제한을 표현하고 적용하는 서로 다른 위치를 보여 준다.

애플리케이션 수준 통합은 사용자의 작업과 가까운 곳에서 결정을 내릴 수 있다. 이를 둘러싼 소프트웨어는 모델이 요청되는 이유를 이해한다. 이러한 근접성은 모델 선택을 이를 제시하는 인터페이스나 워크플로와 연결하는 데 도움이 될 수 있다.

게이트웨이는 공유 서비스 경계에 제어 장치를 둘 수 있다. 그 경계를 통해 요청을 보내는 애플리케이션은 해당 규칙을 적용받는다. 아키텍처 측면의 질문은 모든 관련 요청이 실제로 이를 시행하도록 설계된 서비스를 거치는지 여부가 된다.

어느 위치에 두든 구성을 검토할 필요가 사라지지는 않는다. 애플리케이션은 여러 로컬 제한을 잘못 조합할 수 있다. 더 광범위한 배포 환경에서도 애플리케이션이 허용하는 범위와 공유 인프라가 허용하는 범위 사이에 불일치가 생길 수 있다.

따라서 유용한 비교는 결정이 어디에서 구속력을 갖게 되는지 묻는다. 제한된 메뉴는 표시 방식에 관한 증거다. 애플리케이션의 거부는 요청 처리에 관한 증거다. 제공업체 요청은 최종적으로 어떤 일이 일어났는지를 보여 주는 또 다른 관찰 자료다.

이러한 관찰을 구분해 두면 구매자는 더 나은 질문을 할 수 있다. 모델 전환 시연이 제어 적용을 입증하지는 않는다. 구성 스크린샷만으로는 후속 구성 요소가 그 선택을 보존하는지 알 수 없다.

어느 접근 방식을 평가하든 개발자는 제한의 소유권이 명확한지 살펴봐야 한다. 승인된 집합을 정의하는 구성 요소는 무엇인가? 이를 더 좁힐 수 있는 구성 요소는 무엇인가? 어떤 문서화된 조건에서 다른 구성 요소가 예외를 도입할 수 있는가?

조직이 여러 계층을 함께 사용하더라도 이 질문들은 여전히 중요하다. 애플리케이션과 게이트웨이는 상호 보완적인 제한을 적용할 수 있다. 그래도 운영자가 최종 접근 범위를 설명할 수 있을 만큼 정책은 충분히 명확해야 한다.

이러한 결정에 관한 근거를 관리하는 팀이라면 검색 가능한 지식 베이스가 구성 근거와 검토 이력을 보존하는 데 도움이 될 수 있다. 그러한 문서는 조사에 기여하며, 실제로 애플리케이션이 무엇을 허용하는지는 런타임 점검으로 확인된다.

이번 릴리스가 아키텍처 경쟁의 승패를 가르는 것은 아니다. 제한이 어디에 있든, 선택된 아키텍처에는 제한을 결합하는 명시적 규칙이 필요하다는 점을 보여 주는 구체적 사례를 제공한다.

수정이 확립한 사실과 아직 입증되지 않은 사실

공개 근거는 특정 결함과 수정은 뒷받침하지만, 해당 사고의 과거 범위는 밝혀지지 않은 채로 남아 있다. 이 구분은 보도와 운영 대응 모두를 이끌어야 한다.

릴리스와 연결된 개발 기록은 구성된 제한이 재정의된 사실을 설명한다. 또한 수정과 프로젝트 측이 보고한 점검도 설명한다. 이 자료들을 종합하면 모델 선택이 잘못되었다는 설명 없는 주장보다 더 강한 근거가 된다.

그러나 이 자료들은 영향받은 동작이 실제 사용 환경에서 얼마나 자주 발생했는지는 입증하지 않는다. 개발 점검 중의 수용은 애플리케이션 동작에 관한 증거다. 이는 과거 요청량을 밝히거나 관련 플러그인 조합을 사용하는 모든 배포 환경을 식별하지는 않는다.

마찬가지로 더 넓은 모델 가용성이 프롬프트가 의도하지 않은 제공업체에 도달했다는 사실을 자동으로 입증하지는 않는다. 그러한 결론을 내리려면 사용자가 어떤 선택을 제출했는지와 어떤 요청이 완료됐는지에 관한 증거가 필요하다. 릴리스 기록은 배포 기록을 대체할 수 없다.

잠재적인 지출 노출과 측정된 손실 사이에도 차이가 있다. 모델 제한은 운영자의 사용 정책을 지원할 수 있다. 버그가 특정 설치 환경에서 추가 소비를 초래했는지는 실제로 무엇이 실행됐는지에 달려 있다.

정보 처리에도 같은 주의가 적용된다. 민감한 콘텐츠가 예상치 못한 목적지에 도달했다면 이는 중요할 수 있다. उपलब्ध 릴리스 근거는 그러한 순서를 입증하지 않으며, 이 글은 가능한 결과를 보고된 사건으로 바꾸어서는 안 된다.

이처럼 더 좁은 틀은 수정을 축소하지 않는다. 소프트웨어가 보존하지 못하는 제한은 누군가 하류 피해를 입증하기 전에도 수정할 가치가 있다. 예방과 사고 측정은 서로 다른 질문에 답한다.

보고된 검증 역시 정확하게 읽어야 한다. 테스트 통과는 해당 테스트가 실행한 동작을 뒷받침한다. 통합 점검은 특정 조합에 관한 증거를 추가한다. 어느 쪽도 확장 가능한 애플리케이션의 모든 경로에 대한 독립 감사는 아니다.

따라서 회의적인 독자도 배포별 확인을 요구하면서 수정은 받아들일 수 있다. 이러한 입장은 근거를 따른다. 프로젝트는 그럴듯한 실패와 이에 대응하는 수정을 설명하지만, 운영자는 설치한 확장 기능에 대해 여전히 책임을 진다.

버전 라벨은 또 다른 실무적 구분을 제시한다. 릴리스 식별자는 운영자에게 어떤 패키지 빌드가 설치되어 있는지 알려 준다. 하지만 모든 로컬 설정, 호환성 변경 또는 최종 동작을 형성하는 추가 플러그인을 설명하지는 않는다.

이 때문에 datasette-llm 0.1a10을 평가하려면 인벤토리에서 예상 버전이 보이는 것만으로는 충분하지 않다. 관련 질문은 사용자가 마주하는 조건에서 애플리케이션이 의도한 제한을 보존하는지 여부다.

공개 기록 역시 추가 출처 없이 더 광범위한 보안 서사로 확대해서는 안 된다. 이는 공개 악용, 표준화된 취약점 식별자 또는 독립 평가를 입증하지 않는다. 그러한 주장은 각각의 근거를 필요로 한다.

방어 가능한 결론은 여전히 유용하고 실행 가능하다. 유지 관리자는 조합 오류를 식별하고, 필터의 상호작용 방식을 변경했으며, 검증을 보고했다. 과거 영향과 배포 전반의 보증은 조사를 위한 별개의 주제로 남는다.

모델 필터링 수정 이후 주시할 사항

가장 강력한 후속 근거는 현실적인 배포 환경에서 동작이 보존되는지에 관한 것이다. 앞으로 몇 달 동안은 세 가지 신호를 특정한 순서로 주목할 만하다.

첫째, 의도한 제한과 수용된 요청 사이의 일치를 보여 주는 배포 보고를 살펴봐야 한다. 유용한 보고는 관련 플러그인 조합을 설명하고, 보이는 선택지와 대화를 시작할 때 수용되는 선택지를 구분할 것이다.

그러한 근거는 수정이 사용자가 마주하는 애플리케이션 경계까지 도달한다는 신뢰를 높일 것이다. 비교 가능한 조건에서 제외된 모델이 다시 나타났다는 보고는 그 신뢰를 약화하고 추가 조사가 필요한 구체적 상호작용을 식별할 것이다.

중요한 신호는 업그레이드가 작동했다는 일반적 진술이 아니라 반복 가능한 동작이다. 운영자에게는 다른 팀이 유사한 구성을 테스트했는지, 상당히 다른 애플리케이션을 테스트했는지 이해할 수 있을 만큼의 맥락이 필요하다.

둘째, 향후 필터 변경이 확장 기능이 결합될 때도 제외 항목을 보존하는지 살펴봐야 한다. 수정은 오늘 효과적일 수 있지만, 이후 기능이 다른 가정을 지닌 새 경로를 도입할 수 있다. 모델 검색, 사용량 집계 또는 선택과 관련된 변경은 특히 면밀히 검토할 필요가 있다.

이런 조합이 예측 가능한 제한을 유지한다는 근거는 설계의 신뢰성을 높일 것이다. 등록 순서나 추가 확장 기능이 접근 범위를 넓힌다는 근거는 수정이 세운 기대에 의문을 제기할 것이다.

이 신호는 릴리스 빈도보다 유지 관리 규율에 관한 것이다. 릴리스가 많다고 해서 본질적으로 더 나은 제어를 뜻하지는 않는다. 변경된 동작을 명확히 설명하면 운영자는 무엇을 다시 배포 점검해야 하는지 판단할 더 확실한 근거를 얻는다.

셋째, 빈 결과, 예외 및 책임 경계를 쉽게 이해할 수 있게 하는 문서를 살펴봐야 한다. 운영자는 어떤 구성 요소가 결정적인 답을 제공했는지 추측하지 않고도 모델이 왜 사용 가능한지 설명할 수 있어야 한다.

더 명확한 문서는 시스템의 사용성에 대한 신뢰를 높일 것이다. 특히 애플리케이션 작성자가 어떤 구성 요소가 단지 모델을 검색하는지, 아니면 사용을 승인하는지 판단할 수 없다면 상충하는 설명은 그 신뢰를 약화할 것이다.

AI 제품 구매자에게 이러한 신호는 모델 제어 주장을 평가하는 실용적인 방법을 제공한다. 명시된 제한과 거부된 요청을 연결하는 근거를 요구하라. 이어서 그 결정에 어떤 설치된 구성 요소가 참여했는지 물어보라.

개발자에게 지속적인 쟁점은 구성 가능성이다. 즉, 각각 유용한 구성 요소가 결합됐을 때 의도한 동작을 유지하는지 여부다. 모델 통합에는 이러한 특성이 필요하다. 선택, 사용량 측정 및 애플리케이션 인터페이스가 흔히 동일한 요청 흐름을 공유하기 때문이다.

이번 릴리스는 업계 전반의 실패율이나 보편적 해결책에 관한 주장을 뒷받침하지 않으면서도 검토할 구체적인 수정을 제공한다. 그 중요성은 실패의 구체성과 변경된 규칙의 명확성에 있다.

애플리케이션이 제한된 모델 선택에 의존한다면, 업그레이드가 완료됐다고 간주하기 전에 의도한 정책을 현재 동작과 비교하라. 다른 유지 관리자가 결정을 이해할 수 있도록 관련 구성, 설치된 플러그인 버전 및 관찰된 결과를 함께 보관하라. 성공적으로 허용된 요청은 질문의 일부에만 답하므로, 그 근거에는 제외된 선택지도 포함하라. datasette-llm 0.1a10 수정을 계기로 자체 구성 요소가 결정을 어떻게 결합하는지 살펴보라. 유용한 결과는 팀이 허용하는 것과 실행 중인 애플리케이션이 수용하는 것 사이에 문서화된 연결을 만드는 것이다. 배포 환경이 가장 크게 의존하는 제한부터 시작해, 그것이 전체 요청 경로에서 유지되는지 확인하라.