참고 : 이하 글은 네이버 카페 - DBian 포럼에 게시한 MSA를 DB엔지니어 입장에서 봤을 때 에도 게시된 글입니다.
Microservice Architecture. 이 키워드가 핫해서 저도 잠깐 찾아봤던 기억이 납니다. DB엔지니어 입장에서 느끼는 점을 써보겠습니다.
(아래 수영초보님 댓글의 링크 자료가 좋네요- https://www.slideshare.net/Byungwook/msa-52918441 위 이미지는 해당 슬라이드 중 발췌)
제가 알고 있는 MSA의 특징은 이렇습니다.
- 시스템을 작은 단위의 시스템들로 만든다
- DB는 논리적 또는 물리적으로 분리될 수 있음
- 각 단위 시스템 간의 통신은 주로 API를 이용
MSA가 핫하다고 해서 살펴봤는데, DB엔지니어 입장에서 볼 때 그리 좋아 보이지는 않습니다. 특히 DB가 논리적으로 또는 물리적으로 분리한다는 부분. 이해하기 힘듭니다. 기업의 메인 시스템으로 따져보면 고객, 상품, 주문, 배송, CS등을 모두 별개의 시스템으로 만든다는 건데요. 같은 DB에 존재하며 함께 조인되어야 빛을 발할 테이블들이 격리되어서 논다는 것이 이해가 안됩니다. 또 API를 통한 통신이라니… 같은 집에서 다른 방을 갈 때 안방 창문으로 나가서 작은방 창문으로 들어오는 모습이 그려집니다. 대량 데이터를 조인하는 것은 어떻게 할 것인지? 흔히 말하는 표준화 같은 경우는 포기하는게 나을 수도 있습니다. 아니 개발 언어나 프레임워크 조차 다른 경우도 있는 것 같습니다.
MSA로 개발한다는 것은 확실히 지금까지의 방향에 역행하는 느낌입니다. 시대적으로 봤을 때, 90년대는 업무 전산화의 시대라 생각합니다. 수기 업무들이 수많은 시스템들로 탄생되었죠. 2000년대는 이런 시스템들을 통합하는 시대였고요. 특히 엔터프라이즈 들의 SI가 유행처럼 번졌죠. 여러 단위 시스템을 통합 관리하면 이득이 훨씬 많았기 때문에 시스템 통합은 대세였습니다. 말그대로 차세대와 SI의 시대였죠. 한 회사가 차세대를 하면 나머지 회사도 줄줄이 차세대를 하는… (DB 엔지니어도 이런 때가 가장 호황기가 아니었나 싶습니다. 특히 데이터 모델러의 몸값은 치솟았죠. 여러 시스템을 통합하는 기술은 초고급 기술에 속했고요. 통합에 수반되는 데이터 표준화부터 모델링 이행은 호황기였다고 봅니다.)
이렇게 시스템이 통합하는 것은 비즈니스 트랜드가 그러하기 때문이라고 봅니다. 과거에는 비즈니스라는 것에 대한 어느정도 틀이 있었습니다. 보통 산업이라고 부르는 제조, 금융, 공공, 유통같은 분야별로 말이죠. 제조를 예로 들면 공정 프로세스같은 것은 꽤 변하지 않는 비즈니스 프로세스입니다. 대신 규모, 속도, 효율성 등이 사업의 성패를 좌우했죠. 시스템도 그런 식으로 구축이 되었고요. DB모델의 경우에도 최대한 유연하게 오래 사용할 수 있는 데이터 모델을 만들기 위해 노력했습니다. 시스템은 개발하기 힘들고 DB는 더욱 변경이 힘들기 때문이죠. 이 시기엔 분석/설계 단계에서 생각하지 못했던 기능을 구현하는 것은 그냥 죄악이었습니다. 차세대 프로젝트에서 반영하지 못한 기능들은 차기 프로젝트에 반영하기를 기다릴 수 밖에 없었죠. 어쨌건 DB는 차세대 간의 기간(5~10년)정도는 쓸 수 있게 만드는 것이 중요했습니다.
하지만 지금은 이런 트랜드가 많이 바뀌었습니다. 미래의 먹거리가 없다는 말을 하는데, 향후 뭘 해야 기업이 지속될 지 알기 힘든 때가 된거죠. 10년은 커녕 3년을 내다보기 힘듭니다. 각자 자기의 산업에서 탈피하려고 합니다. 통신회사는 통신만으로 먹고 살 수 없다 판단하고, 신용카드회사는 신용카드만 해서는 안된다고 판단합니다. 다만 기업의 규모때문에 그만큼 느릴 수 밖에 없죠.
지금까지의 개발방법론이라고 하는 것은 현업이 뭘 요구하는지를 잘 명세화하는 요구공학부터 시작했습니다. 현업이 비즈니스는 잘 알지만 IT적이지 못해서 요구사항을 IT적으로 풀어내는 것이죠. 지금은 그 현업이 뭘 해야 할지를 모르는 상황입니다. 지금같은 상황에서 큰 돈을 들여 10년을 쓸 시스템을 1년간 분석-설계-개발-테스트하면서 만들 여유 뿐 아니라 이유가 없어지는 것입니다. 차라리 이런저런 아이디어로 시스템을 10개정도 개발새발 만들어서 반응이 좋은 1개를 밀고 나가는 작전이 생존률이 훨씬 좋아 보입니다. 방송에서 파일럿 프로그램 하듯이 말이죠. 이런 트랜드가 MSA같은 아키텍처를 밀어주고 있다고 봅니다.
MSA도 다른 개발 트랜드처럼 어느 순간 없어질 수도 있다고 봅니다. 하지만 이런 트랜드를 이해하고 어느정도 대응하는 것은 필요할 것 같습니다. 아키텍처는 DB엔지니어에게 불편해졌지만, 그래도 편하게 쓸 수 있도록 만들어야 하는 숙제가 생긴 것이죠.