마이크로 서비스 구축 경험 공유

아키텍처, 시스템 구성, 모델링, 개발 프로세스를 고민하고 만들었다기 보다는 현재의 조직 구성원으로 서비스를 만들 수 있는 가장 최선의 방법을 선택한 것입니다. 복잡한 것은 만들기 어려우니 아주 잘게 쪼개고, 잘 만들고 있는지도 모르겠으니 일주일에 한번씩 확인하는 방식이었던 것입니다.

우리의 여정이 11개월째로 접어들 때 합류한 김형준님이 내 의도를 너무나 잘 정의했다.^[1] '꿈보다 해몽'인가? 김형준님의 글, Micro Service, Docker로 할 수 밖에 없었던 사연을 읽을 때는 싱크로율 100%를 느꼈고 그래서 우리가 서로 훌륭한 동료가 되었다는 사실에 감동했다. 그 감동에 대한 답례로 무언가 쓰고 싶어 이 글을 남긴다.

시스템은 유기체란 사실

2012년 즈음인가 처음 김형준님과 같은 프로젝트에 참여했다. 그때 그는 빅데이터 플랫폼 도입을 고민하는 대기업 임원들을 만나곤 했는데, 대체로 그들이 올바른 선택을 하지 못하는 이유를 다음과 같이 설명했다.

시스템은 유기체인데, (개발을 해보지 않은 그들은) 그 사실을 모른다

쉽게 말하면 시스템의 반은 프로그램이라면 나머지 반은 사람 즉, 개발자란 사실이다.^[2]  이 사실을 인정한다면 마이크로 서비스 아키텍처를 채용한다고 할 때, 프로그램 구조뿐 아니라 우리 조직이 어때야 하는지 함께 고려할 필요가 있다. 이 글의 초점은 그 점에 맞춰져 있다.

마이크로 셀: 기민한 개발 조직

운좋게도 나에게 마이크로 서비스 아키텍처를 주문했던 두 분의 훌륭한 경영자가 있었다. 둘 다 개발자 출신은 아니지만, 빠른 시장 대응(Time to market)을 위해서는 소수가 독립적으로 판단하고 개발하는 조직이 필요하다는 데에 초점을 두고 있었다. 한 분은 이를 마이크로 셀이라고 표현했다. 린(Lean)이나 애자일 관련 자료를 찾아보면 이론적으로 마이크로 셀을 구축하는 방법론은 어렵지 않게 찾을 수 있다. 그러나, 우리가 일할 대상은 모두 감정과 생각이 있는 사람들이다. 그래서 일원화된 방식^[3]으로 성공을 기대하는 것은 어리석은 일이다. 그래서, 각자 조직에 맞는 방법을 찾아 끊임없이 시도해야 한다.

그에 대한 내 경험을 공유하려고 한다. 앞서 김형준님이 '현재의 조직 구성원으로 서비스를 만들 수 있는 가장 최선의 방법'이라고 말했던 것이 어떤 과정이었는지 설명한다.

체질부터 바꾸자

최초에 우리는 모든 개발자를 대상으로 변화를 꾀하지는 않았다. 레거시 유지보수 성격 일을 하는 친구들은 일단 그대로 두었다. 기민한 개발을 하겠다고 나선 소수의 선발대가 첫 대상이었다. 게다가 최초 참여한 이들중에서 우리가 만들려는 대상이 모호하다 생각했는지 몇 주가 지나자 선발대에서 빠져 나가서 숫자는 줄기까지 했다. 일단, 참여는 개인의 권한에 맡겼다.

그리한 후에 내가 첫 아기 발걸음으로 역점을 둔 부분은 뭔가 다 정해진 뒤에야 개발하려는 이들의 습성이었다. 나는 이렇게 말했다.

아무렇게나 만들어도 좋으니 일주일 안에 결과를 달라

