Programming is Fun

java8이 나오고 빠르게 한번 환경을 변경시켜보고 난 후, 문제점 상황을 정리해봤습니다.

jacoco 버젼 문제

jacoco를 최신 버젼으로 해줄 필요가 있습니다. jacoco는 최신 버젼이 0.7.0.201403182114 입니다. 버젼뒤의 날짜를 보시면 아시겠지만, java8 발표 일자와 완전히 동일합니다. 기존 jacoco에서는 byte code exception이 발생하기 때문에 반드시 업그레이드 할 필요가 있습니다.

tomcat 8

gradle tomcat plugin이 아직 tomcat8을 지원하지 못합니다. gradle을 이용한 build의 경우에는 java 8을 사용하시는 것을 고민해주시는 것이 좋습니다. 물론 java 8에서 tomcat7을 사용하는 것은 아무런 문제가 발생되지 않습니다.

SonarQube

sonarQube에서 아직 java 8을 지원하지 못하고 있습니다. 3월말에 최신 업데이트가 될 것이라는 이야기가 아래 링크에 있는데…… java8은 작년 여름에 release 될 예정이였지 않나요. 이걸 믿어야지 되는지 고민하고 있습니다.

http://sonarqube.15.x6.nabble.com/Sonar-Support-for-JDK-8-td5019488.html

무엇보다 위 링크에 이야기되고 있는 JIRA Issue는 이미 resolved된 상태입니다. 일단 stackoverflower에 질문을 올려두긴 했는데.. 메일링 리스트에서 물어보세요. 라는 답변을 받아서 상처받고 메일링 리스트에 가입해서 다시 물어봤습니다. ㅠ-ㅠ 답변을 기다려야지요.

FindBugs

sonarQube에서 지금 지원을 못하는 가장 결정적 이유가 바로 FindBug가 Java8을 지원하지 못하는 이슈가 있기 때문입니다. StringSequence class를 비롯해서 몇몇 Class에 대한 오류를 발생시키고 있습니다. Java8에서 가장 큰 이슈중 하나네요.

Java8

개인적으로는 이번 java8을 매우 기다리고 있습니다. PermGemSize에 대한 GC의 개선과 더불어 lamda expression으로 대표되는 java 언어의 확장성. 그리고 지겹고 지겨운 Date 객체 추가.

개인적으로는 이 3가지때문에 java8을 기다리고 있는데. 다른 분들은 어떠실지 모르겠네요.

매번 코드를 작성할 때마다 까먹어서 정리합니다. 기억력이 감퇴가 된것 같네요.

1. MessageSource를 선언. refresh를 위해 ReloadableResourceBundleMessageSource를 사용하는 것이 정신건강상 좋다.
2. LocaleChangeInterceptor를 선언
3. addInterceptors method를 override 시켜, interceptor를 추가
4. AcceptHeaderLocaleResolver, CookieLocaleResolver, SessionLocaleResolver 중 하나를 선택하여 LocaleResolver를 구현

AcceptHandlerLocaleResolver

기본적인 Http Header인 Accept-Language를 이용하는 방법입니다. 기본값이 AcceptHeaderLocaleResolver로 되어 있습니다. 가장 구현이 간단하나, parameter를 통해서 동적으로 Locale을 변경하지 못합니다. UnsupportedOperationException이 발생합니다. 이를 테스트 하기 위해서는 Browser의 설정중에 언어 셋을 변경시켜야지 됩니다.

CokieLocaleResolver

Cookie를 이용하는 방식으로, Cookie name, expired time 등을 설정 가능합니다.

SessionLocaleResolver

Session값을 이용하는 방법으로 서버의 부하측면이 적다면 가장 좋은 방법인것 같습니다.

