RESOURCES

선 포스팅에서 클라우드 매니지드 서비스에 대한 견해를 적은 바 있습니다. 어쨌든 요새 트렌드는 IT, 클라우드, 빅데이터, 인공지능 및 머신러닝이 가장 많이 언급이되며 화두가 되는 단어라고 생각되는데, 그렇다면 실제로 기업을 운영하는 분들이라면, 회사가 자사의 서비스나 운영 시스템을 좀 더 민첩하고 효율적으로 구성하기 위해 어떤 부분이 준비가 되어야 하는지 실질적인 고민에 직면하게 됩니다. 쉽게 말해 Agile한 IT환경을 만들기 위해 어떤 부분이 준비되면 좋을 지, 이번 블로그에서 한번 구성해보고자 합니다.

 

 

 

특히나 요즘 코로나로 인해 다양한 산업내 변화가 있는데, 사실 IT업계(인프라, DevOps, SaaS솔루션 등)에서 이 부분에 대한 변화가 더 크게 느껴집니다. 이런 예상치 못한 변수로 인해 IT업계에서는 Agile하고 효율적인 방법으로 업무를 보고 프로젝트를 진행하는 부분에 대한 디지털 혁신(DT: Digital Transformation)이 가속화 되고 있습니다.

 

흔히들 얘기하는 클라우드 네이티브(Cloud Native: 태생이 클라우드로 구성된 환경을 정의) 애플리케이션 혹은 마이크로서비스로의 전환이나, 기업 내 DevOps(개발과 운영을 하나로 고려하여 운영하는 방식 혹은 조직을 의미)팀을 구성하여 민첩하게 프로젝트를 하는 등의 다양한 논의가 이루어지는 상황입니다.

 

이러한 화두와 트렌드를 바탕으로 기업내 IT의 예상되는 변화와, 대내외적 불확실한 상황에서 IT를 안정적으로 운영하기 위한 내용을 살펴 보고자 합니다.

 

글에 앞서, 해당 블로그 구성에 많은 인사이트를 주신 AWS Digital Native 고객들을 담당하고 계신 박경표 솔루션즈 아키텍트, 그리고 VMWare Tanzu Korea의 김영태 대표님과 이정인 매니저님께 감사의 말씀을 드립니다.

 

 

 

1. 기업 내 Agile한 IT환경 및 서비스 구성

1) Agile이 현재 주목 받는 이유는 무엇인가?

 

Agile 환경을 논의하기에 앞서, 먼저 Agile 개발 방법론에 대한 얘기를 해보고 싶습니다. Agile 개발 방법은 우리가 예전에 많이 사용해 왔던, 폭포수 모델의 단점을 극복하기 위해, 대두된 내용입니다. 폭포수 모델은 긴 개발 사이클과 잘못된 초기 계획 설계로 인하여, 최종 소비자 전달 단계에서 크나큰 손실을 볼 수 있다는 단점이 있습니다. 이 부분은 해당 하는 방법론이 만들어진 시대적인 특성과 관련이 있습니다.

 

아직 수작업과 관행적인 업무 프로세스가 진행되는 1960~1980년대에, 실제로 업무 프로세스 라던가, 비즈니스 접근 방식 자체의 변경은 그리 크지 않았습니다. 이럴 경우, 문제가 되는 부분은 초기 요구 사항에 대한 면밀한 탐사, 이를 바탕으로한 정밀한 설계, 그리고 대규모 프로젝트를 위한 통합 설계 및 일정 계획 등이 가장 중요한 요소로 측정되었습니다.

 

하지만, 최근 비즈니스 상황을 보면 알겠지만, 일년 전과 동일한 서비스 및 동일한 비즈니스 환경으로 구성된 곳이 얼마나 될까요?

 

특히, B2C환경에서의 서비스는 매일매일 새로운 서비스와 사용자 유인요건을 제공하지 않으면, 바로 순위에서 밀릴 수 있는 환경이 지배하고 있습니다. Amazon.com의 경우에도 서비스의 분리 및 개별 서비스의 지속적인 개선을 통해 새로운 기능을 지속적으로 고객들에게 전달하고 있습니다.

 

이를 극복하기 위해, 서비스를 세분화 하고, 세분화된 서비스에 대하여, 새로운 고객 요구 사항을 반영하기 위한 기민한 개발 방법이 필요하며, 이를 위한 Agile 방법이 각광 받게 되었습니다.

 

