GitLab 애플리케이션 한계

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

GitLab은 대부분의 대규모 애플리케이션과 마찬가지로 최소한의 성능 품질을 유지하기 위해 특정 기능에 한계를 적용합니다.

일부 기능이 무제한으로 허용되면 보안, 성능, 데이터에 영향을 미치거나 심지어 애플리케이션에 할당된 리소스를 소모할 수 있습니다.

인스턴스 구성

인스턴스 구성 페이지에서는 현재 GitLab 인스턴스에서 사용되는 일부 설정에 대한 정보를 찾을 수 있습니다.

구성한 한계에 따라 다음 내용을 볼 수 있습니다:

  • SSH 호스트 키 정보
  • CI/CD 한계
  • GitLab Pages 한계
  • 패키지 레지스트리 한계
  • 속도 제한
  • 크기 제한

이 페이지는 모든 사용자에게 표시되므로 인증되지 않은 사용자는 관련 정보만 볼 수 있습니다.

인스턴스 구성 페이지를 방문하려면:

  1. 왼쪽 사이드바에서 도움말 ( ) > 도움말을 선택합니다.
  2. 도움말 페이지에서 현재 인스턴스 구성 확인을 선택합니다.

직접 URL은 <gitlab_url>/help/instance_configuration입니다. GitLab.com의 경우, https://gitlab.com/help/instance_configuration를 방문할 수 있습니다.

속도 제한

속도 제한은 GitLab의 보안성과 내구성을 향상시키는 데 사용될 수 있습니다.

속도 제한 구성에 대해 자세히 읽어보세요.

이슈 생성

이 설정은 이슈 생성 엔드포인트에 대한 요청 속도를 제한합니다.

이슈 생성 속도 제한에 대해 더 알아보세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

사용자 또는 IP별

이 설정은 사용자 또는 IP별 요청 속도를 제한합니다.

사용자 및 IP 속도 제한에 대해 더 알아보세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

원시 엔드포인트별

이 설정은 엔드포인트별 요청 속도를 제한합니다.

원시 엔드포인트 속도 제한에 대해 더 알아보세요.

  • 기본 속도 제한: 프로젝트, 커밋 및 파일 경로당 300 요청입니다.

보호된 경로별

이 설정은 특정 경로에 대한 요청 속도를 제한합니다.

GitLab은 기본적으로 다음 경로에 대한 속도를 제한합니다:

'/users/password',
'/users/sign_in',
'/api/#{API::API.version}/session.json',
'/api/#{API::API.version}/session',
'/users',
'/users/confirmation',
'/unsubscribes/',
'/import/github/personal_access_token',
'/admin/session'

보호된 경로 속도 제한에 대해 더 알아보세요.

  • 기본 속도 제한: 10개의 요청 후, 클라이언트는 다시 시도하기 전에 60초를 기다려야 합니다.

패키지 레지스트리

이 설정은 패키지 API에 대한 요청 속도를 사용자 또는 IP별로 제한합니다. 자세한 내용은 패키지 레지스트리 속도 제한을 참조하세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

Git LFS

이 설정은 Git LFS에 대한 요청 속도를 사용자별로 제한합니다. 자세한 내용은 GitLab Git 대용량 파일 저장소 (LFS) 관리를 읽어보세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

파일 API

이 설정은 패키지 API에 대한 요청 속도를 사용자 또는 IP 주소별로 제한합니다. 자세한 내용은 파일 API 속도 제한을 읽어보세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

사용 중단된 API 엔드포인트

이 설정은 사용 중단된 API 엔드포인트에 대한 요청 속도를 사용자 또는 IP 주소별로 제한합니다. 자세한 내용은 사용 중단된 API 속도 제한을 읽어보세요.

  • 기본 속도 제한: 기본적으로 비활성화되어 있습니다.

가져오기/내보내기

이 설정은 그룹 및 프로젝트의 가져오기/내보내기 작업을 제한합니다.

제한 기본값 (사용자당 분당)
프로젝트 가져오기 6
프로젝트 내보내기 6
프로젝트 내보내기 다운로드 1
그룹 가져오기 6
그룹 내보내기 6
그룹 내보내기 다운로드 1

가져오기/내보내기 속도 제한에 대해 자세히 알아보기.

회원 초대

그룹 계층 구조당 허용되는 최대 일일 회원 초대를 제한합니다.

  • GitLab.com: Free 회원은 하루에 20명, Premium trial 및 Ultimate trial 회원은 하루에 50명을 초대할 수 있습니다.
  • Self-managed: 초대에 제한이 없습니다.

웹훅 속도 제한

  • 제한 변경 GitLab 15.1에서 후크당이 아닌 최상위 네임스페이스당으로 변경되었습니다.

웹훅을 호출할 수 있는 횟수를 분당, 최상위 네임스페이스당 제한합니다.

이는 프로젝트와 그룹 웹훅에만 적용됩니다.

속도 제한을 초과하는 호출은 auth.log에 기록됩니다.

Self-managed 설치의 경우, 다음을 실행하여 이 제한을 설정합니다.

GitLab Rails 콘솔:

# 기본 계획에 제한이 없는 경우 다음과 같이 제한을 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(web_hook_calls: 10)

제한을 0으로 설정하면 비활성화됩니다.

  • 기본 속도 제한: 비활성화됨 (무제한).

검색 속도 제한

  • 변경됨 GitLab 15.9에서 이슈, 병합 요청 및 에픽 검색을 속도 제한에 포함하도록 변경되었습니다.
  • 변경됨 GitLab 16.0에서 인증된 요청에 대한 검색 스코프에 속도 제한을 적용하도록 변경되었습니다.

이 설정은 검색 요청을 다음과 같이 제한합니다.

제한 기본값 (분당 요청 수)
인증된 사용자 300
인증되지 않은 사용자 100

분당 검색 속도 제한을 초과하는 검색 요청은 다음과 같은 오류를 반환합니다:

이 엔드포인트에 너무 많은 요청이 있었습니다. 나중에 다시 시도하세요.

파이프라인 생성 속도 제한

이 설정은 파이프라인 생성 엔드포인트에 대한 요청 속도를 제한합니다.