@Configuration code는 다음과 같습니다.

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = {
        "me.xyzlast.web.controllers"
})
public class ControllerConfiguration extends WebMvcConfigurerAdapter {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/lib/**").addResourceLocations("/lib/**");
        super.addResourceHandlers(registry);
    }

    @Bean
    public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() throws IOException {
        return new PropertySourcesPlaceholderConfigurer();
    }

    @Bean
    public LocaleChangeInterceptor localeChangeInterceptor() {
        LocaleChangeInterceptor localeChangeInterceptor = new LocaleChangeInterceptor();
        localeChangeInterceptor.setParamName("lang");
        return localeChangeInterceptor;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(localeChangeInterceptor());
        super.addInterceptors(registry);
    }

    @Bean
    public AcceptHeaderLocaleResolver acceptHeaderLocaleResolver() {
        return new AcceptHeaderLocaleResolver();
    }

    @Bean
    public ReloadableResourceBundleMessageSource messageSource() {
        ReloadableResourceBundleMessageSource messageSource = new ReloadableResourceBundleMessageSource();
        messageSource.setDefaultEncoding("UTF-8");
        messageSource.setBasename("classpath:messages");
        messageSource.setFallbackToSystemLocale(false);
        return messageSource;
    }
}

국내 SI 개발환경에서의 거의 100이면 99정도 myBatis를 이용한 DB Handling을 하고 있습니다. 개인적으로는 상당한 ORM 빠돌이라서… 왜 ORM을 사용하지 않지? 라는 의문을 항시 가지고 있다가 다른 여러 사람들 및 개인적인 생각을 정리해서 한번 올려봅니다.

ORM에 대한 learning curve

먼저, 개발자들에 대한 개인 책임이 어느정도 있다고 생각합니다. 근처의 여러 사람들을 만나보면, 개발자들중 3년이 지나고 나서 공부를 꾸준히하는 개발자들을 찾기 힘들다는 이야기를 자주 듣습니다. 현업에서 주로 사용되고 있는 myBatis 이외에 자신이 찾아서 공부를 하는 사람들의 수가 의외로 적은 것이 한 이유가 아닐까 생각됩니다.

이는 철저히 개발자들의 문제점이 아닐까 라는 생각을 가지고 있습니다. 한해한해 바뀌어가는 개발환경에 대해서 자기 자신을 꾸준히 업그레이드해두지 않으면 자연스럽게 도태가 되어버리는 것이 현 상황인데, 한가지 기술로 너무나 오랫동안 욹어먹는 것 역시 현 IT 환경에서의 죄악 이지 아닐까 싶습니다.

수주에 따른 SI 개발이기 때문에 초기 Reference가 없다.

공적인 분야에서의 대규모 SI를 토대로 성장한 국내 IT 개발환경은 초기 Reference가 매우 중요합니다. 대부분 SQL을 그대로 사용하는 개발환경이 지금까지 이어져왔고, 이러한 개발환경에 대한 reference를 요구하기 때문에, 어쩔수 없이 myBatis를 이용하게 되는 것이 당연하게 이어져오고 있습니다.

이건 어떻게 하면 깰수 있을까요? 솔찍히 이 부분이 개인적으로는 가장 답이 안나옵니다. 공공부분 SI의 경우, reference를 요구하는 것이 당연하다고 생각됩니다. 그렇지만, 이러한 reference 요구에 의해서 신기술의 발전 및 보다 나은 기술의 채택부분이 막힌다면 이거 역시 문제가 아닐까 싶습니다. 점진적으로 해결해 나간다면, 개발자들이 최대한 ORM을 이용해서 공공부분 SI 이외의 현장에서 reference를 쌓는 것이 필요하다고 생각합니다. 지금까지 시장에셔와는 다르게 외부에서의 reference를 이용해서 공공부분에 들어가보는 것 이외에는 조금 답이 안나오는 것 아닌가 싶습니다.

기존 BL이 SQL로 구성되어 있기 때문에

가장 막막하고, 답답한 부분입니다. 기존의 로직이 SQL로 구성되어 있기 때문에 그 SQL을 사용하기 위해서 myBatis를 이용해야지 된다. 라는 의견입니다. 이에 대해서는 전 조금 다른 관점을 보고 싶습니다.

국내는 유독 차세대라는 개발 Project들이 많습니다. 해외에는 차세대라는 말을 붙일 수 있을 정도로 모든 시스템을 갈아엎는 Project들이 별로 없습니다.

그 이유가 무엇일까요?
해외는 대부분 점진적인 개량을 통해서 시스템을 항상 최신으로 유지를 시키거나, 계속적인 성능 개선을 해오고 있기 때문이라고 합니다. 국내의 사정은 어떤가요? 국내는 대부분 SI/SM으로 개발자의 직군이 나뉘게 됩니다. 전자는 주로 개발을, 후자는 주로 운영업무를 하게 됩니다. 그런데, 이 SM 업무의 경우에 대부분 신규로 무언가 개발을 하는 일을 막아버립니다. 업무로 인해서요. 개발이 필요한 상황이 있으면 개발팀에. 라는 것이 일반적인 상황이지요. 실리콘밸리의 새로운 trend라고 불리우고 있는 devOps의 경우, 이러한 용어로 만들어진 것은 얼마 안되었지만 기존까지 이런 식의 조직운영은 꾸준히 계속되어가고 있던것으로 알고 있습니다. 운영팀에서 보다 나은 개발방향을 위해서 시스템을 점진적으로 업그레이드 하고 변경시키는 과정을 이미 행하고 있는겁니다. 그렇지만, 국내의 SM환경은 대부분 어떻습니까? 대부분이 업무처리에 대한 전화상담 및 그에 따른 DB rollback, sql query문 작성에 대부분의 시간을 보내게 되는 것이 사실입니다.

이 문제는 제 개인적으로는 다음 문제와도 연결이 되고 있다고 생각합니다.

개발에 대한 사회적인 인식 문제

현 상황에서 우리 사회는 개발을 한번에 큰 돈을 들여서 하고, 그 다음에는 돈을 안쓰는 것이라고 인식하고 있습니다. 물론 개발에는 초창기 큰 돈이 듭니다. 그렇지만, 유지보수에 더욱더 많은 돈과 시간이 들게 되는 것또한 사실이지만, 국내에는 전혀 이런 사실이 먹히지 않고 있습니다. 유지보수 비용측정만봐도 알 수 있지요.

위 인식때문에, 개발을 할때 대부분이 외주개발자 또는 프리랜서들을 사용해서 대규모 프로젝트를 수행합니다. 그리고, 개발이 마쳐지면 이 사람들이 모두 이 업무에서 손을 떼게됩니다. 개발에 대한 내부적인 역량자체가 거의 없어지는거지요. 그리고 큰 돈을 들인 Application이 정상적으로 돌아가기 위한 산소호흡기만 붙인 상태로 유지를 시켜나가게 되는거지요. 점진적인 개선같은 것은 꿈도 못 꾸는 경우가 많습니다.

거기에다 우리나라는 자산에 대한 선호도가 매우 강합니다. 매우 잘 정제되고 훌륭한 Application이 아닌 시스템과 DB, 즉 자산에 해당되는 곳에는 매우 큰 돈을 쓰지만, 무형자산이라고 할 수 있는 Application에 대한 홀대는 매우 심각한 편입니다. 다른 이야기를 한다면, 이런 이유로 인하여 국내 기업환경에서 내부 데이터에 대한 Cloud는 매우 험난한 길을 가야지 될 것같다는 예상을 합니다. 국내 SI 개발환경에서 개발자들에게 투자한다는 이야기는 정말로 들어본적이 없습니다. 대부분 서버나 DB를 얼마나 비싼것을 샀는지를 자랑하는 기사들을 많이 봤지요.

솔찍히 이 문제는 국내의 천박한 자본주의를 보여주는 것이 아닌가도 싶습니다. 개발을 하는 사람들과 그 사람들의 노력이 귀한줄을 모르고 있는 것이 아닌가 싶어요.

마치면서…

ORM이 아닌 myBatis에 대한 의존 문제 자체가 개인적으로는 국내 IT 발전상황을 가로막는 일중 하나가 되지 않을까 생각하고 있습니다. 당장 open source로 무언가 새로운 web framework가 나오게 되면, 그 다음에 바로 나오는 것이 ORM입니다. DDD를 이용한 ORM modeling을 잘 할 줄 아는 사람들은 결국은 객체에 대한 이해가 좀더 나은 사람들이였던것이 제 개인적인 경험들이였습니다.

이제 ORM은 보다 더 나은 개발자가 되기 위한 조건이 아니라, 필수가 되어가고 있는 것 같은데… 국내 환경은 앞으로도 어떻게 되어갈까요.