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

“오픈소스를 지탱하는 힘은 클라우드 업체” AWS까지 코드 기여에 적극적

누군가는 사악한 클라우드 업체들이 연약한 오픈소스 커뮤니티에서 단물만 빨아먹고 기여는 거의 하지 않아서 오픈소스가 고사할 위기에 처했다고 말한다. 뿌리가 꽤 깊은 이 이야기에 영향을 받은 몇몇 예언가들은 오픈소스의 지속 가능성이 곧 끝을 맞이한다고 주장한다. 그러나 데이터를 통해 본 상황은 이 예언과는 전혀 다르다. 두 건의 독립적인 깃허브(GitHub) 데이터 및 CNCF 데이터 분석에 따르면 오픈소스 프로젝트의 가장 큰 기여자는 다름아닌 퍼블릭 클라우드 서비스 업체들이다. 이들 업체의 비즈니스는 소프트웨어 판매가 아닌 운용이며, 바로 그 이유로 앞으로 오랜 기간 오픈소스 파괴가 아닌 번성을 이끌 가장 적합한 위치에 있다.   나무가 아닌 숲의 오픈소스화 잘 살펴보면 꽤 오래 전부터, 특히 마이크로소프트와 구글은 가장 크고 공개적인 오픈소스 프로젝트 기여자 역할을 해왔다. 개발자에게 다가가고자 하는 지배적인 플랫폼 기업에 오픈소스는 선택이 아닌 필수다. 마이크로소프트는 애저에서 다양한 오픈소스 프로젝트의 실행을 개방하거나 지원하는 방법으로 오픈소스에 입성했고, 구글은 한걸음 더 나아가 쿠버네티스, 텐서플로우와 같은 강력한 코드를 아예 오픈소스화했다. 오픈소스에 거의 기여하지 않기로 유명했던 클라우드 선두업체인 아마존 웹 서비스도 더 이상 오픈소스 커뮤니티를 옆에서 구경만 하고 있을 수는 없는 상황이다. 사실 AWS는 사람들이 생각하는 것보다는 오픈소스 분야에서 많은 활동을 해왔지만, 2018년부터 오픈소스 참여를 대대적으로 확대했다. 620만 개의 깃허브 프로필과 각각의 기여 내역을 다룬 어도비 개발자 필 마즈의 분석을 보면 이러한 업계의 움직임이 명확하게 드러난다. 물론 이 분석은 비정밀 과학이고 아파치 프로젝트와 같은 굵직한 코드 저장소도 빠졌다. 그러나 GitHub.com 사용자-기업 관계에 대한 마즈의 분석은 많은 신호를 담고 있으며, 그 신호는 “클라우드가 오픈소스를 이끌고 있다”는 사실을 보여준다. 아래 표...

커뮤니티 저장소 코드기여 2019.02.27

깃허브 대 비트버킷 대 깃랩: 개발자의 마음을 사기 위한 치열한 경쟁