그런데, Agile 방법 자체를 보면 알겠지만, 고객이 필요로 하는 요구사항을 “가정 – 이게 성공할지, 실패할지 아무도 모르는” 하고, 이를 빠르고 안전하게 구현해야 했습니다. 사실 성공한다면 다행이지만, 만약 그렇지 않다면, 매몰 비용(Sunken Cost)에 대한 최소화를 고려해야 하고, 또한 빠르게 구성하기 위해서는 이미 Ready Made되어 있는 Library, Framework, Service의 사용이 거의 필수적입니다.

 

이를 위해서, Agile개발 환경에 대한 중요성이 더욱 커지고, 빠른 접근 및 필요한 시점에 Resource를 빠르게 제공 받고, Scale을 올리고, 검증된 솔루션을 통한 빠른 개발 환경이 필요하게 된 것입니다.

 

가만히 보면 다들 느끼겠지만, 빠른 접근, 필요한 자원에 대한 빠른 수급 및 확장, 검증된 Managed Service는 바로 일반적인 클라우드의 특성이기도 하기 때문에, Agile 개발 환경으로 클라우드가 각광 받게 된 것이고, 실로 뜨거운 관심을 받고 있습니다. AWS의 경우에도 고객 비즈니스의 성공을 위해서 고객들이 요청하는 사항을 중심으로 새로운 서비스 및 환경을 제공하여 고객들의 성공을 지원하고 있습니다.

 

 

 

2) Agile한 환경 구성을 위해, 각 회사(조직)의 팀/문화/기술 관점에서 준비되야 하는 내용

<조직/문화 관점>

게임 업계, 이커머스, IT업계는 비교적 Agile 환경에 익숙하고, 가장 빠르게 Agile 문화에 적응한 분야입니다. 하지만, 최근에는 금융, 제조와 같은 전통적인 분야에서 Agile을 받아들이고, 확산하는 부분에서 많은 시도들이 일어나고 있습니다. 특히, 전통적인 업권에서는 수십년 동안 쌓여온 Legacy때문에, 디지털 시대의 변화와 흐름에 대처하고, 스스로를 변혁하는데 어려움을 겪고 있습니다. 이 부분에 Focus하여 얘기를 풀어보겠습니다.

 

Digital 제품을 얼마나 매력적으로 만들어 내느냐는 결국 제품을 기획/개발하는 팀을 어떻게 조직하느냐로 귀결됩니다. 이를 위한 조직을 Balanced Team이라고 하는데, PM, 디자이너, 개발자가 각각의 조직에 속해있는 것이 아닌 하나의 Balanced Team이라 불리우는 5-6명 정도로 구성된 2-Pizza팀에 속해있는 것이 특징입니다. 이는 기존의 Silo형태에서 벗어나서 커뮤니케이션 단절 현상을 없애고, 공동의 목표를 향해 가는 거라 볼 수 있습니다. 

 

또한, 이 팀은 최대한의 자율성을 부여해야 합니다. 매니저는 보고만 받는 형태가 아닌, 사업 추진에 있어서 식별된 Blocker들을 제거해주는 역할을 담당하게 됩니다. 이러한 환경에서는 Lean방법론, Extreme Programming, 유저 중심적 디자인(UCD) 등을 실천하기에 매우 효율적일 수 밖에 없습니다. 처음부터 이런 Agile하고 효율적인 조직을 구성하기는 어렵습니다.

 

이러한 사상을 조직 전체에 Big Bang형태로 주입시킬 수도 없습니다. 소규모로 Balanced Team을 구성하고, 하나의 성공적인 레퍼런스 케이스를 만드는 것이 중요합니다. 또한, 이렇게 성공한 케이스를 바탕으로 2팀, 4팀, 8팀으로 조금씩 성장시키는 것도 중요합니다. 이렇게 하기 위해서는 Seed Team을 키워내는 것에 많은 집중을 해야 합니다. 그러므로, 훌륭한 파트너와 함께 초기에 기반을 잡아 나가는 것이 매우 중요할 것입니다.

 

마지막으로 한 가지 더 강조하고 싶은 것은 팀 구성원들의 Mentality가 매우 중요합니다. 이를 위해서는 Psychological Safety가 중요합니다. 즉, 심리적인 안정성인데, 내가 어떤 일을 추진하더라도 예상되는 비난 때문에, 그 동력이 꺾이면 안된다는 것과 비슷합니다.

 

이를 위해  Amazon과 같은 경우엔, Leadership Principle에 “Have Backbone”과 같이 나의 의사를 용기 있게 관철시킬 수 있는 안전장치를 마련해 놓았습니다.

 

