DuckDB에 클라이언트-서버 프로토콜이 생겼다 — Quack이 바꾸는 것과 바꾸지 않는 것

• 들어가며 — 인프로세스 DB가 서버를 갖는다는 것
• 사실관계부터
• 어떻게 생겼나
• 프로토콜 설계 — 왜 HTTP인가
• 왜 Arrow Flight SQL이 아니었나
• 벤치마크 — 벤더 자체 측정이라는 점부터
  • 이 숫자들을 어디까지 믿을 것인가
• 보안 기본값 — 여기가 제일 조심할 곳
• Quack이 하지 않는 것
• Quack vs DuckLake — 헷갈리기 쉬운 지점
• 그래서, 당신은 써야 하나
• 마치며
• 참고 자료

들어가며 — 인프로세스 DB가 서버를 갖는다는 것

DuckDB의 정체성은 오랫동안 한 문장이었습니다 — 클라이언트도 서버도 없고, 프로토콜도 없고, 그냥 저수준 API 호출만 있다. 2019년 첫 릴리스 이후 DuckDB 팀은 이 인프로세스(in-process) 구조를 꽤 큰 목소리로 자랑해 왔고, 실제로 그게 값을 했습니다. 파이썬 노트북 안에서 분석가가 자기 데이터를 만지작거리는 워크로드, 기존 애플리케이션에 SQL 능력을 덧붙이는 워크로드에서 프로토콜 오버헤드가 0이라는 건 압도적인 이점이니까요.

그런데 2026년 5월 12일, 같은 팀이 Quack: The DuckDB Client-Server Protocol을 발표했습니다. DuckDB 인스턴스 두 개가 네트워크 너머로 서로 이야기하는 프로토콜입니다. 한쪽이 서버가 되고 한쪽이 클라이언트가 됩니다.

이게 흥미로운 건 성능 숫자 때문이 아닙니다. 7년 동안 "우리는 클라이언트-서버가 아니다"를 아키텍처적 신념으로 내세운 프로젝트가 스스로 그걸 붙였다는 사실 때문입니다. 발표 글의 문장이 이 전환을 꽤 솔직하게 설명합니다 — "In the end we care deeply about user experience and perhaps less about having the last word on architecture."

그래서 이 글은 "DuckDB가 이제 서버가 됩니다!"를 반복하는 대신, 무엇이 실제로 가능해졌고 무엇이 여전히 안 되는지를 봅니다. 후자가 훨씬 깁니다.

사실관계부터

하이프를 걷어내려면 날짜와 버전부터 고정하는 게 좋습니다.

• 2026년 5월 12일 — Quack 발표. 이 시점엔 core_nightly 저장소에 있었고, 당시 최신 릴리스인 DuckDB v1.5.2에서 쓸 수 있었습니다.
• 2026년 5월 20일 — DuckDB v1.5.3에서 Quack이 코어 확장으로 승격됐습니다. 이제 처음 쓸 때 투명하게 자동 설치·자동 로드됩니다. 같은 릴리스에서 DuckLake가 Quack을 카탈로그 데이터베이스로 쓸 수 있게 됐습니다.
• 상태: 베타. 1.5.3 릴리스 글의 표현 그대로 — "Quack is still in beta state and breaking changes may happen in the protocol, in function names, etc."
• 안정화 목표: DuckDB v2.0. Quack FAQ는 "as part of DuckDB v2.0 in September 2026"이라고 적고 있고, 릴리스 캘린더는 2.0.0을 "Fall 2026"으로 표기하면서 이 날짜들이 잠정(tentative)이라고 명시합니다. 두 페이지의 표현이 미묘하게 다르니, 9월을 확정으로 읽지는 마십시오.

즉 지금 이 글을 읽는 시점(2026년 7월)에 Quack은 프로토타이핑용입니다. FAQ의 "Is Quack production-ready?" 항목 답이 그냥 "Not yet"입니다.

어떻게 생겼나

사용자 입장에서의 모양은 놀랄 만큼 단순합니다. DuckDB 인스턴스 두 개를 띄우고, 한쪽에서 서버를 시작합니다.

-- DuckDB #1 (서버)
CALL quack_serve('quack:localhost', token = 'super_secret');
CREATE TABLE hello AS FROM VALUES ('world') v (s);

-- DuckDB #2 (클라이언트)
CREATE SECRET (TYPE quack, TOKEN 'super_secret');
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;

붙이고 나면 원격 테이블이 로컬 테이블처럼 보입니다. DDL도, 쓰기도, 트랜잭션도 그대로 전달됩니다.

