MSA 기술이전 사업을 시작하다

CTO님이 잘 풀이 해주신 팡팡 프로젝트(북경의념과기유한공사 x 베터코드 콜라보)에서 마이크로 서비스 아키텍처를 채택한 이유는 기술적 이유와는 거리가 멀다. 역동적인 중국의 빠른 변화를 수용하기 위한 필수 요건이었다. 당시 나는 이를 비즈니스 전개라고 불렀는데, 이해하는 사람은 거의 없었다. 아무튼, 그런 전적(?)탓인지 여기저기서 MSA를 도와달라고 부르는 곳이 있었는데, 사업적 목표가 없는 곳은 가지 않았다. 그런데, 팔자인지 몇 주 전부터 서울 모처에서 MSA 기술이전을 하고 있다.

늘 그렇듯이, 주변의 buzzword에 오염된 고객들과 실랑이(?)를 하는 2주가 지나갔다. 얼추 마무리를 끝낸 주간보고를 마치고 나서 퇴근 길 페북에서 본 이미지가 이 글을 쓰게 만들었다.

가장 실용적인 MSA 구현

해학이 넘치는 페친님 글에 별점 기능이 있었다면 만점을 드렸을 법하다. 이 글은 일종의 리트머스인데, 독자분들이 아래 글을 읽고 공감하면 업계 사람이고, 아니면 소프트웨어 문외한에 가깝다고 대충 나눌 수 있다.

꼭 필요한 일만 딱 하는 방법을 소프트웨어 업계나 스타트업 씬에서 MVP(Minimum Viable Product)라고 부른다. 기능이 아니지만 MSA 채택을 윗선(?)에서 요구하면 하던대로 하고 간판만 다는 방법이 좋을 수 있다. 그게 바로 MVP 구현이다. :)

ISTIO 를 쓰고 싶어요

개발자는 아닌 DX 전문 임원이 지인인데, API Gateway 선정에 대한 회의를 참석하셨다고 한다. 왜 그런 회의를 하는지 짐작은 가는데, 그 분(임원)이 진지하게 다룰 문제인가 궁금해서 여쭤보았다. 그랬더니, '판교에서 유행이라 개발자들이 쓰고 싶어해요.' 라고 이해하기 쉽게 말씀해주셨다. 이 글을 쓰는 중에도 페이스북에서 아래와 같이 광고가 개발자를 선동하는 모습을 쉽게 관찰할 수 있다.

과거에 외국계 벤더가 ESB 등을 비롯해서 아직 쓸모도 모르는 대기업에 각종 유행하는 솔루션을 넣어 그걸 걷어내는 프로젝트를 하는 모습을 지켜본 내 입장에서는 프로젝트 초반부터 저런 고민을 하면 오지랖이 발동한다. 하지만, 임원이 저렇게 동인을 알고 있으면 문제가 없다. 최근에 내가 직접 경험한 곳에서도 비슷한 논의가 있었는데, 개인의 호기심이라고 회의 석상에서 의견을 나누고 나니 문제가 되지 않았다. 투명한 의사소통은 buzzword와 외산 벤더 영업에 백신 역할을 한다.

Strategic Monoliths and Microservices

이왕 기술이전도 하기로 한 김에 간만에(무려 6년) 킨들 이북을 하나 샀다.

필요한 부분만 발췌해서 읽을 생각이지만, 얼마나 읽을지 모르겠다. 하지만, 이왕 배우는 김에 아는 족족 공유를 위해 글을 쓰기로 한다. 글만 쓰면 개발자들이 이해할 수 없으니 샘플을 만들어줄 개발자 2명을 섭외했는데, 그들이 결과를 내주겠지? (10여년 전에 DDD 샘플 만드는 스터디에서는 실패했던 흑역사가 있다.) 혹시 관심 있는 개발자님들은 참여(contribution)할 수 있다.

마이크로서비스 도입 이렇게 한다

아차! 그리고 보니 출판사 사장님과 역자가 모두 지인이라 서평으로 섰던 글이 있었지? 그걸 썼더니 프로젝트가 엮인 것은 아니지만, 여러모로 올해 MSA 기술 이전 프로젝트는 팔자였나 보다.