Bilberrry
시애틀 사무실에서 웹 애플리케이션 코드를 함께 검토하는 Bilberrry 개발팀

Seattle, WA · 600 1st Ave Unit 413

시애틀에서 웹과 앱을 만드는 개발팀

Bilberrry는 미국 시애틀에 있는 IT 개발 회사입니다. 웹 애플리케이션, 모바일 앱, 맞춤 소프트웨어, 디지털 플랫폼을 기획 단계부터 출시와 유지보수까지 함께 다룹니다.

아이디어에서 출시까지

이 페이지에서는 Bilberrry가 어떤 일을 하는지, 프로젝트를 어디서 시작하면 되는지, 그리고 개발 과정에서 발주처가 어떤 결정을 하게 되는지를 순서대로 정리했습니다. 읽고 나서 바로 상담을 신청하거나, 기술 스택과 진행 방식을 먼저 확인해도 됩니다.

Bilberrry는 아이디어만 있는 단계의 스타트업부터 사내 시스템을 다시 짜야 하는 기업 팀까지 상대합니다. 한쪽은 몇 주 안에 쓸 수 있는 프로토타입이 필요하고, 다른 쪽은 기존 코드베이스를 유지하면서 기능을 붙여야 합니다. 두 경우에 필요한 설계와 일정이 전혀 다르기 때문에, 저희는 첫 미팅에서 "무엇을 만들까"보다 "이걸 왜 만드는가"를 먼저 묻습니다.

작업 범위는 화면 설계에서 그치지 않습니다. 데이터 모델, 인증, 배포 파이프라인, 그리고 출시 후 첫 몇 달의 운영까지 포함하는 경우가 많습니다. 시애틀에 기반을 두고 있지만 협업 도구와 코드 리뷰 방식을 갖춰 두었기 때문에, 시간대가 다른 팀과도 일정을 맞출 수 있습니다.

도구는 유행이 아니라 제약으로 고릅니다. 그래서 남는 이유를 문서로 남깁니다.

정답은 프로젝트마다 다르기 때문에, 저희가 어디를 왜 골랐는지 적어 두지 않으면 1년 뒤 유지보수 비용이 눈에 띄게 올라갑니다.

네 가지 개발 영역을 다룹니다

서비스 자세히 보기
웹 개발
웹은 지금 대부분 "웹사이트"가 아니라 "웹 애플리케이션"입니다. 로그인하고, 데이터를 입력하고, 결제나 대시보드가 붙는 순간 정적 페이지 도구로는 감당이 안 됩니다. Bilberrry는 반응형 웹과 SaaS 형태의 제품 화면을 함께 만듭니다.
프런트엔드는 Svelte, Vue.js 같은 프레임워크를 프로젝트 성격에 따라 고릅니다. 어떤 쪽이든 마케팅 페이지와 제품 화면이 같은 디자인 시스템을 공유하도록 정리합니다.
모바일 앱 개발
모바일 앱을 만들 때 가장 먼저 갈리는 결정은 네이티브로 두 번 만들 것인가, 크로스플랫폼으로 한 번 만들 것인가입니다. Flutter는 Google이 주도하는 UI 툴킷으로, iOS와 Android를 단일 코드베이스로 겨냥하고 웹과 데스크톱까지 확장할 수 있습니다.
플랫폼별 네이티브 기능을 깊게 써야 하거나 성능이 최우선이면 별도 구현을 검토합니다. 이 판단은 예산이 아니라 유지보수 문제입니다.
소프트웨어와 시스템
맞춤 소프트웨어는 기성 제품으로는 안 되는 업무 규칙이 있을 때 시작됩니다. 예를 들어 사내 승인 흐름, 외부 시스템과의 API 연동, 데이터 집계 같은 것들입니다. Bilberrry는 이런 영역에서 백엔드 구조와 데이터 흐름을 먼저 설계하고, 그 위에 화면을 얹습니다.
팀이 작은데 서비스를 잘게 쪼개면 운영 부담만 늘어납니다. 반대로 트래픽 변동이 큰 기능은 서버리스가 관리 비용을 줄여 줍니다. 저희는 그 차이를 문서로 남깁니다.
디지털 플랫폼
플랫폼은 여러 사용자 유형이 한 시스템 안에서 만나는 구조입니다. 공급자와 소비자, 관리자와 운영자처럼 역할이 나뉘고 각자 다른 화면과 권한을 가집니다. 이런 프로젝트는 첫 버전의 범위를 좁히는 게 성패를 가릅니다.
콘텐츠가 많아지고 채널이 늘어나면 헤드리스 CMS를 검토합니다. 다만 콘텐츠 운영 인력이 없는데 도입하면 관리 비용만 늘어납니다.
기술 스택 선택과 배포 파이프라인을 함께 검토하는 개발팀의 작업 테이블

