같은 “Jira Automation”이라는 이름을 쓰지만, Data Center(DC)와 Cloud는 라이선스 제공 방식부터 권한 모델, 처리 한도, 보안 기능, 감사 로그까지 구조가 상당히 다릅니다. 이 글은 Atlassian 공식 문서를 근거로, 실무에서 자주 혼동되는 지점들을 정리합니다.
Data Center Automation for Jira는 과거에는 별도로 설치하는 마켓플레이스 앱이었지만, 현재는 Jira Software Data Center와 Jira Service Management Data Center의 네이티브 기능으로 통합되었고 모든 Data Center 고객에게 무료로 제공됩니다. Automation for Jira 8.0 이상 버전은 Jira Data Center의 일부이기 때문에 별도 라이선스가 필요하지 않습니다. Data Center 10.0부터는 아예 번들 형태로만 제공되며, 이전처럼 마켓플레이스에서 개별 버전을 내려받는 방식은 종료되었습니다.
Cloud Cloud에서는 별도의 “라이선스” 개념이 아니라, Jira Cloud 요금(Free/Standard/Premium/Enterprise)에 자동화 기능이 포함되는 구조입니다. 다만 과금 방식 자체가 계속 바뀌고 있는데, 최근에는 앱별 월간 플로우 실행 한도 방식에서 벗어나, 조직(Organization) 단위로 풀링되는 사용량 기반 자동화 스텝(step) 과금 모델로 전환되었습니다. 트리거, 조건, 액션, 분기(branch), 반복(loop) 등 플로우 안에서 실행되는 모든 요소 하나하나가 “스텝”으로 집계되며, 조직의 구독/요금제에 따라 매달 정해진 스텝 허용량이 갱신됩니다.
정리: DC는 “제품에 포함된 무료 기능”, Cloud는 “요금제에 연동된 종량 과금 서비스”라는 근본적인 차이가 있습니다.
두 플랫폼 모두 전역 관리자와 프로젝트(스페이스) 관리자로 역할을 나누지만, 위임 방식이 다릅니다.
Cloud Administer Jira 전역 권한을 가진 관리자는 사이트 전체의 자동화 플로우(단일 프로젝트, 다중 프로젝트, 전역 규칙 모두)를 생성·관리할 수 있고, 사용량 데이터도 확인할 수 있습니다. 전역 관리자는 Global configuration 화면에서 “Allow project administrators to manage project rules” 옵션의 체크를 해제하거나 특정 그룹으로 제한하여, 프로젝트 관리자의 규칙 관리 권한 자체를 없애거나 좁힐 수 있습니다.
Data Center DC도 동일하게 전역 관리자가 프로젝트 관리자의 규칙 생성 권한을 그룹 단위로 제한할 수 있는 기능을 제공합니다. 다만 옵션을 끄더라도 프로젝트 관리자는 자신의 프로젝트에 적용된 규칙을 읽기 전용으로는 계속 볼 수 있도록 설계되어 있습니다.
Cloud 자동화 규칙은 어떤 계정의 권한으로 실행될지를 나타내는 “flow actor” 개념을 명시적으로 문서화하고 있습니다. 프로젝트 관리자는 본인 자신 또는 Automation for Jira 사용자만 flow actor로 지정할 수 있는 반면, 전역 관리자는 임의의 사용자를 flow actor로 지정할 수 있습니다. 또한 프로젝트 관리자는 자신이나 Automation 사용자가 flow actor로 설정된 플로우만 수정할 수 있고, 다른 사람이 flow actor로 지정된 플로우를 고치려면 먼저 flow actor를 자신 또는 Automation 사용자로 바꿔야 합니다. 이 제약은 전역 관리자에게는 적용되지 않습니다.
Cloud 자동화는 성격이 다른 두 가지 한도를 독립적으로 적용합니다.
특히 서비스 한도는 하나의 자동화 플로우가 12시간을 초과해 처리되거나, JQL 검색이 한 번에 가져올 수 있는 작업 항목 수를 초과하면 발생하며, 병렬로 처리 가능한 대기열 항목 수에도 제한이 있어 관련 작업 항목(Related work items) 분기를 많이 쓰는 규칙일수록 이 한계에 쉽게 도달합니다.
Data Center는 이러한 “월간 실행 횟수 과금 한도” 개념 자체가 없습니다(별도 라이선스가 없기 때문). 대신 인스턴스 성능 보호를 위한 큐 기반 처리 한도가 존재하는데, DC 자체 인프라 자원(노드 수, 스레드, DB 성능)에 따라 실질적인 처리량이 좌우되는 구조입니다.
시크릿(secret) 관리 Data Center의 Automation은 외부 서비스로 나가는 요청에 사용할 URL과 시크릿 값을 중앙에서 관리할 수 있는 Secret keys 패널을 자체적으로 제공합니다. 이 패널이 도입된 이후로 웹훅 대상 URL이나 인증값을 규칙 안에 평문으로 노출하지 않고 참조하는 방식이 지원됩니다.
Cloud에는 이에 대응하는 자동화 전용 시크릿 마스킹 UI가 별도로 안내되어 있지 않으며, Send web request 액션을 사용할 때 인증 토큰을 스마트 값(smart value)이나 헤더에 직접 넣는 방식의 활용 가이드가 공식 문서에 제공됩니다. 예를 들어 Jira REST API를 호출하기 위해 개인용 액세스 토큰(Personal Access Token)을 발급해 헤더에 담아 호출하는 방법이 공식 자료로 안내됩니다.
리스너와 웹훅 Jira Data Center와 Server에서는 외부 시스템에 이벤트를 전달하기 위한 방식으로 리스너(listener) 인터페이스가 쓰였지만, Cloud에서는 리스너 설정 자체가 불가능하며 이를 대체하는 방식으로 웹훅을 사용해야 합니다. 최신 버전의 Data Center에서도 리스너보다 웹훅 방식이 권장됩니다.
Assets/자산 관리 자동화 Jira Service Management의 자산(Assets) 관리 기능에서는 Cloud와 DC 간 객체 스키마 템플릿, 서드파티 도구 연동, 일부 대량 작업(bulk action), Groovy 스크립트를 통한 자동화 확장 가능 여부 등에서 차이가 있습니다.
Cloud Cloud 자동화의 감사 로그는 90일 동안 저장되며, 이 기간이 지난 항목은 삭제되어 복구할 수 없습니다.
Data Center Data Center의 감사 로그(Jira 8.8, Confluence 7.5, Bitbucket 7.0 이상 기준)는 보존 기간을 관리자가 일/월/년 단위로 세밀하게 직접 설정할 수 있으며, 이전 버전에서 마이그레이션한 경우 기본값은 20년, 신규 설치의 경우 3년입니다. 다만 보존 기간을 길게 설정할수록 데이터베이스 크기와 인스턴스 성능에 영향을 줄 수 있어, 장기 보관이 필요하다면 Splunk 같은 외부 로그 도구와의 연동이 권장됩니다. DC는 감사 이벤트를 데이터베이스뿐 아니라 로컬 홈 디렉터리의 로그 파일로도 기록하며, 노드별로 파일이 보존 한도(기본 100개, 현재 파일 포함)에 도달하면 가장 오래된 파일부터 삭제됩니다.
즉, Cloud는 고정된 90일 보존이라는 단순한 구조인 반면, DC는 관리자가 보존 기간과 저장 방식(DB/파일/외부 연동)을 직접 설계해야 하는 대신 훨씬 유연합니다.
Cloud 자동화는 Atlassian의 Forge 플랫폼을 통해 개발자가 커스텀 자동화 액션을 직접 만들 수 있는 확장 경로를 제공합니다. Forge는 Jira/Confluence Cloud 앱을 만들기 위한 Atlassian의 개발 플랫폼이며, 2025년 9월 17일부터는 신규 마켓플레이스 앱이 오직 Forge로만 제출 가능해졌고, 앞으로의 모든 신규 확장 기능은 Forge로만 제공됩니다.
Data Center 쪽 자동화 액션 문서에서도 마켓플레이스 앱이 기여하는 서드파티 액션의 존재를 확인할 수 있으며, Send web request 액션과 Slack/Teams/Twilio 등에 대한 네이티브 알림 액션을 통해 아웃바운드 연동을 구성하는 구조 자체는 Cloud와 유사합니다.
| 구분 | Data Center | Cloud |
|---|---|---|
| 제공 방식 | 제품에 내장, 별도 라이선스 없음 (8.0+) | 요금제(Free/Standard/Premium/Enterprise)에 연동, 조직 단위 사용량 기반 스텝 과금 |
| 프로젝트 관리자 권한 위임 | 그룹 단위 제한 가능, 미허용 시 읽기 전용 뷰 제공 | 그룹 단위 제한 가능(Global configuration) |
| 실행 계정(Flow Actor) | 문서상 별도 개념 문서화 없음 | 전역 관리자는 임의 사용자, 프로젝트 관리자는 자신/Automation 사용자로 제한 |
| 처리 한도 | 인스턴스 자원에 따른 큐 기반 처리 한도 | Usage limit(월간) + Service limit(실행당) 이중 구조 |
| 시크릿 관리 | Secret keys 패널 내장 | 별도 마스킹 UI 없음, 토큰/헤더 직접 구성 안내 |
| 리스너 | 지원(단, 웹훅 권장) | 미지원, 웹훅으로 대체 |
| 감사 로그 보존 | 관리자가 일/월/년 단위로 설정(기본 3년 또는 20년) | 고정 90일 |
| 확장 | Marketplace 서드파티 액션 | Forge 기반 커스텀 액션 |
DC와 Cloud 자동화는 겉보기엔 같은 UI, 같은 트리거·조건·액션 개념을 쓰지만, 실제로는 “인스턴스를 직접 운영하며 자원과 보존 정책을 스스로 설계하는 모델”과 “관리형 서비스로서 사용량과 요금제에 묶여 있는 모델”이라는 서로 다른 전제를 깔고 있습니다. 마이그레이션이나 이중 운영을 고려하고 있다면, 특히 시크릿 관리, 감사 로그 보존, 월간 사용량 한도 세 가지 지점에서 실제 운영 정책을 다시 점검해볼 필요가 있습니다.