또한, Google의 경우에도 이러한 부분이 팀의 생산성에 매우 많은 영향을 미치고 있다는 것을 알고 있습니다. Google 내부 여러 조직 중에 효율성이 높고 성과가 높은 팀과 그렇지 않은 팀을 비교해서 어떤 부분에서 차이가 났는지를 Research한 프로젝트가 아리스트텔레스 프로젝트입니다. 이 프로젝트에 따르면 Psychological Safety가 이 팀들을 차별화하는 가장 Fundamental한 요소라고 보고 있습니다.

 

정리하자면, 팀의 구성원, 체계, 점진적인 확장에 대한 견해 그리고 구성원들의 Mentality까지 풀어 보았습니다.

 

 

<기술 관점>

먼저 애플리케이션 측면에서 살펴 보겠습니다.

 

위에 살펴본 Balanced Team을 운영하게 되면, 각각의 Balanced Team은 빠른 속도로 팀 내부의 커뮤니케이션을 통해 제품을 만들어내게 됩니다. 이 때, 다른 팀의 코드에 영향을 많이 받는다던지, 배포를 함께 해야해서 릴리즈 사이클에서 팀이 원하는 속도를 못 낸다던지 등의 이슈가 생길 수 있습니다.

 

이것을 해결하기 위해, 마이크로서비스 아키텍처를 최근에는 많이 도입하고 있습니다. 기존의 모노리틱 형태로 커다란 애플리케이션을 여러 팀의 개발자가 함께 했다고 하면, 이제는 그것을 각각의 애플리케이션으로 나눠서 개발 하고, 서로간의 연계는 API로 하는 것입니다. 이렇게 되면 API변경만 없다면 각각의 애플리케이션 팀이 다른 팀의 Dependency없이 코드 변경을 하고 개별적으로 릴리즈 할 수 있게 됩니다.

 

이번엔 플랫폼 측면에서 생각해보겠습니다.

 

여러개의 팀이 제각기 릴리즈를 여러번 하게 된다면, 기존의 인프라 운영 방식으로는 도저히 그 속도를 지원할 수가 없습니다. 전통적인 방법을 살펴보면 애플리케이션이 배포되려면 테스트 사이클을 거치고, 운영팀이 받아서 사용량이 적은 한 밤중에 배포할 때가 종종 있는데, 이는 너무 많은 시간과 노력이 들어가기 때문에, 한 달에 1번 정도 할까 말까라고 생각됩니다. 새로운 방식을 적용 하지 않고는 원하는 속도를 낼 수가 없는데, 이 때 DevOps라는 컨셉이 나옵니다. 운영팀이 다 해줄 수 없으니 개발팀이 애플리케이션을 배포하고 운영하게 되고, 운영팀은 쉽게 애플리케이션이 배포되고 모니터링이 가능한 플랫폼을 구성해주고 잘 관리해주는 역할을 맡는 것입니다. 이는 플랫폼 팀이라 부르고, Google에서는 SRE(Site Reliability Engineering)팀이라고도 부릅니다. 플랫폼 자체는 이런 소규모의 플랫폼 팀이 효율적으로 운영이 가능하게 만들어져야 하는데, 그렇게 하기 위해서는 많은 부분이 자동화되어 운영되어야 합니다. 플랫폼의 패치나 업그레이드가 플랫폼 내부에서 자동으로 이루어진다던지, 서버 확장 등도 수작업 없이 실행되어야 합니다. 애플리케이션 팀에게 필요한 기능들도 많은데, 일단 자주 배포하려면 서비스에 지장을 주지 않고, 배포하는 것이 중요한데, 이럴때 블루그린배포 방식 등이 많이 쓰이고 있습니다. 이런 기능들이 플랫폼에서 제공이 되어야 하는 요소입니다. 또한, PaaS플랫폼에 애플리케이션이 배포되려면 컨테이너 이미지가 필요한데, 이것을 개발자들이 직접 만들게 되면, 보안에 대한 리스크를 가져갈 수 있고, 향후에 이러한 이미지에 포함된 JDK나 스프링 라이브러리 등의 버전이 업그레이드 되었을 때, 일일이 변경을 해줘야하는 불편함이 있습니다. 이러한 이미지 생성 작업은 플랫폼이 내부적으로 실행되어져야 보안 취약점이 최소화 되고, 관리의 편리성을 가져갈 수 있게 됩니다.

 

마지막으로 클라우드 인프라 관점에서 얘기해 보겠습니다.

 

