마이크로 프론트엔드 개발

마이크로xx 개발은 '개인사업자'가 '법인'으로 전환하는 것과 같다.

 

사실상 혼자서 개발한다면 굳이 협업 과정을 따질 이유가 없다. 아무렴 그냥 하면 된다. 

문제는 팀과 팀끼리 중~대규모 sw 협업이다. 

 

 

 

1 모놀리틱 

모놀리틱(소규모 개발)

 

JS 3대장 '리액트, 뷰, 앵글러'를 사용한다면 서비스에 대한 아키텍처 과정을 생각할 필요가 없다. 정해진 컴포넌트와 각종 훅을 사용해 폴더 정리만 하면 된다. 

 

그런데 개발자 5,000명이 단 하나의 프로젝트를 개발하는 상황을 생각해보자.

 

혼자서 반취미용으로 개발하며 프레임워크에 의존한 개발자들은 아마도 대략 다음 2가지 선택지를 꺼낼 것이다.

 

1. 그냥 혼자서 한다 (4999명 해고)

2. 새로운 아키텍처를 개발한다

 

결론적으로 위의 2가지 모두 권장하지 않는 방법이다. 1번은 부족한 실력을 숨기려는 개발자의 변명이며, 2번은 개발된 수레바퀴를 또 개발하는 셈이다. 그럼에도 대부분 스타트업들은 1번, 대기업들은 2번을 선택한다. 그래서 스타트업은 개발자들의 횡포에 공중분해(1명 개발자에게 권력 집중), 대기업은 그들만의 세상에서 가장 비효율적인 결과물을 선보인다. 

 

 

 

 

2 마이크로 방식

마이크로: 직접 연계(x)

 

5,000명의 개발자가 공동으로 1개의 프로젝트를 개발한다면, 위와 같이 하위 모듈간 직접적인 연결은 피해야한다. 대규모 작업에서 직접 연결은 고착을 불러일으키고, 이는 점차 변화에 취약한 상태를 만들기 때문이다. '유연한 설계', 유연성 만이 대규모 프로젝트의 본질이다.

 

이와 같은 유연한 설계는 '프랜차이즈', '도요타 시스템', '나이키 아웃소싱'과 같은 사례가 대표적이다.

 

기업규모 성장 = 모듈형 설계

 

가령, 자동차 회사는 외관만 다를 뿐 공유하는 플랫폼은 같다. 그래서 협력사(부품업체)는 완성차가 아반떼인지 소나타인지 신경쓰지 않고 자체 개발에만 집중하면 된다. 어차피 외관과 크기만 다를 뿐, 부품은 같기 때문이다. 맥도널드와 나이키 역시 유연한 설계로 성장했다. 전세계 어느 매장이건 '나이키, 맥도날드' API(브랜드 로고)를 반영한 제품들이 놓여있다. 그러므로 사용자는 일정 수준 이상의 품질을 경험한다. 대규모 웹개발 역시 이렇게 되어야 한다. 

 

 

가령, 'Product'개발팀과 'Shopping Cart'개발팀은 (서로 간섭하거나 받지 않고) 독자적으로 개발한다. 

(팀별)독립적 개발

 

 

단, 각 개발팀은 본사가 정한 공통의 API를 사용해 팀마다 '독자적인 방식'으로 개발한다.

 

Micro FrontEnd: 공통 API 기반의 독자적 개발

 

 

위와 같이, 공통 API(본사 기준)에 따라 각 개발팀이 독자적으로 개발한다면, 대규모 팀을 협력으로 이끌 수 있다. 마치 "소고기 없는 인도의 빅맥", "양고기를 넣은 러시아 빅맥", "와인을 곁들인 프랑스 빅맥"이 세부 내용은 제각각이더라도 이것들은 모두 '빅맥'인 것과 같다. 어쨌든 맥도날드 API를 따르기 때문이다. 그래서 맥도날드는 장소와 문화 그리고 상황에 따라 유연하며, 1~2개의 사업장을 운영하기에도 벅찬 수제 햄버거 가게와 달리 전세계 37,000여개의 매장을 운영할 수 있다.

 

대규모 sw개발 역시 맥도날드 시스템(유연한 설계)과 같아야 한다.

 

 

팀별 다른 프레임워크 & 공통API

 

 

 마이크로 프론트엔드 방식은 "리액트, 뷰, 앵글러"를 제각각 사용하는 개발자들의 협력도 가능하다. 이로써 개발자 채용에 굳이 특정 언어나 프레임워크를 사용하는 제약을 걸 필요가 없다.(시작부터 유연하며 인재채용에 앞서나갈 수 있음) 만일, 특정 언어와 프레임워크를 고집하는 CTO가 있는 회사의 미래는 어둡다. 이미 시작부터 고착화 된 것이나 다름없기 때문이다.

 

어느 스타트업의 제품이 모놀리틱으로 개발된 상황을 가정해보자. 

모놀리틱 쇼핑몰

 

위와 같이, 쇼핑몰의 기본 뼈대부터 "리액트(or 기타 프레임워크)"라면 신입사원도 리액트를 알아야 한다. 또, 리액트가 변경되면 변경된 리액트를 배워야 하고, 리액트 플러그인에서 오류가 발생하면 다른 '리액트' 플러그인을 찾아야 한다. 끊임없이 '리액트'라는 메아리가 회사 내에 울려퍼지고, 심지어 리액트를 잘 구현할 수 있는지 여부가 개발자 실력이라고 착각할 수도 있다.(특정 프레임워크를 할 수 있는지 여부는 개발자 실력과 무관하다) 

 

 

 

 

3 유연한 설계

결국 '유연성'이다. CTO가 제대로 된 회사라면, "특정 프레임워크", "버전"에 종속되지 않는다. 그래서 회의 때마다 새로 출시된 '라이브러리'나 '프레임워크'에 대한 학습 공포가 없으며, 개발자들이 뭔가를 배운다고 주말과 야근을 밥먹듯 할 필요가 없다. 좋은 회사의 기술팀은 대략 아래와 같이 굴러간다.

 

 

MFE #1, MFE #2는 각 개발팀이며, 프로젝트 규모에 따라 MFE #n.. 팀의 수는 유연하게 조절된다. 가령, 'Container'가 햄버거의 브랜드, 조리방식, 조리시간, 재료 설정, 포장방법, 고객응대, 등.. 과 같은 "회사 공용 API"라면 "MFE #1 = 한국 맥도널드", "MFE #2 = 일본 맥도널드", 등.. "MFE"는 무한정 늘어날 수 있다. 서두에 제시한 5,000명의 개발자로 팀을 만들 수 있으며, 그 이상도 가능하다. 

 

하지만 여전히 많은 회사들이 특정 프레임워크나 방식에 열광하며, 수제 햄버거 방식에 열광한다. 이 상황이 뭔가 불안한 이유는 개발자라면 직감적으로 알고 있다. 다만, 개발자 교육방식부터 어쩔 수 없는 코딩산업의 현실에 순응할 수 밖에 없다.