개발자 자동화 실습 03. 개인 Jira와 회사 Jira를 한 도구로 다루되 섞지 않는 법

지난 글에서는 Jira 티켓을 안전하게 만드는 파이프라인을 정리했습니다. summary-only intake -> duplicate check -> dry-run -> exact confirmation -> apply 흐름으로 개인 Jira PER 티켓 9개를 만들었습니다.

그 다음에 남은 질문은 더 까다로웠습니다.

개인 Jira와 회사 Jira를 같은 자동화 도구로 다뤄도 되는가.

처음에는 간단해 보였습니다. PER는 개인 프로젝트고, KAN은 회사 프로젝트입니다. project key만 잘 보면 되는 것처럼 보였습니다. 그런데 실제로는 그 정도로는 부족했습니다. 같은 Atlassian 계정, 같은 Jira site, 같은 자동화 명령 안에서 개인 작업과 회사 작업을 다루려면, project key보다 먼저 소유권과 기록 위치를 분리해야 했습니다.

이번 글은 Jira API 사용법이 아니라 Jira 자동화의 경계 설계에 관한 기록입니다.

project key만 보면 자동화가 너무 쉽게 섞입니다

처음에는 PER와 KAN을 나누면 충분하다고 생각했습니다.

PER = 개인 Jira
KAN = 회사 Jira

겉으로는 맞습니다. 하지만 자동화 관점에서는 부족했습니다.

project key는 Jira 안의 위치를 알려줍니다. 하지만 그 티켓을 어디에 기록해야 하는지, 어떤 저장소가 durable record를 가져야 하는지, 어떤 write action까지 허용되는지는 말해주지 않습니다.

예를 들어 개인 학습 티켓은 ai-survival-log의 wiki tracking으로 충분합니다. 하지만 회사 Jira 관리 기록은 company-wiki가 맡아야 합니다. 회사 Jira write가 실제로 실행됐다면 실행 audit은 별도 운영 표면으로 넘겨야 합니다.

이 차이를 project key만으로 판단하면 위험합니다.

KAN이라는 key가 보인다고 해서 회사 도메인 evidence를 company-wiki에 그대로 복사해도 되는 것은 아닙니다. PER라는 key가 보인다고 해서 같은 명령을 회사 create에 그대로 써도 되는 것도 아닙니다.

Jira 자동화에서 project key는 힌트일 뿐입니다. 소유권 판단은 별도 profile이 해야 했습니다.

같은 Jira site보다 중요한 것은 기록의 주인입니다

이 실습에서 기록의 주인은 세 갈래로 나뉘었습니다.

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

여기서 중요한 건 저장소 이름이 아니라 책임입니다.

ai-survival-log는 개인 지식과 블로그의 upstream authoring source입니다. 개인 Jira PER 티켓은 여기서 추적할 수 있습니다. 다만 Jira는 source of truth가 아닙니다. 학습 결과와 글의 본문은 wiki에 남고, Jira key는 작업 dashboard metadata로 남습니다.

company-wiki는 회사 Jira 관리 허브입니다. Jira issue key, summary-only description, routing, next action, waiting 상태 같은 안전한 관리 정보만 둡니다. 회사 Jira 원문, ITSM 원문, source code, SQL, DB dump, credential, 상세 검수 증적은 여기에 그대로 복사하지 않습니다.

shared-agent-harness는 공통 실행 레이어입니다. 개인과 회사가 같은 패턴을 쓸 수 있도록 명령과 guardrail을 제공하지만, 어느 쪽의 durable knowledge source도 되면 안 됩니다.

이 구분이 생기고 나서야 자동화의 질문이 바뀌었습니다.

이 Jira issue는 어느 project key인가?

이 질문이 아니라 다음 질문으로 바뀌었습니다.

이 작업의 durable record는 어디에 남아야 하는가?
이 명령은 어느 profile로 실행돼야 하는가?
이 실행 결과는 어떤 audit surface가 소유해야 하는가?

이 질문으로 바꿔야 개인과 회사가 같은 도구를 쓰면서도 섞이지 않습니다.

profile은 옵션이 아니라 안전장치였습니다

그래서 Jira 자동화에는 세 가지 classification profile을 뒀습니다.

personal-jira
company-jira
needs-classification

personal-jira는 개인 학습, 블로그, 개인 tooling, 개인 task에만 씁니다. 이 profile의 durable record는 개인 wiki나 개인 ops surface로 갑니다.

company-jira는 회사 업무에만 씁니다. 이 경우 durable management surface는 company-wiki 또는 승인된 회사 audit surface입니다.

가장 중요한 profile은 사실 needs-classification이었습니다.

분류가 애매하면 실행하지 않습니다. 이것은 경고가 아니라 block입니다. 개인 작업인지 회사 작업인지, 기록 위치가 어디인지, profile과 command가 맞는지 확정되지 않으면 Jira API credential을 꺼내기 전 단계에서 멈춰야 합니다.

