마이크로 서비스는 왜 점점 더 각광을 받을 수 밖에 없을까?
예언자처럼 말했다. 확실히 그럴 가능성이 높기 때문이다. 주식처럼 살 수 있다면 마이크로 서비스가 늘어난다에 여유 재산을 다 쏟아 부어도 좋다. 그런 확신이 어디에서 비롯된 것인지 여러분과 공유하는 것이 이 글의 주제다.
마이크로 서비스는 사업 전개 속도의 문제
현재 내 직업 일상은 비즈니스 속도를 높이는 일이다. 단언컨대 소프트웨어를 잘 활용하면 굴뚝 기업[1]도 엄청난 사업 전개 속도를 갖출 수 있다. 사실 그외 다른 방법으로 사업 전개 속도를 높이기는 쉽지 않아 보인다. 소프트웨어란 말 대신에 IT라 칭할 수도 있고, 누구는 디지털화/디지털 전환 등으로 말할 수 있지만, 그 중에 하나만 고르라고 하면 소프트웨어가 가장 적합하다. 무언가 빠르게 시장에 내어놓는 일은 여러 관점에서 설명할 수 있겠지만, 필자는 그 중에서 기업의 소프트웨어 시스템 구성이 마이크로 서비스 형태일 때 확실히 사업적으로 민첩해진다는 주장을 하려고 한다.
지난 몇 년을 돌아보면 흥미로운 사실은 애초부터 마이크로 서비스를 적용하려고 한 일이 없다는 사실이다. 컨설팅 회사에 시니어로 재직하던 시절 고객의 요구에 부응[2]하는 과정에서 '소 뒷걸음질 치다 쥐 잡았다'[3]. 2012년 즈음부터 필자를 찾는 이들이 그 전과 구분되었다. 과거의 관행으로는 결코 달성할 수 없는 벽을 뚫는 작업을 요청해왔다. 당시에는 그들의 요구를 어렴풋한 방향성 정도로만 이해했다. 지금에 와서 생각하면 그들은 경쟁우위를 점하기 위해 비즈니스 속도를 높이는 일과 관련하여 소프트웨어로 할 수 있는 일이 있을 것이라고 믿고 날 찾은 것이 아닐까 싶다.[4]
아무튼 그래서 지금은 마이크로 서비스 적용의 목적을 사업 전개 속도를 높이는 일이라고 과감하게 말할 수 있다.[5] 그러던 차에 확신에 확신을 더하는 사건을 겪었다.
밀크티를 사면서 모바일 결제를 하려는데
사랑스런 나의 동료 庆의 치과 치료를 기념하여 밀크티를 쏘기로 했다. 함께 식사를 한 다섯 명을 위한 밀크티 주문을 하고, 결제를 위해 아래 보이는 사진의 하얀색 QR 스캐너에 휴대폰에서 WeChat 페이 QR화면을 띄워서 갖다 대고 있었다.
하얀 기계는 QR 코드 스캐너
종업원이 반복해서 중국말로 '기다리라'고 말했다. '기다리라'는 말이 휴대폰을 뒤로 물린 후에 잠시 기다렸다가 갖다 대라는 말임을 깨닫고 난 뒤에야 휴대폰을 뒤로 물렸다. 뒤로 물러서며 '굳이 왜 사용자가 스캔할 타이밍을 기다려야 하나' 생각해보니 QR을 갖다 대면 판매원 화면에 인터럽트가 발생하는 이유일 듯했다. 시장에 나온 프로그램 관행을 생각하면 불필요한 동기화가 되어 있을 가능성이 높다.
순간 '아하!' 싶었다. 그렇다, 세상은 모바일Mobility 가속일로에 있다. 그리고, IoT는 점차 우리 가까이에 침투하고 있다. 위 사진에 나온 기기를 굳이 IoT라고 부르면서 호들갑을 떨 필요는 없지만, 그렇다고 작은 스캐너와 프린터가 IoT가 아니라고 따질 필요는 없다.
(습관적) 학습에 따라 늘어나는 사용자 요구
그리고 또 연결되는 사건이 있었다. 주문을 하고 밀크티 제조를 기다리는데 메뉴판이 눈에 띄었다. 중국어를 배우는 동료들 중에 현재 5위를 마크 중인 庆이 평소 '쩐주나이차'로 알고 있는 한자가 무엇인지 찾고 있었다. 필자가 珍珠奶茶라고 손가락으로 가리키는데 추천 메뉴를 나타내는 엄지손가락 아이콘이 페이스북 좋아요 버튼처럼 보였다. 그래서, 메뉴판을 터치하면 좋아요 하나가 추가되면 좋겠다는 말을 했다. 만일 그렇게 된다면, 가게 추천이 아닌 사용자 추천 데이터를 만들 수 있을 것이다.
추천 메뉴 아이콘이 좋아요 버튼 같네
사용자의 학습은 이런 식으로 번져 나간다. 페이스북에서 보던 것이 간판으로 옮겨가지 말라는 법따위는 없다. 이미 가상화는 우리의 일상에 깊이 침투해있다. 요즘 많이 쓰이는 디지털 전환이라는 말은 어떤 면에서는 가상화와 일맥한다. 가상화를 실현하는 핵심 기술은 바로 소프트웨어이다. 시장과 산업의 발전 과정에서 소프트웨어가 하드웨어 역할을 잠식해나가는 현상이 바로 가상화[5]다.
이 사건과 마이크로 서비스가 무슨 관련인가?
마이크로 서비스는 빠른 시장 진입에 유리하다. 개발자 입장에서는 갑자기 무슨 일이 툭 튀어나올지 모르는 상황이 바로 비즈니스의 세계라 말할 수 있다. 경계가 사라지고 있는 시장의 경쟁이 점차 가속 일로에 있는 점은 말해 무엇하랴? (비즈니스 전개) 속도는 이제 최고의 경쟁력이라 할 수 있다. 개발자들이 유연하게 비즈니스를 구현해내려면 현대적인 모듈화가 필요한데, 그것이 바로 마이크로 서비스 아키텍처라고 해도 틀린 말이 아니다.
그런데, 여기서 문제는 전통기업의 기존 프로그램이다. 우리가 흔히 레거시라고 부르는 그것은 하나같이 한통으로 짜여있어 고치기가 만만치 않다. 어쩌면 그 경직성을 제거하는 일이 관성에 젖어 무모하게 프로그램을 전부 새로 만드는 일(a.k.a. 차세대) 따위보다 시급하다 할 수 있다. 어떻게 할 수 있나?
첫번째 허들은 회사내에 개발자가 있어야 한다는 점인데, 외주 관리 위주로 IT 인력을 확보하고 있던 회사는 체질 개선이라는 생각지 못한 선행 과제를 만나야 한다. 결국은 다양한 이유로 개발자를 뽑지 못해서 차세대라는 돌아올 수 없는 함정에 빠질 수도 있다. 일단, 우울한 이야기로 끝을 낼 수는 없으니 사내에 개발자가 있거나 개발자를 뽑았다고 치자.
그렇다면, 희망은 있다. 레거시를 고치기는 어렵지만, 비즈니스에서 가장 시급한 과제를 추려본다. 최소한 '이거 하나만 뚫으면 뭔가 될 것 같다' 정도의 가능성이 보이는 일이라면 좋다. 그렇지 않더라도 적극적으로 비즈니스 활동을 하는 누군가 꼭 필요한 것이라면 충분히 만들어볼 가치가 있다.[6] 그걸 어떻게 소프트웨어가 지원할지 모형을 만드는 일은 2주 ~ 한달 정도면 가능하다. 다시 말해, 대충 어떤 모습으로 서비스가 돌아갈지 짜보자고 하는 일은 그리 어렵지 않다.
그렇게 사용자에게 지지를 받을 준비를 한 후에 레거시와 어떻게 절충할 것인가를 살피는 일을 해나간다. 대개는 레거시에서 필요한 데이터를 복사해서 쓰거나 프로그래밍 인터페이스를 만드는 정도로 관계를 맺는 경우로 충분하다. 경험상 여기까지는 용기와 인내만 있다면, 대단한 기술을 필요로 하지 않는다. 그리 어렵지 않다. 문제는 그 다음이다. 레거시에 숨겨진 진짜 큰 문제는 프로그램 자체가 아니라 레거시를 다뤄왔던 사람들과 그 사용자들이 갖고 있던 낡은 습관인 경우가 많다.
결국 이걸 제거하는 가정에서 프로그램 개발 조직이 변한다. 그래서, 피할 수 없는 승부가 필요한 지점이다. 그리고, 마이크로 서비스 구축은 이러한 과정을 통해 만들어져야 조직을 바꿀 수 있다.[7] 구축이라고 말하지만, 1회적으로 만들 수는 없고 운영을 전제한 지속적인 개선과정이다. 필자가 공유한 마이크로 서비스 관련 글은 바로 2년간 끊임없이 노력해서 프로그래밍 실력이 높지 않던 조직이 바뀌어가는 과정을 요약한 글이다. 여전히 그들의 프로그래밍 실력은 높다고 할 수는 없다. 하지만, 2년간 조직력이 갖춰진 그들이 최근에 보여주는 사업 전개 속도는 놀라움 그 자체이고, 필자가 마이크로 서비스에 대해 확신하는 이유이기도 하다.
불필요한 동기화 이야기는 왜 꺼냈나?
불필요한 동기화에서 생각이 마이크로 서비스로 튀었다. 필자는 구체적으로 동기 방식 혹은 비동기 방식의 프로그래밍에 대해 관심을 뒀다기 보다는 불필요한 결합을 제거하는 일이란 점에서 닮은 꼴fractal인 마이크로 서비스로 생각이 나아간 것이다. 필자는 QR 스캐너의 이벤트 감지 시점과 판매원의 입력 사이에 과한 결합이 있다고 추정한 것이다. 그리고, 마이크로 서비스로 분할하는 일은 비즈니스 전개 속도 확보(시스템 속성으로는 유연성)를 위해 한 통 구조monolithic 시스템이 갖는 과한 결합을 연상한 것이다. 대안은 이벤트 드리븐으로 이종 시스템 사이의 정합성을 서서히 맞춰주는 일인데 그에 대해서는 나중에 또 글을 쓸 과제로 남겨둔다. 여기서는 다만, 필자가 쓰는 글의 취지에 따라 빠른 비즈니스 전개에 초점을 맞추면, 바로 어떤 일이 튀어나와도 그 쓰임새로 프로그래밍 구현이 가능한 프로그래밍 방식으로 이벤트 드리븐 프로그래밍의 효용성을 말할 수 있다.
합종연횡의 비즈니스 확장
끝으로 최근 필자가 관심있게 바라보는 텐센트Tencent의 리테일 합작 전략 중 일부를 소개하는 것으로 마치겠다.
腾讯地图跟腾讯云，通过为滴滴打车、美团、京东、顺丰提供服务，积累了很多关于配送的经验，我们也有服务快递配送公司的后台技术，我们可以把这样的能力拿出来帮大家优化配送效率
고객 분석과 관련하여 리테일 업체들과 합작을 도모하는 텐센트의 전략 설명의 일부다. 텐센트의 위챗은 중국에서 가장 많은 사용자가 쓰는 채팅 프로그램이기도 하지만, 편리한 결재 수단을 제공하는 동시에 전기/수도세/통신요금 납부 등을 지원하고, 각종 회원 카드나 쿠폰 보관 기능을 제공하여 사실상 생활 플랫폼 성격을 띈다. 그러한 위챗 사용자의 접점을 기반으로 그들의 지도(腾讯地图) 그리고 클라우드 서비스(腾讯云)는 물론 중국 독점 차량 호출 서비스(滴滴打车), 외식배달 앱(美团), 중국 2위 이커머스 서비스(京东), 최대 물류사업자(顺丰) 등의 시스템과 연계한 분석 기능을 꿈꾸고 있다. 이러한 거대한 야망의 바탕에는 이벤트 기반의 연결과 마이크로 서비스 등으로 설명할 수 있는 사업 전개를 위한 시스템 구조가 깔려있다.
주석
[1] 서양인들이 Brick and Mortar라고 분류한 기업들, 즉 인터넷 서비스 회사가 아닌 다른 업종의 회사들을 말한다.
[2] 컨설팅 회사에서 시니어가 되면서 독립적인 사업부를 맡아서 영업부터 프로젝트 수행은 물론 수금까지 모두 맡아서 할 때부터 나는 고객을 고를 수 있었다. 나는 수익성보다는 다소 모호하지만 스스로 여기기에 '의미 있는 일'을 쫓았다. 고맙게도 시장에서는 필자는 독특한 캐릭터의 컨설턴트였다. 그래서, 필자를 찾는 이들은 여럿 중에 하나로 찾는 것이 아니라 다른 대안으로는 딱히 답이 없는 일에만 필자를 찾았다. 결국 도전적인 일을 고객사 자체로 수행할 역량이 없을 때 필자를 찾는 이들이 많았다.
[3] 속담을 그대로 쓴 것이 아니라 권도균의 스타트업 경영수업 22쪽에 나온 의미를 차용한 것이다.
[4] 어떠한 경우에도 고객들이 컨설턴트에게 '속도를 높여주세요'와 같은 식으로 말하지는 않는다. 컨설턴트는 고객의 직업 일상에 대한 관찰을 통해 진짜 문제를 읽어내야 한다. 고맙게도 필자는 상당기간 고객의 문제에 함께 얽히는 행운을 누렸지만, 민망하게도 문제를 읽어내는 데에만 수년이 걸렸다. 필자가 사업하던 사람이 아니었기 때문에 나에게도 겪으면서 공감할 수 있는 충분한 시행착오의 시간이 필요했던 모양이다.
[5] 2014년 크리스 리차드슨의 마이크로 서비스 정리는 우아한 분산 아키텍처의 현대적인 전형이라 생각한다. 최근까지도 그는 QCon에서 발표를 하고, InfoQ에 글도 올린 것을 지인의 페북을 통해 확인했다. 이제는 거의 언급조차 되지 않는 RMI, EJB 같은 방식이 분산 아키텍처의 초기 모델이라고 보면, 분산 프로그래밍 모델은 점점 더 개방적이고 느슨한 연관loosely-coupled 을 구현하는 식으로 발전해왔다. 크리스 리차드슨의 예에서 DDD의 패턴과 특정 기술 요소에 대한 부분을 제외하고 일반적인 내용만 발췌해보면 RPC 대신에 이벤트 기반 메시지 통신을 하는 점과 동기식 트랜젝션에 의존하는 대신에 메시지 수발신을 감지하여 각각 응용 프로그램 모듈 즉, 마이크로 서비스가 로컬 데이터베이스의 정합성을 유지하는 예시를 보여주었다. 이 내용을 풀어 쓰면 글이 삼천포로 빠질 수 있어 주석에 생각나는대로 메모하는 것으로 그친다. 하지만, 바로 이러한 분산된 형태의 객체 그래프를 만드는 프로그래밍 모델이 등장했다는 사실을 여러분이 인지한다면, 필자가 주장하는 비즈니스 전개 속도에 대한 통찰을 더욱 공감할 수 있을 것이다.
[5] 당신이 만일 개발자나 시스템 엔지니어라면 자신의 시각을 잠시 버려보자.
[6] 조심해야 할 일은 실제로 쓸 사람이 있는 것이 아닌 누군가 머리속에서만 필요하다고 하여 기획한 내용을 무작정 개발하는 일이다.
[7] 이글은 스타트업이나 그에 준하는 개발 문화를 가진 기업에는 그다지 유효한 글이 아닐 듯 하다.
에피소드: 글을 올리고 나서 달린 댓글
이 글을 쓰고, 이전에 썼던 마이크로 서비스 구축 경험 공유에 다음과 같은 댓글이 올라와 답변을 했다. 질문 덕분에 답을 하며 나도 배울 수 있었다. 이 글에서 강조한 전개 속도가 장기적 혹은 누적으로 보면 서비스 대응 속도가 된다는 사실이다. 그래서, 코드 버전이나 품질 관리, 배포 관리 등이 중요해진다. 하지만, 모든 코드를 똑같은 노력으로 다룰 수 없고, 임시로 쓰이다가 사라지는 코드도 존재하기 마련이다. 그러한 임시 코드를 그대로 유지하여 시스템 어딘가에 돌아가게(혹은 코드 안에 있지만 쓰이지는 않는 형태로) 방치해두면 기술 부채인 레거시가 된다. 마이크로 서비스로 서비스를 운영하며, 그러한 상황에도 자연계의 도태와 유사하게 임시 코드를 제거하는 수단을 만들어낼 수 있다.
마이크로 서비스 구축 경험 공유에 달린 댓글