스타트업에서는 어떤 기술을 이용해야 할까?

필자는 지난 5년 동안 스타트업 업계에서 활동하면서 많은 테크니컬 결정들을 내려왔고 또한 그런 결정들의 갈림길에서 고민하는 기업인들을 많이 만나왔다. 스타트업이 유지되고 또 발전해 나가는데 있어서 가장 중요한 요소는 명확한 회사의 비전과 그 회사를 형성하고 있는 문화일 것이다.

실리콘밸리의 많은 스타트업들은 자신들만의 독특한 문화를 가지고 회사를 만들어 가는 것을 많이 보게 된다. 그렇다면 그 문화를 만들어 가는데 있어서 가장 중요한 역할을 하는 것은 무엇일까? 다른 요소들보다도 그 회사가 선택한 기술 스택이 아무래도 개발 문화에 큰 영향을 주게 된다는 것은 부정하기 어렵다.

tech-startup-office-apprenaissance.665.281.s

새로운 스타트업이 J2EE/Oracle, Perl, PHP, Rails, Node.js, .NET 중에 회사의 주 기술을 선택하게 되면 그 팀의 엔지니어들은 각 플랫폼 별로 다른 기대를 가지게 되고 또 다른 가치와 개념을 무의식 중에 품게 된다. 즉, 이러한 기술들 중에서 어떤 기술이 나쁘다고 우리는 이야기 할 수 없지만 그들은 다른 문화를 가지게 되는 것은 사실이다.

몇 년 전에 필자는 런던에서 열린 스타트업 기술 컨퍼런스를 참석하게 되었는데 굉장히 많은 기업들이 Node.js 기술을 이용하고 있는 것을 알게 되었다. 필자는 그들에게 왜 노드를 선택하게 되었는지 물었다. 하지만 대부분의 기업가들은 똑똑한 엔지니어들은 Node.js를 좋아하기 때문에 보다 쉽게 구인 활동을 하기 위해서 선택했다고 이야기 했다. 이 이야기는 영국의 엔지니어들은 자신의 경험을 늘리는데 있어서 회사를 많이 의존하고 있다는 이야기로 들렸다. 물론, 트랜디한 기술을 가지고 좋은 엔지니어를 섭렵할 수 있는 장점이 있다고 한들 정확한 목표를 이루기 위해서 얼만큼 적합한 기술을 선택하고 있느냐 역시 충분히 검토해봐야 할 문제이다.

각 기술별 다양성

그렇다면 지금 우리 회사의 목표와 문화를 잘 반영할 수 있는 기술은 무엇일까? 이 질문에 대한 답을 얻어가기 위해서는 현재 회사의 목표를 보다 정확하게 이해해야 한다. 그리고 그 회사의 목표가 확실하다면 보다 성공적으로 프로젝트를 수행할 수 있는 확률이 높을 것이다. 이런 이해 없이 많은 기업들이 그저 기술 스택들을 그저 카피하려고만 한다면 어떤 목표와 기대 없이 프로젝트가 진행될 수 있을 것이다.

실리콘밸리의 기술 트렌드가 오픈스택이라고 해서 스타트업을 넘어 모든 기업들이 그 트랜드를 쫓아서는 안 된다. 어떤 기술이 맞고 틀리다가 없는 것이 페이스북을 한번 살펴보면 PHP를 주 언어로 이용한다는 것인데 그렇다고 우리도 PHP를 이용해야 한다라는 논리를 주장해서는 안 되기 때문이다. 먼저 문화와 목표에 맞는 기술 스택을 정하기 이전에 필자가 가지고 있는 기술에 대한 몇 가지 뷰 들을 정리해보도록 하겠다.

PHP

  • 일단 만든 결과를 빨리 보여주자고 할 때 높은 효율을 발휘한다.
  • 어떤 것이든 할 수 있는 길이 있는 만큼 한계는 없다.
  • 깊은 학문적인 이해가 없이도 충분히 접근가능하고 누구든지 쉽게 개발할 수 있다.
  • 객체지향은 나중에 고려해 볼 대상이다.

facebook-optimise-php

