마이크로서비스 도입, 기술보다 문화가 관건

[지디넷코리아]

혁신을 통해 비즈니스 성장을 도모하는 기업에게 '마이크로서비스'를 도입한 IT환경 구축과 운영이 제안되고 있다.

마이크로서비스는 과거 대형 IT시스템에서 돌아가던 애플리케이션을 목적별로 쪼개 독립적으로 동작케 만든 구성요소를 가리킨다. 구성요소를 조합해 필요한 애플리케이션을 유연하고 빠르게 만들어내고 이를 통한 혁신과 비즈니스 성장을 거둔 사례로 아마존과 넷플릭스가 꼽힌다.

모든 회사가 아마존이나 넷플릭스를 추종할 필요는 없겠지만 기업마다 변화가 빠른 현시대에 걸맞게 IT환경 구축과 운영 방법을 달리 가져가야 한다는 고민에 시달리고 있는 건 사실이다. 이전 30~40년간 업계가 따랐던 소프트웨어(SW) 개발 방법론을 바꿔야 한다면 마이크로서비스 활용이 하나의 대안일 수 있다는 얘기다. 말처럼 간단한 얘기는 아니다. 마이크로서비스 도입을 위해 건너야 할 문턱이 있다.

마이크로서비스의 구루로 알려진 마이크 아문센 CA테크노로지스 API아카데미 API아키텍처 담당 이사는 지난 12일 서울 삼성동 한국CA 사무실 그룹인터뷰를 통해 기업의 마이크로서비스 도입 문턱을 낮출 수 있는 아이디어를 제시했다. 그는 마이크로서비스 도입과 같은 혁신을 추구하는 기업에는 그럴만한 문화가 필요하고, 기업에 이런 문화가 형성되려면 몇 가지 특징이 갖춰져야 한다고 조언했다.

■ 작게 만들어 배포하라

아문센 이사는 일단 간단한 마이크로서비스의 개념을 제시했다.

"마이크로서비스는 기업이 IT환경을 구축하기 위한 툴을 만드는 것에 대한 개념이다. 작은 일을 수행하면서 상호 소통하는 구조의 서비스를 다량으로 만드는 식으로 활용한다. 탄탄하고 조율된 시스템 안에서 구동되는, 느슨하게 결합된 구성요소다. 스스로 잘 운영되는 독립적 존재이면서, API를 통해 다른 시스템과 연결될 수 있는 구조를 띤다는 의미다."

조직이 마이크로서비스의 이점인 빠른 SW개발 속도와 높은 안정성을 얻으려면 파이프라인 구축, 조율된 배포, 진행중 업무 감축, 3가지를 추구해야 한다고 지적했다.

"우선 코드를 개발한 다음 정확성, 의존성, 스타일 등을 종합 검토하고 테스트하는 파이프라인이 구축돼야 한다. API를 개발하고 관리하는 전체 생애주기를 아우르는 툴은 이 조건을 충족한다. 또 다양한 단계의 테스트를 높은 수준으로 자동화해 배포 안정성과 전체 SW품질을 높여야 한다. 마지막으로 진행중인 작업(work in progress)을 줄여야 한다. 단순한 개념이지만 실행하긴 쉽지 않고 대기업에선 특히 어렵다."

마이크로서비스를 잘 활용하는 조직은 '상시 배포'를 자연스럽게 여긴다는 설명이 이어졌다.

"많은 기업이 대형 SW 배포를 1년에 4번쯤 배포하는데, 마이크로서비스를 잘 활용하는 조직은 훨씬 작은 SW를 연중 상시로, 2주에 한 번 할 수도 있고 하루에도 여러개의 SW를 개발, 배포하기도 한다. 자주 배포한다고 꼭 잘 하는 건 아니다. 그보다 SW를 더 작은 부분으로 나눠 배포하면 성공률이 높아진다. 이를 위해 진행중인 작업을 줄여나가는 것이 마이크로서비스 도입의 주요 성과지표다."

그에 따르면 빠른 SW개발 속도와 안정성 확보에 '인터페이스(API)'의 역할도 중요하다.

"아마존은 실제 서비스보다 그걸 표현하기 위한 인터페이스에 더 많은 시간을 할애한다. 잘 설계된 인터페이스는 애플리케이션이 그걸 더 잘 사용케 하고 사고와 실수를 줄여 준다. 인터페이스 설계시 3가지가 중요하다. 첫째, 그게 기계든 인간이든, 소비자를 위한 인터페이스를 설계해야 한다. 둘째, 단일한 인터페이스 규범은 없다. 셋째, 동일 프로세스에 대해 여러 인터페이스를 만들어 상호운용되게 해야 한다."

■ 문화가 더 중요하다

기술이 마이크로서비스 도입과 활용의 전부는 아니었다. 기업과 조직의 '문화'에 초점을 맞춘 설명이 인터뷰 후반부를 차지했다. 혁신을 추구하는 기업에겐 혁신을 위한 문화도 함께 필요하다는 얘기였다.