CREATE TABLE remote_db.t AS FROM range(10) r (i);  -- 원격 DDL
INSERT INTO remote_db.t VALUES (42);               -- 원격 쓰기
FROM remote_db.t WHERE i = 42;                     -- 필터도 원격 실행
BEGIN; ...; COMMIT;                                -- 트랜잭션 전달

붙이지 않고 한 방에 던지는 방법도 있습니다.

FROM quack_query('quack:localhost', 'SELECT 42', token = 'MY_TOKEN');

프로토콜 설계 — 왜 HTTP인가

설계 선택 몇 가지가 눈에 띕니다. 전부 공식 문서의 Overview에 정리돼 있습니다.

HTTP 기반. 발표 글의 논리는 방어적이라기보다 실용적입니다 — "It would be rather misguided not to build a database protocol on top of HTTP in 2026." 이유도 명료합니다. 로드밸런싱, 인증, 방화벽, 침입 탐지 — HTTP는 이 인프라 전부가 이미 다룰 줄 아는 계층이니까요. 커스텀 와이어 전송을 새로 운영할 필요가 없습니다. 부수 효과도 하나 있습니다. DuckDB-Wasm 배포판이 Quack을 네이티브로 말할 수 있어서, 브라우저 안의 DuckDB가 EC2에 있는 DuckDB에 직접 붙습니다.

application/duckdb 직렬화. 새 MIME 타입을 만들었고, 인코딩은 DuckDB 내부 직렬화 기본기를 그대로 씁니다 — WAL 파일에 쓰던 바로 그 코드 경로입니다. 문서의 설명으로는 이렇게 하면 교환 포맷을 경유하지 않아도 되고, 중첩 타입·decimal·interval 같은 복잡한 타입이 무손실로 건너갑니다.

클라이언트 주도 요청-응답. 모든 상호작용은 클라이언트가 시작합니다. 서버가 먼저 밀어 넣는(push) 동작은 없습니다.

쿼리당 왕복 1회. 연결 핸드셰이크 이후, 쿼리 하나는 요청-응답 쌍 하나로 끝납니다. 큰 결과는 후속 FETCH 요청으로 청크 단위로 흘러오고, 이건 여러 스레드로 병렬화할 수 있습니다.

기본 포트 9494. 94는 넷스케이프 네비게이터가 나온 해라서 외우기 쉽다는 게 팀의 설명입니다.

여기서 DuckDB 팀이 자기 이력을 활용하는 대목이 재밌습니다. 이 사람들은 2017년에 Don't Hold My Data Hostage — A Case for Client Protocol Redesign(Raasveldt·Mühleisen, VLDB 2017)이라는 논문을 썼습니다. 큰 결과셋을 DB에서 클라이언트로 옮기는 게 얼마나 비싼지, 기존 프로토콜들이 왜 비효율적인지를 실측한 논문이죠. 9년 뒤 그 논문의 저자들이 프로토콜을 처음부터 설계할 기회를 얻은 셈입니다.

왜 Arrow Flight SQL이 아니었나

당연한 질문이고, 발표 글도 부록을 따로 붙여 답했습니다. 이유는 두 갈래입니다.

하나는 기술적입니다. Arrow Flight SQL에는 "one fateful design decision"이 있다는 게 팀의 지적입니다 — "every single query requires at least two protocol round trips, CommandStatementQuery and DoGet." 왕복 2회는 작은 업데이트, 특히 지연이 큰 환경에서 불리합니다. Quack이 왕복 1회에 집착한 이유가 여기 있습니다.

다른 하나는 정치적입니다. 그리고 이쪽이 더 솔직합니다 — "We feel that in order to be able to keep innovating in data systems, we cannot allow ourselves to be restricted by formats that are controlled externally." 즉 외부가 통제하는 포맷에 묶이기 싫다는 겁니다. 새 데이터 타입이나 프로토콜 메시지를 추가하고 싶으면 내일 배포할 수 있어야 한다는 것.

이건 기술적 우열의 문제가 아니라 거버넌스 선호입니다. 팀도 Arrow와 ADBC의 가치를 인정합니다 — ODBC·JDBC의 후계자로서 시스템 간 데이터 교환 마찰을 줄이는 인터체인지 API로는 "works pretty well"이라고 적었습니다. 다만 DuckDB 내부에서 교환 포맷을 쓰는 데는 경계심이 있다는 것이고, FAQ는 이를 "clean slate implementation from the core DuckDB team"이자 "does not have any third-party dependencies"로 정리합니다.

