개발자 자동화 실습 02. Jira 티켓 자동화는 API 호출이 아니라 안전장치 설계다

Jira 티켓 자동화라고 하면 보통 API 호출부터 떠올립니다. 이메일과 API token을 넣고, project key와 summary를 넘기면 이슈가 하나 만들어지는 그림입니다.

근데 실제로 해보면 문제는 거기서 시작하지 않았습니다.

토큰이 맞는지, 지금 접근하는 Atlassian 사이트가 맞는지, PER와 KAN 중 어느 프로젝트에 쓰려는지, issue type이 정확한지, 같은 티켓을 또 만들고 있는 건 아닌지부터 확인해야 했습니다. 그리고 더 중요한 질문이 하나 있었습니다. 개인 학습 티켓과 회사 업무 티켓을 같은 자동화 흐름으로 다뤄도 되는가.

이번 실습에서는 개인 Jira PER 프로젝트에 학습과 블로그용 티켓 9개를 실제로 만들었습니다. 다만 목표는 "Jira API로 티켓 만들기"가 아니었습니다. 목표는 외부 시스템에 기록을 남기는 자동화를 어떻게 안전하게 설계할 것인가였습니다.

PR summary 다음에는 외부 시스템에 쓰는 자동화가 왔습니다

개발자 자동화 실습 01에서는 PR summary를 다뤘습니다. 그때의 자동화는 리뷰 보조에 가까웠습니다. 변경 파일을 보고, 위험도를 계산하고, 리뷰어가 먼저 볼 지점을 정리해 주는 흐름이었습니다.

이번 Jira 자동화는 성격이 달랐습니다.

PR summary는 틀려도 다시 고치면 됩니다. 하지만 Jira create는 외부 시스템에 실제 티켓을 만듭니다. 잘못된 project key로 만들 수도 있고, 회사 프로젝트에 개인 학습 티켓을 만들 수도 있고, 이미 있는 티켓을 중복으로 만들 수도 있습니다. 그래서 이번 실습은 "더 똑똑한 자동화"보다 "멈출 수 있는 자동화"에 가까웠습니다.

자동화가 강해질수록 먼저 정해야 하는 것은 실행 능력이 아니라 실행 조건이었습니다.

처음 막힌 곳은 PER/KAN 권한이 아니라 인증이었습니다

처음에는 PER 프로젝트에 접근할 수 있는지, 아니면 KAN 프로젝트만 접근 가능한지부터 확인하려고 했습니다. 그런데 실제 문제는 프로젝트 권한이 아니었습니다. Jira 인증 자체가 실패하고 있었습니다.

/rest/api/3/myself를 호출했을 때 401 Unauthorized가 나왔습니다. 이 시점에서 PER 접근 문제인지 KAN 접근 문제인지 따지는 것은 의미가 없었습니다. 먼저 API token이 맞는지부터 확인해야 했습니다.

이때 문제를 네 층으로 나눴습니다.

• Python 명령을 잘못 붙여 넣은 문제
• jira_create.py가 있는 디렉터리에서 실행하지 않은 문제
• Atlassian API token이 틀렸거나 만료된 문제
• 프로젝트별 권한이나 issue type 문제

이 순서를 지키는 게 중요했습니다. 명령 복사 문제를 Jira 권한 문제로 착각하면 엉뚱한 곳을 고치게 됩니다. 반대로 401 인증 실패가 확인됐는데도 project key만 바꾸면 아무것도 해결되지 않습니다.

새 API token을 Keychain에 다시 등록한 뒤 /myself가 이렇게 돌아왔습니다.

status: 200
active: True

그제야 다음 단계로 넘어갈 수 있었습니다. 인증이 확인된 뒤에야 PER와 KAN 프로젝트의 issue type을 읽고, PER에는 개인 학습 티켓을 만들 수 있고 KAN은 회사 Jira 표면으로 따로 다뤄야 한다는 판단을 할 수 있었습니다.

Jira 자동화의 첫 번째 교훈은 단순했습니다. 접근 문제를 보기 전에 인증 문제를 먼저 닫아야 합니다.

