QueryDock Database Client 시리즈 15종이 모두 출시되었습니다. MySQL·MariaDB부터 Redis까지, 계획했던 데이터베이스 클라이언트를 각 DB의 특성에 맞춰 하나씩 구현하고 공개했습니다. 이제 QueryDock은 단순히 출시 숫자를 늘리는 프로젝트가 아니라, 실제 사용자의 의견을 반영하며 계속 다듬어 가는 모바일 데이터베이스 클라이언트 제품군으로 출발합니다.
15개의 QueryDock Database Client
이번 시리즈는 하나의 앱 안에서 모든 데이터베이스를 다루는 방식이 아니라, 데이터베이스별로 앱을 나누는 방식으로 완성했습니다. 출시된 앱은 다음 15종입니다.
- MySQL & MariaDB
- Apache CouchDB
- Cassandra & Scylla
- ClickHouse
- DuckDB
- Elasticsearch & OpenSearch
- Firebird
- IBM Db2
- InfluxDB
- MS-SQL
- MongoDB
- Neo4j
- Oracle Database
- PostgreSQL
- Redis
데이터베이스마다 연결 방식과 인증 방식이 다르고, 사용자가 먼저 확인해야 하는 정보도 다릅니다. 관계형 DB는 스키마와 트랜잭션, 문서 DB는 인덱스와 검색 결과, 그래프 DB는 노드와 관계, 시계열 DB는 시간 범위와 변화 추이를 중심으로 경험을 설계해야 합니다. 그래서 공통 화면을 복제한 뒤 이름과 드라이버만 바꾸는 방식으로는 각 데이터베이스의 장점을 충분히 살리기 어렵다고 판단했습니다.
각 앱은 데이터베이스의 작업 흐름에 맞춰 특화된 기능을 구현했고, 앱들 사이에 소스코드를 재활용하거나 공유하지 않고 모두 처음부터 작성했습니다. 기술적으로는 매우 비효율적인 선택입니다. 하지만 앱마다 색상과 이름만 다른 붕어빵처럼 보이게 하기보다, 사용자가 선택한 데이터베이스에 맞는 도구라는 느낌을 주고 싶었습니다. 이 결정은 개발 속도를 늦췄지만, 15개 앱을 각각 하나의 제품으로 바라보게 만든 기준이 되었습니다.
데이터베이스 이름 대신 QueryDock을 사용하게 된 이유
처음에는 앱 이름을 “MySQL & MariaDB Client”, “PostgreSQL Client”처럼 각 데이터베이스 이름을 직접 포함하는 방식으로 정했습니다. 그러나 여러 데이터베이스 상표와 제품명 사용 문제를 검토하면서, 앞으로의 제품군을 표현할 자체 브랜드가 필요하다는 결론에 도달했습니다. 그래서 데이터베이스 이름은 앱이 지원하는 대상과 설명에 사용하고, 제품 브랜드는 QueryDock으로 분리했습니다.
기존에 출시한 SQLite Client는 그대로 유지합니다. SQLite는 다른 데이터베이스 제품명과 사용 맥락이 다르고 상표 사용에 비교적 관대한 편이어서 현재 이름을 바꿀 필요가 없다고 판단했습니다. 앞으로 새로 출시하는 데이터베이스 클라이언트에는 QueryDock이라는 이름을 붙여, 특정 데이터베이스 회사의 공식 제품으로 오해되지 않는 독립적인 클라이언트 브랜드를 만들어 가겠습니다.
개발 과정에서 만난 네 가지 난관
15개의 데이터베이스를 다루는 일은 연결 화면을 15번 만드는 작업과 달랐습니다. 공식 지원 범위, 테스트할 수 있는 환경, UI 구조, 버전별 호환성이 앱마다 달랐고, 각 문제를 따로 확인해야 했습니다.
1. Firebird의 Android 미지원 문제
Firebird는 Android를 공식적으로 지원하는 라이브러리를 제공하지 않습니다. 따라서 공개된 소스를 바탕으로 Android에서 동작할 수 있도록 직접 포크하고 수정하는 작업이 필요했습니다. 단순히 의존성을 추가하는 수준이 아니라 빌드 환경, 네이티브 연동, 실제 연결 흐름을 함께 확인해야 했습니다. Firebird 공식 문서와 공개 저장소를 참고하면서 지원 가능한 범위를 보수적으로 정리했습니다.
2. 유료 계정이 필요한 데이터베이스의 테스트 공백
모든 기능을 검증하려면 유료 계정이나 특정 운영 환경이 필요한 데이터베이스도 있습니다. 이런 기능은 공식 문서를 여러 번 확인하고 실패 가능성을 낮추는 방향으로 구현했지만, 실제 유료 환경에서 충분히 반복 테스트하지 못한 부분이 남아 있습니다. 이 글을 통해 테스트 범위의 한계도 함께 공개하는 이유입니다. 기능이 동작할 것이라는 추정과 다양한 환경에서 검증되었다는 사실은 다르기 때문입니다.
3. Navigation 3 전환으로 인한 UI 불안정
개발 도중 UI 구조를 Navigation 3로 변경하면서 화면 이동, 상태 복원, 백 스택 처리 등이 의도와 다르게 동작하는 경우가 많았습니다. Navigation 3 관련 지침을 다시 학습하고, 여러 차례 정밀 리뷰를 거쳐 문제를 수정했습니다. 현재도 다양한 화면 크기와 복잡한 이동 경로에서 계속 테스트해야 하는 영역으로 보고 있습니다. Navigation 3의 공식 문서와 Android의 최신 권장 방향도 함께 확인하며 유지보수하고 있습니다.
4. 데이터베이스별 특성과 버전별 breaking change
각 데이터베이스의 동작 방식이 너무나 다르고, 같은 데이터베이스라도 버전에 따라 breaking change가 발생합니다. 우선 최신 버전을 기준으로 기능을 구현하고 이전 버전도 가능한 범위에서 폭넓게 지원하려고 했지만, 모든 버전과 배포 환경을 커버할 수는 없었습니다. 연결에 성공하더라도 권한, 서버 설정, 확장 기능, 클라우드 제공 방식에 따라 결과가 달라질 수 있다는 점도 계속 확인하고 있습니다.
사용자와 함께 만드는 데이터베이스 클라이언트
QueryDock Database Client 시리즈는 출시로 끝나는 제품군이 아닙니다. 실제 사용자가 어떤 화면에서 작업을 멈추는지, 어떤 연결 환경이 필요한지, 어떤 기능을 더 안전하게 제공해야 하는지를 사용자 의견과 리뷰를 통해 배우려고 합니다. 특히 ANR이나 크래시가 보고되면 원인을 우선적으로 확인하고 가능한 한 즉각 대응하겠습니다.
15개 앱을 모두 출시했다는 것은 목표의 끝이라기보다, 각 데이터베이스 사용자에게 제대로 신뢰받을 수 있는지 검증을 시작했다는 뜻에 가깝습니다. 불완전한 부분은 숨기지 않고 개선 과정을 공유하며, 모바일 환경에서도 안심하고 사용할 수 있는 데이터베이스 클라이언트가 되도록 계속 만들어 가겠습니다.
다음에 출시할 앱은 Supabase Manager와 Container Manager입니다. Supabase Manager는 데이터베이스 연결을 넘어 Supabase를 폭넓게 관리할 수 있도록 기획하고 있으며, Container Manager는 Docker를 포함한 다양한 컨테이너 서버를 모바일에서 관리할 수 있는 도구를 목표로 하고 있습니다. QueryDock Database Client 시리즈에서 쌓은 경험을 바탕으로, 다음 제품군도 각각의 운영 대상에 맞는 작업 흐름을 처음부터 설계해 나가겠습니다.
QueryDock 앱 전체 확인: Sia MakerLab Apps
이전 공지: QueryDock 프로덕션 출시 현황과 앞으로의 계획
관련 개발 이야기: 76개의 앱, 그리고 다음 단계
참고 문서: Firebird 공식 문서 · Android Navigation 공식 문서
답글 남기기