개발 이야기

시아메이커랩은 지금까지 76개의 Android 앱을 공식 포트폴리오에 정리했습니다. 이 가운데 51개는 공개 상태이며, 25개는 심사·출시 준비 또는 개발을 이어가고 있습니다. 작은 생활 도구에서 시작한 앱 개발은 이제 Database Client와 서버·인프라 Manager/Client 제품군으로 확장되고 있습니다.

76개의 아이디어, 51개의 공개 앱

Sia Makerlab Apps에는 개발자 도구, Database Client, 로컬 AI, 언어·번역, 오프라인 도구, 위젯, 생산성 앱과 생활형 앱까지 총 76개 프로젝트가 정리되어 있습니다. 현재 공식 목록 기준으로 51개 앱을 이용할 수 있고, 25개 앱에는 Coming Soon 상태가 표시되어 있습니다.

앱의 수만 늘리는 것이 목표는 아닙니다. 자주 반복되는 불편을 발견하면 가장 작은 기능부터 구현하고, 실제 Android 환경에서 검증한 뒤 다음 앱에서 공통 구조를 더 단단하게 만드는 방식으로 개발해 왔습니다. Base64/Hash Toolbox, JSON Analyzer, Regex Tester 같은 개발 도구부터 오프라인 계산기와 변환기, 언어 앱과 위젯까지 서로 다른 문제를 다루면서도 이 원칙은 같습니다.

76이라는 숫자보다 중요한 것

76개라는 숫자만 보면 처음부터 큰 포트폴리오를 계획한 것처럼 보일 수 있습니다. 실제 시작점은 훨씬 단순했습니다. 일상이나 개발 과정에서 “이 기능만 빠르게 쓸 수 있는 앱이 있으면 좋겠다”는 순간을 발견하고, 그 문제를 작은 Android 앱으로 해결하는 일이 하나씩 쌓였습니다. 어떤 아이디어는 공개 앱이 되었고, 어떤 아이디어는 실험 과정에서 방향이 바뀌었으며, 아직 준비 중인 프로젝트도 있습니다.

공개 앱 51개와 준비 중인 25개는 성공과 실패를 구분하는 숫자가 아닙니다. 공개 이후 실제 사용 환경을 관찰하고 개선할 단계에 도달한 앱과, 기능·품질·스토어 정책·설명 자료를 더 다듬어야 하는 앱을 구분한 현재의 스냅샷입니다. 준비 중인 앱을 무리하게 출시하기보다 핵심 사용 흐름이 분명한지, 작은 화면에서도 불편하지 않은지, 사용자의 데이터를 안전하게 다룰 수 있는지를 먼저 확인하고 있습니다.

작은 앱이 다음 앱의 기반이 되는 방식

서로 다른 앱을 계속 만들다 보면 매번 처음부터 다시 구현해서는 속도와 품질을 함께 유지할 수 없습니다. 화면 상태를 관리하는 방식, 설정을 저장하는 구조, 파일을 선택하고 공유하는 흐름, 오류를 사용자에게 설명하는 문구처럼 제품마다 반복되는 문제가 많기 때문입니다. 시아메이커랩은 한 앱에서 검증한 패턴을 다음 앱의 출발점으로 옮기고, 반복되는 구현은 공통 기반으로 정리해 왔습니다.

다만 공통화 자체가 목적이 되지 않도록 주의합니다. 계산기와 Database Client는 사용자가 기대하는 정보 밀도와 조작 방식이 다르고, 번역 앱과 서버 관리 도구는 실패했을 때 알려줘야 할 내용도 다릅니다. 기술 기반은 재사용하되 각 앱의 첫 화면에서 “무엇을 할 수 있는 도구인지”가 바로 드러나야 합니다. 앱의 수가 늘수록 공통성과 제품 고유성 사이의 균형이 더 중요한 설계 과제가 됩니다.

아이디어에서 공개까지 확인하는 것

