지라(Jira)가 튜링 완전하다고? 워크플로우로 만든 진짜 계산기

업무 도구로 컴퓨터를 만들었다는 이야기

개발자라면 한 번쯤은 지라(Jira)를 써봤을 거예요. 티켓 만들고, 상태 바꾸고, 누군가에게 할당하고... 그런데 이 지라로 실제 계산을 수행하는 컴퓨터를 만들 수 있다는 사실, 알고 계셨나요? 스위스의 개발자 Nicolas Seriot이 자신의 블로그에 올린 글에서, 지라의 워크플로우 시스템만 가지고 튜링 완전(Turing-complete)한 계산 모델을 구현할 수 있다는 걸 증명했거든요.

튜링 완전이 뭐냐면, 쉽게 말해 "이 시스템으로 이론상 어떤 계산이든 다 할 수 있다"는 뜻이에요. 우리가 쓰는 파이썬, 자바스크립트, C++ 같은 일반적인 프로그래밍 언어가 다 튜링 완전이고, 심지어 엑셀이나 매직: 더 개더링 같은 카드 게임, 마인크래프트의 레드스톤 회로도 튜링 완전이라는 게 증명돼 있어요. 그러니까 지라가 여기에 합류한 거죠.

지라 워크플로우로 어떻게 계산을 한다는 걸까

지라의 핵심 개념을 잠깐 짚어볼게요. 지라에서 이슈(티켓)는 상태(Status) 를 가져요. "To Do", "In Progress", "Done" 같은 거죠. 그리고 상태에서 다른 상태로 넘어가는 걸 트랜지션(Transition) 이라고 해요. 이때 트랜지션이 실행되면 포스트 함수(Post Function) 라는 게 동작하는데, 여기서 다른 이슈를 만들거나 필드 값을 바꾸거나 할 수 있어요.

저자는 바로 이 메커니즘을 이용해서 카운터 머신(Counter Machine) 을 구현했어요. 카운터 머신이 뭐냐면, 1960년대 컴퓨터과학자 민스키(Minsky)가 제안한 아주 단순한 계산 모델인데요. 정수를 담는 레지스터 몇 개와 "1 증가시켜라", "1 감소시키고 0이면 점프해라" 같은 기본 명령어만 있어도 튜링 완전이라는 게 수학적으로 증명돼 있어요.

구체적으로 지라에서는 이슈 하나를 "레지스터"로 보고, 그 이슈에 연결된 서브태스크의 개수를 레지스터의 값으로 삼았어요. 서브태스크를 새로 만들면 값이 1 증가, 서브태스크를 닫으면 값이 1 감소하는 식이죠. 그리고 워크플로우의 상태와 트랜지션이 프로그램의 명령어 역할을 해요. 트랜지션이 발동되면 포스트 함수가 다른 이슈에 트랜지션을 트리거하고, 이런 식으로 연쇄 반응이 일어나면서 계산이 진행되는 거예요.

저자는 이걸로 단순히 "이론상 가능하다"를 넘어서 실제로 덧셈, 곱셈, 그리고 콜라츠 추측(Collatz Conjecture) 까지 지라 안에서 돌아가게 만들었어요. 콜라츠는 "짝수면 2로 나누고, 홀수면 3을 곱하고 1을 더한다"는 규칙을 반복하면 결국 1에 도달한다는 유명한 미해결 수학 문제인데, 이걸 지라 워크플로우로 시뮬레이션한 거죠.

비슷한 사례들과 비교해보면

이런 "의도하지 않게 튜링 완전한 시스템" 발견은 컴퓨터과학에서 꽤 인기 있는 장르예요. 가장 유명한 건 엑셀의 LAMBDA 함수예요. 마이크로소프트가 2021년에 정식으로 "엑셀은 이제 완전한 프로그래밍 언어다"라고 발표했죠. CSS도 룰 110이라는 셀룰러 오토마타를 구현할 수 있어서 튜링 완전이라고 증명됐고요, 심지어 파워포인트의 애니메이션 기능, SQL의 재귀 쿼리, x86 CPU의 MOV 명령어 하나만 가지고도 튜링 완전한 게 증명됐어요.

그럼 "튜링 완전하면 좋은 거냐"는 질문이 나올 수 있는데, 사실 실용적으로는 별 의미 없어요. 오히려 "이런 것까지 가능하다"는 건 그 시스템이 의도하지 않은 복잡성을 품고 있다는 신호이기도 해요. 워크플로우 엔진이 튜링 완전하다는 건, 누군가 악의적으로 또는 실수로 무한 루프를 만들 수도 있다는 뜻이거든요. 실제로 지라를 운영하는 회사들 중에는 "왜 이슈가 자기 혼자 막 만들어지지?" 하면서 워크플로우 버그로 시스템이 마비되는 경험을 한 곳도 적지 않아요.

한국 개발자에게 이게 무슨 의미일까

많은 한국 회사들이 지라를 메인 이슈 트래커로 쓰고 있죠. 특히 스크럼이나 칸반을 도입한 팀이라면 워크플로우 커스터마이징은 거의 필수일 거예요. 이 글이 주는 실용적인 교훈은 두 가지인데요.

첫째, 워크플로우의 포스트 함수와 자동화 규칙을 조심하라는 거예요. 한 트랜지션이 다른 이슈를 만들거나 상태를 바꾸고, 그게 또 다른 트랜지션을 트리거하는 식의 자동화를 짜다 보면 의외로 복잡한 연쇄 반응이 만들어질 수 있어요. 코드 리뷰는 하면서 워크플로우 리뷰는 안 하는 팀이 많은데, 사실 워크플로우도 일종의 "프로그램"이라고 봐야 해요.

둘째, "이게 가능한가?"라는 질문이 시스템 설계의 깊이를 보여준다는 점이에요. 어떤 도구를 단순 사용자로만 보면 그 한계를 모르고 살게 되지만, "이걸로 다른 걸 만들 수 있을까?" 하고 비틀어 보면 그 도구의 진짜 본질이 드러나거든요. 이런 사고 방식은 새로운 라이브러리나 프레임워크를 배울 때도 똑같이 적용돼요.

한 줄 정리

지라의 워크플로우 엔진이 카운터 머신을 흉내 낼 수 있을 만큼 강력하다는 건, 우리가 매일 쓰는 업무 도구 안에 생각보다 깊은 계산 능력이 숨어 있다는 뜻이에요. 그게 축복인지 저주인지는 그걸 쓰는 사람의 손에 달려 있고요.

여러분의 팀에서는 지라 워크플로우 자동화를 얼마나 적극적으로 쓰고 계신가요? 혹시 자동화 규칙끼리 충돌해서 곤란했던 경험이 있다면 어떤 상황이었는지 공유해주세요.