보통 IT관리자나 엔지니어들은 “우린 Agile한 개발을 수행하고 싶어, 어떤 기술을 활용하면 될까?” 등의 공통된 요구나 문의를 하는 경우가 있습니다. 실은, 여기에 고정된 서비스 솔루션이 존재한다고 보기는 어렵습니다. 위에 설명한 팀/문화/기술에 대한 부분과도 일맥상통하는 부분인데. 각 회사가 갖고 있는 내부 역량과 방향성이 일치되는 서비스를 중심으로 접근하는게 가장 합리적이라 생각합니다. 예를 들어, 스타트업이 초기 단계이고, 단일 서비스 개발에 방점을 두며, 개발팀이 신규 기술에 대한 선호도가 높다면, Serverless서비스를 적극적으로 활용하는 방법을 추천해 볼 수 있습니다.

 

또한, Data Layer에 개별 서비스의 특성에 맞는 Database, 예를 들어 연관 관계 검색에 특화되어 있는 Graph Database인 Neptune, 시계열 분석 저장을 위한 TimeStream등을 이용할 수도 있으며, 서비스 복잡도나, Scalability 측면에서 DynamoDB와 같은 NoSQL로 접근하는 것도 향후 대규모 서비스 제공 측면에서 유리할 수 있습니다.

 

만약, 내부에서 이미 Chef, Puppet 등 과 같은 대규모 Provisioning Management  도구들을 잘 활용하고 있고, 조직 구성상 Infra Control이 필요하며, 기존 Software Architecture를 재활용하면서, 빠르고, 최신의 배포방식을 반영코자 한다면, Elastic Beanstalk을 활용하는 것도 좋은 방식이 될 수 있습니다. 이럴 경우, 큰 변환 없이 블루그린배포, 카나리 배포 등을 이용하여, 좀 더 안정적인 서비스를 운영할 수 있습니다. 예를 들어, 삼성 프리턴 사업부의 경우, 운영팀의 큰 도움 없이, 개발자로 이루어진 사업부에서 Elastic Beanstalk을 이용하여, 몇 달만에 서비스를 런칭하기도 했습니다.

 

사용자 관점에서 Cloud에서의 Agile한 환경을 마음껏 누리기 위해서 AWS에서는 다양한 서비스를 제공합니다. 이는 시스템 서비스를 포함하여, Microservice Architecture로의 전환을 고려하거나, 상용 Database에서 Open source database로의 전환을 고려하는 상황이라면, ProServ의 컨설팅/프로젝트 서비스를 이용하여, 좀 더 원활하게 목표로 하는 구성을 진행할 수 있습니다.

 

 

 

2. 기업의 Agile한 환경 구성을 통해 Digital Transformation(DT)를 구현한 사례

영국에 있는 CYBG은행 – 요크셔, National Australia Bank,  Clydesdale, Virgin Money에서 좀 더 혁신적인 서비스를 구현하고 싶어 했던 사례가 있습니다. 즉, 실제 창구에 오는 고객 군의 동선, 인원, 고객 만족도, 성별/나이 등을 실시간으로 분석하고 이를 통해, 고객에게 최상의 서비스를 제공하고 싶어 했습니다.

 

이를 위해 Finance고객이라면, 실제 구현 경험이 많지 않았던, AWS IoT서비스와 Data Analytics 환경을 이용하여, 각 지점 상황을 실시간으로 모니터링 하며, 이를 분석하여 실시간으로 고객의 불편한 사항을 해소드릴 수 있었습니다. 만약, 과거와 같이, Finance에 특화되어 있는 서비스만을 이용하기로 생각했었다면, 이런 혁신적인 서비스를 구현 및 운영하는 것이 매우 어려웠을 것입니다. 클라우드의 이점을 활용하고, Agile 환경을 통해, 매우 단기간에 해당 프로젝트를 수행할 수 있었습니다.

 

 

다양한 산업에 다양한 케이스들이 존재하지만, 금융권에서의 JPMC는 디지털 기반의 업무를 대응하기 위해 클라우드 플랫폼을 내부에 만들고, 플랫폼, 프레임워크, 툴, 이 세가지가 가장 중요하다고 보고 다양한 전략을 추진하고 있습니다. VMWare Tanzu를 기반으로 한, 플랫폼, 스프링부트 기반의 프레임워크, 그리고 여러 개발자를 지원하기 위한 도구들을 결합하여 내부의 디지털 애플리케이션 개발자들에게 제공하고 있습니다.

 

