---
title: "Jira는 튜링 완전하다: Atlassian Automation으로 민스키 머신 만들기"
published: 2026-05-25T03:54:14.000Z
canonical: https://jeff.news/article/3276
---
# Jira는 튜링 완전하다: Atlassian Automation으로 민스키 머신 만들기

한 개발자가 Jira Automation으로 2카운터 민스키 머신을 구현해 Jira가 튜링 완전하다는 주장을 실제 구성과 실행 추적으로 증명했다. 에픽 상태를 명령 포인터로 쓰고, 연결된 이슈 개수를 레지스터로 쓰며, 이슈 생성·삭제·전환으로 INC, DEC, 분기를 흉내 낸다.

## Jira로 민스키 머신을 만든다는 정신 나간 증명

- “Jira는 튜링 완전하다”는 개발자 농담이 실제 증명으로 나옴
  - 글쓴이는 Atlassian Automation 위에 민스키 레지스터 머신(Minsky register machine)을 구성함
  - 단순 주장이나 밈이 아니라 설정 방법과 실행 추적까지 제시함
  - 결론은 꽤 깔끔함. Jira 자동화로 2카운터 머신을 구현할 수 있으면, 민스키의 1967년 증명에 따라 튜링 완전하다는 것

- 민스키 머신은 생각보다 단순함
  - 필요한 건 무한히 커질 수 있는 카운터 2개와 라벨이 붙은 유한한 명령 집합
  - 명령은 `INC r; goto S` 또는 `if r == 0 goto S else (DEC r; goto S')` 정도면 됨
  - 예를 들어 A를 B에 더하는 프로그램은 A가 0이 될 때까지 A를 줄이고 B를 늘리는 루프임

- 이 추상 기계를 Jira에 매핑하는 방식이 이 글의 핵심임
  - 에픽의 상태가 현재 실행 중인 명령을 나타냄
  - 연결된 이슈 개수가 레지스터 값이 됨
  - `INC`는 이슈 생성, `DEC`는 연결 이슈 삭제로 구현함
  - 조건 분기는 JQL 조건이 붙은 자동화 규칙으로 처리함

```mermaid
sequenceDiagram
    participant 에픽상태
    participant 자동화규칙
    participant 연결이슈
    participant JQL조건
    participant 다음상태
    에픽상태->>자동화규칙: 현재 명령 상태 진입
    자동화규칙->>JQL조건: 연결 이슈 개수 검사
    JQL조건->>연결이슈: 0 여부 확인
    연결이슈->>자동화규칙: 생성 또는 삭제 실행
    자동화규칙->>다음상태: 다음 명령 상태로 전환
```

## 2+3=5를 Jira 에픽 하나로 계산하기

- 최소 구현은 에픽 하나, 연결 이슈 5개, 명령 상태마다 자동화 규칙 하나로 돌아감
  - 워크플로에는 `BACKLOG`, `TODO`, `DEV`, `PROD` 상태를 만듦
  - 어떤 상태에서도 어떤 상태로든 전환할 수 있게 설정함
  - 시작 에픽은 `BACKLOG` 상태에 둠

- 덧셈 머신은 두 규칙으로 구성됨
  - `TODO`: A가 0이면 3번으로 가고, 아니면 A를 하나 줄인 뒤 2번으로 감
  - `DEV`: B를 하나 늘린 뒤 다시 `TODO`로 감
  - 두 규칙 모두 “다른 규칙을 트리거하도록 허용” 옵션을 켬

- 초기 레지스터는 연결 이슈 타입으로 표현함
  - Bug 2개를 연결해서 A=2
  - Task 3개를 연결해서 B=3
  - 에픽을 `TODO`로 전환하면 자동화 연쇄가 시작됨

- 실제 실행 추적도 제시돼 있음
  - `(2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD`
  - 최종적으로 에픽은 `PROD`에 도착하고 Bug는 0개, Task는 5개가 연결됨
  - 즉 Jira가 2+3=5를 계산한 셈. 웃기지만 진짜임

> [!IMPORTANT]
> 이 증명에서 중요한 건 Jira가 덧셈을 했다는 사실이 아니라, 조건 분기와 카운터 증감으로 일반 계산 모델을 흉내 낼 수 있다는 점임.

## Convert Issue Type으로 피보나치까지 감

