[컴퓨터월드] 지난 다보스포럼 이후로 전 세계가 ‘4차 산업혁명’이라는 화두로 시끌벅적하다. 인공지능(AI)이나 사물인터넷(IoT)과 같은 새로운 IT가 전 산업분야의 지형을 바꿔나갈 것이라는 전망으로, 소프트웨어(SW)를 기반으로 한 디지털과 피지컬(물리적인 현실세계)의 융합이 그 핵심으로 꼽히고 있다. 네 번째 혁명이라는 다소 자극적인 명명을 차치한다면, 이는 현재 수많은 기업들이 꾀하고 있는 ‘디지털 트랜스포메이션(Digital Transformation)’의 연장선상에 있다고도 볼 수 있을 것이다.

IT를 기반으로 디지털 기업으로 성공적으로 거듭나기 위해서는 무엇이 필요할까. 이에 대한 답으로 흔히 언급되는 것 중 하나가 바로 ‘데브옵스(DevOps)’다. IT의 개발과 운영을 유기적으로 통합한다는 개념으로, 이를 통해 보다 신속하고 안정적으로 고품질의 SW를 지속적으로 내놓는 것을 골자로 한다. SW기업을 표방하는 모든 기업들에 새로운 동력을 제공해줄 수 있는 데브옵스와, 이를 실제로 구현하기 위한 ‘마이크로서비스 아키텍처(MSA)’에 대해 살펴본다.

간단하고도 복잡한 데브옵스

SW개발 관련 트렌드는 20여년 전 워터폴(waterfall) 방식의 등장부터 10여년 전 애자일(agile) 방법론의 부상까지 SW의 발전과 함께 지속적으로 변화해왔다. 그 뒤를 잇는 ‘데브옵스’는 지난 2008년 SW개발자 패트릭 드부와(Patrick Debois)와 앤드류 클레이 셰이퍼(Andrew Clay Shafer)가 애자일 인프라에 대해 논의하던 중 처음 등장한 개념이다. 개발(development)과 운영(operation)을 합쳐놓은 단어로, 말 그대로 개발과 운영의 통합을 뜻한다. 이렇듯 표면적인 의미는 간단하지만, 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화와 방식 및 도구를 모두 내포한다.

최근 들어 데브옵스가 더욱 주목받고 있는 이유로는 먼저 산업분야 전반에 걸쳐 비즈니스 지형이 변화하고 있다는 점을 들 수 있다. GE(제너럴일렉트릭)나 메르세데스벤츠 등 전통적인 제조업체들도 이제는 스스로 SW기업이라 일컫고 있고, 실제로 SW와 데이터를 통해 새로운 비즈니스 모델을 발굴하면서 수익을 창출하고 있다. 조직 전체의 애플리케이션 딜리버리 향상이 곧 기업 경쟁력 제고로 이어지는 시대로, 각 단계를 확실히 매듭짓고 난 후 다음 단계로 넘어가는 워터폴 모델의 SW개발방식이나 12~18개월 단위의 SW배포주기로는 까다로워진 고객들의 입맛을 맞추기 점차 힘들어지고 있는 상황이다.

기업IT에 있어 비즈니스 요구사항을 적시적소에 충족시키기 위한 민첩성의 중요성이 날로 높아져가는 가운데, 현재 IT부서가 현업부서의 요구를 기민하게 지원하는 데 가장 큰 어려움 중 하나는 전통적으로 경계가 구분된 개발과 운영 환경의 통합이라 할 수 있다. 지금까지는 그 경계가 분명해 개발에서 운영에 이르기까지 다양한 유형의 병목현상(bottleneck)에 봉착하게 됐고, 역할 분담에서 비롯되는 여러 사무절차와 입장차 및 책임소재공방 등 현실적인 문제들이 걸림돌이 되기도 했다.

일례로, 국내 기업 상당수가 지난 2014년 발견된 오픈SSL 보안 취약점인 ‘허트블리드(Heartbleed)’에 대한 패치를 아직도 충분히 하지 못하는 실정이다. 개발과 운영이 분리된 상태로 필요할 때마다 덧씌워지면서 IT시스템 전반에 대한 가시성이 떨어져, 시스템 내 각 요소들 간 의존성(dependancy)으로 엮인 실타래를 풀지 못하는 모양새다.

데브옵스 모델에서는 개발조직과 운영조직이 더 이상 ‘사일로(silo)’에 묶여있지 않다. 때로는 이 두 팀이 단일팀으로 병합돼 엔지니어가 개발에서 테스트, 배포, 운영에 이르기까지 전체 애플리케이션 수명주기에 걸쳐 작업하고, 단일 기능에 한정되지 않은 광범위한 기술을 개발하기도 한다. 품질보증 및 보안 담당 역시 애플리케이션 수명주기에 걸쳐 개발과 운영에 보다 긴밀하게 통합된다.

