미래를 꿈꾸고 성공을 희망하며

Django MVC 프로젝트가 Micro-frontend React 프로젝트로 탈바꿈하는 과정

* 인프라 패키지 : 동일한 빌드 툴링을 공유
* 라이브러리 패키지 : 공통 소스코드를 관리
* 서비스 패키지 : 페이지에서 독립적으로 작동

위의 방식을 통해, 소스와 빌드 설정을 완벽히 격리시키고, 서비스별 의존성 문제를 해결하여 빌드업 시간, 소스 동기화 시간을 해결할 수 있습니다. 

Monolithic에서 MSA전환 사례?

MSA(MicroService Architecture)는 Netflix에서 도입되어 IT에서 많이 화자가 되고 있습니다. 다양한 서비스들이 서로 의존성에 대한 걱정없이 배포하고 운영되는 것에 많은 흥미를 가졌습니다.

하지만, 이미 대규모의 웹, 앱을 안정적으로 운영하는 기업 입장에서 100에 +1, +2를 더하는 것은 쉬우나, 이것을 다시 1+1+1+1...(100번) 하여 재구축하는 것은 전면 재구축이라, 단순 MSA로 전환에 따른 이점이 크지 않아 도입하는게 좋은 선택이 아닐 수 있습니다. 또한, MSA에 대한 충분한 이해없이, 서비스간 의존성을 최소화하면서, 빌드, 분산 배포 계획까지 마련한 사례가 없어 참고자료가 마땅치 않습니다. 

MSA의 대표 사례인 Netflix경우, 서비스가 다양하지 않고, 일부 오류(제안, 검색 화면 등)가 나더라도 크리티컬하지 않지만, 금융거래 또는 개인정보 처리 및 전자서명하는 거래의 경우에는 거래의 무결성을 보장해야 하기에 오히려 부적합할 수도 있습니다. 

토스는 다른 전략을 갖고 개발되는 제품(서비스)들이 다르게 개발될 수 있는 문화가 이미 정착되어 있고, 그런 환경이기에 MSA가 적합해 보입니다. 그래서 제품 전략적으로 독립된 제품들이 기술적으로도 독립할 수 있는 것입니다. 따라, 각자 다른 엔지니어와의 커뮤니케이션을 최소화하여 개발에 집중할 수 있지만, 다른 측면으로는 추후 업무 이관 등 관리적면에서는 또다른 문제가 있을 수 있습니다. 기존 Monolithic 방식의 장점이 이런 관리 운영적인 측면에서 체계적이었기 때문입니다. 

빌드 시간 최소화

전체 소스빌드가 아닌 incremental build를 이용하여 변경된 소스만 빌드하고, 기존 소스는 빌드하지 않고, 그대로 이용하면 됩니다. Eclipse 기반에서는 build는 auto를 설정하면, 기본적으로 지금 수정된 파일만 incremental build를 수행하고, "clean"을 명령해야 전체 소스를 build합니다. 또한, 상용/무료 형상관리 프로그램 역시 두가지 버전(clean, incremental)을 모두 지원하고 있습니다. 

우리가 사용하는 서버의 Java 버전이 변경되는 경우는 매우 드믑니다. 없다고 생각하셔도 좋습니다.

• 전체 소스코드를 rebuild해야 하며, 그과정에서 일부 소스 수정이 필요할 수도 있습니다. 따라 전체 메뉴에 대한 기능 테스트를 수행
• 이용하고 있는 암호화 솔루션, 프린트 솔루션 등 자바 버전이 충돌되어 오작동하는 솔루션이 있는지 미리 체크
• Java 버전 변경의 장점이 매우 적어 버전업을 하지 않지만, 너무 오래된 버전(1.3 등)의 경우에는 신기술 도입을 위해 전면 재개발을 할 때, 신규 서버에 Java 버전을 최신의 안정화 버전으로 Up

Java 버전이 변경되는 경우가 아니라면, 굳이 전체 소스를 build, 배포할 필요가 없으며, 배포할 필요가 없는 소스를 굳이 build할 필요 역시 없습니다. 

요약
• 수평적인 애자일 조직(각자 다른 서비스앱을 개발하는 것이 아니라, 여러팀이 각자 서비스를 단일 앱에 올리는 경우)에 MSA는 좋은 선택
• 변경한 소스만 build : Zero-Build