1주는 너무 짧으니까 2주로 해달라는 요구가 있었지만, 내 대답은 시간이 부족하면 하다 말고 가져와도 좋으니 1주일마다 데모를 하자는 것이었다. 그렇게 시작하니 첫주나 두번째 주에는 개발이라고 말할 수 없는 결과물이 나왔다. 하지만, 완성이 되지 않아도 1주일마다 결과가 나오니까 된 것 아닌가? 이렇게 우리는 가장 먼저 결과물보다는 서로에 대한 신뢰를 쌓는 시간을 갖었다. 그 신뢰가 없었더라면 우리의 터무니없는 모험이 지금까지 계속될 수 없었을 것이다.

여기서 다시 한번 시스템이 유기체란 사실을 상기해보자. 유기체로서 갖는 특징은 상호신뢰이다. 만들 것을 요구하는 자(일종의 Product Owner 혹은 기획자)와 개발자 사이의 신뢰, 그리고 개발자 상호간의 신뢰는 측정하기 어렵지만 너무나도 중요한 기반이다. 고로 당신 조직이 갑질이 횡행하는 환경이라면 마이크로 서비스를 구축해봐야 모래성쌓기와 같으니 관두라고 권하고 싶다. 그리고, 당신이 정말 진지하게 마이크로 서비스를 조직 차원에서 구축하겠다면, 상호 신뢰할 수 있는 팀/회사 분위기를 만들기 위해 노력해야 한다.

그렇게 신뢰를 구축하는 동시에 한달 넘게 노력했더니 일주일안에 결과를 만들 수 있는 기민함을 갖췄다. 이 기민함을 조금 더 들여다 보자. 일주일에 결과를 만든다 할 때 보통 이틀은 회의, 제3자 테스트, 배포, 데모 등으로 시간을 쓰기 마련이다. 3일 정도가 실제 개발 할 수 있는 시간이다. 게다가 모호하게 개발 범위를 잡아두면 3일안에 끝내기도 어렵다. 또한, 바로 확정이 필요한 결정은 기획자나 PO를 찾아 그 즉시 물어야 한다. 이런 소양을 갖추는 데에 적응이 빠른 친구들 기준으로 4~6주 정도는 소요되었던 것으로 기억한다.

기술스택 통일에 시간 쓰지 않기

초기에 상당한 시간을 소비했던 일은 바람직한 기술스택에 대한 논쟁이나 서로 다른 기술을 쓰고 싶어 벌어지는 실랑이었다. 개발자들에게 자신이 원하지도 않는 기술을 쓰느라 배우는 시간을 강제하면 일주일 단위 배포 주기가 깨어질 수 있다고 판단했다. 실제로 일부 개발자들은 과업중 상당수를 배우는 일로 채우려고 했다. 그래서, 세운 기준을 이랬다.

아무거나 가장 빨리 만들 수 있는 방법으로 한다

사실 이 결정 이면에는 기술이 비즈니스(혹은 타이밍)에 우선하지 않다는 원칙을 습관으로 심어주려는 의도가 깔려 있었다. 그리고, 언젠가는^[4] 리팩토링을 하면 되니까. 당장은 시장에서 쓰이는 서비스를 만들고 생존시키는 것이 먼저였다.

과거에 프레임워크 개발^[5] 등을 업으로 했던 터라 스스로도 매우 어색한 결정이었지만, 덕분에 내 자신도 바뀔 수 있었다.

동시에 여러 버전을 만들기

생각보다 빨리 제품 릴리즈가 이뤄졌다. 품질은 낮은데, 시장 반응이 뜨거워서 가능성이 보였다. 반대 급부로 장애를 처리하고 오류를 개선하면서 동시에 추가 요구사항이 생기다보니 자연스럽게 개발자 숫자도 늘어갔다. 그렇게 되니 선발대도 점차 진지해졌다. 처음에는 무슨 연구이거나 애자일 교육훈련이라고 느슨하게 생각했다가 실제로 릴리즈가 되고, 장애가 터지고 요구사항이 쏟아지니까 긴장감도 늘고 그만큼 관심도가 높아졌다.

