주: 이 글의 내용에는 저도 지금은 동의를 안합니다.

본문 최근에 웹 개발 스택에 대한 질문을 받았다. 프론트엔드는 절대자에 가까운 React를 추천해드렸고, 서버 언어로 고, 스칼라, 자바스크립트를 추천해드렸다. 하지만 대부분의 다른 사람들이 여전히 레일즈나 장고를 추천하는 것을 보고 약간은 놀랐다. 결론부터 말하자면, 이 글은 ‘어떤 서버 언어를 골라야 하는가’ 라기 보다는 ’왜 루비와 파이선이 아닌 다른 언어를 사용해야 하는가’에 더 가깝다. 하지만 그 과정에서 어떤 언어의 특징들이 최근 트렌드의 서버 개발에서 중요한지를 언급할 것이다. 솔직하게 고백하자면, 나는 함수 언어들과 고, 그리고 특히 자바스크립트의 팬이다. 이 글은 약간 편향될 수 있고, 주관적으로 보일 수 있다. 따라서 가능한 사실과 저명한 사이트를 이용해서 의견을 뒷받침 하도록 노력해보겠다.

우선 루비와 파이선을 한없이 깎아내리고 싶지만, 그렇게는 하지 못한다. 칭찬을 하고 시작하자. 둘은 분명히 좋은 언어다. 나는 루비에는 아주 익숙하지 못하지만, 파이선을 이용해서는 작은 플러그인을 만들어서 배포해본 적도 있고, 아직도 파이선을 사용한 툴 개발을 즐긴다. 또한 장고나 레일즈는 굉장한 프로젝트들이다. 몇년 전에 나타나 웹 서버 개발을 송두리째 바꾸어 놓았다고 말해도 과언이 아니다. 실제로 두 언어와 그 대표 MVC 프레임워크들은 생산성이 높다. 만약 시간에 굉장히 쫓기는 작업을 하거나, 지금 아이디어가 너무나도 좋아서 한시라도 빨리 일단 동작하도록 만들어야 한다면 충분히 좋은 옵션이 될 수 있고 실제로 많은 스타트업들에서 사용했다. 하지만 그런 경우를 제외하고서는 루비와 파이썬을 써야하는 이유를 잘 모르겠다. 혹시 몰라서 다시 말하지만 언어 자체에는 아무런 문제가 없다. 다만 그 두 언어가 요즘 서버개발 추세에 맞지 않을 뿐이다.

그렇다면 요즘 웹서버 개발 추세는 어떠한가? MVC 프레임워크 가지고 컨트롤러에서 데이터 가져와서 템플릿 엔진으로 뷰를 일일히 그리는 일이 점점 사라지고있다. 풀스택 개발이 줄어들고, 프론트엔드와 백엔드를 나누는 경우가 많아졌다. 그 과정에서 백엔드는 API 중심으로 개발이 이루어진다. 웹 프레임워크들은 오히려 프론트엔드단을 더 중요하게 생각하는 추세이다. GitHub의 Trending Repositories를 보면 프론트엔드 웹 프레임워크가 거의 점령하고있는 것 처럼 보인다. 또한 MVC의 의미 자체도 점점 흐려지고있다. 프론트엔드 개발을 거의 평정하고있는 React의 경우 스스로를 ’MVC의 V와 같은 것’으로 여기고 있지만 페이스북 자체에서도 Flux 아키텍쳐와 자바스크립트 네이티브 데이터 모델만으로 M을 대체할 수 있다고 말하고, 사실상 C는 로직이기 때문에 React 컴포넌트 자체가 그 역할을 대신하는 경우가 많다. 여전히 엄밀하게 나누면 디자인 패턴 상 MVC를 정의할 수 있겠지만, 이전처럼 풀스택 MVC프레임워크를 사용하는 추세는 아니다. API 중심 개발과정에서는 레일즈와 장고의 V의 장점이 흐려지는 것이다. 오히려 노드를 사용하는 것이 프론트엔드와의 긴밀한 관계를 맺는데는 더 좋을 것이다.

