▲

Jira는 튜링 완전하다

 (seriot.ch)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Jira Automation은 두 무한 카운터와 유한 명령 상태를 가진 Minsky 머신을 표현해 Jira의 튜링 완전성을 보일 수 있음
  • Epic 상태는 프로그램 카운터, 연결된 Bug와 Task 수는 두 레지스터가 되며, Automation 규칙이 명령별 디스패치 테이블이 됨
  • INC와 DEC는 연결 이슈 생성·삭제로 구현되고, 조건 분기는 JQL 조건 규칙으로 연결 이슈 수를 검사해 결정함
  • 덧셈 예시는 A=2, B=3에서 Bug를 줄이고 Task를 늘려 실제 *.atlassian.net 실행에서 Task 5개와 정지 상태에 도달함
  • Fibonacci 예시는 이슈 유형 변환으로 루프를 줄이며, Jira Cloud의 체인 깊이 제한 10에 닿으면 수동 재트리거로 계속 진행 가능함

Jira 자동화로 만든 Minsky 머신

  • Jira Automation은 두 개의 무한 카운터와 유한한 명령 상태를 갖는 Minsky register machine을 표현할 수 있어, Jira의 튜링 완전성을 보이는 환원이 가능함
  • Minsky가 1967년에 증명한 모델은 INC r; goto S와 if r == 0 goto S else (DEC r; goto S')만으로 구성됨
  • Jira 구성 요소는 Minsky 머신의 각 요소에 대응됨
    • Register A: 연결된 Bug 이슈 수
    • Register B: 연결된 Task 이슈 수
    • Program Counter: 단일 Epic 이슈의 상태
    • Dispatch Table: 명령 상태별 Jira Automation 규칙
    • Clock: 자동화가 트리거하는 전환 또는 체인 제한 이후 외부 재트리거
  • Epic 상태가 현재 명령을 인코딩하고, Automation rules가 연결 이슈 수를 검사해 다음 상태로 전환함
  • INC와 DEC는 해당 유형의 연결 이슈 생성과 삭제로 구현되고, 조건 분기는 JQL 조건 규칙으로 처리됨

실행 예시와 제한

  • 덧셈 프로그램은 A를 줄이면서 B를 늘리는 Minsky 프로그램으로 구성됨 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • 최소 구현은 하나의 Epic, 연결 이슈 5개, 명령 상태별 Automation 규칙 하나씩으로 구성됨

  • 워크플로와 규칙

    • Jira Workflow에 초기 상태 BACKLOG, 이후 TODO, DEV, PROD를 만들고 모든 상태가 서로 전환 가능하게 설정함
    • BACKLOG 상태의 Epic을 하나 생성함
    • TODO 규칙은 DEC A; if A=0 halt, else goto DEV를 구현함
      • Epic 상태가 TODO로 바뀌면 트리거됨
      • 연결된 Bug가 하나 이상 있으면 Bug 하나를 삭제하고 Epic을 DEV로 전환함
      • Bug가 없으면 Epic을 PROD로 전환해 정지함
    • DEV 규칙은 INC B; goto TODO를 구현함
      • Epic 상태가 DEV로 바뀌면 트리거됨
      • 새 Task를 만들고 Epic에 연결함
      • Epic을 TODO로 전환함
    • 두 규칙 모두 "Allow rule to trigger other rules"가 활성화됨

  • 초기값과 결과

    • Epic에 Bug 2개와 Task 3개를 연결해 A=2, B=3으로 초기화함
    • Epic을 TODO로 전환하면 다음 흐름으로 연쇄 실행됨 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • 실제 *.atlassian.net 인스턴스에서 실행됐고, 최종적으로 Epic은 PROD에 도달하며 Bug 0개와 Task 5개가 연결됨
    • 이 실행은 Jira 자동화로 2 + 3 = 5를 계산한 결과가 됨

  • Fibonacci 구성

    • Convert Issue Type은 Bug → Story, Story → Task처럼 이슈 유형을 즉시 바꿀 수 있음
    • CONVERT는 DEC + INC로 표현 가능해 계산 능력을 확장하지 않지만, 이동 루프의 디스패치 테이블을 줄여 더 복잡한 프로그램을 다루기 쉽게 만듦
    • Fibonacci는 (A, B) → (B, A+B)로 표현되며, 세 레지스터 A=Bug, B=Task, C=Story와 세 상태 TODO, QA, DEV로 구성됨 
      TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to TODO
    • 초기 상태는 A=1, B=1, C=0이며, Task 수인 B에서 1, 1, 2, 3, 5, 8, 13, ... 수열이 나타남
    • 덧셈 머신과 달리 Fibonacci 머신에는 정지 상태가 없고, Jira Cloud의 체인 깊이 제한 10에 도달할 때까지 실행됨
    • 제한에 닿으면 운영자가 Epic을 다시 트리거해 계속 진행할 수 있으며, 한 번의 상태 편집으로 연쇄 실행이 재시작됨
    • Jira Data Center는 automation.rule.execution.timeout과 관련 설정을 구성 가능한 속성으로 노출함
    • 무한한 이슈 생성과 규칙 실행을 가정하면 Jira 자동화 언어는 두 카운터 머신을 인코딩할 수 있으며, 물리 컴퓨터도 유한하다는 통상적 기준에서는 Jira Cloud의 유한 쿼터가 이 구성을 반박하지 않음

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • Jira는 완전히 끔찍해서, 다른 어떤 형태의 끔찍함으로도 변할 잠재력이 있음

    • Jira는 소외 개념의 궁극적 사례임
      Marx가 Atlassian을 알았다면 Grundrisse가 엄청나게 불타올랐을 것
    • 최악은 작업 관리 제품을 만드는 회사들이 전부 결국 Jira 방향으로 간다는 것임
      2014년의 GitHub Issues와 지금의 모습을 비교해 보면 됨: https://github.com/features/issues
      그리고 계속, 계속, 중복 기능을 추가하고 있음

  • Jira는 인기가 많고 선호하는 언어용 API 래퍼도 잘 갖춰져 있음
    해커 정신이 있는 기업 개발자들이 Python 명령줄 스크립트 같은 걸로 Jira에서 시키는 일 대부분을 자동화하지 않았다는 게 놀라움
    Jira를 강요하는 사람들보다 내가 한 자릿수 이상 쉽게 쓸 수 있게 만들면 판이 뒤집혀서, Jira는 자신을 보호하기 위해 밀어붙이는 도구가 됨
    가끔 거의 악의적으로 Jira를 써봤는데, 책임 회피용으로는 훌륭함
    문제가 생기면 “이건 내가 쓴 수백 개의 Jira 업데이트에 다 명확히 적혀 있었고, 읽고 있었죠?”라고 하면 됨
    이제 AI도 있으니 커스텀 스크립트로 전부 묶어서 AI가 Jira 잡일을 하게 만들면 됨

    • 꽤 많은 사람이 이미 그렇게 했지만, 문제는 Jira 인스턴스마다 오래된 실패한 마이그레이션과 새 조직 전략이 층층이 쌓인 커스텀 속성의 프랙털 눈송이라는 데 있음
      API가 UI에서는 허용하지 않는 일을 할 수 있는 경우도 많고, 모두가 UI를 기준으로 움직이다 보니 이상하게 깨진 구석으로 빠짐
      예를 들어 custom_field_5537이 custom_field_442와 짝지어져야 다른 사람 대시보드에 보인다는 걸 못 알아차릴 수 있음
      또 custom_field_10995는 정수 필드라고 주장하고 XML에서도 정수로 반환하지만, 작업 생성 시에는 문서화되지 않은 마법 상수 문자열을 써야 하고 업데이트 때는 또 안 그래도 되는 식임
      웹 UI는 그렇게 하지 않고 HTML과 요청에는 그냥 정수가 들어가며, 문자열의 80%만 드롭다운 표시 텍스트와 일치함
      Jira 자동화는 내가 겪은 최악의 프로그래밍 경험이었음
      더 단순한 설정은 분명 존재하고 꽤 쉬울 수도 있지만, 그래도 너무 심함
      슬프게도 여전히 들인 노력이 완전히 가치 있음. 강력 추천함
    • 예전에 일하던 곳에서 API로 시간을 아끼는 도구들을 여러 개 만들었고, 전부 작은 셸 스크립트였음
      각 티켓에 사람이 읽을 수 있는 설명용 커스텀 텍스트 필드를 추가하고, 릴리스가 배포되면 배포 스크립트가 타임스탬프를 자동으로 채웠음
      우리는 작업 단위로 티켓 하나씩 릴리스했고 하루에도 여러 티켓을 처리했음
      커스텀 필터와 합쳐서 Jira가 각 보드와 회사 전체에 대해 사람이 읽을 수 있는 변경 로그를 제공했고, 이 메시지들이 Slack으로 비즈니스 쪽에 전달돼 무엇이 배포되는지 모두가 알 수 있었음
      코드 변경과 연결되는 검색 가능한 릴리스 감사 로그이기도 했음
      배포 과정이 Jira 티켓 상태도 전환해서, 개발자는 티켓을 main에 머지하기만 하면 배포되고 Jira에서도 완료됐음
      반복 작업용 티켓을 자동 생성하는 작은 스크립트도 많았음
      수년간 아주 견고했고 지금도 돌아가고 있을 가능성이 큼
      커스텀 필드 명명 규칙은 별로였지만 팀이 Jira 설정을 통제한다면 모두 같은 기준을 유지하기 어렵지 않았음
      처음에는 Jira를 좋아하지 않았고 오래전에는 문제가 많았지만, 요즘은 설정만 잘 하면 그렇게 나쁘지 않음
      내 회사라면 고르지 않겠지만, 개발자이자 관리자이자 최종 사용자이자 내부 도구 개발자로 써본 입장에서는 구성되고 작동하기 시작하면 대체로 방해가 되지 않음
    • “커스텀 스크립트로 전부 묶어서 AI가 Jira 잡일을 하게 하라”는 건, 이미 Jira의 비대함이 충분하지 않다는 듯 보임
      텍스트를 더 추가하면 Jira는 somehow 그 모든 텍스트 위에서 항상 모든 걸 자동 실행할 테니 더 느려질 것임
      회사에 난방이 필요하면 Jira를 쓰면 됨
    • 아주 오래전에 JetBrains YouTrack으로 옮겼고, 우리는 그 API로 이런 일을 함
      꽤 유연하고, AI 덕분에 더 많이 열렸음
    • 우리 회사 전체가 사실상 Jira로 돌아감
      대부분의 프로세스가 Jira에 의존하고, 특정 전환이 자동화를 위한 웹훅을 실행함
      AI 접근 권한을 얻자마자 처음 한 일 중 하나가 Jira MCP를 만드는 것이었음
      이제 Jira를 거의 직접 만지지 않으려 하고, Claude에게 Jira 이슈 생성, 댓글 작성, 하위 작업 생성, 이슈 연결 등을 시킴
      예전에는 구현 방법을 조사하고 작업으로 쪼개야 할 때마다 두려웠음
      더 세밀하게 나눌수록 각 작업을 담을 Jira 이슈를 더 많이 만들어야 했기 때문임
      이제는 파일에 전부 정리해 놓고 대형 언어 모델에게 Jira 잡일을 맡기면 됨

  • 예전에 일하던 곳으로 돌아갔더니 여전히 JIRA를 쓰고 있었음
    면접 때는 당연히 “아 JIRA요, 아직 그거 쓰세요? 쓸 수 있죠”라고 했음
    실제로 쓸 수는 있지만, 최신 JIRA를 보고 정말 충격받았음
    자잘한 불편이 천 개쯤 있고, 최악 중 하나는 텍스트를 더블클릭해서 선택하려 하면 갑자기 필드가 편집 모드로 들어가는 것임
    내가 기억하던 건 JIRA Server 4.0이었고, 여기서 추억을 돌아볼 수 있음: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    충분히 확대하면 각 이슈에 제목, 유형, 수정 버전, 영향 버전 등이 있고 곧바로 댓글로 이어지는 구조였음. 매우 단순했음

    • 더블클릭이 편집 모드로 들어가는 문제는 정말 맞음
      너무 짜증남. 기본적인 텍스트 조작조차 틀림
      그런데 어떤 프로젝트 관리자는 그걸 좋아한다고 했음
      단어 전체를 선택하려고 더블클릭 드래그를 안 쓰기 때문이라고 함
      늘 그렇듯 컴퓨터를 겨우 쓰는 사람들의 편의 때문에 더 능숙한 사용자가 끌려 내려감
    • “JIRA요, 아직 그거 쓰세요?”라는 반응이 이상하게 들림
      내가 뭔가 놓쳤나, 시간 구멍에 빠졌나 싶음
      왜 Jira를 Visicalc처럼 이야기하는지 모르겠음
      지금은 IT 회사에서 일하지 않아서 지난 2년 사이 뭔가 대격변을 놓쳤을 수도 있음
    • 주가와 긍정적 사용자 인식이 제품에서 유지되던 시기의 상관관계를 찾을 수 있음
      4.x에서 6.x로 넘어갈 때나, OFBiz의 삐걱거리는 상자들과 겉모습만 맞춘 완전히 다른 제품들처럼 자잘한 불편도 함께 왔음
      그 엔지니어들은 한참 전에 떠났고 주당 280달러도 같이 가져갔음
    • 이제 본업에서 Jira나 비슷한 도구를 쓸 필요가 없어져서 진짜 궁금한데, 개발자들만이 아니라 전체 프로젝트 팀 관점에서 더 나은 대안에 대한 합의가 있나?
    • 그 버전의 JIRA도 설정만 잘못하면 쉽게 끔찍해질 수 있었음
      JIRA의 핵심 문제는 정상적으로 설정할 권한이 항상 소수에게만 있고, 그 사람들은 귀찮아하거나 시간이 없거나 매일 쓰지 않아서 신경 쓰지 않는다는 데 있음
      물론 문제는 그것만이 아님
      상상하기 힘들 정도로 느리고, 이슈가 다른 이슈의 부모가 될 수 없는 식의 이상한 제한도 있음

  • JIRA는 너무 느리고, 관리자들은 제대로 설정하는 법을 모르는 것처럼 보였음
    써본 것만으로도 트라우마가 있음

    • 도구 잘못은 아니라고 볼 수도 있음
      이 행성에는 그 도구를 올바르게 설정할 수 있는 사람이 단 한 명도 없을 뿐임
      인간의 무능을 이유로 도구에 책임을 물을 수는 없겠지
      그럼 누구를 위해 만들어졌느냐는 질문은 전혀 다른 문제고, 지금은 논의하지 말아야 함
    • 항상 걸리는 건 느림임
      본질적으로 티켓 시스템은 티켓과 티켓 간 관계, 상태를 담은 데이터베이스 이상이 아님
      물론 연결된 티켓, 커스텀 필드, 플러그인이 많으면 복잡도가 폭발할 수는 있음
      그래도 단순한 텍스트 데이터와 첨부파일을 다루는 물건이 어떻게 그렇게 참을 수 없이 느릴 수 있는지는 이해가 안 됨

  • 드디어 Jira에서 Doom을 할 수 있게 됐음

    • 맞음. Quake 3 Arena Multiplayer도 가능함

  • https://mattrickard.com/accidentally-turing-complete

  • 그래서 어떤 Jira 작업이 정지할지 말지 판별할 수 없는 이유가 설명됨

    • 그럼 “Jira에서 Doom을 할 수 있다”에 해당하나?
      Jira가 그 결과로 생기는 악마들을 죽일 펌프 액션 샷건도 제공하나?

  • 대신 Azure Boards를 써보면 JIRA를 사랑하게 될 것임
    Microsoft가 더 나쁘게 만들 수 없는 소프트웨어는 세상에 없기 때문임

    • 늘 Gmail을 싫어했고 지금도 싫어하지만, 작년에 직장을 옮긴 뒤 새 회사가 Outlook을 쓰면서 생각이 바뀌었음
      Outlook에 대한 경멸을 제대로 표현할 단어를 찾기 어렵고, “싫다”는 말로는 시작도 안 됨
      이메일을 받고 보내는 가장 기본적인 작업조차 버거워함
      휴대폰에 이메일 알림이 와서 앱을 열면 아무것도 없고, 아래로 당겨 새로고침해도 아무 일도 없음
      보통 1~15분 뒤에야 나타남
      Outlook에서 하는 모든 일이 지독하게 번거로움
      오래전 Office 2003 시절에도 Outlook을 썼는데 이렇게 나빴던 기억은 없음. 어떻게 이렇게 퇴보했는지 모르겠음
      Teams는 시작도 하고 싶지 않음. 그 프로그램이 무슨 문제를 풀려는 건지도 잘 모르겠음
      공유 파일은 OneDrive에 있는데 Teams에도 있고, 어째서인지 Outlook에도 있음
      컴퓨터 백업 파일들, CloneZilla 이미지 약 30GB를 OneDrive/Teams/Outlook으로 옮겨야 했는데 영원히 걸렸고, Win11이 깔린 6코어 Ryzen 노트북 팬이 내내 미친 듯이 돌았음
      어떻게? 왜?

  • 모든 작업 흐름 및 오케스트레이션 엔진은 튜링 완전함
    목적 자체가 실행 흐름을 자동화하는 것이기 때문임

    • 그중 얼마나 많은 것이 무한히 실행될 수 있나?
      혹은 사람이 다시 트리거해서 중단한 지점부터 이어갈 수 있나?
    • 그렇게 생각하지 않음
      첫째, JIRA는 오케스트레이션이 아님
      둘째, 작업 흐름이 해야 할 일은 어떤 상태를 외부 정보와 연결하고 그것들을 쉽게 조작하게 만드는 것임
      튜링 완전하려면 트리거와 규칙, 무한 카운터 같은 것, 두 개의 스택, 양방향 테이프 같은 게 필요함
      틀렸다는 걸 증명해 보라

  • Jira 자동화를 좋아함
    Jira를 쓰는 새 팀에 들어가면 하위 작업의 스토리 포인트를 자동 합산해 부모 작업의 스토리 포인트를 채우거나, 충분히 정제된 속성이 없으면 티켓을 자동으로 백로그로 옮기는 자동화를 설정함
    예를 들면 담당자, 스토리 포인트, 우선순위, 설명 등이 빠진 경우임
    한 스프린트만 지나도 팀 보드가 훨씬 정리됨
    왜 기본값이 아닌지는 모르겠지만, 자동화로 고치기 쉬움

    • 티켓이 정제됐다고 보려면 왜 담당자 지정이 필요하지?
      담당자는 그 일을 집어 든 사람이 배정받으면 되는 것이지, 정제 단계의 일부가 아니어야 함
답변달기