Xinics Skill Plugin
Jira 기반 개발 워크플로우를 자동화하는 Claude Code 스킬 플러그인
왜 만들었는가
AI 에이전트를 팀 개발에 투입해봤는데, 생각보다 결과물 품질이 들쑥날쑥했다. 같은 요청을 해도 어떤 날은 훌륭한 코드가 나오고, 어떤 날은 엉뚱한 방향으로 가버렸다. 문제는 AI가 아니라 구조의 부재였다. 에이전트가 따라야 할 워크플로우가 없으니 매번 다른 결과가 나왔다.
팀 전체가 일관된 개발 프로세스를 따르게 하고 싶었다. Jira 이슈 하나를 열면 — 기술 조사, 설계, 구현, 리뷰, 검증, 커밋, PM 보고까지 — 정해진 순서대로 진행되어야 한다. 사람이 하든, AI가 하든, 어떤 팀원이 하든 동일한 흐름을 거치는 것.
Night Worker와의 결합도 큰 동기였다. Night Worker가 밤 사이 자동으로 개발 파이프라인을 돌리려면, 스킬이 비대화형 환경에서도 동일하게 작동해야 한다. 그냥 대화용 프롬프트를 던지는 게 아니라, 구조화된 스킬이 필요했다.
한 가지 걸림돌이 있었다. private Bitbucket repo라 Claude Code의 공식 마켓플레이스에 올릴 수가 없었다. 그래서 팀 내부에서 git pull + plugin update 방식으로 배포하는 로컬 마켓플레이스 패턴을 직접 만들었다.
8개의 스킬, 하나의 파이프라인
8개의 스킬이 하나의 파이프라인을 이룬다. orchestrator가 Jira 이슈 상태를 감지해서 적절한 스킬로 라우팅하고, 각 스킬이 다음 스킬을 자연스럽게 이어받는다.
graph LR
O[orchestrator] --> TE[tech-explore]
O --> P[plan]
TE --> P
P --> D[develop]
D --> R[review]
R --> V[verify]
V --> C[commit]
C --> RP[report]
orchestrator
Jira 이슈 상태를 감지하고 적절한 스킬로 자동 라우팅. 사용자가 스킬을 직접 고를 필요가 없다.
tech-explore
구현 전 기술 조사 및 타당성 분석. "이게 가능한가, 어떻게 할 것인가"를 먼저 탐색한다.
plan
Jira 이슈 기반 설계 도출 + 구현 계획 수립. 복잡도에 따라 superpowers:brainstorming / superpowers:writing-plans로 자동 위임.
develop
확정된 플랜 기반 코드 구현. subagent-driven-development 패턴으로 복잡한 작업을 처리한다.
review
superpowers 패턴을 활용한 코드 리뷰. 구현이 끝나면 반드시 거치는 필수 게이트.
verify
QA 시나리오 생성 + 자동화 테스트 실행. 검증을 통과하지 못하면 커밋으로 넘어가지 않는다.
commit
Jira 이슈 번호가 포함된 git commit. lint / format / typecheck를 통과한 뒤에만 커밋을 실행한다.
report
비기술적 변경 요약을 Jira 이슈에 코멘트로 등록. PM과 QA가 기술적 맥락 없이도 내용을 파악할 수 있다.
기술적으로 재밌었던 것들
Superpowers를 감싸는 설계
처음엔 각 스킬을 처음부터 직접 설계하려 했다. 그런데 Claude에는 이미 강력한 superpowers 시스템이 있었다. brainstorming, writing-plans, subagent-driven-development — 이미 잘 동작하는 것들을 굳이 재구현할 이유가 없었다.
대신 래핑했다. 각 스킬은 superpowers를 그대로 활용하되, Jira 컨텍스트를 주입하는 역할을 담당한다. 이슈 번호, 프로젝트 설정, 현재 상태 — 이걸 superpowers에 넘기면 기존의 힘을 그대로 쓰면서 Jira 인식까지 갖게 된다.
복잡도 감지도 이 설계 덕분에 자연스러워졌다. plan 스킬이 이슈 규모를 판단해서 단순하면 writing-plans, 복잡하면 brainstorming + writing-plans 조합을 자동으로 선택한다.
Iron Law 패턴과 합리화 방지
스킬을 만들면서 가장 신경 쓴 부분은 "AI가 규칙을 우회하는 상황"을 막는 것이었다. "NO DEVELOP WITHOUT PLAN", "NO COMMIT WITHOUT VERIFICATION" — 이런 절대 규칙을 Iron Law라고 부른다. 어떤 상황에서도 예외가 없다.
그런데 AI는 합리화를 잘 한다. "이번 건 간단하니까 plan 없이 바로 구현해도 될 것 같은데요"처럼 그럴듯한 이유를 만들어낸다. 그래서 각 스킬에 합리화 테이블을 넣었다 — 예상되는 핑계 목록과 그에 대한 반박을 미리 정의해두는 것이다.
심리학의 commitment principle도 활용했다. 모든 스킬은 시작 시 "X 스킬을 사용해서 Y를 수행합니다"라는 선언으로 시작한다. 선언을 먼저 하면 이후 행동이 그 선언에 일관되게 따라가는 경향이 있다.
대화형과 비대화형의 통합
같은 스킬이 두 환경에서 동작해야 했다 — 사용자와 직접 대화하는 인터랙티브 모드와,
claude -p로 실행되는 Night Worker의 비인터랙티브 모드.
인터랙티브 모드에서는 사용자 승인 게이트가 존재한다. plan 결과를 보여주고, 확인을 받고, develop으로 넘어가는 식이다. 비인터랙티브 모드에서는 게이트 없이 자동으로 진행되고, critical 에러가 발생할 때만 중단된다.
이 분기 처리가 생각보다 까다로웠다. 환경 감지 로직을 각 스킬에 내장해서, 같은 코드가 맥락에 따라 다르게 동작하도록 설계했다. 덕분에 Night Worker에서도 사람이 만든 스킬과 완전히 동일한 품질 게이트를 거친다.
로컬 마켓플레이스 패턴
Claude Code의 공식 마켓플레이스는 public repo만 지원한다. 팀 내부 코드가 담긴 private Bitbucket repo는 등록 자체가 불가능했다. 그래서 팀 전용 배포 방식을 만들었다.
방법은 단순하다.
git pull로 최신 스킬을 받고,
claude plugin update로 적용하면 끝이다.
Confluence에 설치 가이드를 작성해두었고, 팀원 누구나 5분 안에 세팅할 수 있다.
제약이 오히려 명확한 설계로 이어진 케이스였다. 마켓에 올릴 수 없어서 만든 패턴이, 팀 내 배포와 업데이트 사이클을 오히려 더 빠르게 만들었다.
팀에서 쓰고 나서
개발 워크플로우가 표준화됐다. 누가 작업하든, AI가 작업하든, 기획→구현→리뷰→검증→커밋→보고라는 흐름은 항상 동일하게 유지된다. "이 PR은 리뷰를 거쳤나요?" 같은 질문이 사라졌다.
Night Worker와 조합하면서 야간 자동화 파이프라인이 완성됐다. 퇴근 전 Jira 이슈를 확인하고 태스크를 등록해두면, 아침에 commit과 report까지 완료된 결과가 올라와 있다. Jira 이슈에 달린 Claude의 변경 요약 코멘트를 처음 봤을 때 팀 반응이 꽤 인상적이었다.
QA팀이 구조화된 테스트 시나리오를 자동으로 받게 됐다. verify 스킬이 실행될 때마다 QA 시나리오가 생성되고 Jira에 첨부된다. PM도 마찬가지 — report 스킬이 비기술적 변경 요약을 이슈에 남기기 때문에, 개발자에게 따로 물어볼 필요가 없어졌다.
코드 품질도 올라갔다. 리뷰와 검증 게이트가 필수가 되니, 예전처럼 "일단 올리고 나중에 정리하자"가 통하지 않는다. 규칙이 자동으로 강제되는 구조를 만드는 게 규칙을 정하는 것보다 훨씬 효과적이었다.
돌아보며
v2.0.0 재설계를 하면서 모듈성이 크게 좋아졌다. 처음엔 스킬마다 비슷한 코드가 반복됐는데, 공통 패턴을 추출하고 나니 새 스킬을 추가하는 게 훨씬 빨라졌다. 좋은 추상화는 직접 만들어보기 전엔 보이지 않는다는 걸 다시 실감했다.
"도구를 만드는 도구"를 만든 경험이 흥미로웠다. 코드를 짜는 AI를 제어하는 스킬을 만들고 있으니, 한 레이어 위에서 시스템을 설계하는 느낌이었다. AI의 행동을 어떻게 구조화할지 고민하는 과정 자체가 새로운 종류의 엔지니어링이었다.
Night Worker와의 시너지는 예상보다 컸다. 두 프로젝트가 서로를 완성시키는 구조가 되었다 — Night Worker는 스킬 플러그인이 있어야 제대로 돌아가고, 스킬 플러그인은 Night Worker가 있어야 야간 자동화가 된다. 처음부터 이렇게 설계했던 건 아니었는데, 자연스럽게 맞물리는 방향으로 수렴했다.