004. MVC? Model2 - 개발자를 칼퇴 시켜주는가? - 추고 중

진정한 분업과 협업 - MVC

지난 강좌가 바로 MVC 였습니다.  따라서 패스하고 005 강좌로 가시죠.  자 어서요.

잉? 보신 기억이 없다굽쇼?  흠 그럼 보신 분들은 005로 가시고요.  못 보신 분들은 제가 확인 사살해 드리지요 뭐...

		Web MVC	Web MVC 구현	Console MVC 구현
M - Model	도메인 모델	주로 POJO	Member.java	Member.java
V - View	화면-사용자 대화 담당	주로 JSP	NeoMember.jsp	MemberDriver.java
C - Controller	흐름 통제	주로 Servlet	NeoMemberServlet.java	MemberDriver.java

뭔지 모르겠지만 감은 오시죠.  이제 그 감을 본인의 문장으로 표현하시면 MVC 는 끝난 겁니다.  MVC 그까이꺼... 그런데 저는 왜 문장으로 표현이.. 아직 내공이 부족해요. ㅡㅜ

실전에서

Model 은 거의 대부분 DB 에 저장되는 정보입니다. 

View 는 Web App 인 경우 브라우저 화면, Console App 인 경우 그 시커먼 창, Window App 에서는 Window 가 되겠습니다.

Controller 는 음지에서 View, Model, 비지니스 요구 사항 처리 등등 전체 흐름을 통제하는 빅브라더 입니다.

그리고 잘 보시면 우리가 구현한 어플리케이션에서 Model 에 해당하는 Member.java 는 Web 이던, Console 이던 심지어 구현 못해본 Windows 어플리케이션이던 수정없이 사용할 수 있습니다.  View 는 표현하고자 하는 플랫폼에 따라 갈아 끼울 수 있는(플랫폼에 의존하는) 존재입니다.  Controller 도 플랫폼에 의존적인 존재이군요.  우리는 일단 Web MVC 구현에 관심이 있으니 Web MVC 에만 집중해서 조금 더 파고 들겠습니다.

어느 날 여러분이 구현한 Web 프로젝트의 Veiw 를 JSP 가 아닌 vm (몰라도 됩니다.  저도 몰라요.  다만 웹화면을 구성하는 기술 중 하나라고 들었어요) 이나 velocity (역시 모르셔도... 제가 모르니 여러분도 모르길), Tapestry (모른다니깐요.. ㅡㅡ;) 또는 서블릿(이건 조금 알아요. ^^v), Excel, PDF 등등 다른 View 기술로 교체하기로 했다고 해도 Model 은 전혀 손 댈 필요가 없습니다.  Controller 는 View 를 호출하는 부분만 조금 손 보시면 됩니다.  웹의 View 표현 기술은 정말 어마 어마 어마.. 엄마 놀래라 할 정도로 많습니다.  입맛에 맞게 골라쓰시면 됩니다.  다만 본인의 입맛을 찾기 전에 지칠 수도 있으니.... 물론 Java Web Project 에서는 JSP 가 가장 많이 쓰이고 있긴 합니다.

이렇게 Java Web Project 에 MVC 패턴을 적용한 것을 Sun 에서 Model2 라 지칭했는데요.  이제는 Model2 라는 표현보다는 그냥 Web MVC 라는 표현을 더 많이 쓰니 Model2 라는 표현은 잊으셔도 될 것 같습니다.  그리고 각각의 MVC 구성 요소를 분리하지 않고 Sevlet 하나에 또는 JSP 하나에 MVC 모든 역활을 쑤셔 넣는 방식을 Model1 이라고 합니다.  그런데 사실 Model1 과 Model2 는 같이 발표됐다고 하네요.  뭐 제가 그런 정사에는 별로 아는 게 없으니.. "뭐라 카더라" 정도로 받아들이시면 되겠습니다.  "모델2는 모델1만큼 오래된 역사를 자랑한다" 라는 것만 잘난 체하기 위해 기억해 두시면 되겠네요.