오늘날의 소프트웨어 개발은 너무 복잡해져서 만들어야 할 소프트웨어를 이해하고 제작하는 데 도움이 되는 소프트웨어를 만들어야 할 판이다. 코드가 코드를 낳고, 그 코드가 또 다른 코드를 낳는다 깃(Git)이라는 이름의 코드 리포지토리가 소프트웨어를 관리하기 위한 툴로 각광받고 있지만, 이것으로도 충분하지는 않다. 대부분의 프로그래머와 이들이 속한 팀은 다양한 부가적인 분석 및 프레젠테이션 계층을 더해 광활한 늪지와 같은 코드를 헤쳐 나갈 수 있게 해주는 온라인 버전의 깃을 애용한다. 정규식과 익명 함수, 재귀적 트리 워킹 등을 쌓아 두기 위한 최적의 장소는 깃허브(GitHub), 비트버킷(Bitbucket), 깃랩(GitLab) 세 곳인데, 이 세 플랫폼이 소스를 보관할 최적의 장소를 두고 경쟁 중이다. 셋 중 어느 것이 가장 좋을까? 팀에서는 어느 것을 사용하는 편이 가장 유리할까? 셋을 비교해 보고 어느 것이 가장 뛰어난지 확인해 보자. 깃허브가 가장 크다 깃 리포지토리 호스팅에 전문화된 최초의 대규모 웹사이트. 오픈소스 커뮤니티에서의 긍정적인 활동, 이유가 무엇이든 순수한 코드 양을 기준으로 보면 깃허브가 가장 크다. 깃허브에 따르면 사용자 수는 2,800만 명, 리포지토리는 8,500만 개에 이른다. 비트버킷 사용자는 600만 명이고 깃랩은 무슨 이유에선지 사용자 수를 묻는 질문에 답을 하지 않았다. 규모를 중시하는 사람도 있다. 여러 프로젝트 사이를 자주 오가는 오픈소스 개발자들은 한 번 로그인해서 모든 작업을 연결할 수 있다. 고양이를 좋아하는 사람들이 유튜브에서 인기 고양이 비디오 제작자들을 팔로우하듯이, 깃허브에서도 인기 개발자를 팔로우할 수 있다. 인터넷을 지배하는 네트워크 효과가 깃허브에서도 제대로 힘을 발휘하고 있다. 반면 규모를 그다지 중시하지 않는 사람도 있다. 많은 개발자가 공개 코드는 기꺼이 연결하더라도 클라이언트를 위한 작업은 연결하고 싶어하지 않는다. 그 코드를 별도로, 비공개로 보관해야 한...

소스코드 깃허브 Git 2018.07.11

새단장한 깃허브, 의존성 관리와 보안 경보 강화

인기 코드 공유 사이트 깃허브가 개발자들이 의존성을 관리하고 보안을 개선하는 데 유용한 새로운 서비스를 추가했다. 깃허브 의존성 그래프 서비스(GitHub dependency graph service)를 이용하면 개발자들이 사용하고 있는 코드가 의존하고 있는 프로젝트는 물론 자신의 코드에 의존하고 있는 프로젝트에 대한 인사이트를 얻을 수 있다. 깃허브는 자체 데이터를 사용해 의존성 그래프를 생성한다. 의존성 그래프를 통해 개발자는 어떤 애플리케이션이나 패키지와 연결되어 있는지 리포지토리를 벗어나지 않고도 확인할 수 있다. 그래프는 현재 자바스크립트와 루비 코드를 지원하며, 추후 파이썬도 지원할 예정이다. 의존성 그래프그는 의존성이 명시된 파일이 있으면, 패키지 관리자를 이용해 의존도를 파악한다. 장기적으로 깃허브는 의존성이 분명하지 않은 프로젝트에 대해서도 의존성 그래프 서비스를 제공할 계획이다. 하지만 깃허브는 이런 의존성을 파악하기 위해 각 프로젝트가 의존성을 명시한 파일 형식을 사용할 것을 권장한다. 그래프는 또한 보안이나 라이선스, 운영 위험 등의 추가 정보도 주석으로 표시할 예정이다. 의존성 그래프 서비스는 Github.com의 공개 및 비공개 리포지토리 모두에서 이용할 수 있다. 기업용 유료 서비스인 깃허브 엔터프라이즈용으로는 2018년 초에 제공될 예정이다. 또 하나 주목할 만한 서비스는 깃허브 보안 경보 서비스(Github Security Alerts Service)로, 깃허브가 준비하고 있는 보안 기능들 중 첫 번째이다. 보안 경보는 공개된 보안 취약점과의 의존성을 추적하는 그래프와 연동되며, 이런 연결을 기반으로 보안 경보를 제공한다. 깃허브는 조만간 공개 및 비공개 리포지토리에서 보안 경보 서비스를 제공할 것이라고 밝혔다. 깃허브 엔터프라이즈용 서비스는 마찬가지로 2018년 초에 제공될 예정이다. 한편, 깃허브는 이외에도 관심있는 오픈소스 프로젝트를 좀 더 쉽게 찾을 수 있는 디스커버리 리포지토리 ...

경보 깃허브 의존성 2017.10.13

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

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

Copyright © 2022 International Data Group. All rights reserved.