기술 선택을 대하는 방식

도구는 유행이 아니라 제약으로 고릅니다. 이런 선택은 프로젝트 중간에 바꾸기 어렵기 때문에 초기에 이유를 남겨 두는 것이 중요합니다.

Supabase

PostgreSQL 기반 백엔드로 인증, 실시간 기능, 스토리지를 한곳에서 다룹니다. 빠른 출시가 필요한 팀이 Firebase 대안으로 자주 검토합니다.

Vercel

프런트엔드 미리보기와 엣지 배포에서 강점을 보입니다. 리뷰용 미리보기 URL이 곧 협업 기준이 됩니다.

GitHub

협업은 GitHub를 기준으로 이슈와 풀 리퀘스트, 자동화를 정리합니다.

AWS 중심으로 이미 운영 중인 조직이라면 AWS Amplify가 인증, API, 호스팅, 스토리지를 기존 스택과 이어 주는 편이 낫습니다. 저희는 어느 쪽이든 선택 이유를 먼저 확인합니다.

프로토타입 화면 흐름을 테이블 위에 펼쳐 놓고 검토하는 협업 회의 장면

진행 방식

모든 프로젝트가 같은 순서로 흘러가지는 않습니다. 다만 공통적으로 요구사항 정리, 프로토타입, MVP, 출시, 유지보수라는 큰 단계를 거칩니다. 프로토타입 단계에서 화면과 흐름을 먼저 확인하면, 개발에 들어간 뒤에 방향을 바꾸는 비용을 줄일 수 있습니다.

각 단계마다 발주처가 확인해야 할 것이 있습니다. 요구사항 단계에서는 우선순위, 프로토타입 단계에서는 사용자 흐름, MVP 단계에서는 실제로 쓸 기능의 경계입니다. 저희는 이 지점마다 짧은 문서와 데모를 공유하고, 다음 단계로 넘어가기 전에 확인을 받습니다.

진행 방식 확인하기

유지보수와 장기 운영

출시는 끝이 아니라 운영의 시작입니다. 코드를 넘겨받은 팀이 없으면 기능 하나를 고치는 데도 시간이 배로 듭니다. Bilberrry는 인수인계 문서와 함께 저장소, 배포, 모니터링이 어떻게 돌아가는지 정리해 둡니다.

  • 인수인계 문서

    저장소, 배포, 모니터링이 어떻게 돌아가는지 정리해 둡니다. 나중에 다른 팀이 합류해도 같은 기준에서 시작할 수 있습니다.

  • 일관된 규칙

    네이밍, 디자인 시스템, 테스트 범위 같은 것들이 장기적으로 버티는 코드를 만듭니다. 새 기능을 붙일 때마다 구조가 흔들리면 1년 뒤 유지보수 비용이 눈에 띄게 올라갑니다.

  • 이런 팀과 일합니다

    첫 제품을 세상에 내야 하는 스타트업, 기존 서비스를 다시 만들어야 하는 성장 단계 회사, 사내 도구를 정리하려는 기업 팀과 일해 왔습니다. 작은 팀에는 빠르게 검증할 수 있는 프로토타입이, 큰 조직에는 문서화된 설계와 인수 절차가 더 중요합니다.

