1인 개발자로서 테크 스타트업을 운영하며

본문은 요즘IT와 번역가 Chase가 함께 만든 해외 번역 콘텐츠입니다. 필자인 Erik는 개발자로 일하고 있으며, 백엔드와 프론트엔드를 담당하고 있습니다. 크로스핏과 트레이닝을 좋아하고 있으며, 블로그를 통해 다양한 주제의 글을 공유하고 있습니다.

이번 번역 콘텐츠는 1인 개발자가 겪은 스타트업 창업에 대한 경험담을 설명하고 있습니다. 만약 스타트업 창업을 고민하는 개발자가 있다면 이 글을 통해 미리 준비하고 고려해야 할 사항들에 대해 확인하는 것도 매우 좋아 보입니다.

벌써 제가 테크 스타트업을 운영한 지 1년이 되어가네요!

이번 글에서는 지난 1년여 동안 제가 1인 개발자로서 테크 스타트업을 운영하며 경험한 실수들, 여러 생각, 그리고 몇 가지 팁을 여러분께 공유하고자 합니다.

나는 무엇을 개발했나?

저는 헬스장과 운동선수들을 위한 크로스핏 훈련용 애플리케이션(이하 앱) ‘Dreamwod’를 만들었습니다. 이 앱은 Dreamwod라는 이름으로 현재 앱스토어와 구글 플레이스토어에 등록되어 있습니다. 이 프로젝트는 Android 앱 1개, iOS 앱 1개, 백엔드 API, 그리고 회사 웹 페이지로 구성되었습니다.

그럼 이제 어떻게 Dreamwod 프로젝트가 진행되었는지, 그리고 프로젝트를 진행하면서 겪은 저의 실수에 대해 얘기해 보겠습니다.

기술 스택 정하기

저는 기술 스택을 정하기에 앞서 아래와 같은 기준을 정했습니다.

백엔드와 운영

1) 빠른 개발과 이터레이션이 가능해야 함

2) 로컬 환경에서 쉽게 실행 가능해야 함

3) 확장의 용이성과 고부하 처리 능력

4) 배포의 용이성

5) 가능한 단순함을 지향

앱 개발

저는 iOS 개발 경험이 없었기 때문에 빠르게 배울 수 있어야 했습니다.

최종 선정된 기술 스택

백엔드 - Golang

백엔드 언어는 Golang으로 정했습니다. Golang은 배우기 쉽고 컴파일이 빠르면서도 준수한 성능을 보여줍니다. 또, 메모리와 CPU 자원을 적게 사용하기에 선택했습니다.

앱 - Flutter

저는 앱 개발 경험이 적었지만 iOS와 Android 앱 모두를 만들어야 했습니다. 그래서 크로스 플랫폼 개발이 가능한 ‘Flutter’를 선택했습니다.

DB - PostgreSQL

DB는 여러 선택지 중 아래 기준에 부합하는 PostgreSQL로 정했습니다.

• 사용자들 간에 데이터가 공유되어야 한다. 즉, 데이터는 최초 업로더가 아닌 사용자도 열람하고 수정할 수 있어야 한다.
• DB 테이블 간 상호 연결이 가능해야 한다.
• 연구에 시간을 쏟아야 하는 ElasticSearch와 같은 기술 없이 전문 텍스트 검색 (full-text search)[1] 기능이 지원되어야 한다.

전문 텍스트 검색 기능에 관해 덧붙이자면, PostgreSQL은 pg_trgm 확장 모듈을 제공해서 해당 기능을 즉각적으로 차용할 수 있었습니다. 또 postgis 확장 모듈을 통해 앱의 사용자와 헬스장 간의 거리를 계산하기 용이했습니다.

클라우드 – GCP(Google Cloud Platform)

