깃허브·버셀·파이어스토어, 인디 개발자의 초고속 배포 삼각편대
요즘 애플리케이션 개발자는 방대한 아키텍처 솔루션 메뉴에서 마음에 드는 것을 선택할 수 있다. 메뉴에는 잘 알려진 것부터 실험적인 솔루션까지 펼쳐져 있고, 그 사이에는 둘을 적당히 혼합한 솔루션도 있다. 클라우드 혁명기에 등장한 강력한 여러 중간 지대(middle-ground) 기술이 그동안 성숙기에 접어들었는데, 이 글에서는 그중 가장 두드러진 세 가지인 깃허브(GitHub), 버셀(Vercel), 파이어스토어(Firestore)를 함께 사용하는 방법을 살펴본다.
세 가지 툴은 각각 특정 문제를 해결하는 데 사용할 수 있으며 그 자체로 모두 중요한 툴이지만 조합해 사용하면 여러 중요한 애플리케이션 시나리오의 요구를 충족하고, 개발과 배포 사이의 거리를 비약적으로 단축할 수도 있다.
지금 필요한 것을 정확히 충족하는 툴 조합을 완성할 때의 만족감은 무엇과도 바꿀 수 없다.
오직 속도만을 위한 ‘노옵스’ 스택
순수한 개발 속도가 주된 목표라면 이 아키텍처보다 더 나은 옵션은 찾기 어렵다. 이 “노옵스” 스택은 로컬 IDE와 전 세계에 걸쳐 분산된 프로덕션 환경 사이의 거리를 비약적으로 좁혀준다. 사실상 VM과 로드 밸런서 관리에 따르는 부담을 대가로 초고속 코드 커밋과 자동 배포를 얻게 된다.
각 구성요소는 매우 유연하지만, 서버리스 스택을 도입하기 위해서는 구체적인 이벤트 주도 사고방식이 필요하다. 주의해야 할 까다로운 부분이 몇 가지 있는데, 주로 환경 변수의 안전한 라우팅, 그리고 무상태 백엔드 함수를 중심으로 한 설계와 관련된 부분이다. 그러나 이런 제약 사항은 명확하고 문서화도 잘 되어 있다.
더 자세히 들어가기에 앞서 이 스택에 꼭 맞는 종류의 앱, 그럭저럭 쓸 만한 앱, 그리고 다른 접근법이 필요한 앱을 각각 빠르게 짚고 넘어가자.
- 꼭 맞는 영역(배포 즉시 효과) : AI 매개 애플리케이션, 비동기 게임 백엔드, 실시간 협업 B2B 대시보드. 깃허브-버셀-파이어스토어 스택은 예측할 수 없는 LLM API의 지연을 완벽하게 흡수하며, 여러 클라이언트에 걸쳐 즉시 상태를 동기화하므로 개발자가 맞춤형 웹소켓 인프라를 구축할 필요가 없다.
- 중간 지대(가능하지만 절충이 필요) : 헤드리스(headless) 전자상거래, 적당한 수준의 IoT 텔레메트리, 예약된 일괄 처리가 필요한 앱. 카탈로그가 복잡한 관계형 SQL 제약 조건에 과도하게 의존하거나, 백그라운드 보고 작업에 소요되는 시간이 길어 서버리스 실행 한도에 걸린다면 마찰이 발생하게 된다.
- 위험 영역(다른 방법을 찾아야 함) : 초단타 트레이딩, 빠른 속도로 진행되는 액션 멀티플레이어 게임, 무거운 데이터 ETL 파이프라인, 핵심 회계 장부. 서버리스 아키텍처는 초고속 반응이 필요한 데이터를 처리하는 데 필수적인 웹소켓을 열린 상태로 유지할 수 없으므로 무거운 연산 작업은 도중에 시간 초과로 갑자기 종료된다.
다만 이런 범주가 상호 배타적이지 않다는 점도 염두에 둬야 한다. 풀 스케일 전자상거래 플랫폼을 비롯한 많은 기업 애플리케이션이 사실 여러 범주의 경계에 걸쳐 있다. 버셀과 파이어스토어를 사용해서 장바구니와 같이 수명이 짧은 사용자 상태를 처리하는 빠르고 반응성이 높은 상점을 구축하면서도, 동시에 수파베이스(Supabase), 플래닛스케일(PlanetScale)과 같은 관리형 SQL 데이터베이스를 여기에 “맞춰 넣을” 수 있다. 혼합 접근 방식을 사용하면 백오피스 재고와 회계장부에 필요한 관계형 무결성을 유지하면서 이 스택이 제공하는 프론트엔드 속도도 함께 얻을 수 있다.
깃허브 : 토대
깃허브에 대해서는 소개가 필요 없을 것이다. 깃허브는 현재 개발 생태계의 중심이다. 필자는 여전히 CVS와 SVN에 약간 향수를 느끼지만, 깃이 가져온 긍정적 혁신에는 이론의 여지가 없다. 깃허브 오케스트레이션 기능과의 결합을 기점으로 사실상 업계 전체가 이런 형태의 플랫폼을 채택한 것은 자연스러운 수순이었다.
깃+깃허브는 프로젝트를 기업하고 자동화하는 방법 관점에서 이미 막대한 위력을 발휘한다. 그러나 깃허브와 버셀을 결합하면 한 차원 더 높은 경험을 할 수 있다. 자바스크립트 기반 프로젝트의 경우 단순한 깃허브 푸시를 즉시 배포되는 클라이언트와 서버리스 함수로 변모시킬 수 있다. 이는 로컬 머신의 원시 코드에서 전 세계에 걸쳐 배포된 풀스택 아키텍처로 이동하는 가장 간편하고 손이 적게 가는 방법 중 하나다.
버셀 : 넥서스
버셀은 단순한 배포 호스트에 그치지 않고, 고속 노옵스 아키텍처 전반을 엮는 제어 평면이다. 깃허브, 파이어스토어와 함께 버셀의 더 깊은 강점은 반응형 프론트엔드와 외부 상태 저장 서비스 사이에서 오케스트레이션 계층 역할을 한다는 데 있다.
버셀은 어느 브랜치가 어느 환경으로 가는지를 세밀하게 조정하기 위한 풍부한 기능을 제공하며, 즉각적인 롤백과 같은 유용한 기능도 있다. 프로젝트의 버셀 대시보드에 로그인하기만 하면 배포 이력과 오류, 로그를 모두 확인할 수 있고 메뉴만 선택하면 간단히 과거 버전으로 롤백하거나 두 버전을 비교할 수 있다.
서드파티 서비스(예를 들어 수파베이스와 같은 관리형 SQL 데이터베이스 또는 스트라이프(Stripe)와 같은 결제 처리 시스템)를 “엮어 넣을” 때, 버셀 서버리스 함수는 간편한 인터페이스가 되고 버셀의 어댑터가 통신을 처리한다. 통합 로직(서비스 계층)을 버셀의 글로벌 에지 네트워크로 덜어내서 UI와 백엔드를 깔끔하고 반응성이 뛰어난, 디커플링된 상태로 유지할 수 있다.
간단히 말해 버셀을 사용하면 엔터프라이즈 재고 시스템과 같은 일부 애플리케이션에 필요한 복잡한 트랜잭션 무결성을 희생하지 않고도 “노옵스” 개발 수명 주기가 주는 속도의 이점을 얻을 수 있다.
파이어스토어 : 데이터스토어
파이어스토어는 극단적으로 가벼운 NoSQL 클라우드 데이터스토어다. 방대한 부가 기능을 갖추고 있지만, 가장 큰 강점은 어느 데이터든 거의 다 수용하고 데이터 변경에 대한 이벤트 주도 구독을 제공한다는 점이다.
구독 기능과 이벤트 주도 방식이 결합돼 파이어스토어는 관리형 백엔드를 위한 가장 명쾌한 솔루션이 된다. 컬렉션이나 필드를 구독한 다음 “비정형” 데이터(즉, 가변 필드가 있는 JSON)를 던져 넣기만 하면 되고, 클라이언트 입장에서는 자신이 관심 있는 변경 사항이 발생할 때까지 그냥 대기하면 된다.
연동 과정은 매우 간략해서, 브라우저(또는 네이티브 모바일 앱)를 파이어스토어에 직접 연결하고 이벤트 수신을 대기하는 게 전부다. 여기서 인증과 데이터 가시성을 위한 ID 문제를 제기할 수 있지만 파이어스토어에는 잘 작동하는 인증 모듈이라는 세 번째 강력한 장점이 있다. 즉, 실제로 매우 간단하면서도 앱을 확실히 보호한다.
인증 솔루션이 너무 단순하고 불투명하거나 지나치게 자잘한 부분에 얽매이는 것처럼 보일 수 있지만 파이어스토어 인증은 몇 가지 기본 구성만으로 거의 즉시 적절한 인증을 사용할 수 있게 해준다.
길게 설명할 필요 없이, 현실적이고 접근성 좋은 인증 솔루션을 두면 많은 실제 애플리케이션을 처리할 수 있는 프로덕션 급으로 스택 수준을 올려놓을 수 있다. 파이어스토어 인증은 스트라이프와 같은 다른 중요한 API와 잘 연계된다. 일반적으로 인증은 마치 혼다 시빅을 타고 오프로드를 달리는 듯한 느낌인데, 파이어스토어의 인증 접근 방식은 일반적인 과속방지턱 정도의 느낌이다. 코드에 엮어서 넣어야 하는 복잡한 요소가 아니라 플러그인처럼 끼워 넣는 또 하나의 구성요소일 뿐이다.
속도 스택의 한계
이 아키텍처는 유연성에 최적화된 여러 구성요소를 결합한다. 다만 이 특성에는 명확한 한계점도 따르는 만큼 프로덕션 워크로드를 적용하기 전에 이런 한계를 반드시 이해해야 한다.
서버리스 수명 주기
서버리스 함수는 요청을 처리하기 위해 생성되고 처리 이후 곧 종료되며 모든 상태를 상실한다. 그런 이유로 웹소켓을 열린 상태로 쥐고 있을 수 없다. 실시간 멀티플레이어 액션 게임이나 초단타 트레이딩 대시보드와 같이 지속적인 밀리초 미만 단위의 양방향 스트림이 필요한 시스템에서 순수 서버리스는 계속 마찰을 일으키게 된다. HTTP 웹훅을 통해 무상태 엔드포인트로 메시지를 라우팅하기 위해서는 어쩔 수 없이 서드파티 관리형 웹소켓 서비스를 가져와야 한다.
실행 시간 제한
버셀은(모든 서버리스 플랫폼이 그렇듯이) 작업에 엄격한 타임아웃을 적용한다. 엔터프라이즈 등급에서는 최대 15분까지 허용할 수 있지만 표준 함수는 대체로 10초~60초 후에 타임아웃된다. 장시간 실행되는 작업, 예를 들어 20분 정도 소요되는 영상 트랜스코딩, 데이터베이스 스크립트, 다단계 AI 에이전트 워크플로우 오케스트레이션 등은 이런 제한에 걸리게 된다. 무거운 작업은 구글 클라우드 런과 같은 전용 장기 실행 서비스로 덜어내거나 메시지 큐를 통해 더 작은 비동기 조각으로 쪼개야 한다.
콜드 스타트의 현실
특히 가벼운 에지 네트워크에서 초기화 시간을 최소화하는 데 있어서는 지금까지 상당한 진전이 이뤄졌지만 전통적인 Node.js 기반 서버리스 함수는 여전히 콜드 스타트를 경험한다. 함수가 최근에 호출되지 않았거나 트래픽 급증으로 인해 동시에 새 인스턴스를 생성해야 하는 경우, 컨테이너가 준비되고 코드가 로드되는 동안 첫 번째 요청은 현격한 지연을 겪게 된다.
RAM 대신 API
전통적인 서버 환경에서는 휘발성 데이터를 전역 RAM에 저장해 후속 요청이 공유 컨텍스트에 즉시 액세스하도록 할 수 있다. 서버리스 모델에서는 모든 요청이 새 컨테이너에 도달할 수 있으므로 모든 공유 컨텍스트를 외부화해야 한다. 파이어스토어는 상태 관리자 역할을 아주 잘 수행하지만, 밀리초 이하 단위의 고빈도 휘발성 캐싱을 데이터베이스에 의존할 경우 네트워크 지연과 작업당 비용이 발생한다. 다만 하나의 앱 서버와 VM을 사용하지 않는 한 서버에서 공유 RAM 상태를 사용하는 것도 간단한 일은 아니다(고가용성 또는 페일오버 요구사항으로 인해 전통적인 서버에서도 RAM의 이득이 반감되기 때문).
속도와 제어를 위한 튜닝
모든 아키텍처 결정은 타협이다. 대가 없는 선택은 없다. 깃허브, 버셀, 파이어스토어 스택을 채택한다는 것은 세밀한 제어보다 속도를 명시적으로 극대화하는 선택이다.
기반 운영체제를 세밀하게 조정하고 소켓을 열린 상태로 쥐고 있거나 한 시간 길이의 백엔드 스크립트를 실행하는 능력을 잃는 대신 0에서 글로벌 분산 환경까지 즉각 확장되고 데브옵스 유지보수가 사실상 불필요하며 현대 애플리케이션 개발의 비동기적인 이벤트 주도 현실을 완벽하게 흡수하는 아키텍처를 얻게 된다.