양승도 아마존웹서비스(AWS)코리아 솔루션즈 아키텍트는 “이러한 팀은 데브옵스 방식을 사용해 속도가 느리고 수동으로 수행되던 프로세스를 자동화한다. 또한, 애플리케이션을 안정적이고 빠르게 운영하고 개선하는 데 도움이 되는 기술 스택과 도구를 사용한다. 덕분에 엔지니어는 과거 다른 팀의 도움이 필요했을 코드 배포 또는 인프라 프로비저닝과 같은 작업을 독립적으로 수행할 수 있으며, 따라서 팀의 작업 속도가 더욱 빨라지게 된다”고 설명했다.

민첩성이 곧 경쟁력

현대에 들어 SW와 데이터가 필요치 않은 산업분야는 이제 찾아보기 힘들어졌다. 급변하는 시장의 니즈에 맞춰 프로세스를 효율화하고 서비스를 향상시키기 위해서는 다각적인 데이터 분석을 기반으로 고객이 만족할 만한 경험을 제공할 수 있어야 하기 때문이다. 기존 자동차 업체에게는 에어컨 버튼 하나 바꾸는 것도 부품 생산과 구매 프로세스까지 엮여있어 쉽지 않은 일인 반면, 테슬라, 우버, 에어비앤비 등 ‘디지털 와해(Digital Disruption)’를 불러일으켰다고 평가받는 새로운 기업들은 SW를 기반으로 비즈니스 민첩성을 확보했다는 공통점을 지닌다.

데브옵스가 기업에 가져다줄 수 있는 이점도 이러한 부분이다. 기존에 개별적으로 작업을 수행해왔던 개발조직과 운영조직이 긴밀하게 협업, 새로운 기능과 서비스의 딜리버리 속도와 유연성을 향상시킨다. 협업, 소통, 통합, 공유, 자동화 등을 통한 보다 신속하고 효율적인 SW개발 프로세스를 형성, 궁극적으로는 더 빠르게 고품질의 애플리케이션 서비스를 배포하고 시장에 출시할 수 있는 민첩성을 얻게 되는 것이다.

먼저, 빨라진 작업 속도로 시장 변화에 기민하게 대응함으로써 보다 효율적으로 비즈니스 성과를 창출, 릴리스 빈도와 속도 증가를 통해 버그 수정이나 요구사항 반영도 제때 이뤄질 수 있게 된다. 또한, CI(Continuous Integration) 및 CD(Continuous Delivery)를 통해 꾸준히 변경사항을 관리하고 테스트와 모니터링을 수행함으로써 안정성과 품질을 확보하고, 자동화와 일관성을 기반으로 규모에 따라 인프라와 개발 프로세스를 운영 및 관리할 수 있다. 아울러, 구성원 간 협력과 책임 공유를 통해 개발에서 운영까지 인도 기간을 줄이고 실제 환경을 고려한 코드가 작성되는 등 효율적인 협업을 가능케 하며, 자동화된 규정 준수 정책과 세분화된 제어 및 구성 관리 기술을 활용해 보안을 유지하는 것도 가능하다.

[인터뷰] “IBM의 노하우 녹인 데브옵스” 데브옵스를 통해 얻을 수 있는 이점은. 우선 데브옵스를 왜 고민해야 하는지에 대해 생각해볼 필요가 있다. 2000년대 이전부터 애자일한 프랙티스들은 개발자들에게 많은 생산성 향상을 제공하고 있다. 다만, 스크럼(scrum) 같은 종류의 개발방법론이 다소 개발에 치중됐다보니 운영에 이르기까지 다양한 유형의 병목현상에 봉착하게 된다는 문제를 겪게 되고, 이 부분의 해결을 위해 데브옵스가 회자된다고 보면 된다. 따라서 데브옵스의 가치는 이러한 병목을 해결함으로써 생산성을 높인다는 점이 가장 크다고 할 수 있다. 이러한 방법은 기업의 규모나 분야와 무관하게 SW 개발과 운영이 필요한 모든 곳에 적용 가능하다고 볼 수 있다. 데브옵스를 구현하려면. 툴 도입만으로 마칠 게 아니라 조직의 변화도 병행돼야 하고, 조직이 변하려면 문화도 변해야 한다. 우리나라 기업들의 경우 자체 개발팀을 풍부하게 보유하지 않고 단위별로 그때그때 외주를 주고 유지보수도 따로 맡기는 방식을 선호해왔기에, 이렇게 분리된 구조와 문화 및 스킬셋이 장애물이 될 수 있다. 오래 쌓여왔으니만큼 이를 타파하려면 전사적으로 움직여야 한다. 한 번에 확산시킬 수는 없더라도 작은 단위로 파일럿을 시도하면서 조금씩 바꿔갈 수 있다고 본다. 데브옵스는 IT만의 이슈가 아니다. 이를 통한 ROI(투자수익률)를 어떻게 환산할 수 있는가는 쉽지 않은 문제지만, 분명 경쟁우위를 가질 수 있는 차별점이 될 수 있다는 점에서 주목받고 있다. IBM이 제공하는 데브옵스 전략은. IBM 클라우드 플랫폼인 블루믹스(Bluemix)가 핵심 솔루션이다. 전체 데브옵스 라이프사이클에 걸쳐, 블루믹스 서비스와 오픈소스 툴 및 써드파티 툴들을 연동해 구성 가능한 ‘데브옵스 오픈 툴 체인’, 자동화된 빌드/배포 파이프라인을 구성해주는 CD 서비스, 애플리케이션 품질 향상을 위한 분석을 제공하는 ‘데브옵스 인사이트’, 애플리케이션 상태 및 가용성 모니터링 서비스, 온프레미스 환경의 CD를 위한 ‘어반코드 디플로이’, 지속적 테스트를 위한 ‘래셔널 테스트 워크벤치’ 등을 제공하고 있다. 올해는 국내외를 막론하고 데브옵스와 마이크로서비스 아키텍처의 적용이 가속화될 것으로 전망된다.