그런데, 기술력이 높지 않는 상황에서 빨리 만들기 까지 했으니 새로운 요구사항에 맞춰 기존 프로그램을 고치지 못하는 일이 발생했다. 예를 들어, 로그인과 인증을 담당하는 Account 모듈^[6]이 레거시 데이터 소스가 달라 단시간에 두 가지 방식을 모두 지원하게 코드 수정을 못하는 일이 생겼다. 우리 결정은 단순했다. 출시 속도(Time-to-market)를 우선시하는 것이다. 데이터 소스에 따라 두 개 버전을 만들면 빠르게 개발할 수 있다. 이런 멀티 버전 공존 전략을 짤 때 중요한 것은 같은 개발자(혹은 개발팀)가 해당 버전 모두를 맡게 해야 한다는 점이다. 그래야만 적극적으로 유지보수에 드는 노력을 줄이려는 동기가 생긴다. 프로그래머들은 다 아는 이야기지만, 이렇게 두 개 버전이 생기도록 내버려두지 않는 '중복 제거'가 리팩토링의 시작이다. 그러나, 개발자 각자의 역량이 다르고 생활패턴이 다르다른 점을 존중했다. 그래서, 리팩토링을 강제하지는 않았고, 두 개 버전을 운영하는 책임을 대신 맡으라는 것이다.

여기서 또 유기체를 거론할 수 있다. 시스템이 장기적으로 생존하려면 리팩토링은 필수다. 하지만, 그 어떤 원칙도 개발자의 삶에 우선할 수는 없다. 하여 우리는 기다렸다. 필요성을 이해하고, 방법을 공부하고, 스스로 행할 때까지. 그게 유기체를 대하는 태도다.

또, 애자일이나 린을 모르는 분들은 앞서 말한 출시 속도(Time-to-market)를 우선시하는 것과 납기준수를 비슷하게 생각할 수 있다. 하지만, 전혀 그렇지 않다. 무조건 정해진 일자에 정해진 것을 만들어내라는 것은 일종의 폭력이다. 사업하는데 있어 가장 중요한 것만 영리하게 만드는 것이 대안이다. 그러려면 Toyota가 혁신을 이뤄낸 것처럼 생산라인에 참여하는 모두가 합심에서 최선안을 만들어야 한다.

결론

여기까지 하기로 한다. 중요한 것은 어떤 방법이나 기술에 100% 의존하지 말고, 상식적으로 동료들과 함께 할 수 있는 길을 찾으라는 뻔한 이야기다. 머리로는 뻔할지 몰라도 대부분은 그렇게 행하지 못하는 모습을 목격한 탓에 이런 글을 남긴다.

주석

[1] 올해 1월에 합류해 8개월동안 핵심 서비스 개발과 인프라 개선, 코드 리뷰 등을 하면서 과거를 모두 읽어낸 그의 역량이 놀랍다.

[2] 프로그램과 개발자는 대표값이며, 엄밀히 말하면 프로그램에는 인프라 등의 구동환경을 내포해서 말하며, 개발자는 개발에 참여하는 사람을 포괄적으로 지칭한다.

[3] 주로 베스트 프랙티스(Best Practices) 운운하며 다른 나라에 있는 다른 조직이 했던 방식을 모양만 따라하는 행위로 벌어진다.

[4] 그 언젠가는 결국 해를 넘겨 김형준님 합류 이후에나 가능했다.

[5] 한때 필자는 프레임워크에 푹 빠져 대기업 프레임워크 개발 이후에 다른 프레임워크 구축 PM도 맡은 바 있고, 그때 활용했던 오픈소스인 Spring에 매료되어 KSUG(한국 스프링 사용자 모임)이라는 단체를 만든 이력이 있다.

[6] 우리는 마이크로 서비스 최소 단위를 모듈이라 부른다.