ECPJT log-1

지난 2월에 퇴사 후 이커머스 회사에 입사했다. 신규 서비스 개발 프로젝트를 진행 중이고 마이크로 서비스 아키텍쳐 기반의 시스템을 구성 중이다. 회사에 입사해서 사람들만큼 낯설었던게 MSA였다. 이전까지 모노리틱 아키텍쳐 - 사실 모노리틱이란 용어도 한참 후에 알았다 - 기반의 시스템만 경험했고, AWS 서비스를 적극 활용해야 하는 상황이라 낯선게 아니라 이전과 전혀 새로운 환경에 적응, 거의 신입 입사 때 만큼 내가 여태까지 해왔던 경험을 이제 해야할 일에 거의 써먹을 수 없을거란 생각이 들었다.

회사에서 가장 많이 듣는 용어가 ‘MSA’이다. 우리의 프로젝트 아키텍쳐는 MSA, 각 마이크로 서비스를 부르는 단위도 MSA - 회사에선 각 단위 서비스 모듈을 주문 MSA, 결제 MSA 등으로 부른다 - MSA 천지이다. MSA는 뭘까? 웹에서 아키텍쳐에 대한 여러 글을 보았고 아래 목록은 여러번 읽었던 포스트들이다.

• https://www.slideshare.net/Byungwook/msa-52918441
• https://www.popit.kr/%eb%a7%88%ec%9d%b4%ed%81%ac%eb%a1%9c-%ec%84%9c%eb%b9%84%ec%8a%a4-%ea%b4%80%eb%a0%a8-%ea%b8%80-%ec%b4%9d%ec%a0%95%eb%a6%ac/
• https://medium.com/coupang-tech/%ED%96%89%EB%B3%B5%EC%9D%84-%EC%B0%BE%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%9A%B0%EB%A6%AC%EC%9D%98-%EC%97%AC%EC%A0%95-94678fe9eb61

웹에 올라온 관련 포스트들을 읽어보면 대부분 모노리틱 아키텍쳐 기반으로 서비스를 개발/운영 하다 어떤 이유로 인해서 마이크로 서비스 아키텍쳐로의 전환을 고려하게 된다. 그 이유는 아래와 같다. 이 외에도 많은 이유가 있을 것이다.

• 단위 서비스 모듈 간의 의존성을 낮춤
• 자유로운 스케일링(In/Out)
• 서비스 배포의 자유로움

그런데 이번 프로젝트는 MSA 기반으로 프로젝트를 시작한다는 것이다. 마이크로 서비스 아키텍쳐는 많은 장점이 있다. 대규모 서비스의 리소스 스케일링이 자유롭고 새로운 서비스를 추가하거나 사용하지 않는 서비스를 제거하는 것도 모노리틱에 비해 쉽다. 하지만 모노리틱 아키텍쳐도 장점이 있다. 개발 기간에 비교적 빠르게 개발할 수 있다. 하나의 프로젝트 소스코드를 가지고 작업을 하기 때문에 다른 모듈에서 어떤 일이 일어나는지 쉽게 확인할 수 있다. 그에 비해 마이크로 서비스는 고민해야 할게 많다. 회사마다 다르겠지만 기본적으로 MSA는 프로그래밍 언어부터 내부 동작방식까지 각 서비스 모듈에서 책임지고 개발한다. 이 말은 주문 서비스에서 자바와 스프링을 이용해서 웹서비스를 개발했지만 상품 서비스는 파이썬에 NoSQL을 써도 서로 신경쓰지 않는다는 것이다. 단 하나 통일해야하는 것은 서비스간 통신 규격이다. 서로 약속한 규칙에 의거한 통신만 이루어지면 내부에서 어떻게 작동되던 신경쓰지 않는다. 그건 각 팀 혹은 모듈에서 책임진다. 그래서 각 서비스 모듈 구성원에는 서비스 기획자부터 개발자, DBA 등이 포함될 것이다.

MSA는 정답이 없다. 로마로 가는 길이 여러가지가 있고 이 말은 사람들이 이해하는 MSA도 천차만별이라는 것이다. 내가 생각한 개념과 옆 사람이 생각한 개념이 다르기도 하다. 이 프로젝트는 MSA이다. 그리고 데이터 관리자, 인프라 관리자, 개발자 모두 다른 조직이다. 그리고 서로가 생각하는 MSA가 모두 다르다. 그리고 기존에 있던 구성원들도 MSA 프로젝트가 낯설었다.