GitLab CE

GitLab CE는 Git 저장소를 기반으로 한 소스 코드 관리 기능을 제공한다. 이를 통해 개발자는 버전 관리 시스템을 활용하여 코드 변경 이력을 추적하고, 여러 브랜치에서 병렬 작업을 수행하며, 병합 요청을 통해 코드 변경 사항을 통합할 수 있다. 저장소는 웹 기반 인터페이스를 통해 접근 및 관리되며, 코드 탐색, 커밋 히스토리 조회, 파일 비교 등의 작업을 손쉽게 수행할 수 있다.

기본적으로 분산 버전 관리 시스템인 Git의 모든 기능을 지원하며, 이를 웹에서 직관적으로 운영할 수 있는 환경을 구축한다. 사용자는 마스터 브랜치를 포함한 다양한 브랜치를 생성하고 관리할 수 있으며, 태그를 이용해 릴리스 포인트를 표시하는 것도 가능하다. 포크 기능을 통해 프로젝트를 복사하여 독립적으로 개발을 진행한 후, 원본 프로젝트에 변경 사항을 제안하는 워크플로우도 표준적으로 지원된다.

저장소는 공개, 내부, 비공개로 설정할 수 있어 프로젝트의 접근 권한을 세밀하게 제어할 수 있다. 또한 웹훅을 설정하여 저장소에 특정 이벤트(예: 푸시, 병합 요청 생성)가 발생했을 때 외부 서비스로 알림을 전송하는 자동화도 구성할 수 있다. 이는 지속적 통합 서버나 협업 도구와의 연동에 유용하게 사용된다.

이러한 소스 코드 관리 기능은 GitLab CE의 다른 핵심 모듈인 이슈 트래킹, 코드 리뷰, CI/CD 파이프라인과 긴밀하게 연동되어 있다. 예를 들어, 병합 요청은 관련 이슈와 연결되고, 자동으로 지속적 통합 작업을 트리거하여 코드 품질을 검증하는 일관된 개발 생태계를 형성한다.

GitLab CE는 프로젝트 관리의 핵심 도구로서 통합된 이슈 트래킹 시스템을 제공한다. 이 시스템은 소프트웨어 개발 과정에서 발생하는 버그, 기능 요청, 작업 항목, 질문 등을 체계적으로 관리할 수 있도록 설계되었다. 각 이슈는 제목, 설명, 담당자, 마일스톤, 라벨, 우선순위 등을 포함한 상세한 정보를 담고 있으며, Git 저장소의 특정 커밋이나 머지 리퀘스트와 직접 연결될 수 있다. 이를 통해 코드 변경과 관련된 논의나 작업 내역을 쉽게 추적할 수 있다.

이슈 트래킹 기능은 애자일 및 스크럼과 같은 협업 방식을 지원하기 위해 다양한 기능을 포함한다. 사용자는 이슈 보드를 통해 칸반 보드 스타일로 작업의 진행 상태를 시각적으로 관리할 수 있으며, 마일스톤을 설정하여 프로젝트의 주요 목표와 일정을 계획하고 추적할 수 있다. 또한, 라벨을 활용해 이슈를 카테고리, 우선순위, 상태 등에 따라 분류하고 필터링할 수 있어 대규모 프로젝트에서도 효율적인 관리가 가능하다.

이슈는 팀 내 협업의 중심이 된다. 담당자를 지정하고, 댓글을 통해 토론을 진행하며, 체크리스트를 관리할 수 있다. 특히, 머지 리퀘스트를 생성할 때 관련 이슈를 닫도록 설정하면, 코드가 메인 브랜치에 병합되는 동시에 해당 작업이 완료된 것으로 자동 표시되어 개발 워크플로우의 연속성을 보장한다. 이 모든 기능이 GitLab의 단일 플랫폼 내에 통합되어 있어, 툴 간 전환 없이 원활한 협업이 가능하다.

GitLab CE는 내장된 지속적 통합 및 지속적 배포 기능을 제공하여 개발자가 코드 변경 사항을 자동으로 빌드, 테스트, 배포할 수 있도록 지원한다. 이 기능은 .gitlab-ci.yml 파일을 통해 파이프라인을 정의하여 구성하며, 파이프라인은 여러 단계로 구성된 작업을 실행한다. 이를 통해 소프트웨어 개발 팀은 코드 품질을 유지하고 배포 과정을 자동화할 수 있다.