국내 데브옵스는 걸음마 단계

넷플릭스를 위시해 데브옵스 성공사례가 전 세계적으로 늘어나면서, 국내에도 데브옵스에 대한 인식이 확산되고 있다. 최근 CA테크놀로지스가 전 세계 비즈니스 및 IT 고위 임원 1,770명을 대상으로 조사한 결과에서도 아시아태평양(82%) 및 한국(69%) 기업 대다수가 애자일과 데브옵스를 디지털 트랜스포메이션 성공의 결정적 요인으로 인식하는 것으로 나타났다. 그러나 우리나라의 경우 이 분야에서 아태지역 국가 중 가장 뒤처진 것으로 드러나, 향후 우리 기업들의 IT경쟁력 확보가 우려되는 상황이다.

CA는 이번 조사에서 기업 내 1개 이상 조직에 애자일을 확장했거나 전사에 도입한 기업은 애자일 우수기업, IT 전 영역과 기업문화에 데브옵스 적용한 기업을 데브옵스 우수기업으로 분류했다. 이에 따르면, 아태지역 기업은 애자일과 데브옵스가 디지털 트랜스포메이션 성공에 중요한 역할을 한다는 점에 의견을 같이했지만, 실제 애자일과 데브옵스를 전사적으로 도입한 우수기업은 각각 29%와 38%에 그쳤다. 특히 한국기업은 애자일(6%)과 데브옵스(20%) 모두 아태지역 국가 중 가장 낮은 성숙도를 기록했다.

아태지역 기업은 애자일 개발 및 방법론의 활용을 가로막는 주요원인으로 ▲사내 기술·지식 부족(49%) ▲예산 제약(46%) ▲적절한 기술·도구 통합(45%)을 꼽았다. 반면 한국기업은 ▲조직문화(58%) ▲사내 기술·지식 부족(53%) ▲적절한 기술·도구 통합(52%) 순으로 조직문화를 가장 큰 걸림돌로 간주했다. 데브옵스 활용을 가로막는 주원인으로 한국기업은 ▲조직문화 및 사고방식·변화 거부(51%) ▲사내 기술·지식 부족(51%) ▲적절한 기술·도구 통합(49%)을 들었다. 아태지역 기업은 ▲예산 제약(41%) ▲보안 문제(41%) ▲적절한 기술·도구 통합(40%)을 장애물로 꼽았다.

애자일 및 데브옵스와 실질적 비즈니스 성과 사이에는 직접적 상관관계가 있는 것으로 나타났다. 아태지역 애자일 우수기업은 의사결정 시간을 35%(기본기업 27%), 데브옵스 우수기업은 출시 기간을 46%(기본기업 19%) 개선했고, 특히 애자일과 데브옵스 우수기업은 고객경험을 각각 91%, 87% 개선하는 효과를 거뒀다. 데브옵스를 애자일 환경에 도입해 함께 활용한 기업은 더 큰 성과를 거둬, 애자일과 데브옵스를 병행한 아태지역 기업은 애자일만 활용한 기업에 비해 ▲IT관련비용(135%) ▲신규 비즈니스 성장(86%) ▲운영효율성(65%) ▲고객만족도(NPS, 59%)에서 더 큰 개선 효과를 얻었다.

