스프링 프레임웍과 금융 프로젝트

스프링 프레임웍 기반의 상용 프레임웍을 이용해서 금융 차세대 프로젝트를 하고 있습니다. 현재는 본개발 이전의 파일럿 단계입니다

 

저도 개인적으로 스프링을 좋아하고 여러 프로젝트에 적용도 해봤고 해당내용을 교육도 했었지만 최근에는 그 단점이 철저히 느껴지기 시작했습니다.

 

핫 디플로이가 안된다.

 

가장 큰 단점중에 하나입니다. 프로젝트 특성상 원격 서버에서만 테스트할 수 있는 경우가 있습니다. 솔루션, 운영체제, 라이센스, 대내시스템, 대외시스템 연계 등 다양한 이유가 있습니다.

핫 디플로이가 안돼서 주기적으로 was를 restart 해야합니다. 너무 자주하면 테스트가 끊기고 너무 가끔하면 테스트를 위해서 재시작 될때까지 기다려야 합니다. 개발 효율성 면에서 큰 문제입니다

 

Bean 설정이 잘못되면 was가 실행이 안된다

 

치명적인 장애를 유발하는.부분입니다. 스프링은 ioc와 aop를 위해서 완벽한 설정 정보를 요구합니다. 그리고 이를 좀더 편리하게 하기 위해서 annotation 을 통한 설정을 제공합니다. Autowire가 대표적입니다. 문제는 앞서 말한 핫디플로이가 안되는 이유로 자주 restart를 하게 되고 이때 단 하나의 설정 오류 혹은 잘못된 annotation이 was를 실행못시키게 만듭니다. 정확히는 스프링 컨테이너를 실행시키지 못합니다.

70,000개가 넘는 자바 코드와 300명이 넘는 개발자가 참여하는 금융 차세대에서 한명의 오류 혹은 실수가 전체 개발자의 발목을 잡을 수 있습니다.

 

모든 개발자가 스프링에 익숙하지는 않다.

 

모든 개발자가 스프링에 익숙하지는 않습니다. 자바에 익숙하지 않더라고 업무를 잘 아는 개발자를 많은 고객들이 선호합니다. 이 와중에 스프링도 잘하는 사람을 구하긴 하늘에 별따기입니다.

이로 인해 개발에 앞서 교육에 들어가는 시간 소모가 굉장히 큽니다. 또한 기술 응대와 에러 대응을 위해 평소보다 더 많은 프래임웍 인력을 유지해야 합니다.

 

스프링의 제약이 법이 된다.

 

스프링 뿐만 아니라 모든 프래임웍들이 자체적인 제약과 전제조건을 가지고 있습니다. 스프링도 예외는 아닙니다. 스프링은 해외에서 범용적인 사용 목적을 고려해서 만든 관계로 국내에서 수십년간 관행처럼 여겨지는 여러가지 약속을 적용하기가 어려운 경우가 있습니다. 그런데 이러한 약속을 "스프링이 원래 그래요" 라는 말로 어길수는 없습니다.

 

경험있는 엔지니어가 많지 않다.

 

비교적 역사가 짧고 젊은 엔지니어들이 많이 참여해서 활용 되어진 관계로 프레임웍 자체보다 프레임웍 팀원의 자세가 프로젝트에서 받아들여지지 못하는 경우가 많습니다.

예를 들어 반바지와 크록스 슬리퍼 그리고 출퇴근의 자유를 주장하는 엔지니어를 금융 프로젝트에서 인정해 줄리가 없습니다.

 

이론 뿐만 아니라 경험도 중요함을 알아야 합니다.

 

SI는 상식이 통하지 않는 곳입니다. 그래서 동종업계 경력을 가장 우선시 합니다. 책에서 나오는 이론이 항상 옳다고 할수 없는 곳입니다. 많은 스프링 프레임웍 기반의 제품을 판매하는 분들을 보면 프로젝트 경험을 의심하게 만드는 말투와 행동을 보입니다. 프레임웍을 안다는것이 대단한 감투가 될수 없음에도 말입니다. 

 

그래도 다행인것은 이러한 여러가지 이유로 아직 제가 할일이 많이 있고 그 덕에 먹고 살수 있어서 좋습니다. 앞으로 5년은 더 일할수 있을것 같습니다.