시스템을 구축한다면 - (2) DBMS
지난 글에 이어서 두 번째 글을 쓰게 되었습니다.
지난 글: 시스템을 구축한다면 - (1) 사전 고려 사항
0. Intro
일단 시스템을 구축하기 위해서는 그에 맞는 환경을 구축하고 설정하는 것이 우선이겠죠. 물론 앞선 글에서의 사전 고려사항과 같이 예산, 인원, 기간을 고려해서 그에 맞는 환경을 구축하는 것이 중요한 일입니다만, 어떤 환경에서의 구축이 필요할 지에 대해서는 어느 정도 준비는 갖춰지지 않을 수 없다고 볼 수 있습니다.
흔히들 Infrastructure(이하 Infra, 인프라)를 구축하기 위해서 고려해야 할 요소는 일반적으로 다음과 같습니다.
- 애플리케이션 서버(Application Server: AP)
- 데이터베이스 관리시스템(Database Management System: DBMS)
- 네트워크 및 방화벽(Network and Firewall)
- 보안(Security)
- 프레임워크, 디자인 패턴 및 언어(Framework, Design Pattern, Programming Langauge)
- 저장소(Storage)
- 도메인(Domain)
- 형상관리(Configuration Management)
물론 그 외에도 다른 요소들이 있을 수 있습니다만, 일반적으로는 위 범주에서 이루어진다고 볼 수 있습니다.
이번에 쓸 글은 위 요소 중 DBMS를 주제로 해서 써 볼까 합니다. 하지만 인프라의 한 요소에서 DBMS를 어떻게 구축해야 할까를 중심으로 쓰는 것이 아니라, 어떤 시스템을 구축할 것인가에 따른 DBMS의 형태를 중심으로 한 번 구성해볼까 하니 참고 바라겠습니다.
1. DBMS의 변화
DBMS는 예전에는 단순히 데이터를 저장하고, 검색하기 위한 용도가 주요 목적이였습니다. 1990년대 LOTUS, Excel 등이 사실상의 DB였고, RDBMS가 체계화된 이후로는 SQL을 중심으로 해서 Oracle, MySQL, MSSQL 등의 관계형 DBMS, 즉 RDBMS에서 모든 데이터를 관리했었습니다.
그러나 2010년 이후부터는 DB의 트렌드가 다소 달라지긴 했습니다. DB 경량화 자체가 모바일 애플리케이션이 등장한 이후로 하나의 트렌드이자 이슈화가 되었다는 점에서 NoSQL을 사용하는 시스템도 상당수 있으며 이러한 시스템에는 DB에 의존된 데이터보다는 휘발성으로 사용될 수 있는 데이터 관리의 중요성 역시 떠오르게 되었습니다.
하지만 2010년대 중후반부터는 또 다시 변화를 맞이하게 되었죠. 빅데이터, 인공지능, 블록체인 등이 주요 기술로 부각되면서 대용량의 데이터를 관리하고 활용해야 할 필요성이 다시 한번 대두되었습니다.
2. DBMS의 목적
그렇다면 DBMS의 목적은 어떻게 변화되었을까요.
빅데이터가 등장하기 전까지는 위에서 언급한 대로 그저 데이터를 저장하고 불러오는 단일된 형태로 사용되었습니다. 그렇기 때문에 기존에는 DBMS 내 Procedure, Function 등을 통해서 Transaction의 주요 기능을 DBMS 내에서 수행했었죠.
그러나 빅데이터의 등장은 오히려 DBMS의 역할을 줄이는 대신, 다양한 형태의 DB를 구축하여 목적에 맞게 관리하는 형태로 변화되었다고 볼 수 있습니다. 이를 잘 나타내는 부분으로는 DW(Data Warehouse), DM(Data Mart), OLAP(On-Line Analytical Processing) 등을 들 수 있겠죠.
왜 이러한 변화가 있었을까요.
데이터는 쌓이고, 접속자는 늘어나고 관리는 해야겠고 분석을 하면 뭔가 유의미한 내용이 나타날 것 같습니다.
- 쌓이는 데이터: 유의미하게 가공할 수 있는 별도의 데이터 공간을 설정해서 관리한다.
- 접속자 증가: 트랜잭션 처리를 DB에서 다 수행하는 것이 아니라 Front-end, Back-end에서 조절할 수 있도록 한다.
- 데이터 분석: OLAP를 갖추고 유의미한 의사결정을 위한 BI를 별도 구축한다.
다시 요약하자면,
“그동안은 RDBMS에서 혼자 많은 것을 수행했는데, 이제는 DBMS는 데이터만 잘 저장하고 대신 다른 DBMS를 구축하고 시스템을 갖추어서 여러 기능을 분산해서 수행하자.”
정도가 될 수 있겠습니다.
물론 반드시 구축해야 한다는 것은 아닙니다. 소규모 시스템을 구축한다면 이를 검토하는 것이 오히려 비용적인 측면에서 큰 손실을 가져다 줄 가능성도 있기 때문에 주어진 환경에서 어떻게 데이터를 관리할 것인지를 검토한 후에 결정하는 것이 합리적일 수 있습니다.
3. DBMS Transaction 처리
그러나 빅데이터 기반의 DBMS를 구축하지 않더라도, 동시간대 접속자 부분에 대한 고려는 필요할 수 있습니다. 특히 이 부분은 사이트 품질과 직결된 문제이기 때문에 소수의 사용자만 이용하는 시스템이 아니라면 반드시 고려하는 것이 좋습니다.
그렇다면 어떤 방식으로 고려하는 것이 좋을까요.
먼저 DBMS에서 처리해야 할 영역을 먼저 설정합니다. 애플리케이션 서버(AP)라던가, 네트워크 자체에서 처리를 못하고 DB에서 반드시 수행해야 하는 부분은 존재합니다. 어떻게 보면 Core 영역이라고 볼 수도 있겠는데요. DB 처리 영역에 대한 비즈니스 로직을 먼저 전반적으로 구성을 해야 되겠죠.
그런 다음에는 AP서버 내에서 트랜젝션 처리를 위한 대부분의 기능을 구현하는 것이 좋습니다. 특정 용도로 접근했을 때 거부하는 부분이라던가, 예외 처리 부분이나, 또는 몇몇 상황에 대해서 필터링 기능을 적용한다던가 등. 일반적인 기능도 DBMS에서 Back-end로, 그리고 Front-end로 점점 End-user의 상위 단으로 올라가려는 성향이 있기 때문에 트랜잭션 처리 또한 DBMS에서 단독 수행하는 것이 아닌 AP에서도 분담해서 할 수 있도록 사전 고려를 하는 것을 권장하겠습니다.
4. B2B, B2C 시장과 DBMS
그리고 시스템 구축 시 DBMS를 고려할 때 가장 중요한 것은 주요 사업 모델이 B2B냐 B2C냐 하는 부분으로 볼 수 있습니다. 과연 그것이 무엇을 의미하는 것일까요.
일단 B2C부터 보겠습니다.
B2C의 고객은 진짜 말 그대로 일반 고객입니다. 주요 고객 타겟층은 정해져 있지만, 일정한 고객층은 분명 아닙니다.
특히 IT 업체의 경우는 웹 애플리케이션 자체가 주요 매출입니다. 대표적인 경우가 쇼핑몰, 포털 등이 있겠죠. 이러한 업체에서는 웹 애플리케이션에서 발생하는 모든 트랜젝션 데이터가 전부 다 유의미한 정보가 될 수 있습니다. 웹 사이트에서의 제품 목록, 제품 검색, 구매, 반품, 배송이력, 회원정보, 고객지원 등.
IT 업체가 아닌 곳이라도 사실 크게 상황이 다르지는 않습니다. 자동차를 포함한 대부분의 제조 및 판매 업체인데요. 대부분의 매출은 대리점이나 직판(직접판매) 등을 통해서 발생하지만, 판매제품 및 수량, 고객 성향, 지역 등의 다양한 데이터를 보유할 수밖에 없고, 이를 통해서 특정 데이터를 가공해서 고객 맞춤형 서비스를 포함한 여러 형태로 매출 신장을 위한 BI를 제공하는 형태로 나아가고 있습니다.
B2B도 유사할 것 같죠. 냉정하게 말하자면 전혀 그렇지 않습니다.
일단 B2B의 고객은 매우 제한적입니다. 그렇기 때문에 빅데이터 자체를 구축하는 것이 굉장히 어렵습니다. 물론 판매 대행을 위한 대리점에 판매하는 간접판매 형태를 통해서 고객을 다양화할 수는 있습니다.
그러나 딱 거기까지입니다. 관련 글을 한번 살펴보겠습니다.
‘B2C와 다르다’ B2B 마케팅에서 데이터 문제는? - CIO Korea
이 글은 결국 B2B 솔루션 판매를 위한 부분이 아래에 언급되어 있지만, B2B의 한계를 명확하게 나타내 있습니다.
“데이터는 B2B 조직에서 계속해서 문제였다. 무한해 보이는 인터넷의 바다에서 데이터를 수확할 수 있는 B2C 부문과는 달리 B2B 조직은 얻을 수 있는 이익에 상관없이 데이터를 효과적으로 사용할 동기가 거의 없거나 교육을 받지 않은 인간 영업 담당자에 훨씬 의존하고 있다.”
사실 인터넷 검색하면 B2B도 빅데이터, AI를 통해서 고객의 경험 등을 분석하면 된다 등등의 글도 있기는 한데, B2B 업계 IT 종사자인 제 관점에서 봤을 때는 부정적일 수밖에 없고, 그 이유는 위의 문장으로 요약 가능합니다.
그래서 BI가 형식적이고, DW는 꿈도 꿀 수 없을 정도이며, 그나마 OLAP 흉내 정도는 낼 수 있다로 보는 것이 맞지 싶습니다. 그래도 B2B 관련된 데이터를 빅데이터로 활용할 수 있는 기업이 있다면 오라클이나 구글 정도의 글로벌 기업을 들 수 있겠네요.
그러므로 B2B를 할 것이고 관련된 시스템을 구축한다면. DBMS는 고전적인 형태의 RDBMS를 중심으로 해서 OLTP 형태로 처리하는 것이 가장 이상적입니다. DW, DM, OLAP, BI 등은 꿈도 꾸지 마시고요.
4. 마치며
글 주제를 변경하려다 보니까 조금 두서없이 써진 면이 있습니다. 불편한 점이 있으셨다면 양해를 바라겠고요.
요약하자면 아래 정도로 볼 수 있습니다.
- DW, DM, BI를 구축하기 위한 현실적 여건 고려 필요
- Transaction 처리를 위한 범위 지정 여부 및 설정
- 주요 비즈니스 모델에 따른 DBMS 구현 형태
언제나 그랬듯 제 게시물은 정답이 아닙니다. 그냥 제 주관적 의견이 들어간 생각을 표현했을 뿐입니다. 다만 제가 가지고 있는 생각을 공유함으로써 조금이라도 참고가 되었다면 저는 그것으로 만족할 뿐이고, 제 소신을 정리하고자 하는 것이 글을 쓰는 주요 목적이기 때문에 이 부분도 감안하면 좋을 것 같습니다.
글 마치겠습니다.