그 외에 레일즈와 장고의 장점으로는 모델과 컨트롤러가 유기적으로 동작한다는 것인데, 레일즈나 장고가 처음 등장했을 때는 ORM을 이용한 DB의 추상화가 굉장히 편리한 기능으로 생각되었지만, 요즘 ORM 라이브러리가 없는 언어는 거의 없다. 대부분의 언어가 ORM을 가지고 있고, 오히려 자바스크립트나 고와 같은 마이크로 커뮤니티 중심의 생태계를 가진 언어들의 경우에는 필요에 맞는 라이브러리를 취사선택할 수 있다. 웹서버 벤치마크 결과를 보면 알지만 다중 DB쿼리를 테스트한 경우 Go의 ORM을 사용한 경우보다 장고나 레일즈가 5배나 느리다. 심지어 NoSQL을 사용한 Node보다도 1.5배나 느리다. 싱글 DB쿼리의 경우에 차이는 더더욱 크다. 웹 서버의 대부분의 작업이 DB와 통신해서 결과를 반환하는 것이고, 그 과정에서 발생하는 비용이 전체 비용의 대부분을 차지하는 것을 생각하면 이 성능차이는 큰 문제이다.

하지만 이 시점에도 루비나 파이선(혹은 그 프레임워크들)이 생산성이 높은 스택으로 여겨지는 이유는 언어의 친숙함이다. 파이선이나 루비가 많은 개발자들이 쉽게 익숙해질 수 있는 언어이고 배우기 쉬운 언어인 것은 분명하다. 이것은 분명한 장점이다. 다시 말하지만 만약 시간적이나 인적자원의 한계를 고려해야 한다면 루비나 파이선이 괜찮은 선택지가 될 수 있다. 하지만 새로운 언어를 배울 시간이 충분하다면 파이선이나 루비를 서버언어로 선택할 필요는 없다. 숙달되었을 때 파이선이나 루비만한 생산성을 보이는 언어는 충분히 많다. 실제로 LISP계열의 함수형 언어에 친숙한 사람들이 Clojure등을 이용해서 내는 생산성도 만만치 않다. 심지어 Clojure는 프론트엔드에서도 활발히 쓰이고 커뮤니티도 굉장히 성숙해있다. 언어의 친숙함 만으로 루비나 파이선을 고평가 해주기에는 무리가 있다.

조금 다른 관점에서 보자. 언어의 발전 속도에 대해서 조금 생각해볼까 한다. 같은 스크립트언어인 자바스크립트의 경우에, 이상하리만치 싫어하는 사람들이 많다. 하지만 그들이 자바스크립트를 싫어하는 이유는 대부분 언어 자체에 대한 무지에서 비롯한다. 가장 많이 듣는 말은 콜백헬과 스파게티 코드이다. 문제가 없다고 말하지는 않겠다. 하지만 그 문제는 없어질 것이다. 자바스크립트 엔진은 기본적으로 비동기 실행을 기본으로 한다. 비동기 실행은 콜백을 이용해서 행해지는데, 여러 작업을 연속해서 해야되는 경우 콜백이 한도 끝도 없이 추가되는 문제가 있었다. 가독성도 크게 떨어졌다. 하지만 이 문제는 ES6에서 Promises나 Future가 추가되면 사라질 일이다. 그 외에도 자바스크립트 커뮤니티에서는 프론트엔드 뿐만 아니라 서버에서도 굉장히 빠른 연구 및 발전이 이루어지고 있는 언어다. 환경, 라이브러리를 개선하는 것 뿐만 아니라 언어 자체도 다른 어떤 언어보다 빠르게 발전이 이루어지고 있다. 이미 콜백헬, 자체적인 모듈 시스템의 부재 등 현존하는 대부분의 문제가 다음 에크마스크립트 표준인 ES6에서 해결될 예정이며, ES6는 서버사이드에서 이미 사용이 가능하다. 그 외에 Immutability 등을 포함한 ES7의 표준에 대해서 계속해서 논의가 이루어지고 있는 상태다. Type safety에 대한 문제를 극복하기 위해서 나온 툴에는 마이크로소프트의 타입스크립트도 있고, 페이스북의 Flow도 있다. 같은 스크립트 언어지만 파이선이나 루비에서 자바스크립트 정도의 발전속도를 보이고 있다고 보기는 어렵다.

또한 서버 언어라면 컨커런시에 대한 부분을 짚고 넘어가지 않을 수 없다. 테크니컬 구루들이 추천하는 2015년에 배워야할 언어는 JavaScript, Erlang, Clojure, Scala, F# 등이다. 보면 알겠지만 5개 모두 함수형 언어이다. 인텔에서 무어의 법칙이 가까운 시일 내에 깨질 것이라고 언급하는 가운데, 가장 핫한 이슈는 Scalability와 그와 관련된 Cuncurrency이다. Scalability는 단순히 앱서버 더하고 로드밸런서 붙인다고 이루어지는게 아니다. 가장 중요한 것은 프로세스간 Shared mutable state를 최소화하는 것이다. 그렇기 때문에 mutable state를 기본적으로 가지지 않는 순수 함수형 컨셉의 언어들이 강세를 보이는 것이다. 실리콘 밸리에서 가장 높은 평균 연봉의 언어가 Scala, Clojure등과 같은 함수형 언어인 것은 결코 우연이 아니다. 함수형 언어가 아닐지라도, 새로 개발되고 있는 핫한 언어들은 컨커런시나 mutable state에 대한 고려를 많이 하고있다. Go와 Rust같은 새로운 언어들은 기본적으로 효율적 컨커런시 처리를 위한 방법을 제공하고 있고, Rust와 Swift는 Immutable한 데이터 모델을 지원한다. 많은 함수 언어들이 메세지 패싱이나 워커등을 이용해서 컨커런시를 지원하고, 이를 이용해서 효율적으로 스케일아웃을 해나가고 있다. 파이선이나 루비가 언어적으로 이런 부분에 대해 큰 신경을 썼다고 말하기는 어렵다. 기본적으로 단일 스레드상에서 동작하는 자바스크립트도 이런 부분에서 비난을 피하기는 어렵지만, 최소한 Node플랫폼 자체에서 Node-cluster라는 방법을 제시하고 있기는 하다.

마지막으로 몇가지 예상 가능한 반박을 일축하고싶다. 우선 여전히 루비나 파이선이 많이 사용되기 때문에 괜찮다는 의견에 대해서는, 사용 빈도와 기술 스택의 효율성과는 별 관련이 없다는 이야기를 하고싶다. 그렇게 따지자면 문제덩어리인 PHP는 루비나 파이선보다 100배 이상 많이 쓰이고 있지만, 그것이 더 좋음을 의미하지는 않는다. 또한 파이선이나 루비가 사용자가 많고 자료찾기가 더 쉽다는 의견에 대해서는, pip이나 easy_install 등으로 패키지매니저조차 중구 난방인 파이선보다는 GitHub 커뮤니티 중심의 패키지매니저를 기본으로 탑재하고있는 고나 노드커뮤니티가 원하는 일을 하기에 더 적합할 것이다.

굉장히 읽기가 힘들고 정리가 되지 않은 글이 된 느낌이다. 사실 입이 너무 근질근질했지만 차마 남들 앞에서는 말하지 못하고 혼자서 토해낸 느낌의 글이 돼버렸다. 요는, 현재 트렌드에 크게 벗어나있는 루비나 파이선을 서버 언어로 선택하기 보다는, 트렌드에 맞고 효율성이 높은 언어를 선택하는 것이 좋다는 것이다. 몇년 전에는 레일즈나 장고가 트렌드였지만, 요즘에는 레일즈나 장고에서 다른 스택으로 갈아 타는 것이 트렌드이다. 실제로 트위터를 포함한 많은 회사들이 ’Rails doesn’t scale’을 외치며 갈아타고 있는 것이 현실이다. 트렌드가 물론 전부는 아니지만, 개발자라면 개발을 잘 하는 것과 동시에 전체적인 커뮤니티에서 어떤 일들이 일어나고 있는지 아는 것도 굉장히 중요하다. 어떤 흐름이 아무 이유 없이 일어나고 있지는 않기 때문이다. 그리고 무엇보다도, 기존에 익숙한 파이선이나 루비를 계속해서 쓰는 것 보다는 새로운 기술들을 계속해서 써보는 것이 프로그래머의 입장에서 더 재미있고 신나는 일이 아니겠는가?

자, 그렇다면 이 주제넘은 글을 뒷받침할만한 레퍼런스들을 나열하고 글을 마무리하겠다. 이 글 자체보다 레퍼런스가 더 훌륭한 자료들을 갖고 있으니, 레퍼런스들도 꼭 읽어보기를 권하겠다.

read other posts