파이프라인은 일반적으로 빌드, 테스트, 배포 등의 단계로 구성되며, 각 단계는 하나 이상의 작업으로 실행된다. 이러한 작업은 GitLab Runner라는 에이전트에 의해 실행되며, Docker 컨테이너나 가상 머신, 심지어 셸 환경에서도 동작할 수 있다. 사용자는 YAML 문법을 사용해 파이프라인을 정의함으로써 자동화된 워크플로를 쉽게 구축할 수 있다.

주요 CI/CD 기능으로는 병렬 작업 실행, 아티팩트 관리, 환경 변수 보안 관리, 그리고 캐싱을 통한 빌드 시간 단축 등이 포함된다. 또한, 머지 리퀘스트와의 통합을 통해 코드가 메인 브랜치에 병합되기 전에 자동으로 테스트를 수행할 수 있어, 코드 품질을 사전에 보장하는 데 기여한다.

GitLab CE의 CI/CD는 자체 호스팅 환경에서 완전히 통제된 배포 파이프라인을 운영하고자 하는 팀에게 적합하다. 이를 통해 개발부터 운영까지의 전체 생명주기를 단일 플랫폼 내에서 관리할 수 있으며, 오픈 소스 프로젝트나 중소 규모의 조직에서 비용 부담 없이 강력한 자동화 도구를 활용할 수 있다.

GitLab CE는 코드 리뷰를 위한 포괄적인 도구를 제공하여 개발 팀이 코드 품질을 유지하고 지식을 공유하며 협업을 촉진할 수 있도록 지원한다. 병합 요청은 코드 리뷰의 핵심적인 장소로, 기능 브랜치의 변경 사항을 메인 브랜치에 병합하기 전에 논의와 검토가 이루어진다. 리뷰어는 코드 라인에 직접 코멘트를 남기거나, 특정 코드 라인을 인용하여 토론을 시작할 수 있으며, 이러한 모든 논의는 병합 요청 내에 기록되어 투명한 의사 결정 과정을 보장한다.

코드 리뷰 과정을 체계화하기 위해 승인 규칙을 설정할 수 있다. 프로젝트 관리자는 특정 수의 승인이 필요하거나, 특정 사용자나 그룹의 승인을 필수로 요구하는 규칙을 정의할 수 있다. 이는 중요한 변경 사항이 적절한 검토를 거치도록 강제하는 데 유용하다. 또한, 코드 소유자 기능을 활성화하면 특정 파일이나 디렉토리 경로의 변경 사항에 대해 지정된 소유자나 팀의 자동적인 리뷰를 요청할 수 있어 코드베이스의 책임 영역을 명확히 하는 데 도움이 된다.

리뷰 효율성을 높이기 위한 여러 보조 기능도 제공된다. 병합 요청 위젯은 CI/CD 파이프라인의 실행 상태, 코드 커버리지 변화, 정적 분석 결과 등을 한눈에 보여주어 리뷰어가 코드 변경의 전반적인 영향을 평가하는 데 도움을 준다. 드래프트 모드를 사용하면 병합 요청이 아직 검토 준비가 되지 않았음을 표시하여 실수로 머지되는 것을 방지할 수 있다. 이러한 기능들은 팀이 표준화된 워크플로우를 통해 체계적이고 효과적인 코드 리뷰 문화를 구축하도록 돕는다.

GitLab CE는 프로젝트 문서화를 위한 내장 위키 시스템을 제공한다. 각 프로젝트는 별도의 위키 공간을 가지며, 마크다운 문법을 지원하여 쉽게 문서를 작성하고 관리할 수 있다. 이를 통해 개발팀은 요구사항, 아키텍처 설계, API 문서, 설치 가이드 등을 프로젝트 내에서 직접 관리할 수 있어, 지식 관리와 정보 공유가 용이해진다.

위키 페이지는 Git 저장소에 파일로 저장되므로, 다른 소스 코드와 마찬가지로 버전 관리와 변경 이력 추적이 가능하다. 사용자는 커밋 기록을 통해 문서의 변경 사항을 확인하고, 필요 시 이전 버전으로 되돌릴 수 있다. 또한 병합 요청을 통해 위키 내용에 대한 코드 리뷰와 협업 프로세스를 적용할 수 있어, 문서의 품질을 보장하는 데 도움이 된다.

GitLab의 위키 기능은 정적 사이트 생성기와의 통합도 지원한다. 프로젝트 저장소에 문서 소스 코드를 저장하고, CI/CD 파이프라인을 구성하여 변경사항이 커밋될 때마다 자동으로 문서 사이트를 빌드하고 배포할 수 있다. 이는 공식 프로젝트 문서 사이트나 API 문서를 호스팅하는 데 효과적인 방법이다.

