Jira Automation으로 반복 업무를 효율적으로 관리해보자

16 hours ago 1

들어가며

Jira는 Atlassian의 대표적인 이슈 추적 및 프로젝트 관리 도구입니다. 대다수의 조직에서는 Jira를 활용해 이슈를 추적하고 프로젝트의 계획부터 관리까지 수행합니다. Jira의 강력한 필터 검색, 워크 로그 기반의 업무 현황 파악, 스프린트 연동을 통한 일정 관리 기능은 업무 생산성을 크게 향상시킵니다. 또한 Rich Filter로 대시보드를 구성하거나 BigPicture로 리소스를 관리하는 등, 다양한 앱과 플러그인을 연동하여 필요한 기능을 얼마든지 확장할 수 있습니다.

하지만 Jira의 기능을 제대로 활용하려면, ‘티켓’이라 불리는 개별 작업 단위에 정확한 정보가 충분히 입력되어야 합니다. 데이터가 많을수록 지표의 정확도와 활용도가 높아지기 때문입니다.
그러나 정보는 저절로 쌓이지 않습니다. 누군가 지속적으로 티켓의 상태를 업데이트하고 관련 정보를 입력해야만 합니다. 관리할 티켓과 입력 필드가 늘어날수록 이 작업은 점점 부담이 되고, 결국 정보가 누락되는 문제로 이어지기도 합니다.

이처럼 Jira는 강력한 기능을 제공하는 반면, 이 기능들을 제대로 활용하기 위한 반복적인 입력과 관리는 오히려 업무 부담으로 작용하기도 합니다.
결국 이러한 관리 비용을 줄이고 데이터 누락을 방지하기 위해, 사람이 직접 하던 작업을 자동으로 처리해 줄 방법을 모색하게 되었습니다. 그중 가장 실용적인 도구가 바로 Jira Automation입니다.

이 글에서는 Jira Automation이 어떤 도구인지 알아보고, 실제 업무에 어떻게 적용할 수 있는지에 대한 사례를 공유합니다. 나아가, 직접 REST API를 활용하는 서버를 구축하는 방식과 비교했을 때 어떤 장단점이 있는지도 함께 살펴보겠습니다.

Jira Automation에 대하여

Jira Automation은 Atlassian에서 제공하는, 코드 없이 사용할 수 있는 자동화 도구입니다. 이 기능을 통해 반복적이거나 연관된 작업들을 자동화하여 중요한 업무에 더 집중할 수 있습니다.

사내에서는 Jira Cloud를 사용하고 있는데, 여기에는 이 기능이 기본적으로 내장되어 있습니다. 대부분의 경우 이 버전의 Jira를 사용하시겠지만, Jira Data Center와 같은 셀프 호스팅 서비스를 활용 중이라면 Marketplace의 Automation for Jira 앱을 통해 이러한 자동화를 구현할 수 있습니다. Jira Automation은 이슈 생성, 필드 값 변경, 상태 전환, 일정 예약과 같은 이벤트를 감지하여 미리 설정된 작업을 자동으로 수행하는 이벤트 기반 자동화 시스템입니다. 간단하고 직관적인 규칙 빌더를 통해 누구나 쉽게 자동화 규칙을 만들 수 있으며, 별도의 서버나 개발 없이 즉시 구현하고 테스트 및 실행할 수 있다는 장점이 있습니다.

Jira Automation을 활용하게 된 이유

다른 많은 기업과 같이 우아한형제들에서도 업무 관리 도구로 Jira를 사용하고 있습니다.
기존에도 Jira의 티켓을 업무의 단위로 활용하고 있었고, 업무가 종료되는 시점에는 상태를 완료로 변경하고 프로젝트별 릴리스를 생성하여 수정 버전에 명시하는 등 기본적인 과제 진행의 단계를 표현하는 데에 무리 없이 활용하고 있었습니다.

하지만 조금 아쉬웠던 부분은 해당 업무에 깊게 관여하지 않은 경우 티켓만으로는 업무의 진행 정도와 리소스 투입 현황, 범위와 크기를 파악하기 어렵다는 점이었습니다.
때문에 팀에서는 개발 단계에 따라 적절한 필드에 값을 채워 일의 진행과 더불어 어느 정도의 규모의 업무인지 외부에서도 파악할 수 있게 하는 한편, 실제 업무에 투입된 리소스까지 파악할 수 있도록 하고자 하였습니다.