Jira는 source of truth가 아니라 작업 표면이어야 했습니다

이 실습에서 가장 중요한 설계 결정은 Jira를 어디에 둘 것인가였습니다.

제 개인 위키의 기본 흐름은 raw -> wiki -> output/blog -> site입니다. 여기서 source of truth는 wiki/입니다. Jira는 공부 결과나 블로그 원고를 저장하는 곳이 아니라, 제가 어떤 작업을 해야 하는지 보여주는 dashboard에 가깝습니다.

회사 쪽은 더 조심해야 했습니다. 회사 Jira KAN과 관련된 기록은 개인 위키에 원문으로 들어오면 안 됩니다. 회사 업무 요약과 routing은 company-wiki가 맡고, 실행 audit은 별도 운영 표면이 맡아야 합니다. 공통 명령과 정책은 shared-agent-harness에 둡니다.

그래서 표면을 이렇게 나눴습니다.

ai-survival-log       = 개인 학습, 블로그, 개인 Jira PER 추적
company-wiki          = 회사 Jira KAN 관리 요약과 routing
shared-agent-harness  = 공통 Jira 명령, guardrail, skill

이 구분이 없으면 자동화는 빨라지는 대신 위험해집니다. 개인 학습 주제가 회사 Jira에 들어가거나, 회사 업무 맥락이 개인 블로그 저장소에 섞일 수 있습니다.

Jira 자동화는 티켓을 만들기 전에 먼저 "어디가 기록의 기준인가"를 정해야 했습니다.

제가 고정한 생성 파이프라인은 일곱 단계였습니다

개인 Jira PER에 티켓을 만들 때는 아래 순서를 고정했습니다.

summary-only intake
-> duplicate check
-> dry-run preview
-> exact confirmation
-> apply
-> execution-note verification
-> wiki tracking

각 단계에는 이유가 있습니다.

summary-only intake는 원문을 복사하지 않기 위한 단계입니다. Jira 티켓을 만들기 위해 필요한 최소 요약만 둡니다. 회사 원문, credential, source code, SQL, raw payload, private evidence는 넣지 않습니다.

duplicate check는 자동화의 재실행 위험을 줄입니다. 네트워크가 끊겼거나 중간에 결과를 놓치면 같은 티켓을 다시 만들기 쉽습니다. 그래서 create 전에 Jira에서 비슷한 summary가 있는지 확인합니다.

dry-run preview는 실제 생성 전에 target site, project key, issue type, summary, description, execution note 경로를 확인하는 단계입니다. 여기서 틀리면 아직 외부 시스템에는 아무것도 쓰지 않은 상태입니다.

exact confirmation은 마지막 human gate입니다. 예를 들어 첫 번째 티켓은 이런 확인 문구를 요구했습니다.

CREATE PER 작업 노정석 EP 95 DeepSeek-V4 논문 공부 후 블로그 글 작성

이 문구가 preview와 정확히 맞아야만 apply를 실행했습니다. summary가 바뀌거나 issue type이 바뀌면 dry-run부터 다시 해야 합니다.

execution-note verification은 생성 이후의 audit입니다. 생성된 Jira key가 있는지, HTTP 201 created가 맞는지, summary가 의도한 값인지, token 값과 raw Jira JSON이 저장되지 않았는지 확인합니다.

마지막 wiki tracking은 제 source of truth를 갱신하는 단계입니다. Jira key는 dashboard metadata로 남기고, 실제 공부 결과와 블로그 원고는 계속 wiki에 쌓습니다.

이 파이프라인 덕분에 자동화는 "바로 실행하는 명령"이 아니라 "실패 조건을 통과해야 실행되는 절차"가 됐습니다.

PER 티켓 9개는 자동으로 만들었지만 한 번에 믿지는 않았습니다

실제로 만든 개인 Jira 티켓은 9개였습니다.

