Hacker News 의견

• AES-GCM의 nonce 재사용 민감도는 구현 시 까다로운 부분임
  문서에서는 이를 인지하고 있지만 해결 방법을 공유하지 않았음
  헤더에 12바이트 대신 16바이트 nonce가 포함되어 있고, 어떤 바이트가 랜덤인지 명시되지 않아 혼란스러움. 혹시 내가 놓친 부분이 있는지 궁금함

  • 정적 키를 사용하고, 12바이트 랜덤 nonce를 생성하며, 임시 버퍼에는 세션별 키를 사용하지 않는 구조임

• DuckDB 팀의 성과에 계속 놀라고 있음
  예전에 OpenSSL로 DuckDB 파일을 암호화하는 단순한 솔루션을 만들었는데, 첫 쿼리 시 2배의 실행 시간이 걸리고 메모리도 많이 사용했음
  반면 DuckDB는 페이지 단위 암호화와 CPU의 AES 가속을 활용해 읽기/쓰기 비용이 거의 없는 수준임

  • 왜 그냥 LUKS를 쓰지 않는지 궁금함
    커널 레벨에서 가속을 활용하고, 상위 애플리케이션에는 투명하게 동작함
    여러 앱이 각기 다른 ACL과 키를 써야 하는 경우가 아니라면 DB 자체 암호화는 불필요함
  • 솔직히 말해 DuckDB의 작업이 “놀라운” 수준은 아니라고 생각함
    단순한 전체 파일 암호화 방식과 비교하면 당연히 좋아 보이지만, 이는 기본적인 수준의 구현임
    우리 스스로도 이런 수준의 품질을 목표로 해야 함
  • 결국 파이프라이닝 덕분임
    저장소 입출력에 비하면 암호화 비용은 거의 무료에 가까움

• MotherDuck 외에 다중 사용자용 클라우드 기반 DuckDB를 잘 운영하는 모델이 있는지 궁금함
  일반 DB처럼 여러 사용자가 동시에 접근하면서 DuckDB의 장점을 그대로 활용할 수 있는 구조를 찾고 있음

  • 순수 DuckDB만 쓴다면 Arrow Flight 서버를 앞단에 두거나 httpserver 확장을 사용할 수 있음
    .duckdb 파일을 어디에 저장하느냐(S3 vs EFS)에 따라 성능 차이가 큼
    하지만 DuckLake가 더 나은 멀티플레이어 옵션으로 보임
    우리는 DuckLake를 제품에 사용 중이며, 성능 저하를 줄이기 위해 분석용 테이블은 GCP Filestore 같은 빠른 스토리지에 저장함
    하나의 DuckLake 카탈로그 안에서도 여러 스토리지 방식을 혼합할 수 있어 유연함
  • 요즘 “Postgres 안의 DuckDB”라는 글을 자주 보는데, 아마 그게 원하는 형태일 것 같음
  • GizmoSQL도 참고할 만함

• DuckDB는 지금까지 써본 AI 도구들보다 더 유용했음
  LLM을 좋아하지만, 실제 업무 효율에서는 DuckDB가 훨씬 큰 도움을 줌

• 키의 인덱싱 처리 방식이 궁금함
  검색 시 키를 암호화한 상태로 찾는지, 아니면 블록마다 복호화를 수행하는지 알고 싶음

• “SQLite 암호화 확장은 2000달러 유료 애드온”이라는 말이 있지만,
  SQLiteMultipleCiphers는 오래전부터 무료로 제공되고 있음
  또한 Turso Database는 기본적으로 암호화를 지원함

  • 실제로 Python이나 Go에서 이런 변형된 SQLite를 플러그인과 함께 빌드해 사용하는 방법이 궁금함
    언어별로 링크 과정이 까다로워 보임
  • SQLCipher도 있음
    2009년부터 개발되어 안정적으로 동작하는 솔루션임