Jira는 튜링 완전하다: Atlassian Automation으로 민스키 머신 만들기

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 조건이 붙은 자동화 규칙으로 처리함

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를 계산한 셈. 웃기지만 진짜임

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이면 한 상태로, 아니면 이슈를 줄이고 다른 상태로 가는 식이에요. 그래서 자동화 규칙이 단순 트리거가 아니라 제어 흐름을 가진 프로그램처럼 바뀌어요.