MSA와 CICD가 실패하는 이유

개발 프로젝트 현장을 보면 '애자일' 단어 만큼 요즘 많이 나오는 단어가 'MSA', CICD'인 것 같습니다. 그러데 애자일, MSA, CICD를 주장하는 프로젝트 중 이전의 개발 프로젝트와 다른 점은 크게 보이기 않습니다. 단지 용어나 사용하는 툴이 바뀐 것 정도 밖에 없어 보입니다.

저는 개발자는 아닙니다. 하지만 인터넷 벤처와 피처폰 모바일 웹 시절부터 마케팅과 서비스, 사업 기획을 해온 나름 시스템 전문가이고 조직 구조 설계자, 전략가라 자부합니다.

그러므로 단지 기술의 적용과 용어의 사용을 그대로 받아들이지 않습니다. 발생되는 데이터와 현상을 토대로 주장하는 기술과 단어가 지향하는 개념과 철학을 비교 분석해서 결론을 냅니다.

이렇게 데이터 중심 판단으로 볼 때, MSA, CI/CD를 말하는 프로젝트가 실패하는 이유는 과거의 프로젝트 진행 방식과 다르지 않다는데 있습니다.

마이바흐를 구매했다고 세계 최고 드라이버가 되는 것이 아닙니다. MSA, CI/CD를 주장하고 관련된 툴을 구매했다고 MSA, CICD 최고 전문가가 된 것은 아닙니다. 이 차이를 모르는 것이 실패 이유입니다.

아마존 사례: MSA, CICD가 성공하는 이유와 실패하는 이유

아마존은 '피자 두 판 팀'이 있습니다 "피자 두 판으로 식사를 마칠 수 있는 규모"의 조직을 말합니다. 이 팀이 하나의 마이크로서비스를 전담합니다. 기획부터 운영까지 책임지는 것입니다.

아마존 직원 수가 대략 150만 명 넘는 수준이므로, 피자 두판 팀은 수 백개 수준이 아니라 물류 인력을 제외한다고 해도 수천 개는 될 것이라 추정됩니다.

그런데 이런 많은 피자 두 판 팀에서 개발해서 배포하는 코드가 서로 연동될 수 없다면, 아마존 플랫폼이 제대로 작동되지 않을 것입니다.

여기서 아마존 플랜폼의 작동과 서비스 지속성이라는 IT 시스템 측면의 MSA와 CI/CD가 나옵니다. 마이크로 서비스 아키텍처(피자 두 판 팀으로 구성)를 취하는 순간 지속적인 통합과 배포(CI/CD)를 위한 전략과 관리가 필요하게 됩니다.

그러면 MSA와 CICD가 아마존이라는 전체 플랫폼 측면의 방향성과 연동 규칙(API)을 정하는 것은 누구일까요?

만약 수천 개 피자 두 판 팀(마이크로 서비스 팀)이 서로의 이익을 주장하며 개발의 방향성을 자신의 팀에 맞추라 하고, 연동(API)도 자신의 규칙에 맞추라 주장한다면 아마존 플랫폼이 유지될 수 있을까요?

소프트웨어 공학의 아키텍처인 MSA와 CI/CD가 성공하기 위해서는 이를 적용할 수 있는 조직이 되어야 합니다. 그래서 MSA와 CI/CD는 세트로 애자일 조직론과 묶이는 것입니다.

특히 아마존과 같은 매머드 조직이 일관성과 속도를 동시에 확보하기 위해서는 단순히 개발 기술과 아키텍처만으로 불가능합니다. 기술과 아키텍처를 작업하는 작업자(개발자)는 사람이기 때문입니다.

외주 개발에서 MSA와 CI/CD가 실패하는 이유

아마존은 피자 두 판 팀을 MSA로 통합하기 위한 CI/CD를 적용하였습니다. 그런데 외주 개발 프로젝트에 참여해 보면 피자 두 판 팀 하나에 해당하는 8~10정도 팀이 스스로 MSA와 CI/CD를 설계하고 관리한다고 합니다.

기본적으로 MSA와 CI/CD 관리의 대상이 되어야 하는 마이크로 서비스 팀이 스스로 설계자와 관리자가 된다고 합니다.

이는 마치 아마존의 수천 개 MSA 팀이 모두 자신이 아마존 플랫폼의 설계자이고 관리자가 되겠다고 하는 것과 같습니다. 결국 CI/CD가 될 수 없습니다.

앞서 아마존 MSA와 CI/CD 적용 사례에서 성공이 아닌 실패할 수 밖에 없는 조직론이 적용되고 있기 때문에 외주 개발 팀이 MSA와 CI/CD은 실패하는 것입니다.

실제로 시스템 분석 측면에서 프로젝트에서 발생되는 데이터를 보면 전형적인 관료제 조직의 징후가 보입니다. 말과 기술, 툴은 MSA와 CI/CD인데 전형적인 변화 없는 전통 산업 조직의 모습을 보이고 있는 것입니다.

