출처 : http://kwon37xi.egloos.com/3666564
OKJSP에 자주 가서 요즘 자바 개발자들이 어떻게 살아가나 를 보는 편인데, 아주 많이 반복적으로 올라오는 질문이 "대체 뭘 공부해야 하나요? 프레임워크는 Spring을 해야 할까요? iBATIS를 해야 할까요?" 하는 식의 질문들이다(이 질문은 사 실 말이 안된다. 왜 그런지 읽다보면 나온다).
Java는 웹 관련 프레임워크들이 너무 다양하고, Ruby나 Python 같은 경우에는 RubyOnRails나 Django 처럼 하나의 프레임워크 안에 기능별 프레임워크들도 모두 다 All in one 형태로 들어 있어서 혼란을 주지 않는 반면, Java는 각 영역별 로 프레임워크가 모두 다르고, 또한 각 영역별로 존재하는 프 레임워크들의 종류도 많아서 초보 개발자들에게 극심한 혼란 을 주고 있다.
그래서 나름대로 Java Web 개발자들을 위한 학습 로드맵을 정리해 보았다.
1. Java 그 자체 많은 웹 개발자들이 마치 JSP 코드를 짤 줄 알면 그걸로 Java 웹 개발을 할 줄아는 것이라 생각하고 Java 그 자체를 소홀히 하는 것을 본다. 말도 안되는 소리이다. Java를 모르고서 Java 웹 개발을 제 대로 한다는 것은 어불 성설이다. Java 그 자체를 먼저 공부 하라.
특히 Java 5 문법을 숙지하길 권한다. 이제 우리나라도 점차 Java 5가 대세가 되어 가고 있다. 대부분의 프레임워크들과 WAS(JSP와 서블릿을 구동하는 서버)도 모두 Java 5를 기준 으로 바뀌었으며, JVM 자체도 버전이 높을 수록 성능이 더 좋 다.
2. JSP와 Servlet 그리고 Model 1 모델 1은, JSP 하나에 DB에 접속해서 쿼리를 날리는 등의 모 든 업무적인 기능(Business Logic)을 넣고, 그 아래에 HTML 코드를 박아 넣는 식으로 개발하는 것을 의미한다. 아직도 많은 개발자들이 여기에 길들여져 있는데, 일단 JSP 자체에 대한 기본기를 익힌 뒤로는 재빨리 버려야 할 습관이 다.
그리고 많은 개발자들이 Servlet을 무시하고 JSP만 하는 것 을 보곤 하는데, Servlet에 대한 학습이 제대로 이뤄지지 않으 면 더 나은 웹 개발이 곤란하다. Servlet에 대한 기초 개념을 확실히 잡길 권한다.
모델 1은 제가 알기로는 HTML과 로직을 모두 한 JSP에 넣는 방식이 아니라 jsp:beans를 이용하는 방식입니다. 모델 1에 서도 여전히 비즈니스 로직과 UI는 분리할 수 있죠. thin controller, fat model에는 더 맞는 방식이라고도 할 수 있습 니다. - 영록, 그리고 Servlets and JSP Pages Best Practices에서 Model 1 관련 부분 참조
모델 1은 JSP나 혹은 서블릿 하나가 요청에 대한 처리, 데이 터 유효성 검사, 비즈니스 로직 처리, 응답 생성을 모두 다 책 임지는 방식이다. 모델 1은 작고, 간단한 애플리케이션에서 개발을 쉽게하고자 할때 사용된다.
In Model 1, a request is made to a JSP or servlet and then that JSP or servlet handles all responsibilities for the request, including processing the request, validating data, handling the business logic, and generating a response. The Model 1 architecture is commonly used in smaller, simple task applications due to its ease of development. - Wikipedia
3. Model 2 - 프레임워크의 등장 JSP로 열심히 개발을 하다보니 프로젝트 규모도 커지기 시작 하고, JSP 파일 크기도 수천줄에 달하는등 엄청나게 커진다. 그런데 이 JSP에다 두서없이 모든 기능을 다 때려 넣다보니 JSP마다 똑같은 기능들이 Copy&Paste로 들어가고, JSP 안 에 들어 있는 Java 코드들에서 에러가 발생하면 찾아내서 디 버깅 하는 일이 지옥같이 느껴지기 시작한다.
여기서 Model 2가 구원자로 등장한다.
Model 2는 말만 멋드러졌지 실제로는 간단한 개념이다.
JSP에서 수행하던 DB 쿼리 등의 작업을 Servlet에게 넘겨주 고 JSP에서는 오로지 화면 출력만 담당하는 것이다.
Servlet에서 DB 쿼리등 화면 출력과는 상관없는 비지니스 로 직을 일단 먼저 모두 수행하고, 그 결과를 request.setAttribute("key",결과객체);로 담은 다음 JSP 페이 지로 포워딩(forward)을 하면 JSP에서는 request.getAttribute("key")로 그 객체를 받아서 화면에 뿌려 주기만 한다. 이런 업무 수행단/화면 출력단의 철저한 역할 분리가 Model 2이다.
여기서 이러한 각 역할을 "MVC - Model View Controller" 라 고 한다. 그래서 Model 2는 MVC와 동일한 의미로 사용하기 도 한다. MVC의 의미는 공부하면서 찾아보라.
이게 뭐가 좋냐고? 개발 기간이 좀 길어지고 프로젝트 규모가 쬐끔 커지고, 기존 프로젝트를 유지보수를 해보면 얼마나 좋 은지 몸소 뼈져리게 느끼게 된다.
Model 2의 기능을 정형화해서 쉽게 구현하게 해주는 것이 MVC Framework들의 역할이다. 가장 유명한 Model 2 웹 프레임워크들은 다음과 같은 것들이 있다.
* 스트럿츠 1 - Struts 1 * 스트럿츠 2 - Struts 2 * 스프링 MVC - Spring MVC * 기타 덜 유명한 Wicket, Stripes, JSF, Tapestry 등.
Struts 1은 MVC의 효시라고 할 수 있다. 우리에게 MVC라는 축복을 주기는하였으나, 나온지 오래된 만큼 낡은 개념들이 많이 녹아있고 쓸데 없이 복잡하고 배우기도 어려운 편이다.
오히려 Struts 2와 Spring MVC가 더 배우기 쉬울 것이며, 개 발도 더 쉽다. 현재 추세는 Struts 2와 Spring MVC이다. 대형 포탈이나 SI 업체들도 Spring/Struts 2를 주로 채택하는 추세 로 가고 있는 것으로 알고 있다.
둘 중 하나의 개념만 확실히 이해해도 다른 것을 배우는데 어 려움이 별로 없으므로 그냥 둘중에 골라서 배우길 권한다. 나 는 Spring을 선호한다.
그리고 MVC 프레임워크를 사용하기 시작하면서 View를 만 드는 JSP에 대해서도 재조명이 시작된다. 기존에 Java 코드 를 JSP에 직접 넣던 관행을 버리고 JSTL과 태그 라이브러리 를 사용하거나 아예 JSP를 버리고 다른 템플릿 엔진으로 만 들기도 한다. 이에 관해서는 맨 마지막에.
4. 퍼시스턴스 프레임워크 : JDBC 반복 작업에 짜증이 나기 시작하다. 현대 웹 개발에서 가장 큰 역할을 차지하는 것은 뭐니뭐니해 도 단연 Database 작업이다. 지금까지는 아마도 JDBC에서 DB 커넥션을 맺고, 쿼리를 날 리고 그 결과 ResultSet을 JSP로 넘겨주어서 출력하는 식으 로 했을 것이다. 이미 다들 알고 있겠지만 JDBC를 사용하면 똑같은 코드가 굉 장히 많이 반복해서 나온다. 한마디로 "삽질"의 전형이 JDBC 작업이다. 이것을 깨달은 많은 개발자들이 조금 어정짱하게 반복작업을 해결해주는 Util 클래스들을 프로젝트별로 만들어서 사용하 곤 한다. 하지만, 물론 이에 대해 정형화하고 깔끔하고 훨씬 더 사용하 기 쉬게 만들려는 노력이 이미 수년에 걸쳐 이루어졌다.
이렇게 DB관련된 작업을 정형화한 것들을 Persistence Framework 라고 한다.
* 아이바티스 - iBATIS : SQL Mapper - JDBC보다 더 쉽게 배우고, 더 편하게 사용한다. * 하이버네이트 - Hibernate : 객체지향을 객체지향답게, 개발 기간을 엄청나게 단축시켜주다.
퍼시스턴스 프레임워크의 양대 산맥은 iBATIS와 Hibernate 이다. 이 둘 모두 우리나라에 책이 나와 있다. iBATIS는 SQL Mapper의 한 종류이고, Hibernate는 ORM의 한 종류이다.
이 둘의 차이는 iBATIS는 개발자가 SQL 쿼리를 직접 작성한 것을 객체에 매핑시켜주는 것이고, ORM은 DB 스키마와 객체 간의 관계를 설정파일로 만들면 자동으로 쿼리를 만들어주는 것이다.
자, 이 둘을 보면 미국에서는 Hibernate가 인기가 좋고, 우리 나라에서는 iBATIS가 사실상 SI 업계를 평정했다. 그러니까, 일단은 우리나라에서는 iBATIS를 공부하면 된다고 보면 된다.
이렇게 말하니까 마치 이 둘이 경쟁자 같은데, 사실 이 둘은 경 쟁 상대라기 보다는 보완해주는 역할을 한다. SI에서 처럼 DB 테이블이 정규화 되어 있지 않은 경우에는 Hibernate같은 ORM을 사용하면 프로젝트를 말아먹을 수 있다.
iBATIS는 테이블 정규화에 무관하게, 개발자가 작성한 SQL 을 객체로 매핑하기 때문에 DB 스키마가 마구 꼬여 있는 상황 에서도 유연하게 작동하고, 개발자가 직접 SQL 튜닝을 할 수 있다는 장점이다.
그리고 Hibernate는 배우기가 굉장히 어려운 프레임워크이 고 튜닝이 매우 어렵다. Hibernate책을 보면 캐싱을 통해 성 능을 향상시키라고 하지만 캐싱은 iBATIS도 못지않게 잘 지 원한다. 하지만 일단 배우면, 그로인한 코딩 생산성이 iBATIS 가 감히 넘볼 수 없을 정도록 급격히 향상된다.
Hibernate는 DB 정규화가 잘되어 있는 웹 포탈 업체나 패키 지 소프트웨어 제작시에 강력히 권장할만 하다.
5. IoC와 DI - 객체의 생성주기와 의존성을 관리하고 싶어지 다 사실 내가 경험한 SI를 보면 4단계 까지만 가도 막장은 아닌 프로젝트라고 본다. 아직도 신규 프로젝트를 하면서도 Model 1에 JDBC로 코딩하는 것을 많이 보았기 때문이다.
앞서, MVC라는 형태로 웹 애플리케이션의 역할을 철저하게 분할해서 처리하라고 했었다.
이제 여기서 좀 더 역할을 분할하기 시작한다.
Database를 관장하는 코드(DAO)와 Database 처리 결과를 가지고 그외 비지니스 로직을 추가로 수행하는 코드 (Service), 그리고 웹으로 들어온 요청을 받아서 비지니스 로 직을 호출하고, 그 결과를 다시 웹(HTML 등)으로 내보내는 코드(Controller)로 분할을 하면 유지보수가 더 쉽고, DB가 Oracle에서 DB2 로 변경되는 식의 중대 변화가 있을 때도 DAO만 바꾸면 되는 식으로 변화에 대한 대처가 유연해 진다 는 것을 깨닫기 시작한다.
이제는 각 역할별로 클래스를 분할하고 컨트롤러 객체는 서비 스 객체에 서비스 객체는 DAO 객체에 의존해서 작동하도록 코드를 바꾸기 시작한다. 그리고 객체의 생성과 파괴 주기도 관리해야만 하게 된다. 객체를 하나만 생성하면 되는데 불필 요하게 매번 new를 할 필요는 없으니까.
이렇게 객체의 생성/파괴 주기를 관리하고 객체간의 의존성 을 관리해주는 프레임워크를 IoC 컨테이너라고 부른다.
1. Spring Framework 2. EJB 3.0
사실상 대세는 Spring Framework로 굳어졌다. EJB 3.0은 내 가 안써봐서 뭐라 말은 못하겠다.
Spring MVC는 이 Spring Framework의 일부분이다.
Spring은 또한 AOP도 지원한다.
AOP 의 개념이 상당히 어려운 편이라서 개념 자체를 확실히 한마디로는 표현하지 못하겠다. 어쨌든 개발자들에게 가장 쉽 게 다가오는 표현으로 하자면, AOP는 동일한 패턴으로 반복 적으로 해야하는 일을 설정을 통해 자동으로 해주는 것이다. 이에 관한 가장 보편적인 예가 바로 트랜잭션이다. 지금까지는 아마도 비지니스 로직이 시작될 때 트랜잭션이 시 작되고, 비지니스 로직이 끝날 때 트랜잭션을 종료하는 코드 를 매번 작성해서 넣었을 것이다. AOP를 사용하면, 비지니스 로직의 역할을 하는 메소드가 무 엇인지 설정파일에 넣어주기만 하면 자동으로 메소드가 시작 될 때 트랜잭션을 시작시키고, 메소드가 끝날 때 트랜잭션을 종료시켜준다. 물론 예외가 발생하면 트랜잭션을 rollback도 해준다. 따라서 Spring을 사용한 프로젝트에서는 트랜잭션 관련 코드를 볼 수 없을 것이다.
Spring 프레임워크는 기본적으로 IoC 컨테이너 역할을 하는 것이 핵심이다. 따라서 Spring을 사용한다고 해서 꼭 Spring MVC를 사용할 필요는 없다. Struts 2 + Spring + iBATIS 나 SpringMVC + Spring + Hibernate 등... 어떠한 조합이라도 가능하다.
6. 그 외 ◈ Template Engine : JSP 보다 더 간결하면서 강력한게 필요 해! * JSP + JSTL : Sun이 지정한 산업표준이다. JSTL은 당연 히 쓰고 있으리라 믿는다. * Freemarker : 가장 권장할 만하다. * Velocity : 굉장히 배우기 쉽다. JSTL보다 더 빨리 배워서 쓸 수 있다. 가독성도 좋다. 그러나 Freemarker 만큼 편하고 강력하지는 못하다. 많은 사람들이 Java 웹 개발을 그냥 "JSP 개발"이라고도 부 르는데, MVC가 도입되고, Freemarker 같은 다른 템플릿 엔 진을 사용하게 되면 더이상 JSP는 코빼기도 안보이게 된다. 그러므로.. JSP 개발이라는 말은 쓰지 않았으면 좋겠다.
◈ Layout Engine * Sitemesh : 헤더 푸터 처럼 동일 패턴이 반복되는 레이아 웃을 관리해준다.
◈ XML 도우미 : W3C DOM은 너무 어렵고 난잡하다. 좀 더 편 한 XML관련 개발을 원한다면.. * JDOM : Java 표준으로 지정됐다고 한다. * DOM4J 둘 다 비슷하게 편한거 같다. 예전엔 JDOM을 썼었는데, 나 같 은 경우 현재 프로젝트에서는 DOM4J를 사용한다. Hibernate가 DOM4J를 사용하기 때문에, 별도의 라이브러리 더 넣는게 귀찮아서.
◈ 단위 테스트 * jUnit : 코드를 철저하게 테스트하자.
◈ 소스코드 버전관리 * CVS * Subversion : 현재 대세는 Subversion 내가 최고 막장으로 꼽는 프로젝트는 아직도 FTP로 소스 관 리하는 프로젝트이다. 이런 프로젝트에는 절대로 참여하지 않 을 것이라고 굳게 맹세하고 또 맹세했다. --; 소스 코드 버전관리는 여러 개발자들이 동시에 개발할 때 소 스코드를 저장하고 충돌을 관리해주며, 소스 변경 내역을 계 속해서 추적해서 과거 소스로 언제든지 돌아갈 수 있도록 도 와준다. 현재 대세는 Subversion이지만 CVS로도 버전관리의 이점을 충분히 만끽할 수 있다. 그리고.. 사실 CVS가 사용법을 익히 기는 더 쉽다.
◈ 자동 빌드 * Ant : Ant 면 만사 Ok! * Maven 아직도 javac 로 컴파일하고 있고, FTP로 파일 올려서 복사하 고 있다면.. 이 모든일을 자동으로 명령 한방에 처리하도록 해 야 실수도 적고, 퇴근도 일찍한다. Ant로 빌드와 배포를 자동화 하자.
결론
내가 권하는 조합은 * SI 업체에서 일하는 경우 : Struts 2 혹은 SpringMVC + iBATIS + JSP/JSTL + 가능하다면 Spring Framework * 웹 포털등과 같은 업계, 패키지 소프트웨어 제작 업체 : Struts 2 혹은 Spring MVC + Hibernate + Spring Framework + Freemarker + Sitemesh
'트랜드' 카테고리의 다른 글
[펌]'2013년 하지 말아야 할' 9가지 애플리케이션 개발 프로젝트 (0) | 2015.03.08 |
---|---|
2014년 IT 일자리 트렌드 ‘개인 사업자를 준비하라’ (0) | 2015.03.06 |
컴퓨웨어, ‘2014년 5대 IT 기술 전망’ 발표 ITIL (0) | 2015.03.04 |
sw 엔지니어 를 위한 로드맵 (0) | 2015.03.04 |
헉슬리의 경박함에 대한 경고 (0) | 2015.02.15 |