파이프라인 생성 속도 제한에 대해 자세히 알아보기.

Gitaly 동시성 제한

클론 트래픽은 Gitaly 서비스에 큰 부담을 줄 수 있습니다. 이러한 작업량이 Gitaly 서버를 압도하지 않도록 Gitaly 구성 파일에서 동시성 제한을 설정할 수 있습니다.

Gitaly 동시성 제한에 대해 자세히 알아보기.

  • 기본 속도 제한: 비활성화됨.

이슈, 병합 요청 또는 커밋당 댓글 수

이슈, 병합 요청 또는 커밋에 제출할 수 있는 댓글 수에는 제한이 있습니다.

제한에 도달하면 시스템 노트는 여전히 추가할 수 있어 이벤트의 기록이 손실되지 않지만, 사용자가 제출한 댓글은 실패합니다.

  • 최대 제한: 5,000 댓글.

문제, 병합 요청 및 에픽의 댓글과 설명 크기

문제, 병합 요청 및 에픽의 댓글과 설명의 크기에는 제한이 있습니다.

제한을 초과하는 본문을 추가하려고 하면 오류가 발생하며,

항목이 생성되지 않습니다.

앞으로 이 제한이 더 낮은 숫자로 변경될 가능성이 있습니다.

  • 최대 크기: ~100만 문자 / ~1 MB.

커밋 제목 및 설명 크기

무제한으로 큰 메시지를 가진 커밋은 GitLab에 푸시할 수 있지만,

다음 표시 한계가 적용됩니다:

  • 제목 - 커밋 메시지의 첫 번째 줄. 1 KiB로 제한됩니다.
  • 설명 - 커밋 메시지의 나머지 부분. 1 MiB로 제한됩니다.

커밋이 푸시될 때, GitLab은 제목과 설명을 처리하여