바로 이런 모습이 외주 개발에서 MSA와 CI/CD 실패하는 이유입니다.

MSA와 CICD를 적용하는데 왜 기존 개발 방법론과 같은 모습일까?

MSA는 수 많은 마이크로서비스로 구성된 시스템 아키텍처를 의미합니다. 그리고 각 마이크로서비스를 담당하는 많은 팀이 존재합니다. 이 때문에 시스템을 통합 관리하기 위한 CI/CD가 필요하게 됩니다.

그런데 마이크로서비스가 하나이고, 작업하는 팀고 하나라면 CI/CD가 필요할까요?

MSA와 CI/CD를 한다는 외주 개발 프로젝트에서 기획을 해 보면 너무나 전형적인 폭포수 개발 방식을 보이는 것을 봅니다. 현재 개발 팀 이외에 마이크로 서비스 팀이 없기 때문입니다.

기업 조직 시스템과 MSA, CICD

MSA와 CICD와 조직 시스템 설계 이론

MSA와 CI/CD는 소프트웨어 공학 이전에 조직 공학에서 이미 개념과 철학이 나타났습니다.

시장이 다원화됨에 따라 기업은 하나의 생산 라인만으로 소비자 니즈를 충족할 수 없게 됩니다. 판매하는 상품이 많아지고 이에 따라 상품을 담당하는 팀도 많아지게 됩니다. 이들은 PM(프로덕트 매니저)으로 불렸습니다. PO와 같은 의미입니다.

이렇게 각 상품을 관리하는 팀은 하나의 마이크로서비스 팀이 됩니다.

삼성전자의 경우도 반도체 부문, 가전 부문, 모바일 부문 등으로 각 상품 사업 부문(BU)가 나누어져 있습니다. 이들은 하나의 마이크로서비스 부문이라 할 수 있습니다. 너무 크기는 하지만 말입니다.

모바일 부문도 스마트폰, 패드 등의 부문으로 구분될 수 있고, 또 스마트폰 부문도 갤럭시S, 폴더/플립, A를 관리하는 팀으로 구분될 수 있습니다.

이 이전에는 재무, 인사, 영업, 광고, 생산 등의 팀이 있었습니다. 이 팀들도 하나의 마이크로서비스팀이라 할 수 있습니다.

기업은 효율을 높이기 위해 이런 각각의 마이크로서비스팀의 회사의 전략에 맞게 상호작용할 수 있게 하는 업무 프로세스가 필요하게 되었습니다. 이를 API로 볼 수 있습니다.

그리고 작업량이 많아지고 상호 인터페이스가 이루어지는 과정에서 병목이 발생합니다. 이로 인한 기업 내부에 비효율이 증가합니다. 이는 단지 API 문제가 아닌 각 마이크로서비스가 다른 마이크로서비스의 요청을 받아 처리하는 시간과도 관련이 있고, 또 각 마이크로서비스 내부의 업무 효율 문제도 해당합니다. 이 때문에 데이터베이스(DB)를 관리하게 됩니다.

기업의 전략팀/기획팀은 마이크로서비스팀의 성과 자체 뿐 아니라 기업 전체 성과 지표(SPI)와 각 마이크로서비스의 기여율을 관리합니다. 또한 가치 프로세스의 병목 및 문제를 모니터링하여 효율을 높이게 됩니다.

여기서 나오는 것이 통합 관리 및 업무 프로세스 관리가 되고 이는 소프트웨어적으로 보았을 때 지속적 통합과 배포로 CICD가 됩니다.

기업 조직 이론 측면에서 외주 개발 MSA와 CICD가 실패하는 이유

기업이 성장하면 다양한 시장에서 다양한 상품으로 사업을 하게 됩니다. 이렇게 되면 때로는 하나의 상품 매출과 직원 수가 일반 중소 기업보다 더 많아지는 일도 생깁니다.

이에 따라 효율적 관리와 운영을 인사, 회계 등의 기능들도 상품 부문(BU)에 따로 두는 경우도 생기게 됩니다.

중소 기업이 상품마다 인사, 회계를 따로 두지는 않습니다. 상품 매출 규모와 인력이 그 정도는 아니기 때문입니다. 그런데 만약 중소기업이 인사, 회계를 상품마다 따로 둔다면 실무 인력(가치 생산에 핵심 작업을 하는 인력)보다 관리 인력이 더 많아지게 되는 기형 구조가 됩니다.

외주 개발에서 MSA와 CICD 실패하는 이유는 중소 기업의 예라 할 수 있습니다. 제가 MSA와 CI/CD를 적용한다는 프로젝트에 기획자로 일을 한 경우에도 실무를 하는 인력보다 관리/설계 인력이 더 많은 것을 본 이유도 여기에 기인합니다. 유휴 인력이 많은 이유도 여기에 있습니다.