[인터뷰] “앱 이코노미와 디지털 SW 팩토리” 국내외 데브옵스 도입 상황은. CA는 데브옵스를 ‘디지털 SW 팩토리’라 정의한다. 애플리케이션 이코노미에서는 SW 개발과 운영이 곧 프로덕트로 거듭나기 때문이다. 애자일, 데브옵스, 마이크로서비스 아키텍처 등은 결국 스피드와 퀄리티를 목표로 한다. 이 같은 관점에서 글로벌에서는 전 산업에 걸쳐 필요성을 인식하고 혁신을 진행하고 있는데 반해, 우리나라의 경우 그동안 리테일 등 일부 업종에서만 움직임을 보였다. 상당부분 정착돼가는 조직도 있지만, 공공이나 금융 등 전통적인 산업분야에서는 아직 미진한 실정이다. 그러나 고객들도 열심히 학습하고 있는 상황으로, 이제는 국내 전 산업분야에서 움직임이 가시화될 전망이다. 데브옵스를 구현하려면. 휴리스틱 관점, 즉 전체적으로 봐야 한다. 전통적인 제품 생산도 디자인부터 조립하고 QA 및 출고까지 공정 전반에 걸쳐 일어나는 일인데, 데브옵스도 어느 한 곳만 볼 게 아니라 전체적으로 짜임새를 갖춰야 한다. 또한, 기존 생산라인을 다 걷어내면 무리가 될 수밖에 없다. 미션 크리티컬한 코어는 그대로 두고, 기능 하나씩 적용해보면서 부분적으로 확산시켜가는 것을 권장한다. 나아가 장기적인 관점에서 전사적으로 바꿔나갈 수 있도록 전폭적인 지원이 필요하다. 아직도 IT를 비용절감의 대상으로만 여길 게 아니라, 가치를 창출할 수 있는 조직으로 바라볼 필요가 있다. CA가 제공하는 데브옵스 전략은. CA 데브옵스 포트폴리오는 개발부터 생산까지 전 과정을 아우르며, 클라우드에서 디바이스에 걸쳐 모든 기술을 지원한다. 데브옵스라는 용어가 등장하기 이전부터 지속적인 배포나 테스트 자동화 툴을 공급해왔고, 최근에는 기업IT에 스피드와 퀄리티에 대한 요구사항이 많아지면서 수요도 늘고 있다. 자사 금융 고객들의 경우 지난해 오픈API로 효과를 보면서 자연스레 데브옵스에도 관심을 두기 시작한 것으로 보인다. 한편, PSD 2(지급서비스지침 2)가 유럽과 북미를 중심으로 화두가 되고 있는 반면, 아직 우리나라의 경우 이에 대한 대비가 충분히 이뤄지지 않는 것으로 보여 우려된다.

데브옵스 위한 마이크로서비스 아키텍처

데브옵스에 대한 인식이 확산되면서 최근 주목받고 있는 것으로는 ‘마이크로서비스 아키텍처(MicroService Architecture, MSA)’를 들 수 있다. 단일 애플리케이션을 작은 서비스의 집합으로 구축하는 설계 접근방식으로, 느슨하게 결합되면서 자율적인 서비스를 생성하기 위한 새로운 아키텍처 스타일이라 할 수 있다. 애플리케이션을 작은 단위의 서비스들로 나눠 개발하고, 각 서비스는 독립적으로 배포 및 운영될 수 있으며, 주로 잘 정의된 HTTP 기반 API(앱프로그래밍인터페이스)를 통해 다른 서비스와 통신하는 단일 목적의 기능(single function) 단위 모듈로 구성된다. 도커(Docker)와 같은 컨테이너 기술을 활용, 작은 태스크들에 초점을 맞춘 분산구조인 셈이다.

기존 SOA(서비스지향아키텍처)가 ESB(엔터프라이즈서비스버스)를 통한 기업 내 애플리케이션 간 연계가 주목적이었다면, 글로벌 웹서비스 업체들의 서비스 확장 과정에서 파생된 마이크로서비스 아키텍처는 개발부터 운영에 이르기까지 모든 애플리케이션 구축 단계에서 SOA의 이점을 제공하면서 복잡한 시스템을 최적화된 구성요소로 제작하기 위한 기술 간소화에 주안점을 둔다. 다중 언어 지원(Polyglot) 프로그래밍 및 영속성, 컨테이너 또는 변경 불가능한 VM(가상머신), 탄력적이면서 프로그래밍 가능한 IaaS(서비스형 인프라) 및 PaaS(서비스형 플랫폼) 등이 주요 차이점으로 꼽힌다.

기존 방식이라 할 수 있는 단일(monolithic) 애플리케이션에서는 애플리케이션의 일정 부분을 고치더라도 전체를 다시 빌드하고 배포하는 변경주기를 갖고 있어, 시간이 지남에 따라 모듈화가 어려워지고 영향을 받는 부분만을 쉽게 변경할 수 없게 됐다. 전체 애플리케이션 구조를 스케일링하게 됨으로써 꼭 필요한 것보다 더 많은 자원을 사용하게 된다는 문제점을 안고 있었다.

