[스크랩] 2.0으로 새롭게 거듭나다, 플레이 프레임워크

황상철 k16wire@gmail.com｜현재 NHN에서 애자일 개발에 대한 코칭 및 교육을 담당하고 있다. 번역, 블로그(http://pragmaticstory.com), 커뮤니티, Agile Korea 활동을 통해 소프트웨어 개발에서 애자일의 가치를 널리 알리기 위해 노력 중이다.

현재 Play의 최신 버전은 2.0으로 Play 1.2.x 버전(이하 Play1)과 Play 2.0 버전(이하 Play2) 간에 많은 차이점이 생겨났다. 이를 제대로 이해하기 위해 먼저 Play1의 특징을 살펴보고 이어서 Play2에서 새롭게 달라진 부분을 설명하기로 한다.

Play Framework의 이해
국내에 본격적으로 Play가 알려지게 된 것은 2011년 JCO 컨퍼런스를 통해서다. 당시 ‘Play Framework를 이용한 빠른 개발과 MongoDB를 이용한 실습’이란 주제 발표가 JCO를 통해 진행됐는데, 이때부터 많은 국내 개발자들도 Play에 관심을 갖기 시작했다. 

이후 2012년 JCO 컨퍼런스에서도 ‘PLAY! GAE!’라는 주제로 Play를 구글 앱 엔진에서 구동하는 발표가 이뤄지며 Play에 대한 관심을 더욱 키웠다(흥미롭게도 2012년 ‘PLAY! GAE!’의 발표자는 2011년의 발표를 보고 Play를 시작했다고 한다). 

필자의 경우 지인 덕분에 일찍부터 Play에 관심을 가질 수 있었고, 이번 기고를 통해 독자들에게 Play를 또 한 번 소개하려고 한다.

애자일 개발을 위한 최고의 선택
Play1 시절 공식사이트의 Play Overview를 보면 Play가 지향하는 바를 한 문장으로 잘 서술하고 있다. 이는 Play가 애자일 개발을 지향하고 있음을 의미한다. 

“Play is a perfect companion to agile software development.”

Play를 처음 시작한 개발자들은 웹 개발에 드는 어려움을 줄여보려 했다. 이를 위해 Play1에서는 다음과 같은 다섯 가지 특징을 장점으로 내세웠다.

- HTTP 인자와 자바 메소드 인자 간에 바인딩
- 자바 메소드에 대응하는 액션
- 템플릿에서 자바 객체 지원
- JPA 지원
- 파일 업로드 지원

이런 세부적인 특징 외에도 아키텍처 측면에서 Play1만의 차별화된 부분도 여러 가지가 있다.

자바 코드를 수정해도 서버를 재시작할 필요가 없다

Play는 Java 코드에서 변경된 사항이 서버 재시작 없이 바로 반영된다. 이는 Play가 컴파일된 class 파일이 아닌 Java 소스 코드를 직접 읽기 때문에 가능하다. Play는 자체 컨테이너를 내장하고 있는데 현재 Play가 사용하는 컨테이너는 JBossNetty (http://www.jboss.org/netty)다. 이전에 아파치 Mina를 사용하다가 WebSocket을 지원하기 위해 변경했다. 그렇다고 Play로 개발된 웹 애플리케이션을 자체 서버에서만 실행할 수 있는 것은 아니다. Tomcat과 같은 일반 서블릿 컨테이너에서도 얼마든지 실행할 수 있다.

무상태(stateless) MVC 아키텍처

Play는 루비 온 레일즈나 장고, PHP에서 강조하는 Share Nothing 아키텍처를 따른다. 뷰에서 상태를 유지하지 않으면 브라우저를 클라이언트로 쓰기 때문에 발생하는 문제(새로운 창을 만든다거나, 브라우저 백 버튼을 누르는 등)를 원천적으로 예방할 수 있고 화면을 나타내는 페이지 렌더링도 쉽게 구현이 가능해진다. 이 설명을 잘못 이해하면 Play 기반의 뷰에서는 웹 애플리케이션에서 흔히 사용하는 Session 객체를 쓰지 못한다고 오해할 수 있는데 그렇지 않다.

HTTP 지원

다른 자바 웹 프레임워크와 달리 Play는 서블릿 API를 사용하지 않고 HTTP를 직접 액세스한다. 이는 Play가 다른 웹 프레임워크와 크게 다른 특징인데 HTTP, REST 스타일 URI, 요청/응답 패턴 등을 직접 지원한다.

템플릿 엔진

앞에서 서블릿 API를 사용하지 않는다고 했다. 당연히 JSP도 사용할 수 없다. Play는 JSP, 태그 라이브러리 대신 템플릿 엔진을 사용한다. Play1이 사용하는 템플릿 엔진은 Groovy(http:// groovy.codehaus.org/)다.

TDD 지원

Play는 기본적으로 TDD 방식의 개발을 지원한다(앞에서 Play가 지향하는 바가 애자일 개발이라고 말했다). JUnit을 이용한 단위테스트뿐만 아니라 Selenium 기반의 브라우저 테스트도 직접 지원한다.

<그림 1> Test 모드에서 브라우저로 실행된 테스트 러너

모듈 구조

특정 기능을 하나의 모듈로 개발해 재사용하는 형태가 가능하다. 사실 모듈은 애플리케이션 설정 파일을 빼면 일반 Play 애플리케이션과 100% 동일하다.

이외에도 JDBC, SOAP, OpenID, 캐시 등 웹 애플리케이션을 개발하는 데 필요한 대부분 기술들을 기본적으로 지원하는 Full Stack Application 프레임워크라고 할 수 있다.

생산성 높은 웹 개발 플랫폼
Play 2.0 정식 버전은 2012년 3월 13일 출시됐다. 정식 버전이 출시되기 전에 이미 RC3까지 선보였지만 출시 이후에 많은 논란이 제기되고 있다. 이 부분은 나중에 다시 이야기하기로 한다. 그럼 주요 변경사항을 살펴보자.

비동기 프로그래밍 모델 지원

Play1에서도 확장 모듈을 통해 Future, Promise 같은 비동기 프로그래밍을 지원했지만 Play2는 아키텍처를 비동기 모델로 재구성했다. Play가 참조한 비동기 모델은 Actor-based model이며 이 모델을 Java와 Scala로 구현한 프레임워크 akka (http://akka.io/)를 사용했다.

기본 템플릿 엔진을 Scala로 변경

Play1까지 사용되던 Groovy 대신 Scala로 기본 템플릿 엔진이 변경됐다. Groovy 대신 Scala를 채택한 이유는 엄격한 타입 검사와 속도 때문이었다. Play1에서는 템플릿 오류를 런타임에서만 확인할 수 있었지만 Play2는 개발 타임에서 이런 오류를 확인할 수 있다. 템플릿의 속도가 느리다는 고질적인 불만도 해소됐다.

native 수준에서 Java와 Scala 지원

Play1에서 Scala를 사용하려면 별도 모듈을 설치해야 가능했다. 하지만 Play2는 Scala가 Java와 같은 수준의 기본언어가 됐다. 그러면서 Play의 많은 부분(특히 Java Reflection API를 사용하던 부분)이 Scala로 재개발됐다. 이 때문에 새로운 Play 애플리케이션을 만들 때 기본 언어를 선택하는 옵션이 추가됐다. 이때 기본언어를 Java로 설정해도 Play가 사용하는 라우터나 설정 파일은 Scala로 작성해야 한다.

다양한 데이터 스토어 지원

Play1에서는 JPA만을 지원했지만 Play2부터는 Ebean (http://www.avaje.org/), Anorm 등 다양한 데이터 관련 기술을 통합해 기존에 많이 사용하던 SQL, DB 이외에 다양한 데이터 스토어를 지원한다.

강화된 빌드시스템

Play는 초기부터 container-less deployment를 채택했다. 이 덕분에 development 모드에서는 Java 코드가 변경돼도 컨테이너를 재구동할 필요가 없었다. 

일반적인 jvm 환경에서는 이런 접근이 불가능하며 이를 가능하게 해주는 jrebel(http://zeroturn around.com/jrebel/) 같은 상용 제품이 나와 있다. 일반적 빌드 도구들이 이를 지원하지 않기 때문에 1.x에서는 파이썬을 이용해 빌드를 자체적으로 구현했다. 그러다 보니 Maven과 같은 전문 도구들에 비해 확장성이 떨어지는 문제가 있었다. Play2부터는 다양한 빌드 프로세스를 지원하기 위해 Scala 기반의 sbt(http://www.scala-sbt.org/learn.html)를 내장했다.

정리하면 Play2는 Play1에서 제기됐던 문제를 극복하고 non-blocking이나 WebSocket과 같은 최신의 웹 기술을 지원하는 플랫폼이다.

<그림 2> 버전별 Play를 구성하는 기술 요소

Play가 갖고 있는 문제들
지금까지 Play1, Play2에 대한 특징들을 살펴봤다. 이번에는 Play가 갖고 있는 이슈들을 짚어보자.

static 이슈

일반적인 Java 프로그래밍에서는 static 변수나 메소드 사용을 권장하지 않지만 Play는 Controller와 Model에서 많은 static 메소드를 사용한다. 그런데 이 방식에 문제가 없는지에 대한 이슈가 있다. 이를 지지하는 사람들은 Play가 무상태 아키텍처를 지향하고 단순히 요청을 포워딩하거나 데이터를 전달하는 역할을 하는 Controller와 Model에서만 statc 메소드를 쓰기 때문에 별다른 이슈가 없다고 말한다.

하위 호환성 문제

Play2는 많은 부분이 Play1과 호환되지 않는다. 템플릿은 언어 자체가 변경됐고 컨트롤러도 API가 완전히 달라졌다. 그러면서 마이그레이션에 대한 지원은 거의 없는 상황이다. Play1을 사용했던 사람들이 Play2를 사용하려면 전면 재개발은 피할 수 없다.

새롭게 변화된 특징이 올바른가?

Play2에서 일어난 많은 변화에 불만을 가진 한 개발자가 ‘Open Letter to Play Framework Developr’라는 제목의 글을 올렸고 여기에 87개의 답글이 붙으면서 논쟁이 불거졌다. 급기야 Play를 만든 귀욤 보트(Guillaume Bort)가 공식 답변을 내놓기도 했다. 특히 scala가 들어오면서 과거 Pure Java로 구현됐던 Play1과 비교하면 약간 어색한 API들이 보인다. 이런 논란은 RC 버전부터 계속됐던 것으로 앞으로 Play가 개발자들에게 어떻게 인식되느냐에 있어서 중요한 터닝포인트가 될 것이다.

Play에 대한 향후 전망지금까지 Play가 무엇이고 어떤 특징과 문제들을 갖고 있는지 살펴봤다. Play를 배워야겠다는 생각이 드는가? 이미 Java 기반 웹 애플리케이션 프레임워크의 ‘끝판왕’은 스프링이다. Java를 알아도 스프링을 모르면 개발자로 일하기 힘든 세상이 됐다.

Play가 스프링을 대신할 수 있을까?

어려워 보인다. Play가 할 수 있는 일은 스프링으로도 모두 가능하며 더 많은 레퍼런스를 찾을 수 있을 것이다.

그러면 Play는 배울 필요가 없는가?

그렇지 않다. 요리사가 칼 한 자루를 가지고 모든 요리를 하는 경우는 없다. 어느 정도 가능할 수도 있겠지만 불편한 것은 분명하다. 작지만 손에 익은 작은 칼 하나가 요긴하게 쓰이는 법이다.

Play를 사용하게 되면 가장 좋은 점은 무엇인가?

Play는 루비 온 레일즈를 보면서 많은 개발자들이 열광했던 높은 생산성을 Java에서 가능하게 해준다. 하지만 레일즈가 지녔던 한계인 성능 이슈가 Play에서는 문제가 되지 않는다. 그 이유는 Java를 기반으로 하기 때문이다. 기존에 J2EE에서 활용했던 기술을 전부 사용할 수가 있다. 게다가 웹 애플리케이션을 위한 Full-stack을 제공한다. 외부 모듈도 계속 추가되고 있다. Play2가 출시되고 얼마 지나지 않아서 프레임워크 자체에 대한 불안한 부분이나 문서 부족 등의 이슈가 남아있지만 Play1의 경우로 미루어 보면 이런 이슈는 곧 해소될 거라 믿는다.

참고자료
1. Play 공식사이트 - http://www.playframework.org/documentation/
2. Play 구글그룹 - https://groups.google.com/forum/?fromgroups#!forum/play-framework
3. source code on github: https://github.com/playframework
4. static issue - http://stackoverflow.com/questions/5192904/play-framework-uses-a-lot-of-statics
5. play2 issue - https://groups.google.com/forum/#!topic/play-framework/AcZs8GXNWUc/discussion
6. 자바지기 블로그 ‘왜 플레이 프레임워크인가?’ -
http://www.slipp.net/wiki/pages/viewpage.action?pageId=950302
7. Play Framework Cookbook, 알렌산더 릴젠, 에이콘출판

출처 : http://www.imaso.co.kr/?doc=bbs/gnuboard.php&bo_table=article&wr_id=40235