GitLab Runner는 GitLab CI/CD 파이프라인에서 작업을 실행하는 핵심 구성 요소이다. GitLab 서버 자체는 파이프라인을 정의하고 스케줄링하지만, 실제로 코드를 빌드, 테스트, 배포하는 작업은 GitLab Runner가 담당한다. 이는 별도의 에이전트로, GitLab 인스턴스에 등록되어 파이프라인 작업을 수신하고 실행 환경을 제공한다.

Runner는 다양한 환경에서 작업을 실행할 수 있도록 설계되었다. 가장 일반적인 형태는 셸 익스큐터를 사용하여 애플리케이션이 설치된 동일한 서버나 가상 머신에서 직접 명령어를 실행하는 것이다. 또한 Docker 익스큐터를 통해 컨테이너 내에서 작업을 실행하거나, Kubernetes 클러스터, SSH를 통한 원격 서버, 심지어 Windows 환경에서도 실행될 수 있다. 이러한 유연성 덕분에 개발팀은 프로젝트 요구사항에 가장 적합한 환경을 선택할 수 있다.

GitLab Runner는 공유 Runner와 특정 Runner로 구분된다. 공유 Runner는 GitLab 인스턴스의 모든 프로젝트에서 사용할 수 있도록 설정되며, 일반적으로 관리자가 인프라를 관리한다. 반면 특정 Runner는 특정 프로젝트나 그룹에만 할당되어, 해당 프로젝트의 요구사항에 맞춰 특수한 환경이나 보안 설정을 제공한다. 이는 민감한 프로젝트나 특수한 도구가 필요한 경우 유용하다.

Runner의 구성은 config.toml 파일을 통해 관리되며, 여기서 동시 실행 작업 수, 실행자 유형, Docker 이미지, 캐시 설정 등을 정의할 수 있다. GitLab Runner는 오픈 소스 프로젝트로, Go 언어로 작성되었으며 자체적인 활발한 개발 커뮤니티를 보유하고 있다. 효과적인 CI/CD 파이프라인 구축을 위해서는 Runner의 아키텍처와 설정 옵션을 이해하는 것이 중요하다.

GitLab Container Registry는 GitLab CE에 통합된 도커 이미지 저장소이다. 이 기능을 통해 사용자는 별도의 외부 레지스트리 서비스를 구성하지 않고도 GitLab 프로젝트 내에서 도커 이미지를 빌드, 저장, 관리할 수 있다. 각 GitLab 프로젝트는 자체적인 컨테이너 레지스트리 공간을 가지며, CI/CD 파이프라인에서 생성된 이미지를 직접 푸시하거나 풀할 수 있어 개발 및 배포 워크플로우를 단순화한다.

레지스트리는 프로젝트의 패키지 영역에 위치하며, 사용자는 docker login 명령어로 GitLab 인스턴스에 인증한 후 이미지를 푸시할 수 있다. 이미지 태그는 프로젝트의 Git 커밋, 브랜치, 또는 CI 파이프라인 작업과 연결하여 관리할 수 있어 버전 추적이 용이하다. 또한 프로젝트의 접근 제어 설정을 그대로 상속받아, 레포지토리 접근 권한을 세밀하게 관리할 수 있다.

GitLab Container Registry는 자체 호스팅 환경에서 운영되므로, 기업 내부 네트워크에 이미지를 안전하게 보관할 수 있고, 외부 네트워크 트래픽과 비용을 절감할 수 있다. 레지스트리 청정 정책을 설정하여 사용하지 않는 오래된 이미지를 자동으로 삭제함으로써 저장소 공간을 효율적으로 관리할 수 있는 기능도 제공한다. 이는 지속적 통합과 지속적 배포 프로세스에서 필수적인 컨테이너 오케스트레이션 요소를 완성하는 데 기여한다.

GitLab CE는 소프트웨어 개발 라이프사이클에 필요한 다양한 패키지 레지스트리를 내장하고 있다. 이를 통해 개발 팀은 소스 코드와 함께 의존성 패키지를 같은 플랫폼 내에서 중앙 집중식으로 관리할 수 있다. 주요 패키지 레지스트리로는 NPM 레지스트리, Maven 레지스트리, PyPI, NuGet, 컨테이너 레지스트리 등이 포함되어, 프론트엔드부터 백엔드까지 다양한 기술 스택의 패키지를 지원한다.

이러한 통합된 패키지 관리 기능은 지속적 통합 및 지속적 배포 파이프라인의 효율성을 크게 높인다. 개발자는 GitLab CI/CD 파이프라인에서 직접 패키지를 빌드하고, 테스트한 후, 프로젝트의 레지스트리에 게시할 수 있다. 다른 프로젝트나 파이프라인은 이 레지스트리에서 최신 버전의 패키지를 안정적으로 가져와 사용함으로써, 의존성 관리와 빌드 자동화가 원활하게 이루어진다.

