InfoGrab DocsInfoGrab Docs

계정 및 제한 설정

요약

GitLab 관리자는 인스턴스에 다음과 같은 프로젝트 및 계정 제한을 구성할 수 있습니다. 새 사용자가 개인 네임스페이스에서 만들 수 있는 최대 프로젝트 수의 기본값을 구성할 수 있습니다. 새 사용자의 개인 네임스페이스에서 최대 프로젝트 수를 구성하려면:

GitLab 관리자는 인스턴스에 다음과 같은 프로젝트 및 계정 제한을 구성할 수 있습니다.

  • 사용자가 만들 수 있는 프로젝트 수.
  • 첨부 파일, 푸시, 리포지터리의 크기 제한.
  • 세션 기간 및 만료.
  • 만료와 접두사 같은 액세스 토큰 설정.
  • 사용자 개인 정보 및 삭제 설정.
  • 조직 및 최상위 그룹의 생성 규칙.

기본 프로젝트 제한#

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

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Default projects limit 값을 늘리거나 줄입니다.

Default projects limit를 0으로 설정하면 사용자는 개인 네임스페이스에서 프로젝트를 만들 수 없습니다. 다만 그룹에서는 계속 프로젝트를 만들 수 있습니다.

사용자의 프로젝트 제한#

특정 사용자를 편집해 그 사용자가 개인 네임스페이스에서 만들 수 있는 최대 프로젝트 수를 변경할 수 있습니다.

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Users를 선택합니다.
  3. 사용자 목록에서 사용자를 선택합니다.
  4. Edit를 선택합니다.
  5. Projects limit 값을 늘리거나 줄입니다.

최대 첨부 파일 크기#

GitLab 댓글과 답글에 첨부하는 파일의 최대 크기는 100 MB입니다. GitLab UI를 통해 리포지터리에 업로드하는 파일에도 이 제한이 적용됩니다. 최대 첨부 파일 크기를 변경하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Maximum attachment size (MiB) 값을 변경해 늘리거나 줄입니다.

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

GitLab.com의 리포지터리 크기 제한은 계정 및 제한 설정을 참고합니다.

최대 푸시 크기#

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Maximum push size (MiB) 값을 변경해 늘리거나 줄입니다.

GitLab.com의 푸시 크기 제한은 계정 및 제한 설정을 참고합니다.

Note

웹 UI를 통해 리포지터리에 파일을 추가할 때는 최대 첨부 파일 크기가 제한 요인입니다. GitLab이 커밋을 생성하려면 웹 서버가 먼저 파일을 받아야 하기 때문입니다. 리포지터리에 큰 파일을 추가할 때는 Git LFS를 사용합니다. 이 설정은 Git LFS 오브젝트를 푸시할 때는 적용되지 않습니다.

리포지터리 크기 제한#

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

리포지터리 크기 제한은 비공개 프로젝트와 공개 프로젝트 모두에 적용됩니다. 여기에는 리포지터리 파일과 Git LFS 오브젝트(외부 오브젝트 스토리지에 저장된 경우에도 포함)가 포함되지만, 다음은 포함되지 않습니다.

  • 아티팩트
  • 컨테이너
  • 패키지
  • 스니펫
  • 업로드
  • 위키

리포지터리 크기에 제한을 두는 사용 사례는 많습니다. 예를 들어 다음 워크플로를 생각해 봅니다.

  1. 팀이 애플리케이션 리포지터리에 큰 파일을 저장해야 하는 앱을 개발합니다.
  2. 프로젝트에 Git LFS를 활성화했는데도 스토리지가 크게 늘어났습니다.
  3. 사용 가능한 스토리지를 초과하기 전에 리포지터리당 10 GB의 제한을 설정합니다.

GitLab Self-Managed와 GitLab Dedicated에서는 GitLab 관리자만 이러한 제한을 설정할 수 있습니다. 제한을 0으로 설정하면 제약이 없습니다. GitLab.com의 리포지터리 크기 제한은 계정 및 제한 설정을 참고합니다.

이 설정은 다음 위치에 있습니다.

  • 각 프로젝트의 설정:
    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 오브젝트를 포함해 새 프로젝트의 첫 푸시는 크기를 검사합니다. 크기의 합이 허용된 최대 리포지터리 크기를 초과하면 푸시가 거부됩니다.

리포지터리 크기 확인#

프로젝트가 구성된 리포지터리 크기 제한에 가까워졌는지 확인하려면:

  1. 스토리지 사용량을 확인합니다. Repository 크기에는 Git 리포지터리 파일과 Git LFS 오브젝트가 모두 포함됩니다.
  2. 현재 사용량을 구성된 리포지터리 크기 제한과 비교해 남은 용량을 추정합니다.

Projects API를 사용해 리포지터리 통계를 조회할 수도 있습니다.

리포지터리 크기를 줄이려면 리포지터리 크기를 줄이는 방법을 참고합니다.

세션 기간#

기본 세션 기간 사용자 정의#

사용자가 활동 없이 로그인 상태를 유지할 수 있는 기간을 변경할 수 있습니다.

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Session duration (minutes) 필드를 입력합니다.

    [!warning] **Session duration (minutes)**를 0으로 설정하면 GitLab 인스턴스가 손상됩니다. 자세한 내용은 이슈 19469를 참고합니다.

  5. Save changes를 선택합니다.
  6. 변경 사항을 적용하려면 GitLab을 재시작합니다.

    [!note] GitLab Dedicated에서는 인스턴스 재시작을 요청하는 지원 티켓을 제출합니다.

Remember me 옵션이 활성화되어 있으면 사용자 세션이 무기한 활성 상태로 유지될 수 있습니다.

자세한 내용은 로그인에 사용되는 쿠키를 참고합니다.

