Prompt Combo를 처음 구상할 때 가장 먼저 한 결정 중 하나는 서버를 두지 않는다 는 것이었습니다. 기능을 만들기 어렵게 만드는 선택이었지만, 결국 이 제품에는 그게 맞다고 판단했습니다.
왜 서버를 두는 방식이 편해 보였나
서버를 두면 쉬운 점이 많습니다.
- API 키 연결 UX를 단순하게 만들 수 있습니다.
- 실행 로그를 중앙에서 수집할 수 있습니다.
- 과금과 계정 관리도 한곳에서 처리할 수 있습니다.
하지만 이 편의성은 곧바로 신뢰 문제로 이어집니다. 사용자는 자기 프롬프트와 결과, 그리고 API 키가 어디를 지나가는지 예민하게 봅니다.
프롬프트 도구에서 가장 무서운 질문
실제 사용자 입장에서 가장 먼저 나오는 질문은 이것입니다.
"내 키가 네 서버를 거치나요?"
이 질문에 "네, 하지만 안전합니다"라고 답하는 순간 설명 비용이 생깁니다. 그리고 그 비용은 제품의 나머지 장점을 상당 부분 잠식합니다.
Prompt Combo는 이 질문에 "아니요, 로컬에만 저장됩니다" 라고 답하는 쪽을 선택했습니다. 그 한 문장이 제품을 훨씬 쉽게 이해하게 만들었습니다.
로컬 퍼스트의 대가
물론 손해도 있습니다.
- 기기간 동기화는 기본 제공하기 어렵습니다.
- 웹 대시보드 같은 기능을 바로 만들기 어렵습니다.
- 결제 이후 라이선스 처리도 더 신중하게 붙여야 합니다.
그럼에도 불구하고 이 대가는 감수할 가치가 있었습니다. Prompt Combo의 핵심은 팀 협업 SaaS가 아니라, 개발자가 자기 컴퓨터에서 빠르게 프롬프트 워크플로를 돌리는 도구 이기 때문입니다.
기술적으로는 무엇을 선택했나
로컬 저장소에는 아래 세 가지 계층을 분리했습니다.
- 민감한 자격 증명: OS 보안 저장소
- 프롬프트와 큐 정의: 앱 내부 데이터 디렉터리
- 로그와 실행 캐시: 회전 가능한 로컬 파일
이렇게 나누면 사용자가 원하는 지점만 지우거나 백업하기 쉬워집니다. 그리고 데이터 성격이 섞이지 않아 장애 대응도 단순해집니다.
결론
로컬 퍼스트는 단순한 구현 취향이 아니라 제품 메시지 자체였습니다. Prompt Combo는 "계정을 만들고 서버에 접속해서 쓰는 서비스"가 아니라, 설치 후 바로 자기 환경에서 돌리는 도구 로 보여야 했습니다.
그 기준에서 보면 서버를 두지 않는 선택은 제약이 아니라 정체성에 가까웠습니다.