읽는 사람 입장에서 이 대목은 그대로 받아들이되, 함의는 계산해 둘 필요가 있습니다. Quack은 DuckDB 전용입니다. 클라이언트도 서버도 DuckDB여야 합니다. Arrow Flight SQL의 장점 — 이기종 시스템이 같은 프로토콜로 말한다 — 을 Quack은 설계상 포기했습니다. 그 자리를 메우는 서드파티 대안으로 airport 확장과 GizmoSQL이 여전히 존재하고, 발표 글은 GizmoSQL의 Philip Moore가 "이 길을 먼저 닦았다"고 감사를 표합니다.

벤치마크 — 벤더 자체 측정이라는 점부터

이제 숫자입니다. 먼저 못을 박아 두겠습니다. 아래 벤치마크는 전부 DuckDB 팀이 직접 설계하고 직접 돌린 벤더 자체 측정입니다. 자기 프로토콜을 발표하는 글에서 자기가 만든 프로토콜이 이깁니다. 놀랄 일이 아니고, 그 자체로 부정직한 것도 아닙니다 — 다만 어디를 재고 어디를 안 쟀는지를 봐야 합니다.

측정 환경은 명시돼 있습니다. AWS m8g.2xlarge(vCPU 8, RAM 32GB, 네트워크 "up to 15 Gbps"), Ubuntu on Arm, 클라이언트와 서버는 같은 가용 영역의 서로 다른 머신, 인스턴스 간 핑 평균 약 0.280 ms. 중앙값 5회 측정. 벤치마크 스크립트도 공개돼 있습니다. 이 정도면 벤더 벤치마크치고는 성실한 편입니다.

벌크 전송 — TPC-H lineitem 테이블의 행 수를 늘려 가며 전송한 벽시계 시간(낮을수록 좋음).

작은 쓰기 — lineitem과 같은 구조의 빈 테이블에 한 행씩 각각의 INSERT 트랜잭션으로 5초간 삽입, 병렬 스레드 수를 늘려 가며 측정한 초당 트랜잭션(높을수록 좋음).

이 숫자들을 어디까지 믿을 것인가

팀이 스스로 밝힌 캐비엇이 하나 있습니다. 벌크 전송 표 아래에 이렇게 적혀 있습니다 — "In fairness we have to mention that the standard PostgreSQL clients do not parallelize reads over multiple threads, but Quack and Arrow can." 즉 PostgreSQL의 158초에는 "표준 클라이언트가 단일 스레드로 읽는다"는 핸디캡이 섞여 있습니다. 이걸 발표 글이 직접 적어 둔 건 점수를 줄 만합니다.

Arrow Flight 쪽도 조건을 봐야 합니다. 비교 대상 Arrow Flight는 GizmoSQL 서버가 제공했고, 그 서버는 내부적으로 DuckDB를 씁니다. 그러니까 이건 "Arrow Flight 프로토콜의 이론적 최선"이 아니라 "특정 구현 하나"입니다. 프로토콜 비교라기보다 구현 비교에 가깝습니다.

쓰기 벤치마크의 프레이밍은 후하게 잡혀 있습니다. 한 행씩 개별 트랜잭션으로 INSERT하는 워크로드는 PostgreSQL이 태어난 목적 그 자체이고, 컬럼 지향 분석 엔진이 잘할 이유가 없는 일입니다. 그런데 8스레드까지 Quack이 이깁니다. 여기서 팀은 자기 발등을 스스로 찍습니다 — "Beyond that, we hit a current limitation of DuckDB itself in concurrent insertions per second into the same table. PostgreSQL scales better here, which is something to look into for us in the near future." 최대 약 5,500 tx/s에서 천장을 치고, 그 위로는 PostgreSQL이 더 잘 확장된다는 걸 자기 입으로 말한 겁니다. 벤치마크 표가 8스레드에서 끝나는 이유가 그것입니다.

한 가지 산수. 발표 글은 60M 행을 "76 GB in CSV format!"이라고 소개합니다. 그런데 76GB를 4.94초에 옮겼다면 초당 15.4GB, 약 123Gbps입니다. 명시된 회선이 "up to 15 Gbps", 즉 초당 약 1.9GB이니 물리적으로 불가능합니다. 76GB를 그 회선에 그대로 흘리면 최소 40초는 걸립니다. 결론은 어렵지 않습니다 — 76GB는 데이터셋의 CSV 환산 크기를 실감시키려는 표현이지, 회선에 흐른 바이트가 아닙니다. Quack의 바이너리 표현은 CSV보다 훨씬 조밀합니다. 발표 글이 거짓말을 한 건 아니지만, 두 숫자를 나란히 놓고 "초당 15GB"를 상상하면 그건 독자가 속은 겁니다.

