Whiteship's Note


기술 보다는 팀이 개발 정책을 세울 때 우선이 되어야 한다.

모하니?/Thinking : 2008.11.28 11:24


당연한 말이죠. 그런데 정말 이렇게 하고 계신가요?

오늘 "사람을 위한 자동화" 시리즈를 번역하다가 멋진 문장 하나를 발견했습니다. (번역을 하면 이게 좋습니다. 정독을 하게 되고, 정독을 하다보면 좋은 문장도 놓치지 않을 수 있죠.)

There are probably version-control systems that support parallel development better than Subversion, but in my experience the policies that teams adhere to when developing are much more important than how a tool technically solves the problem.

병렬로 개발할 때 서브버전보다 더 좋은 툴도 있겠지만, 본인 경험상 개발을 할 때 기술 보다는 팀원에게 익숙한 정책을 세우는게 더 중요했다는 내용입니다.(아마도 GIT 같은 분산 SCM을 두고 말한거 같네요.)

저 한 문장이 저한테 참 많은 생각을 하게 합니다.

SI에 대한 (경험없고 몽매한 저의) 생각

실제 제품 코드 작성하는 개발자들이 자꾸 바뀌는 환경에서 저런게 가능한가? SI가 어쩌다 그런 구조가 됐을까? 팀 단위로 다니는 SI 업체에서는 가능할까? 그 사람들은 프로젝트에 가서 코딩만 하고 기술 선택에 대한 의사결정에 어떤 영향을 주고는 있는 건가? 그런 의사결정 권한이 있는 사람들은 코딩하는 개발자들을 팀으로 생각할까 아니면 종으로 생각하고 있을까? 일단 다 정해놓고 와서 코딩만 시키는거 아닌가? 어떻게 그렇게 개발을 하지? 고객과 개발자가 직접 만나서 일을 하면 안 되고 꼭 중간다리 역할을 하는 사람이 있어야 하나? 그 사람들이 실제로 코딩을 할 개발자들과 같이 개발을 할꺼면 상관없겠지만 그런 경우가 아니라 아예 업체도 다르고 개발할 사람들이랑 전혀 공감대도 없다면. 뭔가 잘못 된 거 아닌가? 개발자와 고객 사이를 막고서서 자기들의 입지를 만들고 개발자 의사소통 능력을 점점 쇠퇴시키는거 아닐까? 개발자는 왜 의사소통을 못한다고 생각하지? 못 하는게 아니라 안 하니까 퇴화 되는거 아닌가? 고객과 개발자가 직접 만나서 대화를 하면 오히려 중간 다리가 고객 - 인코딩 디코딩 - 개발자 - 디코딩 인코딩 - 고객 사이의 네 번의 인/디코딩 과정이 사라지니까 훨씬 좋은거 아닌가? 그래야 위와 같이 팀을 고려한 정책을 만들지 않을까?

나에 대한 내 생각

내가 공부하는 것들을 다른 사람들도 공부하고 있을까? 난 누구랑 일할 수 있는거지? 내가 좋아하는 기술을 포기하고 다른 사람들에 맞춰서 혹은 누군가 이미 다 정해놓은 틀 속에서 개발을 해야 하는건가? 어떻게 해야 되는거지.. 나도 팀 생활을 하고는 싶은데, 내가 사용하고 싶은 기술로는 팀 생활을 할 수가 없고.. 난 선택의 기로에 서있는 건가? 팀이냐 기술이냐 라는 선택인가?? 흠..아니야. 내가 쓰고 싶은 기술(스프링, 하이버, 스프링 DM, 메이븐, ...)이 그렇게도 유별 난건 아니자나. 저 기술을 쓰면서 개발하는 곳이 정말 그렇게도 없을까? 지금도 어디선가는 저 기술로 개발하고 있을 텐데. 글치.. 한국에서도 조금 큰 회사에서 이미 저렇게 하고 있자나. 그래도 역시 혼자는 너무 외로워. 하지만 사실 나 혼자는 아니지. 사부님도 있고 고객도 있으니까. 고객이랑 놀지 뭐. 그러고 보면 다음 프로젝트 기술은 사부님이 기술 결정을 하니까 내가 좋아하는 기술도 써먹어 볼 수 있단 말이지. 딱 저 문구에 맞는 상태로 개발하는.. 즐거움. 팀이 좋아하고 팀에게 익숙한 기술을 사용하는 이 즐거움을 다른 많은 개발자들도 알고 있겠지?? 그래야 할텐데..
top


