클라우드에서 서비스 스타트업 시작하기
디지털서비스 이슈리포트 2024-07호
이 글은 제가 NIA [한국지능정보사회진흥원]의 < 디지털서비스 이슈리포트 > 2024년 7월호에 기고한 글입니다. 원본 글 '클라우드에서 서비스 스타트업 시작하기'를 이곳 브런치에서도 공유합니다.
들어가며
클라우드 컴퓨팅이 가까이에서 사용 가능하게 된 이후 다양한 방식으로 서비스들을 이 클라우드 안에서 이용할 수 있게 되었다. 창업자 혹은 스타트업들은 이를 이용해서 클라우드 기반으로, 가지고 있는 사업 아이템들을 비교적 쉽게 구현할 수 있게 되었고, 기술적인 고민들을 일일이 하기보다 원래 하고자 하는 부분에 더 많은 시간과 에너지를 할애해서 쓸 수 있게 되었다.
하지만, 실제로는 서비스를 만들어 처음 데모를 만드는 것부터 더 많은 사용자들을 감당하는 단계까지 사업을 키워 나가는 과정에서 클라우드의 지원을 받지만 이전에 없던 여러 가지 일들이 벌어지게 되고, 또 이 부분들을 도와주는 여러 서비스 혹은 프로그램들이 다양한 방식으로 존재해 왔고 변하면서 발전해 가고 있다.
이 글에서는 독자 여러분들이 일반 사용자를 대상으로 하는 가상의 서비스를 만드는 스타트업을 만들어서 운영하게 될 때 어떤 일들을 겪게 될 지를 간접적으로 알려 드리려 한다. 여기서 가상의 서비스는 간단한 HelloWorld 혹은 단순한 게시판의 예를 들겠으며, 어떤 내용으로 어떤 사용자들을 어떻게 모을 건지, 제품 내에서 어떤 일들이 벌어질 지는 논외로 하고, 많은 사용자들이 모이게 될 때 클라우드 서비스를 어떻게 이용하게 될 지 등에 대해 창업자 혹은 기술 책임자의 시각에서 고민 거리들을 모아 이야기 하겠다.
필수적인 요소들
게시판 데모 만들기
HelloWorld 혹은 간단한 게시판의 예를 들어 만드는 데 있어 모든 내용을 처음부터 다 프로그램을 만드는 것이 아니라, 일반 사용자에게 이용되는 서비스를 만들기 위해서는 아래의 다양한 선택들을 해야 한다.
서버 프레임워크 : Node.js , Python (Django, Flask), Java (Spring), Ruby on Rails 등
데이터베이스 : MySQL, PostgreSQL, MongoDB 등
API 설계 : RESTful API 또는 GraphQL
프론트엔드 프레임워크 : React, Angular, Vue.js 등
디자인 : Bootstrap , Tailwind CSS
데모 서비스를 만드는 단계에서 각 항목 사이에 큰 차이는 없고, 기술 책임자 혹은 개발자들이 가장 구현하기 익숙한 환경에서 필요한 선택을 하고, 데모를 구현한다. 로컬 환경에서 기본적인 테스트를 하고, 사용자 입장에서 여러 테스트를 해 본 후 여러 기능들을 테스트 해 보며, 관리자의 시각과 사용자의 시각에서 테스트를 해 본다.
예를 들어, 하나의 기계에서 프론트엔드, 백엔드, 데이터베이스를 같이 설치해서 운영한다고 하면, 프론트엔드로 리액트(React)를 사용하면 3000번 포트를, 서버 프레임워크로 파이썬 장고(Django)를 사용하는 경우 8000번 포트를, 그리고 로컬에 설치된 PostgreSQL 데이터베이스는 5432 번 포트를 사용하게 함으로써 필요한 기능들을 하나의 로컬 기계에서 연결해서 테스트해 볼 수 있다. 물론 각각의 포트들은 다른 번호들로 설정 가능하고, 이후 클라우드 환경으로 변경되더라도 서로 다른 기계들의 주소를 사용해서 전체를 구현할 수 있다. 아래는 장고를 성공적으로 설치한 후, 실행할 때 보이는 화면과 HelloWorld에 해당하는 리액트 코드 예제와 실행 화면을 보여 준다.
그림 1: 장고의 기본 실행 화면( https://realpython.com/get-started-with-django-1/ )
그림 2. 리액트 코드와 실행 화면 그리고 아래는 장고에서 지원하는 관리 도구(admin tool) 예제 화면이다. 서비스가 만들어졌다고 해도 여러 기능들을 테스트 해 보기 위해 혹은 수정이 필요한 경우 이 도구를 이용해서 회원 가입 승인이라든지, 게시판 내용의 삭제 혹은 추가 등을 할 수 있고, 모든 데이터베이스 내용을 열람, 수정할 수 있어 필요한 기능을 테스트해 볼 수 있다. 장고 이외의 다른 서버 프레임워크들도 비슷한 정도의 관리 도구를 제공하고 화면 구성 등을 수정할 수 있다. 개발 단계에서 데이터베이스를 직접 열람할 수도 있지만, 그 경우 과도한 권한으로 인한 부작용이 클 수 있어 추천하지 않는다.
그림 3. 장고 관리 도구 예제 화면서비스를 만들고 관리 도구까지 사용 가능하면 비로소 데모 시스템이 만들어졌다고 생각할 수 있겠다. 로컬 환경에서 테스트가 끝났다면 이제 이를 클라우드에 올려 여러 사람들이 테스트 해 볼 수 있도록 한다.
클라우드 컴퓨팅 자원
이제 로컬에서 만든 데모를 클라우드로 데모 환경을 옮겨야 하는데, 클라우드 업체 별로 다양한 옵션들이 있다. 먼저 가상의 기계를 대여해서 모든 설정을 하게 할 수 있는데, 각각 아래와 같은 이름으로 사용 가능하다.
AWS : 아마존 엘라스틱 컴퓨팅 클라우드 ( EC2 )
애저: 애저 가상 머신 ( Azure Virtual Machine )
GCP : 구글 클라우드 엔진 ( Google Cloud Engine )
네이버 클라우드 : 서버 ( Server )
CPU 종류와 개수, 메모리 크기, 스토리지 크기 따라 다양한 옵션들이 있고, 사용 가능한 물리적 위치와 운영체제에 따라 과금이 달라진다. 가격은 2024년 7월 기준으로 시간당 1센트에서 10센트 정도이고, 이는 월 7달러에서 70달러 정도의 비용을 의미한다.
로컬에서 만들어진 데모는 하나의 기계에 여러 서비스를 운영하는 방식으로 만들어져 있었지만, 각각의 서비스를 따로 운영하는 경우는 여러 가지의 선택지가 있을 수 있다. 서로 다른 서비스는 다른 기계들에 할당하고 여러 개의 기계에 자동으로 배포되게 하는 서버리스 환경으로 구현해서 많은 트래픽에 대비하기도 하고, 더 비싸지만 용량이 큰 기계를 확보함으로써 많은 트래픽을 준비하거나 더 빠른 데모를 구현하게 할 수도 있다.
같은 방식으로 데이터베이스도 제공되는 서비스를 이용할 수 있다. 위 데모에서 사용한 PostgreSQL 의 경우 아래와 같은 이름으로 주요 클라우드 플랫폼, 다양한 서비스에서 지원한다.
AWS : 아마존 RDS for PostgreSQL
애저: 애저 PostgreSQL 데이터베이스 ( Azure Database for PostgreSQL )
GCP : 클라우드 SQL for PostgreSQL ( Cloud SQL for PostgreSQL )
네이버 클라우드 : Cloud DB for PostgreSQL
이들은 관리형 서비스들로 자동 백업, 패치, 업그레이드 등을 지원하고, 복구와 고가용성 설정 등을 할 수 있으며 모니터링 및 성능 분석 도구도 제공하는데, 사용량이 작은 서비스라고 하더라도 아마존 RDS의 경우 시간당 2센트, 월 약 15달러 정도가 발생하게 된다. 실제 대규모 서비스로 가면 기계 당 월 1,000 달러 이상까지 비용이 발생하겠지만, 데모를 위한 작은 시스템이라도 이 즈음에서 대개 유의미한 비용이 발생하게 되고, 비용에 대한 고민이 시작된다.
도메인, 회사 소개 페이지
회사 이름과 서비스 이름을 정하는 것만큼 도메인을 정하는 것도 어려운 일이고, 실제 사용자들을 만나 시범 서비스를 하게 될 때, 유의미한 이름을 가진 도메인을 운용하는 것은 매우 중요한 일이다. 그리고, 회사 소개와 제품 소개가 담겨 있는 정적인 페이지들이 있으면 투자자들과의 관계나 제휴사들과의 협업의 기회에 도움을 많이 받을 수 있다.
이 때 앞에서 클라우드 환경에서 기계를 할당 받아 운영하는 것의 더 간단한 버전으로, AWS 에서는 라이트세일 (Lightsail ) 이라는 제품군이 많은 도움이 된다.
그림 4. AWS 라이트세일 가격미리 설정된 인스턴스를 저렴한 가격에 사용할 수 있고, 네트워크 도메인까지 연결할 수 있어 극초기 회사들의 데모와 홈페이지 운영에 자주 이용된다. 작은 리눅스 기계의 경우 월 3.5 달러에 사용할 수 있고, 3개월 무료 사용까지 할 수 있어서 로컬 환경의 데모를 바로 옮겨 올 수 있는 경우 다른 클라우드 환경들을 설정할 때까지 유용하게 쓰인다.
스타트업을 시작할 때 준비할 것들이 많이 있지만, 소유하고 있는 도메인과 회사 소개 혹은 서비스 소개 페이지들은 이후 각종 스타트업 지원 프로그램 시 검증하는 용도로도 자주 쓰이게 된다. 만일 지원을 받고 싶은 프로그램이 있는 경우, 법인 등록, 창업자 등록 등과 함께 도메인과 홈페이지를 먼저 만들어 놓는 것을 추천한다.
스타트업 지원 프로그램들
스타트업을 운영할 때 많은 경우 다양한 곳에서 지원 프로그램을 이용하게 되는데, 정부 지원, 벤쳐 캐피털들이 운영하는 프로그램 등과 더불어 각종 클라우드 업체들도 아래와 같은 프로그램을 운영한다. 각각 잠재적 고객 확보의 차원에서 스타트업들을 다양한 방법으로 지원하고 있으니 스타트업들은 많은 참고와 지원을 추천한다. 심사 결과에 따라 규모들의 차이가 있긴 하지만, 아래의 지원들을 기대할 수 있고, 많은 도움을 받을 수 있다.
무료 클라우드 서비스 사용 지원
전문가들의 멘토링 지원
네트워킹, 자금 조달 지원
제휴 서비스 이용권, 할인권
필요한 교육 이수
아래는 각 클라우드 업체 별 운영하는 프로그램의 이름들과 특징들이다.
마이크로소프트 : 마이크로소프트 스타트업 파운더스 허브 (Microsoft for Startups Founders Hub )
최대 $150,000 애저 크레딧 / 1년
최대 $2,500 오픈AI 크레딧
깃허브(GitHub) 엔터프라이즈 20인 / 1년
스트라이프(Stripe) 최대 $25,000 수수료 없는 결제 지원
AWS : AWS 스타트업 (AWS Startup)
최대 $100,000 AWS 크레딧 / 1년
구글 클라우드 : 구글 포 스타트업 클라우드 프로그램 (Google for Startups Cloud Program)
최대 $100,000 구글 크레딧 / 1년
AI 승인 시 최대 $350,000 구글 크레딧
네이버 클라우드 : 네이버 클라우드 플랫폼 그린하우스 베네핏 ( Naver Cloud Platform Greenhouse Benefit )
최대 2,000만원 크레딧 / 1년
메일, 메신저, 결제, 드라이브 등 다양한 기능을 제공하는 그룹웨어 워크플레이스(WORKPLACE) 사용 가능
각 프로그램들이 무료 클라우드 사용을 지원하기에 서비스가 있는 곳의 프로그램을 먼저 신청하면 좋고, 다른 서비스들도 동시에 신청할 수 있지만, 보통 12개월의 기한 제약이 있으니 필요할 때 시작하도록 한다. 그리고 크레딧 사용의 경우 모든 회사들이 처음에 $1,000 정도의 크레딧을 지원하여 데모 운영 정도를 할 수 있게 하고, 더 큰 크레딧은 시드 투자 이상의 투자자들과 같이 라운드를 올라가며 지원하는 방식으로 운영한다.
서비스 확장 시 필요한 것들
기본적인 데모 서비스를 운영한 후에, 투자를 받거나 앞의 지원 프로그램들을 이용해서 더 많은 사용자를 위한 확장을 고려하게 되면, 이전에 없던 혹은 미뤄 두었던 이슈들이 발생하는데, 비지니스의 종류와 상관 없이 실제 벌어지는 일들을 몇 개 정리해 본다.
약관과 사용자 관리
간단한 데모라 할 지라도 일반인들을 대상으로 서비스를 하게 되면 각 서비스가 제공하는 약관과 함께 사용자 관리가 필요하게 된다. 사용자 등록을 제한된 방법으로 할 때는 필요한 조치를 하나하나 다룰 수 있지만, 자동으로 회원 가입이 되는 경우 예상되는 일에 대해 제품 면에서 미리 준비가 되어 있어야 한다. 사용자가 가입 과정을 자동으로 되기보다는 먼저 수동으로 가입 승인을 해서 불필요한 제품의 노출을 줄일 수 있는데, 이 경우 위에서 쓰인 장고 관리 도구의 기능을 유용하게 쓸 수 있다. 이는 제품이 아직 데모 단계에 있어 특별한 노출을 막고 싶을 때에도 유용하게 쓰인다.
회사나 서비스가 필요한 허가를 받은 후, 임의의 사용자를 대상으로 운영하기 시작할 때에는 약관과 개인 정보 관련한 고지 등이 필요하다. 특히 허가와 개인 정보 관련해서 현지법에 따라 지켜야 할 규정들이 있게 되고, 이는 임의의 사용자가 가입을 할 때 필요한 내용들을 접근 가능하게 하는 방식으로, 충분한 정보들을 고지하는 데 중점을 둔다고 보면 되겠다. 아래에는 오픈서베이 와 뱅크샐러드 의 모바일 홈페이지에 있는 약관과 개인정보 관련한 내용들의 예제이다.
그림 5. 약관과 개인정보 처리 방침 예제 (오픈서베이, 뱅크샐러드)결제 시스템 연동과 운영
회사나 서비스가 필요한 허가를 받은 후, 약관의 기본적인 것을 갖추고 나서는, 결제 서비스를 연결하거나 운영 관련 기능을 구현한다. 수익화를 위해 각종 지불 관련 기능을 추가하고 싶을 때 미국의 스트라이프 API 라든지 한국의 포트원 같은 업체의 결제 관련 API 등을 사용할 수 있다. 다만 게시판의 예제에서 직접적인 결제 서비스 연결 여부는 비즈니스 모델에 해당하는 것이라 이견의 여지가 있지만, 이를 포함한 다양한 운영을 대비해야 한다.
사용자 피드백을 받을 수 있는 폼을 제품의 일부로 넣을 수도 있고, 실제 운영의 경우 이메일 응대나 전화 응대 같은 일이 벌어질 수 있게 된다. 결제가 직접 연결되는 경우 환불과 취소 등이 일어날 수 있고, 회사 내에서 이 요구들을 전담하는 구성원이 필요하게 된다. 대개 초기 멤버들이 교대로 담당하다가 실제 CX(customer experience) 직군의 전문가가 필요하게 되고, 그들의 생산성을 높이는 형태로 관리 도구를 변경해야 한다. 이 개선된 관리 도구를 통해서 누가 언제 어떤 데이터를 열람, 수정하는지를 남기기 시작해야 하고, 이 모든 과정을 운영의 일부로 취급한다.
스케일 조절과 점검
사용자 혹은 사용량이 늘어 시스템 전체 부하가 몰리는 게 예상되는 경우, 더 많은 리소스를 준비해서 이를 대비해야 하는데, 스케일 업과 스케일 아웃 두 가지 방식을 사용한다. 예를 들면 위의 게시판 예제의 경우 접속해서 읽는 사용자가 늘어나는 경우와 글을 쓰는 사용자가 느는 경우 다른 접근이 필요하게 된다. 이 경우 모니터링을 통해 미리 어느 곳이 병목인지 알고 있는 게 중요하다.
동시 접속자가 많아져서 읽기가 많아지는 경우는 프론트앤드와 읽기 인스턴스들을 여러 개 더 확보해 놓음으로 다를 수 있겠고 (스케일 아웃 ) , 쓰기가 많아지는 경우에 AWS RDS 와 같은 관계형 데이터베이스는 더 빠르고 비싼 기계를 확보해서 기존 서비스를 대체하게 함으로써 이 문제를 다룰 수 있다.
그림 6. 스케일업과 스케일 아웃의 예제다만, 이후 트래픽이 줄어들게 될 경우, 비용 절감을 위해서 원래대로 돌리거나 낮은 사양으로 조절하는 게 필요한데, 스케일 아웃의 경우 추가된 리소스들을 단순히 반납함으로써 시스템의 지장 없이 가능하지만, 스케일 업의 경우 낮은 사양의 기계로 교체를 해야 하는데, 이 경우 최소 순간적인 단절이 일어나기에 안전하게 점검을 걸어 사용자들의 접속을 인위적으로 차단해서 점검을 공지한 후에 필요한 내용을 해결한다. 한국의 금융 관련 서비스들은 이 점검 기간을 공지하고 운영하도록 하고 있고, 매일 혹은 매 주 마감의 형태로 필요한 내용들을 보고하도록 되어 있다.
참고로, 실제 환경에서 사용량이 많아지는 경우 병목은 대개 데이터베이스 내에서 일어나게 되고, 특히 읽기에 소모되는 자원들 때문에 쓰기가 제대로 일어나지 않는 경우가 대부분이다. 이를 해결하기 위해 읽기와 쓰기의 분리, 부하 조절, SQL 구문 최적화 등 여러가지 다양한 노력이 필요하고, 캐쉬 시스템을 구현해서 성능을 올리기도 한다.
이벤트 관리와 데이터 관리
그리고 데이터베이스에 필요한 내용들이 많이 쌓이게 되어 이를 분석하기 위해서는 데이터베이스 내의 내용을 분석 전문 도구들이 있는 곳으로 이동시켜 사용할 수 있도록 한다. 기본적으로 사용되고 있는 운영계의 데이터베이스는 끊임없이 변하므로, 주기적으로(예를 들면 매일) 어느 시점의 데이터베이스 스냅샷을를 모아 분석할 수 있는 분석계로 보내는 방법을 쓸 수 있고, 이 때 운영계에 영향을 주지 않으면서 데이터 수집을 할 수 있도록 한다. 분석을 효율적으로 하는 방법에도 여러 가지 기법들이 있다. 최근에는 데이터브릭스나 스노우플레이크 등이 여러 클라우드 환경을 지원하는 솔루션이 각광을 받고 널리 쓰이고 있다.
서비스를 운영하면서는 실제 사용자들의 행동에 대한 많은 내용들을 모으는 것이 제품의 품질 개선에 중요하다. 게시판의 경우 게시판 내용 뿐 아니라 화면 스크롤 내용이라든지 페이지간 이동 형태, 검색 시 사용되는 필터나 쿼리 등의 다양한 정보들을 모으는 게 필요하고, 이 내용들을 담기 위해 코드를 수정하거나 SaaS 제품들과의 통합이 필요하다. 사용하는 데이터베이스에 별도의 전담하는 테이블을 만들고 이를 이용하는 코드를 만들거나 구글 애널리틱스 혹은 앰플리튜드(Amplitude)와 같은 유무료 도구를 통합함으로써 사용자들의 행동과 관련된 이벤트를 모을 수 있다.
그림 7. 데이터브릭스와 스노우플레이크 비교비용 관련해서 주의할 점들
스케일 아웃의 부작용
시스템이 준비한 양보다 예상보다 많은 사용자들이 몰리게 되는 경우 어떤 형태로든 장애가 일어나게 되고 이를 대응하게 되는데, 스케일 아웃이 아주 잘 준비된 시스템의 경우 너무 많이 몰리게 될 경우 대기열을 건다든지 예산 관리 경고를 꼭 켜 놓아야 한다. 클라우드 시스템을 사용하는 경우 리소스의 옵션이 다양해서 스케일 아웃이 너무 자연스럽게 진행이 되면, 실수로 불필요한 자원을 쓰게 되는 경우가 일어나곤 한다.
비슷한 사례로 관계형 데이터베이스의 경우 무심코 “select *” 같은 동작이 일어나게 되면 운영계의 데이터베이스 내의 특정 테이블 전체를 훑는 연산이 일어나게 되고, 이는 읽기 자원의 부족, 데이터베이스 자원 고갈 등의 영향으로 이어지게 된다. 이 때 자원 고갈뿐 아니라 불필요한 연산을 지원하느라 비용이 전가되기도 하는데, 모두 주의 깊게 다루어야 하겠다.
아울러 사용자를 모으는 마케팅 이벤트들은 조율이 된 상태에서 진행해야 할 것이고, 여러 클라우드 서비스와 가시성 도구(observability tool )에 필요한 알람과 경고를 알릴 수 있게 설정해 놓고, 관련된 프로세스를 정의해 놓아야 한다.
무료 크레딧 기간 마감
초기의 스타트업의 경우 클라우드 시스템에서는 연간 $1,000 부근의 크레딧을 받을 수 있는데, 이는 보통 규모의 데모 서비스를 만들어 운영하고, 클라우드에서 제공하는 데이터베이스와 몇몇 컴퓨팅 인스턴스를 1년 정도 여유롭게 운영할 수 있는 양이다. 그리고 투자를 더 받게 되는 경우 프로그램들은 다음 레벨로 지원의 폭이 넓어지는데, 이 경우 $100,000 혹은 그 이상의 크레딧을 운영할 수 있게 되고, AI 관련해서는 $300,000 이상의 운영비를 지원받을 수 있다.
이 경우 사용자가 늘었다든지 각종 스케일 기법들을 이용해서 운영하는 그 자체로 축하할 일인데, 이는 다르게 말하자면 매달 $10,000 이상 지불하고 있고, 크레딧 마감 기간이 되어서는 갑작스럽게 아주 부담스러운 청구서로 다가오게 된다. 단순한 게시판에 초기 사용자 수를 고려하는 경우 그렇게까지 해당이 있진 않겠지만, 이 비용이 실제 사용자들의 접근 때문에 발생하는 경우 비용 절감의 노력들을 미리부터 해 놓는다든지, 다른 클라우드 솔루션으로 옮겨 갈 수 있도록 준비하는 등의 조치가 미리부터 필요하다.
맺으며
지금까지 HelloWorld 혹은 간단한 게시판의 예를 들어 스타트업이 클라우드에서 어떤 과정들을 거치며 서비스를 시작하는지에 대해 2024년 기준으로 훑어 보았다. 실제 스타트업의 운영과 서비스들의 운영은 훨씬 복잡하고 고민할 것들도 많겠지만, 비즈니스 방향과 제품 자체의 품질 등과 별개로 클라우드 플랫폼의 도움을 받더라도 기술적으로 신경 써서 챙겨야 할 일들이 매우 많다 하겠다. 사용할 수 있는 클라우드 솔루션도 여러 가지이고, 각 클라우드 플랫폼 내에서도 여러 개의 서비스들을 선택해야 하는 일들이 많이 생긴다. 그리고 실제 서비스를 구현에 도움이 되는 프레임워크들도 새로운 것들이 나오면서 발전하고, 데이터를 다루는 측면에서도 새로운 기법과 새로운 서비스들이 끊임없이 발전하고 있다.
비즈니스의 성패와 나란히 스타트업들의 창업자와 기술 담당자는 계속 새로운 것들을 배우고, 비교하고 고민해야 할 것이다. 여러 솔루션을 놓고 가장 나은 방법을 선택하는 것, 그리고 그와 관련된 비용을 고민해서 효용을 높이는 것 등은 굳이 스타트업이 아니라도 계속 풀어 나가야 할 문제일 것이다. 이 고민들을 치열하게 풀어 나가는 이 나라의 스타트업들을 특히 기술 개발 책임자들을 진심으로 응원한다.
