마이크로 서비스 못 다한 이야기
지난 해 썼던 마이크로 서비스 구축 경험 공유 그리고, 님 시각으로 쓰여진 Micro Service, Docker로 할 수 밖에 없었던 사연에 빠진 내용을 써서 공유하고 싶다. 쓰기에 앞서 독자 입장에서 어떤 효용이 있을까 의심스러워 몇 가지 질문을 해본다.
- 다른 이의 경험은 얼마나 전달될까? 또, 전달 여부는 무엇으로 확인할 수 있을까?
- 마이크로 서비스에 대해서 독자는 저자와 얼마나 비슷하게 생각하고 있을까?
- 독자들은 읽고 난 후에 무엇을 기대할까? 아니면 기대없이 읽다가 무엇을 건질 수 있을까?
즉흥적으로 내놓은 질문이지만, 본질적인 물음인지 가볍게 썼는데 점차 무거워지는 질문들이다. (잠시 경미한 좌절) 그래도, 다행인 점은 질문을 던지고 나니 (기대했던 결과와는 다르지만) 자신감이 생겼다는 점이다. 이제 엉뚱한 글을 쓸 우려가 줄었으니 하고싶은 말을 쓴다.
당신의 MSA(마이크로 서비스 아키텍처)는 무엇인가?
가장 중요한 질문이다. 독자분들이 자신이 서 있는 위치를 인지하도록 도울 목적으로, 필자가 관찰했던 대강의 유형 구분을 제시한다. 주로 페이스북을 통해 접하는 글에 나타나는 MSA에 대한 시각은 크게 둘이다.
첫째는 '뜨는 프로그래밍 방식'으로 보는 개발자들이다. 자신이 거기에 속하는지 아래 질문이 힌트가 될 수 있다.
MSA와 NoSQL은 무슨 관계인가?
위에 대해서 자기 나름의 답이 바로 나오지 않는 개발자는 이 부류에 속할 가능성이 높다. 근거는 아래와 같다. MSA 는 아키텍처Architecture 일종인데, 마이크로 서비스MS의 반대 개념인 한통구조Monolithic의 핵심에는 단일 데이터베이스, 다시 말해 전사적 데이터 모델링[1]에 의존하는 데이터 관리 프로그래밍 방식 해결과 밀접하게 관련이 있기 때문이다. 그래서, 이를 이해하지 못하거나 NoSQL을 위 문제와 연관지을 수 없다면 아키텍트 관점이 없다고 보기 때문이다.
둘째로 아키텍처 측면에서 보는 개발자(혹은 나처럼 개발자 출신인 ...)들이 있다. 상대적으로 소수인데, 대체로 아래와 같은 고민을 목격한 바 있다.
- 우리 조직에서 이것을 어떻게 할 수 있을까? (한숨부터 나온다.)
- 나는 하고 싶은데, 주변에서 따라주지 않는다. (설득으로 지쳐가며 시간 보내고 싶지 않은데...)
- 거품이 낀 말이다. (그냥 하면 되는데...)
- 서비스를 어떻게 나눌까? (참조할 기준이 있으면 좋겠는데...)
당신은 어디에 속하는가? 혹은 다른 관점이라면 글로 표현할 수 있는가? 없다면 둘 중에 고르는 편이 생산적이다. :)
나에게 MSA는 RESTful 아키텍처 다음 여정
2009년 프로젝트에서 RESTful 아키텍처 도입을 통해서 .NET, 자바, 안드로이드 환경을 손쉽게 연결한 경험이 이후 필자를 MSA 의 길로 가게 한 것이 아닐까 싶다. 2000년 초중반만 해도 엔터프라이즈 환경에서는 개발표준이 매우 중요했다. 필자 역시 프레임워크 구축을 업으로 하고 있었고, 스프링Spring 프레임워크에 푹 빠져있던 시절이었다. 그러다가 고객의 문제로, 프레임워크를 넘어선 문제 인식의 출발이 바로 2009년 프로젝트였다. 모바일 기기가 변수로 등장하면서 만병통치약 같았던 스프링 중심의 개발표준에 큰 빈틈이 생긴 것이다. 이 프로젝트를 계기로 RESTful 아키텍처와 MSA가 공통으로 해결해주는 문제를 몸으로 겪게 되었다. 물론, 당시는 개념적으로 충분히 소화하지 못했다. 이제와서 해석해보면 당시 얻은 것은
프레임워크[2]가 아닌 프로토콜 수준의 제약이 주는 자유도가 시스템 수준의 객체(혹은 컴포넌트) 사이에서 느슨한 연결Loosely Coupled을 가능하게 해준다.
10년 가까이 지난 지금에야 해석한 것이다. 당시에는 몸으로만 익히고, 감으로만 알았을 뿐이다. 배움이란 이런 식으로 (긴 시간에 걸쳐) 눈덩이 불어나듯이 진행되는 듯하다. 2009년 경험은 다시 나를 2012년 즈음부터 모바일 쇼핑몰에 RESTful 아키텍처를 적용하는 일로 이끌었다.
왜 RESTful 아키텍처가 아니고 MSA인가?
2012~2013년 즈음의 프로젝트는 운영중인 쇼핑몰을 점진적으로 교체하는 일이었기 때문에 고통[3]이 이만저만이 아니었다. 구축은 그럭저럭 성공적이었는데, 우리가 감수한 고통에 비해 실제 효과에 강한 의심이 들기 시작했다. 당시에는 '이건 아니다' 정도의 감이었고, 역시 6년 여가 지난 지금에는 사실은 MSA를 지향했으나 RESTful 아키텍처 적용 수준에 그치면서 놓친 가치를 설명할 수 있다. 기술과 조직을 포괄하는 총체적 측면에서 아래 두 가지 사항이 당시 결여되어 있었다.
- 운영조직은 바뀌지 않았다. 만든 사람이 따로 있다보니, 전부터 운영하던 개발자들이 완전히 바뀐 구조와 기술을 단시간에 학습하는 일은 불가능하다. 이런 상황에서 인수인계란 개발자를 궁지로 모는 일이란 사실을 당시 관리자들은 전혀 알지 못했다.[4]
- 단일 데이터 모델을 그대로 두고 프론트 API 영역만 RESTful 아키텍처로 변경하는데 그쳤다. 진정한 복잡도는 그대로 두고 당장 급한 부분 즉, 모바일 대응만 할 수 있게 조치했다. 당장 비즈니스는 견디지만, 수정은 점점 더 어려워지는 레거시로 변하는 현상은 오히려 가중된다. 가중되는 레거시를 드러내는 증상은 (1) 필연적인 하드코딩, (2) CDC나 EAI 솔루션에 의존해서 데이터를 밤에 복제하는 일, (3) 새로운 비즈니스 상황에 대해서 가능한지 아닌지 아무도 즉답을 못해주는 현상 등이 있다.
당시 구축 자체는 성공했으니 여기 저기 소문이 났는지 업계 몇몇 업체에서 연락이 왔다. 그 중 두 곳과는 개발팀장과 미팅을 한 일이 있다. 당시 대화로는 설명이 안되던 부분을 회한으로 담은 글이 시스템 개선을 위한 REST API 도입? 이란 글이다.
그래서 정리하면
경험에 기반한 내용이 많다보니 여기까지 독자가 따라오기 힘들거나 슬슬 지루할 듯하다. 그래서, 이쯤에서 정리를 해보자.
MSA를 적용 혹은 실현했다고 자신있게 말하려면 무엇이 필요한가?
크게 두 가지만 추리면 아래와 같다.
- 데이터베이스가 물리적뿐만 아니라 논리적으로도 완전히 나눠져 있는가?
- 서로 다른 서비스를 개발하는 개발자와 인프라 운영자 사이 혹은 개발팀간 소통이 잘 되고 있는가? 데브옵스라 할 정도는 아니라도 최소한 CI 환경은 돌아가는가? 다시 말해 Jenkins는 당연하고, Git을 쓰고 Jira나 Github/lab은 활발히 쓰고 있는가?
첫 항목은 어쩌면 MSA에서 마이크로 서비스의 적당한 단위에 대한 훌륭한 안내자가 될 수 있다. 비즈니스(혹은 도메인 지식)에 맞춰 자른 데이터베이스 단위가 마이크로 서비스 단위로 쓰일 수 있다. 주의할 점은 여기서 자른다는 말은 전통적으로 DB 모델러가 정의하는 주제 영역 구분과는 다른다. 그 정도가 아니라 ERD를 개별적으로 그리는 수준의 분리이다.
두번째는 데브옵스 구축이라는 말로 대신할 수도 있다. MSA 구축과 데브옵스는 어쩌면 불가분의 관계다. 필자는 현재도 지속하고 있는 2년 가까운 경험에서 이 부분을 매우 중요하게 다뤘고, 그 이야기를 작년에 마이크로 서비스 구축 경험이란 글로 공유한 바 있다. Micro Service, Docker로 할 수 밖에 없었던 사연 역시 같은 공간에서 벌어진 일에 대한 다른 관점을 기록하고 있다.[5]
당신은 MSA로 무엇을 얻을 것인가?
글을 읽기 전과 읽은 후에 차이가 있어야 한다는 생각이 바로 앞에서 효용 운운했던 이유다. 독자들께 변화가 있었으면 좋겠다. 가장 중요한 것은 각자의 삶이니, 글쓰는 나의 욕심은 독자들께 무언가 긍정적인 영향을 주는 촉매제가 되었으면 하는 마음이다.
마지막으로, 독자들을 돕기위해 MSA로 뭔가 혜택을 얻는 사람들을 열거해보겠다.
- 필자같은 사람들은 MSA 적용 경험(RESTful 아키텍처 적용 경험까지 포함해서)을 직업 생활의 중요 주제로 재사용하고 있다. 그 과정에서 비즈니스에도 관여해야 하고, 조직 문화 변화가 필수인지라 MSA란 이름 대신에 '디지털 전환Digital Transformation'이란 서비스/상품 이름[6]을 붙였다.
- 2014년 QCon에서 강연했던 크리스 리차드슨 같은 사람이 있다. 당시와 거의 유사한 장표를 3년 후에도 QCon에서 발표했다. MSA를 프로그래밍 방식으로 상품화 해서 팔고 있다. 한국의 모 대기업에 초청을 받아 다녀가기도 했다. 장표에 담긴 내용 정도로 프로그래밍 방식을 상품화 하여 전세계를 돌며 직업으로 삼고 있다.
- 경영자중에도 있다. 바로 필자와 협력중인 파트너이자 고객사 대표님인데, 최근 당신이 조직을 바꿔가며 얻은 소회를 글로 쓰신 바 있다.
이제 여러분들 이야기도 삶에서 행동으로 실천하면 좋겠다. :)
주석
[1] 필자의 프로그래밍 경험은 모두 엔터프라이즈 환경(차세대, SI, ITO 등등)에서 겪었기 때문에 인터넷 서비스 회사의 경우는 글의 내용이 그대로 부합하지 않을 수 있다.
[2] 엄밀히 말하면 프레임워크가 아니라 프로그래밍 수준의 제약이라고 말할 수 있겠다. 프레임워크뿐 아니라 SOAP 등을 처리하기 위한 미들웨어 성격의 프로그램 제약 등등을 포괄한 말을 이 글에서는 대표값으로 '프레임워크'라고 했다.
[3] 데브옵스DevOps 필요성을 절실히 느꼈던 시간이었다.
[4] 이런 이유로 외주 개발에 의존하는 회사는 곧 사라질 것이다.
[5] 우리는 2016년 3월부터 글을 쓰는 현재까지 중국 커머스 서비스 환경에서 MSA 적용하는 일을 하고 있다. 여기서 우리는 베터코드 주식회사와 중국의 의념과기유한공사衣念科技发展有限公司의 협업 주체를 의미한다.
[6] 위에 언급한 일이 전력하고 있어 별다른 홍보나 영업활동을 하고 있지 않지만, 베터코드 주식회사의 향후 컨설팅 서비스 주력 상품이다.