회사에서 GitLab을 처음 사용하며 정리한 GitHub와의 차이

개인 프로젝트나 이전 개발 경험에서는 주로 GitHub를 사용해왔다.

그런데 이번에 회사에서 프로젝트 소스코드를 확인하기 위해 저장소를 전달받았는데, 평소에 사용하던 GitHub가 아니라 GitLab을 사용하고 있었다.

처음에는 별다른 생각 없이

GitHub랑 거의 비슷한 서비스 아닌가?

정도로 생각했다.

실제로 저장소를 Clone하고 Branch를 만들거나 Commit, Push를 하는 과정은 GitHub를 사용할 때와 다를 것이 없었다.

그런데 저장소 주소를 살펴보니 gitlab.com이 아니라 회사 내부 주소를 사용하고 있었다.

알아보니 GitLab.com을 이용하는 것이 아니라 회사 내부에 Self-Managed GitLab, 쉽게 말해 사내 GitLab Server를 구축해서 사용하고 있었다.

여기서 한 가지 궁금증이 생겼다.

GitHub와 GitLab은 정확히 무엇이 다르고, 회사에서는 왜 자체 GitLab Server를 구축해서 사용하는 걸까?

이번에 GitLab을 처음 사용하게 된 김에 두 플랫폼의 차이를 정리해봤다.

GitHub와 GitLab은 기본적으로 비슷하다

먼저 GitHub와 GitLab 모두 Git을 기반으로 소스코드를 관리하고 개발자들이 협업하기 위한 플랫폼이다.

두 플랫폼 모두 다음과 같은 기능을 제공한다.

• Git Repository 관리
• Branch 기반 개발
• 코드 리뷰
• Issue 관리
• Wiki
• 사용자 및 권한 관리
• CI/CD
• Package 및 Container Registry

따라서 Git 자체를 사용하는 방법은 동일하다.

예를 들어 GitLab에서도 평소 GitHub를 사용할 때와 똑같이 작업할 수 있다.

git clone <repository-url>

git switch -c feature/login

git add .
git commit -m "feat: 로그인 기능 추가"

git push -u origin feature/login

clone, branch, commit, push, pull, merge 같은 명령은 원격 Repository가 GitHub인지 GitLab인지와 상관없이 동일하다.

처음 GitLab을 사용하면서도 Git 명령어나 SourceTree 사용법 때문에 새로 배워야 할 것은 거의 없었다.

차이는 Git 자체보다는 Git을 둘러싼 협업과 운영 환경에 있다.

간단하게 비교하면 다음과 같다.

다만 이 표만 보고 GitHub는 개인용, GitLab은 기업용이라고 구분하면 정확하지 않다.

기업에서도 GitHub를 많이 사용하고 GitLab 역시 개인 프로젝트에 사용할 수 있다.

GitHub도 GitHub Enterprise Server를 이용한 자체 구축이 가능하며, Self-hosted Runner도 제공한다.

결국 둘의 차이는 기능의 유무보다는 어떤 방식으로 개발 환경을 구성하고 운영하느냐에 더 가깝다.

직접 써보니 PR과 MR은 거의 똑같았다

GitHub를 사용하다 GitLab으로 넘어오면서 가장 먼저 눈에 들어온 용어가 **Merge Request(MR)**였다.

GitHub에서는 보통 작업한 Branch를 main이나 develop Branch에 합칠 때 **Pull Request(PR)**를 만든다.

feature/login
      ↓
Pull Request
      ↓
Code Review
      ↓
Merge
      ↓
main

GitLab에서는 Pull Request 대신 **Merge Request(MR)**라는 용어를 사용한다.

feature/login
      ↓
Merge Request
      ↓
Code Review
      ↓
Merge
      ↓
main

처음에는 이름이 다르니 사용법에도 어느 정도 차이가 있을 것이라고 생각했다.

그런데 직접 MR을 만들어서 사용해보니 생각보다 훨씬 익숙했다.

• Source Branch 선택
• Target Branch 선택
• 변경된 코드 확인
• 제목과 설명 작성
• Reviewer 지정
• Comment 작성
• 승인
• Merge

전체적인 흐름이 GitHub의 PR과 거의 동일했다.

실제로 사용하면서 느낀 차이는 기능보다는 UI와 메뉴 배치의 차이에 가까웠다.

GitHub에서 Pull Request를 사용해본 경험이 있다면 GitLab의 Merge Request 때문에 새롭게 배워야 할 내용은 많지 않은 것 같다.