문제(#123) 및 병합 요청(!123)에 대한 참조를

문제 및 병합 요청에 대한 링크로 교체합니다.

많은 수의 커밋이 있는 브랜치를 푸시할 경우,

마지막 100개의 커밋만 처리됩니다.

마일스톤 개요에서의 문제 수

마일스톤 개요 페이지에 로드되는 문제의 최대 수는 500개입니다.

한계를 초과할 경우 페이지에 경고가 표시되고

모든 문제의 페이지 매김된 문제 목록으로 연결됩니다.

  • 제한: 500개 문제.

Git 푸시당 파이프라인 수

단일 Git 푸시로 여러 변경 사항(여러 태그 또는 브랜치)을 푸시할 경우,

오직 네 개의 태그 또는 브랜치 파이프라인만 트리거될 수 있습니다.

이 제한은 git push --all 또는 git push --mirror를 사용할 때

우연히 많은 수의 파이프라인이 생성되는 것을 방지합니다.

병합 요청 파이프라인은 제한되지 않습니다.

Git 푸시가 동시에 여러 병합 요청을 업데이트하면,

업데이트된 각 병합 요청에 대해 병합 요청 파이프라인이 트리거될 수 있습니다.

단일 Git 푸시 이벤트에 대해 어떤 수의 파이프라인이 트리거될 수 있도록

제한을 제거하려면, 관리자는 git_push_create_all_pipelines 기능 플래그를 활성화할 수 있습니다.

이 기능 플래그를 활성화하는 것은 권장되지 않으며,

한 번에 너무 많은 변경 사항이 푸시되고

우연히 많은 파이프라인이 생성되면 GitLab 인스턴스에

과도한 부하를 유발할 수 있습니다.

활동 기록 보존

프로젝트 및 개인 프로필의 활동 기록은

3년으로 제한됩니다.

포함된 메트릭 수

성능상의 이유로 GitLab Flavored Markdown(GLFM)에 메트릭을 포함하는 데에는 제한이 있습니다.

  • 최대 한도: 100개 포함.

웹후크 한도

웹후크 속도 한도도 참고하세요.

웹후크 수

자체 관리 설치를 위한 그룹 또는 프로젝트 웹후크의 최대 수를 설정하려면,

GitLab Rails 콘솔에서 다음을 실행하세요:

# 기본 요금제에 대한 한도가 없는 경우, 다음을 사용하여 생성할 수 있습니다:
# Plan.default.create_limits!

# 프로젝트 웹후크용
Plan.default.actual_limits.update!(project_hooks: 200)

# 그룹 웹후크용
Plan.default.actual_limits.update!(group_hooks: 100)

한도를 0으로 설정하면 비활성화됩니다.

기본 최대 웹후크 수는 프로젝트당 100개, 그룹당 50개입니다.

하위 그룹의 웹후크는 상위 그룹의 웹후크 한도에 포함되지 않습니다.

GitLab.com의 경우, GitLab.com의 웹후크 한도를 참조하세요.

Webhook 페이로드 크기

최대 webhook 페이로드 크기는 25 MB입니다.

Webhook 시간 초과

GitLab이 webhook을 전송한 후 HTTP 응답을 기다리는 초의 수입니다.

webhook 시간 초과 값을 변경하려면:

  1. Sidekiq가 실행 중인 모든 GitLab 노드에서 /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['webhook_timeout'] = 60
  2. 파일을 저장합니다.

  3. 변경 사항을 적용하려면 GitLab을 재구성하고 다시 시작합니다:

    gitlab-ctl reconfigure
gitlab-ctl restart

자세한 내용은 GitLab.com의 webhook 제한을 참조하세요.

반복되는 webhook

GitLab은 반복적이거나 다른 webhook에서 트리거된 webhook의 제한을 초과하는 webhook을 감지하고 차단합니다. 이를 통해 GitLab은 비반복적으로 API를 호출하는 데 webhook을 사용하는 워크플로우를 계속 지원할 수 있으며, 다른 webhook을 비합리적인 수로 트리거하지 않도록 합니다.

반복이 발생할 수 있는 경우는 webhook이 자신의 GitLab 인스턴스(예: API)에 호출하도록 설정된 경우입니다. 이 호출은 동일한 webhook을 트리거하고 무한 루프를 생성합니다.

다른 webhook을 트리거하는 일련의 webhook이 인스턴스에 보내는 요청의 최대 수는 100입니다. 이 제한에 도달하면 GitLab은 시리즈에 의해 트리거된 추가 webhook을 차단합니다.

차단된 반복 webhook 호출은 "Recursive webhook blocked from executing" 메시지와 함께 auth.log에 기록됩니다.

가져오기 플레이스홀더 사용자 제한

가져오기 중에 생성된 플레이스홀더 사용자의 수는 최상위 네임스페이스별로 제한할 수 있습니다.

GitLab 셀프 관리의 기본 제한은 0(무제한)입니다.

셀프 관리 설치의 이 제한을 변경하려면, GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 계획에 제한이 없으면 다음과 같이 만들 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(import_placeholder_user_limit_tier_1: 200)

비활성화하려면 제한을 0으로 설정합니다.

풀 미러링 간격

풀 새로 고침 간의 최소 대기 시간은 기본적으로 300초(5분)입니다. 예를 들어, 주어진 300초 기간 동안 풀 새로 고침은 한 번만 실행됩니다. 이는 얼마나 자주 트리거하든 관계없이 동일합니다.

이 설정은 projects API를 사용하여 호출된 풀 새로 고침의 맥락에서 적용되며, Settings > Repository > Mirroring repositories에서 Update now( )를 선택하여 업데이트를 강제할 때에도 적용됩니다. 이 설정은 풀 미러링을 위해 Sidekiq에서 사용하는 자동 30분 간격 일정에는 영향을 미치지 않습니다.

셀프 관리 설치의 이 제한을 변경하려면, GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 계획에 제한이 없으면 다음과 같이 만들 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(pull_mirror_interval_seconds: 200)

자동 응답기에서 오는 이메일

GitLab은 X-Autoreply 헤더를 확인하여 자동 응답기에서 발송된 모든 수신 이메일을 무시합니다. 이러한 이메일은 이슈이나 병합 요청에 댓글을 생성하지 않습니다.

Sentry를 통한 오류 추적에서 전송되는 데이터 양

GitLab에 전송되는 Sentry 페이로드는 보안상의 이유와 메모리 소비 제한을 위해 최대 1 MB로 제한됩니다.

오프셋 기반 페이지 매김을 위한 REST API에서 허용되는 최대 오프셋

REST API에서 오프셋 기반 페이지 매김을 사용할 때, 결과 집합의 최대 요청 오프셋에 제한이 있습니다. 이 제한은 키셋 기반 페이지 매김을 지원하는 엔드포인트에만 적용됩니다. 페이지 매김 옵션에 대한 자세한 내용은 API 문서의 페이지 매김 섹션에서 확인할 수 있습니다.

셀프 관리 설치의 경우 이 제한을 설정하려면 다음 명령을 GitLab Rails 콘솔에서 실행하세요:

# 기본 요금제에 대한 제한이 존재하지 않으면 다음과 같이 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(offset_pagination_limit: 10000)
  • 기본 오프셋 페이지 매김 제한: 50000.

제한을 0으로 설정하면 비활성화됩니다.

CI/CD 제한사항

활성 파이프라인의 작업 수

활성 파이프라인의 총 작업 수를 프로젝트별로 제한할 수 있습니다. 이 제한은 새로운 파이프라인이 생성될 때마다 확인됩니다. 활성 파이프라인은 다음 상태 중 하나에 있는 모든 파이프라인입니다:

  • created
  • pending
  • running

새로운 파이프라인으로 인해 총 작업 수가 제한을 초과하면 파이프라인은 job_activity_limit_exceeded 오류와 함께 실패합니다.

  • GitLab SaaS 구독자는 요금제별로 정의된 서로 다른 제한을 가지며, 이는 해당 요금제 하의 모든 프로젝트에 영향을 미칩니다.
  • GitLab Premium 셀프 관리 또는 그 이상의 설치에서는 이 제한이 모든 프로젝트에 영향을 미치는 default 요금제 하에 정의됩니다. 이 제한은 기본적으로 비활성화(0)되어 있습니다.

셀프 관리 설치의 경우 이 제한을 설정하려면 다음 명령을 GitLab Rails 콘솔에서 실행하세요:

# 기본 요금제에 대한 제한이 존재하지 않으면 다음과 같이 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_active_jobs: 500)

제한을 0으로 설정하면 비활성화됩니다.

작업 실행 최대 시간

작업의 최대 실행 시간은 기본적으로 60분입니다. 60분을 초과해 실행되는 작업은 타임아웃됩니다.

작업이 타임아웃되기 전에 실행될 수 있는 최대 시간을 변경할 수 있습니다:

  • 주어진 프로젝트의 프로젝트 CI/CD 설정에서 프로젝트 수준으로. 이 제한은 10분에서 1개월 사이여야 합니다.
  • 러너 수준에서. 이 제한은 10분 이상이어야 합니다.

파이프라인에서의 배포 작업의 최대 수

파이프라인에서 배포 작업의 최대 수를 제한할 수 있습니다. 배포는 environment가 지정된 모든 작업입니다. 파이프라인 내에서 배포 수는 파이프라인 생성 시 확인됩니다. 배포가 너무 많은 파이프라인은 deployments_limit_exceeded 오류와 함께 실패합니다.

기본적인 제한은 모든 GitLab 셀프 관리 및 SaaS 요금제에 대해 500입니다.

셀프 관리 설치의 경우, 다음 GitLab Rails 콘솔 명령을 사용하여 default 요금제의 제한을 변경하세요:

# 기본 요금제에 대한 제한이 존재하지 않으면 다음과 같이 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_pipeline_deployments: 500)

제한을 0으로 설정하면 비활성화됩니다.

CI/CD 구독 수

프로젝트당 총 구독 수는 제한될 수 있습니다. 이 제한은 새로운 구독이 생성될 때마다 확인됩니다.

새로운 구독으로 인해 총 구독 수가 제한을 초과할 경우, 해당 구독은 유효하지 않은 것으로 간주됩니다.

  • GitLab SaaS에서: 제한은 플랜별로 정의되어 있습니다
    , 그리고 모든 프로젝트에 영향을 미칩니다.
  • 셀프 관리에서: GitLab Premium 또는 Ultimate에서는 이 제한이 모든 프로젝트에 영향을 미치는 default 플랜 아래 정의됩니다. 기본적으로 2개의 구독이 제한되어 있습니다.

셀프 관리 설치에 대한 이 제한을 설정하려면, 다음을 실행하세요
GitLab Rails console:

Plan.default.actual_limits.update!(ci_project_subscriptions: 500)

이 제한을 비활성화하려면 0으로 설정하세요.

파이프라인 트리거 수 제한

프로젝트당 최대 파이프라인 트리거 수를 제한할 수 있습니다. 이 제한은 새로운 트리거가 생성될 때마다 확인됩니다.

새로운 트리거로 인해 총 파이프라인 트리거 수가 제한을 초과할 경우, 해당 트리거는 유효하지 않은 것으로 간주됩니다.

이 제한을 비활성화하려면 0으로 설정하세요. 셀프 관리 인스턴스의 기본값은 25000입니다.

셀프 관리 설치에서 이 제한을 100으로 설정하려면, 다음을 실행하세요
GitLab Rails console:

Plan.default.actual_limits.update!(pipeline_triggers: 100)

이 제한은 GitLab.com에서 활성화되어 있습니다.

파이프라인 스케줄 수

프로젝트당 총 파이프라인 스케줄 수는 제한될 수 있습니다. 이 제한은 새로운 파이프라인 스케줄이 생성될 때마다 확인됩니다. 새로운 파이프라인 스케줄로 인해 총 파이프라인 스케줄 수가 제한을 초과할 경우, 해당 파이프라인 스케줄은 생성되지 않습니다.

GitLab SaaS 구독자는 플랜별로 정의된 서로 다른 제한을 가지며, 이는 해당 플랜 아래 모든 프로젝트에 영향을 미칩니다.

GitLab Premium 셀프 관리 또는 그 이상의 설치에서는 이 제한이 모든 프로젝트에 영향을 미치는 default 플랜 아래 정의됩니다. 기본적으로 10개의 파이프라인 스케줄이 제한되어 있습니다.

셀프 관리 설치에 대한 이 제한을 설정하려면, 다음을 실행하세요
GitLab Rails console:

Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)

