프레임워크 없는 자바 웹 개발
points
요 몇 년 간은 항상 프레임워크라고 불리는 놈들을 사용해왔습니다. struts 도 썼었고, webwork 도 사용해봤고, wicket 도 관심을 가지고 지켜보고 있습니다. 자체적으로 만든 프레임워크도 있었구요. spring 은 웹 프레임워크는 사용해보지 않았고, dependency injection 용도로만 사용해봤구요. ORM 은 하이버네이트만 사용해봤네요. 뷰 용도로 jsp 대신에 velocity 를 사용해본 적도 있었습니다. 어쨌거나.
그러다가 간단한 프로젝트 하나를 이런 저런 프레임워크 없이 jsp 2.0 과 서블릿만 가지고 해봤습니다. 있다고만 알고 있었고 실제로 써본적은 없었던 sql 태그를 사용했고, 커스텀 태그 라이브러리 대신에 jsp tag file 을 많이 활용했습니다. 자바 코드가 많이 들어가는 부분들은 가능한 한 추상화해서 jsp tag file 로 만들어 사용했습니다. .java 파일은 가능한 한 적게 만드려고 노력했구요.
허어.. 이거 일하는 스트레스가 확~ 줄어든 느낌입니다. 프레임워크를 사용하는 경우와 그렇지 않은 경우를 구체적으로 비교해볼만한 지표같은 것을 만들어보지는 못했지만, 적어도 "체감상" 개발 기간도 줄어든 것 같고, 뭐랄까 훨씬 직관적인 개발을 할 수 있다는 느낌이 들었습니다. 생각해야할 것이 줄어들었다는 느낌? 뭐 그런건데 뭐라고 표현해야할 지 모르겠군요. 이 프로젝트에 전혀 관여하지 않았던 사람에게 보수를 부탁했는데, 고치는 사람 입장에서도 훨씬 편했다고 하더군요. 그리고 jsp tag file 만 좀 신경써서 체계적으로 만들어 놓으면, 웬만한 규모(? 애매하지만..)의 프로젝트는 문제없겠다는 생각도 들었습니다.
어쩌면 그동안 지나치게 프레임워크를 고집했던 것은 아닌가하는 생각이 듭니다. 무수히 많은 (자바) 프레임워크들... 실제로 편리한 걸까요? 얼마나 복잡하고 덩치가 큰 프로젝트면 이런 놈들이 진가를 발휘할까요?
-- 덧붙임 --
자바 웹 프레임워크들을 사용하는 이유 중에 하나가 MVC(2) 를 (반)강제적으로 구분하도록 하는 것이지요. 프레임워크가 전체적인 제어 흐름을 관장하고 프로그래머는 M,V,C 를 구현해서 일종의 플러그인처럼 그 흐름에 끼워 넣는 방식이지요. 그런데 이번에는 그것도 버려봤습니다. 제어 흐름은 아주 단순합니다. 요청 -> 간단한 필터 몇 개 -> 요청한 JSP 페이지 -> 브라우저 입니다. MVC 도 딱히 구분해서 생각하지 않았구요. 다만 하는 일이 다른 코드는 서로 다른 파일에 담는다는 원칙만 지키려고 했습니다. JSP 사이의 forward, redirect, include 를 적절히 사용해서 분리된 파일 사이에 흐름을 조정했구요.
points
소잡는 칼이냐? 닭잡는 칼이냐?
그것에 대한 정답은 없는것 같습니다. 사이트의 규모는 항상 변하는것 같습니다.
제가 나름대로 내린 결론은 개발에 참여하는 인력의 수준? 관심도에 따라서 결정하는게 좋지만 갑이 결정한다.
프레임워크란 이름이 들어가면 일단 잘 모르는 사람들한테(갑 or 의사결정하시는 비개발자) 좋게 보여서 더 높은 값을 받기가 편해집니다.
저만의 생각이었는지 모르겠습니다만 결론은 상황마다 다르다.
points
프레임워크와 개발 생산성 문제
프레임워크를 썼는데 개발자의 부담이 증가하고
유지보수가 어렵고 하면 프레임워크를 써야 할 이유가 없지 않을까요?
그리고 아무리 남들이 좋다고 해도 스팩과 장단점에 대한 분석도 없이
가져다 쓰는 것은 개발에 대한 철학이 부족하다고 생각되네요.
저 같은 경우에는
1. 사전에 확립된 표준에 맞춰서 검증한다.
1) 범용성
다양한 프로젝트에 적용가능
2) 안정성
다양한 플렛폼에서 검증(Windows, Linux, SUN, HP, AIX등등)
3) 개발 및 유지 보수의 편의성 등등
예를 들어 tree, grid, map을 한 화면에 표시하는 UI가 있고 tightly coupled방법론을 지향한다면
function processResponse(dataFromService)
{
ui.setData(new MultiDataSet(dataFromService)); //set data of all object so that it can render it
}
이렇게 한줄로 코딩이 끝나도록, 사실 더 이상의 불필요한 코딩이 있을 이유가 없지요(그건 코딩이 아니라 노가다일 뿐...)
2. reference
얼마나 많은 확실한 적용사례를 갖고 있는가.
3. 미래지향성
지금 아무리 좋다고 하더라도 한 5년 후에 무용지물이 될 것이라고 예측되면 못 쓰겠죠?
points
--__--
솔직히 유지 보수하기가 힘들다면..
프레임 워크를 쓰는 이유를 찾기는 힘들꺼 같은데요..
물런 유지 보수하시는 분이 그 프레임 워크에 대해 잘 모르신다면..
그것도 문제고요..
구지 프레임워크가 아니더래도..
내가 어떤 패턴을 이용해서 클래스를 작성했는데..
그 패턴이 뭔지 모르는 사람이 보면 더 햇깔릴수도 있는거랑 비슷 한것도 같고요..
제가 생각하는 프레임워크의 사용 이유는 사후 유지 보수의 효율성에 더 좋치 않을 까 합니다..
일정한 패턴이 강요 되기 때문에 그에 맞추어서 작성된 프로그램이라 한다면..
유지보수 하는데 그리 많은 시간이 들지 않을 꺼니까요..
개발시에는 뭐 오히려 더 불편할수도 있을꺼 같고요..
문제는 프레임워크의 패턴도 무시하는 일부.. private 화된 소스 가 되겠죠..
============================================================
선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-
============================================================
points
학원에서 갓 마치고
학원에서 갓 마치고 들어온 신입사원에게는 추상이니 뭐니 코딩이 어떻니 가르치는 것보다 프레임웍을 보여주고 A, B, C, D, E를 차례대로 만들면 된다고 하는 것이 일하기 더 편합니다.
유지보수(나 아닌 누군가가) 하는 입장에서도 공통된 프레임웍이 있다면 A, B, C, D, E를 차례대로 살펴보고 해당되는 부분을 수정하면 되는겁니다.
잘하는 전문가라면 범용 프레임웍이 오버헤드가 될 수 있지만, 잘 못하는 사람과 같이 일할 때 전문가의 잣대로만 진행을 한다면 전체적인 프로젝트의 생산성은 떨어질지도 모릅니다.
------------------------------
How many legs does a dog have?
points
잘 못하는 사람과
제 경험으로는 생산성이 떨어지더군요.
물론 경험이 모든걸 다 말해준다는 이야긴 아닙니다.
봄들판에서다
points
"간단한 프로젝트 하나"니까요.
"간단한 프로젝트 하나"에서 Struts 2 + Spring + Hibernate 를 사용하는건 당연이 오버헤드가 심합니다.
그리고 제가보기엔 솔직히 말하면 그런 프로젝트에서 Java를 사용한다는 것 자체도 오버헤드가 심한겁니다.
그런경우에 최대 생산성을 내는것은 PHP 일텐데요.
앞서 다른분도 말씀하셨지만, 규모가 커지기 시작하는데 프레임워크 없으면 삽질과, 코드 중복이 장난이 아닙니다.
그렇다고, 그런 코드 중복을 없애는 코딩을 시작하면, 바로 그것 자체가 해당 프로젝트를 위한 새로운 프레임워크가 되어버리게 됩니다. 새로 만드느닌 차라리 기존에 검증받은 것을 사용하는게 낫겠죠?
오히려 프레임워크의 반복적인 패턴을 신입에게 알려주고, 어려운 부분을 사수들이 컨트롤하면 더 쉽게, 유지보수성 높게 개발이 가능해진다고 생각합니다.
당연한 얘기지만 프레임워크를 사용하면 개발 초기 생산성은 매우 떨어집니다. 설정할게 너무 많아서. 하지만 일단 설정이 끝난 후부터, 유지보수를 생각할 때, 프레임워크가 진가를 발휘합니다.
http://kwon37xi.egloos.com
points
매우 공감가는 글이네요.
그런데, 뭐라할까
언제나 개발내역에 꼭맞는 프레임워크는 없더라구요. -_-
프레임워크에 맞춰 개발내역이 수정되는 이상한 현상이...
결국 업무분석시 인터뷰과정에서 얻은 요구사항이 수용되지 않고
오히려 사용자들에게 프레임워크에 맞는 사용방법이나 혹은 업무패턴 변화를 요구하게 되는
불상사도 심심하지 않게 생기게 되더군요. ㅋㅋㅋㅋ
There is no spoon. Neo from the Matrix 1999.
points
프레임워크는
프레임워크는 프레임워크일 뿐입니다.
struts 를 쓰든, spring 을 쓰든, iBatis 를 쓰든, hibernate 를 쓰든...
필요한 만큼만 쓰면 됩니다.
java 로 하다가...이부분은...아무래도 이 프레임워크의 기능을 일부 도입해서 쓰면 더 좋을 것이다...하는 것을 판단해서 사용하면 되겠죠.
일례를 들면...
기본적으로 struts 에서 제공하는 tld 가 3 개 있는데, html, logic, bean 입니다.
그런데 개인적으로 html 은 사용하지 않습니다.
웹디자이너들이 html 태그에 대해서 잘 알고 있는데 굳이 [input] 등을 대체하기 위해서 [html: ... 어쩌구저쩌구를 써버리면
더 헷갈릴 수 있다는 거죠.
struts 의 validate 나 tiles, spring 의 DI 나 AOP 도 굳이 필요없는데 억지로 끼워넣을 필요없겠죠.
DB 교체를 할 가능성이 거의 0% 인 곳에서(예를 들면 자사의 사이트 구축) 억지로 DAO 를 넣거나...할 필요가 전무할 것이고,
DBA 가 있는 환경에서 굳이 hibernate 를 이용해서 구성해버리면 DBA 가 쿼리 튜닝할 여지를 많이 줄어들어...오히려 안쓰는 것만 못하게 되겠죠.
결국 프레임워크는 프레임워크라고 생각합니다.
어떤 구조를 잡기위한 하나의 도구이지, 그 이상의 정책이나 구조가 되어서는 안된다고 봅니다.
points
저의 경우와는 다르네요...
저같은 경우에는 기본적인 html 코드 태그만 제외하고는 전부 JSTL을 사용하려고 하고 있습니다.(같이 개발하시는 분들의 양해가 있다면요)
스트럿츠 태그가 jstl보다 먼저 등장했다보니 JSTL과 중복되는 기능도 많고, View단이 스트럿츠와 강하게 결합되는것 같아서 보기가 좋지 않아서 나머지 태그들은 사용하지 않는편입니다.
하지만 html 태그들은 어쩔수 없이 사용할수 밖에 없는게, Form의 Validation이 실패했을경우나 수정모드에서 Form을 재활용해야 하기 때문입니다.
굳이 html을 대체하기위하여 스트럿츠의 html태그를 사용할 필요는 없겠죠.
points
약간의 오해가
약간의 오해가 있으신 것 같은데...
struts 의 tld 를 이용한다는 것은...한 예일 뿐입니다.
tld 3종이 있는데 모두 사용하는 것이 능사가 아니다...라는 것이죠.
어짜피 값을 출력하기 위해서는 logic 과 bean 은 사용할 수 밖에 없지만 html 은 프로그래머 입장에서는 몰라도 디자이너 입장에서는 재교육이 필요한만큼 꼭 쓸 필요가 있겠냐는 의미이구요.
이 내용을 가지고 struts 를 써야한다고 확대 해석하시면...-_-;;; 쬐금 난감해지네요.
view 를 보여주기 위해 struts 의 tld, velocity, EL, jstl 등을 사용해봤지만 현재 익숙해진게 struts 의 tld 라서 그 예를 든 것일 뿐입니다.
jsp 는 쓰기 싫은데...두 개체 간의 비교를 위해서 struts 의 tld 로는 이게 안되므로 EL 을 쓰곤 합니다만...그래선 안되는 것도 아니니...자기가 원하는 대로 쓰면 될 것이구요...
개인적으로 Velocity 는 null 처리를 못하는 것 때문에 골때려서 사용을 자제하고 있고, jstl 은 Sun 꺼라서 싫어합니다.
(왜 개인적으로 Sun 은 정이 안갈까요 -_-;;; apache, eclipse, ibm... 등을 좋아합니다)
곧 struts 가 아닌 spring 을 이용해볼 건데...뭘로 view 단을 처리할지 고민 좀 해봐야겠습니다. struts 1 과 spring 을 연동하고 싶진 않아서...
(T.T struts 의 formbean 의 편리함을 어떻게 대체하란 말인지...)
points
요새 프레임워크가 너무 많아
저같이 웹쪽으로는 실무 프로젝트를 할 기회가 없었던 사람은 이름들조차 생소할 지경입니다.
프레임워크도 많지만 각 프레임워크 내에서도 개발 방식이 다양하다보니 당최 뭔지...
그래서 말인데 이런걸 구구절절히 설명한 책보다는 차라리 그냥 이런게 있고 이게 이런거다만
소개한 그런 책이나 자료가 있었음 좋겠네요. 혹시 아시는 좋은 자료 있으시면 추천 구걸.
points
제가 언급한
제가 언급한 프레임웍이 4개인 것 같은데요...
struts, spring, iBatis, hibernate...
모두 찾아보시면 어떤 것이다...라고 아시겠지만...
struts 는 현재 apache 프로젝트에 서브 프로젝트로 들어갔고 버젼 1과 버젼 2로 나누어져있습니다. 버젼 2는 webwork 라는 프레임워크를 기반으로 완전 다른 코드로 만들어져 1 과는 호환성 없구요.
MVC 구현을 위한 것입니다. 말 그대로 웹쪽에서 요청이 들어오면 그걸 분석해서 처리한 다음 결과를 뿌려줄 페이지로 값을 넘겨주는 역화를 하죠.
이 때 뿌려줄 페이지는 jsp 로 만들어서 struts 에서 제공하는 tld 를 이용해 값을 뿌리든, jsp 에서 out.print 로 그냥 뿌리든, jstl 로 뿌리든 상관 없구요.
아니면 velocity 의 vm 으로 페이지를 만들어서 출력해도 됩니다.(xslt parser 인 xaran 을 생각하시면 쉬울 듯)
spring은 거의 모든 영역에서 사용할 수 있는 프레임워크로...웹 뿐만 아니라 모든 영역에서 사용가능합니다. MVC, DAO, DI, AOP...무수히 많군요. 게다가 다른 프레임워크와의 결합도 지원합니다.
iBatis 와 hibernate 는 DB 와의 연동을 위한 프레임워크입니다. Web 와는 상관없구요.
iBatis 는 간편하고 쉽고...쿼리를 XML 로 따로 작성해서 사용합니다.
hibernate 는 DB 를 개체로 연결해서 java 에서 개체의 데이터를 쪼물딱 거리면 DB 에 자동 반영이 되는 겁니다. 대충 그렇다고 생각하시면 됩니다.
그 외에도 많은 프레임워크가 있지만...국내에서 많이 쓰는건 대충 이정도가 아닐까 합니다.
points
제가 언급한
삭제가 어디있는지 몰라서...-_-; 지우질 못하겠네요.
points
제가 경험에 의하면
제가 경험에 의하면 프레임워크를 쓰는 이유의 하나는 그어떤 고급의 코드기술보다는 추가적인 요구사항에 대처하자는 것이라고 생각합니다.
그리고 프레임워크에 대해서 저도 지금 개발중인데 최근에는 어떤 방식이 가장 괜찮은 방식인지 구걸....
전 spring + hibernate + tapstry를 쓰고 있어요
points
이미 괜찮은 조합을
이미 괜찮은 조합을 이용하고 계신 것 아닌가요? ^^;;;
개인적으로 spring 은 설정 파일이 좀 복잡해서 잘 안쓰게 되긴 하지만, 기능이 워낙 많고 다양하며 막강해서...^^;;;
hibernate 의 경우...전 Query 작성에 굉장히 부담도 없고 오라클 튜닝을 주업으로 하는 친구의 도움을 쉽게 받을 수 있어서
hibernate 보다는 iBatis 를 쓰긴 합니다만...iBatis 3 가 나오기 전까진 j2se 5 이상에서의 Warning 문제 때문에 약간 걸리기도 하고...
DB 쪽을 전혀 몰라도 된다는 걸 강조하고 싶거나 SQL 작성에 부담을 느끼는 개발자를 데리고 있다면 hibernate 는 좋은 선택이라고 봅니다.
tapstry 는...뭔지 모르겠네요. ^^;;;
결론은...좋은걸 이미 쓰고 계시네요. ^^;;;
points
Framework 은 Tool 일 뿐이죠.
필요하면 쓰는 것이고, 필요없다면 안쓰면 되고.... 아.. 무슨 회사 광고 카피 같군. 쩝.
대규모 프로젝트일 경우, Framework 은 거의 필수가 되는데, 그 이유는 여러가지입니다.
그건 낱낱히 설명안해도 아시겠죠.
===================================================
Make it Simple, Easy, Compact !!!!
points
하향평준화를 위한게 프레임웍이지 않을까합니다.
윗 댓글에도 여러번 업급되었지만.. 수십명이 동시에 진행하는 프로젝트에는 경력차 분포가 심합니다.
경험이 많은 개발자는 프레임웍 없이도 스스로 체득한 방법으로 잘 코딩합니다.
하지만 초짜가 보기엔 넘 어렵고, 그 의도를 정확히 알수있을만한 잘 정리된 문서가 없으니...
그냥 막 코딩하게 되는일이 발생하죠..
암튼.. 표준적인 방법으로 인해 동일한 방식으로 코딩하게 만들어서 운영인력이 바뀌어도
룰은 변하지 않으니 유지보수에 아주 유용하겠죠..
결국 패턴의 덩어리인 프레임웍은 책에 나온 그대로입니다.
혼자 개발하고 혼자 관리하는 프로그램이나 간단한 프로그램 정도를 프레임웍을 쓴다면
닭잡는데 소잡는칼 쓰는격으로 적재적소에 알맞게 사용하면 그만이라고 생각합니다.
대신 프레임웍이나 패턴을 만든사람들이 어떤 걸 고민하다가 어떤 의도로 만들었는지 이해하고 쓰면
프레임웍을 쓰면서 학습도 하는 좋은 계기도 될 수 있을거란 생각을 합니다.