개인적인 체감으로는 처음 적응할 때

GitHub의 PR이 GitLab에서는 MR이라는 이름으로 바뀌었다

정도로 생각해도 큰 문제가 없었다.

물론 세부적으로 들어가면 GitHub의 Actions, Checks, Rulesets와 GitLab의 Pipeline, Approval Rules, Merge Train 등 각 플랫폼에 특화된 기능 차이는 존재한다.

하지만 일반적인 개발자가 Branch에서 작업하고 코드 리뷰를 거쳐 Merge하는 기본적인 협업 흐름은 상당히 비슷하다.

GitHub는 공개 협업과 오픈소스에서 익숙하다

GitHub라고 하면 가장 먼저 떠오르는 것은 역시 오픈소스다.

React, Spring Boot, Kubernetes, TensorFlow를 비롯한 수많은 오픈소스 프로젝트가 GitHub에서 관리되고 있다.

개발자는 공개 Repository에서 코드를 확인하고 Issue를 등록하거나 Pull Request를 보내 프로젝트에 직접 참여할 수도 있다.

개인 개발자 입장에서도 GitHub를 접할 일이 많다.

• 개인 프로젝트 관리
• 포트폴리오 공개
• 오픈소스 참여
• 개발 기록 관리
• 외부 개발자와 협업
• GitHub Actions를 활용한 CI/CD

특히 GitHub 프로필에 공개 Repository와 Contribution 기록이 남기 때문에 개발자의 포트폴리오 역할도 어느 정도 한다.

나 역시 그동안 GitHub를 개인 프로젝트와 개발 결과물을 관리하는 용도로 자연스럽게 사용해왔다.

GitHub Actions까지 사용하면 GitHub 안에서 테스트나 빌드, 배포 자동화도 구성할 수 있다.

Push
 ↓
GitHub Actions
 ↓
Build
 ↓
Test
 ↓
Deploy

따라서 GitHub 역시 단순한 소스코드 저장소라고 보기에는 이미 제공하는 기능이 상당히 많다.

GitLab은 DevOps 환경을 통합해서 운영하기 좋다

GitLab 역시 Git 저장소 플랫폼이지만 서비스를 살펴보면 DevOps 전체 흐름을 하나의 플랫폼에서 관리하는 것을 상당히 중요하게 다루고 있다.

하나의 GitLab Project 안에서 다음과 같은 기능을 연결할 수 있다.

• Repository
• Issue
• Merge Request
• Wiki
• CI/CD Pipeline
• CI/CD Variables
• Package Registry
• Container Registry
• Release
• Security Scan

예를 들어 다음과 같은 흐름을 GitLab 안에서 구성할 수 있다.

개발자
   ↓
Git Push
   ↓
GitLab Repository
   ↓
CI/CD Pipeline
   ↓
GitLab Runner
   ↓
Build / Test
   ↓
Docker Image
   ↓
Container Registry
   ↓
Deploy

물론 GitHub에서도 GitHub Actions와 Packages 등을 통해 비슷한 환경을 구성할 수 있다.

따라서 GitLab만 CI/CD를 지원한다거나 GitLab만 DevOps 플랫폼이라고 생각하면 안 된다.

다만 GitLab은 Repository, Merge Request, Runner, CI/CD, Registry 등의 기능을 Group과 Project 안에서 통합해서 운영하는 형태가 상당히 자연스럽게 구성되어 있다.

그리고 이번에 회사에서 사용하고 있던 것처럼 GitLab 자체를 사내 서버에 구축할 수 있다는 점도 기업 환경에서는 중요한 특징인 것 같다.

회사에서 사용하는 GitLab은 GitLab.com이 아니었다

이번에 가장 흥미로웠던 부분이다.

GitLab에는 우리가 웹에서 가입해서 사용하는 GitLab.com뿐만 아니라 회사가 서버에 직접 설치해서 운영할 수 있는 GitLab Self-Managed가 있다.

회사에서 사용하고 있는 것도 이 방식이었다.

단순화하면 이런 구조다.

회사 내부망

개발자 PC
    │
    │ Git Push
    ▼
GitLab Server
    │
    │ Pipeline
    ▼
GitLab Runner
    │
    ▼
개발 / 운영 서버

즉 소스코드를 외부 GitHub나 GitLab.com으로 보내는 것이 아니라 회사에서 관리하는 GitLab Server에 저장한다.

GitLab Server부터 Runner와 개발 서버까지 회사 내부 네트워크에서 연결하는 것도 가능하다.