담당자로 지정된 업무를 리뷰한 후 업무량을 산정하여 Story Points를 기입
- Story Points는 내부 배수 로직에 따라 절대적인 시간으로 바꾸어 최초 추정치 값으로 설정
업무 시작 시점 아래 필드를 기입하고 상태를 진행 중으로 변경
- 시작일(Start Date)
- 활성화된 스프린트 연동
업무를 진행하는 동안 사용한 시간을 워크로그에 기입
배포일이 결정되면 Jira 티켓의 기한(Due Date)에 날짜 기입 및 해당 날짜의 릴리스를 생성하고 티켓과 연동
작업이 완료되면 상태를 완료로 변경
- 배포일보다 먼저 개발 완료된 경우 종료일(End Date)은 완료 날짜를 기준으로 기입

이렇게 자세하게 티켓에 값을 기입하게 되면서 일이 진행되고 있는 중에도 일이 언제부터 언제까지 진행되는지와 현재 진행 상태, 그리고 과제를 처리하기 위해서 투입된 시간을 외부에서도 파악하기가 편해졌습니다. 하지만 과제를 진행하는 중간에 기입해야 하는 필드들이 상당히 늘어나게 되었고, 업무 진행 간 맥락이 변경되어 집중에 오히려 방해가 되는 문제가 발생하였습니다.

특히 ‘티켓 관리’ 자체가 또 하나의 업무처럼 여겨지면서 팀원들의 부담감이 커지고 집중을 흩트리게 되는 것이 가장 큰 문제였습니다.
이러한 문제점을 해결하기 위해, 최소한의 노력으로 필드 값을 자동으로 채우고 반복 작업을 줄이며, 필수 필드를 누락하지 않도록 Jira Automation(자동화) 기능을 도입하게 되었습니다.

Jira Automation의 흐름

Jira Automation은 세 가지의 핵심 요소로 이루어져 있습니다. 바로 자동화를 시작하는 이벤트(Trigger)가 발생하면 조건이 일치하는지(Condition) 검사하고, 동작을 수행(Action)한다는 것입니다. Jira Automation에서는 이러한 것을 규칙(Rule)으로 정의할 수 있습니다. 이 규칙은 일상생활에서의 규칙과 크게 다르지 않은데, 예를 들어 “현관문이 열렸을 때(Trigger) 밝기가 어둡다면(Condition) 거실 등을 켜줘(Action)”와 같은 문장도 하나의 규칙이 될 수 있습니다.

트리거(Trigger): 자동화 규칙의 실행을 유발하는 이벤트입니다. 이슈 생성, 필드 값 변경, 상태 변경, 예약 시간 등이 트리거가 될 수 있습니다.
조건(Condition): 규칙의 실행 범위를 좁히는 역할을 합니다. if 문과 같이 특정 필드의 값이 충족되는 경우에만 동작하게 하거나, JQL 쿼리로 조건을 통과한 경우에만 후속 작업을 실행하게 할 수도 있습니다.
동작(Action): 실제로 수행되는 자동화 작업입니다. 이슈 할당, 상태 변경 등 기본적으로 우리가 Jira 티켓에 수행할 수 있는 대부분의 동작을 수행할 수 있고, 이에 대한 알림도 전송할 수 있습니다.

Jira Automation 설정 방법

간단한 자동화를 만들어 보면서 설정 방법을 소개해 보려고 합니다.
티켓의 상태가 ‘완료’가 될 시 종료일(End Date) 필드를 현재 날짜로 자동으로 채워주고, 이때 기한(Due Date)이 비어있다면 기한도 같은 날짜로 채워주는 자동화를 만들어 보려고 합니다. 실제로 팀 내에서도 사용하고 있는 자동화 기능이며, 필드의 이름은 조직의 방침에 따라 조금씩 다를 수 있습니다.