패키지 레지스트리는 프로젝트 또는 그룹 단위로 구성되며, 세분화된 접근 제어를 통해 보안을 유지한다. 이를 통해 내부적으로 개발된 라이브러리나 컴포넌트를 외부에 공개하지 않고도 팀 내에서 안전하게 공유하고 재사용할 수 있다. 이는 DevOps 문화의 핵심 요소인 협업과 자동화를 실현하는 데 기여한다.

GitLab CE를 자체 호스팅 방식으로 설치하기 위해서는 최소한의 시스템 요구사항을 충족해야 한다. 요구사항은 사용자 수, 프로젝트 규모, CI/CD 사용 여부 등에 따라 크게 달라진다.

소규모 인스턴스의 경우, 권장 최소 사양은 4코어 CPU와 4GB의 메모리(RAM)이다. 이 경우 약 500명의 사용자와 기본적인 CI 파이프라인 실행을 지원할 수 있다. 중간 규모 이상의 팀이나 활발한 CI/CD 사용을 위해서는 8코어 CPU와 8GB 이상의 메모리를 확보하는 것이 좋다. GitLab은 루비 온 레일즈와 PostgreSQL 데이터베이스, Redis 캐시 서버를 기반으로 구동되므로, 특히 메모리와 디스크 I/O 성능이 중요하다.

디스크 공간은 저장할 Git 저장소의 크기와 수, CI/CD 파이프라인에서 생성되는 아티팩트, 컨테이너 레지스트리에 저장된 이미지 등에 따라 결정된다. 빠른 디스크 성능을 위해 SSD를 사용하는 것이 권장된다. 운영 체제는 우분투, 데비안, CentOS 등의 주요 리눅스 배포판이 공식적으로 지원된다.

GitLab CE는 자체 호스팅 방식으로 배포되며, 사용 환경과 선호도에 따라 다양한 설치 방법을 제공한다. 가장 일반적인 방법은 공식 패키지인 Omnibus 설치, 컨테이너 기반의 Docker 설치, 그리고 소스 코드를 직접 컴파일하는 소스 설치가 있다.

Omnibus 패키지는 가장 권장되는 설치 방식으로, GitLab과 그에 필요한 모든 의존성(PostgreSQL, Redis, Nginx 등)을 하나의 패키지로 묶어 제공한다. 이 방식은 설치와 업그레이드가 간편하며, 통합된 구성 파일을 통해 시스템 관리를 용이하게 한다. 사용자는 공식 저장소를 자신의 리눅스 배포판에 추가한 후 패키지 관리자를 이용해 설치할 수 있다.

Docker를 이용한 설치 방법은 컨테이너 환경에서 GitLab을 빠르게 구동하고자 할 때 적합하다. 공식 GitLab Docker 이미지를 사용하면 몇 가지 명령어만으로 서비스를 시작할 수 있으며, Docker Compose를 활용하면 데이터베이스와 같은 관련 서비스도 함께 구성하기 편리하다. 이 방식은 호스트 시스템에 미치는 영향을 최소화하고, 테스트나 개발 환경 구축에 특히 유용하다.

소스 코드를 통한 설치는 가장 유연한 방법이지만, 복잡도가 높다. 사용자는 Ruby, Go, Node.js 등 필요한 모든 런타임과 라이브러리를 직접 설치하고, GitLab의 각 구성 요소를 수동으로 설정해야 한다. 이 방법은 패키지나 Docker가 지원하지 않는 특정 플랫폼에 설치하거나, 시스템을 최대한 세밀하게 제어해야 하는 경우에 고려된다.

GitLab CE는 프로젝트와 그룹 수준에서 세분화된 사용자 및 권한 관리를 제공한다. 사용자는 개인 계정으로 시스템에 가입하며, 관리자는 사용자를 생성하거나 LDAP와 같은 외부 인증 시스템을 연동할 수 있다. 각 사용자는 프로젝트와 그룹 내에서 역할에 따라 다른 권한을 부여받는다.

권한 체계는 역할 기반 접근 제어(RBAC)를 따른다. 주요 역할로는 소유자, 관리자, 유지보수자, 개발자, 보고자, 손님 등이 있다. 예를 들어, 소유자는 그룹이나 프로젝트의 모든 설정을 변경할 수 있고, 개발자는 코드를 푸시하고 머지 리퀘스트를 생성할 수 있으며, 손님은 읽기 권한만 가진다. 이러한 역할은 그룹 전체에 적용되거나 개별 프로젝트에 할당될 수 있다.