여기서 왜 일부 기업이 GitLab을 자체 구축해서 사용하는지 어느 정도 이해할 수 있었다.

왜 사내 GitLab Server를 사용할까?

1. 소스코드를 회사 내부에서 관리할 수 있다

가장 먼저 생각할 수 있는 이유는 소스코드 관리와 통제다.

GitHub.com과 GitLab.com은 외부 회사가 운영하는 SaaS다.

Private Repository를 사용하더라도 결국 소스코드가 외부 서비스의 인프라에 저장된다.

반면 Self-Managed GitLab을 사용하면 GitLab 자체를 회사가 관리하는 서버에 설치할 수 있다.

외부 SaaS

개발자
 ↓
Internet
 ↓
GitHub.com / GitLab.com

대신 다음처럼 구성할 수 있다.

Self-Managed

개발자
 ↓
사내 Network
 ↓
GitLab Server

소스코드뿐 아니라 사용자 계정과 접근 정책, 백업, 네트워크 구성까지 조직 정책에 맞춰 직접 관리할 수 있다.

금융권이나 공공기관처럼 외부 서비스 사용이 제한되거나 소스코드 반출 정책이 엄격한 환경에서는 이런 구성이 특히 중요할 수 있다.

다만 자체 서버를 사용한다고 무조건 더 안전한 것은 아니다.

직접 운영하는 만큼 회사에서 다음과 같은 작업도 책임져야 한다.

• GitLab 업데이트
• 보안 패치
• 서버 관리
• 백업 및 복구
• 스토리지 관리
• 접근 권한 관리
• 장애 대응

즉 통제권이 커지는 대신 운영 책임도 커진다.

2. 내부망에서도 개발 환경을 구성할 수 있다

GitLab Server와 Runner를 내부에 구축하면 외부 인터넷 접근이 제한된 환경에서도 개발 프로세스를 구성할 수 있다.

개발자 PC
    ↓
사내 GitLab
    ↓
Merge Request
    ↓
GitLab Runner
    ↓
개발 서버

내부 네트워크만으로도 다음 작업을 수행할 수 있다.

• Clone
• Pull
• Push
• Merge Request
• Code Review
• CI/CD
• 사내 서버 배포

물론 Self-Managed GitLab을 사용한다고 해서 반드시 완전한 폐쇄망이라는 뜻은 아니다.

프로젝트에 따라 외부 Package Repository나 Docker Registry, API 등에 접근해야 할 수도 있기 때문에 일부 외부 통신을 허용할 수도 있다.

이 부분은 회사의 네트워크와 보안 정책에 따라 달라진다.

3. Group과 Subgroup을 이용한 조직 관리

GitLab에서 눈에 띄는 또 하나의 특징은 Group 구조다.

GitHub가 주로

Organization
└── Repository

형태라면 GitLab은 다음처럼 구성할 수 있다.

Group
└── Subgroup
    └── Project

예를 들어 회사 조직을 기준으로 한다면 이런 구조도 만들 수 있다.

company
├── platform
│   ├── frontend
│   │   ├── web
│   │   └── admin
│   │
│   └── backend
│       ├── api
│       └── batch
│
└── infrastructure
    ├── terraform
    └── kubernetes

Group과 Subgroup에 멤버를 등록하고 권한을 부여하면 하위 Project에서도 해당 권한을 상속하도록 구성할 수 있다.

프로젝트 몇 개만 운영할 때는 큰 차이가 없겠지만 여러 부서와 팀, 프로젝트를 관리해야 하는 조직에서는 이런 계층 구조가 유용해 보인다.

4. 프로젝트별 권한을 관리할 수 있다

GitLab에서는 Project나 Group에 참여하는 사용자에게 역할을 부여할 수 있다.

대표적으로 다음과 같은 Role이 있다.

Guest
Reporter
Developer
Maintainer
Owner

일반적인 개발 업무에서는 Developer, 프로젝트 관리나 설정 권한이 필요한 경우 Maintainer를 부여하는 식으로 사용할 수 있다.

또한 main이나 develop 같은 주요 Branch를 Protected Branch로 설정할 수도 있다.

예를 들어 일반 개발자가 main Branch에 직접 Push하지 못하게 하고 다음과 같은 절차를 강제할 수 있다.

feature/login
     ↓
Push
     ↓
Merge Request
     ↓
Code Review
     ↓
CI Pipeline
     ↓
Approval
     ↓
main Merge

