HAMA 블로그

현재 웹서비스를 Play 랑 스프링중 무엇으로 만들지 고민하던 중에 발견한 글을 공유합니다. 

https://www.quora.com/Which-is-better-Play-Framework-or-Spring-MVC-How-should-I-decide-what-to-use 번역을 했으며 . 2016년 7월 현재 이 글이 쓰여진 시점하고 무엇이 얼마나 달라졌는지 혹은 무엇이 잘못된 정보인지를  댓글로 보충해주시면 많은 분들에게 도움이 될듯합니다. 저의 아주 한정된 지식보다는 모든사람이 힘을 합치는게 좋겠죠.  Collaborative intelligence!!

Play Framework vs Spring MVC  

답변 1 Play2 scala 광전사님) 

링크드인은 Spring MVC 를 사용하다 몇년후에, Play Framework 로 바꿔 버렸는데 .  주요 이유는 다음과 같다.

1. 개발자 생산성 :  스프링은 시작하고 변경을 확인하는데 꽤 오래 시간이 걸리며, 그 때 재시작을 해야하며 그것은 큰 프로젝일 경우 수십분이 걸릴 수 있다. API 들은  무겁고 거추장스럽다. 모던 app 을 빌드하기위해 필요한 내장된 부가기능이 거의 없다. 사실, 규모가 있는 어떤 회사의 스프링 개발자와 대화해 보아도 더티한 면을 많이 보게 될것이다. 허접한 커스텀 프레임워크를 스프링 MVC 위에 쏟아붙고 관리도 제대로 안되고 있다. 링크드인도 예외는 아니었다. 헬~ 심지어 스프링소스에 있는 그 녀석 스스로도 스프링 MVC 위의 또다른 레이어를 빌드하고 자빠져있다. 그것은 스프링 부트라고 불린다. 
   
   왜 그러냐고 ?  스프링 MVC 는 그 자체로 맛탱이 간 놈이기때문이지.  반면 Play 는 hot-reload 변경이 가능하고, 그 덕분에 너는 환상적인 코딩-리프레쉬-코딩-리프레쉬 사이클에 따라 리듬을 탈 수 있게되는거지. 코딩하는게 아니라 리듬에 몸을 맡긴다고나 할까? API 들은 또 얼마나 파워풀하고 함수형 프로그래밍이 주는 구성력 덕분에 얼마나 좋은가 말도 못하지. 그리고 이 현대적인 프레임워크는 대부분의 유명인사들을 자체적으로 지원하고 있어, JSON,Web Sockets, DB access, Web Service calls 등등 말야 
   
   
2. Non-blocking I/ON :  스프링은 블럭킹이지. 의미가 뭐냐고?  니가 I/O (사용자로부터의 request, remote servcie call ) 를 할때마다  쓰레드로 떠 받치고 있어야한다는거야. 대부분의 현대 어플리케이션은 그들의 대부분의 시간을 I/O 하는데 사용하거든 , 그때마다 아까 팠던 진지 덮고 또 파고 ~  삽질하고 있다는거지.
   Play 는 완전한 non-blocking 이라 서비스지향 아키텍처 (마이크로서비스라는 멋진말로 불리기도 하지) 에는 엄청 좋은 성능을 보여줘 그리고 웹소켓도 지원하고, 스트리밍도 지원하고  (이걸 보라~ Play Framework: async I/O without the thread pool and callback hell).  이것은 엄청난 가능성을  열어 놓는건데 , 특히  BigPipe 스타일의 스트리밍에서 말이지.(이걸 보라고  Composable and Streamable Play Apps and Ping-Play: Big Pipe Streaming for the Play Framework).
   
   
3. 함수형 프로그래밍 :  스프링은 변경가능한 아슬아슬한 객체,어노테이션,XML 설정파일, 그리고 몇가지 마술들 로 이루어져있는데, 이것들은 처음엔 OK 된것으로 보여도 먼가 잘못되기 시작하면 넌 먼가를 해야하지만 그것들이 일으키는 부작용 (부수효과)의 파도에 넌 그대로 익사하고 말꺼야.  간단히 말해서 대부분의 스프링 MVC 어플리케이션은 헝크러진 실타래의 더미라고 봐도 무방.  니가 실타래 풀 수 있을까?  그냥 남들 안보는곳에서 가위로 삭둑하는게 보이네;; 반면 Play 는 함수형 프로그래밍 코어로 만들어져서 함수형 프로그래밍의 장점을 가지고 있지. 그것들은 쩌는 타입시스템을 사용하며 (타입세이프 클래스뿐만아니라 타입세이프 라우트,템플릿,빌드시스템 등등 더 많이) 이것들은 코드를 더 쉽게 이해하고 구성되고 새로 이용되게 해주고 디버그 문제도 쉽게 해결할 수 있게 해주고 커스텀 플러그인도 쉽게 만들어주지. 등등 너무 많다.  
   
   
4. 쩌는 오류 리포팅  :  스프링 가지고는 거대하고 이해 할 수 없는 스택 트레이스만 보았을꺼야. 그거 이해 하기 힘들었다고? 스프링님은 쩌는데 내가 실력이 없어서 어려웠던거라고 제발 생각하지마 ~ 스프링이 구린거니깐.
   플레이님은 말이지 굉장히 명쾌한 오류메세지만 브라우저 상에 잘못된 코드 조각과 보여줄거야. 타입시스템의 더 나은 사용예라고 말 할 수 있을거 같아. 대부분의 에러는 컴파일 타임 에러들 이거든 런타임이 아니라.  
   
   

더 많은 정보는 다음을 살펴보면되

The Play Framework at LinkedIn. 왜 LinkedIn 이  Play 로 갈아 탔는지 말해주는 영상 

2013. 6. 26 

Node.js vs Play Framework.  Node 와  Play 를 예로 보여주는 영상 

Composable and Streamable Play apps.  non-blocking I/O 와 functional programming 의 파워를 BigPipe-style streaming in Play 를 통해 알려주고 있는 영상 

답변 2 비둘기님)

제 생각엔 적재적소라는 말이 맞는거 같아요. 자신의 상황에 적합한 툴을 선택하는 거죠.

Play 는 어떤 상황에는  맞게 잘 만들어졌어요. 그리고 스프링은 다른 상황에 적합하죠. 둘이 겹치는 부분에서 조금 헷깔릴 수 도 있지만 무엇을 선택했다고 해서 나중에 망했다~ 라고 까지 할 만한 건 없을거에요. 

사실 Play 를 저는 깊게 파보진 못했지만 웹싸이트를 만들기 위한 툴이란걸 알고 있습니다. 아마 당신이 SOAP 나 REST 서비스를 하면서 주요 목적이 웹싸이트를 만드는것이라면 뭐 전형적인 웹어플리케이션 말이죠 Play 는 당신의 친구가 되어 줄겁니다.

스프링 MVC 는 스프링이라는 거대한 플랫폼의 한 부분이에요. 스프링에는 MVC 말고도 엄청난 프로젝트들이 있습니다. Spring MVC 그 자체는 스프링 어플리케이션에 MVC 행위를 하는 컴포넌트를 추가한것일 뿐이에요. 그 말은

스프링의 진정한 가치는 그 많은 컴포넌트들을 가지고 적재적소에 사용할 수 있다는 것입니다. 

이런 상황에서 스프링은 빛을 발할것입니다. 만약 Play 라면 한계가 있으며 당신에게 이미 만들어진 바퀴를 또 만들라고 강요할거에요. 

Updated Oct 4, 2015 · View Upvotes