개인적으로는 가장 micro service architecture를 도입 해야 하는 곳이 내부 운영 service 이다.
예를 들면 구성관리, 장애관리, ncsr, 비용처리, 변경관리 등등
해당 service들은 서로 간에 밀접하게 연관이 되어 있어 service의 needs가 변경되는 경우 유연하게 연결되는 부분이 가장 중요하다고 생각한다.
다만, 잘 운영하기 위해서는 전체를 관장하는 부서가 있어야 할 듯하다.
개발팀이 직접 needs를 확인해서 만들게 되면 결국 많이 쓰는 쪽을 위한 service가 되거나 당장의 서비스를 위한 부분이 되어 나중에는 유연성이 떨어져 변경을 할 수 없거나 뭔가의 기능 추가에 소요되는 cost가 높아지는 악순환이 반복될 것이다.
이를 위해 해당 service들에 대한 전체 그림을 그리고 각 service 들의 필요 사항을 정리해주는 architecture 부서의 역할이 필요할 것으로 보인다.
해당 부서는 전체 service 구성도 및 각 service 별 필요 사항들을 현업에 받아 처음부터 전체 환경을 포용할 수 있고 추가로 추후 service 가 커졌을 경우를 대비한 architecture 수립을 하고 각 micro service 사용법 및 기능 개선의 요구를 전달해주는 역할을 하여 service들이 정체되지 않고 개선될 수 있도록 하며 개발팀은 개발에만 몰두할 수 있게 하여 서로 간에 시너지를 낼 수 있게 하면 좋지 않을까 하는 생각을 해본다.