이렇게 하지 않으면 자동화는 너무 친절해집니다. 요청 문장이 애매해도 도구가 project key를 추측하고, summary에서 domain을 추측하고, 저장소 위치까지 추측하게 됩니다.

그 순간부터 자동화는 보조 도구가 아니라 데이터 경계를 흐리는 도구가 됩니다.

profile의 역할은 자동화를 빠르게 만드는 것이 아니었습니다. 애매한 작업을 멈추게 만드는 것이었습니다.

command profile과 Jira profile은 서로 맞아야 했습니다

Jira 자동화에는 두 종류의 profile이 필요했습니다.

하나는 command-facing wiki profile입니다.

personal-wiki
company-wiki

다른 하나는 Jira classification profile입니다.

personal-jira
company-jira
needs-classification

처음에는 둘을 하나로 합쳐도 될 것처럼 보였습니다. 하지만 실제로는 역할이 다릅니다.

command-facing profile은 local planning artifact를 어디 기준으로 만들지 결정합니다. personal-wiki면 개인 wiki 문맥으로 plan을 만들고, company-wiki면 회사 Jira 관리 문맥으로 plan을 만듭니다.

Jira classification profile은 외부 Jira issue가 개인인지 회사인지, 아니면 분류 보류인지 결정합니다.

그래서 둘은 서로 맞아야 합니다.

personal-wiki + personal-jira = 허용 가능
company-wiki  + company-jira  = 승인된 gate 안에서 허용 가능
personal-wiki + company-jira  = block
company-wiki  + personal-jira = block
needs-classification          = block

이 규칙은 사소해 보이지만 실제로는 핵심 guardrail입니다. 회사 Jira issue를 개인 wiki profile로 처리하면 회사 기록이 개인 저장소에 섞입니다. 개인 티켓을 회사 wiki profile로 처리하면 개인 학습 기록이 회사 관리 표면에 들어갑니다.

자동화는 입력을 받는 순간부터 분류를 강제해야 했습니다. 나중에 사람이 읽고 정리하면 된다는 방식은 Jira write automation에서는 너무 늦습니다.

회사 Jira에서는 write action마다 gate가 달라야 했습니다

개인 Jira에서 PER 티켓을 만드는 일과 회사 Jira에서 KAN에 무언가 쓰는 일은 같은 위험 등급이 아닙니다.

특히 회사 Jira에서는 write action을 하나로 묶으면 안 됐습니다.

issue create
comment write
status transition
field mutation
attachment handling
bulk write

이것들은 모두 Jira API를 쓰지만, 위험이 다릅니다.

issue create는 새 기록을 만듭니다. comment write는 협업 표면에 문장을 남깁니다. status transition은 workflow state를 바꿉니다. field mutation은 routing, priority, ownership, due date 같은 운영 metadata에 영향을 줄 수 있습니다. attachment handling은 원문과 private payload 위험이 커집니다.

그래서 회사 Jira 자동화에서는 "한 번 create가 됐으니 이제 comment도 되고 status도 된다"는 식으로 확장하면 안 됐습니다.

실제 정리는 더 좁았습니다.

• controlled company create test는 특정 gate 안에서만 허용
• KAN-4 같은 테스트 issue는 test evidence로만 취급
• KAN-1 같은 durable planning record와 test issue를 분리
• comment apply는 별도 pilot gate가 필요
• status transition apply는 현재 표면에서는 block
• broader company write는 category-specific gate 없이는 승인하지 않음

이 흐름은 답답해 보일 수 있습니다. 하지만 회사 Jira 자동화에서 중요한 것은 한 번 성공한 API call이 아닙니다. 같은 도구가 다음 write category로 넘어갈 때 어떤 조건으로 멈출 수 있는지를 확인하는 것입니다.

자동화 확장은 "할 수 있음"이 아니라 "허용된 범위가 무엇인가"로 관리해야 했습니다.

Jira status는 완료 증거가 아니라 dashboard metadata였습니다

회사 Jira 자동화에서 계속 반복된 원칙이 하나 있었습니다.

Jira status is dashboard metadata.
It is not wiki completion evidence.

Jira에서 Done이나 완료로 보인다고 해서, wiki에서도 완료 근거가 생기는 것은 아닙니다. Jira status는 작업 보드에서 현재 상태를 보여주는 metadata입니다. 하지만 왜 완료됐는지, 어떤 검토를 거쳤는지, 어떤 증거가 있는지는 별도의 durable record가 필요합니다.

이 원칙이 없으면 자동화가 위험해집니다.

예를 들어 sync report가 Jira status를 읽고 "Jira는 Done인데 wiki는 reviewing"이라고 알려주는 것은 유용합니다. 하지만 그 보고서가 wiki 상태를 자동으로 done으로 바꾸면 문제가 됩니다.