무엇을 안 쟀나. 전부 같은 가용 영역, 핑 0.280ms입니다. WAN 너머나 지연이 큰 환경의 숫자는 없습니다. 이건 은근히 중요한데, Quack이 왕복 1회에 공을 들인 이유가 바로 "latency-sensitive environments"였기 때문입니다. 그 설계가 실제로 값을 하는 고지연 환경의 측정치가 정작 빠져 있습니다. TLS를 켰을 때의 비용도 없습니다(기본값이 평문이라 벤치마크도 평문일 가능성이 높습니다). 동시 읽기와 쓰기가 섞인 혼합 워크로드도 없습니다.

정리하면 — 벌크 전송이 빠르다는 주장은 재현 스크립트까지 있어 신뢰할 만하고, 방향성은 놀랍지 않습니다(컬럼 지향 바이너리 전송이 Postgres의 행 기반 프로토콜을 압도하는 건 2017년 논문의 결론이기도 합니다). 다만 "Quack이 PostgreSQL보다 빠른 DB"라는 식으로 읽으면 안 됩니다. 저 표는 프로토콜 전송 벤치마크지 쿼리 엔진 벤치마크가 아닙니다.

보안 기본값 — 여기가 제일 조심할 곳

Security 문서의 첫 문장이 무섭습니다. Quack 서버는 밑에 깔린 DuckDB 인스턴스의 SQL 표면 전체를 노출합니다 — 그 세션이 볼 수 있는 모든 테이블에 대한 읽기와 쓰기를 포함해서요.

그래서 기본값이 보수적으로 잡혀 있습니다.

• 서버가 시작할 때 랜덤 인증 토큰을 생성하고, 클라이언트는 매 연결마다 그걸 제시해야 합니다.
• 서버는 localhost에만 바인딩합니다. 외부에서 닿는 주소로 열려면 allow_other_hostname => true를 명시적으로 넘겨야 합니다.
• TLS는 서버가 직접 하지 않습니다. localhost 통신에 TLS 인프라를 끌어오는 건 의존성만 늘고 실익이 없다는 게 이유입니다.

그리고 발표 글의 권고는 단호합니다 — "We do not recommend opening up a DuckDB Quack endpoint directly to the Internet." 대신 nginx 같은 검증된 HTTP 리버스 프록시를 앞에 두고 거기서 TLS를 종료하라고 합니다. 클라이언트 쪽은 비로컬 URI에 대해 기본적으로 HTTPS를 가정합니다(재정의 가능).

인증·인가 모델은 DuckDB답게 확장으로 밀어 놨습니다. 발표 글의 표현이 정직합니다 — "We are likely unable to capture everyone's use case, certainly not in a first release. The smart thing is therefore not to try." 그래서 기본 인증 함수와 "전부 허용"인 기본 인가 함수를 주되, 둘 다 사용자 코드로 갈아끼울 수 있게 했습니다. LDAP를 조회하든 텍스트 파일을 읽든 주사위를 굴리든 알아서 하라는 겁니다. 콜백을 그냥 SQL 매크로로 써도 됩니다.

실무 관점의 번역: 기본 설정으로는 안전하지만, 유용하게 만드는 순간 안전 장치를 하나씩 끄게 됩니다. allow_other_hostname => true를 켜는 순간 당신은 "그 DuckDB 세션이 보는 모든 테이블에 대한 읽기·쓰기 권한이 딸린 평문 HTTP 엔드포인트"를 열게 되고, 인가 함수는 기본적으로 모든 쿼리에 "예"라고 답합니다. 프록시와 인가 콜백은 선택이 아니라 필수라고 읽는 게 맞습니다.

Quack이 하지 않는 것

여기가 이 글의 핵심입니다. FAQ가 고맙게도 명시적으로 답해 둔 항목들입니다.

분산 쿼리 처리를 하지 않습니다. FAQ 원문 그대로 — "Does DuckDB with Quack support distributed query processing? Currently, DuckDB with Quack does not support distributed query processing." Quack은 여러 클라이언트가 하나의 서버에 붙는 구조입니다. 여러 노드가 하나의 쿼리를 나눠 처리하는 게 아닙니다. "쿼리가 한 대에 안 들어간다"는 문제는 Quack으로 풀리지 않습니다. 발표 직후 커뮤니티에서 "수평 확장 문제를 풀었다"는 반응이 나왔지만(InfoQ 보도에 인용된 반응들 중 하나입니다), 문서가 말하는 바는 그게 아닙니다. Quack은 접근을 확장하지 연산을 확장하지 않습니다.

