DHH(@dhh)의 스레드

마이크로서비스는 소프트웨어 업계에서 가장 성공적인 사기극입니다. 작은 팀들에게 "큰 그림을 그리고 있다"는 착각을 심어주면서도, 실제로는 움직일 능력 자체를 체계적으로 파괴합니다. 불안감을 무기로 삼아 야망을 부추깁니다. 서비스 집합체를 운영하지 않으면 과연 제대로 된 회사인가? 이 아키텍처가 원래는 지구 규모의 조직 기능 장애에 대처하기 위해 고안되었다는 사실은 중요하지 않습니다. 이제는 슬랙 채널과 점심 식탁을 공유하는 작은 팀들에게까지 마이크로서비스를 강요하고 있습니다. 소규모 팀은 공유된 컨텍스트를 기반으로 작동합니다. 이것이 그들의 가장 큰 강점입니다. 모든 구성원이 엔드 투 엔드를 이해하고, 무엇이든 변경할 수 있습니다. 하지만 마이크로서비스는 이러한 장점을 순식간에 없애버립니다. 공유된 이해를 분산된 무지로 대체하는 것입니다. 더 이상 전체를 소유한 사람은 없고, 모두가 샤드를 소유하게 됩니다. 시스템은 팀이 적극적으로 이해하는 대상이 아니라, 그저 팀에 발생하는 무언가가 되어버립니다. 이것은 정교함이 아니라 책임의 포기입니다. 그다음은 운영상의 우스꽝스러운 상황이 펼쳐집니다. 각 서비스는 자체적인 파이프라인, 비밀 키, 알림, 지표, 대시보드, 권한, 백업, 그리고 온갖 종류의 달래기 의식을 요구합니다. 더 이상 "배포"가 아니라 "군대 동기화"를 해야 합니다. 버그 하나를 고치려면 여러 서비스에 걸친 분석이 필요합니다. 기능 출시는 아무 이유 없이 만들어낸 인위적인 경계를 넘나드는 조정 작업이 되어버립니다. 시스템을 단순화한 것이 아니라, 산산조각 내고 그 잔해를 "아키텍처"라고 부른 셈입니다. 마이크로서비스는 또한 미숙함을 고착화시킵니다. 비즈니스를 제대로 이해하기도 전에 API를 정의해야 하는 상황에 놓이게 되고, 추측이 계약이 되어버리며, 잘못된 아이디어가 영구적인 의존성으로 굳어집니다. 초기의 모든 실수는 네트워크를 통해 확산됩니다. 모놀리식 아키텍처에서는 잘못된 사고방식을 리팩토링으로 바로잡을 수 있지만, 마이크로서비스에서는 잘못된 사고방식이 인프라로 귀결됩니다. 단순히 후회하는 데 그치지 않고, 호스팅, 버전 관리, 모니터링까지 직접 해야 합니다. 모놀리식 아키텍처가 확장성이 없다는 주장은 현대 엔지니어링 속설 중 가장 어리석은 거짓말 중 하나입니다. 확장성이 없는 것은 혼돈입니다. 확장성이 없는 것은 프로세스를 흉내 내는 것입니다. 확장성이 없는 것은 단순한 CRUD 앱을 출시하면서 넷플릭스인 척하는 것입니다. 모놀리식 아키텍처는 팀에 규율, 테스트, 그리고 절제가 있다면 충분히 확장 가능합니다. 하지만 절제는 유행이 아니고, 지루한 것은 컨퍼런스 발표 소재가 되지 않습니다. 소규모 팀을 위한 마이크로서비스는 기술적인 실수가 아니라 철학적인 실패입니다. 이는 팀이 스스로의 시스템을 제대로 이해하지 못한다는 것을 명백히 보여주는 것입니다. 책임감을 프로토콜로, 추진력을 미들웨어로 대체하는 것이죠. 미래에도 문제없이 사용할 수 있다는 보장은커녕, 영구적인 정체만 초래합니다. 결국 이러한 혼란을 정당화할 만큼의 규모를 갖추게 될 즈음에는, 팀의 속도, 명확성, 그리고 제품에 대한 직관력은 이미 사라져 있을 것입니다.