구글 애드센스가 영문에 맞는 광고는 잘 가져오는지 테스트 하기 위해 한글 단어들을 영문으로 수정....
IT블로그를 살펴보면 Struts, Spring, Hibernate등으로 대표되는 Open Source Java framework을 사용하여 web program을 개발하는것에 대해 부정적으로 생각하는 개발자들이 많은것 같다. 사실 단순한 CRUD web program을 개발하는데 이런 framework을 사용하는건 오버킬이 맞다.
시스템의 규모가 일정 수준 이상 커지면 framework이 개발, 유지/보수 생산성에 도움이 된다고 말들을 하는데, 체험들을 못해봐서 별로 공감을 하지 못하는듯한 느낌이 든다.
그럼 도대체 얼마나 큰 시스템을 다루는 경우에 프레임웍의 혜택이 느껴질것인가? 사실 나도 명확히 선을 그어 말하기가 어렵다. 내가 만지고 있는 시스템의 경우 프레임웍이 도움이 된다는 정도는 말해줄수 있을뿐이다.
현재 내가 만지고 있는 시스템은 98년에 첫 버전이 개발되었으니 거의 10년 묵은 시스템이다. 테이블의 갯수는 4자리수이고 전체 class file의 갯수는 여섯 자리수에 근접한다. 연관되어 있는 엔지니어는 한 50~100명 사이일것 같다. component 갯수가 50개 정도 될 것 같다. 이런걸 framework 없이 개발자에게 맡겨놓으면 구현이 중구난방이 된다. 이런 규모의 시스템을 일관성있게 구현하기 위해서 framework은 필수 불가결하다.
그럼 어떤 framework을 쓰는가? Struts, Spring, Hibernate 하나도 안쓴다. 모든 framework은 내부에서 개발된 것이다. Gavin King이 Hibernate 프로젝트 시작도 하기전에 개발 완료된 OR engine을 쓰고, JSP 1.0이 구현이 되기도 전에 JSF나 Tapestry스타일의 component based UI framework을 개발해서 썼다. 사실 component based UI framework은 90년대 중반에 벌써 Nextstep이 WebObject란걸 만들어 썼는데, 이거 만들었던 사람이 와서 만든것이다. Apple 에서 web program램 만드는 사람은 아마 알 것이다.
이 framework를 써서 productivity가 어떻게 높아지는가 알아보자.
상품 catalog를 관리하기 위해 상품의 이름과 가격등을 입,출력,검색하는 UI가 필요하다.
상품 검색 UI는 주문을 입력하는 화면에서도 필요하고, 송장이나 지불을 처리하는 화면에서도 필요하고, 웹 사용자 카탈로그 검색 화면에도 필요하다.
이제 이 상품 class에 새로운 필드가 하나 추가되어야 한다고 예를 들어보자.
이 framework를 사용하면 상품 metadata file에 새로운 field하나 넣는걸로 일이 끝난다.
Database table column을 추가할 필요도 없고, 위에 나열한 screen들을 다 수정할 필요도 없다.
Metadata는 XML text file이므로 일반 version control system을 통해 언제 뭐가 바뀌었는지 알 수 있고 다시 이전 version으로 돌아갈수도 있다.
System을 serious하게 개발 유지하는 회사는 Open source framework을 가져와서 productivity가 높아지게 자기들이 직접 개선을 하거나 아니면 돈 주고 사거나 알아서 할 일이다.
Java web framework이 너무 많이 나온다고 불평들이 많은데 그건 당연한 거다. 주로 개발자 한명이 자기가 web application 시스템 만들어 보니까 틀을 이렇게 가져가면 편리하고 생산성도 높아지겠더라고 생각해서 쉬는 시간에 열심히 만들어서 그거 가지고 project 들어가서 consulting도 하고 돈도 좀 벌어보겠다고 내놓는 것이다.
나오는 framework마다 배우느라고 정신없다고 불평할게 아니라, 본인이 web application을 만들어보니까 이런식으로 틀을 만들어야 겠다는 아이디어를 가져야되고, 다른 넘이 이미 나하고 비슷한 생각을 가지고 만든게 있으면 그거 가져다가 개선하면 되는것이다.
그런 역량이 안되면 유명한거 찍어서 source code 보고 열심히 배우는 수밖에 없다.
만약 framework이 필요하지 않는 수준의 시스템이어서 framework을 사용하는게 시간도 더 걸리고 유지보수도 더 어렵다고 가정하더라도, 그걸 왜 파견나간 개발자가 걱정하나? 어차피 돈 받고 일하는데, 그 기간동안 하나라도 더 배우는 기회로 활용하면 되는것이다.
IT블로그를 살펴보면 Struts, Spring, Hibernate등으로 대표되는 Open Source Java framework을 사용하여 web program을 개발하는것에 대해 부정적으로 생각하는 개발자들이 많은것 같다. 사실 단순한 CRUD web program을 개발하는데 이런 framework을 사용하는건 오버킬이 맞다.
시스템의 규모가 일정 수준 이상 커지면 framework이 개발, 유지/보수 생산성에 도움이 된다고 말들을 하는데, 체험들을 못해봐서 별로 공감을 하지 못하는듯한 느낌이 든다.
그럼 도대체 얼마나 큰 시스템을 다루는 경우에 프레임웍의 혜택이 느껴질것인가? 사실 나도 명확히 선을 그어 말하기가 어렵다. 내가 만지고 있는 시스템의 경우 프레임웍이 도움이 된다는 정도는 말해줄수 있을뿐이다.
현재 내가 만지고 있는 시스템은 98년에 첫 버전이 개발되었으니 거의 10년 묵은 시스템이다. 테이블의 갯수는 4자리수이고 전체 class file의 갯수는 여섯 자리수에 근접한다. 연관되어 있는 엔지니어는 한 50~100명 사이일것 같다. component 갯수가 50개 정도 될 것 같다. 이런걸 framework 없이 개발자에게 맡겨놓으면 구현이 중구난방이 된다. 이런 규모의 시스템을 일관성있게 구현하기 위해서 framework은 필수 불가결하다.
그럼 어떤 framework을 쓰는가? Struts, Spring, Hibernate 하나도 안쓴다. 모든 framework은 내부에서 개발된 것이다. Gavin King이 Hibernate 프로젝트 시작도 하기전에 개발 완료된 OR engine을 쓰고, JSP 1.0이 구현이 되기도 전에 JSF나 Tapestry스타일의 component based UI framework을 개발해서 썼다. 사실 component based UI framework은 90년대 중반에 벌써 Nextstep이 WebObject란걸 만들어 썼는데, 이거 만들었던 사람이 와서 만든것이다. Apple 에서 web program램 만드는 사람은 아마 알 것이다.
이 framework를 써서 productivity가 어떻게 높아지는가 알아보자.
상품 catalog를 관리하기 위해 상품의 이름과 가격등을 입,출력,검색하는 UI가 필요하다.
상품 검색 UI는 주문을 입력하는 화면에서도 필요하고, 송장이나 지불을 처리하는 화면에서도 필요하고, 웹 사용자 카탈로그 검색 화면에도 필요하다.
이제 이 상품 class에 새로운 필드가 하나 추가되어야 한다고 예를 들어보자.
이 framework를 사용하면 상품 metadata file에 새로운 field하나 넣는걸로 일이 끝난다.
Database table column을 추가할 필요도 없고, 위에 나열한 screen들을 다 수정할 필요도 없다.
Metadata는 XML text file이므로 일반 version control system을 통해 언제 뭐가 바뀌었는지 알 수 있고 다시 이전 version으로 돌아갈수도 있다.
System을 serious하게 개발 유지하는 회사는 Open source framework을 가져와서 productivity가 높아지게 자기들이 직접 개선을 하거나 아니면 돈 주고 사거나 알아서 할 일이다.
Java web framework이 너무 많이 나온다고 불평들이 많은데 그건 당연한 거다. 주로 개발자 한명이 자기가 web application 시스템 만들어 보니까 틀을 이렇게 가져가면 편리하고 생산성도 높아지겠더라고 생각해서 쉬는 시간에 열심히 만들어서 그거 가지고 project 들어가서 consulting도 하고 돈도 좀 벌어보겠다고 내놓는 것이다.
나오는 framework마다 배우느라고 정신없다고 불평할게 아니라, 본인이 web application을 만들어보니까 이런식으로 틀을 만들어야 겠다는 아이디어를 가져야되고, 다른 넘이 이미 나하고 비슷한 생각을 가지고 만든게 있으면 그거 가져다가 개선하면 되는것이다.
그런 역량이 안되면 유명한거 찍어서 source code 보고 열심히 배우는 수밖에 없다.
만약 framework이 필요하지 않는 수준의 시스템이어서 framework을 사용하는게 시간도 더 걸리고 유지보수도 더 어렵다고 가정하더라도, 그걸 왜 파견나간 개발자가 걱정하나? 어차피 돈 받고 일하는데, 그 기간동안 하나라도 더 배우는 기회로 활용하면 되는것이다.
'잡소리' 카테고리의 다른 글
| 구글 신택스 하이라이터 테스트 (0) | 2007/12/20 |
|---|---|
| 2007년 업무 끝 (0) | 2007/12/19 |
| Java framework에 대해서 (2) | 2007/12/18 |
| 한국 블로그스피어 유감 (0) | 2007/12/17 |
| 새로 나온책: Implementation Patterns (0) | 2007/12/16 |
| 페이퍼 아키텍트 (0) | 2007/12/16 |
댓글을 달아 주세요
저도 얼마전에 관련글을 읽고 잠시 생각을 하게 되었던거 같습니다만, '겪어보지 못한 것에 대한 필요성을 느끼지 못한것이 아닌가..' 라고 결론을 짓고 말았던 기억이 있네요. :-)
여담이지만, 저는 지금 모 금융기관의 차세대 시스템 개발을 하고 있는데, 소요기간이 2년정도 지난 시점이고 투입된 개발자 네자리수, 사용된 테이블 네자리수 입니다.
이정도 시스템을 프레임워크의 도움 없이 전체적인 구조를 잡고 개발을 한다는것은 국내 개발 환경의 여건상 거의 자살행위가 아닐까요?
마지막 문단의 말씀이 가장 와 닫는거 같네요. :-)
그정도 규모 시스템이면 일개 웹 프레임웍을 넘어서서 어떤 형태든 플랫폼이 있어야하는게 당연합니다. 보통 UI, persistence, messaging, integration, workflow, rule engine, report engine, monitoring, log, alert, security, clustering, test harness등 비즈니스 어플리케이션코드가 필요로 하는 하부 소프트웨어를 통칭해서 플랫폼이라고 부릅니다.
개발자 천명 이상 2년간 지속적으로 투입이라면 엄청난 물량입니다. 개발인력 투입양만으로 본다면 시벨, 피플소프트, 세일즈포스닷컴 같은 엔터프라이즈 어플리케이션 패키지 소프트웨어 몇개는 나올수 있는 투자수준 같습니다.
대개 금융권 차세대 시스템이란 소리를 몇년마다 한번씩 듣는것 같은데 이런 주기적인 대규모 시스템 개발을 필요로 하는 요인이 무엇인지 궁금하더군요. 사업 환경이 정말 그렇게 몇년마다 변하는지, 아니면 단지 기술 변화때문에 그렇게 대공사를 하는지...