글
애니프레임을 위한 항변
2008/Spring Framework
2008/07/19 13:12
한 3년쯤 전에 스프링이나 블로그의 존재부터 배웠던 백기선군이 많이 컸습니다. 꾸준한 노력은 정말 아무것도 모르던 친구도 3년이면 수준에 오르게 하는게 확실하군요. 급성 편도염1으로 누워있다 인터넷 기사가 깨워서 인터넷 재개통 기념2으로 서핑을 하는데 Anyframe 보다가 흥분 해버렸네요.를 보고, 저 역시 사석에서 애니프레임을 저평가하는 발언을 했던 점을 떠올리면, 이번에는 애니프레임을 위한 항변을 해봅니다. 하지만, 몇 가지 항목에 대한 항변일 뿐입니다. ^^
처음으로 지적한 유틸리티의 중복 문제는 저 역시 고민한 바 있습니다. 학습비용을 중요하게 생각하는 SI 환경을 고려하면, Commons 산하의 엄청난 API를 그대로 노출하는 것보다는 숨기는 것이 도움을 줍니다. 물론, public 메소드 들이기 때문에 jar로 포함시키는 이상 완전히 숨긴다고 볼 수는 없지만, 인터페이스 래핑만으로 어느 정도는 API 혹은 API 문서 분량을 줄일 수 있죠. 이런 내용은 스프링이 3rd 파티 코드를 수용할 때도 사용했죠. 물론, 단순 복사는 없었지만. 기선군이 아직 현장에서 한 번의 프로젝트도 참여한 적이 없기 때문에 이런 경험은 알 수가 없는 것이죠. 하지만, 논리적으로 일리 있는 반론이기 때문에... 블로그가 아닌 포럼에 글을 올려보는게 어떨까 싶네요. 물론, 그 분들 감정을 고려해서 표현은 정화를 해야겠죠.
로거문제는 중요3 하지만, 기선군이 제시한 문제는 잘 모르겠습니다. Xinternet - iBatis 연동 부분은 애니프레임 개발시 현업 요구가 가장 많았던 부분입니다. 코드를 자세히 보지 않아 몰랐는데, 패키지 구성에서 일관성은 취약한 모양이군요. Hibernate 부분은 뭘 더 구현할 수 있을까 싶어 보지도 않았는데, 문제가 있었나 보네요. 이거 항변한다고 해놓고선... 다시 항변으로 가보죠.
마지막으로 전후처리 부분에 대해서는 preprocess(), postprocess()는 나름 이유가 있죠. 가장 큰 이유는 전, 후 처리는 대형 프로젝트에서는 마치 패턴처럼 고착화 한 용어입니다. 메대규모 프로젝트에서 웹은 일부에 지나지 않이 filter나 interceptor로 무조건 해결할 수는 없습니다. 정리하면, 내부에서 사용하는 라이브러리를 제대로 쓰는 것이 오랫동안 해오던 SI/SM의 업무 방식을 무조건 바꿀 수는 없죠. 설득과 보급의 과정이 필요합니다. 우리 프로젝트에서도 웹과 채널 연계에서 전/후처리를 공동화 하려고 할 때 현장 경험이 풍부한 친구는 역시 preprocess(), postprocess()를 선택했습니다. :) 스마트한 고객이 문제제기를 한 탓에 바닥에서부터 재검토를 했고, AOP로 비즈니스 서비스 전/후처리를 하는 것으로 변경했다가 지금은 웹에서는 유겐할러가 만든 HandlerInterceptor를 쓰고, 채널 등에서는 유겐할러가 만든것과 유사하게 인터페이스를 재정의하는 것으로 결론을 내렸습니다. 권장안은 Interceptor이지만, AOP와 Intercptor 두 개의 옵션을 제공하기로 했죠.
전체적으로 보면 Anyframe 보다가 흥분 해버렸네요.에서 기선군이 애니프레임에 묻어있는 스프링, 하이버네이트에 대한 무지함을 자극적인 말로 질타했습니다. 하지만, 무모함까지 엿보이는 표현의 이면에는 수행 프로젝트가 0이라는 기선군의 현장에 대한 무지함이 있습니다. 이것을 단순히 싸움의 논리로 보면, 서로 약점이 있으니 물고 늘어지면 되겠죠. 하지만, 저는 기선군과 같은 스타일의 공격성 발언이 점잖빼고 일면 위선적이기도 한 우리 SI 현실에 많이 필요하다고 생각합니다. 기선군의 스프링에 대한 이해는 상당한 수준입니다. 애니프레임을 만들어낸 SDS의 현장 경험은 아마 국내 최고 수준이 아닐까 생각합니다. web 2.0 시대 운운하는데 다른 유형의 지식이 MASH UP을 이뤄서... 생산적인 결과물을 만들어내면 좋겠습니다. 그런 의미에서 KSUG에 오셔서 한 판 하세요. 듬직한 토비님과 새로 합류한 젊은 피(?) setq4님이 싸움으로 번지면 말려줍니다. 결국 광곤가... 일민형이 좋아하겠군. :)
처음으로 지적한 유틸리티의 중복 문제는 저 역시 고민한 바 있습니다. 학습비용을 중요하게 생각하는 SI 환경을 고려하면, Commons 산하의 엄청난 API를 그대로 노출하는 것보다는 숨기는 것이 도움을 줍니다. 물론, public 메소드 들이기 때문에 jar로 포함시키는 이상 완전히 숨긴다고 볼 수는 없지만, 인터페이스 래핑만으로 어느 정도는 API 혹은 API 문서 분량을 줄일 수 있죠. 이런 내용은 스프링이 3rd 파티 코드를 수용할 때도 사용했죠. 물론, 단순 복사는 없었지만. 기선군이 아직 현장에서 한 번의 프로젝트도 참여한 적이 없기 때문에 이런 경험은 알 수가 없는 것이죠. 하지만, 논리적으로 일리 있는 반론이기 때문에... 블로그가 아닌 포럼에 글을 올려보는게 어떨까 싶네요. 물론, 그 분들 감정을 고려해서 표현은 정화를 해야겠죠.
로거문제는 중요3 하지만, 기선군이 제시한 문제는 잘 모르겠습니다. Xinternet - iBatis 연동 부분은 애니프레임 개발시 현업 요구가 가장 많았던 부분입니다. 코드를 자세히 보지 않아 몰랐는데, 패키지 구성에서 일관성은 취약한 모양이군요. Hibernate 부분은 뭘 더 구현할 수 있을까 싶어 보지도 않았는데, 문제가 있었나 보네요. 이거 항변한다고 해놓고선... 다시 항변으로 가보죠.
마지막으로 전후처리 부분에 대해서는 preprocess(), postprocess()는 나름 이유가 있죠. 가장 큰 이유는 전, 후 처리는 대형 프로젝트에서는 마치 패턴처럼 고착화 한 용어입니다. 메대규모 프로젝트에서 웹은 일부에 지나지 않이 filter나 interceptor로 무조건 해결할 수는 없습니다. 정리하면, 내부에서 사용하는 라이브러리를 제대로 쓰는 것이 오랫동안 해오던 SI/SM의 업무 방식을 무조건 바꿀 수는 없죠. 설득과 보급의 과정이 필요합니다. 우리 프로젝트에서도 웹과 채널 연계에서 전/후처리를 공동화 하려고 할 때 현장 경험이 풍부한 친구는 역시 preprocess(), postprocess()를 선택했습니다. :) 스마트한 고객이 문제제기를 한 탓에 바닥에서부터 재검토를 했고, AOP로 비즈니스 서비스 전/후처리를 하는 것으로 변경했다가 지금은 웹에서는 유겐할러가 만든 HandlerInterceptor를 쓰고, 채널 등에서는 유겐할러가 만든것과 유사하게 인터페이스를 재정의하는 것으로 결론을 내렸습니다. 권장안은 Interceptor이지만, AOP와 Intercptor 두 개의 옵션을 제공하기로 했죠.
전체적으로 보면 Anyframe 보다가 흥분 해버렸네요.에서 기선군이 애니프레임에 묻어있는 스프링, 하이버네이트에 대한 무지함을 자극적인 말로 질타했습니다. 하지만, 무모함까지 엿보이는 표현의 이면에는 수행 프로젝트가 0이라는 기선군의 현장에 대한 무지함이 있습니다. 이것을 단순히 싸움의 논리로 보면, 서로 약점이 있으니 물고 늘어지면 되겠죠. 하지만, 저는 기선군과 같은 스타일의 공격성 발언이 점잖빼고 일면 위선적이기도 한 우리 SI 현실에 많이 필요하다고 생각합니다. 기선군의 스프링에 대한 이해는 상당한 수준입니다. 애니프레임을 만들어낸 SDS의 현장 경험은 아마 국내 최고 수준이 아닐까 생각합니다. web 2.0 시대 운운하는데 다른 유형의 지식이 MASH UP을 이뤄서... 생산적인 결과물을 만들어내면 좋겠습니다. 그런 의미에서 KSUG에 오셔서 한 판 하세요. 듬직한 토비님과 새로 합류한 젊은 피(?) setq4님이 싸움으로 번지면 말려줍니다. 결국 광곤가... 일민형이 좋아하겠군. :)
