케빈 매서니 가트너 시니어 디렉터 애널리스트

[컴퓨터월드] 글로벌 IT 자문기관 가트너(Gartner)는 최근 ‘애자일 아키텍처를 위한 마이크로서비스 설계 방법(How to Design Microservices for Agile Architecture)’이라는 주제로 보고서를 발간했다. 이 보고서는 마이크로서비스 아키텍처(MSA)에 대한 접근 방식을 제안하고, 성공적인 MSA 적용을 위해 고려해야 할 사항을 제시하고 있다. 더불어, MSA의 도입과 가트너가 제안한 방식을 적용했을 때 나타날 수 있는 위험성과 해결 방안을 제언한다. 보고서를 작성한 케빈 매서니(Kevin Matheny) 가트너 시니어 디렉터 애널리스트를 만났다.

▲ 케빈 매서니(Kevin Matheny) 가트너 시니어 디렉터 애널리스트

 

“MSA, 조직의 문화가 준비돼 있어야”

마이크로서비스 아키텍처(MSA)는 기존의 복잡한 모놀리식(monolithic) 체계와는 달리 애플리케이션을 느슨하게 결합된 작은 구성 요소 서비스로 분해함으로써 독립적인 개발, 배포 및 운영이 가능하도록 한다. 이로써 MSA는 애플리케이션 개발 팀이 보다 신속하게 새로운 기능을 제공할 수 있도록 하고, 개발 조직이 커질 수 있도록 지원하며, 서비스가 필요에 따라 신속하고 정확하게 확장되도록 할 수 있다.

그리고 이러한 MSA를 구현하기 위해서는 무엇보다 독립적인 배치, 확장, 운영이 가능한 서비스를 설계할 필요가 있다. 마이크로서비스를 설계하는 기술 전문가는 적절한 인터페이스를 채택하고 서비스를 구현하며, 데이터의 지속성 및 종속성을 관리하는 패턴을 사용해야 한다.

그러나 가트너는 MSA를 통해 민첩성과 확장성이 향상되는 것은 곧 비용을 의미한다고 설명한다. 서비스의 세밀도가 증가함에 따라 ▲다수의 독립적인 파트로 구성된 응용 프로그램을 설계 및 관리하는 데 있어서의 어려움 ▲서비스 지원에 필요한 ‘외부 아키텍처’의 복잡성 ▲분산된 다국어 시스템에서 문제를 해결하는 데 필요한 노력 등과 같은 문제가 증가한다는 것이다.

따라서 MSA를 채택할 때에는 무엇보다 비즈니스를 중심으로 생각해야 한다. 비용은 물론 기술적·조직적 제약 조건을 충족시키는 세밀성과 분해의 올바른 균형을 찾는 것이 목표가 되어야 한다.

케빈 매서니 가트너 시니어 디렉터 애널리스트는 보고서를 통해 “이러한 균형을 찾으려면 완전히 새로운 응용 프로그램을 작성하는 경우에도 대용량 서비스와 응용 프로그램 중심의 배포 모델로 시작하는 것이 좋다”고 말한다.

간단한 응용 프로그램 아키텍처를 구축하고 배포하면, 구성 요소의 세밀성 및 독립성이 향상되고, 민첩성이 향상되는 영역이 보이기 때문에 가장 가치 있는 영역에 개발력을 집중할 수 있다는 것이다.

그러나 특정 기능에 대해 일정한 납기일을 요구하는 경우에는 MSA의 민첩성 및 유연성의 이점을 누릴 수 없다. 이 경우 마이크로서비스는 기술적으로 적합하지 않은 것보다는 문화적으로 더욱 적합하지 않을 수 있다. 조직이 마이크로서비스가 필요하지 않거나, 조직이 투자할 준비가 되지 않았다면 MSA를 채택해서는 안 된다.

케빈 매서니 시니어 디렉터 애널리스트는 이에 대해 “MSA라는 것은 결국 지속적으로 변화가 필요할 때 변화에 빨리 대응하기 위해 도입하는 것이고, 그렇게 해야만 혜택이 생긴다. 그러나 특정 조직이 언제까지 뭔가를 해야 한다는 데드라인을 요구한다면 MSA의 효과를 충족시키지 못한다. 결국 가장 중요한 것은 ‘조직의 문화’라는 것”이라고 설명했다.