용량에 천장이 있습니다. FAQ의 DuckLake 비교 항목에 숫자가 있습니다 — Quack 서버는 DuckDB 네이티브 DB 포맷을 쓰고, 이건 "scale up to a few terabytes" 수준입니다. 페타바이트급이 필요하면 그건 DuckLake(또는 Iceberg류)의 영역이라고 문서가 직접 안내합니다.

쓰기 동시성에 천장이 있습니다. 위에서 본 약 5,500 tx/s, 8스레드 너머로는 DuckDB 자체 한계. 팀은 개선하겠다고 적었지만("we plan to work on greatly increasing the transactions per second achievable"), 그건 미래형입니다. 지금 초당 수만 건의 쓰기가 필요하면 이건 답이 아닙니다. FAQ가 "OLTP 워크로드에 쓸 수 있나"에 "Yes"라고 답하긴 하는데, 붙은 단서가 "a few thousand writes per second on a server with 8 CPUs and 32 GB RAM"입니다. "몇천"이 당신 숫자와 맞는지는 당신만 압니다.

아직 베타입니다. 프로토콜, 함수 이름, 기본 설정 전부 깨질 수 있습니다.

그리고 반대편으로 중요한 것 하나. 인프로세스 모델은 죽지 않습니다. FAQ가 이것도 못 박습니다 — "Yes, DuckDB as an in-process database will continue working just as it did before, and we will treat the in-process deployment model as a first-class citizen in the DuckDB ecosystem." Quack은 방향 전환이 아니라 덧셈입니다. 노트북에서 Parquet 훑는 사람은 이 글을 안 읽어도 됩니다.

Quack vs DuckLake — 헷갈리기 쉬운 지점

둘 다 "멀티플레이어 DuckDB"를 표방하고, 둘 다 확장이고, 둘 다 여러 writer를 허용합니다. 그래서 헷갈립니다. FAQ가 정리한 차이는 이렇습니다.

발표 글은 "part of this could also already be achieved with DuckLake, Quack makes this far simpler and provides far higher performance"라고 적습니다. 다만 이건 동시 쓰기 접근이라는 좁은 축에서의 이야기이고, 두 물건의 목적이 같지 않습니다.

그리고 둘은 배타적이지 않습니다. v1.5.3부터 DuckLake는 Quack을 카탈로그 데이터베이스로 쓸 수 있습니다. FAQ의 권고가 명료합니다 — 데이터가 거대하거나 타임 트래블이 필요하면, DuckLake를 쓰되 그걸 Quack으로 서빙되는 DuckDB 인스턴스를 통해 접근하라. 발표 글이 예고한 다음 단계도 이 방향입니다. DuckDB 서버 자체가 원격 접근 가능한 DuckLake 카탈로그 서버가 되는 것. 데이터 인라이닝 성능에서 이득을 기대한다고 적혀 있습니다.

DuckLake의 기본 개념 — 메타데이터를 수많은 JSON·Avro 파일이 아니라 SQL 데이터베이스에 두는 발상 — 은 DuckDB 실전 편에서 이미 다뤘습니다.

그래서, 당신은 써야 하나

값을 하는 경우

• 여러 프로세스가 같은 DuckDB 데이터베이스에 동시에 읽고 써야 한다. FAQ가 첫 번째로 드는 시나리오입니다. 발표 글의 예시가 구체적입니다 — 텔레메트리를 수집하는 프로세스 여러 개가 같은 DB에 삽입하는 동시에, 대시보드가 같은 테이블을 조회하는 상황. 지금까지 이건 DuckDB로 그냥 안 되던 일이었고, 사람들은 커스텀 RPC를 짜거나 Postgres로 갈아탔습니다.
• 데이터가 서버에 있고 연산을 데이터 가까이 붙이고 싶다. 큰 서버가 처리하고 결과만 노트북에서 본다.
• 큰 결과셋을 클라이언트로 자주 끌어내린다. 저 벌크 전송 숫자가 실제로 값을 하는 지점입니다.
• 브라우저(Wasm)에서 원격 DuckDB에 붙어야 한다. HTTP 기반 선택의 직접적 배당금입니다.
• 지금까지 DuckDB에 클라이언트-서버를 붙이려고 손으로 RPC를 짜고 있었다. 그 코드를 지울 수 있습니다.

