dding-g/GlueSQL.md

## GlueSQL.md

      
    Raw
  

              GlueSQL.md
            
          
    🧩 개요


오픈소스 컨트리뷰션 GlueSQL 멘티로 참여하게 되었습니다.
해당 프로젝트를 분석하고, 기여할 수 있는 방향성을 고민한 결과를 공유드립니다.


🔍 분석 방향

Claude Code를 활용하여 프로젝트의 기본 설계와 구조를 파악하고, 기여 방향성을 도출해보았습니다.

큰 성과는 없었지만, 기본적인 프로젝트 구조와 Document 구성을 학습할 수 있었습니다.


🚀 기여 방향

1. Frontend 지식과의 연결


보유한 Frontend 지식이 녹아들 수 있는 기여가 가장 이상적이라고 생각했습니다.
이미 좋은 상태관리 툴과 캐싱 전략이 존재하므로, 성능과 사용성 측면의 이점이 없다면 굳이 새로 만들 필요는 없다는 결론에 도달했습니다.

2. gluesql 자체 기여 vs 새로운 Feature 개발


GlueSQL 자체에 기여하거나, GlueSQL을 활용한 새로운 Feature 개발 — 두 가지 방향성을 고민하게 되었습니다.

3. 활용 기반 접근


프로젝트를 어떻게 활용할 수 있을까 고민하면서 기여할 수 있는 시나리오를 구상하게 되었습니다.

🔧 WASM + GlueSQL을 활용한 실험


GlueSQL은 다양한 언어 인터페이스를 지원하며, 특히 브라우저 환경에서 WebAssembly 기반 DB 활용이 가능합니다.
사용 방식을 탐색해보고자, 간단한 슈팅 게임을 만들어보았습니다.

👉 gluesql-game-test

💡 상태관리 라이브러리로의 확장 가능성?


GlueSQL 기반 상태관리 라이브러리를 만들어볼까 고민해보았지만,

👉 이미 벤치마킹한 사례가 있으며, WASM 오버헤드로 인해 JS보다 성능이 떨어진다고 합니다.

📎 관련 글


🔎 GlueSQL Docs의 검색 기능 개선 제안

현재 GlueSQL 공식 Docs에는 검색 기능이 존재하지 않습니다.

이에 다음과 같은 개선 아이디어를 고민해보았습니다.
1. gluesql 자체 indexing을 이용한 빠른 검색 기능 추가


Docs 내에 직접적인 검색 기능을 붙이는 접근

2. Client-side Search Engine 구축


정적 웹사이트에서의 검색 구현 사례를 참고하여,

검색 인덱싱 → DB화 → 검색 UI의 흐름을 구현해볼 수 있음.

3. Claude Code 기반으로 비교한 Client Search Engine 분석


전문 보기

🎯 결론 및 권장사항

[장점]
1. 뛰어난 검색 성능: 10~50ms 응답 속도
2. 오프라인 지원: 네트워크 불필요
3. SQL 기반 복잡한 쿼리 지원
4. 대용량 문서에도 확장성 뛰어남
5. 실시간 검색 UX

[단점]
6. 초기 인덱싱 로딩 시간: 약 1~2초
7. 메모리 추가 사용량: 10~20MB
8. 번들 크기 증가: 3~5MB (WASM 포함)
9. 구현 난이도 높음

[권장 시나리오]
- 문서 수: 100~1000개 수준
- 필터링, 정렬, 집계 등 복잡한 검색 요구
- 오프라인 사용 우선
- 입력 즉시 결과가 필요한 실시간 검색


💭 마무리


GlueSQL을 활용한 client 기반 검색엔진을 만들어보는 방향성에 대해 고민 중입니다.
이 외에도 다양한 방식으로 기여할 수 있다면 적극적으로 참여할 예정입니다.


Ideation 차원에서 검토해주시면 감사하겠습니다.
No results found