파이프라인 스케줄에 의해 생성되는 파이프라인 수 제한

파이프라인 스케줄이 하루에 트리거할 수 있는 파이프라인 수를 제한할 수 있습니다.

제한보다 더 자주 파이프라인을 실행하려고 하는 스케줄은 최대 빈도로 조정됩니다. 빈도는 하루의 분인 1440을 제한 값으로 나누어 계산됩니다. 예를 들어, 최대 빈도가:

  • 1분에 한 번: 제한은 1440이어야 합니다.
  • 10분에 한 번: 제한은 144이어야 합니다.
  • 60분에 한 번: 제한은 24이어야 합니다.

최소값은 24, 즉 60분에 하나의 파이프라인입니다.

최대값은 없습니다.

셀프 관리 설치에서 이 제한을 1440으로 설정하려면, 다음을 실행하세요
GitLab Rails console:

Plan.default.actual_limits.update!(ci_daily_pipeline_schedule_triggers: 1440)

이 제한은 GitLab.com에서 활성화되어 있습니다.

보안 정책 프로젝트에 대한 일정 규칙 수 제한

보안 정책 프로젝트당 일정 규칙의 총 수를 제한할 수 있습니다. 이 제한은 일정 규칙이 있는 정책이 업데이트될 때마다 확인됩니다. 새로운 일정 규칙으로 인해 일정 규칙의 총 수가 제한을 초과하게 되면, 새로운 일정 규칙은 처리되지 않습니다.

기본적으로, self-managed 인스턴스는 처리 가능한 일정 규칙의 수를 제한하지 않습니다.

self-managed 설치에 대한 이 제한을 설정하려면, 다음 명령을 GitLab Rails 콘솔에서 실행하세요:

Plan.default.actual_limits.update!(security_policy_scan_execution_schedules: 100)

이 제한은 GitLab.com에서 활성화되어 있습니다.

CI/CD 변수 제한

  • 그룹 및 프로젝트 변수 제한은 GitLab 15.7에서 도입됨.

프로젝트, 그룹 및 인스턴스 설정에서 정의할 수 있는 CI/CD 변수의 수는 전체 인스턴스를 위해 제한됩니다. 이러한 제한은 새로운 변수가 생성될 때마다 확인됩니다. 새로운 변수가 해당 제한을 초과하게 되면, 새로운 변수는 생성되지 않습니다.

self-managed 설치에서 이러한 제한 중 하나의 default 플랜을 업데이트하려면, GitLab Rails 콘솔에서 다음 명령을 실행하세요:

아티팩트 유형별 최대 파일 크기

  • ci_max_artifact_size_annotations 제한은 GitLab 16.3에서 도입됨.

artifacts:reports로 정의된 작업 아티팩트는 러너에 의해 업로드될 때 파일 크기가 최대 파일 크기 제한을 초과하면 거부됩니다. 제한은 프로젝트의 최대 아티팩트 크기 설정 과 주어진 아티팩트 유형에 대한 인스턴스 제한을 비교하여 더 작은 값을 선택함으로써 결정됩니다.

제한은 메가바이트 단위로 설정되므로, 정의할 수 있는 최소 값은 1 MB입니다.

각 아티팩트 유형마다 설정할 수 있는 크기 제한이 있습니다. 기본값 0은 해당 특정 아티팩트 유형에 대한 제한이 없음을 의미하며, 프로젝트의 최대 아티팩트 크기 설정이 사용됩니다:

