근황

몇달 전 새로운 회사로 이직을 했습니다. (그래서 몇달동안은 눈치보느라 적응하느라 글을 못 썼어요.)
작은 스타트업이고, 제가 할 수 있는 일이 많을 것 같아서 (그리고 제 마음대로 할 수 있을 것 같아서) 여러 회사 중 현재 회사를 선택했죠.
결론적으로 후회하지는 않습니다만, 아쉬운 점이 몇 가지 있습니다.

현재 회사는 회사 크기에 비해 업력이 짧지는 않습니다. 보통 스타트업이라고 생각하면 창업한 지 1-2년 내의 회사를 떠올리는 경우가 많은데, 그것보다는 조금 오래되었어요.
그러다보니 많은 개발자가 거쳐갔고, 개발자의 흔적들이 여러 군데에 남아있습니다.
이런 건 어디서든 볼 수 있는 현상이기 때문에 그런가보다 하고 받아들일 수 있습니다.

백엔드의 구성

문제는, 각 시스템이 각각 다른 언어와 프레임워크로 작성되어 있다는 거에요.
현재 저희 회사 백엔드 기술 스택은 대충 다음과 같이 이루어져 있습니다.

• 자바 - 스프링부트
• 파이썬 - flask
• 파이썬 - AWS 람다
• 파이썬 - vanilla python
• 노드JS - express
• php - 코드이그나이터3
• php - vanilla php

(이걸 저 혼자 다 관리하고 개발한다는 것이 아이러니..)

겉보기에는 단순한 편에 속하는 제품을 만들고 있기 때문에, 도대체 뭐가 이렇게 많은가 싶었죠.
단순히 여러 언어로 된 시스템이 많은 거면 그럴수도 있겠구나.. 싶겠지만, 이 시스템들은 서로 연결되어 있습니다.
단순히 데이터베이스를 공유하는 것이 아니라 "A 시스템에서 B시스템의 API를 호출하고, 다시 C를 호출한 다음, C가 A의 다른 API를 호출하고 그 다른 API는 다시 B의 ..." 이런 식으로 되어 있습니다.
그래서 전체를 다 알지 못하면 아무것도 고칠 수가 없어요.

만약에 모놀리딕 아키텍쳐로 구성되어 있다면 단순히 F3 키를 눌러서 메소드가 어떻게 구성되어 있는지 확인할 수 있는 것도, 뭔가를 찾기 위해서 "다른 프로젝트를 열고, API 엔드포인트를 확인하고, 그제서야 내용이 어떻게 구성되어 있는지 확인" 하는 과정을 여러 번 거쳐야지만 간신히 전체를 끼워맞출 수 있습니다.

그렇습니다. 사실 이런 구성은 Micro Service Architecture에서 지향하는 시스템은 분산되어 있지만 전체는 하나의 구성처럼 움직이는 구조가 아니라, 그저 여러 시스템이 제 멋대로 난립되어 있는 형태에 가까워요.
그래서 저는 저희 회사 시스템을 Micro Service Architecture가 아니라 Mad Service Architecture 라고 멋대로 개명해 부르고 있습니다.

추가적인 이슈

여러 언어를 오가다보면 문법이나 라이브러리의 사용법이 다르기 때문에 "문제에 집중하는 것이 아니라 코드를 해석하는 데 집중"하게 되요.

설상가상으로 이 회사를 거쳐갔던 수많은 개발자들도 저처럼 "내 마음대로 할 수 있을 꺼야"라는 개발자의 로망을 맘껏 실현시키신 분들이 많아서.. 도대체 왜 이런식으로 구성해 놓았는지 잘 이해가 안가는 경우도 좀 있고요.

신기술을 도입하고 이것 저것 해 보고 복잡함에 압도되어 퇴사하고, 다음 사람은 이미 복잡한 시스템 위에 또 새로운 복잡함을 추가하고..의 반복이었을 것으로 예상됩니다.

깨달은 점

스타트업은 헬이야! <- 아닙니다.

실은 저도 MSA에 로망이 있었어요.
쿠팡의 MSA 사례를 유튜브에서 보면서 이거 잘 사용하면 멋지겠는데? 라는 생각도 많이 했었고, 스프링으로 하는 마이크로서비스 구축 같은 책을 보면서 "뭐라고 하는지는 모르겠지만 멋진걸?" 이라는 환상을 품기도 했었으니까요.

MSA 자체가 나쁜 것은 아닙니다. 분명히 넷플릭스 같은 시스템을 만들때는 MSA가 아니라면 빌드하다가 밤을 새는 일도 허다할 테니까요.

하지만 만약 MSA를 도입하려면, 전체 아키텍쳐를 잘 꿰고 있는 사람, 문서, 혹은 시스템이 반드시 필요할 것 같습니다. 그저 개발을 잘하는 사람 말고, 비즈니스와 개별 시스템의 연결고리를 잘 알고 있는 사람이요.
이 사람이 퇴사한다면 이 회사도 퇴출이야! 정도의 사람이 반드시 필요하다는 생각이 들었어요.

"넌 제대로 된 MSA를 경험해 보지 못했어!" 라고 하신다면 할 말은 없습니다. 오히려 "도대체 된 MSA가 뭔데?" 라고 물어보는 방법밖에요. Spring Cloud를 도입하신 분들은 이런 복잡한 문제가 없는지도 궁금합니다.
게다가 뭔가 오류가 났을 때 도대체 디버깅은 어떻게 하는지 (API를 하나씩 따라가보는 방법밖에 없는지), 간단한 기능 하나를 도입하려고 했을 때 서버 종단간의 아키텍쳐까지 고려서 개발을 하시는지도 궁금하고요.

저는 지금 사실 Micro도 아닌, Mini 정도 되는 아키텍쳐의 구성인데도 복잡함에 압도되고 있어요.
저도 개발 경력이 10년이 넘었기 때문에 왠만한 구조나 크기에는 놀라지 않습니다만, 이번 회사는 코드를 볼 때마다 매일 놀라고 있습니다.

지금 다시 구성하라면

"시간을 줄 테니 회사의 모든 아키텍쳐를 재구성해주시겠어요?" 라고 제안해 주신다면 저는 지체없이 모놀리딕 아키텍쳐를 선택할 겁니다.
스타트업에 있어서는 무한대의 확장을 위한 MSA보다 특별한 고민 없이 일단 만들고 배포할 수 있는 속도가 더 중요하다고 생각하기 때문이에요.
백엔드 개발자는 달랑 한명인데 도대체 왜 서비스를 분산해야 하는지에 대한 답을 아직도 찾지 못했기 때문이기도 합니다.

개인적으로 좋아하는 개발자 중 하나인 DHH의 The Majestic Monolith 를 보면 , Basecamp 정도되는 시스템도 모놀리딕으로 잘 실행됩니다.
물론 이건 ROR이 훌륭해서라기보다는 Basecamp가 37signals일 때부터 CTO였던 DHH의 힘이 더 크다고 생각하지만, 다른 스타트업이라고 해서 DHH처럼 기술의 중심을 잡아줄 수 있는 CTO가 없는 것은 아니니까요.