이렇게 하면 실수로 주요 Branch에 코드를 직접 Push하거나 리뷰되지 않은 코드가 Merge되는 것을 어느 정도 방지할 수 있다.

물론 GitHub도 Branch Protection과 Rulesets 등을 통해 비슷한 기능을 제공한다.

이 역시 GitLab만 가능한 기능이라기보다는 기업 환경에서 GitLab이 이런 기능을 사내 계정과 Group 구조, CI/CD와 함께 통합적으로 관리하기 편리하다는 정도로 이해하면 될 것 같다.

GitLab CI/CD와 GitLab Runner

GitLab 프로젝트를 보다 보면 .gitlab-ci.yml이라는 파일을 볼 수 있다.

GitLab CI/CD의 Pipeline을 정의하는 파일이다.

예를 들어 다음처럼 작성할 수 있다.

stages:
  - build
  - test

build:
  stage: build
  script:
    - npm ci
    - npm run build

test:
  stage: test
  script:
    - npm test

코드가 Push되면 Pipeline이 실행되고 정의된 Job을 차례대로 수행한다.

그런데 이 명령을 GitLab Server 자체가 실행하는 것은 아니다.

실제로 Job을 실행하는 역할을 하는 것이 GitLab Runner다.

GitLab Server
      │
      │ Job
      ▼
GitLab Runner
      │
      ├── Build
      ├── Test
      └── Deploy

회사 서버에 Runner를 설치하면 내부 네트워크에 접근할 수 있으므로 사내 개발 서버나 Registry와 연결할 수도 있다.

예를 들어 다음과 같은 구조가 가능하다.

Developer
    ↓
Git Push
    ↓
GitLab Server
    ↓
Pipeline
    ↓
GitLab Runner
    ↓
Build / Test
    ↓
Docker Image
    ↓
사내 Registry
    ↓
개발 Server

GitHub Actions에도 Self-hosted Runner가 있으므로 Runner라는 개념 자체는 GitLab만의 것은 아니다.

하지만 회사 내부에서 GitLab Server와 Runner를 함께 운영하고 있다면 저장소부터 빌드와 배포까지 상당 부분을 내부 인프라 안에 넣을 수 있다는 점은 분명한 장점이다.

GitHub Actions와 GitLab CI/CD도 개념은 비슷하다

GitHub Actions와 GitLab CI/CD 역시 문법과 UI는 다르지만 기본적인 목적은 같다.

GitHub Actions는 보통 다음 경로에 Workflow를 작성한다.

.github/
└── workflows/
    └── deploy.yml

GitLab은 프로젝트 루트에 작성한다.

.gitlab-ci.yml

둘 다 결국 다음과 같은 흐름을 정의하는 것이다.

언제 실행할 것인가?
        ↓
어떤 환경에서 실행할 것인가?
        ↓
어떤 명령을 실행할 것인가?
        ↓
빌드와 테스트에 성공했는가?
        ↓
어디에 배포할 것인가?

GitHub Actions를 사용해본 경험이 있다면 GitLab CI/CD 역시 YAML 문법과 GitLab에서 사용하는 용어를 익히는 것이 주요 차이일 것 같다.

GitHub를 사용하다 GitLab을 접하면 무엇부터 보면 좋을까?

직접 사용해보니 GitHub 경험이 있다면 GitLab 자체에 적응하는 것보다 회사의 Git 사용 규칙을 파악하는 것이 더 중요하다는 생각이 들었다.

프로젝트를 처음 전달받으면 다음 내용을 먼저 확인해보는 것이 좋을 것 같다.

Branch 전략