아티팩트 제한 이름 기본값
ci_max_artifact_size_accessibility 0
ci_max_artifact_size_annotations 0
ci_max_artifact_size_api_fuzzing 0
ci_max_artifact_size_archive 0
ci_max_artifact_size_browser_performance 0
ci_max_artifact_size_cluster_applications 0
ci_max_artifact_size_cobertura 0
ci_max_artifact_size_codequality 0
ci_max_artifact_size_container_scanning 0
ci_max_artifact_size_coverage_fuzzing 0
ci_max_artifact_size_dast 0
ci_max_artifact_size_dependency_scanning 0
ci_max_artifact_size_dotenv 0
ci_max_artifact_size_junit 0
ci_max_artifact_size_license_management 0
ci_max_artifact_size_license_scanning 0
ci_max_artifact_size_load_performance 0
ci_max_artifact_size_lsif 100 MB
ci_max_artifact_size_metadata 0
ci_max_artifact_size_metrics_referee 0
ci_max_artifact_size_metrics 0
ci_max_artifact_size_network_referee 0
ci_max_artifact_size_performance 0
ci_max_artifact_size_requirements 0
ci_max_artifact_size_requirements_v2 0
ci_max_artifact_size_sast 0
ci_max_artifact_size_secret_detection 0
ci_max_artifact_size_terraform 5 MB
ci_max_artifact_size_trace 0
ci_max_artifact_size_cyclonedx 5 MB

예를 들어, self-managed 설치에서 ci_max_artifact_size_junit 제한을 10 MB로 설정하려면, GitLab Rails 콘솔에서 다음 명령을 실행하세요:

Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 10)

GitLab Pages 웹사이트당 파일 수

GitLab Pages 웹사이트당 파일 항목(디렉토리 및 심볼릭 링크 포함)의 총 수는 200,000으로 제한됩니다.

이는 모든 GitLab 자가 관리 및 SaaS 요금제에 대한 기본 제한입니다.

자가 관리 인스턴스에서 이 한도를 업데이트하려면 GitLab Rails 콘솔을 사용하세요. 예를 들어 한도를 100으로 변경하려면:

Plan.default.actual_limits.update!(pages_file_entries: 100)

GitLab Pages 웹사이트당 커스텀 도메인 수

GitLab Pages 웹사이트당 커스텀 도메인의 총 수는 GitLab SaaS에 대해 150으로 제한됩니다.

GitLab 자가 관리의 기본 제한은 0(무제한)입니다. 자가 관리 인스턴스에서 한도를 설정하려면 관리자 영역을 사용하세요.

병렬 Pages 배포 수

병렬 Pages 배포를 사용할 때, 최상위 네임스페이스에 허용되는 병렬 Pages 배포의 총 수는 1000입니다.

범위당 등록된 러너 수

  • 러너 유효 기간 변경됨 — GitLab 17.1에서 3개월에서 7일로.

등록된 러너의 총 수는 그룹 및 프로젝트에 대해 제한됩니다. 새 러너가 등록될 때마다 GitLab은 최근 7일 동안 활성 상태였던 러너를 기준으로 이러한 한도를 확인합니다.

러너의 등록이 제한을 초과하면 등록이 실패합니다. 제한 값이 0으로 설정되면 제한이 비활성화됩니다.

GitLab SaaS 구독자는 요금제별로 정의된 서로 다른 한계를 가지며, 이는 해당 요금제를 사용하는 모든 프로젝트에 영향을 줍니다.

자가 관리 GitLab Premium 및 Ultimate 한계는 모든 프로젝트에 영향을 미치는 기본 계획으로 정의됩니다:

러너 범위 기본값
ci_registered_group_runners 1000
ci_registered_project_runners 1000

이러한 한계를 업데이트하려면, GitLab Rails 콘솔에서 다음을 실행하세요:

# 원하는 범위에 따라 ci_registered_group_runners 또는 ci_registered_project_runners 사용
Plan.default.actual_limits.update!(ci_registered_project_runners: 100)

작업 로그의 최대 파일 크기

GitLab의 작업 로그 파일 크기 제한은 기본적으로 100메가바이트입니다. 한계를 초과하는 작업은 실패로 표시되며, 러너에 의해 삭제됩니다.

한도를 GitLab Rails 콘솔에서 변경할 수 있습니다. 메가바이트로 새로운 값으로 ci_jobs_trace_size_limit을 업데이트하세요:

Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 125)

GitLab 러너는 최대 로그 크기를 구성하는 output_limit 설정도 가지고 있습니다. 러너 한도를 초과하는 작업은 계속 실행되지만, 한도에 도달하면 로그가 잘립니다.

프로젝트당 활성 DAST 프로필 스케줄의 최대 수

프로젝트당 활성 DAST 프로필 스케줄의 수를 제한합니다. DAST 프로필 스케줄은 활성 또는 비활성 상태일 수 있습니다.

GitLab Rails console에서 제한을 변경할 수 있습니다.

dast_profile_schedules를 새 값으로 업데이트하세요:

Plan.default.actual_limits.update!(dast_profile_schedules: 50)

CI 아티팩트 아카이브의 최대 크기

CI 아티팩트 아카이브의 기본 최대 크기는 5 메가바이트입니다.

이 제한은 GitLab Rails console에서 변경할 수 있습니다.

CI 아티팩트 아카이브의 최대 크기를 업데이트하려면,

max_artifacts_content_include_size를 새 값으로 업데이트하세요. 예를 들어, 20 MB로 설정하려면:

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

CI/CD 구성 YAML 파일의 최대 크기 및 깊이

단일 CI/CD 구성 YAML 파일의 기본 최대 크기는 1 메가바이트이며

기본 깊이는 100입니다.

이 제한은 GitLab Rails console에서 변경할 수 있습니다:

  • 최대 YAML 크기를 업데이트하려면, max_yaml_size_bytes를 메가바이트로 새 값으로 업데이트하세요:

    ApplicationSetting.update(max_yaml_size_bytes: 2.megabytes)

    max_yaml_size_bytes 값은 YAML 파일의 크기에 직접적으로 연관되어 있지 않으며,

    관련 객체에 할당된 메모리를 나타냅니다.

  • 최대 YAML 깊이를 업데이트하려면, max_yaml_depth를 라인 수로 새 값으로 업데이트하세요:

    ApplicationSetting.update(max_yaml_depth: 125)

전체 CI/CD 구성의 최대 크기

전체 파이프라인 구성에 할당할 수 있는 최대 메모리 양(바이트 기준)입니다.

모든 포함된 YAML 구성 파일과 함께 사용됩니다.

새로운 자가 관리 인스턴스의 경우, 기본값은 157286400 바이트(150 MB)입니다.

