계정 및 한도 설정

Tier: Free, Premium, Ultimate
Offering: Self-managed

기본 프로젝트 한도

새 사용자가 개인 네임스페이스에서 생성할 수 있는 기본 최대 프로젝트 수를 구성할 수 있습니다. 이 한도는 설정을 변경한 후에 생성된 새로운 사용자 계정에만 영향을 미칩니다. 이 설정은 기존 사용자에게는 소급 적용되지 않지만, 기존 사용자의 프로젝트 한도를 별도로 편집할 수 있습니다.

새 사용자의 개인 네임스페이스에서 최대 프로젝트 수를 구성하려면:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 한도를 확장합니다.
  4. 기본 프로젝트 한도 값을 증가시키거나 감소시킵니다.

기본 프로젝트 한도를 0으로 설정하면 사용자는 개인 네임스페이스에서 프로젝트를 생성할 수 없습니다. 그러나 그룹 내에서 여전히 프로젝트를 생성할 수 있습니다.

사용자별 프로젝트 한도

특정 사용자를 편집하여 이 사용자가 개인 네임스페이스에서 생성할 수 있는 최대 프로젝트 수를 변경할 수 있습니다:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 개요 > 사용자를 선택합니다.
  3. 사용자 목록에서 사용자를 선택합니다.
  4. 편집을 선택합니다.
  5. 프로젝트 한도 값을 증가시키거나 감소시킵니다.

최대 첨부 파일 크기

  • GitLab 15.7에서 10 MB에서 100 MB로 변경됨.

GitLab 댓글 및 회신의 첨부 파일에 대한 최대 파일 크기는 100 MB입니다. 최대 첨부 파일 크기를 변경하려면:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 한도를 확장합니다.
  4. 최대 첨부 파일 크기 (MiB)에서 값을 변경하여 증가시키거나 감소시킵니다.

웹 서버에 대해 구성된 값보다 큰 크기를 선택하면 오류가 발생할 수 있습니다. 자세한 내용은 문제 해결 섹션을 참조하세요.

GitLab.com 저장소 크기 한도에 대한 내용은 계정 및 한도 설정을 참조하세요.

최대 푸시 크기

인스턴스의 최대 푸시 크기를 변경할 수 있습니다:

  1. 왼쪽 사이드바에서 하단의 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 계정 및 한도를 확장합니다.
  4. 최대 푸시 크기 (MiB)에서 값을 변경하여 증가시키거나 감소시킵니다.

GitLab.com 푸시 크기 한도에 대한 내용은 계정 및 한도 설정을 참조하세요.

노트:
웹 UI를 통해 리포지토리에 파일을 추가할 때, 최대 첨부 파일 크기가 제한 요소입니다.
왜냐하면 웹 서버가 GitLab이 커밋을 생성할 수 있도록 파일을 수신해야 하기 때문입니다.
대용량 파일을 리포지토리에 추가하려면 Git LFS를 사용하세요. 이 설정은 Git LFS 객체를 푸시할 때는 적용되지 않습니다.

개인 액세스 토큰 접두사

개인 액세스 토큰을 위한 접두사를 지정할 수 있습니다. 접두사를 사용하여 토큰을 더 빠르게 찾거나 자동화 도구와 함께 사용할 수 있습니다.

기본 접두사는 glpat-이지만 관리자는 이를 변경할 수 있습니다.

프로젝트 액세스 토큰그룹 액세스 토큰도 이 접두사를 상속받습니다.

접두사 설정

기본 전역 접두사를 변경하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Personal access token prefix 필드에 값을 입력합니다.
  5. Save changes를 선택합니다.

접두사는 settings API를 사용하여 구성할 수도 있습니다.

저장소 크기 제한

Tier: Premium, Ultimate
Offering: Self-managed

GitLab 인스턴스의 저장소는 빠르게 커질 수 있습니다. 특히 LFS를 사용하는 경우 더욱 그렇습니다. 저장소의 크기는 기하급수적으로 증가하여 가용 스토리지를 빠르게 소모할 수 있습니다. 이를 방지하기 위해 저장소 크기에 대한 하드 제한을 설정할 수 있습니다. 이 제한은 전역, 그룹별 또는 프로젝트별로 설정할 수 있으며, 프로젝트별 제한이 가장 높은 우선 순위를 가집니다.