PER-1  노정석 EP 95 DeepSeek-V4 논문 공부 후 블로그 글 작성
PER-2  실리콘벨리개발자 레포점수 스킬 확인하기
PER-3  AI-Native Change Management 결과 확인 후 공부해서 블로그 글 작성
PER-4  양실장의바이브코딩대학 프론트엔드 백엔드 편 보고 웹기초 블로그 글 작성
PER-5  프론트엔드 언어별 특징 공부
PER-6  알고리즘 강의 시청
PER-7  대규모 시스템 설계 책 읽기
PER-8  mattpocock 클로드 스킬 분석
PER-9  주식종목분석에이전트 스킬 분석

여기서 중요한 건 9개를 만들었다는 숫자가 아닙니다. 2번부터 9번까지 이어서 create하겠다고 승인한 뒤에도, 각 티켓은 자기 차례에 duplicate check와 dry-run preview를 거쳤습니다.

batch 승인은 gate를 생략한다는 뜻이 아니었습니다.

각 항목마다 임시 intake를 만들고, Matches: none을 확인하고, preview의 confirmation string을 기준으로 apply했습니다. 중간에 duplicate가 나오거나 Jira create가 실패하면 멈추는 구조였습니다.

작은 실수도 있었습니다. 첫 번째 티켓 제목에서 노정성이라고 잘못 적은 부분을 노정석으로 고쳤습니다. 이때도 바로 apply하지 않았습니다. summary를 수정하고, duplicate check와 dry-run preview를 다시 실행한 뒤 confirmation을 새로 만들었습니다.

자동화는 빠르게 처리하는 도구지만, 빠르게 틀리는 도구가 되면 의미가 없습니다. 그래서 제가 믿은 것은 batch 실행이 아니라 각 티켓마다 반복된 gate였습니다.

dry-run은 친절한 미리보기가 아니라 마지막 브레이크였습니다

처음에는 dry-run을 단순 미리보기 정도로 생각하기 쉽습니다. 하지만 Jira create에서 dry-run은 마지막 브레이크에 가깝습니다.

Jira 티켓 생성에는 생각보다 많은 필드가 얽힙니다.

• Atlassian site
• project key
• issue type
• summary
• description
• labels
• components
• parent issue
• execution note path
• credential source

이 중 하나만 틀려도 문제의 성격이 달라집니다. PER에 만들 개인 티켓이 KAN에 들어가면 경계 사고가 됩니다. issue type이 잘못되면 API가 실패하거나 보드 운영이 꼬입니다. execution note에 raw payload가 남으면 보안과 retention 문제가 됩니다.

그래서 dry-run에서 봐야 하는 것은 "잘 나왔네"가 아닙니다.

이 티켓이 정말 이 프로젝트에 만들어져도 되는가?
이 issue type이 Jira가 실제로 받는 값인가?
중복 티켓은 없는가?
description에 넣으면 안 되는 정보가 섞이지 않았는가?
실행 기록은 임시 artifact 경로에만 남는가?

이 질문을 통과한 뒤에야 exact confirmation이 의미를 가집니다. confirmation은 작업자의 막연한 승인을 묻는 문구가 아니라, preview된 생성 내용과 apply 명령을 서로 묶는 장치입니다.

자동화에서 "확인했습니다"는 너무 약합니다. 무엇을 확인했는지 문자열로 고정해야 합니다.

회사 Jira에는 같은 규칙을 그대로 가져가면 안 됐습니다

개인 PER 티켓 생성이 성공했다고 해서 회사 KAN 자동화까지 같은 승인으로 밀어붙일 수는 없었습니다.

개인 Jira create와 회사 Jira write는 위험 등급이 다릅니다. 특히 회사 쪽에서는 create, comment, status transition, field mutation, attachment handling을 같은 종류의 작업으로 보면 안 됩니다.

예를 들어 comment는 외부 협업 표면에 문장을 남깁니다. status transition은 workflow 상태를 바꿉니다. field mutation은 routing, priority, ownership, due date 같은 운영 metadata를 바꿀 수 있습니다. attachment는 원문과 private payload 위험이 훨씬 큽니다.

그래서 회사 Jira 자동화 쪽에서는 profile과 gate를 더 강하게 나눴습니다.

personal-jira       = 개인 작업
company-jira        = 회사 작업
needs-classification = 분류가 애매하므로 block

