첫 제품 단계
몇 주 안에 쓸 수 있는 형태로 검증합니다
핵심 흐름 하나를 골라 동작하는 프로토타입을 만들고, 실제 사용자에게 보여 줄 수 있는 상태까지 가져갑니다. 화면 수를 늘리는 대신 데이터 구조와 인증 방식처럼 나중에 바꾸기 어려운 부분을 먼저 정합니다.
이 단계에서 정한 결정이 이후 릴리스의 속도를 좌우하기 때문에, 프로토타입이라도 임시 코드로 넘기지 않고 문서와 함께 남깁니다.
회사 소개
시애틀에서 일하는 개발팀
Bilberrry는 미국 시애틀에 기반을 둔 IT 개발 회사입니다. 웹 애플리케이션, 모바일 앱, 맞춤 소프트웨어, 디지털 플랫폼을 만들고 운영합니다. 이 페이지는 저희가 어떤 원칙으로 일하는지 설명합니다.
우리가 하는 일
저희는 아이디어 단계의 제품부터 사내 시스템까지 다룹니다. 한쪽은 몇 주 안에 검증할 프로토타입이 필요하고, 다른 쪽은 기존 코드베이스를 유지하면서 기능을 붙여야 합니다. 두 경우에 필요한 설계가 다르기 때문에, 시작할 때 무엇을 만들지보다 왜 만드는지를 먼저 확인합니다.
작업 범위는 화면 설계에서 그치지 않습니다. 데이터 모델, 인증, 배포, 출시 후 운영까지 포함하는 경우가 많습니다. 그래서 견적을 낼 때도 화면 수가 아니라 운영까지 남는 일의 양을 기준으로 봅니다.
네 가지 영역을 중심으로 일합니다. 웹 애플리케이션은 사용자가 매일 쓰는 화면과 그 뒤의 데이터 흐름을 함께 설계하고, 모바일 앱은 스토어 심사와 배포 주기까지 감안해 계획합니다. 맞춤 소프트웨어는 기존 업무 도구 사이에서 반복되는 수작업을 줄이는 쪽에 집중하고, 디지털 플랫폼은 여러 서비스가 붙는 구조라면 무엇을 먼저 열어 둘지부터 정합니다.
일하는 원칙
원칙이라고 부르는 이유는, 판단이 갈릴 때 실제로 순서를 정하는 기준으로 쓰기 때문입니다.
첫째, 결정의 이유를 남깁니다.
기술 선택이든 범위 조정이든, 나중에 팀이 바뀌어도 판단 근거를 찾을 수 있어야 합니다. 회의에서 정한 내용은 저장소와 문서에 남기고, 왜 그렇게 정했는지까지 적습니다.
둘째, 발주처 팀이 스스로 운영할 수 있게 만듭니다.
코드 리뷰, 문서, 배포 절차를 남기는 데 시간을 씁니다. 저희가 없어도 돌아가는 구조가 목표입니다. 인수인계를 마지막 주에 몰아넣지 않고 작업하는 동안 계속 쌓아 둡니다.
셋째, 필요 없는 기능을 넣지 않습니다.
견적을 키우기 위해 범위를 부풀리는 방식은 쓰지 않습니다. 지금 단계에서 검증되지 않은 기능이면 제안서에 넣지 않고, 먼저 확인할 방법을 함께 정리합니다.
팀 구성
프로젝트마다 구성이 달라지지만, 보통 기획, 디자인, 프런트엔드, 백엔드 역할이 나뉩니다. 규모가 작은 프로젝트에서는 한 사람이 여러 역할을 겸하기도 합니다. 어떤 구성이든 코드는 GitHub를 기준으로 리뷰 절차를 거칩니다.
기획과 디자인
무엇을 먼저 만들지 정하고, 화면과 흐름을 문서로 확정한 뒤 개발에 넘깁니다. 확정 전에는 시안을 여러 번 비교합니다.
프런트엔드와 백엔드
인터페이스와 데이터, 인증, 배포를 나눠 맡되 같은 저장소에서 리뷰합니다. 작은 프로젝트에서는 한 사람이 양쪽을 겸합니다.
역할이 겹치는 프로젝트라도 검토 없이 넘어가는 코드는 없습니다. 최소 한 명이 다른 관점에서 읽고, 리뷰 기록이 남습니다. 진행 방식에 대한 자세한 내용은 별도 페이지에서 정리해 두었습니다.
진행 방식 확인하기
미국 시애틀 기반
사무실은 600 1st Ave Unit 413, Seattle, WA 98104에 있습니다. 시애틀은 미국 서부 시간대에 속해 있어, 북미 고객과는 같은 시간대에서, 아시아 고객과는 시차를 두고 협업합니다.
시간대가 다르면 비동기 협업이 기본이 됩니다. 저희는 문서와 데모를 자주 공유해서, 회의 시간을 줄이는 방식으로 진행합니다. 확인이 늦게 오더라도 작업이 멈추지 않도록 다음에 할 일을 미리 정해 둡니다.
문의하기
워싱턴주 시애틀, 평일 오전 9시부터 오후 6시까지 통화 가능합니다.
어떤 고객과 일하는가
첫 제품을 내야 하는 스타트업, 서비스를 다시 만들어야 하는 성장 단계 회사, 사내 도구를 정리하려는 기업 팀과 일해 왔습니다. 규모가 다르면 필요한 산출물도 다릅니다. 작은 팀에는 빠른 프로토타입이, 큰 조직에는 문서화된 설계와 인수 절차가 중요합니다.
성장 단계
기존 서비스를 다시 세우는 작업
쓰던 기능은 유지하면서 구조를 바꿔야 하는 경우가 많습니다. 어디까지 한 번에 옮길지, 언제 끊어서 배포할지를 일정에 함께 넣습니다.
사내 시스템
도구를 정리하고 인수 절차를 남깁니다
사내에서 쓰는 도구는 담당자가 바뀌어도 굴러가야 합니다. 배포와 권한 관리 절차를 문서로 정리하고, 담당 팀이 직접 운영할 수 있는 상태로 넘깁니다.
기술에 대한 태도
도구는 유행이 아니라 제약으로 고릅니다. Supabase, Svelte, Flutter, AWS Amplify, Vercel, Vue.js 같은 도구를 쓰지만, 어느 것도 기본값으로 정해 두지 않습니다. 팀 규모, 일정, 기존 인프라를 보고 고르고, 이유를 문서로 남깁니다.
1년 뒤 기능을 붙일 때 걸림돌이 되는 선택은 피합니다. 유행하는 도구라도 이 기준에 맞지 않으면 권하지 않습니다. 반대로 오래된 도구여도 팀이 이미 다루고 있고 운영 비용이 낮다면 그대로 쓰는 편이 낫습니다.
기술 스택 살펴보기Supabase
인증과 데이터베이스를 빠르게 세워야 하는 프로젝트에 씁니다. 직접 운영해야 하는 요구가 있으면 다른 구성을 제안합니다.
Svelte와 Vue.js
사용자 화면을 가볍게 유지하고 싶을 때 검토합니다. 팀이 이미 익숙한 쪽이 있으면 그 선택을 존중합니다.
Flutter
모바일 앱을 한 코드베이스로 관리할 때 씁니다. 플랫폼별로 따로 만들어야 하는 기능이 많으면 다시 계산합니다.
AWS Amplify, Vercel
배포와 운영 부담을 줄이는 쪽으로 검토합니다. 기존 인프라가 이미 있는 팀에는 무리해서 바꾸자고 하지 않습니다.
투명하게 이야기하는 것
일정과 예산은 정확하게 말합니다. 기술적으로 불가능한 것, 기간이 더 필요한 것, 범위를 줄여야 하는 것을 미리 알립니다. 나중에 문제가 드러나는 것보다 처음에 솔직하게 말하는 편이 낫습니다.
진행 중에 판단이 바뀌면 그 자리에서 다시 알립니다. 처음에 세운 계획대로 밀어붙이는 것보다, 바뀐 조건을 반영해 일정을 조정하는 편이 결과적으로 손해가 적습니다.
저희는 발주처를 외부인이 아니라 같이 결정하는 사람으로 봅니다. 각 단계마다 확인할 것을 명확히 하고, 결정이 필요한 지점에서 답을 받습니다. 그 과정을 문서로 남기기 때문에, 프로젝트가 끝난 뒤에도 기록이 남습니다.
함께 일하는 방식
다음 단계로 갈 때 무엇을 준비하면 되는지 정리해 두었습니다. 만들고 싶은 것이 아직 흐릿해도 괜찮습니다. 어떤 문제를 풀려는지부터 이야기하면 범위와 순서를 함께 정리해 드립니다.