main
develop
feature/*
release/*
hotfix/*

어떤 Branch에서 기능 Branch를 만들고 어느 Branch를 대상으로 MR을 생성하는지 확인해야 한다.

Branch 이름 규칙

feature/login
feature/PROJ-123-login
fix/payment-error

Issue 번호나 작업 종류를 Branch 이름에 포함하는지도 확인한다.

Commit Convention

feat: 로그인 기능 추가
fix: 결제 상태 갱신 오류 수정
refactor: 사용자 조회 로직 분리
docs: README 수정

회사에서 별도의 Commit 규칙을 사용하고 있는지도 중요하다.

Merge Request 규칙

다음 항목도 확인할 필요가 있다.

• MR 제목 규칙
• Description Template
• Reviewer
• 필수 승인 인원
• Pipeline 통과 여부
• Merge 권한
• Squash 여부

Protected Branch

main이나 develop Branch에 직접 Push가 가능한지 여부도 알아둬야 한다.

.gitlab-ci.yml

파일이 있다면 프로젝트의 전체 빌드와 배포 과정을 이해하는 데 꽤 도움이 된다.

GitLab Runner

Pipeline이 어느 Runner에서 실행되는지도 알아두면 나중에 CI/CD 오류를 분석할 때 도움이 될 것 같다.

직접 사용해본 현재까지의 느낌

이번에 GitLab을 처음 사용하면서 가장 먼저 느낀 것은 생각보다 GitHub와 크게 다르지 않다는 것이었다.

Git 명령어는 완전히 동일했고 Merge Request도 직접 사용해보니 GitHub의 Pull Request와 거의 같은 흐름이었다.

처음에는 PR과 MR이라는 용어부터 낯설었지만 막상 사용해보면

GitHub PR ≒ GitLab MR

정도로 이해해도 될 만큼 비슷했다.

오히려 차이가 크게 느껴졌던 부분은 Git을 사용하는 방법보다 GitLab을 회사 내부에 직접 구축해서 사용하고 있다는 점이었다.

개인 프로젝트에서 GitHub를 사용할 때는 보통

코드를 어디에 Push할 것인가?

정도를 생각했다면 기업에서는 그보다 훨씬 많은 부분을 고려해야 한다.

• 소스코드를 어디에 저장할 것인가?
• 누가 Repository에 접근할 수 있는가?
• 어떤 Branch에 누가 Push할 수 있는가?
• 어떤 과정을 거쳐 Merge할 것인가?
• 빌드는 어느 서버에서 실행할 것인가?
• CI/CD 환경은 내부망에 있어야 하는가?
• 개발 서버와 운영 서버는 어떻게 연결할 것인가?
• GitLab Server 자체의 백업과 장애 대응은 어떻게 할 것인가?

결국 회사 입장에서는 단순한 Git Repository 서비스 하나를 선택하는 것이 아니라 전체 개발 및 배포 인프라의 일부를 선택하는 것이라는 생각이 들었다.

마무리

처음에는 GitLab을 단순히 GitHub의 다른 버전 정도로 생각했다.

그리고 개발자 입장에서 코드를 Push하고 MR을 만들어 Merge하는 정도까지는 실제로 GitHub와 상당히 비슷했다.

특히 Pull Request와 Merge Request를 모두 사용해보니 기본적인 사용 흐름은 거의 같았고 실제 체감 차이는 UI와 용어에서 더 크게 느껴졌다.

하지만 회사에서 Self-Managed GitLab을 운영하는 이유를 찾아보면서 두 플랫폼의 차이를 단순히 PR과 MR 같은 기능 비교만으로 봐서는 안 된다는 것을 알게 됐다.

GitHub는 공개 프로젝트와 오픈소스, 개인 프로젝트, 외부 협업에서 쉽게 접할 수 있는 플랫폼이다.

GitLab은 자체 서버와 Runner를 구성해 Repository부터 CI/CD까지 조직 내부에서 통합 운영하려는 환경에서 활용하기 좋은 선택지다.

물론 GitHub 역시 GitHub Enterprise Server와 Self-hosted Runner 등을 제공하기 때문에

개인 = GitHub
기업 = GitLab

처럼 단순하게 구분할 수는 없다.

결국 프로젝트의 보안 정책, 네트워크 환경, 조직 구조, 기존 인프라와 운영 방식에 따라 적합한 플랫폼이 달라진다.

그리고 GitHub를 사용해본 개발자라면 GitLab이라고 해서 크게 겁먹을 필요도 없는 것 같다.

Git은 그대로이고

Pull Request → Merge Request
GitHub Actions → GitLab CI/CD
Organization → Group
Repository → Project

처럼 GitLab에서 사용하는 용어와 UI를 몇 가지 익히면 기본적인 개발 업무에는 어렵지 않게 적응할 수 있다.

아직 회사 GitLab의 모든 기능을 사용해본 것은 아니다.

앞으로 실제 프로젝트를 진행하면서 다음 기능들을 직접 접하게 되면 별도로 정리해볼 생각이다.

• Merge Request와 Code Review
• Protected Branch
• .gitlab-ci.yml
• GitLab Runner
• CI/CD Variables
• Container Registry
• 실제 회사 프로젝트의 CI/CD Pipeline 구조

GitLab을 처음 사용하면서 느낀 가장 큰 차이는 결국 Git 자체가 아니라 Git을 회사의 개발 인프라 안에서 어떻게 운영하고 있느냐였다.