Seattle · American IT company
웹부터 플랫폼까지 개발 서비스
Bilberrry는 미국 시애틀에 기반을 둔 IT 개발 회사입니다. 웹 애플리케이션, 크로스플랫폼 모바일 앱, 맞춤 소프트웨어, 디지털 플랫폼을 만들고, 각 영역에서 발주처가 실제로 마주치는 문제를 기준으로 일을 나눕니다.
서비스 지도
네 영역, 서로 다른 문제
나눠 놓고 보면 비슷해 보이지만, 각 영역에서 발주처가 마주치는 문제는 서로 다릅니다. 이 페이지는 그 차이를 기준으로 정리했습니다. 같은 웹사이트라도 로그인해서 데이터를 다루는 도구인지, 읽고 나가는 페이지인지에 따라 설계가 갈립니다.
- 웹 애플리케이션
- 사용자가 로그인해서 데이터를 다루는 도구. SaaS 대시보드, 반응형 웹, 사내 업무 도구를 이 범주에서 만듭니다.
- 크로스플랫폼 모바일 앱
- 하나의 코드베이스로 iOS와 Android를 겨냥합니다. 화면 반복 속도와 두 플랫폼의 디자인 일관성이 관건입니다.
- 맞춤 소프트웨어와 API 연동
- 기성 제품으로 안 되는 업무 규칙을 옮깁니다. 승인 흐름, 정산 규칙, 외부 시스템 연동이 여기에 해당합니다.
- 디지털 플랫폼 구축
- 공급자, 소비자, 관리자가 각자 다른 화면과 권한을 갖는 구조. 첫 버전의 범위를 좁히는 일이 가장 중요합니다.
웹 애플리케이션
읽는 페이지에서 쓰는 도구로
웹이 제품의 중심이 되는 순간 요구사항이 달라집니다. 방문자가 읽고 나가는 페이지가 아니라, 사용자가 로그인해서 데이터를 다루는 도구가 되기 때문입니다. Bilberrry는 SaaS 대시보드, 반응형 웹, 사내 업무 도구를 이 범주에서 만듭니다. 처음 상담에서 가장 먼저 묻는 것도 "누가 로그인하는가"입니다. 사용자 역할이 정해져야 화면 수와 권한 규칙이 함께 잡히기 때문입니다.
프런트엔드는 Svelte나 Vue.js를 프로젝트에 맞게 고르고, 마케팅 페이지와 제품 화면이 같은 디자인 시스템을 쓰도록 맞춥니다. 화면이 늘어날수록 컴포넌트 규칙이 흔들리면 유지보수가 급격히 어려워지기 때문입니다. 반대로 규칙이 자리를 잡으면 새 화면 하나를 붙이는 비용이 눈에 띄게 줄어듭니다.
- SaaS 대시보드와 관리자 화면
- 마케팅 페이지와 제품 화면의 디자인 시스템 통일
- 사내 업무 도구와 승인 흐름 화면
- 반응형 레이아웃과 컴포넌트 규칙 정리
먼저 정하는 것
사용자 역할이 정해지면 화면 수와 권한 규칙이 함께 잡힙니다.
관리자만 보는 화면, 발주처 담당자가 보는 화면, 최종 사용자가 보는 화면을 구분해 두면 개발 중간에 요구사항이 바뀌어도 구조가 흔들리지 않습니다.
크로스플랫폼 모바일 앱
하나의 코드베이스, 두 개의 플랫폼
Flutter는 iOS와 Android를 단일 코드베이스로 겨냥하는 UI 툴킷입니다. 웹과 데스크톱까지 확장할 수 있어, 하나의 제품을 여러 기기에서 보여줘야 할 때 검토할 만합니다. 화면 반복 속도가 빠르고 두 플랫폼의 디자인을 일관되게 가져갈 수 있다는 점이 강점입니다.
다만 모든 앱이 크로스플랫폼에 맞는 것은 아닙니다. 특정 플랫폼의 센서나 백그라운드 기능을 깊게 써야 하면 네이티브 구현이 낫습니다. 이 판단은 출시 후 유지보수를 누가 맡을지를 기준으로 하는 편이 정확합니다.
단일 코드베이스
iOS와 Android 화면을 한 흐름에서 관리합니다. 두 플랫폼의 디자인 차이를 줄이는 데 유리합니다.
네이티브가 나은 경우
센서, 백그라운드 동작, 플랫폼 고유 기능을 깊게 써야 하면 네이티브 구현을 검토합니다.
유지보수를 누가 맡는지
출시 후 코드를 관리할 주체가 내부 팀인지 외주인지에 따라 기술 선택이 달라집니다. 이 기준을 상담 초반에 함께 정리합니다.
맞춤 소프트웨어와 API 연동
기성 제품으로 안 되는 업무 규칙이 있으면 맞춤 개발이 시작됩니다. 승인 흐름, 정산 규칙, 외부 시스템 연동처럼 조직마다 다른 부분이 여기에 해당합니다. Bilberrry는 이 영역에서 데이터 흐름을 먼저 설계합니다.
API 연동은 특히 신경 씁니다
외부 서비스의 응답 형식이 바뀌거나 요청 제한이 걸리면 전체 기능이 멈출 수 있기 때문입니다. 재시도, 로그, 실패 알림을 처음부터 넣어 두는 편이 나중에 훨씬 싸게 끝납니다. 연동 대상이 늘어날 때마다 어떤 실패를 어디서 잡을지 정해 두면, 장애가 생겼을 때 원인을 찾는 시간이 줄어듭니다.
-
1
데이터 흐름 설계
어떤 데이터가 어디서 들어와 어디로 나가는지 먼저 그립니다. 화면보다 흐름이 먼저입니다.
-
2
재시도와 로그
외부 응답이 실패했을 때 다시 시도하는 규칙과 기록을 처음부터 넣습니다.
-
3
실패 알림
문제를 사용자가 먼저 발견하지 않도록 담당자에게 알림이 가게 만듭니다.
디지털 플랫폼 구축
역할이 나뉜 사용자가 만나는 구조
플랫폼은 역할이 나뉜 여러 사용자가 한 시스템에서 만나는 구조입니다. 공급자, 소비자, 관리자가 각자 다른 화면과 권한을 가집니다. 이런 프로젝트는 첫 버전의 범위를 좁히는 것이 성패를 가릅니다. 처음부터 모든 역할의 모든 기능을 만들면 검증 없이 몇 달이 지나가기 쉽습니다.
콘텐츠 채널이 늘어나면 헤드리스 CMS를 검토합니다. Contentful 같은 API 우선 플랫폼은 콘텐츠와 디자인을 분리해서 웹, 앱, 마케팅 사이트가 같은 데이터를 각자 다르게 보여줄 수 있게 합니다. 채널별 편집 권한도 이 구조에서 정리됩니다.
- 공급자
- 등록, 상태 관리, 정산 확인 화면
- 소비자
- 검색, 신청, 결제, 이력 조회 화면
- 관리자
- 승인, 정산, 콘텐츠 발행, 권한 부여 화면
백엔드와 데이터
백엔드 선택은 출시 속도와 운영 방식에 직접 영향을 줍니다. 무엇을 쓰느냐보다, 지금 팀이 그 구조를 감당할 수 있느냐가 더 중요합니다.
Supabase
PostgreSQL 기반으로 인증, 실시간 기능, 스토리지를 한곳에서 제공합니다. 빠르게 시작해야 하는 프로젝트에 맞습니다.
빠른 시작이 우선일 때
AWS Amplify
AWS 중심으로 인프라를 이미 운영하는 조직이라면 기존 구성과 이어 붙이기 편합니다.
기존 AWS 자산이 있을 때
서버리스
변동이 큰 트래픽에서 관리 비용을 줄여 줍니다. 다만 작은 팀이 서비스를 잘게 쪼개면 운영 부담만 커집니다.
트래픽 변동이 클 때
마이크로서비스와 서버리스 중 무엇이 맞는지는 팀 규모에 달려 있습니다. 서비스 경계를 나누는 일 자체가 운영 비용이라는 점을 감안하면, 팀이 감당할 수 있는 단위부터 시작하는 편이 오래 갑니다.
배포와 운영
되돌릴 수 있는 배포
배포는 Vercel처럼 프런트엔드에 강한 플랫폼을 쓰는 경우가 많습니다. 미리보기 배포가 있어서 변경 사항을 실제 환경에 가깝게 확인할 수 있습니다. 코드는 GitHub를 기준으로 이슈, 풀 리퀘스트, 자동화를 정리합니다.
운영 단계에서는 모니터링과 롤백 절차가 중요합니다. 문제가 생겼을 때 이전 버전으로 되돌릴 수 있는지, 로그가 충분한지에 따라 대응 시간이 달라집니다.
모니터링
어떤 오류가 언제 늘었는지 볼 수 있어야 대응이 시작됩니다. 확인할 지표를 배포 전에 정해 둡니다.
롤백 절차
이전 버전으로 되돌리는 순서를 문서로 남깁니다. 급한 상황에서 순서를 다시 고민하지 않도록 하기 위해서입니다.
시작점 정하기
어떤 서비스를 먼저 볼까
무엇부터 시작할지는 지금 가진 것이 무엇인지에 달려 있습니다. 아이디어만 있으면 프로토타입이, 검증된 흐름이 있으면 MVP가 먼저입니다. 이미 서비스가 돌아가고 있는데 기능을 붙여야 하면 기존 구조를 먼저 진단합니다.
기성 플랫폼으로 충분한지도 같이 봅니다. 콘텐츠 판매라면 Shopify나 WordPress로 시작하는 편이 빠를 수 있습니다. 다만 결제 규칙이나 권한 구조가 복잡해지면 그때 맞춤 개발이 필요해집니다. 이 판단은 상담에서 함께 정리합니다.
아이디어만 있을 때
가장 좁은 핵심 흐름 하나를 골라 프로토타입으로 확인합니다. 이 단계에서는 넓은 기능 목록보다 화면 몇 개로 검증하는 편이 낫습니다.
검증된 흐름이 있을 때
MVP로 실제 사용자 반응을 받습니다. 측정할 지표와 배포 범위를 먼저 정해 두면 이후 판단이 쉬워집니다.
이미 돌아가는 서비스가 있을 때
기능을 붙이기 전에 기존 구조를 진단합니다. 데이터 흐름과 권한 규칙을 확인한 뒤 확장 순서를 정합니다.
기성 플랫폼으로 충분할 때
콘텐츠 판매처럼 규칙이 단순하면 기성 플랫폼으로 시작하는 편이 빠릅니다. 결제 규칙이나 권한 구조가 복잡해지는 시점에 맞춤 개발을 검토합니다.
함께 정하는 범위
서비스 범위는 저희가 정해서 통보하는 방식이 아닙니다. 상담에서 발주처의 제약(예산, 일정, 내부 인력)을 확인하고, 그 안에서 현실적인 순서를 제안합니다. 필요 없는 기능을 넣어 견적을 키우는 방식은 쓰지 않습니다.
제약 확인
예산, 일정, 내부 인력. 세 가지를 먼저 확인합니다.
순서 제안
그 안에서 현실적인 개발 순서를 제안합니다.
범위 조정
필요 없는 기능은 빼고, 지금 필요한 것만 남깁니다.
자주 묻는 질문
상담 전에 자주 나오는 질문
상담 자리에서 반복해서 나오는 질문을 먼저 정리했습니다. 여기에 없는 내용은 문의 페이지에서 바로 물어보실 수 있습니다.
웹과 모바일 앱을 같은 프로젝트로 만들 수 있나요?
가능합니다. 다만 화면 설계는 기기별로 나눠서 봅니다. 모바일에서 먼저 검증한 흐름을 웹으로 넓히는 순서가 일반적이고, 반대 순서가 맞는 경우도 상담에서 함께 판단합니다.
크로스플랫폼과 네이티브 중 무엇을 골라야 하나요?
플랫폼 고유 기능을 얼마나 깊게 쓰는지, 출시 후 유지보수를 누가 맡는지에 따라 달라집니다. 두 축을 먼저 정리하면 선택이 훨씬 분명해집니다.
기존 시스템이 있어도 맞춤 개발이 가능한가요?
가능합니다. 먼저 데이터 흐름과 권한 규칙을 확인한 뒤, 기존 시스템을 유지할 부분과 새로 만들 부분을 나눕니다. 연동 실패에 대비한 재시도와 로그 설계도 이 단계에서 함께 정합니다.
시애틀 외 지역에서도 진행할 수 있나요?
원격으로 진행합니다. 상담과 정기 확인은 화상으로 하고, 문서와 코드는 저장소에서 함께 봅니다. 시애틀 사무실은 600 1st Ave Unit 413에 있고, 방문이 필요한 경우 미리 일정을 맞춥니다.