이 문서는 Jira Cloud Automation의 성능에 영향을 미칠 수 있는 제한 사항에 대하여 가이드를 공유하기 위해 작성되었다.
서비스 제한 완벽 이해 & 최적화 가이드
똑똑한 워크플로우 자동화로 반복 작업을 줄이고 생산성을 높이는 Jira Automation, 정말 유용하죠? 하지만 너무 많은 자동화가 오히려 Jira 성능에 부담을 줄 수도 있다는 사실, 알고 계셨나요?
Atlassian Cloud에서는 이를 방지하기 위해 자동화 서비스 제한(Service Limits)이라는 정책을 적용하고 있어요. 오늘은 이 제한이 무엇인지, 왜 중요한지, 그리고 어떻게 효율적으로 관리할 수 있는지 안내해 드릴게요!
1. 자동화 서비스 제한이란?
자동화 서비스 제한이란, Jira Cloud 환경에서 인스턴스 성능을 보호하기 위해 자동화 규칙의 실행 조건과 리소스 사용량에 제한을 두는 정책입니다.
예를 들어, 지나치게 많은 하위 작업을 생성하거나 복잡한 JQL을 자주 실행하면 전체 Jira 시스템에 영향을 줄 수 있어요. 이런 상황을 방지하고자 Atlassian은 자동화 규칙에 다양한 최대 허용 수치를 정의해두었습니다.
2. 주요 서비스 제한 항목 한눈에 보기
| 제한 항목 | 제한 값 | 위반 예시 |
|---|---|---|
| 규칙당 구성 요소 수 | 65개 | 조건, 브랜치, 액션이 65개를 초과할 경우 |
| 고급 규칙 구성 요소 | 500개 | 고급 규칙 사용 시 조건 등 500개 초과 |
| 규칙 그룹당 구성 요소 | 65개 | 그룹 내 조건/액션이 65개 초과 |
| 액션당 하위 작업 생성 | 50개 | 한 액션에서 하위 작업 50개 초과 생성 시도 |
| 검색된 이슈 수 | 1,000개 | JQL 결과가 1,000개 초과 |
| 예약 규칙 동시 실행 | 1개 (5분 초과시) | 5분마다 실행되는 예약 규칙이 이전 실행이 끝나지 않았을 때 5분이 흘러도 다시 규칙을 수행하지 않음 |
| 규칙당 관련 항목 수 | 5,000개 | 복잡한 브랜치 구조로 대량 항목 생성 시 예를 들어 100개의 이슈를 가져오는 스케쥴 트리거에 이슈당 10개의 하위 작업을 가져오는 브랜치가 있으면 100 * 10으로 1000개 항목이 카운트됨 이런식으로 계산해 5000개가 넘으면 해당 규칙은 비활성화됨 |
| 전역 대기열 항목 수 | 50,000개 | 전체 인스턴스에서의 실행 항목 수 |
| 일일 처리 시간 | 12시간당 60분 | 규칙이 실행되는데 걸리는 시간의 총합이 12시간당 60분 제한 |
| 루프 감지 | 10회 | 무한 루프처럼 연쇄 실행 시 |
| 이메일 전송 액션 | 100개 / 24시간 | Free/Trial 플랜 한정 |
| 이슈 조회 액션 | 100개 | Lookup Issues 액션에서 JQL 결과 수 |
| 브랜치 검색 항목 수 | 150개 | For each branch에서 반환되는 쿼리 결과 초과 시 |
| 동시 실행 규칙 수 | Free: 5, Standard: 10, Premium: 20, Enterprise: 30 | 동일 시간대에 실행되는 규칙 수. 여러 사이트에 다른 플랜에 가입되어있다면 가장 높은 한도로 적용 (ex. Jira Premium + JSM Standard 가입 시 20개 동시 실행 가능) |
| AI 액션 실행 | 1,000회 / 12시간 | Atlassian Intelligence 관련 액션 |
| 자동화로 처리되는 필드 수 | 2,000개 | 이슈 생성/복제 시 필드 수 초과 |
3. 제한을 위반하면 어떻게 되나요?
규칙은 자동 비활성화되며 더 이상 실행되지 않습니다.
**감사 로그(Audit Log)**에서
THROTTLED상태 확인 가능예시 오류 메시지:
"Automation for Jira has exceeded the allowed total processing time for this rule"
"A JQL search in this automation rule has exceeded the allowed maximum number of issues..."
Service limit breached 트리거를 활용해 제한 도달 전 알림을 받을 수 있어요!
4. 대기열 항목 제한 심층 분석
Rule Processing Queue는 동시에 실행되는 항목을 관리하기 위한 큐입니다. 복잡한 규칙은 대기열 수를 폭증시킬 수 있습니다.
예시 1: 다중 브랜치 구조
예약 트리거가 100개의 이슈 일치
관련 이슈 브랜치 50개, 또 다른 관련 이슈 브랜치 80개
→ 총 약 13,000개의 대기열 항목
예시 2: 조건 분기 대신 관련 이슈 브랜치 사용
이슈 타입별 관련 이슈 브랜치: Bug(1,000), Task(500), Feature(2,000)
→ 총 3,500개 이상
이 제한에 도달하면 인스턴스 전체의 모든 자동화가 중단됩니다.
5. 제한 초과를 방지하는 스마트한 팁
| 전략 | 설명 |
|---|---|
| 예약 주기 늘리기 | 예: 5분 → 1시간 |
| JQL 쿼리 최적화 | 더 좁은 범위, 구체적인 조건 사용 예: type = Task AND status = "In Progress" |
| 업데이트 시간 조건 추가 | updated > -1w 등 |
| 규칙 분할 | 하나의 거대한 규칙 → 여러 개의 작은 규칙 |
| Jira Bulk 작업 활용 | 자동화보다 대규모 수정에 더 효율적 |
| 이슈 수 최소화 | 트리거 및 브랜치의 이슈 수 줄이기 |
| “이전 실행 이후 변경된 이슈만” 옵션 사용 | 변화가 있는 이슈에만 적용 |
| If/else block 사용 | 관련 이슈 브랜치 대신 조건 분기 사용 |