이러한 기존 모놀리식 방식과 달리 마이크로서비스 아키텍처는 복잡한 대규모 시스템을 간단하고 독립적인 단위로 결합 해제한다. 애플리케이션을 더 작은 서비스 단위로 분해하게 됨에 따라 모듈화가 개선되고 관리 범위가 명확해지면서 애플리케이션에 대한 이해와 개발 및 테스트가 더 용이해진다. 각 서비스는 독립적으로 개발 및 배포가 가능하기 때문에 개발팀의 운영과 일정에 높은 자유도를 제공해주며, 각 서비스를 독립적으로 스케일할 수 있게 돼 자원 효율화를 도모할 수 있다. 또한 각 서비스는 각각 다른 프로그래밍언어와 DB(데이터베이스) 및 도구를 선택해 개발이 가능하므로, 해당 서비스가 요구하는 기능에 최적화된 요소들을 골라 사용할 수도 있다.

[인터뷰] “기업고객의 데브옵스 위한 방향성 제시” 마이크로서비스 아키텍처란. 마이크로서비스 아키텍처는 단일 응용 프로그램을 나눠, 작은 서비스의 조합으로 구축하는 방법을 말한다. 각 개별 서비스는 자신의 프로세스에서 실행하는 HTTP기반 API 등으로 가볍고 느슨하게 결합된다. 개발자가 관리하는 스코프(scope)가 명확해지고 SW개발을 단순하게 만든다. 각 서비스는 독립적으로 개발·배포 가능하며, 각각 다른 프로그래밍언어와 도구로 개발할 수 있게 된다. 반면, 전체적인 테스트나 로깅 등의 경우에는 어려움이 따르고, 또 수많은 배포 작업이 불가피하므로 개발·배포·테스트 과정을 자동화하는 것이 필수적인 요소다. SW개발과 배포가 빈번히 이뤄지는 곳에 적합한 아키텍처라 할 수 있다. 데브옵스를 구현하려면. 예전에는 비즈니스가 선행되고 SW가 뒷받침하는 구조였다면, 지금은 SW가 앞길을 트고 비즈니스가 따라오는 시대다. 이 때문에 데브옵스가 화두가 됐는데, 구현하려면 일단 기업문화부터 변해야 한다. 솔루션을 구입한다고 바로 이룰 수 있는 게 아니며, 필요한 도구도 갖춰져야 한다. 데브옵스는 특정 툴을 의미하는 것도 아니고, 자동화를 했다고 다 된 것도 아니다. 데브옵스를 도입하기 적합한지 여부는 기업이 각자 처한 상황과 시점에 따라 다르며, 구현을 위해서는 협업, 표준화, 자동화의 세 가지 요소를 기반으로 유기적으로 빠르게 프로세스를 처리하는 것이 핵심이다. 그간 앙숙인 경우가 많았던 개발팀과 운영팀이 소통하고 협업하지 않는 이상 데브옵스 구현은 요원한 일이다. 레드햇이 제공하는 데브옵스 전략은. 레드햇은 다양한 오픈소스 커뮤니티 프로젝트 개발 및 지원을 통해 고객들의 데브옵스 성공에 필요하다고 여기는 기술을 선택 제공하고 있고, 고객 및 파트너 에코시스템 구축을 통해 각 기업에 최적화된 적용방안을 제시한다. 이 중 마이크로서비스를 위한 ‘레드햇 제이보스 미들웨어’ 솔루션은 클라우드 환경에서 개발자 툴부터 데이터 관리에 이르는 서비스를 제공하며, ‘레드햇 오픈시프트 컨테이너 플랫폼’은 다양한 애플리케이션을 구현하며 컨테이너 기반 마이크로서비스 아키텍처를 활용하고 오토스케일링 기능 등을 통해 데브옵스 환경을 구축할 수 있도록 지원한다. 국내 기업들도 소비자 중심 IT서비스로 고객 기대치를 충족시키기 위해 마이크로서비스 도입을 확대할 것으로 예상된다.

MSA, 선택은 기업의 몫

애플리케이션 업데이트를 위한 조정 오버헤드를 줄이면서 각 서비스가 이를 담당하는 작고 민첩한 팀과 연결되면 조직이 좀 더 신속하게 움직일 수 있다는 점에서, 마이크로서비스 아키텍처는 기본적으로 데브옵스에 기반을 둔다고 할 수 있다. 그러나 데브옵스를 위해 꼭 마이크로서비스 아키텍처가 필요한 것은 아니다. 꼭 마이크로서비스 아키텍처를 택할 때 감수해야 할 부분도 존재하기 때문이다.