프로젝트 설정에서 자동화 탭으로 이동합니다. 만일 자동화 탭이 보이지 않는다면 권한 문제일 수 있습니다. 관리자에게 문의하여 권한을 획득하여야 합니다.
규칙 만들기를 클릭하여 새로운 자동화 규칙을 생성합니다. 이때 처음부터 모든 단계를 구성할 것인지, 템플릿 기반으로 생성할 것인지 선택할 수 있습니다. 템플릿에는 여러 기본적인 트리거, 조건, 동작들이 사전 구성되어 있으며 이를 기반으로 추가 동작을 구현할 수도 있습니다. 여기서는 모든 단계들을 구성하는 것으로 가정하겠습니다.
규칙을 실행할 트리거 이벤트를 설정합니다. 지금은 상태가 완료로 변경된 경우를 트리거로 하고 싶기 때문에 필드 값이 변경됨을 선택하고, 상태에 대한 모니터링 조건을 추가합니다. 또한 조건 추가를 선택하여 업무 항목 필드 조건에 이 상태가 완료로 될 때만 동작하도록 설정합니다. 이 조건은 따로 분리하여 조건 분기를 할 수도 있지만, 트리거 내에서도 간단하게 설정할 수 있습니다.
다음은 티켓의 종료일을 설정하는 단계입니다. 종료일은 ‘업무 항목 편집’ 액션에서 설정할 수 있습니다. 만약 현재 시간을 기준으로 날짜를 지정하고 싶다면, Jira에서 제공하는 Smart Value를 활용할 수 있습니다. Smart Value는 이슈의 기존 정보를 가져오거나 수학적 표현식, 조건문 등을 코드처럼 사용하여 자동화 규칙을 더욱 강력하게 만들어주는 기능입니다. 이 부분은 뒤에서 더 자세히 다루겠습니다.
여기서 유의할 점은, 규칙이 실행되는 맥락(context)에 따라 사용할 수 있는 Smart Value가 다르다는 것입니다. 또한, 조직이나 프로젝트에서 직접 추가한 커스텀 필드(Custom field)는 어떤 키(key)로 접근해야 하는지 사전에 확인해야 합니다.
이번 단계에서는 날짜 및 시간(Date and Time) 관련 Smart Value 중, 현재 시점을 의미하는 {{now}}를 사용합니다. 이 값은 기본적으로 UTC(협정 세계시)를 반환하며, 필요에 따라 형식을 변환(formatting)하여 사용할 수 있습니다. 예를 들어 {{now.jiraDate}}와 같이 사용하면, Jira의 기본 날짜 형식인 YYYY-MM-DD로 자동 변환됩니다.
다음은 기한(Due date)을 설정할 차례입니다.
저희 팀에서는 보통 다른 자동화 규칙을 통해 티켓의 기한을 미리 입력해 둡니다. 하지만 간혹 이 값이 비어 있는 채로 티켓이 처리될 때가 있습니다. 지금 만들 규칙은 바로 이처럼 기한이 설정되지 않은 경우에만 현재 날짜를 기한으로 입력해 주는 보완적인 역할을 합니다. 이를 구현하려면 조건 분기가 필요합니다. Jira Automation의 ‘업무 항목 필드 조건’을 사용하여 ‘기한 필드가 비어 있다’는 조건을 추가하면, 해당 조건을 만족하는 이슈에만 다음 단계를 실행하도록 설정할 수 있습니다.
위의 조건을 통과한 경우 기한 값을 설정해 주는 단계를 만들어야 합니다. 위에서 종료일을 설정해 준 것과 동일하게 이번에는 기한 값을 설정해 줍니다.

마지막으로 ‘규칙 활성화’를 클릭하여 규칙을 적용하면 모든 설정이 끝납니다.

이제부터 프로젝트 내 이슈가 ‘완료’ 상태로 전환될 때마다, 설정한 자동화 규칙이 동작하여 티켓의 종료일을 자동으로 채워줍니다. 또한, 만약 기한 필드가 비어 있다면 해당 필드 역시 오늘 날짜로 채워주게 됩니다.

Smart Value

앞서 잠시 언급했던 Smart Value를 조금 더 자세히 알아보겠습니다.
간단한 자동화는 Jira Automation UI의 드롭다운 메뉴에서 값을 선택하는 것만으로도 충분히 만들 수 있습니다. 하지만 더 세분화된 조건과 동작을 구현하려면, 티켓의 특정 필드 값에 직접 접근하거나 수학적 연산 및 비교가 필요할 때가 있습니다. 바로 이럴 때 Smart Value를 사용합니다.
Smart Value는 두 개의 중괄호({{ }})로 감싸서 표기하며, 괄호 안의 내용은 Jira가 참조할 수 있는 일종의 변수처럼 작동합니다.