needs-classification은 단순 경고가 아니라 hard block이어야 했습니다. 개인 작업인지 회사 작업인지 애매한 상태에서 Jira API credential을 꺼내거나 durable record를 만들면 안 됩니다.

그리고 Jira status도 조심해야 했습니다. Jira에서 Done처럼 보이는 상태가 wiki에서 완료 증거가 되는 것은 아닙니다. Jira status는 dashboard metadata일 뿐이고, 실제 완료 근거는 wiki나 승인된 audit surface에 남아야 합니다.

이 판단 덕분에 개인 자동화 실습은 회사 자동화의 위험을 줄이는 예행연습이 됐습니다. 단, 개인 승인 규칙을 회사 승인 규칙으로 착각하지 않는다는 전제가 붙었습니다.

성공한 명령을 스킬로 남기면서 구조가 더 분명해졌습니다

티켓을 9개 만들고 나서 남은 질문은 이것이었습니다.

이 절차를 다음에도 똑같이 재현하려면 어디에 남겨야 하는가?

처음에는 두 개의 skill을 모두 ai-survival-log 안에 만들었습니다.

• jira-per-ticket-auto-create
• jira-ticket-create

그런데 다시 보니 위치가 같으면 안 됐습니다.

jira-per-ticket-auto-create는 개인 Jira PER 전용입니다. 개인 학습, 개인 블로그, 개인 tooling 티켓을 summary-only intake에서 시작해 duplicate check, dry-run, apply, wiki tracking까지 처리합니다. 그러니 ai-survival-log에 있는 것이 맞습니다.

반면 jira-ticket-create는 개인과 회사에서 모두 쓸 수 있는 공통 단건 create workflow입니다. 이 스킬은 PER에도 쓸 수 있고, 승인된 회사 create gate에서도 쓸 수 있습니다. 그러면 개인 위키가 canonical 위치가 되면 안 됩니다.

최종 위치는 이렇게 정리했습니다.

ai-survival-log/.codex/skills/jira-per-ticket-auto-create
shared-agent-harness/skills/jira-ticket-create

이 결정이 중요했습니다. 스킬화는 성공한 명령어를 메모장에 저장하는 일이 아닙니다. 그 절차의 소유권과 사용 범위를 정하는 일입니다.

개인 전용 자동화는 개인 위키에 둡니다. 개인과 회사가 함께 쓰는 공통 workflow는 shared harness에 둡니다. 회사 운영 기록은 company-wiki와 승인된 audit surface가 맡습니다.

자동화는 코드보다 위치에서 먼저 틀어질 수 있다는 걸 이 단계에서 배웠습니다.

이번 실습의 결론은 빠른 생성이 아니었습니다

이번 실습에서 Jira 티켓 9개를 만들었습니다. 하지만 이 글의 결론은 "Jira API로 티켓을 자동 생성했다"가 아닙니다.

진짜 결론은 이쪽입니다.

• 인증 확인은 project 권한 확인보다 먼저입니다.
• Jira는 source of truth가 아니라 dashboard/task surface입니다.
• summary-only intake는 원문과 private payload를 막기 위한 최소 단위입니다.
• duplicate check는 자동화 재실행의 피해를 줄입니다.
• dry-run은 미리보기가 아니라 외부 write 직전의 브레이크입니다.
• exact confirmation은 사람의 승인을 preview와 묶는 장치입니다.
• 개인 Jira와 회사 Jira는 profile과 gate를 분리해야 합니다.
• 성공한 절차는 skill로 남기되, canonical 위치를 잘못 잡으면 다시 위험해집니다.

개발자 자동화라고 하면 빨리 처리하는 기술처럼 보입니다. 그런데 실제로 반복 가능한 자동화를 만들려면 빨리 실행하는 능력보다 안전하게 멈추는 능력이 먼저 필요했습니다.

Jira API 호출은 작은 부분이었습니다.

이번 실습의 본체는 티켓 생성 명령이 아니라, 그 명령이 실행되기 전에 반드시 통과해야 하는 안전장치였습니다.