저녁 시간 시애틀 사무실에서 일정과 범위를 다시 확인하는 개발자

예산과 일정 이야기

개발 비용은 기능 개수보다 구조에서 갈립니다. 같은 화면이라도 권한 관리와 데이터 연동이 붙으면 작업량이 달라집니다. 그래서 저희는 견적을 내기 전에 범위를 문서로 확정하는 단계를 둡니다.

일정도 마찬가지입니다. 프로토타입과 MVP를 나눠서 진행하면, 전체를 한 번에 만드는 것보다 중간에 방향을 조정할 여지가 생깁니다. 상담에서는 희망 일정과 실제 필요한 기간 사이의 차이를 솔직하게 이야기합니다.

자주 받는 질문

프로젝트를 시작하기 전에 가장 많이 확인하시는 내용입니다. 여기 없는 질문은 문의하기로 남겨 주시면 범위와 함께 정리해 드립니다.

전체 질문 보기
웹은 어떤 프레임워크로 만드나요?

제품 성격에 따라 다릅니다. 가벼운 번들과 빠른 반응이 중요하면 Svelte를, 팀에 Vue 경험이 있거나 Nuxt 생태계를 쓰면 Vue.js를 검토합니다. 결정 전에 이유를 문서로 정리합니다.

모바일 앱은 Flutter로 만드는 게 유리한가요?

단일 코드베이스로 iOS와 Android를 함께 겨냥하고 화면 반복이 잦은 제품에 잘 맞습니다. 반대로 플랫폼별 네이티브 기능을 깊게 써야 하면 별도 구현을 검토합니다.

Supabase와 Firebase 중 어디가 빠른가요?

Supabase는 PostgreSQL 기반으로 인증, 실시간 기능, 스토리지를 제공해 빠른 출시에 자주 검토됩니다. AWS 중심 조직이면 AWS Amplify 쪽이 기존 스택과 이어 쓰기 편합니다.

헤드리스 CMS가 필요한 규모는 어디부터인가요?

콘텐츠가 여러 채널로 퍼지고 운영 인력이 있을 때 효과가 큽니다. Contentful 같은 API 우선 플랫폼은 콘텐츠와 디자인을 분리합니다. 운영 인력이 없으면 관리 비용만 늘 수 있습니다.

상담은 어떻게 시작하나요?

문의 양식이나 이메일로 연락 주시면 됩니다. 한 줄 설명만 있어도 범위를 정리하는 것부터 함께 시작합니다.

이른 아침 시애틀 다운타운 전경, 프로젝트 착수를 앞둔 창가 풍경

시작하는 방법

상담은 부담 없이 시작할 수 있습니다. 만들고 싶은 것이 한 줄 설명이어도 괜찮습니다. 그 한 줄에서 사용자, 핵심 기능, 제약을 뽑아내는 것부터 함께 합니다.

문의 양식이나 이메일로 연락 주시면, 필요한 경우 짧은 통화를 잡아 범위를 정리합니다. 그다음 서면으로 접근 방식과 예상 단계를 정리해 드립니다. 결정은 그 이후에 하셔도 됩니다.

저희는 개발만 하고 끝내는 방식보다, 발주처 팀이 나중에 스스로 운영할 수 있게 되는 쪽을 선호합니다. 그래서 코드 리뷰, 문서, 배포 절차를 남기는 데 시간을 씁니다.

프로젝트 상담 신청

보내 주신 내용은 상담 목적으로만 사용합니다. 자세한 처리는 개인정보 처리방침에서 확인하실 수 있습니다.

먼저 회사가 어떤 방식으로 일하는지 확인하고 싶다면 회사 소개와 진행 방식을 먼저 읽어 보셔도 됩니다. 시애틀 사무실 방문 일정도 상담에서 조율할 수 있습니다.