마이크로서비스 : 특징 첫번쨰 이야기

마이크로서비스 : 특징 첫번쨰 이야기

 

Biz 역량 기반팀

멜빈 콘웨이의 콘웨이 법칙이라는 것이 있습니다. 이는 시스템 개발 시 항상 시스템의 모양이 팀의 구조를 반영한다는 것을 말합니다. 하나의 어플리케이션을 만들기 위해서는 UI팀, 서버개발팀, DB팀과 같은 기능적으로 같은 기술을 가진 팀이 관여하게 됩니다. 따라서 시스템도 같은 모양이 되고, 이런 방식의 팀 구조에서는 아무래도 팀이 다르기 때문에 의사소통의 시간이 오래 걸리게 됩니다.

마이크로서비스를 만드는 팀은 Biz 역량 기반 팀입니다. 이는 역할 또는 기술별로 팀이 별도로 존재하는 것이 아니라
업무 중심으로 보여 기술이 다양한 사람들이 같은 팀을 이루어 서비스를 만드는 것을 의미합니다. 이러한 Biz 역량 기반 팀은 다양한 역할을 가진 기획자, 디자이너, Frontend 개발자, Backend 개발자, 설계자, 테스터 등으로 구성되고,
이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 기술을 갖추고 있습니다.

같은 팀이기 때문에 의사소통도 원활하고 빠르게 진행될 수가 있습니다. 이러한 팀을 여러 기능들이 모여 있다는 의미에서 cross-functional 팀이라고 부릅니다. 자율적으로 해당 Biz에 관련된 서비스를 만들고 운용할 책임을 지닙니다. 아마존닷컴은 이런 팀을 two pizza team이라고도 합니다. 이는 피자 두 판으로 식사할 수 있는 정도의 팀원 숫자를 의미합니다.

마이크로서비스를 만드는 데 필요한 기술을 팀 내부에 모두 가지고 있기 때문에 다른 마이크로서비스 팀과는 크게 연계할 일이 생기지 않습니다. 따라서 콘웨이 법칙에 의해 이 팀이 만든 마이크로서비스도 다른 팀의 마이크로서비스하고는 느슨한 연계를 가지게 됩니다.

 

 

분권 거버넌스

두 번째는 분권 거버넌스입니다. 마이크로서비스 팀으로 구성된 조직은 중앙에 강력한 표준이나 절차의 준수를 강요하지 않습니다. 각 마이크로서비스 팀은 빠르게 제품을 만드는 것을 목적으로 스스로 효율적인 방법론과 도구, 기술을 찾아 적용합니다.

 

 

프로젝트가 아니라 제품

기존까지 대부분의 어플리케이션 개발 모델은 프로젝트 단위였습니다. 즉, 필요한 기술의 인력들이 한시적으로 모여 장기간의 프로젝트를 통해 개발을 하고, 이를 운영 조직에 넘기는 방식입니다. 그러나 마이크로서비스 팀의 개발에서는 운영을 포함한 소프트웨어의 전체 라이프사이클을 책임져야 합니다. 따라서 소프트웨어를 완성해야 할 기능의 세트로 보는 게 아니라 제품으로 바라보고 빨리 개발한 뒤에 반응을 보고 개선하는 방식으로 진행을 합니다. 즉, 프로젝트 형태의 폭포수 모델, 빅뱅 방식으로 개발하는 것이 아니라 반복 모델 프로덕트 중심의 Agile 개발 방식입니다. 약 2~3주의 iteration이나 스프린트를 통해 소프트웨어를 개발하여 피드백을 받을 수 있습니다.

 

 

인프라 자동화

빠르게 소프트웨어를 개발하기 위해서는 개발을 지원하는 자동화 도구가 필요합니다. 마이크로서비스가 화려하게 등장한 이유는 클라우드라는 가상 인프라에 기반을 두고 있습니다.이런 쉽게 활용 가능한 클라우드가 팀의 속도를 높여줍니다. 또한 build, test 배포하는 부분도 팀의 속도와 품질에 많은 영향을 미치기 때문에 자동화가 이루어져야 합니다.

이런 인프라 자동화에는 지속적으로 소스코드를 build하는 도구와 build하며 자동으로 테스트하는 도구 그리고 가상화된 인프라에 자동으로 배포하는 도구들이 모두 필요합니다. 마이크로서비스 팀이 단기간에 프로덕트를 빨리 개발하여 피드백을 받기 위해서는 이러한 개발 지원을 위한 인프라가 반드시 갖추어져야 합니다. 이런 환경은 DevOps를 궁극적으로 가능하게 하기 때문에 DevOps 개발 환경이라고 부르기도 합니다.