새롭게 마음도 다잡고, 정리도 할겸해서 개발환경을 새롭게 구성하기로 마음먹고 진행 중이다.
여기서 말하는 통합 개발환경이라는 것은 프레임워크, 개발툴, 관련서버, DB, 개발언어, 형상관리,
리팩토링, 테스트, 문서화, 레포팅, 모니터링 등등.. 모든 것을 다 포함한 개념이다.
개발이 단순 노다성을 벗어나며 프레임워크나 패턴의 사용에 따른 설계 및 코딩능력을 중요시 되던
시기가 있었지만, 이는 개발자의 능력과 사상에 따라 팀을 이루어 개발시에 오히려 문제를 일으키는
요소로까지 작용하였고, 그러한 부분은 여러 툴들이 기능을 향상함에 따라 어느정도 보안해기 시작했지만,
적지 않은 가격과 시간이 흐르며 툴에 종속적으로 그 모양새가 변모 되어갔다.
(그래서 한때는 특정 툴에서 개발 잘하던 개발자가 다른 툴에서는 어찌할 바를 모르는 웃지 못할 상황까지
생기기도 했었다.)
이러한 변화의 흐름속에 묻혀 생활하면서 얻은 결론은
시대에서 최고라 칭하는 프레임워크만을 잘한다고, 최고의 기능을 제공한다는 툴을 잘 다루는 것으로,
궁극적으로 원하는 단기간에 최고의 결과물을 내놓기가 어렵다는 것이였다.
결국, 이 모든 것과 그 이외에도 개발에서 사용되어야하는 모든 것들이 함께 잘 어울려져야만 해야만 했고,
또한 이것은 대중적(또는 범용적)인 환경을 제공해야 된다는 것이다.
(아무리 좋은 것도 프로젝트 시마다 새롭게 가르쳐야하고 배워야하는 것이라면, 이는 장점보다
단점이 더 많은 것이다.)
여러 과정과 시행착오, 경험들은 뒤로하고, 그래서 구성할 수 있는 최고의 조합이 현재로써는
eclipse과 springframework을 기반으로 한 통합 개발환경이다. (그 외 다양한 오픈소스들과...)
이 새부적인 내용에 대해서는 생각하는 환경이 구축되어감에 이곳을 통해 조금씩 정리해볼까 한다.
통합환경은 크게 이렇다고 하더라도, 새부적인 부분에 있어서도 이슈들이 상당히 많다.
우선 가장 핵심이되는 프레임워크 차원에서의 spring 의 쓰임새는 이를 사용해본 사람이라면
공감하겠지만, 사용하는 사람의 사상과 설계 방식에 따라서 완전히 달리할 수 있다는 것이다.
이전의 수많은 프레임워크라는 것을 접하고 하면서 지금의 struts나 spring을 바라보는 관점은
일반일들에 비해 나는 좀 달리하고 있고, 사용방식은 조금은 특이하다. (최소한 이러한 방식 또는
관점을 이야기하는 것을 듣고 보지 못했기에.. )
특히나, 웹기반에 있어서의 도메인 객체를 모델링하는 것은, 객체지향이라는 자바의 태생(!)에도
불구하고 이러한 설계를 상당히 싫어함을 넘어 Anti- 로까지 생각을 한다.
core J2EE Pattens에서 이야기하는 VO(Value Object), 최근에는 DTO(Data Transfer Object),
hibernat에서는 domain model 등.. 으로 이야기하는 그 모든 것들이 이 대상이 될 수 있다.
EJB가 툴에서 자동생성해 주는 것이 나오기전의 노가다로 일일이 작성하며, 초기 EJB 기반으로의
프로젝트를 진행해 본 사람이라면, 지금에 이야기하는 DTO나 DAO가 왜 필요한지, 그리고
자신도 모르는 사이 그러한 것을 구현한 것을 알 것이다.
하지만, 그렇게 구현한 DTO(VO)는 결국엔 고객의 무수한 요구사항 수정덕에 이렇게 설계 스스로에
대해, "왜 이렇게 설계한 것일까? 아니야 고객의 잘못이야? 아니지 이러한 수정요구까지 반영 못한
것이 잘못이지"라 떠들며 자학 또한 해보았을 것이다.
그러면서 편법으로 구현빈 내에 쿼리를 집어 넣지 않고 할 수 있는 방법과 파라메터들을 좀 더 유연하고
정형화해서 쓸 수 있는 방법들을 찾으며, 나름대로의 패턴과 프레임워크들을 만들어 보았으리라
생각한다.
이러한 것이 struts의 등장으로 사람들이 다시 우르르 이동과 함께 박수를 보내기 시작했다.
(struts가 EJB 대안이나 그렇다는 이야기는 분명아니다, 많은 이들에게 고민이 많던 시기에
등장했다는 것을 말하려는 것이다.)
나 또한 struts를 여러 프로젝트에서 감사의 마음(!)과 찹찹한 마음(그간만들었던 여러
MVC기반의 나만의 프레임워크가 날아간 순간)으로 잘(!) 사용하였다.
하지만, 개인적으로 사용을 좀 달리해서 사용하였다.
내가 사용하는 Action Mapping 은 프로젝트 많아야 3~5개 정도로 국한 시키는 방식이였고,
ActionForm 또한 사용하지 않는 방식이였다.
(프레임워크는 그대로 적용해야지, 프레임워크의 프레임워크를 만들면 안되다는 이야기 또한
있지만, 난 후자의 방식을 좋아하고 그것이 옳다고 믿는 사람이다.)
대규모 프로젝트의 Action Mapping을 모든 화면의 Action마다 만들어서는 오히려 감당히
어려웠기에 공통의 호출과 그에 따른 리턴 방식을 공통화 시키고, 웹기반에서 주로 사용하는
다운로드, 엑셀변환, pdf 추출, 프린터등등을 별도의 모듈로 만들어 이를 Rule 기반으로 호출시에
이렇나 기능들이 동시에 처리되어 결과로 뿌려줄 수 있게 설계하였기에 이런 것이 가능하였다.
ActionForm을 사용하지 않았던 것은 앞선 EJB를 사용하면서 느꼈던 VO(DTO, DAO)를 별도로 생성해서
개발을 하는 것에 대한 불신(!) 때문이다. 이는 EJB의 비즈니스 로직의 변경보다 화면의 변경이슈가
더 많은 상황에서 화면상의 파라메터와 DTO 간의 종속성(나는 이렇게 표현한다)은 웹개발에 있어서
생산성을 현격히 저하 시킨다고 믿기 때문이다.
(여러 툴에서 이를 해소해 준다고는 하지만, 툴에 지나치게 종속적을 되는 것 또한 옳지 않다고 생각
하기도 하기에... )
이는 최근에 이슈가 되고 있는 DTO와 도메인 모델의 사용에 어느 것이 좋니, 나쁘니 하는 것에 있어
개인적으로는 둘 다 웹개발 생산성에 도움이 되지 않는다는 것으로도 이야기하는 것이다.
(이렇기에 사상적으로 많이 틀리다고 스스로 인정하는 부분이다.)
이러한 논리는 View단과 Controller단의 Layer을 어떻게 잘 구분하고 비즈니스 로직을 어디에 어떻게
줄까라는 것을 해결하기 위해, 많은 고민과 방식을 취하는 이들과는 상반 될 수도 있다고 본다.
이에 대해서는 논란의 소지가 다분히 있지만, 나만의 생각을 정리하는 것이기에..
그리고 누구에게도 강요하고픈 생각 또한 없는 것이기에 편안히 적고 있다.
어쨌든, 내가 얻은 경험에서의 핵심은.
1. DB로부터의 데이터를 가져오고 하는 기본은 변형된 쿼리 방식보다는 각 DB마다의 특성을
그대로 사용할 수 있는 쿼리를 사용할 수 있어야 한다. 즉, 표준 SQL이든 각 벤더에 종속된
쿼리든 그 쿼리 그대로를 사용할 수 있어야 하고, 이럴 시에만 대용량 데이터 처리든 대규모
프로젝트에 유리하다.
2. form 파라메터를 form data든 DTO나 도메인 객체든, 이를 다시 퍼시턴트 객체로 사용하든
하는 방식보다는 파라메터 자체를 쿼리와 직접적으로 처리하는 것이 개발 공수를 상당히
줄 일 수 있다.
3. 이를 위한 컨트롤러는 화면이나 액션마다의 맵핑에 따른 결과보다는 정형화된 패턴으로 호출과
결과값을 가져올 수 있도록 하는 것이 좋다.
는 것이다.
이를 위해서 지난 날에는 모든 부분을 실제 모두 개발을 했었지만,
지금에 있어서는 다음의 조합으로 가능하다.
1. 쿼리를 비즈니스 객체에서 분리하여, DAO는 정형화 할 수 있으며 이에 따른 개발은 spring기반으로
가능하며, 쿼리의 분리는 iBatis를 활용하면 된다. (예전엔 쿼리를 관리하는 XML을 별로도 두어
id를 주고 context상에 쿼리를 넣고 해석하는 등의 엔진을 만들어서 사용도 해봤다.)
2. form의 파라메터들은 Map 타입으로 받을 수 있기에 이는 iBatis에서의 Map을 파라메터들의 맵으로
받아 #파라메터명 으로 처리하는 것이 가능한 부분에서 효과적으로 사용이 가능하다.
(다시 말해, 굳이 form data를 사용하지 않고도 웹의 파라메터를 iBatis에서의 쿼리 파라메터로 바로
처리할 수 있게 있기에 일괄 된 결과 값을 가져올 수 있다.)
이러한 것을 통해 비즈니스 로직은 viewer단에서 자연스레 처리가 가능하다.
(비즈니스 로직이 DTO나 도메인 모델등에 어디에 포함되니 안되니하는 논란에서 벗어날 수 있다.)
3. 이 부분을 위해 예전에 Rule기반의 엔진을 별도로 만들어 XML기반에서 룰(element 또는 Attribute)을
임의대로 바꿔가며 호출해서 사용하였었다. 그런데 이 부분을 요즘에 쓰기 좋게 나온 오픈 Rule 엔진들
또는 Groovy 또는 JRuby를 활용, 이도 아니면 Sping의 WebFlow에서도 어느정도
가능하리라 보인다. (실제 1,2 부분은 얼마전의 프로젝트에서 사용해보며 가능성을 확인한바 있고,
3을 새롭게 설계함에 있어 1,2를 처리 방식이 단순 DB에서의 데이터만을 가져오는 것 이외에 여러
기능들이 추가 될 것으로 생각된다.)
다시 제목의 통합개발 환경으로 돌아가 이러한 기반위에 좀 더 효율적인 개발툴과 기능들의 연계를
새롭게 구성할까 한다.
초기에는 메시징 기반으로 웹서비스의 연동, ESB를 활용한 SOA기반과 BPEL을 포함 시킨 BPM기반으로의 연계 및 확장까지 구상해 보았지만, 일차적으로는 자바의 이러한 개발 환경을 '일반화'와 '대중화' 쪽에
목표를 두기로 했다.
그러기 위한 기준으로는 자바기반(JSP 호스팅)의 호스팅이 되는 곳에서 쉽게 사용이 가능하여야 되는
것을 전제로 하기로 했다.
이는 지금까지 기업솔루션 중심으로 개발을 해온 나였기에... 정작,
내 사이트를 PHP기반의 제로보드나 터터툴로..., 또 지인들의 부탁으로 PHP기반의 쇼핑몰을
만들어줘야했던 현실을 바꿔보고 싶은 마음도 있기 때문이다. (이젠 JSP 호스팅도 많아졌고 저렴도 해졌기에.. )
최근 zb5의 발표로 호스팅업체들의 MySQL4.1 지원, PHP5 등 지원으로 서버증설 및 난리를 치는 것을보며,
자바의 대중적 쓰임은 아직 미비할 따름이듯 싶다. 이에 기업 솔루션 개발 및 생각으로만 굳어버린
머리와 마음을 좀 더 많은 이들이 사용할 수 있는 것들을 만들고 나 또한 사용하고 싶은 요즘이고,
이러한 생각과 정리들을...
틈틈히 실천으로 만들어 볼까 한다.
ps : 위에 쓴 내용만으로는 이해하기 어려운 부분이 많으리란 것은 충분히 동감한다.
많은 분들이 공감할 수 있는 결과물이 빨리 나올 수 있는 날을 기대해 볼 따름이다.
여기서 말하는 통합 개발환경이라는 것은 프레임워크, 개발툴, 관련서버, DB, 개발언어, 형상관리,
리팩토링, 테스트, 문서화, 레포팅, 모니터링 등등.. 모든 것을 다 포함한 개념이다.
개발이 단순 노다성을 벗어나며 프레임워크나 패턴의 사용에 따른 설계 및 코딩능력을 중요시 되던
시기가 있었지만, 이는 개발자의 능력과 사상에 따라 팀을 이루어 개발시에 오히려 문제를 일으키는
요소로까지 작용하였고, 그러한 부분은 여러 툴들이 기능을 향상함에 따라 어느정도 보안해기 시작했지만,
적지 않은 가격과 시간이 흐르며 툴에 종속적으로 그 모양새가 변모 되어갔다.
(그래서 한때는 특정 툴에서 개발 잘하던 개발자가 다른 툴에서는 어찌할 바를 모르는 웃지 못할 상황까지
생기기도 했었다.)
이러한 변화의 흐름속에 묻혀 생활하면서 얻은 결론은
시대에서 최고라 칭하는 프레임워크만을 잘한다고, 최고의 기능을 제공한다는 툴을 잘 다루는 것으로,
궁극적으로 원하는 단기간에 최고의 결과물을 내놓기가 어렵다는 것이였다.
결국, 이 모든 것과 그 이외에도 개발에서 사용되어야하는 모든 것들이 함께 잘 어울려져야만 해야만 했고,
또한 이것은 대중적(또는 범용적)인 환경을 제공해야 된다는 것이다.
(아무리 좋은 것도 프로젝트 시마다 새롭게 가르쳐야하고 배워야하는 것이라면, 이는 장점보다
단점이 더 많은 것이다.)
여러 과정과 시행착오, 경험들은 뒤로하고, 그래서 구성할 수 있는 최고의 조합이 현재로써는
eclipse과 springframework을 기반으로 한 통합 개발환경이다. (그 외 다양한 오픈소스들과...)
이 새부적인 내용에 대해서는 생각하는 환경이 구축되어감에 이곳을 통해 조금씩 정리해볼까 한다.
통합환경은 크게 이렇다고 하더라도, 새부적인 부분에 있어서도 이슈들이 상당히 많다.
우선 가장 핵심이되는 프레임워크 차원에서의 spring 의 쓰임새는 이를 사용해본 사람이라면
공감하겠지만, 사용하는 사람의 사상과 설계 방식에 따라서 완전히 달리할 수 있다는 것이다.
이전의 수많은 프레임워크라는 것을 접하고 하면서 지금의 struts나 spring을 바라보는 관점은
일반일들에 비해 나는 좀 달리하고 있고, 사용방식은 조금은 특이하다. (최소한 이러한 방식 또는
관점을 이야기하는 것을 듣고 보지 못했기에.. )
특히나, 웹기반에 있어서의 도메인 객체를 모델링하는 것은, 객체지향이라는 자바의 태생(!)에도
불구하고 이러한 설계를 상당히 싫어함을 넘어 Anti- 로까지 생각을 한다.
core J2EE Pattens에서 이야기하는 VO(Value Object), 최근에는 DTO(Data Transfer Object),
hibernat에서는 domain model 등.. 으로 이야기하는 그 모든 것들이 이 대상이 될 수 있다.
EJB가 툴에서 자동생성해 주는 것이 나오기전의 노가다로 일일이 작성하며, 초기 EJB 기반으로의
프로젝트를 진행해 본 사람이라면, 지금에 이야기하는 DTO나 DAO가 왜 필요한지, 그리고
자신도 모르는 사이 그러한 것을 구현한 것을 알 것이다.
하지만, 그렇게 구현한 DTO(VO)는 결국엔 고객의 무수한 요구사항 수정덕에 이렇게 설계 스스로에
대해, "왜 이렇게 설계한 것일까? 아니야 고객의 잘못이야? 아니지 이러한 수정요구까지 반영 못한
것이 잘못이지"라 떠들며 자학 또한 해보았을 것이다.
그러면서 편법으로 구현빈 내에 쿼리를 집어 넣지 않고 할 수 있는 방법과 파라메터들을 좀 더 유연하고
정형화해서 쓸 수 있는 방법들을 찾으며, 나름대로의 패턴과 프레임워크들을 만들어 보았으리라
생각한다.
이러한 것이 struts의 등장으로 사람들이 다시 우르르 이동과 함께 박수를 보내기 시작했다.
(struts가 EJB 대안이나 그렇다는 이야기는 분명아니다, 많은 이들에게 고민이 많던 시기에
등장했다는 것을 말하려는 것이다.)
나 또한 struts를 여러 프로젝트에서 감사의 마음(!)과 찹찹한 마음(그간만들었던 여러
MVC기반의 나만의 프레임워크가 날아간 순간)으로 잘(!) 사용하였다.
하지만, 개인적으로 사용을 좀 달리해서 사용하였다.
내가 사용하는 Action Mapping 은 프로젝트 많아야 3~5개 정도로 국한 시키는 방식이였고,
ActionForm 또한 사용하지 않는 방식이였다.
(프레임워크는 그대로 적용해야지, 프레임워크의 프레임워크를 만들면 안되다는 이야기 또한
있지만, 난 후자의 방식을 좋아하고 그것이 옳다고 믿는 사람이다.)
대규모 프로젝트의 Action Mapping을 모든 화면의 Action마다 만들어서는 오히려 감당히
어려웠기에 공통의 호출과 그에 따른 리턴 방식을 공통화 시키고, 웹기반에서 주로 사용하는
다운로드, 엑셀변환, pdf 추출, 프린터등등을 별도의 모듈로 만들어 이를 Rule 기반으로 호출시에
이렇나 기능들이 동시에 처리되어 결과로 뿌려줄 수 있게 설계하였기에 이런 것이 가능하였다.
ActionForm을 사용하지 않았던 것은 앞선 EJB를 사용하면서 느꼈던 VO(DTO, DAO)를 별도로 생성해서
개발을 하는 것에 대한 불신(!) 때문이다. 이는 EJB의 비즈니스 로직의 변경보다 화면의 변경이슈가
더 많은 상황에서 화면상의 파라메터와 DTO 간의 종속성(나는 이렇게 표현한다)은 웹개발에 있어서
생산성을 현격히 저하 시킨다고 믿기 때문이다.
(여러 툴에서 이를 해소해 준다고는 하지만, 툴에 지나치게 종속적을 되는 것 또한 옳지 않다고 생각
하기도 하기에... )
이는 최근에 이슈가 되고 있는 DTO와 도메인 모델의 사용에 어느 것이 좋니, 나쁘니 하는 것에 있어
개인적으로는 둘 다 웹개발 생산성에 도움이 되지 않는다는 것으로도 이야기하는 것이다.
(이렇기에 사상적으로 많이 틀리다고 스스로 인정하는 부분이다.)
이러한 논리는 View단과 Controller단의 Layer을 어떻게 잘 구분하고 비즈니스 로직을 어디에 어떻게
줄까라는 것을 해결하기 위해, 많은 고민과 방식을 취하는 이들과는 상반 될 수도 있다고 본다.
이에 대해서는 논란의 소지가 다분히 있지만, 나만의 생각을 정리하는 것이기에..
그리고 누구에게도 강요하고픈 생각 또한 없는 것이기에 편안히 적고 있다.
어쨌든, 내가 얻은 경험에서의 핵심은.
1. DB로부터의 데이터를 가져오고 하는 기본은 변형된 쿼리 방식보다는 각 DB마다의 특성을
그대로 사용할 수 있는 쿼리를 사용할 수 있어야 한다. 즉, 표준 SQL이든 각 벤더에 종속된
쿼리든 그 쿼리 그대로를 사용할 수 있어야 하고, 이럴 시에만 대용량 데이터 처리든 대규모
프로젝트에 유리하다.
2. form 파라메터를 form data든 DTO나 도메인 객체든, 이를 다시 퍼시턴트 객체로 사용하든
하는 방식보다는 파라메터 자체를 쿼리와 직접적으로 처리하는 것이 개발 공수를 상당히
줄 일 수 있다.
3. 이를 위한 컨트롤러는 화면이나 액션마다의 맵핑에 따른 결과보다는 정형화된 패턴으로 호출과
결과값을 가져올 수 있도록 하는 것이 좋다.
는 것이다.
이를 위해서 지난 날에는 모든 부분을 실제 모두 개발을 했었지만,
지금에 있어서는 다음의 조합으로 가능하다.
1. 쿼리를 비즈니스 객체에서 분리하여, DAO는 정형화 할 수 있으며 이에 따른 개발은 spring기반으로
가능하며, 쿼리의 분리는 iBatis를 활용하면 된다. (예전엔 쿼리를 관리하는 XML을 별로도 두어
id를 주고 context상에 쿼리를 넣고 해석하는 등의 엔진을 만들어서 사용도 해봤다.)
2. form의 파라메터들은 Map 타입으로 받을 수 있기에 이는 iBatis에서의 Map을 파라메터들의 맵으로
받아 #파라메터명 으로 처리하는 것이 가능한 부분에서 효과적으로 사용이 가능하다.
(다시 말해, 굳이 form data를 사용하지 않고도 웹의 파라메터를 iBatis에서의 쿼리 파라메터로 바로
처리할 수 있게 있기에 일괄 된 결과 값을 가져올 수 있다.)
이러한 것을 통해 비즈니스 로직은 viewer단에서 자연스레 처리가 가능하다.
(비즈니스 로직이 DTO나 도메인 모델등에 어디에 포함되니 안되니하는 논란에서 벗어날 수 있다.)
3. 이 부분을 위해 예전에 Rule기반의 엔진을 별도로 만들어 XML기반에서 룰(element 또는 Attribute)을
임의대로 바꿔가며 호출해서 사용하였었다. 그런데 이 부분을 요즘에 쓰기 좋게 나온 오픈 Rule 엔진들
또는 Groovy 또는 JRuby를 활용, 이도 아니면 Sping의 WebFlow에서도 어느정도
가능하리라 보인다. (실제 1,2 부분은 얼마전의 프로젝트에서 사용해보며 가능성을 확인한바 있고,
3을 새롭게 설계함에 있어 1,2를 처리 방식이 단순 DB에서의 데이터만을 가져오는 것 이외에 여러
기능들이 추가 될 것으로 생각된다.)
다시 제목의 통합개발 환경으로 돌아가 이러한 기반위에 좀 더 효율적인 개발툴과 기능들의 연계를
새롭게 구성할까 한다.
초기에는 메시징 기반으로 웹서비스의 연동, ESB를 활용한 SOA기반과 BPEL을 포함 시킨 BPM기반으로의 연계 및 확장까지 구상해 보았지만, 일차적으로는 자바의 이러한 개발 환경을 '일반화'와 '대중화' 쪽에
목표를 두기로 했다.
그러기 위한 기준으로는 자바기반(JSP 호스팅)의 호스팅이 되는 곳에서 쉽게 사용이 가능하여야 되는
것을 전제로 하기로 했다.
이는 지금까지 기업솔루션 중심으로 개발을 해온 나였기에... 정작,
내 사이트를 PHP기반의 제로보드나 터터툴로..., 또 지인들의 부탁으로 PHP기반의 쇼핑몰을
만들어줘야했던 현실을 바꿔보고 싶은 마음도 있기 때문이다. (이젠 JSP 호스팅도 많아졌고 저렴도 해졌기에.. )
최근 zb5의 발표로 호스팅업체들의 MySQL4.1 지원, PHP5 등 지원으로 서버증설 및 난리를 치는 것을보며,
자바의 대중적 쓰임은 아직 미비할 따름이듯 싶다. 이에 기업 솔루션 개발 및 생각으로만 굳어버린
머리와 마음을 좀 더 많은 이들이 사용할 수 있는 것들을 만들고 나 또한 사용하고 싶은 요즘이고,
이러한 생각과 정리들을...
틈틈히 실천으로 만들어 볼까 한다.
ps : 위에 쓴 내용만으로는 이해하기 어려운 부분이 많으리란 것은 충분히 동감한다.
많은 분들이 공감할 수 있는 결과물이 빨리 나올 수 있는 날을 기대해 볼 따름이다.