생성 날짜로부터 만료되는 세션 설정#

히스토리
  • GitLab 18.0에서 session_expire_from_init이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • GitLab 18.3에서 일반 공개되었습니다. 기능 플래그 session_expire_from_init이 제거되었습니다.

기본적으로 세션은 비활성 상태가 된 뒤 정해진 시간이 지나면 만료됩니다. 대신 세션이 생성된 뒤 정해진 시간이 지나면 만료되도록 구성할 수 있습니다.

세션 기간에 도달하면 다음과 같은 경우에도 세션이 종료되고 사용자가 로그아웃됩니다.

  • 사용자가 여전히 세션을 활발히 사용하고 있는 경우.
  • 사용자가 로그인할 때 Remember me를 선택한 경우.
  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Expire session from creation date 체크박스를 선택합니다.

세션이 종료되면 창이 표시되어 사용자에게 다시 로그인하도록 안내합니다.

Remember me 옵션 구성#

사용자는 로그인할 때 Remember me 체크박스를 선택할 수 있습니다. 그러면 해당 브라우저에서 접속하는 동안 세션이 무기한 활성 상태로 유지됩니다. 보안이나 컴플라이언스 목적으로 세션을 만료시키려면 이 설정을 끕니다. 이 설정을 끄면 세션 기간을 사용자 정의할 때 설정한 비활성 시간(분)이 지난 뒤 사용자 세션이 만료됩니다.

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

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

히스토리
Feature flag

이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

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

이러한 세션의 유효 기간에 제한을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Session duration for Git operations when 2FA is enabled (minutes) 필드를 입력합니다.
  5. Save changes를 선택합니다.

최상위 그룹 Owner가 서비스 계정을 만들 수 있도록 허용#

히스토리
  • GitLab Self-Managed용으로 GitLab 17.5에서 allow_top_level_group_owners_to_create_service_accounts라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.6에서 일반 공개되었습니다. 기능 플래그 allow_top_level_group_owners_to_create_service_accounts가 제거되었습니다.

기본적으로 관리자만 서비스 계정을 만들 수 있습니다. 최상위 그룹 Owner도 서비스 계정을 만들 수 있도록 GitLab을 구성할 수 있습니다.

사전 요구 사항:

  • 관리자 액세스 권한이 있어야 합니다.

최상위 그룹 Owner가 서비스 계정을 만들 수 있도록 허용하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Service account creation 아래에서 Allow top-level group owners to create Service accounts 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

새 액세스 토큰의 만료일 요구#

히스토리
  • GitLab 17.3에서 도입되었습니다.

사전 요구 사항:

  • 관리자여야 합니다.

모든 새 액세스 토큰에 만료일을 두도록 요구할 수 있습니다. 이 설정은 기본적으로 켜져 있으며 다음에 적용됩니다.

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

서비스 계정의 개인 액세스 토큰에는 애플리케이션 설정 API의 service_access_tokens_expiration_enforced 설정을 사용합니다.

새 액세스 토큰에 만료일을 요구하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Require expiration date 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

새 액세스 토큰에 만료일을 요구하면 다음과 같습니다.

  • 사용자는 새 액세스 토큰에 허용된 수명을 초과하지 않는 만료일을 설정해야 합니다.
  • 액세스 토큰의 최대 수명을 제어하려면 Limit the lifetime of access tokens 설정을 사용합니다.

비활성 프로젝트 및 그룹 액세스 토큰 보존 기간#

기본적으로 GitLab은 토큰 패밀리의 마지막 활성 토큰이 비활성 상태가 되고 30일이 지나면 그룹 및 프로젝트 액세스 토큰과 그 토큰 패밀리를 삭제합니다. 이 삭제로 토큰 패밀리의 모든 토큰과 연결된 봇 사용자가 제거되고, 봇의 기여 내역은 고스트 사용자로 이동합니다.

사전 요구 사항:

  • 관리자 액세스 권한.

비활성 토큰의 보존 기간을 수정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Inactive project and group access token retention period 텍스트 상자에서 보존 기간을 수정합니다.
    • 숫자를 지정하면 모든 그룹 및 프로젝트 액세스 토큰은 지정한 일수 동안 비활성 상태가 지속된 뒤 삭제됩니다.
    • 필드를 비워 두면 비활성 토큰은 삭제되지 않습니다.
  5. Save changes를 선택합니다.

애플리케이션 설정 API로 inactive_resource_access_tokens_delete_after_days 속성을 수정할 수도 있습니다.

개인 액세스 토큰 접두사#

개인 액세스 토큰에 접두사를 지정할 수 있습니다. 사용자 지정 접두사를 사용하면 다음과 같은 이점이 있습니다.

  • 토큰이 구별되고 식별하기 쉽습니다.
  • 유출된 토큰을 보안 스캔 중에 더 쉽게 식별할 수 있습니다.
  • 서로 다른 인스턴스 사이에서 토큰을 혼동할 위험이 줄어듭니다.

개인 액세스 토큰의 기본 접두사는 glpat-이지만 관리자가 변경할 수 있습니다. 프로젝트 액세스 토큰과 그룹 액세스 토큰도 이 접두사를 상속합니다.

Warning

기본적으로 클라이언트 측 시크릿 탐지, 시크릿 푸시 보호, 파이프라인 시크릿 탐지는 사용자 지정 접두사를 가진 토큰을 탐지하지 않습니다. 이로 인해 거짓 음성이 늘어날 수 있습니다. 다만 파이프라인 시크릿 탐지를 사용자 지정해 이러한 토큰을 탐지하도록 할 수 있습니다.

접두사 설정#

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

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

설정 API를 사용해 접두사를 구성할 수도 있습니다.

인스턴스 토큰 접두사#

