MSA란? - PM의 개발공부

MSA

저희 회사는 운영중인 제품이 여러개 있습니다. 그 중 신사업으로 밀고 있는 프로젝트는 기존에 PHP로 되어있던 커머스 사이트와는 다르게 MSA 구조로 되어있다고 합니다.

 

하지만 개발을 아주 조금 알고 있는 저에겐 생소한 단어였는데요, 그래서 이번주엔 MSA가 무엇인지 알아보았습니다.

 

우선 자료를 찾아보기 전에 개발팀장님께서 설명해 내용을 토대로 생각했을 때, MSA는 PHP처럼 하나의 언어만 사용해서 만드는 것이 아닌 각 개발자가 각자의 언어로 파트를 나누어 개발하는 것인 것으로 이해를 했습니다.

 

 

그래서 정확히 MSA가 뭔데?

MSA는 Microservices Architecture의 약자라고 합니다. 즉 하나의 큰 서비스가 아닌 작고 독립적으로 배포 가능한 마이크로 서비스 단위로 나누는 소프트웨어 개발 방식을 말합니다. 이 개념은 복잡하고 큰 시스템을 더 잘 관리하고 확장하기 위해 사용한다고 하네요.

 

각각의 작은 서비스들은 특정 비즈니스 기능을 수행하며, 서로 간에는 정의된 API를 통해 통신합니다. 

 

듣고 보니 그렇네요! 저희 서비스도 배포할 때면 각 팀에서 "ㅇㅇㅇ 배포진행합니다" 같은 내용을 공유하고 배포했는데, 아마 이런 이유 때문이지 않았을까 싶어요.

 

MSA의 반대 개념, MA

그럼 PHP처럼 하나의 언어로 전체 제품을 만드는 것은 뭐라고 할까요? 그런 방식은 우리가 전통적으로 해왔던 방식으로 하나의 구조로 되어있다는 뜻인 모놀리식 아키텍쳐(Monolithic Architecture, MA)라고 합니다.

 

비개발자의 입장에서 그냥 생각했을 땐 '오히려 하나의 언어를 사용하는 게 단순하지 않나?'라고 생각했습니다. 왜냐하면 각 파트를 나누어 진행하면 개발할 때야 쉬울 수 있겠지만 유지보수가 어려울 것이라고 생각했어요. PHP 개발을 하는 5명이 모여서 PHP로 제품을 만들면 어떤 특정 기능을 만든 사람이 휴가를 썼을 때 오류가 발생하더라도 다른 사람이 그 구조를 파악해서 처리할 수 있지 않나?라고 생각했어요.

 

그렇다면 왜 MSA라는 개념을 사용하는 것일까가 궁금해졌습니다. 제가 오히려 반대로 알고 있는 거더라구요.

 

MSA의 장점

MSA는 서비스를 작게 나누어 각자 개발하는 것이기 때문에 개발 구조가 아주 유연합니다. 실제로 저희 서비스에는 여러 앱이 있는데, 배포를 할 때 같은 타이밍에 하긴 하지만, 배포가 필요한 앱만 배포를 했습니다.

 

그 뿐 아니라, 각자가 구조를 이룬 것이기 때문에 한 부분의 서비스가 다운되더라도 나머지 부분은 문제 없이 작동한다는 장점도 있습니다. DB도 각자 자체 DB를 가지고 있어 데이터의 정상성/정확성도 보장됩니다.

 

실제로 제가 참여해서 개발했던 앱에서 DB 내 계정을 지웠는데, 중앙에서는 계정이 남아있더라구요. 중앙 DB에서 다시 지워야 했답니다. (계정 삭제를 기능으로 만들어 놓은 상태라면 중앙에서도 지워지도록 해놨겠지만, 아직 그 기능은 없어서 DB에서 직접 지웠습니다 :))

 

 

그럼 반대로 MA를 채택하는 경우는 왜일까요?

 

MA의 장점

MA는 하나의 애플리케이션으로 되어있기 때문에 단순합니다. 그렇기 때문에 개발 뿐 아니라 테스트를 하거나 디버깅을 하는 것도 편리합니다. 

 

MSA vs. MA 뭘 선택해야할까?

두 경우 모두 겪어본 입장에서 이야기하자면 서비스의 규모도 중요하지만 구성원간의 커뮤니케이션 정도도 중요하다고 생각합니다. 제가 위에서 언급한 신규 프로젝트의 경우 규모가 커서 어쩔 수 없이 MSA 구조를 선택하긴 했지만, 만약 내부 인원들끼리 커뮤니케이션이 잘 되지 않는다면 개발 속도가 오히려 뒤쳐질 수 있다는 생각이 들었습니다. 결국 하나의 프로덕트를 만든다면 같이 하는 건 MSA든 MA든 똑같은 건데, 자칫하면 MSA가 대기업에서 각 파트가 나뉜 구조처럼 되어 미스커뮤니케이션 혹은 커뮤니케이션의 딜레이가 발생할 수 있겠다는 생각이 들었어요.