Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

모노리포

'폴리리포주의자'가 모노리포를 반대하는 3가지 이유

모노리포(monorepo)와 폴리리포(polyrepo)가 무엇이냐는 질문에 답하려면 먼저 일반적인 애플리케이션을 구성하는 모듈을 살펴보아야 한다. 하나의 애플리케이션에는 여러 가지 구성요소가 있다. 즉, 몇 가지 모바일 클라이언트 앱, 웹 애플리케이션 프론트엔드, 하나 이상의 백엔드 서비스, 데이터베이스 및 데이터 관리 계층, (보고 및 관리와 같은)전문 서비스 등이다.  각 구성 요소에 연결된 소스 코드도 있다. 구성 요소를 담당하는 모든 개발자가 액세스하는 소스 코드는 코드 리포지토리에 저장된다. 코드 리포지토리와 저장소 관리 방법은 매우 다양하다. 리포지토리 대다수는 깃(Git)이라고 알려진 오픈소스 시스템에 기반한다.   각 구성 요소에는 코드 리포지토리가 있다. 자, 여기서 문제가 생긴다. 애플리케이션의 모든 구성 요소에 대한 모든 코드를 회사 전체나 애플리케이션 전체의 코드 리포지토리에 저장해야 하는가? 아니면 각 구성 요소마다 고유한 개별 코드 리포지토리가 있어야 하는가? 최근까지 애플리케이션 각 구성 요소에는 일반적으로 고유한 리포지토리가 있었다. 이 모델은 여러 개의 독립적인 코드 리포지토리를 가진 애플리케이션과 관련이 있으므로 폴리리포라고 한다.  그러나 최근 몇 년 동안, 특히 구글을 비롯한 일부 업체는 모든 애플리케이션 구성 요소의 모든 코드를 하나의 큰 리포지토리에 집어넣는 쪽에 찬성했다. 이러한 코드 관리 모델을 모노리포라고 한다.  폴리리포와 모노리포 방법론은 각기 장단점이 있으며, 분석 기사도 많았다. 과연 둘 중 어떤 방식을 사용해야 하는 것일까? 개인적으로는 전통적인 폴리리포 모델이 훨씬 우수하다고 생각한다. 모노리포 모델은 잘못된 습관이나 건전하지 않은 프로세스를 조장하고, 개발 조직의 확장 가능성과 애플리케이션 자체의 복잡성 등으로 애플리케이션 확장이 실질적으로 더 어려워진다. 이 주장을 뒷받침하는 3가지 이유를 면밀히 살펴보자.   이유 #1 : 모노리포는 단일 팀 소...

모노리포 폴리리포 리포지토리 2021.11.10

'마이크로서비스, 모노리포, SRE'…덮어놓고 구글 따라하면 안 되는 기술들

몇 년 전, 구글은 클라우드 제품 홍보 방식을 두고 고민을 거듭했다. 2017년 당시 필자는 구글이 일반 기업이 ‘구글처럼 운영’할 수 있도록 지원해야 한다고 제안했다. 그러나 한 구글 클라우드 제품 담당 고위 임원과의 대화에서 구글이 이 접근 방식을 배제했다는 사실을 알게 됐다. 이유가 무엇일까? 주류 기업의 요구사항이 구글과 달랐을 수도 있고, 구글처럼 하라는 말이 오히려 기업에 지레 겁을 먹게 할 것이라고 생각했을 수도 있다.   일반 기업의 IT 부서에서 일하는 보통 사람들(결국 모든 사람이라는 뜻)이 걱정할 필요 없다. 어차피 이제 구글이 하는 많은 일이 일반 기업의 IT 요구사항과는 맞지 않기 때문이다.   AWS 엔지니어이자 아파치 HTTP 서버를 만든 사람 중 한 명인 콤 맥카타이는 트위터에서 ‘아마존, 구글, 마이크로소프트, 페이스북이 하고 있지만 다른 모든 기업에는 맞지 않는 기술의 예’가 무엇일지를 물었다. 이 질문에 대해 과도한 업타임 보장, 사이트 안정성 엔지니어링, 마이크로서비스, 모노리포 등 여러 유익한 답이 나왔다.   과도한 업타임 보장 피트 엘크는 “99.999%, 또는 그 이상의 가용성 보장은 FAANG으로 불리는 페이스북, 아마존, 애플, 넷플릭스, 구글만한 규모가 아니라면 의료와 911 콜센터 정도를 제외하고 필요한 분야가 없고 ROI도 맞추지 못할 것”이라고 말했다.   필자도 여러 신생 기업과 어도비에서(어도비의 서비스 수준 보장 수치는 99.999%까지는 아니지만 필요 이상으로 높은 경향이 있음) 직접 경험해서 알고 있다. 멀티 플레이어 게임이 다운된다면 문제가 생기지 않을까? 괜찮다. 오피스 365가 몇 분, 심지어 몇시간 동안 다운되면 문제가 크지 않을까?아니, 괜찮다.   사이트 안정성 엔지니어링(Site reliability engineering) 데브옵스보다 먼저 나왔지만 조금 비슷한 면이 있는 SRE(Site reliability engineering, 맥카타이의...

모노리포 마이크로서비스 FAANG 2020.10.14

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.