먼저, 서비스가 다른 서비스를 호출하는 복잡도가 증가할 수 있는 대형 프로젝트인 경우에는 서비스 호출에 대한 추적 및 서비스들 모니터링이 힘들어질 수 있다. 또한, 서비스는 다른 서비스와 REST API와 같은 메커니즘으로 호출이 이뤄지는데, 상대적으로 단일 애플리케이션의 내부 통신에 비해 느릴 수밖에 없게 된다. 더불어, 서비스가 다른 서비스를 연속적으로 호출하는 구조에서는 디버그가 어려워질 수 있고, 기존 중앙집중형 구조와 달리 DB가 분산되므로 데이터 관리가 제대로 이뤄지지 않으면 문제 발생의 소지가 있다. 이와 함께, 마이크로서비스와 릴리스 빈도 증가의 조합은 배포 수를 현저히 늘려 운영 문제로 이어질 수 있으므로, CI/CD를 지원하는 도구를 통한 자동화가 필수적으로 요구된다. 이밖에도, 마이크로서비스를 나누는 기준 역시 각 기업 상황에 따라 스스로 판단해야 할뿐, 정답은 없는 문제다.

그러나 이 같은 어려움이 있음에도, 데브옵스의 가치인 신속한 개발과 함께 자동 배포를 진행하기 위해서는 현재로서는 마이크로서비스 아키텍처가 최적의 방식으로 꼽히고 있다. 기존 모놀리식 환경의 애플리케이션 구조에서는 민첩한 개발 및 운영을 통해 출시(time-to-market)의 폭을 줄이는 목표를 이루기 어렵기 때문이다. 이 때문에 SW의 빠르고 안정적인 개발과 운영이 곧 경쟁력과 직결되는 기업들이 마이크로서비스 아키텍처를 택하고 있으며, 개발팀과 운영팀이 함께 움직이면서 책임을 공유하는 데브옵스가 필수요소가 되는 것이다. SW와 데이터를 경쟁력의 기반으로 삼는 기업들이 늘어날수록, 마이크로서비스 아키텍처도 더욱 확산될 것으로 보인다.

[인터뷰] “작게 시작해서 조금씩 확장해가야” 마이크로서비스를 성공적으로 활용하기 위한 방법은. 개인적으로 목격한 대부분의 실패사례는 기존 개발팀을 특정 기능 등 사전에 생각되는 목적대로 미리 나눠두고 팀을 할당해 개발하는 경우였는데, 현재 대다수가 이렇게 접근하고 있는 것으로 알고 있다. 이와 달리 접근하는 것은 다음과 같다. 예를 들어 쇼핑몰 MD가 신규 상품을 추가할 때 기존에 없던 색상이나 배송방법 등을 적용하려 한다면, 기존 모놀리식 아키텍처에서는 수주에서 수개월까지 걸릴 수도 있는데, 이러면 그새 상품 가치가 떨어지기 마련이다. 이런 비즈니스 니즈를 충족시키기 위해, 기존 시스템은 그대로 두고 새로운 부분만 클라우드를 바탕으로 마이크로서비스로 시도해보고, 성공적이었다면 다른 부분도 문제 해결이나 기능 개선에 적용해볼 수 있을 것이다. 새로운 기능의 서비스 반영에 얼마나 걸리는지, 하나의 서비스가 전체 시스템에 악영향을 주는 부분은 없는지 파악해야 하며, 개선작업의 난이도나 효과 등을 사전에 확인하고 타깃 애플리케이션을 선정해 범위를 제한해서 개발하는 것이다. 이게 피보탈의 방법이다. 데브옵스를 구현하려면. 먼저 기업이 원하는 속도로 현재 서비스를 개선하고 있는가에 대해 고민해봐야 할 것이다. 만약 경쟁사가 페이스북 수준의 훌륭한 앱을 내놨다면, 이에 대해 우리도 그런 앱이 있다고 말하기보다는 우리도 그 정도쯤은 만들 수 있는 팀이 있다고 답할 수 있어야 할 것이다. 당장 샤오미의 앱들을 봐도 제품들의 연동과 소모품 판매 및 고객서비스 지원 등이 가능하게 돼있는 반면, 국내 대기업들의 앱을 보면 각 서비스가 연동되지 않아 비즈니스가 통합되지 못하는 문제를 발견하게 된다. 이는 데이터의 활용성과 SW의 재사용 및 개선을 힘들게 하고, 궁극적으로 고객에게 더 많은 가치를 부여하지 못해 시장 선도에 걸림돌이 된다. 그러나 이런 문제는 한꺼번에 해결할 수 있는 것이 아니며, 계열사나 사업부 간 사일로 형태 등 조직문제가 발생한다. 따라서 이런 해결을 위해서는 서비스를 먼저 ‘작게’ 시작하고 점진적으로 확장하는 형태의 접근이 유용할 것이다. 피보탈이 제공하는 데브옵스 전략은. 피보탈은 오픈소스 커뮤니티 공헌에 노력하고 있으며, 주력사업인 클라우드 파운드리(CF)도 오픈소스로 존재한다. 애플리케이션의 클라우드 기반 배포와 운영 및 데이터 수집을 돕는 도구로, 개발은 코드에 집중할 수 있고 운영은 공통된 환경을 제공할 수 있게 해주며 각 클라우드 서비스별 상이한 인터페이스나 방법도 일원화해주는 게 특징이다. 또한, 피보탈 랩은 자사 SW를 개발하는 곳이자, 피보탈의 문화, 프로세스, 기술을 적용해 기업고객이 원하는 바를 고객사 엔지니어와 함께 직접 개발하는 곳이기도 하다. 고객들이 데브옵스 조직을 만들어 운영하면서 난항을 겪는 경우 도움이 될 수 있는 서비스로, 현재 글로벌에 19개소가 위치해있고 국내에도 준비될 수 있도록 노력 중이다. 데브옵스와 MSA에 관심 있는 고객에게는 작은 시도부터 전사적인 확장까지 큰 도움이 될 수 있을 것이다.

