웹서버 중에서 Django를 선택한 이유

Django

• 장점

• 굉장히 쉽게 배울 수 있는 프로그램 언어인 Python을 기반으로 한다.

• 인증, 관리와 같이 거의 대부분의 사이트에서 사용하는 기능들이 기본 모듈로 제공된다.

• 성공적인 도입 사례가 있습니다.(Instagram 등)

• 높은 코드 완성도를 유지할 수 있다.

• python의 강제된 indent가 코드 완성도에는 일조함.

• IDE 지원이 훌륭한 편이다.(Pycharm, Visual Studio 등)

• AWS, Google Cloud, Azure등에서 전폭적으로 초기 단계부터 지원한 프레임워크다.

• deploy 및 운용에 대한 개발 비용을 크게 아낄 수 있다.

• 단점

• 한글 문서가 아주 풍부한 편은 아니다.

• typeless 언어의 약점은 그대로 보유하고 있다.

• python에 대한 높은 이해도가 필요하다.

• Django는 문제를 python으로 해결하는 편이다. (프레임워크 특화 기능보다)

• 성능 문제에서 자유롭지 못하다.

• python은 ruby보다 빠를 뿐이다.

• Django도 rails보다 빠를 뿐이다.

node.js

• 장점

• V8 엔진을 기반으로 한 성능이 뛰어납니다.

• 오픈소스 문화권하에 있어서만은 아닌, 풍부한 모듈 지원. (유독 많다. 그것도 짧은 기간내에 급속히 증가)

• C++로 필요한 모듈 작성 가능.

• 싱글스레드, 비동기 IO 처리에 기반한 빠른 속도

• 파일 I/O나 네트워크 처리를 이벤트 드리븐 방식으로 처리하기 때문에 빠른 처리가 가능함

• CPU의 대기시간을 최소화 할 수 있음.

• CPU 부하가 적고, 많은 커넥션을 동시에 처리해야 하는 구조에 적합.

• 자바스크립트를 이용해서 개발할 수 있기 때문에 프론트엔드 개발자의 진입장벽이 낮음.

• 기존 Java 서버에 비해 생산성이 높음

• 단점

• 싱글스레드 모델이기 때문에 하나의 작업에 시간이 오래걸리면 시스템 전체의 성능이 급격하게 떨어짐

• 에러가 발생할 경우 프로세스 자체가 죽어버리므로 주의해야 함(watch dog 등으로 처리 가능)

• 멀티코어 활용을 위해서 cluster 모듈을 이용해야 하고, 세션을 공유할 경우 부가적인 작업이 필요함

• 불편한 비동기 프로그래밍 모델

• 다음 할 일을 계속 콜백(callback) 함수로 넘기는 스타일로 코딩을 하다 보니 Pyramid of Doom이라 불리는 중첩 코드가 나오기 쉽상.

• 이 문제를 해결하기 위해 비동기 제어 흐름을 좀 더 쉽게 표현하기 위한 async 모듈, underscore 등도 사용했지만, 이러한 프로그래밍 스타일은 Django나 Ruby on Rails에 비교해서 코드의 가독성을 현저히 떨어진다.

• 초급 프로그래머라도 쉽게 할 수 있다 얘기는 거짓말.

• 학습 난이도가 높은 편이다.

• 시스템 관리자에게 쉽지 않은 아키텍쳐.

• 자바스크립트로 로직을 구현하는 것은 어울리지 않다.

• typeless 언어가 가져야하는 코드 가독성이 javascript는 부족하기 때문.

rails

• 장점

• ruby언어의 장점을 근간으로한 뛰어난 가독성, 그리고 표현력.

• twitter, github, redmine 이라는 성공적인 도입 사례.

• 검증된 빠른 개발 속도.

• rails로 서비스를 개발한 후, 서비스 트래픽이 높아지는 단계에서 다른 플랫폼으로 갈아타는 사례가 많다는 것이 이를 입증함.

• MVC 모델을 온전히 구현하고 있다.

• github로 공개된 기능 패키지 수 3위 권을 다 년간 유지하고 있다.

• 가져다 쓸 수 있는 기능이 아주 많다는 의미.

• 단점

• 비동기 API가 너무나 부족함.

• GIL과 부족한 비동기 API로 인한 성능 이슈가 크게 대두 됨.

• python 보다도 느림

• 성능 문제로 인한 최적화 한계를, 다른 플랫폼으로 풀었다는 것은, rails의 미래에 대한 큰 숙제다.

• 이로 인해, 고도화 과정이 반드시 필요하며, 고도화 과정은 rails 이외의 영역에 대한 높은 이해도가 필요한 경우가 많다.