뷰가 없는 웹 애플리케이션



뷰가 없이 요청이 오면 응답을 줍니다. Servlet이긴 한데 뷰가 없는 애플리케이션입니다. Request로 받은 메시지를 가지고 어떤 비즈니스로직을 수행하고 그 결과를 Response로 담아서 전달해주면 요청을 보낸 쪽에서 그걸 받아서 또 다른 곳으로 전달합니다.

이 애플리케이션이 할 일은 주로 세 가지죠.
  1. 요청 받기
  2. 메시지를 객체로 파싱
  3. 비즈니스 로직 수행
  4. 결과를 메시지로 변환
  5. 응답으로 메시지 보내기
메시지/객체 변환은 다른 객체에게 위임해버리기로 하고, 비즈니스 로직도 다른 곳으로 위임해버리고 이 서브릿은 오로지 위와 같은 일의 순서를 정해둔 템플릿으로 사용하고 싶네요. 컨트롤러처럼 말이죠. 비즈니스 로직을 수행하는 녀석들은 모두 도메인 객체로 구현하고 메시지를 변환한 객체들은 DTO가 되겠죠.

그런데 문제는 메시지를 받는 쪽에서 이 메시지에 어떤 비즈니스 로직을 태워야 하는지 알 수가 없다는 것입니다. 따라서 파싱한 결과를 보고 판단해야합니다.

지금까지 분석한 내용으로 Spring MVC에 대입해서 생각해보겠습니다.

먼저 전달받는 녀석이 Dispatcher Servlet과 같은 문지기 역할을 합니다. 그리고 메시지를 파싱해주는 녀석을 통해서 메시지를 파싱하고 그 중에서도 어느 비즈니스 로직을 수행해야 하는지 결정하는 인자를 파악하여 Handler Mapper에게 어떤 컨트롤러가 해당 메시지를 처리해야 하는지 물어봅니다.

그 결과를 디스패처에게 알려주면, 디스패처는 다시 해당 컨트롤러에게 변환한 DTO를 인자로 넘겨주면서 처리를 부탁합니다. 그럼 컨트롤러에서 해당 DTO를 가지고 비즈니스 로직을 수행하고 그 결과를 디스패처에게 반환해줍니다.

디스패처는 결과를 받아서 DTO를 메시지로 다시 변환해주는 녀석에게 파싱을 부탁합니다. 그 결과(바이트스트림 메시지)를 응답에 태워서 보냅니다.

기존의 Spring MVC에서 View Resolving과 관련된 부분을 빼고 동일합니다.

구현해야 할 것은 크게 네 가지 입니다.
  1. 위와 같은 일을 해줄 Dispatcher Servlet(DispatcherServlet 소스코드 분석 후 뷰 렌더링 부분 수정)
  2. 메시지(바이트스트림)/객체의 변환을 맡을 객체(Interceptor로 처리할까?)
  3. 특정 정보를 가지고 그것을 처리할 컨트롤러를 매핑할 Handler Mapper(그냥 단순하게 key/value 쌍으로 호출해야할 컨트롤러 이름을 관리하는 클래스가 필요할 듯.)
  4. 비즈니스 로직을 수행할 컨트롤러들.(인터페이스 정도는 미리 설계해 둘 순 있겠군)
비즈니스 로직 수행할 녀석들은 나중에 만든다쳐도 1, 2, 3번 클래스들은 만들어야겠네요. 이게 제가 들어간 프로젝트에서 프레임워크가 해줄 부분 입니다. 흠냐~ 스프링써서 만들어두면 쓰시겠죠.

'프로젝트 > 나이스' 카테고리의 다른 글

뷰가 없는 웹 애플리케이션  (0) 2007.12.09
top