SQLite에도 실시간 알림을? Honker가 가져온 Postgres의 NOTIFY/LISTEN

SQLite 쓰는 사람들의 오랜 고민

혹시 SQLite로 프로젝트를 만들어보신 적 있나요? 파일 하나로 끝나는 간편함, 서버 설치도 필요 없는 가벼움 덕분에 요즘은 프로덕션에서도 SQLite를 쓰는 사례가 꽤 많아졌어요. Litestream, LiteFS 같은 도구 덕분에 백업이나 복제도 어느 정도 해결됐고요.

그런데 딱 하나, 계속 아쉬웠던 게 있거든요. 바로 실시간 알림 기능이에요. Postgres를 써보신 분들은 아실 텐데, NOTIFY/LISTEN이라는 기능이 있어요. 이게 뭐냐면, 어떤 커넥션이 "야, 이런 일이 일어났어!"라고 메시지를 쏘면, 그 채널을 구독(LISTEN)하고 있는 다른 커넥션들이 실시간으로 그 메시지를 받는 기능이에요. 채팅 알림, 캐시 무효화, 작업 큐 트리거 같은 데 엄청 유용하죠.

SQLite에는 이런 게 없었어요. 그래서 보통은 폴링(polling), 즉 "뭐 바뀐 거 있어? 뭐 바뀐 거 있어?" 하고 주기적으로 물어보는 식으로 처리했는데, 이게 비효율적이기도 하고 지연도 생기죠. 오늘 소개할 Honker는 바로 이 문제를 정면으로 해결하겠다고 나온 라이브러리예요.

Honker가 동작하는 방식

Honker의 핵심 아이디어는 의외로 심플해요. SQLite는 단일 프로세스 안에서 여러 스레드가 공유하는 형태로 주로 쓰이잖아요. 그래서 Honker는 DB 내부에 메시지 테이블을 두고, 거기에 이벤트가 쌓이면 프로세스 내부의 리스너들한테 채널 단위로 전달해주는 구조예요.

사용법을 보면 Postgres의 경험을 그대로 가져왔다는 게 느껴집니다. 특정 채널을 LISTEN하는 리스너를 등록해두면, 어디선가 NOTIFY channel, payload 형태로 메시지를 던질 때 그 리스너가 콜백을 받는 식이에요. 페이로드에 JSON을 실어 보내면 주문 접수, 결제 완료, 파일 업로드 같은 이벤트를 실시간으로 전파할 수 있어요.

기존 SQLite에서 이런 걸 만들려면 파일 감시를 하거나, sqlite3_update_hook 같은 C 레벨 훅을 직접 걸거나, 아니면 애플리케이션 코드에서 이벤트 버스를 따로 만들어서 DB 쓰기와 동기화시켜야 했거든요. 근데 애플리케이션 레벨 이벤트 버스는 DB 트랜잭션이 롤백되면 이벤트만 먼저 나가버리는 문제가 있었어요. Honker는 DB 트랜잭션 안에서 알림을 일으키기 때문에 트랜잭션이 커밋될 때만 이벤트가 전파되는 트랜잭션 안정성이 핵심 장점이에요.

비슷한 접근들과의 비교

생태계에서 비슷한 시도들이 없진 않았어요. Turso의 libSQL은 서버 모드를 도입해서 pub/sub 비슷한 기능을 지원하려고 했고, Rqlite는 래프트(Raft) 합의 알고리즘 기반 클러스터를 제공하면서 이벤트 스트리밍을 붙이려고 했죠. Supabase 같은 서비스는 아예 Postgres의 WAL(Write-Ahead Log)을 읽어서 실시간 구독을 구현했고요.

그런데 Honker는 "SQLite의 단순함을 유지하면서 애플리케이션 임베디드 형태로 pub/sub을 넣자"는 접근이에요. 외부 브로커(Redis, RabbitMQ, Kafka)를 띄울 필요 없이, 이미 존재하는 SQLite 파일 안에서 모든 게 완결되죠. 그래서 작은 서비스, 데스크탑 앱, 엣지 배포, 1인 개발 사이드 프로젝트에 잘 맞아요.

물론 한계도 분명해요. SQLite는 태생적으로 단일 프로세스 환경에서 제일 잘 동작하니까, 여러 서버에 걸친 분산 pub/sub이 필요한 상황이라면 결국 Redis나 NATS 같은 전용 메시지 브로커가 필요할 거예요. Honker는 그 사이의 애매한 지점, 즉 "아직 그 정도 규모는 아닌데 실시간 이벤트는 필요해"라는 구간을 노린 거죠.

한국 개발자에게 주는 시사점

요즘 한국에서도 SaaS를 혼자 만들거나, 소규모 팀이 빠르게 MVP를 내놓는 일이 많잖아요. 그럴 때 인프라를 최소화하고 싶은 욕구가 강하죠. 서버는 Fly.io나 Railway에 SQLite 하나 띄우고, 거기에 Honker를 얹으면 알림/실시간 대시보드/작업 큐의 기반이 바로 생겨요. Redis 호스팅 비용을 아낄 수 있고, 운영 복잡도도 줄어들죠.

또 하나, 로컬 퍼스트(local-first) 앱을 만드는 분들에게도 흥미로운 도구예요. 일렉트론이나 타우리로 데스크탑 앱을 만들 때 내부 모듈 간 이벤트 전달을 DB 트랜잭션과 묶어서 처리할 수 있으니까, UI 업데이트 로직이 훨씬 깔끔해질 수 있어요. "DB에 쓰고 → 이벤트 발행"이 원자적으로 일어난다는 건 버그를 많이 줄여주거든요.

다만 프로덕션에 바로 넣기 전에 확인할 게 있어요. 메시지 유실이 허용되는지, 리스너가 꺼져 있는 동안 들어온 이벤트를 재생해야 하는지, 다중 프로세스로 확장될 가능성이 있는지 같은 질문들이에요. 이 체크리스트를 통과하면 진짜 가벼운 실시간 레이어로 써볼 수 있을 거예요.