• 과도한 수준의 추상화로, 원리를 이해하는 데에는 여타 플랫폼보다 더 큰 시간이 든다.

asp.net

• 장점

• C# 사용 가능

• Visual Studio 위에서 개발 가능

• MVC 패턴을 제대로 지원함.

• Model, View, Controller로 프로그램이 분할되어 복잡성을 다루기 쉬워집니다.

• ViewState, 서버 기반 폼(server-based form)을 사용하지 않아서, Web 응용 프로그램에 대한 완전한 제어를 원하는 개발자들에게 이상적인 환경입니다. (WebForm에 비해서 MVC는 추상화의 수준이 낮습니다. WebForm의 경우, WebForm만 알아도 어떻게든 돌아가는 Website를 만들 수 있지만, MVC는 그게 안 됩니다. 그러다 보니 1강에서처럼 그렇게 많은 선수 과목이 필요하게 되었습니다. )

• Website의 흐름을 마음대로 제어할 수 있습니다. 과거 WebForm에서는 blog.net/posts/23 같은 주소로 글을 접근할 수 있게 하려면, IIS를 건드려야 했지만, MVC에서는 매우 쉽게 이 문제를 해결할 수 있습니다.

• 테스트 주도 개발(Test-Driven Development, TDD)을 하기에 좋습니다.

• 큰 팀에서 많은 개발자와 디자이너들이 Web 응용 프로그램에 높은 수준의 제어를 원한다면 추천할만합니다.  

• 단점

• 윈도우 서버 위에서만 온전히 동작.

• 개발자 풀이 좁음.

• 오픈소스권 문화가 아니라서 MS가 제공하지 않는 기능은 .NET 플랫폼 지원언어로 개발해야함.

spring [java]

• 장점

• 크기와 부하의 측면에서 경량.

• 제어 역행(IoC)이라는 기술을 통해 애플리케이션의 느슨한 결합을 도모.

• 관점지향(AOP) 프로그래밍을 위한 풍부한 지원을 함.

• 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너(Container)라고 할 수 있음.

• 간단한 컴포넌트로 복잡한 애플리케이션을 구성하고 설정할 수 있음.

• 대한민국 전자정부 표준 프레임워크의 기반 기술

• 단점

• 설정이 복잡한 편이다.

• 컴포넌트가 다양한 건 사실이나, 컴포넌트로 존재하지 않는 기능을 사용할 경우에 개발 공수가 크다.

play [play]

• 장점

• 국내의 많은 교육기관에서 가르치고 있는 Java 기반 프레임워크인 만큼 누구나 쉽게 접근할 수 있습니다.

• 웹 서버를 내장하고 있어 별도로 서버를 세팅할 필요가 없다.

• 일반적인 Java 어플리케이션은 빌드하는데 굉장히 오랜 시간이 소모되지만, Play의 경우 변경된 내역에 대해 자동으로 빠르게 빌드하기 때문에 개발 및 테스트 시간을 크게 줄일 수 있습니다.

• 가장 훌륭한 IDE인 Eclipse와 Intellij에서 Play!를 완벽하게 지원합니다.

• 단점

• 한글로 된 문서가 거의 없습니다. 진행중이던 문서화 작업이 중단되었으며, 관련 서적과 블로그를 통해 제공되는 강좌들은 오래되어 Play! 최신 버전과 맞지 않습니다.

• 번들이라고 하는 서드파티 모듈들이 많지 않고 그나마 있는 것들도 프레임워크 버전에 맞춰서 버전업이 되지 않아 활용 가치가 매우 낮습니다.

• Twitter의 Rails나 Instagram의 Django와 같은 성공적인 도입 사례가 아직까지 없습니다.

• Java와 Scala를 골라서 개발할 수 있다고 이야기하지만 실제로 Scala를 공부하지 않으면 개발을 진행하기 어려울 정도로 Scala의 비중이 높습니다.

code igniter [php]

• 장점

• PHP 기반 full stack framework 중에서 성능이 매우 뛰어납니다.(Phalcon과 Slim은 경량 프레임워크)

• 서비스가 성장하여 개발 인력을 늘려야 할 때 비교적 쉽게 관련 기술 보유자를 구할 수 있습니다.

• 단점

• RESTful 서비스에 적합한 구조가 아닙니다.

• Session 처리가 안정적이지 않고, DB Session 만을 지원하기 때문에 File이나 Memory 기반의 Session을 사용하기 위해서는 별도의 개발이 필요합니다.

• PHP 언어 특성상 구조적으로 깔끔한 코드 작성이 어렵습니다.

• ORM 기반의 Model이 아니라 코드를 통해 스키마를 파악하기 어렵습니다.