가트너가 제안하는 마이크로서비스 설계 접근 방식은 ‘느슨한 결합(loose coupling)’ 원칙에 무게를 둔다. MSA의 이점을 실현하는 열쇠는 가능하면 분리된 서비스를 설계하고 제공하는 것이다. 케빈 매서니 시니어 디렉터 애널리스트는 개발 팀이 ▲제약 조건과 병목 현상을 파악하고 제거할 것 ▲위험을 식별하고 이를 완화하기 위한 조치를 취할 것 ▲기술을 향상시키고 행동을 취할 수 있는 기회를 확인할 것 등 3가지를 주문한다. 그리고 모든 팀이 이러한 관행을 공유하고 포용함으로써 비즈니스 요구사항에 따라 신속하게 애플리케이션을 변경하고 서비스를 개별적으로 확장하는 MSA를 성공시킬 수 있다고 조언한다.

다음은 케빈 매서니 시니어 디렉터 애널리스트와의 질의 내용을 문답식으로 구성한 것이다.


“MSA, 만능은 아니지만 준비돼 있다면 가치 크다”

Q. MSA가 갖는 가치와 현재 위상은 어떻다고 보고 있는가? MSA를 이상적인 지향점 정도로 이해하는 경우가 많은 것 같은데, 실제로 그러한가?

“일부에서는 MSA를 어떤 측면에서 보면 과장됐다고 이야기하기도 한다. MSA는 그 가치가 높긴 하지만, 특정 상황에만 가치를 낼 수 있다고 생각한다. 많은 기업 및 조직들이 MSA를 차세대 애플리케이션 아키텍처라고 생각하고 도입하는데, 그러면 안 된다. 기존의 모놀리식(monolithic)한 아키텍처를 대체한다기보다는 하나의 대안, 또 다른 애플리케이션 개발 방식이라고 봐야 한다. MSA는 아직 완전히 성숙하지는 않았다. 많은 조직들을 살펴보면 MSA를 도입해 성숙된 경우도 있고, 그렇지 않은 경우도 있다. 현재는 전체적으로 성숙 중인 단계라고 볼 수 있다.”


Q. 기업의 개발 및 서비스 환경을 MSA로 전환할 때 주의해야 할 점이 있다면?

“4가지 주의할 점이 있다. 첫째, MSA를 기술적인 프로젝트로만 간주해서 진행하면 안 되고, 비즈니스 가치를 제공하기 위한 것이라는 것을 염두에 두고 진행해야 한다는 것이다.”

“두 번째, MSA가 가치를 제공하기 위해서는 지속적인 애플리케이션의 변화를 신속하게 따라가면서 서비스를 선보여야 하는데, 만약 어떤 조직이 애플리케이션을 개발해 놓고 변화 없이 그대로 가는 경우에는 굳이 MSA가 필요 없다는 것이다.”

“세 번째는 MSA에서 가치나 효과를 기대하기 위해서는 개발이 신속하게 이뤄져야 하는데, 그 전제조건으로 애자일(agile)한 개발, 데브옵스(DevOps)라던가 통합 파이프라인, 테스팅 자동화, 인프라 등이 갖춰져야 한다는 점이다. 이러한 부분이 되지 않으면 전환해봐야 별다른 가치를 갖지 못한다.”

“네 번째는 전환과정이 점진적으로 이뤄져야 한다는 것이다. 모놀리식에서 MSA로 가는 부분에 있어 단계별 접근이 필요하다. 처음에는 큰 부분(macro)에서부터 점점 작은 부분(micro)으로 가면서, 효과를 체크하면서 가야 한다. 얻을 수 있는 가치가 적어지기 시작하면 마이크로로 갈 필요가 없다는 것이다. 때문에 단계적으로 추진해야 한다.”

“일단은 중요한 것이, 너무 많은 변화를 한 번에 주면 실패에 대한 위험부담이 크다는 점이다. MSA를 도입하기 위해 프로세스를 한 번에 너무 많이 변경하면 실제 어떤 게 성공요인이었고 실패요인인지를 판단할 수 없다. 바꿔나가는 요소를 최소화해서 조그만 변화를 단계적으로 주는 것이 중요하기 때문이다.”

“결국 MSA를 통해 애플리케이션 개발의 전개(deployment) 모델을 바꾸는 건데, 이 과정에서 어떤 혜택을 얻으려면 모든 것이 API(Application Programming Interface)에 기반을 두고 이뤄져야만 한다. 그래야만 코드 등을 변경해도 다른 애플리케이션에는 영향 없이 할 수 있다. 그 다음으로 해야 하는 것은 결국 이 API를 활용해 애플리케이션 코드를 재모듈화(remodulization)해 분해하고, 또 재배포하는 모델을 갖춰야 한다는 것이다.”

                                                  ▲ “MSA는 단계적으로 추진하면서 배워나가야 한다”