사용자 관리는 웹 기반 관리자 영역에서 수행된다. 관리자는 사용자 계정을 활성화 또는 비활성화하고, 이메일 주소를 확인하며, 이중 인증을 강제할 수 있다. 또한 그룹을 생성하여 여러 프로젝트를 논리적으로 묶고, 그룹 단위로 사용자 권한을 일괄 관리하는 것이 가능하다. 이를 통해 대규모 조직에서의 권한 관리를 효율적으로 할 수 있다.

권한은 상속 구조를 가진다. 그룹에 속한 모든 프로젝트는 기본적으로 그룹의 멤버십과 권한 설정을 상속받는다. 필요에 따라 개별 프로젝트 수준에서 상속된 권한을 재정의할 수도 있어 유연한 접근 제어가 가능하다. 또한 보호된 브랜치와 보호된 태그 기능을 통해 특정 브랜치에 대한 푸시 또는 머지 권한을 특정 역할의 사용자로만 제한할 수 있다.

GitLab CE는 자체 호스팅 환경에서 데이터의 안전성을 보장하기 위해 백업 및 복구 기능을 제공한다. 백업은 애플리케이션 데이터, 저장소 데이터, 첨부 파일, 데이터베이스, 구성 파일 등을 포함한 시스템의 전체 상태를 보존하는 과정이다. 관리자는 gitlab-backup create 명령어를 통해 수동으로 백업을 생성하거나, 크론 작업을 설정하여 정기적인 자동 백업을 구성할 수 있다. 백업 파일은 기본적으로 /var/opt/gitlab/backups 디렉토리에 저장된다.

복구 작업은 백업 파일을 사용하여 GitLab 인스턴스를 이전 상태로 되돌리는 과정이다. 복구를 수행하기 전에는 반드시 GitLab 서비스를 중지해야 하며, gitlab-backup restore 명령어를 실행한다. 이 명령어는 백업 파일에서 데이터베이스, 저장소, 업로드 파일 등을 순차적으로 복원한다. 중요한 점은 백업 파일과 복구를 수행할 GitLab의 메이저 버전이 일치해야 한다는 것이다. 버전 불일치는 복구 실패로 이어질 수 있다.

효율적인 백업 전략을 위해서는 백업 파일의 보관 주기와 저장 위치를 관리해야 한다. 백업 파일은 암호화되어 있지 않으므로, 중요한 데이터를 포함할 수 있어 안전한 오프사이트 스토리지에 보관하는 것이 권장된다. 또한, 백업 프로세스의 정상 작동을 확인하기 위해 주기적으로 복구 테스트를 수행하는 것이 좋다. GitLab의 공식 문서는 백업 스크립트 작성, 증분 백업 구성, 대용량 인스턴스의 백업 최적화 등 고급 관리 방법에 대한 가이드를 제공한다.

GitLab CE는 시스템의 상태와 애플리케이션 동작을 추적하기 위한 기본적인 모니터링 및 로깅 도구를 제공한다. 이를 통해 관리자는 서버의 성능 문제를 진단하고, 애플리케이션의 오류를 식별하며, 시스템의 전반적인 건강 상태를 유지할 수 있다.

기본적인 모니터링은 내장된 Prometheus 익스포터를 통해 이루어진다. 이 익스포터는 GitLab CE 자체의 다양한 메트릭을 수집하여 제공한다. 수집되는 데이터에는 HTTP 요청 처리 시간, 데이터베이스 연결 풀 상태, 백그라운드 작업 큐의 길이 등이 포함된다. 관리자는 이 메트릭을 Prometheus 서버에 스크랩하여 시각화하고 알림을 설정할 수 있다.

로깅 시스템은 GitLab CE의 다양한 구성 요소에서 생성되는 로그 파일을 관리한다. 주요 로그 파일로는 애플리케이션 로그, 사이드키q 작업 로그, Git 접근 로그 등이 있다. 이 로그들은 기본적으로 서버의 파일 시스템에 저장되며, 로그 레벨을 조정하여 기록되는 정보의 상세도를 제어할 수 있다. 로그는 시스템 문제 해결, 보안 감사, 사용자 활동 추적에 활용된다.

고급 모니터링 및 중앙 집중식 로그 관리 기능은 GitLab EE에 포함되어 있다. GitLab CE에서는 외부 모니터링 도구나 ELK 스택과 같은 별도의 로그 수집 시스템을 연동하여 모니터링 범위를 확장할 수 있다.