1. 문제를 한 문장으로 정의합니다. 기능 목록보다 누가 어떤 상황에서 무엇을 해결하려는지 먼저 정리합니다.
2. 가장 짧은 사용 흐름을 만듭니다. 앱을 실행한 뒤 핵심 결과에 도달하기까지 불필요한 화면과 입력을 줄입니다.
3. 실제 기기에서 반복해 봅니다. 에뮬레이터만으로 알기 어려운 키보드, 파일 선택, 네트워크 전환, 백그라운드 복귀 같은 상황을 확인합니다.
4. 실패 상황을 설계합니다. 연결 오류나 권한 부족을 단순한 실패 문구로 끝내지 않고 사용자가 다음에 무엇을 확인해야 하는지 안내합니다.
5. 출시 자료를 함께 준비합니다. 앱 이름, 아이콘, 스토어 설명과 스크린샷이 실제 기능을 정확히 전달하는지 검토합니다.
6. 공개 후 다시 판단합니다. 사용 빈도가 낮거나 목적이 흐려진 기능은 유지 비용까지 고려해 단순화합니다.

현재의 중심: 모바일 Database Client

현재 가장 많은 노력을 기울이는 영역은 Android에서 데이터베이스를 안전하고 효율적으로 다룰 수 있는 Database Client 제품군입니다. 로컬 SQLite 파일을 열고 조회·편집·가져오기·내보내기를 수행하는 SQLite Client는 이미 공개됐습니다. 이어지는 QueryDock 제품군은 MySQL·MariaDB, PostgreSQL, Redis를 비롯한 원격 데이터 시스템을 모바일에서 탐색하고 관리하는 경험을 목표로 합니다.

데스크톱 도구를 그대로 작은 화면에 옮기는 대신, 연결 프로필과 인증정보를 안전하게 다루고 스키마 탐색·쿼리 실행·데이터 확인처럼 이동 중에도 가치가 큰 작업을 우선합니다. 각 데이터베이스의 차이를 존중하면서도 연결, 탐색, 실행, 결과 확인이라는 공통 흐름은 일관되게 만드는 것이 과제입니다.

왜 모바일 Database Client인가

데이터베이스 작업은 보통 큰 모니터와 데스크톱 도구를 떠올리게 합니다. 복잡한 스키마를 설계하거나 대량 데이터를 편집하는 일에는 그 환경이 적합합니다. 하지만 모든 작업이 데스크톱을 요구하는 것은 아닙니다. 외부에서 서비스 상태를 확인하다가 특정 레코드가 존재하는지 살펴보거나, 개발 중인 앱의 로컬 SQLite 파일을 빠르게 점검하거나, Redis 키의 현재 값을 확인해야 하는 순간도 있습니다.

QueryDock 제품군은 데스크톱 Database Client를 완전히 대체하기보다 이런 짧고 분명한 작업을 모바일에서 안전하게 처리하는 데 초점을 맞춥니다. 연결 목록에서 대상 서버를 고르고, 데이터 구조를 탐색한 뒤, 필요한 쿼리를 실행하고 결과를 읽는 흐름을 손가락과 작은 화면에 맞게 다시 설계하는 것입니다. 긴 SQL 입력, 넓은 테이블, 가상 키보드가 동시에 등장할 때도 현재 맥락을 잃지 않도록 정보의 우선순위를 세워야 합니다.

서로 다른 데이터베이스, 일관된 사용 경험

MySQL·MariaDB와 PostgreSQL은 비슷해 보이지만 메타데이터와 데이터 형식, 관리 방식에 차이가 있습니다. Redis는 테이블과 행이 아니라 키와 자료구조를 중심으로 접근해야 합니다. 모든 시스템을 억지로 같은 화면에 끼워 맞추면 각 데이터베이스의 장점을 잃고, 반대로 제품마다 조작법이 완전히 달라지면 여러 앱을 함께 사용하는 의미가 줄어듭니다.

그래서 연결 프로필, 검색, 최근 작업, 오류 표시처럼 공통으로 이해할 수 있는 부분은 일관되게 유지하고, 스키마·쿼리·키 탐색처럼 엔진 고유의 특성이 중요한 부분은 별도로 설계하려 합니다. SQLite Client에서 얻은 파일 접근과 데이터 표시 경험도 원격 데이터베이스 제품군의 기초 자료가 됩니다.