"거대한 기계가 계속 예측가능한 방식으로 돌아가는 건 혁신을 의미하지 않는다. 대다수 혁신적 문화는 개미 군집이 제각각 움직이는 듯한 양상을 보인다. 어떻게 일하고 있는지, 어떤 발전이 이뤄지고 있는지, 어떻게 작동하는지 이해하기 어렵고 혼란스럽다. 혁신은 이렇게 (구성원들이) 개미처럼 움직이는 조직에서 일어나지만, 예측이 가능해야 하는 대기업에는 이걸 적용하기가 어렵다."

혁신의 과실을 맺기 위해 일종의 문화적 변화를 각오하란 뉘앙스다. 문화는 조직의 전략(strategy), 기술(engineering), 코드(code)를 압도하는 요소임을 이해하라는 메시지다.

"문화가 SW개발 가이드라인을 제공한다. 아무리 시장에 최적화된 맞춤 전략을 가진 기업이라 해도 실제로 원하는 제품을 만들어내는 건 그들의 문화다. 잘 훈련된 엔지니어와 SW개발 환경이 갖춰져 있어도, 리스크를 감수하는 문화가 없어선 안 된다. 그리고 새로운 언어와 툴을 도입하는 것만으로는 충분하지 않다. 결국은 조직, 프로세스, 개인의 문화가 성공을 좌우한다."

■마이크로서비스에 적합한 문화형성요인 3가지

마이크로서비스같은 아이디어를 실행에 옮길 수 있는 문화는 어떻게 형성될까. 3가지 요인이 꼽혔다. 적정한 소규모의 팀, 업무 독립성을 보장하는 조직 구조, 실제로 혁신을 장려하는 제도다.

꼭 몇 명 짜리 팀을 만들어야 적정하다는 건 아니지만 중요한건 너무 커선 안 된다는 것이다.

"문화인류학자 로빈 던바가 연구한 결과 '효율적인 팀 조직' 크기로 제시한 규모는 5명 또는 15명이다. 우리가 마이크로서비스 조직에 적절한 팀 규모로 권장하는 숫자다. 아마존의 제프 베조스는 (미국 기준 라지사이즈) 피자 2판으로 점심 한 끼를 해결할 수 있는 인원수를 제안하기도 했다."

그리고 조직구조가 중요한 이유는, SW개발 결과물의 구조가 그게 개발되는 조직의 구조에 영향을 받기 때문이라고 한다.

"인원수와 별개로 팀이 속한 조직의 구조도 고려해야 한다. 작은 팀 여럿은 작은 SW 여럿을 개발하고, 큰 하나의 팀은 큰 SW 하나를 개발한다. 어떤 개발팀이 다른 개발팀의 배포를 기다렸다가 자기 팀의 배포를 해야 한다면 그건 작은 규모의 여러 팀으로 운영된다고 볼 수 없다. 마이크로서비스를 잘 적용하려면 (개발 프로세스를 다른 조직에 의존하지 않고) 독립적으로 움직이는 소규모 팀이 많이 필요하다."

혁신 문화를 촉진할 수 있는 제도 역시 중요하다.

"조직내에서도 혁신을 만드는 걸 장려해야 한다. 예를 들어 구글은 이를 위해 업무시간의 20%를 다른 사람 승인이나 허락 없이 진짜 원하는 일에 쓸 수 있는 제도를 운영했다. 덕분에 G메일이란 제품이 탄생했다. 혁신은 이렇게 허락받지 않고 하는 업무를 통해 이뤄진다."

■빅뱅식 전환·중앙집중식 관리…어설픈 도입은 실패한다

아문센 이사는 이후 마이크로서비스를 도입하려는 조직이 빠지기 쉬운 두 가지 함정에 관한 설명을 첨언했다. 하나는 처음부터 대대적인 변화를 추구하는 태도로 빠지는 함정이었다.

"모든 변화를 한 번에 이뤄내고자하는, '빅뱅식'이라 알려진 접근법은 가장 흔히 빠지는 함정이다. 이를 피하려면 작은 팀 하나를 만들고, 작은 제품 하나를 만드는 걸로 시작해야 한다. 작은 성공(사례)을 만드는 것이다. 그리고 실수를 통해 배워야 한다. 실제 업무를 수행해나가는 과정에서 개선방법을 학습해야 한다. 일단 제품을 내놓고, 성공 또는 실패 요인을 바로 발견하고, 실패 요인을 전사적으로 빠르게 공유하는 식이다. 우리는 이런 기업을 설명할 때 '배우는 방법을 배우는 회사'라고 표현한다."

나머지 함정 하나는 관리의 유혹이다. 소규모로 쪼갠 조직 구조에 맞춰 팀이 산발적으로 움직일 수 있도록 자율성을 주지 않고 중앙관리를 유지하려 하면 안 된다는 지적이다.

"나머지 함정 하나는 작은 팀 규모를 만들어 놓고, 이 팀에 중앙집중식 관리를 유지하려는 접근이다. 물론 '가시성'은 필요하다. 큰 조직이나 기업 안에 작은 팀이 많을 때 각 팀에서 무슨 일이 일어나고 있는지 알 수 있어야 한다. 한 기업에선 대형 상황판을 만들어서 주문처리현황, 일일 SW배포 현황, 고객유입현황을 다 보여주며 (작은 팀을 일일이 중앙관리하지 않고도) 가시성을 확보했다. 이렇게 책임을 분산하면서 가시성을 유지하는 게 하나의 성공요소가 될 수 있다."