아직 아닌 경우

• 프로덕션. 베타입니다. 팀이 그렇게 말합니다.
• 분산 쿼리 처리가 필요하다. 설계상 없습니다.
• 진짜 OLTP. 초당 수만 트랜잭션, 높은 쓰기 동시성 — Postgres를 쓰십시오. DuckDB 팀조차 8스레드 위로는 Postgres가 낫다고 적었습니다.
• 페타바이트급. DuckLake나 Iceberg의 영역입니다.
• 인프로세스로 충분하다. 대부분의 DuckDB 사용자가 여기 해당합니다. 프로토콜 오버헤드 0을 굳이 버릴 이유가 없습니다.
• 이기종 클라이언트가 붙어야 한다. Quack은 양쪽 다 DuckDB여야 합니다. Java 앱이나 Go 서비스가 직접 말하는 게 아닙니다.

마치며

Quack에서 가장 흥미로운 건 프로토콜 설계가 아니라 그 뒤의 판단입니다. DuckDB 팀은 인프로세스 아키텍처를 브랜드로 삼아 온 팀입니다. 그런데 사람들이 그 위에 클라이언트-서버를 억지로 붙이는 workaround를 하도 많이 만들어서 — 커스텀 RPC, Arrow Flight를 얹은 GizmoSQL, MotherDuck의 자체 프로토콜, 심지어 Postgres 안에 DuckDB를 넣는 pg_duckdb — 결국 "이건 사람들이 진짜 원하는 것"이라고 인정했습니다. 발표 글이 이 과정을 "we bit the bullet, eventually, finally"라고 표현합니다. 아키텍처 순수성보다 사용자 경험을 택했다는 자기 설명이 그대로 붙어 있고요.

그 결과는 정직하게 말하면 범위가 좁습니다. DuckDB가 분산 쿼리 엔진이 되지도 않았고, Postgres 대체재가 되지도 않았습니다. 수 테라바이트짜리 단일 서버에 여러 DuckDB 클라이언트가 붙어 동시에 읽고 쓸 수 있게 됐을 뿐입니다. 다만 "뿐"이라고 하기엔, 그게 정확히 사람들이 7년 동안 workaround를 만들어 온 이유이기도 합니다.

그리고 늘 그렇듯 — 벤더 벤치마크가 아니라 당신 워크로드로 판단하십시오. 저 표들은 같은 가용 영역, 0.280ms 핑, 평문 HTTP, 재현 스크립트가 공개된 조건에서 나온 DuckDB 팀 자신의 측정입니다. 성실하게 측정된 벤더 벤치마크는 여전히 벤더 벤치마크입니다. 당신의 지연, 당신의 TLS, 당신의 혼합 워크로드에서 같은 그림이 나오는지는 v2.0이 나온 뒤에 직접 재 보는 게 맞습니다.

참고 자료

• Quack: The DuckDB Client-Server Protocol (DuckDB 팀, 2026-05-12) — 발표 글. 설계 근거, 벤치마크, Arrow Flight SQL을 안 쓴 이유(부록)
• Quack 프로젝트 페이지 — 개요와 아키텍처 다이어그램
• Frequently Asked Questions for Quack — 분산 쿼리 미지원, 베타 상태, DuckLake와의 차이 등 핵심 한계가 여기 있습니다
• Quack Remote Protocol — 공식 문서 Overview — 프로토콜 요약과 클라이언트·서버 사용법
• Quack 문서 — Security — 노출 모델과 인증·인가 콜백
• DuckDB 1.5.3: Not an Ordinary Patch Release (2026-05-20) — Quack의 코어 확장 승격, DuckLake 카탈로그 연동
• Announcing DuckDB 1.5.0 (2026-03-09) — Variegata 릴리스
• DuckDB 릴리스 캘린더 — v2.0.0 일정(잠정)
• Don't Hold My Data Hostage — A Case for Client Protocol Redesign (Raasveldt·Mühleisen, VLDB 2017) — 이 프로토콜 설계의 지적 뿌리
• Quack 벤치마크 스크립트
• DuckDB Quack: Client/Server Protocol over HTTP for Multi-User Analytics (InfoQ, Renato Losio, 2026-05-31) — 외부 보도와 커뮤니티 반응
• DuckDB 실전 — 노트북에서 끝내는 임베디드 분석의 시대 (관련 글)