spring batch series jco 2009

[Spring batch] 차세대 배치시스템 구축 성공전략 - 2009 JCO컨퍼런스 중

물개선생님 김승권님이 2009년 JCO 컨퍼런스에서 발표하신, 국내 대형 보험사에 Spring batch 기반으로 배치프레임웍을 적용한 사례입니다. 해당 보험사는 처리 자료 건수가 1억건 단위에 운영인력 50명, 800여건 작업을 돌리는 큰 규모의 배치 시스템을 가지고 있다고 합니다.

발표내용 중에 개발자들에게 배치 프레임웍의 필요성에 대해서 설득하는 과정이 힘들었다는 부분이 가장 재미있으면서도 공감이 갔었습니다. 그 보험사의 프로젝트는 Java의 기초도 잘 모르거나 Copy&Paste가 훌륭한 개발기법이라고 생각하는 개발자도 있었고, 한 메소드에 만라인 넘어가는 코드를 당연하게 여기는 분위기였다고 합니다. 그러다보니 특정 배치처리를 담당하는 사람 외에는 일을 처리할 수 없었기 때문에 담당자가 휴가라도 가면 업무가 중지되고 그 직무에 대한 인력순환도 되지 않는 문제점이 있었다네요. 그런 상황에서 역할별로 클래스가 분리된 Java 배치 프레임웍은 개발자들이 잘 받아들이려 하지 않는 것을 넘어서 처음에는 단체로 데모라도 할 분위기였다고 합니다.

그래서 그 프로젝트에서는 개발자들이 더 쉽게 프레임웍을 적용하기 위해서 Job의 유형에 따른 표준 구조를 정의하고 Job설정을 간편하게 만들 수 있는 FactoryBean을 제공했다고 합니다. 그렇게 유형별로 정의된 구조를 따라서 개발을 하게 하니, Spring의 설정파일을 읽어서 배치Job에 대한 정리된 정보와 통계까지 볼 수 있는 관리화면도 제공할 수 있게되는, 처음에는 생각하지 않았던 장점도 생겼다고 하네요. 저도 프로젝트에서는 같은 유형의 Job의 설정에는 중복코드가 없게 하기 위해서 유형에 따른 FactoryBean을 만들고 bean 설정에서 parent 속성을 이용했었는데, 그런 시도는 스프링배치를 실무에 적용할 때 프로젝트의 특수성을 반영하면서도 간편한 코드를 만들기 위한 필수적인 절차라고 생각되었었습니다.

그리고, 중간의 Wrapping 계층을 두어서 최종 개발자들의 요구사항을 반영할 수 있는 확장점을 만들고, Spring batch의 API변화에 대처할 수 있도록 했다고 합니다. 재미있게도, 이 구조가 ItemProcessor 등 Spring batch 2.0구조와 상당히 비슷해서 프로젝트 내부의 정보가 스프링 쪽에 세어나간 것이 아닌가 하는 농담도 나왔었다고 합니다.[^1]

그 외에도 기술 지원을 위한 프레임웍 운영팀의 역할이 커졌던 점과 프레임웍 적응을 위한 학습기간이 필요했던 점, 천만건 이상의 Skip이 일어날 수 있는 운영계의 데이터 특성이 개발계에서 모두 반영되지 못해서 나중에 대처를 했었던 사건 등을 현장장 있게 전해들 수 었습니다. 아마도 발표로 전달할 수 있었던 것 이상으로 많은 우여곡절들이 프로젝트 중에 있었을 것 같습니다.

제가 작년에 스프링배치에 대해서 어느 세미나에서 발표했을 때, 금융권에서는 많은 배치잡들이 DB에서 Stored procedure로 돌아가고 있는데, 그 만큼 성능이 나오겠냐는 질문을 받았었습니다. 물론 당연히 Store procedure가 속도가 빠르겠지만, 핵심은 '가장 빠르게 처리'하는 것보다는 '업무적으로 필요한' 목표성능을 만족시키는 것이고, Store procedure로만 짰을 때 생기는 개발,테스트,유지보수의 비용 상승이 모든 배치잡에서 감수할 만큼 그만한 가치가 있다고 생각되지는 않습니다.

많은 개발 기술들이 수용되는 과정에서 성능에 대한 염려는 우선적으로 고려되고 있습니다. 하지만, 그런 고려들이 정말 목표성능을 낼 수 없는 기술을 걸려주는 역할이 아닌, 변화에 대한 두려움을 표현하기 위한 수단으로 쓰이고, 실제로 그 성능을 검증해보지도 않고 예단하는 경우도 많습니다. 그러다보면 대부분의 상황에서 성능이라는 것은 충족시켜야할 요구조건, 제약조건일 뿐이지 그것을 최대화하는 것만이 시스템의 목표가 아니라는 것이 숨겨지기도 합니다. 배치시스템에서는 유독 그런 경향이 강했고, 그래서 배치분야에서는 변화의 수용속도가 느리게 보입니다. 2009년 JCO에서 발표된 '차세대 배치시스템 구축 성공전략'의 내용은, 그러한 배치분야에서 시도한 변화에 대한 생생한 증언이였습니다.

정상혁

[^1]: 견고한 하위 호환성을 자랑했던 Spring core 모듈 때문에 생긴 기대치 때문이였던지, 스프링배치 2.0 에서는 너무 많은 부분이 바뀐 것은 상당히 아쉬운 점입니다. 물론 바뀐 API가 더 개선은 되었지만, 1.0부터 그런 것들이 반영되어 있었다면 혼동이 더 적었을 것 입니다. Spring batch 2.0에서 달리진 점에 대해서는 아래에 자료들을 참조할 수 있습니다.