GitLab 16.3 또는 이후로 업그레이드하는 기존 자가 관리 인스턴스의 경우, 기본값은 max_yaml_size_bytes (기본값 1 MB)와 ci_max_includes (기본값 150)를 곱한 값으로 계산됩니다.

두 제한이 모두 수정되지 않은 경우 기본값은 1 MB x 150 = 157286400 바이트(150 MB)로 설정됩니다.

이 제한은 GitLab Rails console에서 변경할 수 있습니다.

CI/CD 구성을 위해 할당할 수 있는 최대 메모리를 업데이트하려면,

ci_max_total_yaml_size_bytes를 새 값으로 업데이트하세요. 예를 들어, 20 MB로 설정하려면:

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

dotenv 변수 제한

dotenv 아티팩트 내에서 최대 변수 수에 대한 제한을 설정할 수 있습니다.

이 제한은 dotenv 파일이 아티팩트로 내보내질 때마다 확인됩니다.

해당 제한을 0으로 설정하여 비활성화할 수 있습니다. 자가 관리 인스턴스에서는 기본값이 20입니다.

자가 관리 인스턴스에서 이 제한을 100으로 설정하려면, GitLab Rails console에서 다음 명령을 실행하세요:

Plan.default.actual_limits.update!(dotenv_variables: 100)

이 제한은 GitLab.com에서 활성화되어 있습니다.

dotenv 파일 크기 제한

dotenv 아티팩트의 최대 크기에 한계를 설정할 수 있습니다. 이 제한은 dotenv 파일이 아티팩트로 내보낼 때마다 확인됩니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 5 KB입니다.

이 제한을 self-managed 설치에서 5 KB로 설정하려면, 다음을 실행하세요.

GitLab Rails 콘솔에서:

Plan.default.actual_limits.update!(dotenv_size: 5.kilobytes)

CI/CD 작업 주석 제한

CI/CD 작업당 최대 주석 수에 한계를 설정할 수 있습니다.

제한을 0으로 설정하면 비활성화됩니다. self-managed 인스턴스에서 기본값은 20입니다.

이 제한을 self-managed 인스턴스에서 100으로 설정하려면, 다음 명령을 실행하세요.

GitLab Rails 콘솔에서:

Plan.default.actual_limits.update!(ci_job_annotations_num: 100)

CI/CD 작업 주석 파일 크기 제한

CI/CD 작업 주석의 최대 크기에 한계를 설정할 수 있습니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 80 KB입니다.

이 제한을 self-managed 설치에서 100 KB로 설정하려면, 다음을 실행하세요.

GitLab Rails 콘솔에서:

Plan.default.actual_limits.update!(ci_job_annotations_size: 100.kilobytes)

인스턴스 모니터링 및 메트릭

수신 사고 관리 경고 제한

이 설정은 특정 기간 동안 수신하는 경고 페이로드 수를 제한합니다.

사고 관리 비율 제한에 대해 더 읽어보세요.

Prometheus Alert JSON 페이로드

notify.json 엔드포인트로 전송된 Prometheus 경고 페이로드의 크기는 1 MB로 제한됩니다.

일반 경고 JSON 페이로드

notify.json 엔드포인트로 전송된 경고 페이로드의 크기는 1 MB로 제한됩니다.

메트릭 대시보드 YAML 파일

구문 분석된 메트릭 대시보드 YAML 파일이 차지하는 메모리는 1 MB를 초과할 수 없습니다.

각 YAML 파일의 최대 깊이는 100으로 제한됩니다. YAML 파일의 최대 깊이는 가장 깊숙한 키의 중첩 수준입니다. 가장 깊숙한 키의 경로에 있는 각 해시와 배열이 깊이에 포함됩니다. 예를 들어, 다음 YAML에서 가장 깊숙한 키의 깊이는 7입니다.

dashboard: 'Test dashboard'
links:
- title: Link 1
  url: https://gitlab.com
panel_groups:
- group: Group A
  priority: 1
  panels:
  - title: "Super Chart A1"
    type: "area-chart"
    y_label: "y_label"
    weight: 1
    max_value: 1
    metrics:
    - id: metric_a1
      query_range: 'query'
      unit: unit
      label: Legend Label

환경 대시보드 제한

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

최대 표시 프로젝트 수에 대한 자세한 내용은 환경 대시보드를 참조하세요.

배포 보드의 환경 데이터

배포 보드는 Kubernetes에서 Pods 및 Deployments에 대한 정보를 로드합니다. 그러나 Kubernetes에서 읽은 특정 환경의 데이터가 10MB를 초과하면 표시되지 않습니다.

병합 요청

차이 제한

GitLab에는 다음과 관련된 제한이 있습니다:

각각에 대해 상한 및 하한 제한이 적용됩니다:

  • 변경된 파일의 수.
  • 변경된 줄의 수.
  • 표시되는 변경 사항의 누적 크기.

하한 제한은 추가 차이가 축소되는 결과를 초래합니다. 상한 제한은 더 이상의 변경 사항이 렌더링되는 것을 방지합니다. 이러한 제한에 대한 추가 정보는 개발 문서를 참조하세요.

병합 요청 보고서 크기 제한

20MB 제한을 초과하는 보고서는 로드되지 않습니다. 영향을 받는 보고서는 다음과 같습니다:

고급 검색 제한

인덱싱된 최대 파일 크기

Elasticsearch에서 인덱싱되는 저장소 파일의 내용에 제한을 설정할 수 있습니다. 이 한도를 초과하는 파일은 파일 이름만 인덱싱됩니다. 파일 내용은 인덱싱되지 않으며 검색되지 않습니다.

제한을 설정하면 인덱싱 프로세스의 메모리 사용량과 전체 인덱스 크기를 줄이는 데 도움이 됩니다. 이 값의 기본값은 1024 KiB(1 MiB)로 설정되며, 이는 이보다 큰 텍스트 파일은 인간이 읽으려고 의도한 것이 아닐 가능성이 높기 때문입니다.

제한을 설정해야 하며, 무제한 파일 크기는 지원되지 않습니다. 이 값을 GitLab Sidekiq 노드의 메모리 양보다 크게 설정하면 GitLab Sidekiq 노드의 메모리가 부족해질 수 있습니다. 이 메모리 양은 인덱싱 중에 미리 할당됩니다.