케빈 매서니 가트너 시니어 디렉터 애널리스트는 너무 많은 변화를 한 번에 주면 실패에 대한 위험부담이 크다며 이 같이 조언했다.


“현업이 주도하고 위에서 지원…‘목표’ 돼선 안돼”

Q. 팀에게 요구하는 세 가지 사항에 대해 좀 더 자세히 설명해 달라.

“세 가지의 경우 데브옵스를 수행하는 개발 팀의 업무방식 특징에 관한 것이다. 먼저 제약 조건과 병목현상을 제거하기 위해 관련 사항을 파악하라는 것은 각 개발팀 간에 종속성이 있을 텐데, 이런 것을 판단해서 어떤 부분들이 우리의 제약 요건인지, 방해 요소인지 파악하라는 것이다. 예를 들어 개발 시 데이터 아키텍처 상에서 종속성 때문에 개발 작업이 늦어진다면 이를 파악해서 해결해야 할 것이다. 데이터 같은 경우라면 DB팀과 지속적으로 아키텍처에 관해 협업하는 방법이 있고, 또는 개발팀 내에서 DB스킬을 가진 사람을 채용하든지, 팀원들이 DB스킬을 배양하든지 하는 방법이 있을 것이다.”

“두 번째는 있는 그대로 ‘위협’이라는 것, 생각지 않았던 잠재적 이슈나 부작용, 실패 등을 파악하고 여기에 대해 조치를 취하는 것을 말한다. 예를 들어 MSA를 선택하게 되면 애플리케이션이 서비스단으로 세분화됐을 때 레이턴시(latency)가 올라갈 수도 있다. 메모리단에서 통합되던 것이 이제는 네트워크단으로 가면서 이런 문제가 발생할 수가 있는데, 그렇다면 이러한 문제를 미리 파악해서 위험을 경감할 수 있는 조치를 취해야 한다는 것이다. 애플리케이션 간 인터랙션을 최소화하는 방향으로 프로파일링한다든가, 또는 기존 애플리케이션과 새로운 애플리케이션의 차이가 어떻게 작용하는지를 파악하고 대응할 수 있을 것이다.”

“세 번째는 예를 들어 애자일 팀 같은 경우, 거꾸로 거슬러 올라가서 개선할 수 있는 부분이 어떤 것들이 있는지를 살펴볼 수 있을 것이다. 지금보다 조금 더 빨리 신속하게 개발할 필요가 있다고 판단된다면, 예를 들어 지연의 이유가 테스팅 때문이라고 판단된다면 시간과 노력을 들여 테스팅을 자동화해야겠다고 판단하는 등 적절한 포인트를 파악하고 액션을 취해야 한다.”


Q. MSA로의 전환을 주도해야 조직은 의사결정자와 현업 개발팀 중 어느 쪽이라고 생각하는가? 그 이유는 무엇인가?

“성공적으로 MSA를 도입하려면 사실 둘 다 중요하다. 경험에 비춰 보면 두 조직이 같이 움직여야 한다고 생각한다. 실제 고객들이 전환하는 여러 가지 실행 단계를 보다 보면, 탑다운 방식으로 할 경우 MSA가 ‘목표’가 되는 경우가 많았다. 앞서 말했듯 MSA가 적절한 가치를 산출하려면 비즈니스 가치를 위한 수단이 돼야 한다. 개인적으로 MSA에 대한 최적의 접근은 현업이 주도하면서 탑에서 적극적으로 지원하는 것이 중요하다고 생각한다. 그렇지 않으면 MSA를 남용하거나, 과대평가되고 목표가 돼서 추진될 가능성이 있다.”


Q. MSA를 이해하는 개발자는 현재 충분하다고 볼 수 있는가? 부족하다면 어떤 해결책이 있다고 생각하는가?

“아직 부족하다. 개발자뿐 아니라 아키텍트, 엔지니어, 매니저, 데이터베이스관리자(DBA) 등도 MSA와 관련해 모두 충분히 이해를 못하고 있다고 생각하고 있다. 해결책이라면 점진적으로, 단계적으로 MSA로 전환해야 한다고 본다. 넷플릭스, 아마존, 길트, 이베이 등 성공사례를 보더라도 이들 역시 굉장히 점진적으로 다양한 레벨에서 MSA를 도입, 실행하고 있다. 완전히 MSA를 하기보다는 이렇게 조금씩 하다 보면 그 과정에서 배우는 것이 생기고, 또 기술을 개발하면서 점차 나아가는 게 최선이라고 생각한다.”

저작권자 © 아이티데일리 무단전재 및 재배포 금지