Page history of 스타트업을 위한 기술 스택

필자가 스타트업 개발자들에게 가장 많이 받는 질문은 기술 스택을 어떻게 구성할 것인가이다. 심지어 개발자가 아닌 창업자들도 기술 스택에 대해 자문을 구해오곤 한다. 그래서, FAQ 삼아 스타트업에게 적합한 기술 스택을 정리해보기로 했다.

본론으로 들어가기에 앞서 잠시 스타트업의 정의에 대해 합의하고 싶다. 필자는 린 스타트업의 저자 에릭 리스의 정의를 좋아한다.

A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.

쉽게 말해서 스타트업은 아주 불확실한 일을 하는 팀이라는 것이고 이 글에서 제시하는 기술 스택 역시 이런 특성을 고려할 것이다.

경고:이 글은 코덕넷의 다른 기사와 마찬가지로 객관적이고 중립적인 관점이 아니라, 필자의 경험과 지식에 따라 과감하고 단정적으로 기술을 평가할 것이다. 만일 자신이 사용하는 기술에 대한 부정적인 견해를 접했을 때 기분이 상하는 성격의 소유자라면 이 글은 더 이상 읽지 않기를 권한다.

서버 프로그래밍 언어와 프레임워크

보통 스타트업의 기술 선택에서 가장 중요한 것은 서버 프로그래밍 언어와 프레임워크다. 기술 스택의 다른 모든 것들을 합한 것보다 더 중요하다. 스타트업의 서버 프로그래밍 언어로 선택할 만한 것은 다음 세 가지 중 하나다.

• 파이썬
• 루비
• 자바스크립트 (Node.js, io.js, ...)

다른 것들은 별로 고려할 필요가 없다. 한 때 자바도 웹 개발용으로 각광을 받았으나, 현 시점에서 자바와 위의 세 가지 대안의 생산성 차이는 몹시 크다. 자바는 이제 좀더 미션 크리티컬한 분야로 넘기도록 하자. 혹시 PHP를 생각하고 있을지 모르겠는데, PHP는 이제 미래가 없다. 간혹 간단한 웹사이트는 PHP가 가장 빠르다는 주장도 있었으나, 요즘은 PHP가 간단한 웹사이트를 만드는 시간에 Rails나 Django는 제법 복잡한 웹사이트를 만들고 시간이 남아서 어드민까지 붙여놓을 수 있다.

언어를 선택하고 나면 프레임워크도 거의 결정되는 거나 마찬가지다.

• 파이썬 - Django
• 루비 - Ruby on Rails
• Node.js - express.js

물론 다른 선택도 있으나, 이 세 가지 프레임워크는 널리 쓰이기도 하고, 딱히 큰 단점이 있는 것도 아니라서 다른 대안을 선택한다고 해도 특별히 나은 선택이 되기는 어려울 것이다. 

셋 중에 개발 생산성이 가장 뛰어난 것은 Ruby on Rails다. 다만, 그 높은 생산성을 얻기까지는 Rails를 깊이 파고 들어야 하고, 트렌드를 잘 따라가야 한다. 루비 언어를 깊이 아는 것보다 Rails를 깊이 아는 것이 더 중요하다. 서드 파티 코드를 넣기가 쉬워서 뭔가 구현하고 싶은 게 있을 때 찾아보면 거의 다 있고, 아주 쉽게 설치할 수 있기 때문에 얼핏 어려워 보이는 기능을 순식간에 구현하곤 한다. 그래서 이 맛에 길들여진 Rails 개발자들은 다른 프레임워크를 거부하는 경우를 흔히 볼 수 있다. 설령 여러 가지 이유로 다른 언어를 쓰더라도 웹 개발만큼은 Rails를 버리지 않는다.

반면, Django는 초기 학습 장벽은 비슷하지만 그걸 넘어서고 나면 그 다음에는 별로 학습할 게 없다. 그 다음부터는 Django보다 파이썬이 중요하다. Ruby on Rails는 문제를 Rails로 해결한다면, Django는 문제를 파이썬으로 해결한다. 그래서 중급 이상으로 올라서는 것은 Django가 더 빠르나, Django를 계속 깊이 판다고 해서 큰 이득이 있는 것은 아니다. 개발 생산성의 성장 그래프를 그린다면 다음과 같을 것이다.