기존 003 강좌에서 우리는 얼떨결에 MVC 패턴을 구현했는데요.  정말 어떨결일까요?  제가 그렇게 허술하게 강좌를 쓰는.. 맞습니다.  ㅡㅜ  저 허술해요.  저도 003 이 MVC 가 될 줄 몰랐어요. ㅡㅜ  그런데 잘 들 따라오셨죠?  여기서 얻을 수 있는 교훈은 MVC 가 어느 날 갑자기 하늘에서 뚝 떨어진게 아니라 홍익인간(java 개발자와 html 코더를 모두 이롭게 하리라)의 정신을 펼치며 작업하다 보니 어떤 패턴이 다수의 프로젝트에서 똑같이 발견되었고 누군가가 그 패턴에 MVC 라는 이름을 붙였다는 걸 아시겠죠(카더라 통신사 제공 - 제가 이름 붙였으면 저도 역사에 남는건데.. 아꿉다).  기술은 결코 뚝 떨어지는 것이 아니라 인간 지향적이라는 걸 다시 확인하실 수 있습니다.  인간은 기술을 개선하고 기술은 다시 사람을 향합니다.  사람을 사랑하면 모든 것이 바뀝니다 New SMS Platoon????  알쥐전자 CF - 인썸니아(Insomnia) 3D TV 기술이 인간을 불면하게 하리라???  S키텔레캅 광고 "[요금명세서는] 사람을 향합니다"???  음음 위 패러디 CF 들이 뭐라건 기술은 결국 사람을 향한다는 거죠... ^^  (이 넘의 기술들 제발 날 좀 내버려 두라고.. ㅡㅜ 스마트폰이 날 감시해요)

003 강좌를 통해서 본 MVC 는 순수 MVC 에 가깝습니다(진정한 순수 MVC 는 책을.. 저는 학문적인 것과 정사에 약하다니깐요).  그런데 여러분은 순수하기만 한게 좋으세요?  순수한 H2O 는 몸에 해롭습니다.  순수하기만 한 사람은 뭔가 또 매력이 없습니다.  우리는 순수 자본주의 세상에 살고 있을까요?  동구권은 순수 공산주의에 성공했나요?  대충 짐작 가시죠.  순수 MVC 는 역시 사람을 향하는 기술 발전을 통해 변질(?)되기 시작하였으니.... 그 절정에 Spring MVC 가 있더라.  결론 Spring MVC 는 순수하지 않다???  뭐 그렇습니다.  무알코올로 시작해서 한해!  지난 3개월 알코올 보충 한번 못하고 있으니 혈중 알코올 농도가 너무 낮아서 강좌가 조금 이상해 지고 있습니다.  제 몸에 흐르는 피는 카페인, 니코틴, 알코올, 예수의 피인데... 알코올이 부족하고, 예수의 피는 ㅡㅡ;  부끄럽네요.

자 그럼 순수 MVC 의 문제점은 뭘까 잠시 생각해 보고 마무리 하겠습니다.

쇼핑몰을 구축하려고 한다고 가정하겠습니다.  순수 MVC 패턴을 따라 만들어 보겠습니다.

고객 관리 해야겠죠. 고객 Model 만들고, 고객 View 만들고, 고객 Controller 만들고...
상품 관리 해야겠죠. 상품 Model 만들고, 상품 View 만들고, 상품 Controller 만들고...
주문 관리 해야겠죠. 주문 Model 만들고, 주문 View 만들고, 주문 Controller 만들고...
배송 관리 해야겠죠. 배송 Model 만들고, 배송 View 만들고, 배송 Controller 만들고...
입고 관리 해야겠죠. 입고 Model 만들고, 입고 View 만들고, 입고 Controller 만들고...
재고 관리 해야겠죠. 재고 Model 만들고, 재고 View 만들고, 재고 Controller 만들고...
통계 관리 해야겠죠. 통계 Model 만들고, 통계 View 만들고, 통계 Controller 만들고...
결제 관리 해야겠죠. 결제 Model 만들고, 결제 View 만들고, 결제 Controller 만들고...
....

고객 Model, 상품 Model, 주문 Model 등등 각각 구현 좋습니다.  각각 관리해야 할 정보가 다름니다.  각각 구현해야 합니다.

고객 View, 상품 View, 주문 View 등등 각각 구현 좋습니다.  각각 보여지는 화면이 달라야 합니다.  각각 구현해야 합니다.

고객 Controller, 상품 Controller, 주문 Controller 등등 각각 구현 좋습니까?.  각각 통제 하는 흐름이 다릅니까?

Contoller 에서 고민이 생기는데요.  기존 코드를 잠시 볼까요.