PHP는 전세계를 거쳐 꽤 많은 업적을 쌓아 왔다. 무엇보다도 PHP를 이용하면 쉽게 웹을 개발할 수 있었다. 하지만 아마도 굉장히 많은 PHP개발자 인력풀과 커뮤니티를 가지고 있지만 소수의 좋은 개발자만이 좋은 PHP코드를 작성할 수 있다. 그래서 그만큼 많은 예제코드들이 존재하지만 좋은 코드 예제들을 찾기 어렵다. 이런 이유들 때문에 굉장히 안 좋은 예제들과 코드들이 커뮤니티에 돌아다니고 있는데 주로 잘 테스트가 안되었고 보안에 큰 문제가 있는 코드들이 많이 있다. 더불어 가끔 PHP 자체가 자연스러운 문법을 가지고 있는지 의문이 들 때가 있다.

PHP에 경험이 많은 팀들은 물론 좋은 코드 표준과 프로세스들을 가지고 있을 것이고 수준 높은 웹 페이지를 빠른 시간 내에 만들어 낼 수 있지만 역시나 개발 수준이 어느 정도 되는 소수의 팀만 그렇게 할 수 있다는 부분이 있다.

자바

  • 포터블(Portability)이다.
  • 객체지향적이다.
  • 어떤 IDE 툴을 이용할지 선택이 필요하다.
  • 쓰레드를 쉽게 이용 가능하다.
  • 오픈소스지만 오라클에 팔린 뒤에 발전주기가 다소 느리다.
  • 살짝 느리지만 더 안전한 개발 주기를 가지고 있다.

oracle_java-100026145-large

자바는 굉장히 좋은 옵션의 선택이 될 수 있는 언어임은 분명하다. 수년 전부터 굉장히 많은 개발자들이 자바를 하기 위해서 노력해왔다. 대부분의 자바 개발자들은 자바와 더불어 PHP, 파이썬, 루비와 같은 인터프리트 언어들을 쉽게 바꾸어 이용하는 것이 가능하고 또 개발자들이 그렇게 이용해 왔다. 오라클이 자바를 잠식한 뒤로 줄곧 자바FX와 스윙과 같은 엉뚱한 곳에만 신경을 쓰느냐 자바의 발전이 더디게 되었다. 하지만 안드로이드를 기반으로 한 구글은 자바가 자바가 자바 자체로는 절대 나쁘지 않다는 것을 보여주게 되었다. 즉, 이말은 J2EE나 Swing에 종속적이지 않은 자바 언어만으로 봤을 때 충분히 훌륭하다는 말이다.

자바를 더욱 빛내 줄 수 있는 것은 JVM(자바 버추얼 머신)의 존재와 굉장히 높은 효율을 가지는 라이브러리들의 양이 아닌가 싶다. 자바 개발자를 고용하는 것은 국내를 넘어 세계적으로도 그렇게 어렵지 않다. 일단, 많은 학생들이 학교에서 자바를 가르킨다. 하지만 실제 실리콘밸리뿐만 아니라 국내의 스타트업에서는 뛰어난 자바 개발자를 찾기 어려운 부분이 있다. 그래도 많은 스타트업들이 자바를 선택하는 이유가 있지만 그 중에서도 루비, 파이썬과 같은 최신 트랜드의 인터프리트 언어들과 환경을 같이 병행하는데 용이하다는 점에서 큰 의미가 있지 않을까 생각한다. 다시 정리하자면 자바를 이용하는 개발자들이라면 오랜 개발 경력을 가지고 잘 알려진 패턴들을 잘 이용할 수 있는 개발자들이 비교적 많이 있다는 장점이 있다. 그리고 다른 플랫폼보다 안정적인 개발 플랫폼을 제공하기 때문에 그 선택이 나쁘지 않다.