Node.js는 요즘 인기를 끌고 있긴 하나, io.js의 분화 같은 일도 있고, 콜백지옥도 아직 완전히 해결된 상태가 아니다. express.js도 훌륭하지만 아직 Django나 Rails에 비하면 부족함이 있다. 그래서 일반적인 웹사이트나 API 서버를 개발한다면 Node.js는 파이썬이나 루비에 못 미친다. 그럼에도 불구하고 세 가지 권고안 중에 들어가는 이유는 전통적인 스타일의 웹과 다른, Single-page_application의 경우에는 Node.js에 유리한 점이 많기 때문이다. 특히 AngularJS 등의 자바스크립트 MVC 프레임워크와 결합하면 클라이언트와 서버의 코드를 매끄럽게 이어지게 개발할 수 있다. 그리고 웹앱 뿐 아니라 채팅처럼 실시간으로 커뮤니케이션이 일어나는 기능을 가장 손쉽게 구현할 수 있는 방법인 socket.io도 Node.js에 기반하고 있다. 타 언어도 socket.io를 지원하지만 Node.js에서 가장 사용하기 쉽다. 

단, Node.js를 사용할 때는 신경써야 할 점이 두 가지 있다. 하나는 콜백지옥에 대한 해법을 선택해야 한다는 것이다. node-fibers가 비교적 일찍 나와서 여러 라이브러리에 적용이 되어 있으나, 자바스크립트 커뮤니티에서는 generator를 더 밀고 있다. generators-vs-fibers 같은 글이 선택에 도움을 줄 것이다. 사용하려는 다른 라이브러리가 둘 중에 뭘 사용하느냐에 따라 선택하는 것도 방법이다. 참고로 step이나 promise는 대안처럼 보이지만 별 도움이 되진 않는다.

두번째 고민해야 하는 것은 자바스크립트를 그대로 쓸지, 아니면 커피스크립트 같은 자바스크립트 기반의 다른 스크립트 언어를 쓸지이다. 자바스크립트를 콜백지옥과 함께 쓰다보면 코드 가독성이 심각하게 떨어지기 쉬운데, 이럴 때 커피스크립트가 도움이 될 수 있다. 

셋 중에 필자의 추천은 파이썬과 Django다. 그 이유는 단점이 적기 때문이다. Rails는 최고의 생산성을 낼 수 있다는 뚜렷한 장점이 있고 진입장벽은 높지 않지만, 높은 수준에 도달하기까지는 학학습 분량이 적지 않고 - 물론 자바와 스프링에 비할 바는 아니지만 - , 아직도 성능 이슈가 약간 있다. Node.js는 single page application이나 채팅에서 강점을 보이지만 그 외에는 Django나 Rails보다 많이 약하다. 이에 비하면 파이썬과 Django는 엄청난 장점이 있는 것은 아니지만 단점이 별로 없어서 두루 쓸 수 있고, 비교적 짧은 시간에 학습 장벽을 넘을 수 있다.

데이터베이스

데이터베이스는 우선 RDBMS를 쓸 것이냐 NoSQL을 쓸 것이냐부터 선택해야 한다. 물론 RDBMS가 여러 모로 유리하다. 많은 스타트업들이 자신들의 서비스가 대박이 나면 그냥 RDBMS로 버티지 못하는 건 아닐까 걱정을 하고, 처음부터 대용량을 커버할 수 있는 설계를 하고 싶어한다. 하지만 RDBMS의 한계는 생각보다 아주 멀리 있다. 우선, 리플리케이션이나 여타 RDBMS를 스케일업할 수 있는 수단을 쓰지 않고 순수하게 RDBMS 서버 한 대에 쿼리 튜닝만 잘 해놓아도 국내에서 방문자 10위권 사이트 정도는 커버가 된다. 간혹 하루 방문자 10만명 내외의 사이트인데 DB가 부하를 못 견딘다고 NoSQL로 가야하는 거 아니냐고 묻는 팀도 있는데, 이건 전적으로 쿼리 튜닝의 문제다. 쿼리 튜닝도 고난이도의 튜닝이 필요한 게 아니라, 잘 정규화가 되어 있고 기본적인 인덱스만 잘 걸려 있으면 된다. 그러면 Django나 Rails에서 사용하는 ORM을 그대로 쓰면서 성능 문제를 해결해갈 수 있는 것이다.