히스토리
  • GitLab 17.10에서 custom_prefix_for_all_token_types라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로는 사용할 수 있지만 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

인스턴스에서 생성되는 모든 토큰 앞에 붙는 사용자 지정 접두사를 설정할 수 있습니다. 사용자 지정 접두사를 사용하면 다음과 같은 이점이 있습니다.

  • 토큰이 구별되고 식별하기 쉽습니다.
  • 유출된 토큰을 보안 스캔 중에 더 쉽게 식별할 수 있습니다.
  • 서로 다른 인스턴스 사이에서 토큰을 혼동할 위험이 줄어듭니다.
Warning

기본적으로 클라이언트 측 시크릿 탐지, 시크릿 푸시 보호, 파이프라인 시크릿 탐지는 사용자 지정 접두사를 가진 토큰을 탐지하지 않습니다. 이로 인해 거짓 음성이 늘어날 수 있습니다. 다만 파이프라인 시크릿 탐지를 사용자 지정해 이러한 토큰을 탐지하도록 할 수 있습니다.

사용자 지정 토큰 접두사는 다음 토큰에만 적용됩니다.

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

사용자 지정 토큰 접두사를 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Instance token prefix 필드에 사용자 지정 접두사를 입력합니다.
  5. Save changes를 선택합니다.

gl은 예약된 접두사입니다. GitLab이 기본 인스턴스 토큰 접두사를 gl에서 접두사 없음으로 변경하기 전에 애플리케이션 설정을 저장한 인스턴스에는 여전히 gl이 값으로 저장되어 있습니다. 이제 GitLab은 저장된 gl 값을 접두사 없음과 동일하게 취급하므로, 인스턴스 토큰 접두사를 gl로 설정할 수 없습니다.

액세스 토큰 수명 제한#

히스토리
  • GitLab 17.6에서 buffered_token_expiration_limit이라는 기능 플래그와 함께 최대 허용 수명 제한을 400일로 늘리도록 변경되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

확장된 최대 허용 수명 제한의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능 플래그는 GitLab Dedicated에서 사용할 수 없습니다.

사용자는 액세스 토큰의 최대 수명을 일 단위로 지정할 수 있습니다. 여기에는 개인, 그룹, 프로젝트 액세스 토큰이 포함됩니다. 이 수명은 필수가 아니며, 0보다 크고 다음 값 이하인 값으로 설정할 수 있습니다.

  • 기본적으로 365일.
  • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.

이 설정을 비워 두면 액세스 토큰의 기본 허용 수명은 다음과 같습니다.

  • 기본적으로 365일.
  • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.

액세스 토큰은 GitLab에 프로그래밍 방식으로 접근할 때 필요한 유일한 토큰입니다. 다만 보안 요구 사항이 있는 조직은 이러한 토큰을 정기적으로 교체하도록 요구해 더 강한 보호를 적용하고 싶을 수 있습니다.

수명 설정#

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

액세스 토큰의 유효 기간에 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Maximum allowable lifetime for access tokens (days) 필드를 입력합니다.
  5. Save changes를 선택합니다.

액세스 토큰의 수명을 설정하면 GitLab은 다음과 같이 동작합니다.

  • 새 개인 액세스 토큰에 수명을 적용하고, 사용자에게 만료일을 설정하도록 요구하며 허용된 수명보다 늦지 않은 날짜를 요구합니다.
  • 3시간이 지나면 만료일이 없거나 허용된 수명보다 긴 수명을 가진 기존 토큰을 취소합니다. 취소가 일어나기 전에 관리자가 허용 수명을 변경하거나 제거할 수 있도록 3시간이 주어집니다.

SSH 키 수명 제한#

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

SSH 키는 GitLab에 접근하기 위한 사용자 자격 증명입니다. 다만 보안 요구 사항이 있는 조직은 이러한 키를 정기적으로 교체하도록 요구해 더 강한 보호를 적용하고 싶을 수 있습니다.

수명 설정#

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

SSH 키의 유효 기간에 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Maximum allowable lifetime for SSH keys (days) 필드를 입력합니다.
  5. Save changes를 선택합니다.

SSH 키의 수명을 설정하면 GitLab은 다음과 같이 동작합니다.

  • 새 SSH 키에 허용된 수명보다 늦지 않은 만료일을 설정하도록 사용자에게 요구합니다. 최대 허용 수명은 다음과 같습니다.
    • 기본적으로 365일.
    • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.
  • 기존 SSH 키에도 수명 제한을 적용합니다. 만료일이 없거나 최대치보다 긴 수명을 가진 키는 즉시 무효가 됩니다.
Note

사용자의 SSH 키가 무효가 되면 같은 키를 삭제하고 다시 추가할 수 있습니다.

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

사전 요구 사항:

  • 관리자여야 합니다.

User OAuth applications 설정은 사용자가 GitLab을 OAuth 공급자로 사용하도록 애플리케이션을 등록할 수 있는지를 제어합니다. 이 설정은 사용자가 소유한 OAuth 애플리케이션에 적용되지만, 그룹이 소유한 OAuth 애플리케이션에는 적용되지 않습니다.

User OAuth applications 설정을 켜거나 끄려면:

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

OAuth 액세스 토큰 수명 제한#

히스토리
  • GitLab 19.1에서 도입되었습니다.

기본적으로 OAuth 액세스 토큰은 2시간(7200초) 뒤에 만료됩니다. 인스턴스 관리자는 OAuth 액세스 토큰의 수명을 사용자 지정해 구성할 수 있습니다.

최솟값은 300초(5분)입니다. 설정하지 않으면 기본값인 7200초(2시간)가 적용됩니다. 이 설정은 인스턴스가 발급하는 모든 새 OAuth 액세스 토큰에 적용됩니다.

