서비스 규모는 별로 중요하지 않다

마이크로서비스라는 용어는 ‘마이크로(micro, 작은)’라는 어감이 제일 먼저 귀에 꽂히는 것이 문제입니다. 왠지 서비스를 아주 작게 만들어야 할 것 같은 느낌이 들기 때문이죠. 미니 서비스(miniservice), 나노 서비스(nanoservice) 등 크기를 바탕으로 만든 용어들도 그렇지만, 사실 크기가 중요한 것이 아닙니다.

크기보다는 작은 팀이 가장 짧은 시간에, 다른 팀과 협동하는 부분은 최소로 하여 개발 가능한 서비스를 설계해야 합니다. 이론적으로는 한 팀이 한 서비스를 맡을 수도 있는데, 이런 경우라면 마이크로서비스가 ‘마이크로’하다고(작다고) 볼 수 없겠죠. 반대로 대규모 팀을 꾸려야 하거나 서비스를 테스트하는 시간이 너무 오래 걸리면 팀과 서비스를 분할해야 합니다. 다른 서비스의 변경분 때문에 내가 맡은 서비스도 계속 바꾸어야 한다거나, 내 서비스 때문에 다른 서비스가 바뀌어야 한다면 서비스가 느슨하게 결합되지 않았다는 반증입니다. 아니면 분산 모놀리스(distributed monolith)를 구축했기 때문에 그럴 수도 있습니다.

마이크로서비스 아키텍처는 작고, 느슨하게 결합된 서비스로 애플리케이션을 구성하기 때문에 유지보수성, 테스트성, 배포성 등 개발 단계의 품질 속성이 개선됩니다. 또 조직 차원에서 소프트웨어를 더 빨리 개발할 수 있고, 주된 목표는 아니지만 애플리케이션 확장성도 향상됩니다. 여러분이 마이크로서비스 아키텍처를 고민 중이라면 먼저 현재 애플리케이션의 서비스를 어떻게 식별하고 서비스를 서로 협동시킬지 결정해야 합니다.