배치 처리의 중요성

OLTP 기반의 업무가 대부분인 요즘은 Front End-User와 Application의 소통이 중요한만큼 대부분의 개발자들의 관심이 UI, Business Logic, DB 설계등에 집중되어 있다. 개발 경력이 얼마 되지 않은 나조차도 신입 때 자주 볼 수 없던 각종 디자인 패턴등을 이용하여 프로그래밍 하는건 당연한 것이 되었고 FrontController를 필두로 한 MVC 기반의 웹 Application 개발은 마치 원래부터 그랬던 것 처럼 자연스럽게 내재화 되었다.
 
개발자가 Business Logic에만 집중할 수 있도록 이런 디자인 패턴을 제공해주는 각종 Framework가 많이 나오고 있고 이를 원할하게 사용하는 것 자체가 개발자의 능력을 가늠하는 중요한 잣대가 되고 있는 것도 사실이다. 하지만 배치로 눈을 돌리면 상황이 달라진다.

OLTP 기반의 Application에서 필수적으로 병행되는 것이 OLAP이다. 실시간 처리가 중요한 웹의 특성 상 대용량 작업은 데몬 모듈에게 위임을 할 수 밖에 없으며 이를 위해 개발자들은 수 많은 배치 프로그램을 POJO 형태나 Stored Procedure로 작성하여 스케쥴러를 통해 결과를 얻고 있다. 배치 작업은 웹 개발의 그것과는 다르게 화면이 필요한게 아니며 직접적으로 End-User와 소통하는 채널 또한 없기 때문에 쉬운 작업으로 치부되어 왔으며 어렵지 않은 작업으로 생각하여 중요도가 낮은 것으로 판단하는 개발자도 많이 보았다.

그런데 배치 작업은 대용량의 데이터 처리가 이뤄지는 만큼 테스트가 쉽지 않다. 일단 스테이징이나 개발 DB에 운영 DB에 버금가는 대용량의 데이터를 확보하는 작업도 그렇고 처리하는 데이터가 DB의 Row에 국한된다는 보장도 할 수 없다. 어떤 경우는 FlatFile (대표적으로 CSV)로 처리해야 할 경우도 있고 XML로 해야 될 경우도 생긴다. 또한 웹의 경우 명시적인 UI가 있으므로 작업 결과에 대한 확인이 비교적 용이하며 혹여나 미쳐 발견치 못한 Defect도 꽤 빠른 시간내에 찾아낼 수 있지만 배치 작업은 UI가 없으니 다른 사람에게 (예를 들어 QA) 테스트를 맡기기도 힘들며 결국 최종 테스트를 해당 개발자만이 수행하게 되고 이는 결국 프로그램 품질 저하로 이어지게 된다. 대충만 생각해 봐도 알 수 있겠지만 배치 Job의 경우가 실시간 처리보다 더 힘든 작업이며 정교한 설계와 높은 품질을 요구함을 알 수 있다.

그런데 나 같은 경우도 배치 작업을 하면서 "웹 개발을 할 때와 같이 Framework를 사용해서 좀 더 쉽고 품질 높은 개발을 할 수 없을까?"하는 생각은 해보지 않았던 것 같다. 웹 개발이야 사실 요즘은 거의 정형화 된 틀안에서 움직이므로 유지보수도 용이하고 신규 인력 투입에 따른 거부감도 많이 줄어들어 좋은 것이 사실이다. 하지만 배치 개발은 웹 개발의 그것과는 달리 POJO 기반으로 수 없이 개발되고 있다보니 정형화 된 구조가 없어 개발자의 역량에 따라 품질 차이가 하늘과 땅 차이로 날 수 밖에 없다. 그러다보니 다른 개발자의 작업 배치를 유지보수하려면 각자의 성향에 따라 코드가 천차만별이므로 분석의 어려움에 봉착하게 되고 이는 결국 배치의 신뢰성 저하라는 심각한 부작용을 낳게 된다. 운영을 담당하는 개발자들이 출근하여 배치 성공 여부를 매일 체크하고 수동으로 돌리는 어쩔 수 없는 상황을 만들게 되는 것이다. 결국 배치 모듈을 뛰어나게 만든 수고는 모두 개발자에게 돌아가게 되고 이를 위해서라도 배치 Application 자체에 End-User를 위한 로직 뿐만 아니라 우리 개발자들에게 필요한 에러처리, 재시도, 복구, 모니터링, 구조화된 설계 등을 녹여야 함은 두말하면 잔소리다. 

문득 실력도 없는 놈이 수 많은 배치 개발을 발로 했다고 생각이 들어 정해진 틀에서 배치를 쉽게 만들 수 있지 않을까하는 생각이 들어 이것저것 찾아보던 중 역시 Spring Framework에서 Batch 또한 제공하고 있어 이를 이용하여 체계적이고 구조화 된 배치를 개발해 보려고 한다.