닷넷(C#/.NET)

  • 대체적으로 자바보다 더 나은 엔터프라이즈 환경을 제공한다.
  • 윈도우 데스크탑 애플리케이션의 개발을 위한 0순위 옵션이다.
  • 자바보다 좋은 IDE를 제공한다.
  • 느리지만 안전한 개발환경을 가지고 있다.
  • 오픈소스화에 대한 비전이 다소 불명확하다.

net-logo-d203ac9ee3cdd26d3f31b0b98a7dea71

필자의 백그라운드가 닷넷 기반의 경험이 많은 부분이 있어서 다소 객관적이지 못한 부분이 있을 수 있겠지만 그래도 자바에서 닷넷으로 전환한 외국의 닷넷 개발자들의 의견들을 종합해서 결론을 내려 보도록 하겠다. 먼저 C#5.0이 발표되었을 때 닷넷 개발자뿐만 아니라 다른 진영의 개발자들이 모두 감탄할 만큼 플랫폼과 그 언어의 발전 속도가 눈부셨다. 실제 C#의 설계와 시작은 자바와 비슷했지만 지금은 언어로서의 발전은 자바보다 훨씬 앞서 나가기 시작했다. 예를 들어 자바8에서 발표하지 못하고 자바9으로 미루어진 기능들이 있는데 이미 C#은 그 기능을 모두 지원하고 있다.

실제로 자바스크립트를 개발하는데 있어서 비주얼 스튜디오는 대단한 인텔리센스와 편의성을 제공한다는 것이 많은 개발자들의 의견이다. 그리고 더불어 닷넷의 가장 큰 장점은 바로 MSDN을 통한 문서화가 굉장히 잘 되어있다는 것이다. 단점을 이야기 해보자면 C# 자체가 완벽한 오픈소스가 아니라는 점과 비주얼 스튜디오와 MSDN 자체가 굉장히 비싸다. 비즈스파크를 활용한 스타트업 전략을 지원받을 수 있는 것이 아니라면 기업에서 이 라이선스 비용을 지불하기가 쉽지 않다. 그러다 보니 플랫폼의 생태계가 마이크로소프트 중심적으로 돌아가게 되는데 요즘 IT의 변화가 개방과 오픈스택을 중심으로 이루어져 나간다는 부분에서 그 문화가 다소 올드해 보인다는 느낌을 받을 수 있다.

하지만 닷넷은 엔터프라이즈 쪽의 백엔드 문화에 적합한 부분이 있는데 이 부분에 있어서는 자바보다 색깔이 진하고 더 안정적이라고 할 수 있다. 국내에서는 닷넷 개발자의 수급이 어려워서 자바를 선택하는 경우도 많지만 외국에서는 그래도 닷넷의 점유율이 자바에 결코 밀리지 않는다. 그래도 희망적인 것은 서서히 마이크로소프트도 오픈소스에 참여하고 있다는 점이고 클라우드 플랫폼 애저를 통해서 플랫폼의 통합에 대한 움직임을 보이고 있다는 것이다.

파이썬(Python)

  • 한가지 분명한 목표를 채워 나가기에 적합하다.
  • 코드가 깔끔하고 단순하다.
  • 프로젝트의 문서화가 수월하다.

python

필자의 직접적인 경험보다는 프로젝트를 관리하면서 파이썬 개발자와 함께 일하면서 보고 간접 체험한 것들을 위주의 의견을 전달해 보겠다. 무엇보다도 파이썬을 선택하는 기업이나 개발자들을 보면 다른 것보다는 프로젝트의 문서화에서 높은 효율을 가져온다는 점에 큰 장점으로 볼 수 있었다. 그리고 실제로 어떤 문제를 해결하는데 있어서 만큼은 최고의 라이브러리들을 가지고 있다고 볼 수 있다.

하지만 개인적으로 닷넷과 자바와 같은 엔터프라이즈 시스템에 비해서 동적 언어에 대한 단점도 분명 존재하기 마련이다. 무엇보다도 파이썬은 인터넷 환경이 대중화되기 전에 설계된 인터프리트 언어이다 보니 멀티 쓰레드를 사용하여 동시성을 처리하는 부분에서는 어느 정도 문제가 있다. 그래도 파이썬이 매력이 있는 부분은 환경자체가 모던적이고 DB부터 서버사이드 그리고 프론트엔드의 HTML과 자바스크립까지 모든 단계를 개발해야 하는 풀스택(Full-Stack) 개발자라면 어떤 언어보다 훨씬 쉽게 개발할 수 있다는 점이다.

루비 온 레일스

  • 기계중심적이 아닌 사람 중심적으로 설계되었다.
  • 문법자체가 굉장히 느슨하고 유연하다.
  • 테스트를 잘 지원한다.
  • 굉장히 쉽게 배우고 개발할 수 있다.
  • 열정적이고 다양한 커뮤니티가 존재한다.

Ruby_on_Rails.svg

루비 온 레일즈(Ruby on Rails)는 루비로 작성된 MVC 패턴을 이용하는 오픈 소스 웹 프레임워크이다. 특히 데이터베이스를 이용한 웹 애플리케이션을 개발할 때 반복되는 코드를 대폭 줄여주고 그만큼 개발 기간을 단축하는 것이 가능하다. 이런 빠른 생산성을 가져다 주는데 있어서 루비의 유연성 부분이 한 몫 한 부분이 존재하지만 역시나 코드 관리에 있어서 약간의 단점도 가지고 있다.

캐시를 지원하고 있기는 하지만 파이썬과 마찬가지로 동시성에 있어서는 어느 정도 제한이 존재한다. 루비온 레일스는 프레임워크 기능보다 루비라는 언어에 익숙해지는데 더 어려움을 가지는 것이 사실이다. 하지만 애자일 환경에 맞추어 보다 쉬운 테스트 환경을 구축하는 것이 가능하다. 레일스 프레임워크 자체가 최신 기술들을 스스로 갖추고 있기 때문에 가능할 수 있는 것인데 얼리 어덥터라면 분명 이 레일스 플랫폼이 더할 나위 없이 큰 장점이 될 것이다. 다시 정리하자면 루비온 레일스는 어떤 제품의 연구를 위해서가 아닌 고객 중심적으로 상품을 보다 빨리 개발하는데 목적이 있다면 굉장히 적합한 환경으로 정리해보고 싶다.

Node.js (Javascript)

  • 실시간 데이터 전달에 적합하다.
  • 이벤트 중심적으로 커플링을 줄일 수 있다.
  • 루비/파이썬의 경험을 참고하여 작성된 프레임워크이다.
  • DIY가 가능한 환경이다.

nodejs

Node.js에서 Node는 웹서버를 말한다. 하지만 파이썬도 토네이도 루비는 이벤트 머신을 가지고 있었던 것처럼 그렇게 새로운 개념이 아닌 단순한 이벤트 기반의 프레임워크이다. 아무래도 Node.js의 다른 경쟁력은 아무래도 자바스크립트라는 언어가 아니었을까 생각해본다. 모든 개발자가 자바스크립트를 이용할 수 있기 때문에 백엔드와 프론트엔드 전부 자바스크립트를 이용할 수 있다는 점에서 큰 호소력을 가질 수 있는 것이다. 하지만 단지 언어 때문에 Node.js가 주목을 받게 되는 것은 아니다. 무엇보다도 굉장히 빠른 응답속도와 전달 대역폭을 지원하고 있고 쉽게 개발을 시작할 수 있다는 점에서 큰 장점이 있다고 볼 수 있다. Node.js의 장점은 앞에서 설명한 루비 온 레일스의 장점을 대부분 가지고 있다.

Node자체가 이벤트 기반의 프로그래밍이다 보니깐 디버깅과 테스트가 상대적으로 어려운 부분이 있다. 그리고 콜백 기능을 다루는데 있어서의 유지보수는 정말 어려운 부분이 있다. 아무래도 이 부분은 향후 Node에서 다른 지원이 있지 않을까 생각해본다. 정리하자면 노드는 어떤 관습을 따르는 것보다는 자신의 구조와 패턴을 만들어서 일하는 것을 좋아하는 얼리 어덥터들에게 훨씬 큰 장점이 있을 것이라고 생각해본다. 그리고 기본적인 MVC 모델로 지원하는 것보다 더 로우 단계의 레벨에서 컨트롤이 가능하기 때문에 더 깊이 있는 제어가 가능하고 프로그래밍 언어에 거부감이 없다는 점에서 높은 점수를 주고 싶다.

스타트업의 기술 선택 가이드

각 기술들을 이용하는데 있어서 어떤 것이 반드시 맞고 틀리다라는 답이 존재하지 않는다. 기술을 선택할 때 있어서 회사의 방향과 목표와 만들어 가고자 하는 문화와 얼마나 적합 하는지를 따져봐야 할 것이다. 예를 들어 한 스타트업이 아직 뚜렷한 제품의 방향이 없고 빠르게 MVP(제품의 최소기능)버전을 만들어서 계속해서 시험을 해 나가야 하는 상황이라면 빠르게 개발할 수 있는 인터프리트 언어 환경이 더 적합할 수 있다.

대체로 루비, 파이썬 그리고 Node.js가 이런 스타트업 환경에 더 좋은 생산성을 보이고 있다. 그리고 스타트업의 태생자체가 Front-end와 Back-end 모두 한 개발자를 의존하게 되는 경우가 많다는 점에서도 좋은 선택이 된다. 개발자 채용에 있어서도 리눅스 환경에서 php와 같은 웹 개발을 해본 개발자라면 손쉽게 적응할 수 있기 때문에 조금 더 유리한 것이 사실이다. 하지만 위의 스타트업에서 만들고자 하는 제품이 높은 난이도의 기술을 요구하고 있다면 반드시 서버와 기술의 흐름을 충분히 이해하고 있는 리드 개발자가 필요할 것이다. 무언가 빠르게 개발할 수 있는 것과 동시에 그 기술의 한계를 이해하고 상황에 맞는 솔루션을 제공해주어야 하는 역할이 반드시 필요하기 때문이다.

대부분 스타트업이 확장과 동시에 많은 어려움을 겪는 것이 “일단 만들고 보자”로 개발한 제품을 확장해야 되는 경우이다. 틀린 이야기는 아닌 것이 이 제품이 살아 남을지 모르는 시험 단계이기 때문에 튼튼한 품질 높은 소스 코드를 만들어내기 보다는 제품을 빨리 만드는 것이 더 중요하기 때문이다. 어찌 되었든 이런 기술적인 문제가 스타트업에 발목을 잡지 않으려면 큰 그림을 제시할 수 있는 아키텍트가 반드시 나중에라도 꼭 합류되어야 잠재적인 난항을 피할 수 있다.

logo_languages

다른 사례로 만약 스타트업에서 만들고자 하는 제품이 기술 난이도가 높다면 필자는 자바나 아니면 닷넷과 같은 엔터프라이즈 환경을 추천하고 싶다. 주로 이런 엔터프라이즈 환경은 어떤 제품을 빠르게 개발하는 것보다는 안전성과 제품의 설계를 중시할 때 적합하다고 할 수 있다. 즉, 스타트업이 정확한 목표가 있고 그 제품이 시험단계를 넘어서 자사의 퀄리티가 높은 질 좋은 제품으로 발전해 가야 한다면 당연히 많은 객체지향과 여러 패턴들을 녹일 수 있는 자바나 닷넷이 적합하다는 이야기이다.

자바와 닷넷 고유한 장단점을 가지고 있는데 먼저 자바는 다른 인터프린트 언어로 닷넷보다는 쉽게 병행할 수 있다는 것이다. 때문에 단단한 자사의 메인 기술을 기반을 다짐과 동시에 다양한 제품 실험을 하는 경우라면 당연히 자바가 더 좋은 선택이 될 수 있다. 반면에 닷넷은 자바보다 더 좋은 개발도구를 지원하고 언어적으로도 더 빠른 업데이트들을 지원하고 있다. 국내에서는 닷넷의 도입이 윈도우 애플리케이션을 개발하기 위한 조합으로 많이 사용되고 있는데 좋은 시너지 효과를 볼 수 있다. 그 외에도 더 안정적인 시스템을 구축함과 동시에 여러 편리한 툴들을 보너스로 사용하고 싶다면 닷넷 또한 나쁘지 않은 선택이 될 것이다.

물론, 기본적인 닷넷과 자바 기술을 가진 개발자만 가지고 다른 플랫폼 환경처럼 결과를 만드는 것이 가능하지만 엔터프라이즈 환경의 빛을 보려면 기술적인 이해와 더불어 다양한 개발방법론과 패턴들을 이해하고 도입할 수 있는 뛰어난 개발자를 찾아야 할 것이다. 하지만 그런 개발자들을 찾는 것이 생각만큼 녹록하지 않다. 닷넷의 경우라면 국내에서는 더더욱 어려울 수 있다.

글을 마치며

이렇게 해서 스타트업의 기술 선택에 대한 주관적인 생각들을 정리해 보았다. 스타트업에서 대부분의 기술정책과 방향은 CTO나 리드 개발자들로부터 내려지게 되지만 그 기술방향을 수립하기 이전에 앞서 회사의 방향과 문화를 조금 더 고려해 볼 필요가 있다. 한번 선택한 기술을 다시 돌리기 위해서는 많은 길을 돌아가야 한다는 점을 잊지 말아야 한다. 때문에 맹목적인 이유를 통한 선택이 아닌 회사의 방향과 문화 그리고 지금의 상황에 맞는 합리적인 결정을 진행할 수 있다면 좋은 건강한 기술문화를 기반으로 좋은 목표를 창출할 수 있는 회사를 이끌어 갈 수 있을 것이다.

%d bloggers like this: