Simon Willison은 최근 Google Sheets에서 SQL 함수로 Datasette 데이터를 가져오는 방법을 소개했다.1 겉으로 보면 "스프레드시트에 데이터 붙이기" 정도의 팁처럼 보이지만, 실제로는 CSV나 SQLite 파일을 팀이 바로 쓸 수 있는 데이터 제품으로 바꾸는 가장 가벼운 경로에 가깝다.
지금 이게 중요한 이유는 분명하다. 많은 팀이 이미 데이터를 갖고 있다. 문제는 활용 방식이다. 파일은 있는데, 사람들은 필터링·검색·공유·재사용을 못 한다. 이때 Datasette는 풀앱을 만들기 전 단계의 빈칸을 메우고, Google Sheets는 여전히 가장 익숙한 소비 인터페이스다. 둘을 연결하면 "데이터는 데이터베이스에 두고, 소비는 스프레드시트에서 한다"는 현실적인 운영이 가능해진다.
스프레드시트와 대시보드 사이, Datasette가 메우는 틈
Datasette를 개발자 장난감처럼 보면 판단을 놓치기 쉽다. 본질은 다르다. SQLite 파일 하나를 읽을 수 있는 웹 데이터 인터페이스로 바꿔서, 테이블 탐색, 필터, SQL 실행, JSON API, 링크 공유를 빠르게 제공하는 도구에 가깝다.
이 포지션이 중요한 이유는, 많은 데이터 프로젝트가 사실 BI 도구까지는 필요 없기 때문이다. Airtable처럼 입력과 협업을 중심으로 한 제품도 아니고, Metabase처럼 조직 단위 분석 체계가 필요한 것도 아니다. 반대로 원시 SQLite 파일을 직접 열게 하는 방식은 협업성이 떨어진다.
여기서 Google Sheets 연동은 의미가 커진다. 사람들은 여전히 숫자를 검토하고, 간단한 계산을 하고, 메모를 붙이고, 다른 시트와 결합하는 일을 스프레드시트에서 한다. Google Sheets는 기본 함수와 Apps Script 기반 확장 지점을 제공하고,2 외부 데이터를 함수나 스크립트로 불러오는 패턴도 익숙하다. 즉 Datasette는 데이터의 "공개·탐색·질의"를 맡고, Sheets는 "소비·가공·공유"를 맡는 식의 역할 분리가 자연스럽다.
실무적으로 보면 이 조합은 특히 이런 경우에 맞는다.
연구 데이터셋을 배포해야 하는데, 매번 CSV를 새로 보내기 싫을 때.
내부 사건 기록이나 로그를 팀이 검색해 보게 하고 싶을 때.
공공기록이나 정제된 결과를 공개하되, 별도 프론트엔드까지 만들 여유는 없을 때.
Airtable, Metabase, Flask보다 나은 순간과 아닌 순간
비교 기준은 화려한 기능보다 도입 비용이다.
Airtable은 입력과 협업은 강하지만, SQLite 파일을 바로 게시하는 발상과는 거리가 있다. 데이터가 이미 파일로 있고, 읽기 중심으로 공유하려면 Datasette 쪽이 더 직선적이다.
Metabase는 대시보드와 시각화엔 강하다. 하지만 "데이터셋 자체를 브라우징 가능하게 공개한다"는 문제에는 다소 무겁다. 질의 결과보다 테이블 자체의 탐색성과 링크 가능성이 중요하면 Datasette가 더 잘 맞는다.
직접 Flask 앱을 만드는 방법도 있다. 물론 자유도는 가장 높다. 대신 인증, 목록 페이지, 필터링, SQL 노출 방식, JSON 응답, 배포까지 모두 직접 책임져야 한다. 작은 팀이나 뉴스룸에는 이 유지비가 생각보다 크다.
반대로 Datasette가 약한 곳도 분명하다. 복잡한 권한 모델, 세밀한 워크플로, 다단계 쓰기 UI, 앱다운 상호작용이 필요하면 어색해진다. 최근 1.0 알파에서 upsert API 개선, CSRF 처리 변경, 테이블 이름 변경 이벤트 같은 변화가 이어지고 있지만,3 이건 어디까지나 도구의 성숙도 향상이지 "앱 프레임워크화"를 뜻하진 않는다. 내부 DB를 임시 디스크로 돌리며 락 문제를 줄이려는 변화도 있었지만, 테스트 환경에서 파일 핸들 이슈가 보고되기도 했다.34 즉 가볍고 빠른 공개·탐색에는 좋지만, 제품 로직이 두꺼워질수록 다른 선택지를 봐야 한다는 뜻이다.
Google Sheets와 붙일 때 진짜 좋아지는 점
이번 뉴스의 핵심은 기술적 신기함보다 운영 방식의 변화다.1
예전에는 누군가 SQLite나 CSV를 갖고 있으면 보통 세 가지 길로 갔다.
그냥 파일을 공유한다.
스프레드시트로 옮기다 깨진다.
아예 앱 개발로 점프한다.
Sheets에서 Datasette를 SQL 함수처럼 다루기 시작하면 중간지대가 생긴다. 데이터 원본은 Datasette에 두고, 필요한 결과만 시트로 가져온다. 그러면 시트는 복사본 저장소가 아니라, 질의 결과를 소비하는 얇은 작업면이 된다. 이 차이는 크다. 데이터 정의와 정리는 한곳에서 하고, 팀별 파생 분석은 각자 시트에서 한다.
이 방식은 QUERY, FILTER, IMPORTRANGE 같은 기존 스프레드시트 습관과도 잘 맞는다.5 차이는 원본이 또 다른 시트가 아니라 Datasette라는 점이다. 즉 시트 간 복붙 체인을 늘리는 대신, SQL을 통해 필요한 결과를 직접 가져오는 쪽이 더 투명하다.
다만 한계도 있다. Sheets는 편하지만 데이터 엔진은 아니다. Google도 데이터가 커지거나 호출이 많아지면 Apps Script 최적화나 외부 DB 대안을 고려하라고 안내한다.2 따라서 Datasette 연동은 "스프레드시트로 모든 걸 해결"하려는 시도가 아니라, 스프레드시트의 한계를 인정한 상태에서 가장 유용한 부분만 활용하는 패턴으로 보는 편이 맞다.
Datasette를 앱처럼 과하게 쓰지 않는 기준
좋은 Datasette 프로젝트는 대개 단순하다.
명확한 데이터셋이 있고,
누가 어떤 질문을 할지 보이며,
링크 공유와 SQL/필터 탐색만으로도 가치가 나온다.
나쁜 프로젝트는 반대다. 로그인 흐름, 복잡한 편집 UI, 업무 승인 절차, 세밀한 멀티테넌시를 붙이기 시작한다. 그러면 "빠른 데이터 제품"의 장점이 사라진다.
판단 기준은 하나다. 사람들이 필요한 것은 "앱"인가, 아니면 "잘 공개된 데이터"인가. 후자라면 Datasette는 매우 강하다. 특히 팀이 이미 SQLite나 CSV를 갖고 있고, 다음 단계가 막막했다면 더 그렇다. 이번 Google Sheets 연결 아이디어가 좋은 이유도 같다. 새 시스템을 도입하는 게 아니라, 이미 익숙한 작업 환경 위에 데이터 접근성을 올려주기 때문이다.1
그래서 지금 신경 써야 할 사람은 개발팀만이 아니다. 뉴스룸, 리서처, 운영팀, 분석가, 작은 SaaS 팀 모두 해당된다. 앱을 만들 준비가 안 됐다고 해서 데이터를 죽은 파일로 둘 필요는 없다. 반대로 앱이 필요할 정도로 요구사항이 두꺼워졌다면, 그때는 Datasette를 졸업하면 된다. 중요한 건 그 사이의 넓은 구간을 너무 자주 무시해왔다는 점이다.
참고
1SQL functions in Google Sheets to fetch data from Datasette
2Google Sheets 확장 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
4is_temp_disk=True leaks files in tests, frequently breaks · Issue #2692 · simonw/datasette · GitHub
5How to Pull Data from Another Google Sheet: 6 Methods [2026]
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.