백엔드 설계와 확장: 마이크로서비스 vs 모놀리스
백엔드 아키텍처는 하루의 업무가 얼마나 싸움으로 변할지를 결정한다. 앱이 커질수록 처음 선택의 균열이 드러나기 시작한다. 그리고 어느 순간 방향을 정해야 하는 지점에 도달한다. 모놀리스를 유지할까. 아니면 전부 마이크로서비스로 분해할까.
은탄환은 없다. 두 방식 모두 나름의 자리가 있다. 올바른 선택은 순수한 기술적 우수성보다 팀 구조와 사업 단계에 좌우되는 경우가 많다. 이 글에서는 두 가지 주요 옵션과, 실제로 가장 잘 통하는 현실적인 중간 지점을 살펴본다.
마이크로서비스의 발상은 단순하다. 거대한 앱 하나를 만드는 대신, 작고 독립적인 서비스들의 집합을 만드는 것이다. 각각이 한 가지를 잘 해낸다.
분산된 팀을 떠올려 보라. 각 서비스는 자신의 데이터베이스를 운영하고, 준비되는 대로 다른 이들에게 허락을 구하지 않고 언제든 배포할 수 있다. 결제 팀이 Go를 쓰고 인증 팀이 Rust를 좋아해도 둘 다 양보할 필요가 없다. 그 자유가 사람을 빠르게 만든다. 적어도 이론상으로는.
실제로 이 방식은 500명의 개발자가 있는 곳에서 단 한 번의 릴리스를 조율하는 게 악몽인 대규모 조직에 잘 맞는다.
모놀리스는 전통적인 방식이다. 코드베이스 하나, 앱 하나, 배포 한 번. 사용자 인터페이스부터 비즈니스 로직, 데이터 접근까지 모든 것이 함께 산다.
'모놀리스'라는 단어는 일부 집단에서 거의 욕설이 되다시피 했다. 그래도 실제 장점은 남아 있다. 단순하다. 함수가 어디에 정의됐는지 찾는 데 지도가 필요 없다. 배포는 스크립트 하나로 끝난다. 소규모에서 중간 규모의 팀에게 그 단순함은 초능력이다. 인프라의 복잡성에 빠지지 않고 빠르게 움직일 수 있게 해준다.
중소기업에서 흔한 안티패턴은 엔지니어보다 마이크로서비스가 더 많은 상황이다. 100명의 엔지니어가 300개가 넘는 서비스를 유지하려는 조직을 본 적이 있다. 결과는 완전한 혼란이다.
그 선을 넘으면 많은 서비스가 주인을 잃거나, 주인이 조직 개편 때문에 맥락을 알지 못하는 서비스를 물려받는다. 또한 모든 저장소에서 의존성을 업데이트해 취약점을 해소하는 데 시간을 더 쏟는다. 마이크로서비스를 제대로 하려면 전담 플랫폼 팀과 도구에 대한 상당한 투자가 필요하다. 대부분의 스타트업은 그런 인프라를 마련할 여유가 없어서, '애자일'한 설계가 유지보수의 악몽으로 변한다.
유행이라서 아키텍처를 고르면 안 된다. 실제로 가진 문제를 해결하기 때문에 골라야 한다. 트렌드는 결정에 들어오면 안 된다.
다음 경우엔 마이크로서비스:
다음 경우엔 모놀리스:
여기 비밀이 하나 있다. 마이크로서비스로 곧장 뛰어들 필요가 없다. 아마 그러지 말아야 한다.
모듈러 모놀리스는 탄탄한 중간 지점이다. 배포 단위는 하나지만, 내부에서는 모듈 사이에 엄격한 경계를 둔다. Module A의 코드는 Module B의 코드를 직접 가져올 수 없다. 정의된 공개 인터페이스를 거쳐야 한다. 인프라 오버헤드 없이 마이크로서비스의 코드 구성 이점을 얻는다.
앱이 성장함에 따라 독립이 필요한 부분을 떼어내면 된다.
마이크로서비스 대 모놀리스 논쟁은 대개 핵심을 놓친다. 문제는 어느 쪽이 이론적으로 더 우월하냐가 아니다. 지금 당신이 어떤 트레이드오프 묶음과 함께 살 수 있느냐다.
잘 구조화된 모놀리스에서 시작하라. 고통이 나타날 때만 분리하면 된다. 미래의 당신과 DevOps 팀이 고마워할 것이다.
© Melvin Laplanche - All rights reserved.