새로운 기업문화로 거듭나는 데브옵스

관련업계에서는 2017년이 데브옵스와 마이크로서비스 아키텍처가 본격적으로 대두되는 한 해가 될 것으로 내다보고 있다. 이에 여러 SW기업들뿐만 아니라 AWS와 같은 클라우드 사업자들도 관련 서비스를 제공하는 데 적극적으로 나서고 있다. AWS 역시 이러한 아키텍처를 기반으로 서비스를 만들고 있으며, 다양한 영역에 세분화된 90가지 이상의 서비스들은 더 세분화된 서비스로 구성되면서 모든 기능이 API로 호출이 가능하게 돼있다. 아마존닷컴과 마찬가지로 AWS 역시 원하는 애플리케이션을 만들기 위한 서비스 기반 빌딩 블록 철학이 자리잡고 있는 것이다.

IT업계에는 ‘애자일은 다이어트와 같다’는 이야기가 있다. 하는 방법은 다들 알고 있는데, 실제로 성공했다는 사례는 드물다는 점을 꼬집는 말일 것이다. 현재 화두로 부상하고 있는 데브옵스에 대해서도 마찬가지다. 대부분의 전문가들이 지적하듯, 데브옵스에 적합하도록 기업문화의 혁신부터 선행돼야 할 것이며, 이에 대한 경영진의 전폭적인 지원도 뒷받침돼야 할 것이다. 마이크로서비스 아키텍처가 자사에 적합한지, 어느 곳에 어떻게 적용할지는 그 다음에 알아봐도 늦지 않다. 데브옵스 팀의 구성에 있어서도, 아마존처럼 피자 두 판으로 모두 한 끼를 해결할 수 있을 정도로 쪼갠다는 ‘피자 두 판의 법칙(Two Pizza Team)’을 꼭 따를 필요도 없다.

모든 기업이 아마존이나 넷플릭스와 같이 뛰어난 데브옵스를 하기에는 현실적으로 쉽지 않고, 또 모두가 그렇게 해야 할 필요가 있는 것도 아니다. 기업 스스로가 현재의 상황을 파악하고 적절한 방향을 찾아, 급변하는 시장에서 경쟁력을 잃지 않도록 민첩성을 확보하면서 발전해나갈 수 있다면 충분하다. 그러나 시스템은 조직의 모양을 닮는다는 ‘콘웨이의 법칙(Conway’s law)’에 비춰보면, 아직 상당수 국내 기업들은 충분한 준비를 하지 못한 것으로 보인다. SW비즈니스를 하는 기업이라면, 데브옵스라는 새로운 ‘문화’를 어떻게 받아들이느냐에 그 미래가 달려있는 것이다.

