적절한 마이크로서비스를 도입하는 시기는 언제일까?

 

지난 해 9월 트레바리 테크유닛으로 이직을 결정하게 된 주요 이유 중 하나는 마이크로서비스를 직접 구축 할 수 있는 기회에 있었습니다.. 이 후 약 8개월이 지난 이 시점에 '적절한 마이크로서비스를 도입하는 시기는 언제 일까?' 을 고민하는 것은 뒷북일 수 있지만, 이제는 이 부분에 대해서 어느정도 답을 할 수 있는 시점이 아닐까? 싶어 고민하게 되었습니다.

---

1.
다우기술에 근무할 적 약 90만 라인이 자바 코드가 모듈형 모놀리스 아키텍쳐로서 운영되는 프로젝트를 약 2년 넘게 관리했었습니다. 이 방대한 코드 속에서 마이크로서비스가 말하는 모놀리스 아키텍쳐의 단점을 운이 좋게도 모두다 겪어볼 수 있었습니다.

• 약 2주에 한 번씩 배포 빈도를 가집니다.
• 코드가 심각하게 방대해, 도메인에 집중할 수 없어 스파게티 코드가 되는 깨진 유리창을 봐왔습니다.
• 코드가 방대해짐에 따라 테스트 코드는 더 이상 관리할 수 있는 대상이 될 수 없었습니다.
• 기술 선택에 있어서 언제나 난항이였습니다. 당시 JAVA 1.8을 사용했지만 , 11을 사용할 수 없었습니다. 이유는 사이드카로 같이 운용되는 솔루션이 JAVA1.8까지만 지원됐기 때문입니다.

이런 문제점을 격하게 겪으면서 내몸이 불편함을 인지하지 못할 정도로 편안해져 몰라서 보이지 않던 단점이 마이크로서비스를 학습하게 되면서 보이게 되었습니다.

--

운이 좋게 마이크로서비스 패턴 스터디를 하게 되면서 다른 개발자분의 생각을 엿볼 수 있었습니다.

그 분들의 이야기를 가져와보면 다음과 같습니다.

언제 마이크로서비스 를 도입하는 것이 적절한가?

2.

지금이 마이크로서비스를 도입해야되는 시기라고 인지하고 있었다고 합니다. 그러나 마이크로서비스를 도입하기 위해서 알아야할 것이 많았다. 트랜잭션 관리부터 DB까지 고려해야될 부분이 많았고 이런 부분이 마이크로서비스를 도입하는 것을 방해하는 요소가 되어 도입할 수 없었다.

--

3.

'마이크로서비스를 도입하는 시기를 기다리고 있다. 아직 개발자가 많지 않고 빠르게 개발하기 위해서 모놀리스가 맞다. 그러나, 생산성이나 배포빈도가 늦어지는 현상을 겪는다면 그 때 마이크로서비스를 도입할 것이다'

--

4.

A: 우리 회사에서는 마이크로서비스를 도입하는 리더가 3~4년차 개발자이다. 경험이 많은 개발자에 비해 마이크로서비스 자체에 대한 이해가 부족한 리더 때문에 올바른 길을 걷고 있지 않는 것으로 보인다. 마이크로서비스를 도입한다는 건 도박일 수도 있다는 생각이 들었다.

Q: "언제 그런 생각을 했는가?"
A: 조인이 필요한데 조인을 할 수 없을 때 그런 생각이 들었다.

--

여러 케이스에서 보이는 것과 같이 마이크로서비스를 도입하는 적절한 시기는 쉽게 답을 내리기 어려운 문제라 판단됩니다. 이전 근무지였던 다우기술의 경우 개발자만 100명이 넘는 회사입니다. 그런 거대한 회사가 마이크로서비스를 몰라서 하지 않았을까요? 한 때 그 회사의 조각으로 근무하던 적에 도입하지 못했던 이유를 생각해보면 언제가 적절한 시기인지 고민에 대한 답을 알 수 있었습니다.