사전 요구 사항:

  • 관리자여야 합니다.

OAuth 액세스 토큰의 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. OAuth access token lifetime (seconds) 필드를 입력합니다.
  5. Save changes를 선택합니다.

이 설정은 애플리케이션 설정 API의 oauth_access_token_expires_in 속성을 사용해 구성할 수도 있습니다.

OAuth 동적 클라이언트 등록 끄기#

히스토리
  • GitLab 19.3에서 도입되었습니다.

MCP 클라이언트나 AI 도구 같은 OAuth 클라이언트는 OAuth 동적 클라이언트 등록(DCR)을 사용해 POST /oauth/register로 요청을 보내 애플리케이션을 자동으로 등록합니다. 기본적으로 DCR은 활성화되어 있습니다.

DCR을 끄면 OAuth 클라이언트에 다음과 같은 결과가 적용됩니다.

  • OAuth 클라이언트는 애플리케이션을 자동으로 등록할 수 없습니다. 대신 클라이언트는 미리 등록된 OAuth 애플리케이션을 사용해야 합니다.
  • GitLab은 동적으로 등록된 OAuth 애플리케이션을 삭제하고 그 액세스 토큰과 권한 부여를 취소합니다.

사전 요구 사항:

  • 관리자여야 합니다.

OAuth 동적 클라이언트 등록을 끄려면 애플리케이션 설정 API를 사용해 dynamic_client_registration_enabled 속성을 false로 설정합니다.

사용자 프로필 이름 변경 비활성화#

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

그렇게 하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Prevent users from changing their profile name을 선택합니다.

이 설정을 선택해도 GitLab 관리자는 Admin 영역이나 API에서 사용자 이름을 계속 업데이트할 수 있습니다.

사용자가 조직을 만들지 못하도록 방지#

히스토리
  • GitLab 16.7에서 ui_for_organizations라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

GitLab Self-Managed에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 ui_for_organizations라는 기능 플래그를 활성화할 수 있습니다. GitLab.com과 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

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

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

새 사용자가 최상위 그룹을 만들지 못하도록 방지#

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Allow new users to create top-level groups 체크박스를 선택 해제합니다.
Note

이 설정은 설정을 끈 뒤에 추가된 사용자에게만 적용됩니다. 기존 사용자는 계속 최상위 그룹을 만들 수 있습니다.

비멤버가 프로젝트 및 그룹을 만들지 못하도록 방지#

기본적으로 Guest 권한이 있는 사용자는 프로젝트와 그룹을 만들 수 있습니다. 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를 선택합니다.

사용자가 프로필을 비공개로 설정하지 못하도록 방지#

히스토리
  • GitLab 17.1에서 disallow_private_profiles라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.9에서 일반 공개되었습니다. 기능 플래그 disallow_private_profiles가 제거되었습니다.

기본적으로 사용자는 프로필을 비공개로 만들 수 있습니다. GitLab 관리자는 이 설정을 비활성화해 모든 사용자 프로필이 공개가 되도록 요구할 수 있습니다. 이 설정은 내부 사용자("봇"이라고도 함)에는 적용되지 않습니다.

사용자가 프로필을 비공개로 설정하지 못하도록 하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Allow users to make their profiles private 체크박스를 선택 해제합니다.
  5. Save changes를 선택합니다.

이 설정을 끄면 다음과 같이 됩니다.

이 설정을 다시 활성화하면 사용자가 이전에 설정한 프로필 공개 범위가 선택됩니다.

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

기본적으로 새로 만들어진 사용자는 공개 프로필을 가집니다. 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가 비활성화되어 있으면 이 설정도 비활성화됩니다.

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

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

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

모든 사용자의 업적 자동 수락#

히스토리
  • GitLab 19.4에서 도입되었습니다.

기본적으로 사용자는 업적이 사용자 프로필에 표시되기 전에 이를 명시적으로 수락해야 합니다. 대신 인스턴스의 모든 사용자에게 새로 부여된 업적이 자동으로 수락되도록 설정을 구성할 수 있습니다.

이 설정을 켜면 새 업적이 즉시 수락되어 수신자의 사용자 프로필에 표시됩니다. GitLab은 업적에 대한 이메일 알림을 계속 보내지만, 이메일에 수락 링크는 더 이상 포함되지 않습니다. 이 설정은 설정을 켜기 전에 부여된 업적에는 적용되지 않습니다.

수신자는 프로필에서 업적을 숨길 수 있습니다.

모든 사용자의 업적을 자동으로 수락하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Automatically accept achievements for all users 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

문제 해결#

413 Request Entity Too Large#

GitLab에서 댓글이나 답글에 파일을 첨부할 때는 최대 첨부 파일 크기가 웹 서버에서 허용하는 값보다 클 가능성이 높습니다.

Linux 패키지 설치에서 최대 첨부 파일 크기를 200 MB로 늘리려면:

  1. /etc/gitlab/gitlab.rb에 다음 줄을 추가합니다.

    nginx['client_max_body_size'] = "200m"
    
  2. 최대 첨부 파일 크기를 늘립니다.

이 리포지터리가 크기 제한을 초과했습니다#

Rails 예외 로그에 다음과 같은 푸시 오류가 간헐적으로 나타나는 경우가 있습니다.

Your push to this repository cannot be completed because this repository has exceeded the allocated storage for your project.

하우스키핑 작업 때문에 리포지터리 크기가 커지고 있을 수 있습니다. 이 문제를 해결하려면 다음 두 가지 중 하나가 단기에서 중기적으로 도움이 됩니다.

계정 및 제한 설정

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

