코드가 한 줄도 없는 마지막 네 쪽

이 절은 열 장을 다섯 문단으로 압축한다. 260쪽을 한 쪽으로 줄이는 일이니 무언가는 빠질 수밖에 없다. 아래 장치는 그 다섯 문단이 각각 어느 장을 가리키는지 짚어준다. 걸음을 따라 누르면 언급된 장에 불이 켜지고, 이미 켜진 것은 켜진 채로 남는다.

회고가 고른 낱말들

빠진 것을 짚었으니 담긴 것도 보아야 한다. 이 절이 열 장에서 건져 올린 표현들이 저자들이 무엇을 이 책의 성취로 여겼는지 알려준다.

• "데이터를 위한 테이블을 만들지 않고도" — 제5장의 제목이 「Exploring data without persistence」였다. 그 무지속성이 회고에서도 첫 자랑거리로 남았다.
• "SQL 질의와 유창한 질의 양쪽으로" — 제6장의 관계형 API를 fluent queries라 부른다. 두 갈래를 같은 무게로 다뤘다는 뜻이다.
• "얼마나 긴밀하고 효율적으로 pandas 데이터프레임과 통합되는지" — 제6장의 오리 시험을 이렇게 한 줄로 줄였다.
• "DuckDB가 표준 SQL 언어에 더한 모든 좋은 것들(goodies)" — 제3·4장에서 하나씩 표시해둔 확장들을 이 낱말로 묶는다. COLUMNS 람다, EXCLUDE, REPLACE, GROUP BY ALL, 별칭 재참조가 모두 여기 들어간다.
• "데이터 아키텍처에 DuckDB를 통합하는 법을 보이기 위해" — 제8장의 세 도구를 시연으로 규정한다. 도구 자체가 목적이 아니었다는 뜻이다.
• "DuckDB의 데이터를 곧바로 시각화" — 제9장의 요점을 directly 한 낱말에 담았다. 중간 서버가 없다는 것이다.

짧은 절이지만 이 책의 시간적 위치를 못 박는다. 이 책이 출간되면 여러분은 곧 첫 안정 판본을 손에 쥐게 될 것이다. DuckDB 1.0이다. 그리고 자기 작업의 토대를 밝힌다. 우리의 작업은 집필 시점의 최신 사전 배포 판본인 0.10.0에 기반한다. 그 판본의 목적이 모든 기능과 API와 형식을 안정화하고 1.0 판본과 호환되게 하는 것이라고 적는다.

호환성에 대한 약속도 구체적이다. 이 판본들은 데이터베이스 판본 형식 변경을 자동으로 처리하고 하위 호환되며, 부분적으로는 상위 호환까지 된다는 뜻이다. 그리고 한마디를 덧붙인다. 그것이 MotherDuck 서비스에도 확장될 것이다.

이 절이 이 장에서 가장 길고, 가장 값지다. 책의 폭이 넓었음에도 DuckDB의 방대한 생태계에서 모든 것을 다룰 수는 없었다. 그리고 무엇을 뺐는지를 이유와 함께 밝힌다. 이 책의 초점이 입문적이고 실용적인 안내서에 있으므로 DuckDB의 내부, 그것이 어떻게 구현되었고 겉으로 드러나지 않는 곳에서 어떻게 작동하는지는 다루지 않았다.

기술서에서 이 절이 드문 까닭은, 다루지 않은 것을 적는 일이 다룬 것을 적는 일보다 어렵기 때문이다. 무엇이 남았는지 알려면 영역 전체의 지도를 갖고 있어야 한다. 저자들은 여섯 갈래를 짚는다.

가장 짧은 절이며 네 갈래로 나뉜다. 저자들이 DuckDB 문서를 시작하기 좋은 곳이라 부르며 매우 포괄적이고 DuckDB의 모든 면을 아주 자세히 다룬다고 평한다. MotherDuck 문서에 대해서도 같은 말을 한다.

네 갈래의 순서가 눈에 걸린다. 문서 → 영상 → 공동체 → 기여다. 읽는 사람에서 묻는 사람으로, 묻는 사람에서 고치는 사람으로 옮겨가는 배열이며, 오픈소스 도구를 배우는 통상의 경로를 그대로 따른다. 마지막 갈래에 버그와 기능 요청을 함께 적어둔 것도 눈여겨볼 만하다. 기여가 코드만이 아니라는 뜻이다.

저자들의 판단은 분명하다. DuckDB는 데이터 엔지니어링의 미래에서 두드러진 구실을 할 매우 유망한 기술이라고 생각한다. 그 근거로 다재다능함을 든다. 중간 규모 데이터셋의 로컬 분석에서부터 데이터가 사는 곳 가까이 클라우드에서 이루어지는 대규모 데이터 처리까지, 아주 다른 여러 상황에 쓸 수 있는 도구다. 제1장의 임베디드 데이터베이스가 제7장의 하이브리드 실행을 거쳐 제10장의 S3 질의에 이르렀던 그 궤적을 한 문장으로 되짚은 것이다.

네 가지 전망

이 절이 내놓는 예측은 넷이다. 근거의 성격이 서로 다르므로 갈라 읽을 만하다.

• 개인 기기의 사적 데이터 — 건강 모니터링, 홈 오토메이션, 그 밖의 개인 정보 시스템에서 나오는 로컬 데이터가 늘어나면서, 자기 기기에서 사적 데이터를 효율적으로 처리하는 일이 더 중요해질 것이다. 데이터를 서버로 보내지 않는 것 자체가 값이 되는 상황을 가리킨다.
• SQLite가 있는 자리 — SQLite와 비슷하다는 점을 생각하면 DuckDB는 오늘 SQLite가 쓰이는 많은 자리에서 쓰일 것이다. 그 자리를 여섯 가지로 열거한다. 애플리케이션, 게임, 브라우저, 전화, IoT와 엣지 기기이며, 용도는 분석, 데이터 집계, 사전 필터링, 다른 시스템과 최종 사용자에게 데이터 제공이다.
• 클라우드 웨어하우스의 롱테일 — 저자들이 흥미로운 비즈니스 사례라 부르는 것이다. 아래에서 따로 본다.
• 생성 AI와 스트리밍 — 지켜볼 만한 혁신 영역으로 생성 AI 사용 사례와의 통합, 곧 효율적인 임베딩 벡터 저장과 인덱싱을 더하는 것, 그리고 스트리밍 데이터 처리 지원을 든다.

이 문단이 이 책 전체의 논지를 한자리에 모은다. 제10장이 「빅데이터는 죽었다」는 글을 각주로 달고 5,800만 게시물을 랩톱에서 다뤘고, 이 절이 그것을 비용과 복잡도의 문제로 번역한다. 그리고 "훨씬 적은 복잡도"라는 마지막 항목이 실은 가장 무거운 항목이다. 비용은 청구서에 찍히지만 복잡도는 사람의 시간으로 지불되기 때문이다.

마지막으로 저자들이 바라는 방향을 적는다. DuckDB 팀이 사용성에 초점을 두는 것을 생각하면, SQL과 데이터 처리를 더 유연하고 접근하기 쉽고 사용자 친화적으로 만드는 그들의 착상도 기대된다. 그리고 그 작업의 일부로 더 많은 조합 가능성(composability)—시스템의 모든 면을 질의하고 유연하게 결합할 수 있게 되는 것을 예상한다고 적는다.

이 조합 가능성이라는 낱말이 이 책을 통과해온 독자에게는 구체적으로 들린다. 테이블처럼 보이면 질의할 수 있다는 제6장의 원칙, SUMMARIZE를 SELECT의 원천으로 쓸 수 있게 된 제10장의 변화, 데이터프레임을 SQL의 FROM에 이름으로 적는 제9장의 왕복이 모두 그 방향의 사례였다. 더 많은 조합 가능성이란, 더 많은 것이 FROM 뒤에 올 수 있게 된다는 뜻이다.