미국 공군(Airforce) 역시 대표적인 예시인데, 기존에 천문학적인 금액의 예산을 집행하였지만, 만들지 못했던 공중 급유를 위 소프트웨어를 Agile 기반의 새로운 조직과 방법론을 바탕으로 더 효율적으로 만들어 낼 수 있었습니다. 더 나아가, 공군 내부에 소프트웨어 센터를 설립하고, 이러한 문화와 방법론을 확산하고 내재화 하기위해 노력하고 있습니다. 가장 보수적일 수 밖에 없는 국가의 군 조직에서조차 Agile문화는 받아들여지고 있는 것입니다.

 

 

 

3. 기업의  MSA(Microservice Architecture) 구현을 위한 제언

약 3~4년 전부터, 기업의 IT애플리케이션 서비스 관련 Microservice 구현에 대한 관심도가 높아지고 있습니다. 기존에 온프레미스를 운영하던 기업이, 클라우드로 전환을 하면서 Microservice로의 전환을 고민한다면 우선, Microservice전환의 목표를 명확하게 하라고 조언하고 싶습니다. 많은 고객은 Microservice가 트렌드이기 때문에 추진하는 경우가 많지만, 실제적으로 Value를 정확하게 알고 조직에 맞는지를 평가하고 진행하는 경우는 드뭅니다. 문제의 정의가 제대로 되지 않은 시점에서 사업에 투자하는 것은 매우 Risk가 높은 일입니다. 또한, 추진을 하면서 결국에는 고꾸라지는 경우를 많이 보게 됩니다.

 

MSA(Microservice Architecture)가 줄 수 있는 Benefit은 매우 다양합니다. 이 중에 직접 취하고 얻어야 하는 목표가 무엇인지를 잘 살펴보고 분석하는 것이 중요합니다. 예를 들어, 조직의 애플리케이션 운영 인력은 기존의 모놀리스 애플리케이션 운영 체계와 같은데, 아키텍처만 바꾸어서는 오히려 관리 포인트만 늘게되는 결과를 얻을 수도 있습니다. 따라서, “운영”을 생각하고 처음부터 아키텍팅하는것이 매우 중요합니다.

 

 

Microservice를 통해 얻고자 하는 가장 큰 장점은 변경에 대한 민첩성입니다. 전환을 고려하고 있는 애플리케이션이 정말 많은 변경을 요구하는가를 살펴보아야 합니다. 한번 만들면 오랫동안 변경이 없는 케이스라고 하면 오히려 Microservice가 비효율적일 수 있습니다. 또, 한가지는 얼마나 많은 Microservice로 나누는가 인데, 자주 범할 수 있는 실수는 필요이상으로 세밀하게 나누는 경우입니다. 많이 나눌수록 운영에 대한 복잡성은 커지게 됩니다.

 

따라서, 나눴을 때 얻을 수 있는 장점을 항상 염두에 두고 진행을 해야 합니다. 각각 배포가 가능해서 Microservice별로 다른 라이프사이클을 가져가는 것이 민첩성에 도움이 된다던지, 아니면 각각 별도로 확장이 가능해서 운영의 효율성 같은 명확한 장점이 없다면, 일단 모듈화만 하여 한 개의 애플리케이션으로 배포하는 것이 효율적일 수 있습니다.

 

상기 문단에서 얘기한 것과 같이 Microservice를 구현한다는 것은 단순한 기술적인 접근으로는 풀 수 없는 내용입니다. Microservice에 대한 장단점을 기업 내부에서 인식하고, MSA도입에 대한 강한 의지를 가지고 있을 경우, 이를 도입하는게 맞다고 생각합니다. MSA를 가장 잘 적용한 Global Site는 아마존닷컴과 넷플릭스를 얘기해볼 수 있을 것 같습니다. 또한, 잘 알려진 공유 숙박 서비스 앱사업을 하는 에어비앤비의 경우도 Service Oriented Architecture를 표방하며, 더 빠른 서비스 대응 및 확장을 MSA구성을 통해 이뤄 나가고 있습니다.

 

 

 

결론

이와 같이 클라우드 기반의 Agile한 환경을 구성하는 부분에 대해 조직의 문화, 그리고 기술적 관점에서 살펴보았습니다. 다시 한번 강조 하자면, 단순히 Microservice구성이 트렌드라서 너도나도 도입해야한다는 주장이 아니라, 왜 Microservice를 도입해야하는지에 대한 니즈와 당위성에 대해 각 기업이 처한 상황에 맞게 면밀히 고민해보고, 정말 MSA구성이 서비스 구성 및 운영 효율에 적합하다면, 가장 작은 단위의 서비스 부터 도입해보는 것이 도움이 될 것이라 생각합니다.

Written by 메가존클라우드 Global Growth Group 임성은 매니저