GitLab 관리자는 인스턴스에 다음과 같은 프로젝트 및 계정 제한을 구성할 수 있습니다. 새 사용자가 개인 네임스페이스에서 만들 수 있는 최대 프로젝트 수의 기본값을 구성할 수 있습니다. 새 사용자의 개인 네임스페이스에서 최대 프로젝트 수를 구성하려면:

GitLab 관리자는 인스턴스에 다음과 같은 프로젝트 및 계정 제한을 구성할 수 있습니다.

  • 사용자가 만들 수 있는 프로젝트 수.
  • 첨부 파일, 푸시, 리포지터리의 크기 제한.
  • 세션 기간 및 만료.
  • 만료와 접두사 같은 액세스 토큰 설정.
  • 사용자 개인 정보 및 삭제 설정.
  • 조직 및 최상위 그룹의 생성 규칙.

기본 프로젝트 제한#

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

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Default projects limit 값을 늘리거나 줄입니다.

Default projects limit를 0으로 설정하면 사용자는 개인 네임스페이스에서 프로젝트를 만들 수 없습니다. 다만 그룹에서는 계속 프로젝트를 만들 수 있습니다.

사용자의 프로젝트 제한#

특정 사용자를 편집해 그 사용자가 개인 네임스페이스에서 만들 수 있는 최대 프로젝트 수를 변경할 수 있습니다.

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Users를 선택합니다.
  3. 사용자 목록에서 사용자를 선택합니다.
  4. Edit를 선택합니다.
  5. Projects limit 값을 늘리거나 줄입니다.

최대 첨부 파일 크기#

GitLab 댓글과 답글에 첨부하는 파일의 최대 크기는 100 MB입니다. GitLab UI를 통해 리포지터리에 업로드하는 파일에도 이 제한이 적용됩니다. 최대 첨부 파일 크기를 변경하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Maximum attachment size (MiB) 값을 변경해 늘리거나 줄입니다.

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

GitLab.com의 리포지터리 크기 제한은 계정 및 제한 설정을 참고합니다.

최대 푸시 크기#

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Maximum push size (MiB) 값을 변경해 늘리거나 줄입니다.

GitLab.com의 푸시 크기 제한은 계정 및 제한 설정을 참고합니다.

Note

웹 UI를 통해 리포지터리에 파일을 추가할 때는 최대 첨부 파일 크기가 제한 요인입니다. GitLab이 커밋을 생성하려면 웹 서버가 먼저 파일을 받아야 하기 때문입니다. 리포지터리에 큰 파일을 추가할 때는 Git LFS를 사용합니다. 이 설정은 Git LFS 오브젝트를 푸시할 때는 적용되지 않습니다.

리포지터리 크기 제한#

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

리포지터리 크기 제한은 비공개 프로젝트와 공개 프로젝트 모두에 적용됩니다. 여기에는 리포지터리 파일과 Git LFS 오브젝트(외부 오브젝트 스토리지에 저장된 경우에도 포함)가 포함되지만, 다음은 포함되지 않습니다.

  • 아티팩트
  • 컨테이너
  • 패키지
  • 스니펫
  • 업로드
  • 위키

리포지터리 크기에 제한을 두는 사용 사례는 많습니다. 예를 들어 다음 워크플로를 생각해 봅니다.

  1. 팀이 애플리케이션 리포지터리에 큰 파일을 저장해야 하는 앱을 개발합니다.
  2. 프로젝트에 Git LFS를 활성화했는데도 스토리지가 크게 늘어났습니다.
  3. 사용 가능한 스토리지를 초과하기 전에 리포지터리당 10 GB의 제한을 설정합니다.

GitLab Self-Managed와 GitLab Dedicated에서는 GitLab 관리자만 이러한 제한을 설정할 수 있습니다. 제한을 0으로 설정하면 제약이 없습니다. GitLab.com의 리포지터리 크기 제한은 계정 및 제한 설정을 참고합니다.

이 설정은 다음 위치에 있습니다.

  • 각 프로젝트의 설정:
    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 오브젝트를 포함해 새 프로젝트의 첫 푸시는 크기를 검사합니다. 크기의 합이 허용된 최대 리포지터리 크기를 초과하면 푸시가 거부됩니다.

리포지터리 크기 확인#

프로젝트가 구성된 리포지터리 크기 제한에 가까워졌는지 확인하려면:

  1. 스토리지 사용량을 확인합니다. Repository 크기에는 Git 리포지터리 파일과 Git LFS 오브젝트가 모두 포함됩니다.
  2. 현재 사용량을 구성된 리포지터리 크기 제한과 비교해 남은 용량을 추정합니다.

Projects API를 사용해 리포지터리 통계를 조회할 수도 있습니다.

리포지터리 크기를 줄이려면 리포지터리 크기를 줄이는 방법을 참고합니다.

세션 기간#

기본 세션 기간 사용자 정의#

사용자가 활동 없이 로그인 상태를 유지할 수 있는 기간을 변경할 수 있습니다.

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Session duration (minutes) 필드를 입력합니다.

    [!warning] **Session duration (minutes)**를 0으로 설정하면 GitLab 인스턴스가 손상됩니다. 자세한 내용은 이슈 19469를 참고합니다.

  5. Save changes를 선택합니다.
  6. 변경 사항을 적용하려면 GitLab을 재시작합니다.

    [!note] GitLab Dedicated에서는 인스턴스 재시작을 요청하는 지원 티켓을 제출합니다.

Remember me 옵션이 활성화되어 있으면 사용자 세션이 무기한 활성 상태로 유지될 수 있습니다.

자세한 내용은 로그인에 사용되는 쿠키를 참고합니다.

생성 날짜로부터 만료되는 세션 설정#

히스토리
  • GitLab 18.0에서 session_expire_from_init이라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
  • GitLab 18.3에서 일반 공개되었습니다. 기능 플래그 session_expire_from_init이 제거되었습니다.

기본적으로 세션은 비활성 상태가 된 뒤 정해진 시간이 지나면 만료됩니다. 대신 세션이 생성된 뒤 정해진 시간이 지나면 만료되도록 구성할 수 있습니다.

세션 기간에 도달하면 다음과 같은 경우에도 세션이 종료되고 사용자가 로그아웃됩니다.

  • 사용자가 여전히 세션을 활발히 사용하고 있는 경우.
  • 사용자가 로그인할 때 Remember me를 선택한 경우.
  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Expire session from creation date 체크박스를 선택합니다.

세션이 종료되면 창이 표시되어 사용자에게 다시 로그인하도록 안내합니다.

Remember me 옵션 구성#

사용자는 로그인할 때 Remember me 체크박스를 선택할 수 있습니다. 그러면 해당 브라우저에서 접속하는 동안 세션이 무기한 활성 상태로 유지됩니다. 보안이나 컴플라이언스 목적으로 세션을 만료시키려면 이 설정을 끕니다. 이 설정을 끄면 세션 기간을 사용자 정의할 때 설정한 비활성 시간(분)이 지난 뒤 사용자 세션이 만료됩니다.

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

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

히스토리
Feature flag

이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

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

이러한 세션의 유효 기간에 제한을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Session duration for Git operations when 2FA is enabled (minutes) 필드를 입력합니다.
  5. Save changes를 선택합니다.

최상위 그룹 Owner가 서비스 계정을 만들 수 있도록 허용#

히스토리
  • GitLab Self-Managed용으로 GitLab 17.5에서 allow_top_level_group_owners_to_create_service_accounts라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.6에서 일반 공개되었습니다. 기능 플래그 allow_top_level_group_owners_to_create_service_accounts가 제거되었습니다.

기본적으로 관리자만 서비스 계정을 만들 수 있습니다. 최상위 그룹 Owner도 서비스 계정을 만들 수 있도록 GitLab을 구성할 수 있습니다.

사전 요구 사항:

  • 관리자 액세스 권한이 있어야 합니다.

최상위 그룹 Owner가 서비스 계정을 만들 수 있도록 허용하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Service account creation 아래에서 Allow top-level group owners to create Service accounts 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

새 액세스 토큰의 만료일 요구#

히스토리
  • GitLab 17.3에서 도입되었습니다.

사전 요구 사항:

  • 관리자여야 합니다.

모든 새 액세스 토큰에 만료일을 두도록 요구할 수 있습니다. 이 설정은 기본적으로 켜져 있으며 다음에 적용됩니다.

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

서비스 계정의 개인 액세스 토큰에는 애플리케이션 설정 API의 service_access_tokens_expiration_enforced 설정을 사용합니다.

새 액세스 토큰에 만료일을 요구하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Require expiration date 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

새 액세스 토큰에 만료일을 요구하면 다음과 같습니다.

  • 사용자는 새 액세스 토큰에 허용된 수명을 초과하지 않는 만료일을 설정해야 합니다.
  • 액세스 토큰의 최대 수명을 제어하려면 Limit the lifetime of access tokens 설정을 사용합니다.

비활성 프로젝트 및 그룹 액세스 토큰 보존 기간#

기본적으로 GitLab은 토큰 패밀리의 마지막 활성 토큰이 비활성 상태가 되고 30일이 지나면 그룹 및 프로젝트 액세스 토큰과 그 토큰 패밀리를 삭제합니다. 이 삭제로 토큰 패밀리의 모든 토큰과 연결된 봇 사용자가 제거되고, 봇의 기여 내역은 고스트 사용자로 이동합니다.

사전 요구 사항:

  • 관리자 액세스 권한.

비활성 토큰의 보존 기간을 수정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Inactive project and group access token retention period 텍스트 상자에서 보존 기간을 수정합니다.
    • 숫자를 지정하면 모든 그룹 및 프로젝트 액세스 토큰은 지정한 일수 동안 비활성 상태가 지속된 뒤 삭제됩니다.
    • 필드를 비워 두면 비활성 토큰은 삭제되지 않습니다.
  5. Save changes를 선택합니다.

애플리케이션 설정 API로 inactive_resource_access_tokens_delete_after_days 속성을 수정할 수도 있습니다.

개인 액세스 토큰 접두사#

개인 액세스 토큰에 접두사를 지정할 수 있습니다. 사용자 지정 접두사를 사용하면 다음과 같은 이점이 있습니다.

  • 토큰이 구별되고 식별하기 쉽습니다.
  • 유출된 토큰을 보안 스캔 중에 더 쉽게 식별할 수 있습니다.
  • 서로 다른 인스턴스 사이에서 토큰을 혼동할 위험이 줄어듭니다.

개인 액세스 토큰의 기본 접두사는 glpat-이지만 관리자가 변경할 수 있습니다. 프로젝트 액세스 토큰과 그룹 액세스 토큰도 이 접두사를 상속합니다.

Warning

기본적으로 클라이언트 측 시크릿 탐지, 시크릿 푸시 보호, 파이프라인 시크릿 탐지는 사용자 지정 접두사를 가진 토큰을 탐지하지 않습니다. 이로 인해 거짓 음성이 늘어날 수 있습니다. 다만 파이프라인 시크릿 탐지를 사용자 지정해 이러한 토큰을 탐지하도록 할 수 있습니다.

접두사 설정#

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

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

설정 API를 사용해 접두사를 구성할 수도 있습니다.

인스턴스 토큰 접두사#

히스토리
  • GitLab 17.10에서 custom_prefix_for_all_token_types라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능은 테스트용으로는 사용할 수 있지만 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

인스턴스에서 생성되는 모든 토큰 앞에 붙는 사용자 지정 접두사를 설정할 수 있습니다. 사용자 지정 접두사를 사용하면 다음과 같은 이점이 있습니다.

  • 토큰이 구별되고 식별하기 쉽습니다.
  • 유출된 토큰을 보안 스캔 중에 더 쉽게 식별할 수 있습니다.
  • 서로 다른 인스턴스 사이에서 토큰을 혼동할 위험이 줄어듭니다.
Warning

기본적으로 클라이언트 측 시크릿 탐지, 시크릿 푸시 보호, 파이프라인 시크릿 탐지는 사용자 지정 접두사를 가진 토큰을 탐지하지 않습니다. 이로 인해 거짓 음성이 늘어날 수 있습니다. 다만 파이프라인 시크릿 탐지를 사용자 지정해 이러한 토큰을 탐지하도록 할 수 있습니다.

사용자 지정 토큰 접두사는 다음 토큰에만 적용됩니다.

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스 권한이 있어야 합니다.

사용자 지정 토큰 접두사를 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Instance token prefix 필드에 사용자 지정 접두사를 입력합니다.
  5. Save changes를 선택합니다.

gl은 예약된 접두사입니다. GitLab이 기본 인스턴스 토큰 접두사를 gl에서 접두사 없음으로 변경하기 전에 애플리케이션 설정을 저장한 인스턴스에는 여전히 gl이 값으로 저장되어 있습니다. 이제 GitLab은 저장된 gl 값을 접두사 없음과 동일하게 취급하므로, 인스턴스 토큰 접두사를 gl로 설정할 수 없습니다.

액세스 토큰 수명 제한#

히스토리
  • GitLab 17.6에서 buffered_token_expiration_limit이라는 기능 플래그와 함께 최대 허용 수명 제한을 400일로 늘리도록 변경되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

확장된 최대 허용 수명 제한의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. 이 기능 플래그는 GitLab Dedicated에서 사용할 수 없습니다.

사용자는 액세스 토큰의 최대 수명을 일 단위로 지정할 수 있습니다. 여기에는 개인, 그룹, 프로젝트 액세스 토큰이 포함됩니다. 이 수명은 필수가 아니며, 0보다 크고 다음 값 이하인 값으로 설정할 수 있습니다.

  • 기본적으로 365일.
  • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.

이 설정을 비워 두면 액세스 토큰의 기본 허용 수명은 다음과 같습니다.

  • 기본적으로 365일.
  • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.

액세스 토큰은 GitLab에 프로그래밍 방식으로 접근할 때 필요한 유일한 토큰입니다. 다만 보안 요구 사항이 있는 조직은 이러한 토큰을 정기적으로 교체하도록 요구해 더 강한 보호를 적용하고 싶을 수 있습니다.

수명 설정#

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

액세스 토큰의 유효 기간에 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Maximum allowable lifetime for access tokens (days) 필드를 입력합니다.
  5. Save changes를 선택합니다.

액세스 토큰의 수명을 설정하면 GitLab은 다음과 같이 동작합니다.

  • 새 개인 액세스 토큰에 수명을 적용하고, 사용자에게 만료일을 설정하도록 요구하며 허용된 수명보다 늦지 않은 날짜를 요구합니다.
  • 3시간이 지나면 만료일이 없거나 허용된 수명보다 긴 수명을 가진 기존 토큰을 취소합니다. 취소가 일어나기 전에 관리자가 허용 수명을 변경하거나 제거할 수 있도록 3시간이 주어집니다.

SSH 키 수명 제한#

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

SSH 키는 GitLab에 접근하기 위한 사용자 자격 증명입니다. 다만 보안 요구 사항이 있는 조직은 이러한 키를 정기적으로 교체하도록 요구해 더 강한 보호를 적용하고 싶을 수 있습니다.

수명 설정#

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

SSH 키의 유효 기간에 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. Maximum allowable lifetime for SSH keys (days) 필드를 입력합니다.
  5. Save changes를 선택합니다.

SSH 키의 수명을 설정하면 GitLab은 다음과 같이 동작합니다.

  • 새 SSH 키에 허용된 수명보다 늦지 않은 만료일을 설정하도록 사용자에게 요구합니다. 최대 허용 수명은 다음과 같습니다.
    • 기본적으로 365일.
    • buffered_token_expiration_limit 기능 플래그를 활성화한 경우 400일. 이 확장된 제한은 GitLab Dedicated에서 사용할 수 없습니다.
  • 기존 SSH 키에도 수명 제한을 적용합니다. 만료일이 없거나 최대치보다 긴 수명을 가진 키는 즉시 무효가 됩니다.
Note

사용자의 SSH 키가 무효가 되면 같은 키를 삭제하고 다시 추가할 수 있습니다.

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

사전 요구 사항:

  • 관리자여야 합니다.

User OAuth applications 설정은 사용자가 GitLab을 OAuth 공급자로 사용하도록 애플리케이션을 등록할 수 있는지를 제어합니다. 이 설정은 사용자가 소유한 OAuth 애플리케이션에 적용되지만, 그룹이 소유한 OAuth 애플리케이션에는 적용되지 않습니다.

User OAuth applications 설정을 켜거나 끄려면:

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

OAuth 액세스 토큰 수명 제한#

히스토리
  • GitLab 19.1에서 도입되었습니다.

기본적으로 OAuth 액세스 토큰은 2시간(7200초) 뒤에 만료됩니다. 인스턴스 관리자는 OAuth 액세스 토큰의 수명을 사용자 지정해 구성할 수 있습니다.

최솟값은 300초(5분)입니다. 설정하지 않으면 기본값인 7200초(2시간)가 적용됩니다. 이 설정은 인스턴스가 발급하는 모든 새 OAuth 액세스 토큰에 적용됩니다.