이에 대한 더 자세한 내용은 Atlassian의 Smart values in Jira automation 공식 문서에서 확인할 수 있습니다. 여기서는 자주 사용되는 몇 가지 예시를 소개해 드리겠습니다.

기본적인 Smart Value

{{issue.summary}}: 이슈 제목을 가져옵니다.
{{issue.assignee.displayName}}: 담당자 이름을 가져옵니다.
{{issue.key}}: 이슈 키를 가져옵니다.

수학 함수 활용

{{#=}}3.2 * {{issue.customfield_10001}} + 43{{/}}: 시작, 끝 태그를 활용한 수학적인 계산을 할 수 있습니다. (여기서 customfield_10001은 integer값이어야 합니다.)
{{now.plusBusinessDays(issue.Story Points.multiply(3))}}: Story Points에 설정된 값에 3을 곱한 수치를 현재 설정된 시간보다 영업일 기준으로 더하는 기능으로, plus, divide, minus도 사용 가능합니다.

조건부 함수

{{#if}}{{issue.priority.name.eq("High")}}우선순위높음{{/}}: if문을 사용하여 조건부 처리를 할 수 있습니다.

시간 관련 함수

{{now.isAfter(issue.created)}}: 이슈 생성일자가 지금보다 이전인지 확인합니다. isBefore, isEquals로 다른 기준으로 확인 가능합니다.
{{now.plusWeeks(3)}}: 현재 시간에서 3주를 더합니다. 시간 단위별로 메서드가 따로 존재합니다.

JSON 함수

{{issue.summary.asJsonObject("title")}}: 이슈의 제목을 { “title”: “이슈의 제목” } 형태와 같이 JSON 형식으로 변환합니다.
{{xmlToJson(webResponse.body)}}: ‘웹 요청 전송’을 활용하는 경우 그에 대한 응답을 webResponse 형태로 받아 사용할 수 있습니다. 이때 응답이 xml 형식으로 들어온 경우 JSON으로 변환하여 활용할 수 있게 바꿀 수 있습니다.

이외에도 수많은 기능들을 제공하여 자동화에 활용할 수 있도록 지원하고 있습니다.

팀에서 활용 중인 자동화 설정들

아래는 현재 저희 팀에서 사용 중인 자동화 규칙 목록입니다.

이러한 규칙들을 업무 전반이나 각 업무 단계에 맞게 활용하고 있습니다. 기본적인 티켓의 상태만을 관리하더라도 나머지 필드들이 자동으로 기입되는 것을 목표로 하였습니다. Jira를 활용하면서 가장 번거로운 부분인 날짜 관련된 값에 대한 자동화를 지원하여 값을 직접 기입하지 않고 상태 변경을 위한 단순 클릭만으로도 필드들이 채워지게 되었습니다.

자동화 규칙을 만들 때, 여러 기능을 하나의 규칙에 모두 담을 수도 있습니다. 하지만 저희는 ‘하나의 규칙은 하나의 역할만 수행한다’ 는 원칙을 따르고 있습니다.
이는 소프트웨어 개발의 ‘단일 책임 원칙(Single Responsibility Principle)’과 같은 맥락입니다. 규칙이 복잡해질수록 사소한 변경도 어려워지고, 문제가 생겼을 때 어디를 고쳐야 할지 파악하기 힘들어집니다. 수정으로 인한 ‘부수 효과(Side Effect)’의 범위도 커지게 됩니다.
물론 규칙을 기능별로 나누면, 한 자동화가 다른 자동화를 순차적으로 실행시켜야 하는 상황이 생깁니다. 이 경우, 아래 옵션을 체크하여 규칙 간의 연쇄 실행을 허용할 수 있습니다. (이 옵션은 자동화 -> 규칙 세부 정보 내에 있습니다)

주의할 점은, 다른 자동화를 트리거할 때 서로 순환 참조가 없도록 해야 합니다. (서로가 서로를 트리거 하여 계속 자동화가 실행됩니다.)

Jira Automation에서 웹 요청 활용하기

여기서는 모든 자동화 규칙을 다루는 대신, 활용도가 높은 ‘웹 요청 보내기(Send web request)’ 액션을 이용한 실용적인 예시 하나를 소개합니다.

기한이 지난 이슈에 대해서 Slack 메신저 메시지 알림 보내기

회사 생활에서 동시에 여러 업무를 진행하는 경험은 다들 해보셨을 것입니다. 한 번에 모든 업무를 병렬적으로 진행하는 경우도 있겠지만, 우선순위에 따라 순차적으로 진행할 때도 있습니다. 이런 경우 특정 업무에 집중하느라 다른 업무의 존재를 잠시 잊거나, 실제로 업무는 정상적으로 진행했지만 티켓의 완료 처리를 하지 않는 경우가 발생하기도 합니다.
이런 부분을 보완하기 위해서 매주 한 번 기한이 지난 티켓에 대해서 담당자에게 메신저 알림을 통해 알려주는 자동화를 운영하고 있습니다.

사내 메신저로 Slack을 사용하지만, 이 방식은 웹훅(Webhook)을 지원하는 모든 서비스(다른 메신저, 사내 시스템 등)에 동일하게 적용할 수 있습니다. 아래 예시를 통해 어떤 방식으로 동작하는지 이해하고 나면, 각 조직의 상황에 맞게 기한이 지나기 며칠 전에 알림을 보낸다거나, 추가적인 조건으로 기한이 지나기 3일 전인데 아직 상태가 해야 할 일(To do)인 경우와 같이 좀 더 세부적이고 고도화된 조건을 더해 운영할 수도 있습니다.
이 자동화가 동작하는 과정을 도식화하면 아래와 같습니다.

수요일 오전 10시 반이라는 예약 트리거를 기반으로 기한이 지난 이슈를 필터링합니다.
Slack 메신저는 사용자 정보를 고유한 ID 값으로 매핑합니다. 이를 얻어오기 위해 각 이슈의 담당자 정보를 Smart Value로 가져옵니다. Slack 메신저의 ID를 조회할 수 있는 이메일 값을 가져오기 위함입니다.
Slack 앱에 사용자에게 보낼 정보를 정리하여 메시지 전송을 요청합니다.

이 과정에서 사용자 정보와 이메일 정보, DM(Direct Message)를 보낼 수 있는 권한을 가진 Slack 앱이 필요합니다. 이 부분은 각 조직에서 권한을 어떻게 관리하느냐에 따라 다르지만, 해당 권한이 있어야 메시지를 전송할 수 있습니다.

이 동작을 자동화로 구현하면 아래 세 단계로 간단히 표현할 수 있습니다.

한 단계씩 구현 내용을 보도록 하겠습니다.

트리거와 조건

트리거는 ‘예약됨(Scheduled)’ 트리거를 사용합니다. 이 트리거를 사용하면 원하는 시작일, 실행 주기, 빈도 등을 자유롭게 설정할 수 있습니다.
또한, 이 트리거에는 JQL(Jira Query Language)을 이용한 조건식을 추가할 수 있습니다. 이번 자동화의 목적은 기한이 지난 모든 티켓을 찾아 담당자에게 알림을 보내는 것이므로, 아래와 같이 JQL을 설정하여 검색 대상을 지정합니다.

JQL 쿼리의 각 필드명은 조직마다 다를 수 있습니다. 원하시는 목적에 맞는 필드로 설정 후 우측 하단에 위치한 ‘쿼리 확인’ 버튼을 통해 내가 작성한 쿼리가 의도한 결과를 올바르게 찾아내는지 미리 확인할 수 있습니다.

담당자의 Slack ID 가져오기

Slack 연동을 위해서는 사전 준비가 필요합니다. 이 글에서 Slack 앱을 만드는 방법을 자세히 다루지는 않지만, 과정은 간단합니다. 코드 개발 없이 몇 번의 클릭과 정보 입력만으로 앱을 만들 수 있습니다.

앱을 만든 후에는 다음 두 가지가 필요합니다.

권한 할당: 생성한 앱에 메시지 전송 등 필요한 권한을 부여해야 합니다.
Bot 토큰 확인: 앱 생성 시 발급되는 xoxb-로 시작하는 ‘Bot User OAuth Token’을 복사해 둡니다. 이 토큰은 잠시 후 Jira에서 Slack API를 호출할 때 인증 정보(Authorization header)로 사용됩니다.

Jira 이슈 담당자에게 Slack 메시지를 보내려면, 먼저 해당 담당자의 Slack User ID를 알아내야 합니다. Slack의 users.lookupByEmail API를 이용하면 이메일 주소로 User ID를 조회할 수 있습니다.

https://slack.com/api/users.lookupByEmail?email={{issue.assignee.emailAddress}}

여기서 {{issue.assignee.emailAddress}}는 Jira의 Smart Value로, 현재 이슈 담당자의 이메일 주소를 동적으로 가져오는 역할을 합니다. 자동화 설정 화면에는 아래처럼 이 URL을 입력하면 됩니다.

유의할 점은 여기서 받아온 응답을 활용하여 다음 동작을 해야 하기 때문에 요청 응답 수신까지 다음 작업을 대기하는 과정이 필요합니다.

Slack 앱을 통해 DM 보내기

이제 마지막으로, 조회한 담당자에게 실제 메시지를 보내는 단계를 설정합니다.
이 기능은 Slack의 chat.postMessage API를 통해 구현할 수 있습니다. 이 API는 POST 방식으로 호출해야 하며, 요청 헤더(Header)에는 다음 두 가지 정보가 포함되어야 합니다.

Authorization: 이전 단계에서 준비한 Slack Bot 토큰 (xoxb-...)
Content-Type: application/json

이 헤더 정보는 요청 본문(Body)이 JSON 형식임을 서버에 알려주는 역할을 합니다.

마지막으로, API 요청 본문(사용자 정의 데이터)에 보낼 메시지 내용을 작성합니다.
가장 중요한 channel 필드에는 메시지를 받을 대상의 Slack User ID가 들어가야 합니다. 이 값은 이전 단계에서 users.lookupByEmail API를 호출하여 얻은 결과에 포함되어 있습니다.
Jira의 {{webResponse.body.user.id}} Smart Value를 사용하면, 이전 API 호출 응답(JSON)에서 사용자의 ID 값을 정확히 추출하여 channel 값으로 넣을 수 있습니다.
메시지 내용은 text 필드에 자유롭게 작성하면 됩니다. Slack의 postMessage API는 블록 킷(Block Kit)도 지원하므로, 원한다면 더 풍부한 형식의 메시지를 보낼 수도 있습니다. (만약 다른 메신저 API를 사용한다면, 그에 맞는 요청 양식을 따르면 됩니다.)

Jira Automation vs 서버 운영 방식의 비교

Jira Automation은 코드 없이(No-code) 쓸 수 있는 자동화 도구입니다. 자동화 규칙을 쉽게 만들 수 있고, 별도의 개발이나 배포 과정이 필요 없어 생성, 수정, 삭제가 매우 빠르고 간편합니다. 하지만 이런 편리함 이면에는 분명한 한계도 존재합니다.

만약 이 글을 읽는 독자께서 개발자라면, Jira의 REST API를 활용하여 직접 서버를 구축하는 자동화 방식을 떠올리실 수도 있습니다. Atlassian은 Jira REST API를 제공하며, 이를 이용하면 Jira Automation만으로는 구현하기 어려운 더 세밀한 조건으로 데이터를 가공하거나 복잡한 로직을 구현할 수 있습니다.

두 방식은 단순히 우열을 가리기보다, 필요와 상황에 맞게 선택하는 것이 중요합니다. 개인과 조직이 원하는 자동화 수준에 맞춰 적절한 방식을 활용하면 됩니다. 이어지는 내용에서는 Jira Automation의 특징을 중심으로, 직접 서버를 운영하는 방식과 어떤 차이가 있는지 비교해 보겠습니다.

항목 Jira Automation 직접 서버 운영

개발 방식	UI 기반으로 코드 없이 구현 가능	개발 환경에 맞는 구현이 필요함
개발 난이도	직접 서버 운영하는 것 대비 난이도 낮음	Jira Automation 대비 난이도 높음
배포 속도	변경 즉시 적용으로 빠름	상대적으로 느림
트리거 방식	이벤트 기반 (비정형화된 이벤트는 웹훅으로 가능)	원하는 형태로 구현 가능
외부 시스템 변화 감지	외부에서 직접 웹훅 호출하여 트리거 가능	서버 내에서 외부 시스템 연동 후 트리거 가능
유지보수	자동화 마이그레이션 지원	개발 측에서 유지보수에 대한 책임 존재
비용	사용하는 Jira 플랜에 따라 차등 적용	개발 방식에 따라 다름
다중 조건/ 복잡한 처리	Jira에서 제공하는 정형화된 데이터 외에는 구현하기 어려움	서버 내에서 여러 조건이나 처리 구현 가능

직접 서버를 운영하여 REST API를 활용하는 방식은 Jira Automation에 비해 훨씬 자유로운 조건과 동작을 구현할 수 있습니다. 하지만 Jira가 기본으로 제공하는 자동화 기능조차 직접 구현해야 하는 노력과 비용이 들며, 자동화 통계가 필요할 경우 이 또한 별도로 만들어야 합니다.

반면 Jira Automation은 대부분의 기능을 UI 기반으로 쉽게 설정할 수 있고, 필요하다면 웹훅(Webhook)을 통해 외부 시스템의 POST 요청을 트리거로 사용하거나 전달된 정보를 활용하는 것도 가능합니다. 다만 개인적인 경험상, 복잡한 규칙의 디버깅이 쉽지 않아 고급 자동화는 오히려 직접 서버를 운영하는 편이 낫다고 생각합니다.

마지막으로 주의할 점은, 사용하는 Jira 플랜에 따라 월별 자동화 실행 횟수에 제한이 있을 수 있다는 것입니다. 자동화를 본격적으로 도입하기 전에 조직의 Jira 관리자에게 문의하여 현재 플랜에서 사용량이 충분한지 미리 확인해 보는 것이 좋습니다. (대부분의 기업용 플랜은 실행 횟수가 매우 여유롭거나 제한이 없습니다.)

마치며

자동화의 목적은 최소한의 노력으로 최대의 효율을 내는 것입니다. 저 역시 아주 간단한 규칙으로 Jira Automation을 처음 시작했습니다. 하지만 시간이 지나며 Jira Automation이 생각보다 강력하고 분명한 장점이 있는 도구라는 것을 알게 되었습니다.

"더 고도화된 시스템을 구축해야 하는 게 아닐까?" 하고 생각하실 수도 있습니다. 하지만 가장 좋은 자동화는 팀이 실제로 사용하고 유지보수할 수 있는 자동화입니다. 복잡한 서버 로직은 특정 개발자에게 의존하게 되지만, Jira Automation의 노코드 특성은 "누구나 수정할 수 있다"는 강력한 장점이 있습니다. 자동화가 팀 전체의 공유 자산이 될 수 있는 것이죠.

물론 모든 것을 한 번에 만족시키는 완벽한 해결책은 없습니다. 각자의 목적에 맞게 주어진 도구를 잘 사용하는 것이 중요합니다. Jira Automation 역시 훌륭한 도구 중 하나이며, 여러분의 목적에 부합한다면 투자 대비 확실한 효과를 보장할 것입니다.

그러니 아주 작은 것부터 시작해 보세요. 분명 예상보다 큰 변화를 경험하게 될 겁니다. 그 과정에서 더 복잡한 요구사항이 생긴다면, 그때 외부 서버나 다른 고급 자동화 도구를 검토해도 늦지 않습니다. 자동화는 목적이 아니라 수단이라는 점을 기억해 주세요.

“매일 반복되는 Jira 관리, 하루 10분을 절약할 수 있다면”

제가 처음 Jira 자동화를 시작하며 세웠던 목표입니다. 감사 로그에 기록된 자동화 실행 횟수를 보면, 수동으로 처리했을 때에 비해 얼마나 많은 시간을 아꼈는지 짐작할 수 있습니다. 이제는 여기서 더 나아가 하루 15분, 20분을 절약하는 것을 다음 목표로 삼고 있습니다.

개인의 10분은 짧아 보이지만, 팀 전체로 보면 거대한 시간이 됩니다. 무엇보다 반복 업무로 인해 끊겼던 업무의 흐름을 유지하고 집중력을 지킬 수 있다는 점에서 그 가치는 10분 이상일 것입니다.

이 글을 통해 Jira Automation이 여러분의 시간을 지켜주고, 더 중요한 일에 몰입하도록 돕는 든든한 파트너가 되기를 바랍니다.

Read Entire Article