[활용사례] “데브옵스 향해가는 NBT” NBT가 생각하는 데브옵스는. 서비스 개발을 지원하기 위해 다양한 공개SW와 클라우드 기반 엔지니어링을 통한 자동화를 추구하며, 서비스의 안정적 운영 및 보안, 아키텍처의 개선을 위한 엔지니어링 팀을 부르는 명칭이자, 이러한 문제들을 신속하게 접근해 해결하기 위한 커뮤니케이션 문화다. 현재 데브옵스를 진행하고 있는 업무영역은 빌드/배포 자동화 구성과 운영, 클라우드를 이용한 인프라 구축 및 운영 자동화, 통합 모니터링 구축 및 장애 예측, 빅데이터 분석 플랫폼 구성과 운영, 보안 취약점 조치 및 관리, DB를 포함한 전체 기술 아키텍처의 구조와 성능 개선 등으로, 서비스 개발 이외 개발 관련 영역 대부분을 포함한다고 할 수 있다. 이렇듯 넓은 범위의 개발영역을 포괄하기 위해 아키텍처의 단순화, 자동화 구현을 기본으로 하는 ‘코드형 인프라(Infrastructure as code)’를 추구하고 있으며, 이러한 방향성은 적은 수의 인원으로 다수의 개발조직에 대응하고 대규모 인프라를 구축·운영해야 하는 데브옵스에게는 선택이 아닌 필수인 상황이다. 자동화할 수 있는 모든 부분은 자동화를 구현하되, 복잡도는 최소화하는 것이 핵심이라고 생각한다. 혼자 고민하기보다는 팀 동료들과 적극적으로 고민을 나누고 서로 의견교환을 통해 빠르게 문제해결에 접근해나가는 일하는 방식 또한 필요하며, 이는 팀의 동반성장에도 중요한 몫을 차지하는 데브옵스의 문화라 여긴다. NBT가 구축한 MSA는. 현재 다수의 프로덕트를 서비스·운영하고 있는데, 이 중 가장 많은 사용자를 확보하고 있는 ‘캐시슬라이드’ 서비스를 기준으로 설명한다면 MSA를 추구하고 있으나 아직 완전한 모습을 갖추고 있진 않다. 그럼에도 독립된 백엔드 서비스 도메인들의 수는 앱 실행 시 보이는 화면의 버튼 수 이상으로 분리돼 운영되고 있고, 이런 느슨한 결합(loosely coupled)구조의 독립된 서비스들은 특정 도메인에 문제가 발생해도 ‘캐시슬라이드’ 전체 서비스에 미치는 영향도가 상대적으로 줄어들어 독립적인 빠른 개발 테스트를 가능하게 만들어주고 있다. 이러한 환경은 하루에 수차례 애플리케이션 배포를 가능하게 해주며, 신규 기능에 문제가 발생한 경우에도 빠른 롤백 처리가 가능해진다. 또한 각각 분리된 서비스별 독립된 개발 환경은 ‘캐시슬라이드’ 서비스 개발 조직의 일하는 모습과도 연관돼있으며, NBT는 이러한 기능별 개발팀을 ‘파티’라 불리는 평균 4인 조직 단위로 운영 중이다. 최근 신규 추가됐던 ‘미션 참여하기’ 기능의 경우에도 이러한 독립된 파티가 기획부터 설계, 개발까지 완료 후 출시한 기능들 중 하나다. 이렇게 분리된 작은 단위의 서비스들은 트래픽 성격에 따라 각기 다른 형태의 시스템 자원을 할당받아 최적화된 자원으로 운영되며, 부분적인 스케일업/다운, 인/아웃이 가능해 자원효율화 및 비용최적화를 추구하기에 유리한 환경을 제공한다. 사용성이 줄어든 서비스를 제거하는 경우에도 관련 여러 자원들을 손쉽게 제거해 비용효율화가 쉬워진다. MSA 도입 및 활용에 어려웠던 점은. 복잡한 인터페이스 구조는 자칫 MSA의 단점으로 작용할 수 있는 부분이다. 분리된 서비스들 간 데이터를 주고받는 과정에서 발생하는 네트워크 레이턴시와 문제 발생 구간 파악의 복잡성은 MSA에서 흔히 경험하게 되는 문제들이다. 따라서 불필요하게 늘어날 수 있는 네트워크 인터페이스 구조의 복잡성을 줄이기 위해 각 분리된 서비스들의 여러 레이어 마다 통일된 관점으로 아키텍처를 바라보고 가이드해주는 시니어 엔지니어가 필요하다. 이에 각 ‘파티’들이 모인 ‘클래스’라는 조직에서 리더 역할을 하는 ‘클래스 리더’가 이를 맡고 있으며, 다시 제품별 아키텍처를 가이드하는 아키텍처 오너와 협력해 다양한 서비스 아키텍처를 만들어나가고 있다. 즉 클라이언트 클래스, 서버 클래스, 데브옵스 클래스, 데이터 클래스 등 여러 레이어별 수평적인 개념의 조직이 존재하고, 이러한 ‘클래스’ 구성원들이 각각 ‘파티’라는 단위로 모여 서로 다른 레이어의 개발자, 기획자들과 협업하며 제품을 개발하고 있다. 이와 함께 통합 모니터링 시스템과 로그데이터 수집·분석 시스템, 장애 예측을 위한 사용 패턴 변화 감지 알람 등도 활용하고 있다. 이뿐만 아니라, 작은 개발조직 단위에서 발생될 수 있는 개발자들의 어려움을 해소하기 위해 다양한 개발문화 행사를 주기적으로 진행하고 있으며, 업무 진행에 문제가 되는 다양한 요소들을 파악하고 줄여나갈 수 있도록 ‘엔지니어링 컬처 클래스’를 운영하고 있다. 다수의 프로덕트와 다수의 클래스, 다수의 파티를 건강하고 활발하게 운영하고 있는 개발조직구조는 엔비티가 자랑하는 개발문화의 모습이다.