연결 정보와 위험한 작업을 다루는 기준

Database Client의 편리함은 곧 위험이 될 수도 있습니다. 앱이 서버 주소와 계정 정보를 다루고, 사용자가 실행한 명령이 실제 데이터에 영향을 주기 때문입니다. 인증정보를 단순한 일반 설정처럼 저장하지 않고 플랫폼의 안전한 저장 수단을 활용하는 것, 연결 과정에서 발생한 오류에 비밀번호나 민감한 쿼리가 그대로 노출되지 않게 하는 것, 변경이나 삭제처럼 되돌리기 어려운 작업을 명확히 구분하는 것이 기본 원칙입니다.

또한 모바일이라는 이유로 모든 관리 기능을 제공하려 하기보다 읽기 중심의 점검과 짧은 조치를 우선하고, 위험도가 높은 기능은 충분한 확인 과정과 복구 가능성을 함께 검토합니다. 빠르게 접속할 수 있다는 장점이 성급한 운영 작업으로 이어지지 않도록 만드는 것까지가 제품 경험의 일부라고 생각합니다.

여러 환경을 잇는 Manager와 Client

Database Client와 함께 Container, NAS, Backend, FTP·SFTP, 이메일 등 다양한 시스템을 다루는 Manager/Client 앱도 준비하고 있습니다. Sia Container Manager는 Docker와 Podman 환경의 상태·로그·터미널을 모바일에서 확인하는 것을, Sia NAS Manager는 Linux·Synology DSM·TrueNAS SCALE 기반 서버의 스토리지와 서비스를 한곳에서 관리하는 것을 목표로 합니다.

이 제품군이 다루는 대상은 서로 다르지만 사용자가 원하는 순간은 비슷합니다. 자리를 비운 사이 컨테이너가 멈추지 않았는지 확인하고, 실패한 로그의 마지막 부분을 읽고, NAS의 저장 공간이나 서비스 상태를 살펴본 뒤 필요한 조치를 취하는 것입니다. 여러 관리 화면에 각각 접속하는 대신 자주 필요한 상태를 빠르게 파악하는 모바일 작업대를 만드는 것이 공통 목표입니다.

Sia Container Manager가 풀려는 문제

컨테이너 운영에서는 실행 중인지 여부만으로 충분하지 않습니다. 재시작이 반복되는지, 자원이 갑자기 늘었는지, 최근 로그에 어떤 오류가 남았는지까지 연결해서 봐야 합니다. Sia Container Manager는 Docker와 Podman 환경의 핵심 상태를 작은 화면에서 빠르게 훑고, 필요한 대상의 로그와 세부 정보로 자연스럽게 이동하는 경험을 고민하고 있습니다.

모바일 터미널은 강력하지만 잘못된 입력의 영향도 큽니다. 따라서 단순히 명령줄을 노출하는 데 그치지 않고 현재 연결 대상과 실행 위치를 분명히 보여주고, 일상적인 상태 확인과 영향이 큰 조작을 시각적으로 구분하는 방식이 필요합니다. 다양한 Docker·Podman 설치 환경에서 연결 방식이 달라지는 문제도 계속 검증해야 할 부분입니다.

Sia NAS Manager가 지향하는 통합

NAS와 홈 서버는 파일 저장소이면서 동시에 백업, 미디어, 컨테이너와 여러 개인 서비스를 운영하는 기반입니다. Linux 서버, Synology DSM, TrueNAS SCALE은 서로 다른 관리 모델을 가지므로 하나의 앱으로 다룰 때 공통 상태와 플랫폼별 기능을 명확히 나누어야 합니다. 저장 공간, 디스크 상태, 서비스와 작업 결과처럼 공통으로 중요한 정보는 일관되게 보여주고, 특정 플랫폼에서만 가능한 기능은 그 차이를 숨기지 않는 방향을 생각하고 있습니다.

Backend, FTP·SFTP, 이메일을 위한 Client와 Manager도 같은 맥락에서 출발합니다. 모든 기능을 한 앱에 쌓는 거대한 관리 도구보다 목적이 분명한 앱들이 공통된 연결 관리와 디자인 언어를 공유하는 구성이 더 이해하기 쉽고 유지하기 좋다고 판단합니다.