---

 

마이크로서비스를 도입하는 적절한 시기 에 대한 저의 생각을 적어보려 합니다.

마이크로서비스라는 것은 장점과 단점이 분명히 보인다고 생각합니다 심지어, 마이크로서비스에 대한 학습을 처음 하는 사람일지라도 당장 알 수 있는 부분이라 생각합니다.(많은 책들의 앞부분을 할애하고 있어서...) 장점과 단점을 이미 알고 있다는 전제하에, 마이크로서비스를 도입 하는 시점은 내 옆에 있는 팀원의 자세에 달려있다고 생각합니다. 다시 말해, 내 옆에 있는 팀원과 더불어 팀이라 불리는 그 자체에 대한 성숙도(?), 태도(?)에 있다고 생각합니다.

트레바리에서 기존 모놀리식 아키텍쳐를 마이크로서비스로 조금씩 작은 스텝으로 전향해가며 좀 더 확신을 가질 수 있었습니다. 예를 들어 '이런 문제가 있는데, 이 문제를 어떻게 해결해야하지?' 라는 질문에 모든 동료가 악착같이 화이트보드 앞에 서서 함께 고민해주는 것. 이것이 곧 팀의 성숙도를 올라갈 수 있도록 해주는 장치가 되고 결과적으로 마이크로서비스로 조금씩 전향해가는 과정에서도 서로를 믿을 수 있는 고리를 만들어 주는 것이 아닐까 싶습니다.

다우기술에서 근무할 적에 유심히 살펴보면 위에서 말하고자 하는 팀의 성숙도가 늘 넘기 어려운 장애물이 되는 것처럼 느꼈졌고, 이는 곧 '마이크로서비스 도입 불가능'이라는 결과물을 만들어내고 있었던건 아닐까 싶습니다.

--

또 적절한 도입시점을 결절할 수 있는 주요한 단서는 무엇이 있을까?

 

앞서 언급한 것과 비슷한 대답일 수 있는데, 내 옆에 있는 팀원과 나 그리고 팀 자체가 마이크로서비스 패턴 에 대해서 얼마나 잘 알고 있는가? 에 대해서도 중요한 결정요소가 될 수 있을 것 같습니다.

 

생각보다 마이크로서비스 패턴 의 각 개념은 단순합니다. 그러나, 운영하는데 있어 많은 높은 난이도의 개발 복잡성을 경하게 됩니다. 그러므로, 이 문제를 해결할 수 있는 경험치를 필요로 하고 있습니다.

 

여기서 말하는 필요한 경험치를 팀원 모두에게 공유할 수 있는 부분이라면 마이크로서비스를 도입하려는 것에는 장애물이 없지 않을까요? 실제로 근무하고 있는 트레바리에서도 이벤트 소싱이라는 패턴을 이해하기 위해 약 일주일간 동료들끼리 고군분투하며 POC를 진행해보며 패턴이 이해가 될 때까지, 그리고 운영이슈를 기술부채로 쌓으면서 경험치를 습득했습니다. 그 결과, 이제는 더 이상 이벤트 소싱이라는 마이크로서비스 패턴에 대한 이해도가 함께 올라갔습니다.

 

당연히 지금은 이벤트 소싱이라는 용어를 사용했을 때, 그 누구도 어려워하지 않고 어떤 것을 개발해야 하는지 알게 되었습니다.

 

생각을 정리해보면 크게 2가지가 마이크로서비스를 도입할 적절할 시기를 결정하게 해준다고 생각합니다.

1. 내 옆의 동료가 우리의 문제를 대하는 자세가 중요하다.
2. 팀 자체가 마이크로서비스 패턴에 대한 이해가 높아야만 한다.

위 2가지가 문제없다면, 그 순간이 바로 마이크로서비스를 도입할 수 있는 적절한 시기이지 않을까?