Supabase
PostgreSQL 기반 백엔드로 인증, 실시간 기능, 스토리지를 한곳에서 다룹니다. 빠른 출시가 필요한 팀이 Firebase 대안으로 자주 검토합니다.
Seattle, WA · 600 1st Ave Unit 413
Bilberrry는 미국 시애틀에 있는 IT 개발 회사입니다. 웹 애플리케이션, 모바일 앱, 맞춤 소프트웨어, 디지털 플랫폼을 기획 단계부터 출시와 유지보수까지 함께 다룹니다.
이 페이지에서는 Bilberrry가 어떤 일을 하는지, 프로젝트를 어디서 시작하면 되는지, 그리고 개발 과정에서 발주처가 어떤 결정을 하게 되는지를 순서대로 정리했습니다. 읽고 나서 바로 상담을 신청하거나, 기술 스택과 진행 방식을 먼저 확인해도 됩니다.
Bilberrry는 아이디어만 있는 단계의 스타트업부터 사내 시스템을 다시 짜야 하는 기업 팀까지 상대합니다. 한쪽은 몇 주 안에 쓸 수 있는 프로토타입이 필요하고, 다른 쪽은 기존 코드베이스를 유지하면서 기능을 붙여야 합니다. 두 경우에 필요한 설계와 일정이 전혀 다르기 때문에, 저희는 첫 미팅에서 "무엇을 만들까"보다 "이걸 왜 만드는가"를 먼저 묻습니다.
작업 범위는 화면 설계에서 그치지 않습니다. 데이터 모델, 인증, 배포 파이프라인, 그리고 출시 후 첫 몇 달의 운영까지 포함하는 경우가 많습니다. 시애틀에 기반을 두고 있지만 협업 도구와 코드 리뷰 방식을 갖춰 두었기 때문에, 시간대가 다른 팀과도 일정을 맞출 수 있습니다.
도구는 유행이 아니라 제약으로 고릅니다. 그래서 남는 이유를 문서로 남깁니다.
정답은 프로젝트마다 다르기 때문에, 저희가 어디를 왜 골랐는지 적어 두지 않으면 1년 뒤 유지보수 비용이 눈에 띄게 올라갑니다.
도구는 유행이 아니라 제약으로 고릅니다. 이런 선택은 프로젝트 중간에 바꾸기 어렵기 때문에 초기에 이유를 남겨 두는 것이 중요합니다.
PostgreSQL 기반 백엔드로 인증, 실시간 기능, 스토리지를 한곳에서 다룹니다. 빠른 출시가 필요한 팀이 Firebase 대안으로 자주 검토합니다.
프런트엔드 미리보기와 엣지 배포에서 강점을 보입니다. 리뷰용 미리보기 URL이 곧 협업 기준이 됩니다.
협업은 GitHub를 기준으로 이슈와 풀 리퀘스트, 자동화를 정리합니다.
AWS 중심으로 이미 운영 중인 조직이라면 AWS Amplify가 인증, API, 호스팅, 스토리지를 기존 스택과 이어 주는 편이 낫습니다. 저희는 어느 쪽이든 선택 이유를 먼저 확인합니다.
모든 프로젝트가 같은 순서로 흘러가지는 않습니다. 다만 공통적으로 요구사항 정리, 프로토타입, MVP, 출시, 유지보수라는 큰 단계를 거칩니다. 프로토타입 단계에서 화면과 흐름을 먼저 확인하면, 개발에 들어간 뒤에 방향을 바꾸는 비용을 줄일 수 있습니다.
각 단계마다 발주처가 확인해야 할 것이 있습니다. 요구사항 단계에서는 우선순위, 프로토타입 단계에서는 사용자 흐름, MVP 단계에서는 실제로 쓸 기능의 경계입니다. 저희는 이 지점마다 짧은 문서와 데모를 공유하고, 다음 단계로 넘어가기 전에 확인을 받습니다.
진행 방식 확인하기출시는 끝이 아니라 운영의 시작입니다. 코드를 넘겨받은 팀이 없으면 기능 하나를 고치는 데도 시간이 배로 듭니다. Bilberrry는 인수인계 문서와 함께 저장소, 배포, 모니터링이 어떻게 돌아가는지 정리해 둡니다.
저장소, 배포, 모니터링이 어떻게 돌아가는지 정리해 둡니다. 나중에 다른 팀이 합류해도 같은 기준에서 시작할 수 있습니다.
네이밍, 디자인 시스템, 테스트 범위 같은 것들이 장기적으로 버티는 코드를 만듭니다. 새 기능을 붙일 때마다 구조가 흔들리면 1년 뒤 유지보수 비용이 눈에 띄게 올라갑니다.
첫 제품을 세상에 내야 하는 스타트업, 기존 서비스를 다시 만들어야 하는 성장 단계 회사, 사내 도구를 정리하려는 기업 팀과 일해 왔습니다. 작은 팀에는 빠르게 검증할 수 있는 프로토타입이, 큰 조직에는 문서화된 설계와 인수 절차가 더 중요합니다.
개발 비용은 기능 개수보다 구조에서 갈립니다. 같은 화면이라도 권한 관리와 데이터 연동이 붙으면 작업량이 달라집니다. 그래서 저희는 견적을 내기 전에 범위를 문서로 확정하는 단계를 둡니다.
일정도 마찬가지입니다. 프로토타입과 MVP를 나눠서 진행하면, 전체를 한 번에 만드는 것보다 중간에 방향을 조정할 여지가 생깁니다. 상담에서는 희망 일정과 실제 필요한 기간 사이의 차이를 솔직하게 이야기합니다.
제품 성격에 따라 다릅니다. 가벼운 번들과 빠른 반응이 중요하면 Svelte를, 팀에 Vue 경험이 있거나 Nuxt 생태계를 쓰면 Vue.js를 검토합니다. 결정 전에 이유를 문서로 정리합니다.
단일 코드베이스로 iOS와 Android를 함께 겨냥하고 화면 반복이 잦은 제품에 잘 맞습니다. 반대로 플랫폼별 네이티브 기능을 깊게 써야 하면 별도 구현을 검토합니다.
Supabase는 PostgreSQL 기반으로 인증, 실시간 기능, 스토리지를 제공해 빠른 출시에 자주 검토됩니다. AWS 중심 조직이면 AWS Amplify 쪽이 기존 스택과 이어 쓰기 편합니다.
콘텐츠가 여러 채널로 퍼지고 운영 인력이 있을 때 효과가 큽니다. Contentful 같은 API 우선 플랫폼은 콘텐츠와 디자인을 분리합니다. 운영 인력이 없으면 관리 비용만 늘 수 있습니다.
문의 양식이나 이메일로 연락 주시면 됩니다. 한 줄 설명만 있어도 범위를 정리하는 것부터 함께 시작합니다.
상담은 부담 없이 시작할 수 있습니다. 만들고 싶은 것이 한 줄 설명이어도 괜찮습니다. 그 한 줄에서 사용자, 핵심 기능, 제약을 뽑아내는 것부터 함께 합니다.
문의 양식이나 이메일로 연락 주시면, 필요한 경우 짧은 통화를 잡아 범위를 정리합니다. 그다음 서면으로 접근 방식과 예상 단계를 정리해 드립니다. 결정은 그 이후에 하셔도 됩니다.
저희는 개발만 하고 끝내는 방식보다, 발주처 팀이 나중에 스스로 운영할 수 있게 되는 쪽을 선호합니다. 그래서 코드 리뷰, 문서, 배포 절차를 남기는 데 시간을 씁니다.
먼저 회사가 어떤 방식으로 일하는지 확인하고 싶다면 회사 소개와 진행 방식을 먼저 읽어 보셔도 됩니다. 시애틀 사무실 방문 일정도 상담에서 조율할 수 있습니다.