최대 필드 길이

고급 검색을 위해 인덱싱되는 텍스트 필드의 내용에 대해 제한을 설정할 수 있습니다. 최대값 설정은 인덱싱 프로세스의 부하를 줄이는 데 도움이 됩니다. 텍스트 필드가 이 제한을 초과하면 텍스트는 이 문자의 수로 잘립니다. 나머지 텍스트는 인덱싱되지 않으며 검색할 수 없습니다.

이것은 인덱싱된 모든 데이터에 적용되며, 별도의 제한이 있는 인덱싱된 저장소 파일에는 적용되지 않습니다. 추가 정보는 인덱싱된 최대 파일 크기를 참조하세요.

  • GitLab.com에서는 필드 길이 제한이 20,000자입니다.

  • self-managed 설치의 경우 필드 길이는 기본적으로 무제한입니다.

self-managed 설치에 대해 이 제한을 구성할 수 있으며, Elasticsearch를 활성화해야 합니다. 제한을 비활성화하려면 이 값을 0으로 설정하세요.

수학 렌더링 제한

History
  • Introduced in GitLab 16.5.
  • Removed the 50-node limit from Wiki and repository files.
  • Added a group-level setting to allow disabling math rendering limits, and re-enabled by default the math limits for wiki and repository files in GitLab 16.9.

GitLab은 Markdown 필드에서 수학을 렌더링할 때 기본 제한을 적용합니다. 이러한 제한은 보안 및 성능을 향상시킵니다.

문제, 병합 요청, 서사, 위키 및 저장소 파일에 대한 제한은 다음과 같습니다:

  • 매크로 확장 최대 수: 1000.
  • 사용자 지정 최대 크기 em: 20.
  • 렌더링된 최대 노드 수: 50.
  • 수학 블록의 최대 문자 수: 1000.
  • 최대 렌더링 시간: 2000 ms.

self-managed 인스턴스에서 실행 중일 때 이러한 제한을 비활성화하고 사용자 입력을 신뢰할 수 있습니다.

GitLab Rails 콘솔을 사용하세요:

ApplicationSetting.update(math_rendering_limits_enabled: false)

이러한 제한은 GraphQL 또는 REST API를 사용하여 그룹별로 비활성화할 수 있습니다.

제한이 비활성화되면 문제, 병합 요청, 서사, 위키 및 저장소 파일에서 거의 제한 없이 수학이 렌더링됩니다. 이는 악의적인 행위자가 브라우저에서 볼 때 DoS를 초래할 수 있는 수학을 추가할 수 있음을 의미합니다. 신뢰할 수 있는 사람만 콘텐츠를 추가할 수 있도록 해야 합니다.

위키 한계

스니펫 한계

스니펫 설정에 대한 문서를 참조하세요.

디자인 관리 한계

이슈에 디자인 추가 섹션에서 한계를 확인하세요.

푸시 이벤트 한계

최대 푸시 크기

허용되는 최대 푸시 크기.

자체 관리 인스턴스에서는 기본적으로 설정되지 않습니다. GitLab.com의 경우, 계정 및 제한 설정을 참조하세요.

웹후크 및 프로젝트 서비스

단일 푸시에서 변경 사항(브랜치 또는 태그)의 총 수입니다. 변경 사항이 지정된 제한을 초과하면 후크가 실행되지 않습니다.

자세한 내용은 다음을 참조하세요:

활동

개별 푸시 이벤트 또는 대량 푸시 이벤트를 생성하는지 여부를 결정하기 위해 단일 푸시에 대한 변경 사항(브랜치 또는 태그)의 총 수입니다.

자세한 내용은 푸시 이벤트 활동 한계 및 대량 푸시 이벤트 문서에서 확인할 수 있습니다.

패키지 레지스트리 한계

파일 크기 한계

GitLab 패키지 레지스트리에 업로드된 패키지의 기본 최대 파일 크기는 형식에 따라 다릅니다:

  • Conan: 3 GB

  • Generic: 5 GB

  • Helm: 5 MB

  • Maven: 3 GB

  • npm: 500 MB

  • NuGet: 500 MB

  • PyPI: 3 GB

  • Terraform: 1 GB

GitLab.com의 최대 파일 크기는 다를 수 있습니다.

자체 관리 설치에 이러한 제한을 설정하려면 관리자 영역을 통해 설정하거나 다음을 실행할 수 있습니다.

GitLab Rails 콘솔:

# 파일 크기 제한은 바이트로 저장됩니다.

# Conan 패키지
Plan.default.actual_limits.update!(conan_max_file_size: 100.megabytes)

# npm 패키지
Plan.default.actual_limits.update!(npm_max_file_size: 100.megabytes)

# NuGet 패키지
Plan.default.actual_limits.update!(nuget_max_file_size: 100.megabytes)

# Maven 패키지
Plan.default.actual_limits.update!(maven_max_file_size: 100.megabytes)

# PyPI 패키지
Plan.default.actual_limits.update!(pypi_max_file_size: 100.megabytes)

# Debian 패키지
Plan.default.actual_limits.update!(debian_max_file_size: 100.megabytes)

# Helm 차트
Plan.default.actual_limits.update!(helm_max_file_size: 100.megabytes)

# 일반 패키지
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)

파일 크기를 0으로 설정하면 모든 파일 크기를 허용합니다.

패키지 버전 반환

지정된 NuGet 패키지 이름의 버전을 요청할 때, GitLab 패키지 레지스트리는 최대 300개의 버전을 반환합니다.

의존성 프록시 한도

의존성 프록시에 캐시된 이미지의 최대 파일 크기는 Dependency Proxy 파일 유형에 따라 다릅니다:

  • 이미지 블롭: 5 GB
  • 이미지 매니페스트: 10 MB

최대 담당자 및 검토자 수

  • 최대 담당자는 GitLab 15.6에서 도입됨.
  • 최대 검토자는 GitLab 15.9에서 도입됨.

이슈 및 병합 요청은 이러한 최대치를 적용합니다:

  • 최대 담당자: 200
  • 최대 검토자: 200

GitLab.com의 CDN 기반 한도