사전 요구 사항:

  • 관리자여야 합니다.

OAuth 액세스 토큰의 수명을 설정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit 섹션을 확장합니다.
  4. OAuth access token lifetime (seconds) 필드를 입력합니다.
  5. Save changes를 선택합니다.

이 설정은 애플리케이션 설정 API의 oauth_access_token_expires_in 속성을 사용해 구성할 수도 있습니다.

OAuth 동적 클라이언트 등록 끄기#

히스토리
  • GitLab 19.3에서 도입되었습니다.

MCP 클라이언트나 AI 도구 같은 OAuth 클라이언트는 OAuth 동적 클라이언트 등록(DCR)을 사용해 POST /oauth/register로 요청을 보내 애플리케이션을 자동으로 등록합니다. 기본적으로 DCR은 활성화되어 있습니다.

DCR을 끄면 OAuth 클라이언트에 다음과 같은 결과가 적용됩니다.

  • OAuth 클라이언트는 애플리케이션을 자동으로 등록할 수 없습니다. 대신 클라이언트는 미리 등록된 OAuth 애플리케이션을 사용해야 합니다.
  • GitLab은 동적으로 등록된 OAuth 애플리케이션을 삭제하고 그 액세스 토큰과 권한 부여를 취소합니다.

사전 요구 사항:

  • 관리자여야 합니다.

OAuth 동적 클라이언트 등록을 끄려면 애플리케이션 설정 API를 사용해 dynamic_client_registration_enabled 속성을 false로 설정합니다.

사용자 프로필 이름 변경 비활성화#

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

그렇게 하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Prevent users from changing their profile name을 선택합니다.

이 설정을 선택해도 GitLab 관리자는 Admin 영역이나 API에서 사용자 이름을 계속 업데이트할 수 있습니다.

사용자가 조직을 만들지 못하도록 방지#

히스토리
  • GitLab 16.7에서 ui_for_organizations라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
Feature flag

GitLab Self-Managed에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 ui_for_organizations라는 기능 플래그를 활성화할 수 있습니다. GitLab.com과 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

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

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

새 사용자가 최상위 그룹을 만들지 못하도록 방지#

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

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Allow new users to create top-level groups 체크박스를 선택 해제합니다.
Note

이 설정은 설정을 끈 뒤에 추가된 사용자에게만 적용됩니다. 기존 사용자는 계속 최상위 그룹을 만들 수 있습니다.

비멤버가 프로젝트 및 그룹을 만들지 못하도록 방지#

기본적으로 Guest 권한이 있는 사용자는 프로젝트와 그룹을 만들 수 있습니다. 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를 선택합니다.

사용자가 프로필을 비공개로 설정하지 못하도록 방지#

히스토리
  • GitLab 17.1에서 disallow_private_profiles라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • GitLab 17.9에서 일반 공개되었습니다. 기능 플래그 disallow_private_profiles가 제거되었습니다.

기본적으로 사용자는 프로필을 비공개로 만들 수 있습니다. GitLab 관리자는 이 설정을 비활성화해 모든 사용자 프로필이 공개가 되도록 요구할 수 있습니다. 이 설정은 내부 사용자("봇"이라고도 함)에는 적용되지 않습니다.

사용자가 프로필을 비공개로 설정하지 못하도록 하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Allow users to make their profiles private 체크박스를 선택 해제합니다.
  5. Save changes를 선택합니다.

이 설정을 끄면 다음과 같이 됩니다.

이 설정을 다시 활성화하면 사용자가 이전에 설정한 프로필 공개 범위가 선택됩니다.

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

기본적으로 새로 만들어진 사용자는 공개 프로필을 가집니다. 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가 비활성화되어 있으면 이 설정도 비활성화됩니다.

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

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

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

모든 사용자의 업적 자동 수락#

히스토리
  • GitLab 19.4에서 도입되었습니다.

기본적으로 사용자는 업적이 사용자 프로필에 표시되기 전에 이를 명시적으로 수락해야 합니다. 대신 인스턴스의 모든 사용자에게 새로 부여된 업적이 자동으로 수락되도록 설정을 구성할 수 있습니다.

이 설정을 켜면 새 업적이 즉시 수락되어 수신자의 사용자 프로필에 표시됩니다. GitLab은 업적에 대한 이메일 알림을 계속 보내지만, 이메일에 수락 링크는 더 이상 포함되지 않습니다. 이 설정은 설정을 켜기 전에 부여된 업적에는 적용되지 않습니다.

수신자는 프로필에서 업적을 숨길 수 있습니다.

모든 사용자의 업적을 자동으로 수락하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
  3. Account and limit를 확장합니다.
  4. Automatically accept achievements for all users 체크박스를 선택합니다.
  5. Save changes를 선택합니다.

문제 해결#

413 Request Entity Too Large#

GitLab에서 댓글이나 답글에 파일을 첨부할 때는 최대 첨부 파일 크기가 웹 서버에서 허용하는 값보다 클 가능성이 높습니다.

Linux 패키지 설치에서 최대 첨부 파일 크기를 200 MB로 늘리려면:

  1. /etc/gitlab/gitlab.rb에 다음 줄을 추가합니다.

    nginx['client_max_body_size'] = "200m"
    
  2. 최대 첨부 파일 크기를 늘립니다.

이 리포지터리가 크기 제한을 초과했습니다#

Rails 예외 로그에 다음과 같은 푸시 오류가 간헐적으로 나타나는 경우가 있습니다.

Your push to this repository cannot be completed because this repository has exceeded the allocated storage for your project.

하우스키핑 작업 때문에 리포지터리 크기가 커지고 있을 수 있습니다. 이 문제를 해결하려면 다음 두 가지 중 하나가 단기에서 중기적으로 도움이 됩니다.