2. 웹서버
전통적인 의미의 웹서버는 클라이언트로부터 HTTP 요청을 받아서 처리를 하고, 그에 따른 응답을 해주는 서버였다. 우리가 이른바 '홈페이지'라고 불렀던 시절을 상상하면 된다. 복잡한 기능은 없고, 사용자의 행동에 따라 정해진 결과를 돌려주는 역할을 한다. 그러나 이런 홈페이지가 '웹서비스'로 진화하면서 사용자의 패턴과 기존에 축적된 데이터에 따라서 다이나믹한 결과들을 도출해주는 서버가 필요하게 되었고, 그 결과 생겨나게 된 것이 WAS(Web Application Server)이다.
우리가 만들게 될 웹서버란 바로 WAS 서버를 의미하며, 웹서버는 모든 서비스의 관문이 되는 만큼 중요하고, 하는 일도 가장 많다. 이 웹서버를 어떻게 설계하느냐에 따라서 사용자가 느끼는 서비스의 품질이 상당 부분 달라질 수 있고, 서비스가 성장했을 때에 발생할 수 있는 위험들을 미연에 방지할 수 있다.
웹서버 설계의 가장 큰 갈림길은 '어떤 언어로 웹서버를 개발할 것인가'이다. 웹서버를 개발할 수 있는 언어는 여러 가지가 있지만 갈래를 나누면 크게 두 가지이다. 첫 번째는 컴파일 언어이고, 두 번째는 인터프리트 언어(혹은 스크립트 언어)이다. 컴파일 언어는 C, C++, Java 등의 전통적인 언어들이며 웹서버 개발 시에는 대부분 Java를 사용하게 된다. 컴파일 언어의 장점은 성능면에서 우월하고, 디버깅이 쉽다는 것이다. 또한 컴파일 언어는 컴파일(프로그램을 제작하는 것이라고 생각하면 된다) 시에 일정 부분 오류를 잡을 수 있기 때문에 상대적으로 안정적이다. 시스템의 규모가 커질 경우를 대비한 멀티 스레드를 사용한 연산에도 유리하다.
Java로 대표되는 컴파일 언어에서 가장 널리 쓰이는 웹서버 프레임워크는 Apache Tomcat과 Spring이다. Spring은 전자 정부 프레임워크에서 사용할 만큼 신뢰도가 높고, 상대적으로 많은 개발자가 다뤄본 프레임워크이다. 국내에서는 다른 프레임워크에 비해서 개발자를 구하기 쉽기 때문에 유지 보수 측면에서도 좋은 선택이 될 수 있다. 다만 대다수의 초급 개발자들이 복잡한 Spring의 설정을 제대로 이해하지 못하는 경우가 많기 때문에 웹서버 전반에 대한 그림을 그릴 수 있는 능력이 있는 개발자가 없다면 초기 단계에서 많은 시간을 소모할 수 있다. 하지만 이런 복잡한 설정 문제를 어느 정도 해결한 Spring Boot가 등장하기도 했고, 워낙 많은 개발자들이 사용하는 프레임워크이기 때문에 참고 서적이나 구글링을 통해서 대부분의 문제를 해결할 수 있다. 또한 전통적인 강자이기 때문에 여전히 많은 개발자 커뮤니티가 활성화되어 있어 향후 발전 가능성 역시 열려있다고 볼 수 있다.
스크립트 언어는 javascript, php, python 등이다. 스크립트 언어의 장점은 한 가지 언어로 웹 클라이언트와 웹서버를 모두 개발이 가능하다는 것이다. 이전의 컴파일 언어가 서버 사이드의 주축이던 시절에는 서버 개발자와 프런트엔드 개발자 사이에 어느 정도 명확한 구분선이 존재했었다. 그러나 프런트엔드에서 사용하는 스크립트 언어로 서버사이드를 구현하려고 하는 시도가 나타났고, 그 결과로 Node.js나 React와 같은 매우 완성도가 높은 서버사이드 프레임워크가 생겨나게 되었다. 이제 더 이상 서버 개발자와 프런트엔드 개발자의 구분선이 존재하지 않게 되었고, 프런트엔드를 개발하던 언어 그대로 서버를 개발하는 것이 가능해졌다. 또한 오픈소스 프레임워크의 설정이 쉽기 때문에 '간단하고 빠르게 만든다'라는 생각으로 개발하는 것이 가능하다. 명령창에 명령어를 몇 개 넣고 나면 다른 훌륭한 개발자들이 만들어놓은 라이브러리를 로딩할 수 있고, 빠르게 웹서버가 기동 되는 것을 볼 수 있다. 이게 전부인가 싶을 정도이다. 여러 가지 언어와 프레임워크를 다룰 수 있는 이른바 풀 스택 개발자를 구하기는 힘들기 때문에 초기 서비스 개발 시에 선택할 수 있는 매력적인 선택지가 아닐 수 없다.
하지만 이 스크립트 언어를 사용한 웹서버에는 분명한 단점이 존재한다. 첫 번째는 '콜백의 지옥'이라고 부르는 코드의 복잡성이다. 사용하는 패턴에 따라서 극복이 가능하다고 말하는 사람들도 있지만, 시스템의 복잡도가 높아질수록 이 '콜백의 지옥'에 빠질 확률은 높아진다. 콜백의 지옥에 빠지게 되면 문제가 생기거나 유지보수를 위해서 코드를 분석하다 보면, 어디에서 출발했는지조차 잊어버리게 된다. 두 번째는 오류에 취약하다는 것이다. 스크립트 언어는 그 특성상 해당하는 코드가 실행되지 않으면 그 코드가 문제가 있는지 알기 어렵다. 물론 도와주는 툴들이 존재하지만 한계가 있다. '유닛 테스트'라고 해서 코드에서 실행될 수 있는 모든 경우의 수를 시험해보는 방법이 있는데, 자칫 잘못하면 원본 코드보다도 테스트 코드가 더 커지는 상황이 발생할 수 있다.
그러나 한 가지 다행인 것은 대부분의 서비스가 이렇게 커지기는 매우 어렵다는 것이다. 커지고 나서 터질 문제들을 미리 걱정하는 것만큼 바보 같은 일은 없다. 95% 이상의 스타트업 서비스는 최신 데스크톱 정도의 사양이면 차고 넘치게 운영할 수 있다. 또한 단순 I/O 작업의 경우에는 스크립트 언어 기반의 프레임워크의 성능이 더 뛰어난 경우도 있어서 경우에 따라서는 스크립트 언어 기반의 프레임워크가 더 나은 결과를 보여주기도 한다. 네이버의 검색 코어 서버의 경우에도 스크립트 언어 기반의 프레임워크로 구성한 것으로 알려져 있다.
그렇다면 과연 어떤 언어와 프레임워크를 선택해야 할까? 정답은 함께하고 있는 개발자에게 맞추라는 것이다. 팀 내부에 개발자가 있다면 그 개발자의 배경에 맞는 프레임워크를 선택하는 것이 가장 좋다. CEO가 어설프게 주워들은 지식으로 실무자에게 특정 방식으로 개발할 것을 주장하는 것만큼 바보 같은 일은 없다. 풀 스택 개발자는 비싸고, 스타트업의 개발자는 그렇지 않아도 할 일이 많으며, 회사의 통장 잔고는 한정적이다. 스타트업은 최대한 빠른 시일 내에 제품과 서비스를 개발해서 세상에 내놓아야 한다. 새로운 것을 배우는 것보다도 이미 익숙한 배경에서 개발하는 것이 훨씬 쉽게 가는 길이다.
하지만 개발자가 팀 내에 없고, 외부의 도움을 빌어야 하거나 새로 개발자를 뽑아야 하는 상황이라면 어떤 선택을 해야 할까? 원론적인 이야기지만 그런 상황이라면 특정한 개발 스택으로 제한을 하기보다는 어떠한 개발 스택이건 개발을 완료할 수 있는 능력을 가진 사람을 뽑는 것이 맞다.
그럼에도 불구하고 권하고 싶지 않은 것이 있다면, 바로 php로 개발을 하는 것이다. 많은 php 개발자들이 반론을 펼칠 테고, 수많은 근거를 제시하려고 노력하겠지만 php보다 우수한 언어들은 많다. 5 ~ 10년 전, php가 유행하던 시절도 잠시 있었으나 많은 개발자들이 php의 단점 때문에 php를 버린 후고, 무엇보다도 더 우수하고, 쉬우며, 많이 쓰이는 javascript, python 등등의 대중적인 언어들이 있는 상황에서 새로 만드는 시스템을 굳이 php로 개발해야 할 이유가 없다. 더 궁금하다면 php에 대해서 불평을 늘어놓은 아주 좋은 글이 하나 있으니 참고해도 좋다. (PHP: 잘못된 디자인의 프랙탈 https://php-a-fractal-of-bad-design-kr.github.io/ )
개발을 배우고자 하는 CEO라면 Java나 javascript를 권한다. Java는 안드로이드 앱까지 뻗어나갈 수 있으며, javascript는 조금의 공부를 거치면 금방 써먹을 수 있는 수준까지 오를 수 있다. 웹서버 개발의 언어와 프레임워크로 컴파일 언어와 스크립트 언어에서 하나씩을 선택하라면 이렇게 추천하겠다. 컴파일 언어에서는 Java + Spring Boot 조합, 스크립트 언어에서는 javascript + node.js를 추천한다.