상태 차이를 보여주는 것과 완료를 승인하는 것은 다릅니다.

그래서 read-only sync report는 허용할 수 있지만, status transition apply나 wiki 상태 자동 변경은 별도 gate 없이는 막아야 했습니다.

Jira는 일을 보기 쉽게 해줍니다. 하지만 일을 끝냈다는 근거까지 대신 만들어주지는 않습니다.

공통 skill은 개인 위키가 아니라 shared harness에 있어야 했습니다

이번 실습에서 가장 실제적인 구조 수정은 skill 위치였습니다.

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

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

그때 제가 다시 물었습니다.

2개 스킬이 ai-survival-log에 있는 것이 맞나요?

이 질문이 중요했습니다. 처음에는 기능만 보고 있었습니다. 하지만 다시 보니 두 skill의 소유권이 달랐습니다.

jira-per-ticket-auto-create는 개인 Jira PER 전용입니다. 개인 학습이나 블로그 티켓을 여러 개 만들 때, summary-only intake부터 wiki tracking까지 이어지는 자동화입니다. 이건 ai-survival-log에 있어도 됩니다.

반면 jira-ticket-create는 개인과 회사가 함께 쓰는 공통 단건 create workflow입니다. 개인 PER에도 쓸 수 있고, 승인된 회사 create gate에서도 쓸 수 있습니다. 이 skill이 개인 위키에 있으면 회사 자동화가 개인 저장소의 로컬 규칙을 빌려 쓰는 모양이 됩니다.

그래서 최종 위치를 바꿨습니다.

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

이 차이는 작아 보이지만 운영상으로는 큽니다.

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

스킬화의 핵심은 명령어를 재사용하는 것이 아니라, 재사용해도 되는 범위를 정하는 것이었습니다.

같은 도구를 쓰려면 더 많은 이름이 필요했습니다

자동화를 처음 만들 때는 이름이 많아지는 것을 부담스럽게 느끼기 쉽습니다.

PER, KAN, personal-jira, company-jira, needs-classification, personal-wiki, company-wiki, shared-agent-harness, company-assistant-ops.

처음 보면 복잡합니다.

하지만 이름이 부족하면 더 큰 문제가 생깁니다. 개인 작업과 회사 작업을 같은 "Jira ticket"으로 부르면, 어느 저장소에 기록해야 하는지 흐려집니다. create, comment, transition을 같은 "Jira write"로 부르면, 한 번 허용된 작업이 다른 작업까지 밀어붙입니다.

좋은 자동화는 이름을 줄이는 것이 아니라, 헷갈리면 안 되는 경계에 이름을 붙입니다.

이번 실습에서 붙인 이름들은 추상적인 아키텍처 장식이 아니었습니다. 실제로 명령이 멈춰야 하는 지점을 만들기 위한 이름이었습니다.

needs-classification = 지금은 실행하지 말 것
company-jira         = 회사 gate를 확인할 것
personal-jira        = 개인 wiki tracking으로 제한할 것
jira-ticket-create   = 공통 create workflow, shared harness 소유
jira-per-ticket-auto-create = PER 전용 batch workflow, ai-survival-log 소유

이름을 잘 붙이면 자동화가 덜 마법처럼 동작합니다. 대신 어디서 멈춰야 하는지 더 잘 보입니다.

이번 후속 실습의 결론은 분리였습니다

02편에서 "Jira create에는 안전장치가 먼저 필요합니다"라고 정리했다면, 이번 글에서는 안전장치가 위치와 이름까지 포함해야 한다고 정리했습니다.

개인 Jira와 회사 Jira를 같은 도구로 다룰 수는 있습니다. 하지만 같은 규칙으로 다루면 안 됩니다.

이번 실습에서 남은 기준은 이렇습니다.

• project key는 routing의 힌트일 뿐 durable ownership을 결정하지 않습니다.
• 개인 Jira는 personal-jira, 회사 Jira는 company-jira로 분류합니다.
• 애매하면 needs-classification으로 block합니다.
• command-facing wiki profile과 Jira classification profile은 일치해야 합니다.
• 회사 Jira write는 create, comment, transition, field mutation, attachment를 각각 다른 gate로 봅니다.
• Jira status는 dashboard metadata이고 wiki completion evidence가 아닙니다.
• 개인 전용 skill은 개인 wiki에, 공통 skill은 shared harness에 둡니다.

자동화는 같은 일을 반복하기 위해 만듭니다. 그런데 반복 가능한 도구일수록 더 먼저 물어야 합니다.

이 반복이 어느 경계 안에서만 안전한가?

이번 Jira 실습에서 제가 얻은 답은 단순했습니다.

같은 도구를 쓸 수는 있습니다. 하지만 같은 표면에 기록하면 안 되고, 같은 승인으로 실행하면 안 됩니다.