만약 정말로 비즈니스가 대박이 나서 저 정도로는 감당할 수 없는 상황이 되어간다고 해도 방법이 있다. 캐시를 추가하면 캐시 전략에 따라 다르지만 수 배에서 수십 배의 부하를 감당할 수 있다. 이것만으로도 많은 상황이 해결될 것이다. 그리고 read-only 리플리케이션을 붙이면 수 배 확장 가능하고, 샤딩을 하면 데이터 사이즈에서의 대용량도 커버 가능하다. 이 정도 수준까지 하면 사실상 국내 최고 수준의 트래픽도 감당할 수 있다. 그리고 여기까지 하는 것도 이미 사례들이 많아서 그리 어려운 일이 아니다.

이걸로도 해결이 안되는 스케일이 되더라도 여전히 솔루션은 존재한다. 미들웨어를 투입할 수도 있고, 테이블 설계를 단순하게 할 수도 있고, 부분적으로 NoSQL을 사용할 수도 있다. 어쨋든 용량이 커진다고 해서 RDBMS로 만든 것을 갈아엎고 NoSQL을 도입해야 하는 것은 아니고 RDBMS를 주력으로 쓰면서 계속 성능을 개선해갈 수 있다.

그렇지만 사실 RDBMS의 한계보다 스타트업에게 더 중요한 것은 그 한계를 만날 수 있게 되느냐일 것이다. 그 한계를 만나려면 어쨋든 제품이 성공해야 하는 것이고, 제품을 성공시키려면 개발 생산성을 우선할 수 밖에 없다. 그렇게 해서 비즈니스가 성공하고 나서 회사의 자원이 넉넉해지면 나중에 성능을 개선할 방법은 얼마든지 있다. 그래서 초기 단계의 스타트업이 성능을 이유로 NoSQL을 선택할 필요는 없다.

RDBMS 중에 선택지는 사실상 둘 뿐이다.

• MySQL
• PostgreSQL

둘다 나쁘지 않은 선택이다. MySQL이 관리하기는 좀더 쉽다. phpmyadmin 같은 훌륭한 관리 도구도 있고, 세계적으로 가장 널리 쓰이는 DBMS이기 때문에 문서나 각종 레퍼런스도 많다. MySQL에 문제점도 아주 많이 있지만, 그 문제점에 대한 대안조차도 검색하면 다 나올 정도다. 다만 SQL 표준을 지키지 않는 부분이 좀 있고, 개발자의 합리적인 예상을 벗어나는 동작들이 가끔 있기 때문에 간혹 어이 없는 상황을 겪기는 할 것이다. 그리고 MySQL이 오라클에 넘어갔기 때문에 오픈소스 계열은 MySQL을 fork해서 MariaDB를 쓰고 있어서 이 혼란도 부담이 될 수 있다.

PostgreSQL은 좀더 순수한 오픈소스로 자리를 지켜왔고, 표준 SQL을 잘 준수하고 있으며, RDBMS로 갖춰야 할 기능들을 잘 갖추고 있다. GIS 지원이라든지, JSON type, Array type 등 여러 가지 기능 면에서도 PostgreSQL이 앞선다. 다만 사례가 부족해서 MySQL보다 좀더 정보를 찾는데 어려움을 겪을 수는 있다.

성능 면에서는 단순한 쿼리일수록 MySQL이 더 낫고, 복잡해질수록 PostgreSQL이 낫다고 하나, 최신 버전에 대해 객관적으로 비교할 수 있는 벤치마크는 드물다. 필자의 경험에서는 MySQL이 이 잘 돌아갔던 사이트보다 10배 정도 작은 규모의 사이트에서 PostgreSQL로 성능 때문에 고생했던 적이 있다.

프론트엔드

서버 호스팅

클라우드

이미지

OS

배치(deployment) 

작업 큐

모니터링

데이터 분석

기초적인 성능 관리