많이 만드는 과정에서 배우는 것

여러 앱을 개발하면 공통 디자인 시스템, 보안 저장소, 네트워크 계층, 오류 처리와 테스트 자동화가 얼마나 중요한지 빠르게 드러납니다. 한 앱에서 해결한 문제를 다음 앱의 기반으로 옮기고, 반복되는 부분은 표준화하면서도 각 도구의 목적은 선명하게 유지해야 합니다.

특히 네트워크를 사용하는 도구는 정상 동작보다 실패 동작을 설계하는 시간이 더 길 때가 많습니다. 서버가 응답하지 않는 상황, 인증이 만료된 상황, 이동 중 네트워크가 바뀌는 상황, 큰 결과를 불러오다가 앱이 백그라운드로 이동하는 상황을 고려해야 합니다. “오류가 발생했습니다”라는 한 줄 대신 연결 대상과 실패 단계, 사용자가 취할 수 있는 다음 행동을 알려줘야 실제 작업 도구가 됩니다.

앱이 많아질수록 유지보수의 우선순위도 배웁니다. 모든 앱에 같은 속도로 기능을 추가할 수는 없습니다. 실제 사용 가치가 큰 핵심 흐름, 운영체제 업데이트로 영향을 받는 부분, 보안과 데이터 손실 가능성이 있는 부분을 먼저 다루고 장식적인 기능은 뒤로 미룹니다. 어떤 기능은 직접 사용해 본 뒤 제거하거나 더 단순한 형태로 바꾸기도 합니다.

AI와 함께 만들되 판단은 제품에 남긴다

시아메이커랩은 AI 코딩 도구를 아이디어 정리, 반복 구현, 코드 검토와 문서화에 적극적으로 활용합니다. 여러 제품을 동시에 실험하고 공통 기반을 개선하는 데 큰 도움이 됩니다. 하지만 AI가 빠르게 코드를 만들 수 있다는 사실과 사용자가 안심하고 쓸 수 있는 제품을 완성하는 일은 같지 않습니다.

어떤 기능을 넣을지, 어떤 권한을 요구할지, 오류를 어디까지 복구할지, 민감한 데이터를 어떻게 보관할지는 제품을 운영하는 사람이 결정해야 합니다. 생성된 구현을 실제 기기와 다양한 환경에서 확인하고, 필요하면 구조를 다시 단순화하는 과정도 빠질 수 없습니다. AI는 제작 속도를 높이지만 제품의 책임까지 대신하지는 않는다는 기준을 유지하고 있습니다.

다음 단계에서 집중할 세 가지

1. Database Client의 핵심 흐름 완성: 연결, 탐색, 실행, 결과 확인이 각 데이터베이스의 특성을 살리면서도 일관되게 이어지도록 다듬습니다.
2. Manager/Client의 공통 기반 정리: 안전한 인증정보 저장, 연결 상태, 로그와 오류 표현 등 여러 앱이 공유할 토대를 강화합니다.
3. 출시보다 지속 가능한 운영: 준비 중인 앱을 한꺼번에 공개하기보다 실제로 유지하고 개선할 수 있는 순서로 검증과 출시를 진행합니다.

25개의 준비 중 프로젝트가 모두 같은 시점에 공개되지는 않을 것입니다. 개발 과정에서 이름과 범위가 달라질 수도 있고, 다른 제품과 합쳐지거나 더 작은 도구로 다시 정의될 수도 있습니다. 포트폴리오의 숫자를 지키기 위해 불필요한 앱을 출시하기보다 사용 이유가 분명한 제품만 남기는 것이 더 중요합니다.

앞으로도 시아메이커랩은 단순히 앱 개수를 늘리기보다 실제 작업에 오래 남는 도구를 만드는 데 집중하겠습니다. Database Client와 여러 Manager/Client가 준비되는 과정, 설계 선택과 시행착오도 이 블로그의 개발 이야기를 통해 꾸준히 공유하겠습니다.