- Jira의 `Convert Issue Type` 기능은 계산 모델을 더 짧게 만드는 축약 연산처럼 쓰임
  - Bug를 Story로, Story를 Task로 즉시 바꿀 수 있음
  - 이건 이론적으로는 `DEC + INC`로 표현 가능한 동작이라 계산 능력을 더 늘리지는 않음
  - 대신 이동 루프의 상태 수를 크게 줄여서 더 복잡한 프로그램을 짜기 쉬워짐

- 글쓴이는 피보나치 변환 `(A, B) → (B, A+B)`도 구성함
  - 레지스터는 A=Bug, B=Task, C=Story
  - 상태는 `TODO`, `QA`, `DEV` 세 개를 사용함
  - 초기 상태는 A=1, B=1, C=0
  - 결과적으로 B, 즉 Task 개수에 1, 1, 2, 3, 5, 8, 13 같은 피보나치 수열이 나타남

- 단, Jira Cloud에는 현실적인 제한이 있음
  - 자동화 체인 깊이 제한이 10이라 무한히 계속 돌지는 못함
  - 그래서 피보나치 머신은 중간에 멈추고, 운영자가 에픽을 다시 트리거하면 이어서 진행됨
  - 글쓴이는 “사람이 다음 클록 틱을 넣어주는 것”이라고 설명함

## 그래서 진짜 튜링 완전하냐

- 글쓴이의 입장은 “표준적인 관점에서는 그렇다”임
  - Jira Automation은 무한한 이슈 생성과 무한한 규칙 실행을 가정하면 2카운터 머신을 인코딩할 수 있음
  - Jira Cloud의 쿼터와 체인 제한은 현실 컴퓨터의 메모리 제한과 비슷한 물리적 제약으로 봄
  - 모든 실제 컴퓨터도 유한하므로, 그런 제약만으로 튜링 완전성 주장을 반박할 수는 없다는 논리임

- 이 글이 실무적으로 찌르는 지점도 꽤 큼
  - Jira 자동화가 복잡해지면 그냥 설정 몇 개가 아니라 프로그램이 됨
  - 상태, 조건, 반복, 부작용, 실행 제한을 다 다뤄야 함
  - 그래서 복잡한 Jira 자동화가 코드처럼 느껴진다면, 실제로 코드와 비슷한 성질을 갖고 있기 때문임

---

## 기술 맥락

- 이 글의 기술적 선택은 튜링 완전성을 직접 보이기 위해 민스키 머신을 고른 거예요. 민스키 머신은 명령어가 매우 작아서 Jira 같은 자동화 시스템에 매핑하기 좋거든요.

- 에픽 상태를 명령 포인터로 쓰는 것도 영리해요. 일반 프로그램에서 현재 실행 위치가 필요하듯이, Jira에서는 워크플로 상태가 그 역할을 해요. 상태 전환이 곧 다음 명령으로 점프하는 동작이 되는 거죠.

- 연결 이슈 개수를 레지스터로 삼은 이유는 Jira가 이슈 생성, 삭제, 검색을 기본 기능으로 제공하기 때문이에요. Bug가 몇 개 연결됐는지 세면 카운터가 되고, 이슈를 하나 만들거나 지우면 INC와 DEC가 돼요.

- JQL 조건은 분기문 역할을 해요. 특정 타입의 연결 이슈가 있는지 검사해서 0이면 한 상태로, 아니면 이슈를 줄이고 다른 상태로 가는 식이에요. 그래서 자동화 규칙이 단순 트리거가 아니라 제어 흐름을 가진 프로그램처럼 바뀌어요.

## 핵심 포인트

- 민스키 레지스터 머신은 두 개의 무한 카운터와 유한한 명령 집합만으로 튜링 완전함이 증명된 계산 모델
- Jira에서는 에픽 상태가 현재 명령, 연결 이슈 개수가 레지스터, 자동화 규칙이 명령 실행을 담당
- Bug 2개와 Task 3개를 연결한 에픽으로 2+3=5 덧셈 머신을 실제 Atlassian 인스턴스에서 실행
- Jira의 Convert Issue Type 기능은 DEC+INC를 한 번에 줄이는 축약 연산처럼 써서 피보나치 머신도 구성 가능
- Jira Cloud에는 자동화 체인 깊이 제한 10이 있지만, 물리 컴퓨터도 유한하다는 표준 관점에서는 튜링 완전성 주장을 깨지 않음

## 인사이트

이 글은 농담처럼 시작하지만 자동화 도구가 어느 순간 ‘설정’이 아니라 ‘프로그래밍 언어’가 되는 지점을 정확히 찌른다. Jira 자동화가 복잡해질수록 왜 유지보수가 코드만큼 어려워지는지 꽤 우아하게 보여준다.