클라우드 호스팅은 GCP와 AWS 사이에서 고민했습니다. 둘 중 GCP를 선택한 이유는 Cloud Run에서 백엔드 API를 실행하고 처리하는 시간만큼만 비용을 지불하면 되었기 때문입니다. 실제로 이 비용은 서비스 개발 및 베타 오픈 기간에 거의 발생하지 않았습니다.

또한 GCP는 여러 편리한 개발 도구들을 제공하고 있습니다. 일례로, 컨테이너[2] 구축 시 사용하는 Cloud Build가 있습니다. GCP Cloud Build는 하루 120분의 무료 빌드 사용 시간을 제공하는데, 1인 개발자인 저에게는 무료로 사용하기 충분했습니다.

GCP의 객체 스토리지[3]인 Cloud Storage는 사용자가 업로드한 콘텐츠를 저장하는 데 사용했습니다. Pub/sub은 비동기 처리[4]에 사용했습니다. 제가 GCP Pub/sub을 사용해서 로컬에서 개발 후 GCP에 손쉽게 배포하는 방법은 별도의 글에 상세하게 서술되어 있습니다.

현재 청구되는 서버 비용은 월 $30(한화 약 3만 6,000원) 정도입니다. 나눠서 살펴보면 CDN의 로드 밸런서[5]가 $18(한화 약 2만 2,000원), Postgres가 $10(한화 약 1만 2,000원) 정도입니다. 당연히 서비스 사용자가 많아지면 서버 비용은 증가하겠지만, 웬만큼 사용자가 많아지지 않는 이상 비용이 부담되지 않을 것으로 예상됩니다.

이메일 - Mailgun

Email 관련 서비스는 굉장히 많지만 이전에 사용한 경험이 있는 Mailgun로 결정했습니다.

결제 - Stripe

결제는 Stripe를 선택했습니다. Dreamwod의 수익 구조는 구독 기반 비즈니스 모델을 채택했습니다. 관련해서 Stripe는 사용자에게 별도의 구독 포탈을 제공하기 때문에 사용자가 구독을 취소하거나 변경하기 편리할 거라 판단했습니다.

회사 웹 페이지 - Webflow

회사 웹 페이지 개발에는 단순하고 별도의 관리가 필요 없는 Webflow을 사용했습니다

업무 방식

노 테스트

개발자 사이에서 개발 테스트를 하지 말라는 조언은 흔히 들어보지 못했을 겁니다. 그럼에도 제가 Dreamwod의 백엔드를 개발할 때 테스트를 총 10회 미만으로 진행한 이유는 아래와 같습니다.

• 어차피 백엔드, 프런트엔드, QA를 모두 저 혼자 구현했습니다.
• Dreamwod 프로젝트는 여러 아이디어를 시도하는 실험의 연속이었는데, 론칭 때 삭제될 수 있는 코드를 테스트하는 것은 개발 속도만 늦출 뿐이라고 판단했습니다.
• 제가 테스트하는 것은 대부분 정규 표현식(regular expression)과 관련된 파싱이기 때문에 API를 직접 테스트하는 것보다 정규 표현식 테스트 웹사이트를 이용하는 게 더 빨랐습니다.

Microservice[6]가 아닌 Monolith[7] 개발 방식

Microservice 방식이냐, 아니면 Monolith 방식을 선택해야 하느냐는 개발자 사이에서 끊임없는 논쟁거리입니다. 저는 개인적으로 Dreamwod를 하나의 백엔드 API(Monolith 방식)로 개발했는데, 그 이유는 아래와 같습니다.

• Microservice 개발 방식에 수반되는 호스팅 관련 문제의 해결과 컨트랙트/API를 정의하는 일에 많은 시간을 할애하고 싶지 않았습니다.
• 프로젝트 초기에 서비스를 어떻게 작은 단위로 분리할지 미리 설계하기 제한되었습니다.
• 현재 시스템에 부하가 적기 때문에 Monolith 방식으로 개발해도 앱 성능에 문제가 전혀 없습니다.

물론 저도 소스 코드를 영역/도메인 별로 분할해서 소위 ‘코드의 스파게티화’를 방지하는 건 좋다고 생각합니다.

Dreamwod 프로젝트를 진행하며 배운 점

• “마지막 20%의 업무가 80%의 시간을 잡아먹는다”라는 명언을 실감했습니다. 실제로 마무리 작업이 예상보다 훨씬 오래 걸렸습니다.
• 혼자서 프로젝트를 진행했기 때문에 납기일이 없었는데, 종종 제 자신에게 관대 해지는 바람에 업무 효율이 떨어졌습니다. 그래서 저에게는 특정한 작업을 꾸준히 하는 업무 스타일이 잘 맞는 걸 체감했습니다. 저는 오전에 집중해서 한 번의 코딩 세션을 갖고, 점심시간에 운동을 한 후에 다시 오후에 한 번 더 코딩 세션을 진행하고 있습니다.

기술 스택을 다시 정한다면?

저는 전반적으로 Dreamwod의 기술 스택에 매우 만족합니다. 그렇지만 다시 개발한다면 몇 가지는 다르게 할 것 같습니다.

• Dreamwod에 REST API보다 GraphQL이 더 적합한지 따져볼 겁니다.
• 지금 기술 스택으로는 Dreamwod를 글로벌 서비스로 확장하기 까다로울 것 같습니다(실제로 이런 걱정을 하게 되면 좋겠네요). 서버와 DB가 벨기에에 호스팅 되어있기 때문에 지구 반대편에 있는 사용자는 Dreamwod가 굉장히 느리다고 느낄 것 같습니다.

제품 관점에서의 회고

때로는 ‘올바른’ 방법보다 ‘빠르고 쉬운’ 방법을 택하는 게 나을 수 있습니다.

• 예를 들어 위에서 언급한 GCP Cloud Run는 Dreamwod를 개발할 때와 비슷한 시기에 시작한 서비스였는데 당시에는 GCP 비밀 관리자(Secrets Manager)에서 Secrets[8]을 당겨오지 못하는 등 구글의 지원이 빈약했습니다. 이런 문제들을 우회하기 위해서 많은 시간을 쏟았는데, 차라리 임시방편으로 개발을 해두고 GCP의 적절한 지원을 기다리는 게 나을 뻔했습니다.

결론

제가 이 글을 작성한 이유 중 하나는 실패에 낙담하지 말라는 말을 전하고 싶었기 때문입니다. 사람들은 결과론적 관점으로 과거의 실패에 대해 쉽게 푸념하기 마련이지만, 여러분이 이뤄낸 성공에 대해서 보람을 느끼는 것도 그만큼 중요함을 명심했으면 좋겠습니다. 1인 개발자로서 창업을 고려하고 있다면 그만 걱정하고 한번 해보세요! 생각 이상으로 재미있습니다!

[1] 여러 문서에서 특정의 문자열을 검색하는 것
[2] 어떤 환경에서나 실행하기 위해 필요한 모든 요소를 포함하는 소프트웨어 패키지
[3] 구조화되지 않은 데이터의 대량 저장을 위한 데이터 스토리지 아키텍처로서, 각 데이터 조각을 하나의 객체로 개별 저장소에 보관
[4] 특정 로직의 실행이 끝날 때까지 기다려주지 않고 나머지 코드를 먼저 실행하는 것
[5] 하나의 인터넷 서비스가 발생하는 트래픽이 많을 때 여러 대의 서버가 분산처리하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 적절히 분산처리하여 해결하는 서비스
[6] 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법
[7] 하나의 서비스 또는 애플리케이션이 거대한 단일 아키텍쳐를 가지도록 하는 소프트웨어 개발 기법
[8] 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 포함하는 오브젝트

<원문 링크>

How I built my tech startup as a solo developer

위 번역글의 저작권은 Erik에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.