저장소 크기에 대한 제한을 설정하려는 다양한 사용 사례가 존재합니다. 예를 들어 다음의 워크플로를 고려해 보세요:

  1. 팀에서 대형 파일을 저장해야 하는 애플리케이션을 개발합니다.
  2. 프로젝트에 Git LFS를 활성화했지만 스토리지가 크게 증가했습니다.
  3. 가용 스토리지를 초과하기 전에 각 저장소에 대해 10GB의 제한을 설정합니다.
note
GitLab.com의 저장소 크기 제한에 대한 내용은 계정 및 제한 설정을 참조하세요.

작동 방식

오직 GitLab 관리자만이 이러한 제한을 설정할 수 있습니다. 제한을 0으로 설정하면 제한이 없습니다.

이 설정은 다음에서 찾을 수 있습니다:

  • 각 프로젝트의 설정:
    1. 프로젝트의 홈 페이지에서 Settings > General로 이동합니다.
    2. Naming, topics, avatar 섹션의 Repository size limit (MiB) 필드에 값을 입력합니다.
    3. Save changes를 선택합니다.
  • 각 그룹의 설정:
    1. 그룹의 홈 페이지에서 Settings > General로 이동합니다.
    2. Naming, visibility 섹션의 Repository size limit (MiB) 필드에 값을 입력합니다.
    3. Save changes를 선택합니다.
  • GitLab 전역 설정:
    1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
    2. Settings > General을 선택합니다.
    3. Account and limit 섹션을 확장합니다.
    4. Size limit per repository (MiB) 필드에 값을 입력합니다.
    5. Save changes를 선택합니다.

LFS 객체를 포함한 새 프로젝트의 첫 푸시가 크기를 확인합니다.

저장소 크기 한도를 초과하면 푸시가 거부됩니다.

note
저장소 크기 제한은 저장소 파일 및 LFS를 포함하지만, 아티팩트, 업로드, 위키, 패키지 또는 스니펫은 포함하지 않습니다. 저장소 크기 제한은 비공식 및 공개 프로젝트 모두에 적용됩니다.

수동으로 파일을 정리하는 방법에 대한 세부정보는 Git을 사용하여 저장소 크기 줄이기를 참조하세요.

세션 지속 시간

기본 세션 지속 시간 사용자 정의

사용자가 활동 없이 얼마나 오래 로그인 상태를 유지할 수 있는지를 변경할 수 있습니다.

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다. 설정된 기간은 Session duration (minutes)에 있습니다.

    caution
    Session duration (minutes)0으로 설정하면 GitLab 인스턴스가 손상됩니다.
    자세한 내용은 issue 19469를 참조하세요.

Remember me가 활성화되면 사용자의 세션은 무기한 활성 상태를 유지할 수 있습니다.

자세한 내용은 로그인에 사용되는 쿠키를 참조하세요.

Remember me 기능 켜기 또는 끄기

사용자는 로그인 시 Remember me 체크박스를 선택할 수 있으며, 해당 브라우저에서 접근할 경우 세션은 무기한 활성 상태로 유지됩니다. 보안 또는 규정 준수를 위해 세션이 만료되기를 원한다면 이 설정을 끌 수 있습니다. 이 설정을 끄면 사용자의 세션은 세션 지속 시간을 사용자 정의할 때 설정한 비활성 시간(minute) 후에 만료됩니다.

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Remember me 체크박스를 선택하거나 선택 해제하여 이 설정을 켜거나 끕니다.

2FA가 활성화된 경우 Git 작업에 대한 세션 지속 시간 사용자 정의

Tier: Premium, Ultimate
Offering: Self-managed

자체 관리되는 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용 가능하게 하려면 관리자가 two_factor_for_cli라는 이름의 기능 플래그활성화해야 합니다. GitLab.com과 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 생산 환경에서 사용할 준비가 되어 있지 않습니다. 이 기능 플래그는 SSH를 통한 Git 작업에 대한 2FA에도 영향을 미칩니다.

GitLab 관리자는 2FA가 활성화된 경우 Git 작업에 대한 세션 지속 시간(분)을 사용자 정의할 수 있습니다. 기본 값은 15이며, 1에서 10080 사이의 값으로 설정할 수 있습니다.

이 세션이 유효한 시간을 제한하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. 2FA가 활성화된 경우 Git 작업에 대한 세션 지속 시간(분) 필드를 입력합니다.
  5. Save changes를 선택합니다.

새로운 액세스 토큰의 만료 날짜 요구

Tier: Free, Premium, Ultimate
Offering: GitLab.com, Self-managed, GitLab Dedicated

전제 조건:

  • 관리자여야 합니다.

모든 새로운 액세스 토큰에 만료 날짜가 있어야 합니다.
이 설정은 기본적으로 켜져 있으며 다음에 적용됩니다:

  • 프로젝트 액세스 토큰.
  • 그룹 액세스 토큰.
  • 비서비스 계정 사용자의 개인 액세스 토큰.

서비스 계정에 대한 개인 액세스 토큰의 경우 Application Settings API에서 service_access_tokens_expiration_enforced 설정을 사용합니다.

새로운 액세스 토큰에 대한 만료 날짜를 요구하려면:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Personal / Project / Group access token expiration 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

새로운 액세스 토큰에 대한 만료 날짜를 요구할 경우:

  • 사용자는 새 액세스 토큰의 허용된 수명보다 초과하지 않는 만료 날짜를 설정해야 합니다.
  • 액세스 토큰의 최대 수명을 제어하려면 액세스 토큰의 수명 제한 설정을 사용합니다.

최상위 그룹 소유자가 서비스 계정을 생성할 수 있도록 허용

Tier: Premium, Ultimate
Offering: Self-managed
  • 도입됨 GitLab 17.5에서 allow_top_level_group_owners_to_create_service_accounts라는 기능 플래그와 함께 제공됩니다. 기본적으로 비활성화되어 있습니다.

GitLab Self-managed에서 기본적으로 이 기능은 사용할 수 없습니다. 이를 활성화하기 위해 관리자는 allow_top_level_group_owners_to_create_service_accounts라는 기능 플래그를 활성화할 수 있습니다. GitLab.com에서는 이 기능이 사용 가능합니다.

기본적으로 GitLab Self-managed에서는 최상위 그룹 소유자가 서비스 계정을 생성할 수 없습니다. GitLab 관리자는 최상위 그룹 소유자가 서비스 계정을 생성할 수 있도록 허용할 수 있습니다.

  1. 왼쪽 사이드바 하단에서 Admin를 선택합니다.
  2. Settings > General을 선택합니다.
  3. 계정 및 한도를 확장합니다.
  4. 서비스 계정 생성 아래에서 최상위 그룹 소유자가 서비스 계정을 생성하도록 허용 체크박스를 선택합니다.
  5. 변경 사항 저장을 선택합니다.

SSH 키의 수명을 제한하기

Tier: Ultimate
Offering: Self-managed

사용자는 선택적으로 SSH 키에 대한 수명을 지정할 수 있습니다.
이 수명은 필수가 아니며, 임의의 일 수로 설정할 수 있습니다.

SSH 키는 GitLab에 액세스하기 위한 사용자 자격 증명입니다.
그러나 보안 요건이 있는 조직은 이러한 키의 주기적 교체를 요구하여 더 많은 보호를 시행하고자 할 수 있습니다.

수명 설정

오직 GitLab 관리자만 수명을 설정할 수 있습니다. 비워두면 제한이 없습니다.

SSH 키가 유효한 기간을 설정하려면:

  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. 계정 및 한도 섹션을 확장합니다.
  4. SSH 키에 대한 최대 허용 수명(일) 필드를 입력합니다.
  5. 변경 사항 저장을 선택합니다.

SSH 키에 대한 수명이 설정되면 GitLab은:

  • 사용자가 새 SSH 키에 대해 허용된 수명보다 늦지 않은 만료 날짜를 설정하도록 요구합니다.
  • 기존 SSH 키에 수명 제한을 적용합니다. 만료가 없거나 최대 수명보다 긴 키는 즉시 무효가 됩니다.
note
사용자의 SSH 키가 무효가 되면 동일한 키를 삭제하고 다시 추가할 수 있습니다.

액세스 토큰의 수명을 제한하기

Tier: Ultimate
Offering: Self-managed

사용자는 개인, 그룹, 및 프로젝트 액세스 토큰에 대해 최대 수명을 선택적으로 지정할 수 있습니다.
이 수명은 필수가 아니며 0보다 크고 365일 이하의 값으로 설정할 수 있습니다. 이 설정이 비워질 경우 액세스 토큰의 기본 허용 수명은 365일입니다.

액세스 토큰은 GitLab에 대한 프로그래밍적 액세스에 필요한 유일한 토큰입니다.
그러나 보안 요건이 있는 조직은 이러한 토큰의 주기적 교체를 요구하여 더 많은 보호를 시행하고자 할 수 있습니다.

수명 설정

오직 GitLab 관리자만 수명을 설정할 수 있습니다. 비워두면 제한이 없습니다.

액세스 토큰이 유효한 기간을 설정하려면:

  1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. 계정 및 한도 섹션을 확장합니다.
  4. 액세스 토큰에 대한 최대 허용 수명(일) 필드를 입력합니다.
  5. 변경 사항 저장을 선택합니다.

액세스 토큰에 대한 수명이 설정되면 GitLab은:

  • 새로운 개인 액세스 토큰에 수명을 적용하고 사용자가 허용된 수명보다 늦지 않은 만료 날짜를 설정하도록 요구합니다.
  • 만료 날짜가 없거나 허용된 수명보다 긴 이전 토큰은 3시간 후에 취소됩니다. 3시간은 관리자가 허용된 수명을 변경하거나 제거할 수 있도록 제공됩니다.

사용자 OAuth 애플리케이션 설정

Tier: Free, Premium, Ultimate
Offering: Self-managed

선행 조건:

관리자여야 합니다.

User OAuth 애플리케이션 설정은 사용자가 GitLab을 OAuth 제공자로 사용하기 위해 애플리케이션을 등록할 수 있는지 여부를 제어합니다. 이 설정은 사용자 소유의 OAuth 애플리케이션에 영향을 미치지만 그룹 수준의 OAuth 애플리케이션에는 영향을 미치지 않습니다.

User OAuth 애플리케이션 설정을 켜거나 끄려면:

  1. 왼쪽 사이드바 아래에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. User OAuth applications 체크박스를 선택하거나 선택 해제합니다.
  5. Save changes를 선택합니다.

사용자 프로필 이름 변경 방지

Tier: Premium, Ultimate
Offering: Self-managed

감사 이벤트에서 사용자 세부 정보의 무결성을 유지하기 위해, GitLab 관리자는 사용자가 프로필 이름을 변경할 수 있는 기능을 비활성화할 수 있습니다.

이를 수행하려면:

  1. 왼쪽 사이드바 아래에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Prevent users from changing their profile name 체크박스를 선택합니다.
note
이 기능이 비활성화되면, GitLab 관리자는 여전히 Admin 영역 또는 API를 사용하여 사용자 이름을 업데이트할 수 있습니다.

사용자가 조직을 생성하는 것을 방지

Status: Experiment
  • 도입됨 GitLab 16.7에서 ui_for_organizations라는 플래그와 함께. 기본적으로 비활성화됨.

자가 관리형 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 관리자는 ui_for_organizations라는 기능 플래그를 활성화하여 이 기능을 사용할 수 있게 할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 생산 사용 준비가 완료되지 않았습니다.

기본적으로 사용자는 조직을 생성할 수 있습니다. GitLab 관리자는 사용자가 조직을 생성하지 못하도록 할 수 있습니다.

  1. 왼쪽 사이드바 아래에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Allow users to create organizations 체크박스를 선택 해제합니다.

새로운 사용자가 최상위 그룹을 생성하는 것을 방지

기본적으로 새로운 사용자는 최상위 그룹을 생성할 수 있습니다. GitLab 관리자는 새로운 사용자가 최상위 그룹을 생성하지 못하도록 할 수 있습니다:

  • GitLab 15.5 및 이후 버전에서 다음 방법 중 하나를 사용하여:
  • GitLab 15.4 및 이전 버전에서는 구성 파일을 사용합니다.
  1. 왼쪽 사이드바 아래에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Allow new users to create top-level groups 체크박스를 선택 해제합니다.

비회원이 프로젝트 및 그룹을 생성하는 것을 방지

기본적으로 게스트 역할을 가진 사용자는 프로젝트 및 그룹을 생성할 수 있습니다. GitLab 관리자는 이 행동을 방지할 수 있습니다:

  1. 왼쪽 사이드바 아래에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Allow users with up to Guest role to create groups and personal projects 체크박스를 선택 해제합니다.
  5. Save changes를 선택합니다.

사용자가 프로필을 비공개로 설정할 수 있도록 허용

Tier: Premium, Ultimate
Offering: Self-managed

Status: Experiment

이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다.
자세한 내용은 이력을 참조하세요.
이 기능은 테스트용으로 제공되지만, 실제 사용 준비가 되어 있지 않습니다.

기본적으로 사용자는 자신의 프로필을 비공개로 설정할 수 있습니다.
GitLab 관리자는 사용자가 프로필을 비공개로 설정하지 못하도록 이 설정을 비활성화할 수 있습니다:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Allow users to make their profiles private 체크박스를 해제합니다.
  5. Save changes를 선택합니다.
note
이 설정이 비활성화되면, Set profiles of new users to private by default도 비활성화됩니다.
caution
이 설정이 비활성화되면 기존 비공식 프로필이 공개로 표시되지 않습니다.
GitLab 관리자는 모든 기존 비공식 프로필을 수동으로 공개로 업데이트해야 합니다.
자세한 내용은 issue 461701을 참조하세요.

새로운 사용자의 프로필을 기본적으로 비공개로 설정

기본적으로 새로 생성된 사용자는 공개 프로필을 갖습니다.
GitLab 관리자는 새 사용자가 기본적으로 비공식 프로필을 갖도록 설정할 수 있습니다:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Make new users’ profiles private by default 체크박스를 선택합니다.
  5. Save changes를 선택합니다.
note
Allow users to make their profiles private가 비활성화된 경우 이 설정도 비활성화됩니다.

사용자가 자신의 계정을 삭제하지 못하도록 방지

Tier: Premium, Ultimate
Offering: Self-managed

기본적으로 사용자는 자신의 계정을 삭제할 수 있습니다.
GitLab 관리자는 사용자가 자신의 계정을 삭제하지 못하도록 할 수 있습니다:

  1. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Account and limit을 확장합니다.
  4. Allows users to delete their own accounts 체크박스를 해제합니다.

문제 해결

413 Request Entity Too Large

GitLab에서 댓글이나 답글에 파일을 첨부할 때 413 Request Entity Too Large 오류가 표시되면,
최대 첨부 파일 크기가 웹 서버에서 허용된 값보다 클 수 있습니다.

Linux 패키지 설치에서 최대 첨부 파일 크기를 200MB로 늘리려면,
최대 첨부 파일 크기를 늘리기 전에 아래의 줄을 /etc/gitlab/gitlab.rb에 추가해야 할 수 있습니다:

nginx['client_max_body_size'] = "200m"

이 저장소는 크기 한도를 초과했습니다

Rails 예외 로그에서 다음과 같은 간헐적인 푸시 오류를 수신하는 경우:

Your push has been rejected, because this repository has exceeded its size limit.

주기적 유지보수 작업이 저장소 크기가 증가하는 원인이 될 수 있습니다.

이 문제를 해결하기 위해 단기에서 중기적으로 도움이 되는 옵션은 다음과 같습니다: