기술 스택
기술 스택은 유행이 아니라 제약으로 정합니다. 팀 규모, 출시 일정, 기존 인프라, 유지보수 주체가 모두 영향을 줍니다. Bilberrry가 실제로 쓰는 도구와 각각을 언제 검토하는지 정리했습니다.
도구는 세 가지 질문으로 좁힙니다. 첫째, 지금 팀이 이걸 운영할 수 있는가. 둘째, 1년 뒤 기능을 붙일 때 걸림돌이 되는가. 셋째, 기존 시스템과 얼마나 잘 이어지는가.
배포, 모니터링, 장애 대응을 감당할 사람이 있는지부터 봅니다. 러닝커브가 큰 도구는 팀 규모가 작을 때 병목이 됩니다.
결제, 권한, 다국어처럼 나중에 붙일 기능을 미리 그려 봅니다. 데이터 모델이 굳으면 되돌리는 비용이 커집니다.
이미 쓰는 인증, 클라우드, CMS가 있으면 그대로 살립니다. 새로 도입하는 도구가 적을수록 첫 릴리스가 빨라집니다.
이 기준에 맞지 않으면 유행하는 도구라도 권하지 않습니다. 선택의 이유는 문서로 남겨서, 나중에 팀이 바뀌어도 판단 근거를 찾을 수 있게 합니다. Bilberrry는 미국 시애틀에 기반을 둔 IT 개발 회사로, 웹 개발, 모바일 앱, 소프트웨어, 디지털 플랫폼 프로젝트를 함께 진행합니다.
백엔드와 프런트엔드는 따로 고르지 않습니다. 한쪽을 바꾸면 다른 쪽의 일정과 유지보수 부담이 같이 움직입니다.
백엔드
Supabase는 PostgreSQL 기반 백엔드 플랫폼입니다. 인증, 실시간 기능, 스토리지를 한곳에서 제공하기 때문에 백엔드를 처음부터 만들지 않고도 제품을 세울 수 있습니다. 개발자 친화적인 대안으로 Firebase와 자주 비교됩니다.
스타트업과 내부 도구에서 사용 사례가 많습니다. 관계형 데이터와 SQL을 그대로 쓸 수 있다는 점이 강점입니다. 다만 데이터 구조가 단순하고 실시간 동기화가 핵심이면 다른 선택지도 함께 따져 봅니다.
검토하기 좋은 때
관계형 데이터가 중심이고, 인증과 스토리지를 초기에 빠르게 붙여야 할 때
다시 따져 볼 때
데이터 구조가 단순하고 실시간 동기화가 제품의 핵심일 때
프런트엔드
Svelte는 컴파일 시점 최적화를 강조하는 프런트엔드 프레임워크입니다. 상대적으로 적은 보일러플레이트로 주목받고, SvelteKit과 함께 풀스택 앱 개발에 쓰입니다. 작은 번들 크기와 빠른 UI 반응이 자주 언급되는 이유입니다.
인터페이스 반응 속도가 제품 경험을 좌우하는 경우에 잘 맞습니다. 화면이 많고 상태 관리가 복잡한 제품에서는 팀의 익숙함도 함께 봐야 합니다.
프런트엔드
Vue.js는 점진적 프레임워크로 알려져 있습니다. 학습 곡선이 비교적 완만한 편으로 자주 언급되고, SPA와 마케팅 중심 웹사이트 모두에 쓰입니다. 생태계에는 Nuxt가 있습니다.
소규모 팀이나 빠른 출시가 중요한 프로젝트에서 자주 선택됩니다. 이미 Vue 경험이 있는 팀이라면 별도 학습 없이 바로 투입할 수 있습니다.
모바일
Flutter는 Google이 주도하는 UI 툴킷으로, iOS와 Android를 단일 코드베이스로 겨냥합니다. 웹과 데스크톱까지 확장할 수 있어 하나의 제품을 여러 기기에서 운영할 때 검토할 만합니다.
빠른 UI 반복과 일관된 디자인 구현에 강점이 있습니다. 플랫폼별 네이티브 기능을 깊게 써야 하는 경우에는 별도 구현이 낫습니다. 그래서 앱 기획 단계에서 어디까지 하나의 코드로 가져갈지 먼저 합의합니다.
iOS와 Android 출시 일정이 붙어 있고, 디자인 일관성이 중요할 때 검토합니다.
진행 방식 확인하기콘텐츠 운영 방식과 이미 쓰고 있는 클라우드가 도구를 거의 결정합니다. 아래 두 가지는 특히 기존 환경에 따라 판단이 갈립니다.
콘텐츠
Contentful은 API 우선 콘텐츠 플랫폼입니다. 멀티채널 퍼블리싱에 적합하고, 디자인과 콘텐츠를 분리하는 구조로 많이 쓰입니다. 디지털 제품과 마케팅 사이트를 함께 운영할 때 자주 비교됩니다.
검토 기준
콘텐츠가 여러 채널로 퍼지고 운영 인력이 있을 때 효과가 큽니다. 반대로 콘텐츠를 다룰 사람이 없으면 관리 부담만 늘어납니다.
클라우드
AWS Amplify는 AWS의 앱 개발 및 배포 서비스군입니다. 인증, API, 호스팅, 스토리지와 연동되고 서버리스 아키텍처와 결합하기 쉽습니다. AWS 중심 조직에서 자주 검토됩니다.
검토 기준
이미 AWS를 쓰고 있다면 권한, 로그, 배포 체계를 그대로 이어 쓸 수 있습니다. 다른 클라우드를 쓰는 팀에는 이점이 줄어듭니다.
배포
Vercel은 프런트엔드 배포와 엣지 기반 배포로 알려져 있습니다. Next.js와의 결합이 특히 강하고, 미리보기 배포와 개발자 경험이 강점으로 꼽힙니다. 현대 웹팀의 표준 도구로 자주 언급됩니다.
검토 기준
변경 사항을 실제 환경에 가깝게 확인할 수 있어 배포 리스크가 줄어듭니다. 마케팅 사이트와 웹 앱을 같은 저장소에서 굴릴 때 특히 편합니다.
협업
GitHub는 Git 기반 코드 저장소와 협업의 표준 도구입니다. 이슈, 풀 리퀘스트, 액션 같은 기능으로 개발 워크플로를 지원합니다. 오픈소스와 기업용 코드베이스 모두에서 핵심 역할을 합니다.
협업 방식이 정리되어 있으면 코드 건강이 유지되고 제품 속도도 올라갑니다. 리뷰 규칙이 없으면 저장소가 커질수록 품질이 흔들립니다.
브랜치와 리뷰 규칙
기본 브랜치를 보호하고 리뷰어를 지정합니다. 병합 전에 무엇을 확인해야 하는지 팀이 같은 기준을 갖게 됩니다.
이슈와 작업 기록
무엇을 왜 바꿨는지 남깁니다. 담당자가 바뀌어도 맥락이 저장소 안에 남아 있어 인수인계가 짧아집니다.
자동화된 검사
테스트와 린트를 배포 전에 돌립니다. 눈으로 놓치는 실수를 병합 전에 걸러내는 장치입니다.
잘못된 선택은 프로젝트를 끝내지 않습니다. 다만 바꾸는 비용은 일찍 알아챌수록 줄어듭니다. 그래서 저희는 개발 중에도 스택이 여전히 맞는지 주기적으로 확인합니다.
교체를 결정했다면 영향을 받는 범위를 먼저 정리합니다. 데이터 이관, 인증 흐름, 배포 파이프라인 중 어디까지 손대야 하는지 목록으로 만들고, 가능하면 한 번에 하나씩 옮깁니다. 한꺼번에 갈아끼우면 문제가 생겼을 때 원인을 찾기 어려워집니다.
미리 정리해 두면 좋은 것
같은 질문을 여덟 개 도구에 던져 봤습니다. 어디에 쓰는지, 언제 검토하는지, 무엇을 조심해야 하는지가 판단의 출발점입니다.
| 도구 | 주로 쓰는 자리 | 검토 신호 | 주의할 점 |
|---|---|---|---|
| Supabase | PostgreSQL 기반 백엔드, 인증과 스토리지 | 관계형 데이터와 SQL을 그대로 쓰고 싶을 때 | 실시간 동기화가 핵심이면 다른 대안도 비교합니다 |
| Svelte | 컴파일 시점 최적화를 노리는 프런트엔드 | 반응 속도와 번들 크기가 제품 경험을 좌우할 때 | 상태 관리가 복잡하면 팀의 익숙함을 먼저 확인합니다 |
| Flutter | iOS와 Android를 함께 겨냥하는 모바일 앱 | 단일 코드베이스로 UI 반복을 빠르게 가져가야 할 때 | 플랫폼별 네이티브 기능이 깊으면 별도 구현이 낫습니다 |
| Contentful | API 우선 헤드리스 CMS | 콘텐츠가 여러 채널로 퍼지고 운영 인력이 있을 때 | 콘텐츠를 다룰 사람이 없으면 관리 부담만 늘어납니다 |
| AWS Amplify | AWS 위의 앱 개발·배포 서비스군 | 이미 AWS를 쓰고 있어 권한과 로그를 이어 쓸 때 | 다른 클라우드를 쓰는 팀에는 이점이 줄어듭니다 |
| Vercel | 프런트엔드 배포와 엣지 배포 | 미리보기 배포로 배포 리스크를 줄이고 싶을 때 | 서버리스 제약을 미리 확인해야 하는 작업도 있습니다 |
| Vue.js | 점진적으로 도입하는 프런트엔드, SPA와 마케팅 사이트 | 소규모 팀이 빠른 출시를 노릴 때 | 이미 Vue 경험이 있는 팀인지 먼저 확인합니다 |
| GitHub | 코드 저장소와 협업 워크플로 | 리뷰 규칙과 자동 검사를 갖추고 싶을 때 | 규칙이 없으면 저장소가 커질수록 품질이 흔들립니다 |
표는 도구의 우열이 아니라 검토 출발점입니다. 실제 선택은 팀 구성과 일정, 기존 시스템에 따라 달라집니다.
저희가 후보와 이유를 정리해 제안하고, 최종 결정은 함께 내립니다. 팀 규모, 출시 일정, 유지보수를 맡을 주체를 먼저 확인한 뒤 도구를 좁히기 때문에, 제안서에는 각 선택지의 장단점이 함께 들어갑니다.
데이터가 관계형이고 SQL로 다루고 싶다면 Supabase 쪽이 맞습니다. 반대로 데이터 구조가 단순하고 실시간 동기화가 제품의 핵심이라면 Firebase도 함께 비교합니다. 어느 쪽이든 인증과 권한 모델을 먼저 그려 두면 이전 비용이 줄어듭니다.
Flutter처럼 여러 플랫폼을 한 코드베이스로 겨냥하는 도구를 쓰면 UI와 비즈니스 로직을 상당 부분 공유할 수 있습니다. 다만 플랫폼별 네이티브 기능을 깊게 써야 하는 부분은 별도 구현이 낫습니다. 어디까지 공유할지는 기획 단계에서 정합니다.
아닙니다. Amplify는 이미 AWS의 권한, 로그, 배포 체계를 쓰고 있을 때 이점이 큽니다. 다른 클라우드 위에 서비스를 올렸다면 기존 도구로 같은 목적을 달성할 수 있는지 먼저 확인하고, 새 도구 도입은 그 다음에 판단합니다.
콘텐츠가 여러 채널로 퍼지고, 콘텐츠를 다룰 담당자가 따로 있다면 검토할 만합니다. 반대로 콘텐츠를 관리할 사람이 없고 페이지 수가 적다면 관리 부담만 늘어납니다. Contentful 같은 도구는 그 조건이 갖춰졌을 때 효과가 큽니다.
바꿀 수 있습니다. 다만 비용은 일찍 알아챌수록 줄어듭니다. 그래서 개발 중에도 스택이 여전히 맞는지 주기적으로 확인하고, 교체가 필요하면 데이터 이관, 인증 흐름, 배포 파이프라인 중 어디까지 손대야 하는지 먼저 정리합니다.
Bilberrry는 미국 시애틀에 기반을 둔 IT 개발 회사로, 웹 개발과 모바일 앱, 소프트웨어, 디지털 플랫폼 프로젝트를 맡고 있습니다. 지금 팀 구성과 일정, 기존 인프라를 알려 주시면 어떤 스택이 맞는지 검토해 안내합니다.
600 1st Ave Unit 413, Seattle, WA 98104, United States · 월요일–금요일 오전 9:00 – 오후 6:00 · [email protected]