package com.heaven.spring; import java.io.IOException; import java.util.ArrayList; import java.util.List; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class NeoMemberServlet extends HttpServlet {     @Override     public void doGet(HttpServletRequest req, HttpServletResponse resp)             throws ServletException, IOException {                Member juliet = new Member();         juliet.setName("줄리엣");         juliet.setGender(Member.FEMALE);         juliet.setAge(18);                 Member romeo = new Member();         romeo.setName("놈임요");         romeo.setGender(Member.MALE);         romeo.setAge(19);                 Member seoyoung = new Member();         seoyoung.setName("이서영");         seoyoung.setGender(Member.FEMALE);         seoyoung.setAge(32);                 Member samjae = new Member();         samjae.setName("이삼재");         samjae.setGender(Member.MALE);         samjae.setAge(62);                 // JSP 에 전달할 자료를 준비합니다.         // 여기서는 Member 객체들을 List 에 담고 있습니다.         List<Member> members = new ArrayList<Member>();                 members.add(juliet);         members.add(romeo);         members.add(seoyoung);         members.add(samjae);                         // JSP 에 준비한 자료를 HttpServletRequest 를 통해 저장해 둡니다.         req.setAttribute("members", members);                 // 화면 처리를 위한 JSP 를 선정합니다.         RequestDispatcher view = req.getRequestDispatcher("NeoMember.jsp");                 // JSP 에게 화면 처리를 의뢰합니다.         view.forward(req, resp);            } }

제가 좀 막 만들어서 그렇치 빨갱이들은 결국 Model 로 부터 정보를 가져와 View 로 넘겨줄 자료를 준비하는 부분입니다. 노랭이 부분에서 제가 미래를 내다 봤다면 members 라는 변수명을 쓰지 않고 아마도 model 이라고 하는 변수명을 썼을 겁니다. View 도 ${} 부분 조금만 손봐주면 될 것 같습니다. 파랭이들에서 달라지는 부분은 그 안에  초록이!  결국 View 를 정하는 부분 뿐입니다. 깜장 부분도 눈치채셨겠지만 모든 Controlle 가 천편 일률적입니다. 잠깐 미션: 숨은 보라를 찾아라 결론 빨갱이와 초록이, 보라돌이만 빼면 모든 Controll 들에서 모두 중복 중복 중복!!!  여기서 똑같은 구조가 보이네요.  이런 경우 Spring 3.0 강좌에서 어쩌라구요? 중복되는 부분과 각자 다른 부분을 분리하라!!!  머리 속에 막 전략 패턴이라던가, Template-Callback 패턴이라던가, 상속을 통해 공통 부분은 슈퍼 클래스로, 각자 다른 부분은 서브 클래스로 옮긴다던가, 이런 것들이 막 떠오르시면 저보다 앞서가시는 겁니다.

마구 마구 리팩토링하고 싶은 욕구가 생겨나지 않으십니까?  코드가 냄새 나잖아요.  무슨 냄새 중복의 냄새!!!  Controller 들이 모두 위처럼 구현될 껀데.. 파랭이들은 완전 중복(? 숨은 함정... ^^v) 이네요.  그리고 다들 토비님 책을 보셨?? 보셨다면, 아니 안 보셨어도 SoC (관심사의 분리) 하고 싶고 막막 그러시죠.. 그러실 꺼예요.  ^^  SoC 는 다음 다음 이 다음에 토끼 머리에 뿔날 때 다루도록 하구요.  여러 Controller 들에서 중복되는 코드를 처리하는 방법은 여러 가지가 있겠지만 제가 다음 강좌에서 어떤 방법을 택할 것 같습니까?  그건 이 강좌가 올라가고 있는 카테고리를 보시면 짐작이 되시죠.  Spring MVC 라는 최종 목표로 가기 전에 중간에 들러야 할 곳은 바로 FrontContoller 가 사는 그곳입니다.  SpringMVC 에서 FrontController 는 DispatchServlet 이죠(헉 스포일러 해버렸다).  그럼 다음 강좌에서 뵈어요.

이번 강좌 이거 이거 어쫘지요.  힝~~~ 본래 상품은 첫 상품을 구매하는 것이 아니라면서요.  차도 그 해의 신규 모델은 사는 게 아니라고 하던데... 뭐 제 강좌는 어쩌겠습니다.  조금씩 강좌도 리팩토링 해야지요.  004 강좌 초본 보고 계신 분들만 손해입니다.  그래서 제가 강좌 초반에 005 로 그냥 가시라고...  글과 표현이 이상해도 그냥 주최 측의 농간이다 생각하시고 참으세요.  메롱...

() ()
(^.^)

이번 강좌는 언제가 좋은 아이디어가 생각나면 확 갈아엎어야 겠습니다.  책이나 다른 좋은 강좌를 통해 MVC 패턴에 대해 학습하심을 권고합니다.  권고 기간 4 주 지나고 다시 이혼 법정..  아니 여기 강좌에서... 댓글 달리면 더 빨리 옵니다.

Web MVC 패턴에 관해서는 HFSJ "3장 초 간단 미니 MVC 튜토리얼" 까지 읽으시면, 지난 강좌와 더불어 MVC 까지 그림책으로 보실 수 있습니다.  그리고 90 페이지(초판 5쇄 기준)의 밥 아저씨를 구할 방법도 아실 수 있게 됩니다.  밥 아저씨가 필요했던 해법 바로 FrontController 입니다.

그런데 강좌 제목하고 강좌 내용하고 또 불협화음입니다. ㅡㅡ;

제목은 진정한 분업과 협업이라매...

알았어요.  알았어.  흥분하시기는...

Model - 도메인 모델은 주로 무엇이다?  DB 의 테이블이다.  1:1 또는 1:n, m:1, m:n 으로 POJO 와 DB Table 이 매핑되곤 합니다.  DB 테이블은 누가 만들죠?  DBA.. 결국 모델의 모델(?)이 되는 테이블 설계는 DBA 에게 던져 주세요.  그리고 쉬시다가 테이블 스키마 나오면 스키마를 거의 그대로 Model POJO 로 후딱 만들어 버리면 됩니다.  Eclipse  코드 생성기 이용하세요. ^^/.  DB ERD 달라고 하세요.  ERD 테이블 하나가 메소드만 없는 클래스 정의라고 보시면 80%는 맞습니다.

View - 화면은 누구한테 던져주면 될까요?  지난 시간에 했죠.  HTML 코더에게 던져 주십시요.  그리고 jstl 사용법과 el 사용법 반나절 강의 해주시고,  향후 작업할 때마다 그때 그때 짝프로그래밍으로 조금씩만 검토해 주시면 어느 날부터 HTML 코더도, 개발자인 님도 행복해 지실 겁니다.  아름답거나 멋진 HTML 코더와 사랑에 빠질 수도.... 빠지고 싶은데 제 주변에는 이성 HTML 코더/퍼블리셔가 없어요. ㅡㅜ 군대 같은 회사... 에잇

Controller - 이건 이 글 읽으시는 분, 즉 Java 프로그래머가 머리를 빡세게 혹사하면서 만드셔야죠.  비즈니스 요구를 만족 시킬 수 있도록... (비지니스 요구를 만족 시키는 코드는 Model 에 있어야 되는 것 아니냐 하시는 분도 있을 수 있는데.. 그건 나중에 나중에 변질 MVC 패턴에서 Service 계층을 두는 걸로 합의 보시죠.  합의금은 통장 이체 부탁드립니다.)

이 얼마나 아름다운 DBA, HTML 코더, Java 프로그래머의 분업과 협업입니까?

강좌 내용이 강좌 제목에 이제 부합 되죠??? 후다닥.. 텨텨텨...

제가 튄 이유.. 정말 MVC 가 당신의 삶을 행복하게 해줄까요?

회사에 협조 잘 해주는 DBA 있으세요? 이쁘거나 멋진 HTML 코더 있으세요?

결국 님이 혼자 다 하셔야 하는군요.  한국에는 슈퍼 클래스는 잘 몰라도 슈퍼맨 같은 개발자는 수두룩 합니다.  ㅡㅡ;

MVC 배웠으니 구현한다고 해보죠. 

예전에는 Servlet 에 다 때려 넣습니다. 한시간이면 뭔가 뚝딱 나옵니다. 

좀 전에는 JSP 에 다 때려 넣습니다. 40분이면 뭔가 뚝딱 나옵니다.

MVC 로 했더니 분할하고 파일 3개 관리하고 두 시간(?)이면 뚝딱?

MVC 로 개발하면 개발 속도/생산성은 쭉쭉 떨어집니다.  심지어 프로그램 퍼포먼스도 당신이 눈치채지 못하게 떨어집니다.  불러야 할 파일이 3 배나 많아졌거든요.

그래서 하루면 개발했던 작업이 이제는 이틀이 걸립니다.  여러분이라면 MVC 로 구현하시겠습니까?

정답은?  바로 프로젝트 기간과 그리고 당신의 업무와 관련이 있습니다.

기간 상관성

3개월 미만의 프로젝트라면 굳이 MVC 를 적용하려고 하지 마세요.  학습을 겸한다면 모를까...

3개월 이상이면 적극 도입하십시요.

Model1 기반으로 작업할 때는 하루에 걸리던 일이 MVC 를 도입함으로 이틀 또는 삼일이 되지만, 이게 기간이 늘어나고 늘어나면 잘 분리한 MVC 체계는 당신이 어디를 수정해야 할지 빠르게 파악하는데 도움이 됩니다.  모델1 로 작성된 대형 프로젝트의 유지보수는 정말이지 Welcome to Hell 입니다.

Model1 은 프로젝트 규모가 큰 경우 시간이 지나면 지날수록 냄새를 풍깁니다.  단위 테스트 하기도 힘들고, 어디를 수정해야할지 찾는데 시간 다 보냅니다.

Model2 은 프로젝트 규모가 작을 때 별로 빛을 발하지 않지만 어느 정도 규모가 있는 프로젝트에서 그 진가를 발휘합니다.  유지보수도, 단위테스트도 쉬워지고 문제가 있을 때 어디를 손 봐야 하는지 쉽게 찾을 수 있으며 객체 지향 설계 원칙인 OCP 에도 충실한 코드들 자연스럽게 만들 수 있게 됩니다.

업무 상관성

MVC 는 개발자에게 단기간의 이익을 주는 게 아니라고 바로 위에서 알려드렸습니다.  Model1 과 Model2 중에 Model1 이 사실 개발하기 더 편하다기 보다는 학습과 구현을 빠르게 할 수 있죠.  그러나 여러분이 추후 유지 보수 업무까지 생각하신다면 Model1 으로 구현된 프로그램은 녹녹하지 않습니다.  냄새가 더 나빠질 수도 있습니다.  그리고 더해서 님이 추후 개발도 맞게 된다면 Model2 를 적극 도입하셔야 합니다.

그러고 역사 상 가장 많은 득표를 한 프로그래밍 팁을 알려드립니다.

"당신의 후임자가 역사 상 가장 악랄하고 비열하며 잔인한 연쇄 살인마일지도 모른다.  그러니 보기 좋고 이해하기 좋고 수정하기 좋고 유지 보수 하기 좋은 코드를 만들라."

보기 좋고, 이해하기 좋고, 수정하기 좋고, 유지 보수 하기 좋은 코드는 Model1 일까요? Model2 일까요? 

물론 MVC 를 습득하는 작은 시간을 투자를 해야 하지만.. 여러분은 제 강좌 보시고 2시간 만에 MVC 의 전체적인 구조를 간파하셨잖아요. ^^

기술이 인간을 향한다는 말에 숨어있는 깊은 뜻을 찾는 노력을 해보세요.  Model2,  즉 MVC 가 어떻게 인간을 이롭게 하는지.. ^^

만약 주변에서 Model1 이 Model2 보다 빠른 성능을 내기 때문에 Model1 으로 개발한다는 개인이나 팀이 있으면 이렇게 말해주십시요.  "너(희 팀)는 똥컴 써?"  그리고 잘 개발된 Model2 는 허접하게 개발된 Model1 에 비해 빠르기도 하답니다.  정확한 수치로 보고 싶으시다구요?  그건 학자에게 요구하세요. ^^;

Model2 를 도입했다는 건 Model1 하는 사람보다 더 많이 학습하고 더 많이 고민했다는 의미가 됩니다.  더 많이 학습하고 더 많이 고민했던 사람이 짠 코드는 그렇치 않은 사람이 짠 코드와는 엄청난 격차가 있기 마련입니다.

Model1 하는 분께 String 과 StringBuffer 의 차이를 물어보세요.  여러분은 String 을 절대 남용하지 않으시겠죠. ^^

제가 잘 이어지지 않는 내용으로 이 글을 계속하는 건.. 저의 허접함을 감추기 위한... ^^  에잇 빨리 다음 글로 넘어가야겠네요.  후다닥..

갈 땐 가더라도.. 할렐루야 ^^/

Be happy! Don't worry in the name of Jesus Christ!!!