비즈니스 로직 구현의 문제 - Backend vs Stored Procedure
거의 두 달만에 쓰는 글이네요.
최근에 Governance와 관련된 글을 올렸습니다만, 아직 완결을 하지는 못했습니다. 나중에 시간 여유가 되면 마저 완결하는 방법은 고려하겠습니다.
최근의 IT 기업에서는 시스템을 구축하는 데 있어서, Web Application을 구축할 경우에는 특히, Front-end와 Back-end로 구분해서 개발하고 데이터는 DB에 저장해서 호출하는 형태를 사용합니다. 그리고 주요 Business Logic의 경우는 Backend에서 구현하도록 되어 있고, Front-end는 화면 상에서 표시하는 부분에 보다 중점을 두겠죠.
사실 위에 언급한 것은 굉장히 일반적인 이야기입니다. 그러나 전통적인 시스템을 개발했던 기업, 그리고 이를 유지보수하는 입장에서는 낯선 일일 수도 있습니다.
왜 그럴까요.
전통적 프로그램을 개발했던 기업은 Front-end와 Back-end를 크게 구분하지도 않았고, 주요 Business Logic은 DB단에서 구현하는 경우가 많았기 때문이죠. 사실 데이터 분석가, 관리자 등등이 하는 일도 결국은 SQL Programming이 주된 업무라고 볼 수도 있었고요.
잘못되었다고 생각하지는 않습니다. 10년 전, 20년 전에는 이 방식이 대세이기도 했으니까요.
저 또한 약 10년 전에 지금 다니는 회사에 입사를 해서 대부분 SQL Programming을 했었고 사실 지금도 일부 하고 있기는 합니다. 왜냐하면 회사에서 개발하는 시스템은 거의 대부분 DB의 Stored Procedure에서 Business Logic을 구현하기 때문입니다.
굉장히 구식인 것처럼 보이죠? 하지만 10년 전부터 구축하고 유지보수했던 시스템을 완전히 새로 갈아엎지 않는 한 이를 싹 변경하는 것은 어려운 일입니다. 그렇기 때문에 어쩔 수 없이(?) 계속 사용하고 있는 셈이죠.
하지만 개발 플랫폼이 진화해 가면서 Stored Procedure 방식은 진짜로 구식이 된 것이 사실입니다. 안타깝지만 그렇습니다. 최근의 트렌드는 모두가 아시다시피, Business Logic은 Backend에서 모두 처리하도록 하고, DB는 그저 순수하게 데이터만 저장하고 불러오는 용도로만 사용되어야 합니다. 그것이 트렌드입니다.
그래도 의문을 표하는 사람들이 있다면, 다음과 같겠죠.
“왜 그럴까? DB에서 직접 처리하는 것이 더욱 빠를 수도 있는데?”
그래서 위와 같은 의문에 대한 대답을 하나씩 해 볼까 합니다.
1. Big Data
최근에는 DB가 하는 일이 많아지고 빅데이터로 인해서 데이터 양이 방대해지고 있습니다. 특히 IT로 산업 전반이 개편되면서 데이터는 더욱 쌓이게 되겠죠.
물론 특정 검색을 한다거나 할 때 DB Index를 사용하는 것이 속도 측면에서는 최적화를 가져다줄 수는 있습니다. 그럴 때에는 Index를 사용해서 Query를 하는 것이 맞습니다. 보다 정확히 말한다면, DB에서 수행하는 정규화 작업이라던가. DB Table의 최적화에 필요한 부분은 DB에서 처리하는 것이 맞겠죠. 사실 이러한 정규화 작업이 Business Logic은 아닙니다.
그러나 조금 더, 복잡하고 다양한 연산을 필요로 하는 부분은 Backend로 넘기는 것이 맞을 것 같습니다. 즉 단순히 SQL Query를 하는 부분은 DB에서 수행하되, 이를 가지고 추가적인 연산을 하는 것은 Backend에서. 그렇지 않으면? 데이터가 너무나도 많기 때문에 DB 내에서 처리를 하다가 부하가 걸릴 수 있으니까.
빅데이터가 가장 큰 요소인 것은 바로 DB 처리의 문제입니다. DB에서는 데이터를 저장하고 불러오는 것만으로도 벅찬데, 이에 대한 연산도 수행한다면 더욱 큰 성능의 문제를 가져다 줄 수 있기 때문입니다.
2. NoSQL, RDBMS
최근에는 DB를 RDBMS, NoSQL을 모두 사용하는 경향이 있죠. 물론 이러한 변화는 빅데이터의 활용이 가장 중요한 부분으로 작용하겠고요. NoSQL의 목적 자체가 일관성있는 데이터의 저장 및 검색을 위한 부분이기 때문에 이를 활용하기 위해서는 진짜 검색 그 이상의 목적으로 사용했을 때에는 오히려 효율이 떨어질 수 있습니다. 결국 NoSQL을 활용한다면 Stored Procedure에서 뭔가 Logic을 구현하는 것은 무리가 따를 수 있겠죠.
3. DW, DM, OLAP
다 연관이 있는 부분입니다. OLTP에서 OLAP로 변화해가면서, 원본 데이터를 가공하고 관리하기 위한 부분은 DW(Data Warehouse)나 DM(Data Mart) 등에서 처리를 하도록 되어 있습니다. 그리고 DW나 DM에서 정의된 내용을 가지고 실제 이들 데이터를 사용하고 있는 부서 등에서는 각각에 맞는 Business Logic을 활용하여 구현하도록 되어 있겠죠. DW나 DM의 데이터 자체는 Business Logic은 아니지만, 빅데이터로 인해서 혼재되어 있는 데이터를 보다 정제해서 바로 가지고 올 수 있는 형태로 변환해주는 역할을 합니다.
이러한 데이터 저장 및 검색, 가공 등의 범위가 보다 세분화되면서 Stored Procedure에서 해야 할 부분은 급격하게 줄어들고 있고, 심지어 어떤 Web Application에서는 아예 구현하지 않기도 합니다. 흐름의 변화라 해야 할까요.
Legacy System은 어떻게 개선되어야 하는가
결국 과제는 하나입니다.
기존의 Stored Procedure에 의존하고 있는 시스템을 어떻게 개선해야 할까요.
Client 시스템에서도 사용할 수 있고, 예전에 구축된 Web Application에서 사용할 수도 있습니다. 결국 Migration만이 정답이 될까요.
하지만 단순히 트렌드를 따라가기 위해서 Migration을 해야 한다는 것은 아무런 이유가 되지 못합니다. 경영진의 승인조차도 얻어낼 수 없겠죠.
단계적 개선을 통해서 나아가는 것이 정답에 가장 근접하지 않을까 생각합니다.
시스템 업데이트 시 트래픽에 영향을 많이 줄 수 있으며, Backend를 통해서 개선 가능한 로직을 파악하거나. 신규 시스템을 구축할 때 해당 방법을 적용해서 개발하거나 등이 될 수 있겠죠.
어느 회사든 어느 시스템이든 간에 데이터는 결국 쌓이게 될 것이고, 망하지 않는 이상은 데이터를 어떻게 해서든 비즈니스에 유용한 방향으로 활용하지 않을 수는 없습니다. 그렇다면 결국은 당장은 아니더라도 Stored Procedure에 의존적인 시스템의 경우라면 의존도를 하나씩 줄여가면서 시스템을 개선하는 것이 더욱 나은 시스템으로 개선되고 신규 시스템 개발 및 유지보수에도 도움이 될 것입니다.