애플리케이션 기반 한도 외에도, GitLab.com은 Cloudflare의 표준 DDoS 보호 및 Spectrum을 사용하여 SSH를 통해 Git을 보호하도록 구성되어 있습니다. Cloudflare는 클라이언트 TLS 연결을 종료하지만 애플리케이션에 대한 인식이 없어 사용자 또는 그룹에 연결된 한도에 사용할 수 없습니다. Cloudflare 페이지 규칙과 요금 한도는 Terraform으로 구성됩니다. 이러한 구성은 보안 및 남용 구현을 포함하고 있어 공개되지 않습니다. 공개되면 이러한 작업이 약화될 수 있습니다.

컨테이너 리포지토리 태그 삭제 한도

컨테이너 리포지토리 태그는 컨테이너 레지스트리에 있으며, 각 태그 삭제는 컨테이너 레지스트리에 대한 네트워크 요청을 트리거합니다. 이로 인해 단일 API 호출로 삭제할 수 있는 태그 수를 20으로 제한합니다.

프로젝트 수준의 보안 파일 API 한도

Secure Files API는 다음과 같은 한도를 적용합니다:

  • 파일 크기는 5 MB보다 작아야 합니다.
  • 프로젝트는 100개 이상의 보안 파일을 가질 수 없습니다.

변경 로그 API 한도

변경 로그 API는 다음과 같은 한도를 적용합니다:

  • from과 to 사이의 커밋 범위는 15000 개의 커밋을 초과할 수 없습니다.

가치 흐름 분석 한도

  • 각 네임스페이스(그룹 또는 프로젝트 등)는 최대 50개의 가치 흐름을 가질 수 있습니다.
  • 각 가치 흐름은 최대 15개의 단계를 가질 수 있습니다.

감사 이벤트 스트리밍 대상 한도

사용자 정의 HTTP 엔드포인트

  • 각 최상위 그룹은 최대 5개의 사용자 정의 HTTP 스트리밍 대상을 가질 수 있습니다.

Google Cloud Logging

  • 각 최상위 그룹은 최대 5개의 Google Cloud Logging 스트리밍 대상을 가질 수 있습니다.

Amazon S3

  • 각 최상위 그룹은 최대 5개의 Amazon S3 스트리밍 대상을 가질 수 있습니다.

모든 인스턴스 한도 목록

모든 인스턴스 한도 값을 나열하려면 GitLab Rails 콘솔에서 다음을 실행하십시오:

Plan.default.actual_limits

샘플 출력:

id: 1,
plan_id: 1,
ci_pipeline_size: 0,
ci_active_jobs: 0,
project_hooks: 100,
group_hooks: 50,
ci_project_subscriptions: 3,
ci_pipeline_schedules: 10,
offset_pagination_limit: 50000,
ci_instance_level_variables: "[FILTERED]",
storage_size_limit: 0,
ci_max_artifact_size_lsif: 100,
ci_max_artifact_size_archive: 0,
ci_max_artifact_size_metadata: 0,
ci_max_artifact_size_trace: "[FILTERED]",
ci_max_artifact_size_junit: 0,
ci_max_artifact_size_sast: 0,
ci_max_artifact_size_dependency_scanning: 350,
ci_max_artifact_size_container_scanning: 150,
ci_max_artifact_size_dast: 0,
ci_max_artifact_size_codequality: 0,
ci_max_artifact_size_license_management: 0,
ci_max_artifact_size_license_scanning: 100,
ci_max_artifact_size_performance: 0,
ci_max_artifact_size_metrics: 0,
ci_max_artifact_size_metrics_referee: 0,
ci_max_artifact_size_network_referee: 0,
ci_max_artifact_size_dotenv: 0,
ci_max_artifact_size_cobertura: 0,
ci_max_artifact_size_terraform: 5,
ci_max_artifact_size_accessibility: 0,
ci_max_artifact_size_cluster_applications: 0,
ci_max_artifact_size_secret_detection: "[FILTERED]",
ci_max_artifact_size_requirements: 0,
ci_max_artifact_size_coverage_fuzzing: 0,
ci_max_artifact_size_browser_performance: 0,
ci_max_artifact_size_load_performance: 0,
ci_needs_size_limit: 2,
conan_max_file_size: 3221225472,
maven_max_file_size: 3221225472,
npm_max_file_size: 524288000,
nuget_max_file_size: 524288000,
pypi_max_file_size: 3221225472,
generic_packages_max_file_size: 5368709120,
golang_max_file_size: 104857600,
debian_max_file_size: 3221225472,
project_feature_flags: 200,
ci_max_artifact_size_api_fuzzing: 0,
ci_pipeline_deployments: 500,
pull_mirror_interval_seconds: 300,
daily_invites: 0,
rubygems_max_file_size: 3221225472,
terraform_module_max_file_size: 1073741824,
helm_max_file_size: 5242880,
ci_registered_group_runners: 1000,
ci_registered_project_runners: 1000,
ci_daily_pipeline_schedule_triggers: 0,
ci_max_artifact_size_cluster_image_scanning: 0,
ci_jobs_trace_size_limit: "[FILTERED]",
pages_file_entries: 200000,
dast_profile_schedules: 1,
external_audit_event_destinations: 5,
dotenv_variables: "[FILTERED]",
dotenv_size: 5120,
pipeline_triggers: 25000,
project_ci_secure_files: 100,
repository_size: 0,
security_policy_scan_execution_schedules: 0,
web_hook_calls_mid: 0,
web_hook_calls_low: 0,
project_ci_variables: "[FILTERED]",
group_ci_variables: "[FILTERED]",
ci_max_artifact_size_cyclonedx: 1,
rpm_max_file_size: 5368709120,
pipeline_hierarchy_size: 1000,
ci_max_artifact_size_requirements_v2: 0,
enforcement_limit: 0,
notification_limit: 0,
dashboard_limit_enabled_at: nil,
web_hook_calls: 0,
project_access_token_limit: 0,
google_cloud_logging_configurations: 5,
ml_model_max_file_size: 10737418240,
limits_history: {},
audit_events_amazon_s3_configurations: 5

일부 한도 값은 Rails 콘솔에서의 필터링 때문에 목록에서 [FILTERED]로 표시됩니다.