Jira에 티켓 적고 산책 갔다 왔더니 PR이 만들어져 있었다 — 개발 자동화 기록

Jira 티켓 적고 산책 7분 뒤 PR — jira-agent 자동화 기록

Jira에 KAN-9 티켓 하나 적고 산책 갔다 왔더니 PR이 만들어져 있었다. 정확히는 16시 44분에 enqueue, 16시 51분에 done. 7분 5초. polling 5분 빼면 실제 처리는 2분 안쪽이다.

Jira 티켓을 적으면 M4 Mac Studio에 상주하는 워커가 그걸 받아서 코드 변경, 테스트 작성, GitHub PR 생성, CI 통과 확인까지 자동으로 한다. 사람이 개입하는 건 두 군데뿐이다. 티켓 작성과 PR 리뷰·머지. 그 사이는 모두 자동이다.

비슷한 도구가 이미 있다. Cursor는 IDE 통합형으로 시작했지만 2025년부터 Background Tasks로 비동기 영역에 들어왔다. Devin은 풀스택 자율 SaaS다. 둘 다 잘 만든 도구다.

그래도 jira-agent를 직접 만들 이유가 있었다. 첫째, Jira-driven이라 IDE도 Cursor 화면도 안 켜도 된다. Jira 티켓에 스펙만 적으면 5분 안에 워커가 가져간다. 둘째, 로컬 LLM 우선이다. 기본 백엔드가 Qwen3.6 35B (Ollama), 무료. 유료 백엔드(Claude, Kimi)는 옵션이다. Cursor Background Tasks는 cloud 인프라 + Cursor 구독료가 기본이고, Devin은 SaaS 비용이 든다.

흐름은 8 action 시퀀스

Jason         Jira Cloud         M4 Mac Studio              GitHub
─────         ──────────         ─────────────              ──────
티켓 작성  ─→  description    
              labels=ai-impl  
                              ─→ worker (launchd 상주)
                                  └─ polling 5분
                                  └─ 8 action 시퀀스
                                     ├─ spec_validate
                                     ├─ branch_create
                                     ├─ impl (LLM)
                                     ├─ test_write (LLM)
                                     ├─ test_run_local (red-green)
                                     ├─ push
                                     ├─ pr_create
                                     └─ ci_monitor
                              ←─ comment "✅ ok"

핵심은 TDD red-green 검증이다. test_write 단계가 끝나면 새로 쓴 테스트가 실제로 fail하는지 확인한다 (red 단계). impl을 stash해서 테스트만 돌렸을 때 fail이 안 나면 거부한다. 가짜 테스트 차단이다.

KAN-9 사례

티켓 본문은 이렇게 적었다.

## Target File
src/utils/version_bump.py

## Related Files
- src/utils/version_bump.py
- src/utils/_semver.py

## Acceptance Criteria
- _semver.py has parse_semver(version: str) -> tuple[int, int, int]
- version_bump.py has bump_version(version: str, kind: str) -> str
- bump_version("1.2.3", "patch") returns "1.2.4"
- bump_version with bad kind raises ValueError

## Test Examples
- tests/test_version_bump.py::test_parse_semver_returns_tuple
- tests/test_version_bump.py::test_bump_patch

워커가 처리한 Jira 코멘트 로그는 이랬다.

🤖 [spec_validate] ✅ ok (0.5s)
🤖 [branch_create] ✅ ok (0.5s) — branch=jira-agent/KAN-9
🤖 [impl] ✅ ok (66s) — files=[src/utils/version_bump.py, src/utils/_semver.py]
🤖 [test_write] ✅ ok (28s)
🤖 [test_run_local] ✅ ok (0.5s)
🤖 [push] ✅ ok (1.8s)
🤖 [pr_create] ✅ ok (2.1s) — PR #5
🤖 [ci_monitor] ✅ ok (22.6s)

3 파일이 PR에 들어갔다. version_bump.py 32줄, _semver.py 22줄, test_version_bump.py 30줄. 총 84줄. 티켓 적은 뒤로 남은 사람 작업은 PR 머지뿐이었다.

중단 규칙

워커가 무한루프나 가짜 완료에 빠지지 않도록 3가지 중단 규칙이 들어 있다.

  • loop_no_progress: LLM이 tool call 50회 넘게 돌았는데 worktree diff가 0이면 blocked로 떨어뜨린다. 무한루프 멈춤.
  • fake_done_no_evidence. impl이 ok로 끝났는데 changed_files가 비어있으면 가짜 완료로 처리한다.
  • stale_blocker: blocked 상태가 30분 지나면 Jira 코멘트 + macOS 알림을 보낸다.

원래는 cost_cap_exceeded도 들어 있었다. LLM 비용 누적이 한도 넘으면 멈추는 규칙이다. 다만 Qwen이 cost_usd를 보고하지 않아서 현재 운영에서는 작동할 일이 없다. 무료 로컬 LLM만 쓴다면 빼도 된다. Claude·Kimi 같은 유료 backend로 갈 사람은 처음부터 넣어두는 게 좋다.

한계

  • loop_no_progress 실 트리거가 production에서 0회. unit 테스트로만 검증됐다. 작동 검증은 paid backend 단계에서 한다.
  • Qwen 품질은 L1~L5 단순 task만 검증됐다. L6(KAN-9 multi-file)까지는 됐지만, 복잡한 비즈니스 로직이나 라이브러리 깊은 호출은 미검증이다.
  • mDNS 의존. M4 워커는 jaeseung-ui-MacStudio.local로만 접근된다. 외부망에서 안 됨. webhook도 Cloudflare Tunnel 없이는 불가.

다음 단계

지금 검증 범위는 Qwen 무료 backend의 L1~L5 task다. L6 multi-file은 KAN-9 한 번 됐다. 다음 검증은 paid backend로 복잡한 비즈니스 로직을 돌리는 단계다.

참고

댓글

댓글 쓰기

이 블로그의 인기 게시물

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

맥 스튜디오 M4 Max 128GB 로컬 LLM 4개 속도 비교 — gemma4·llama3.3·qwen3 실측

이미지
결론: M4 Max 128GB에서 가장 빠른 건 120B가 아니라 26B Dense 모델이다. 이유는 MoE 구조의 메모리 접근 패턴. 4개 모델 실측(tok/s 기준) + ChatGPT Plus 쿼터 제약 우회 대안 정리. 타이틀이 약속한 반전, 왜 생겼나 gpt-oss:120b 는 117B 파라미터짜리 MoE 구조. 총량은 117B지만 토큰 생성 한 번에 활성화되는 건 5.1B 정도. 이론적으로는 작은 모델만큼 빨라야 한다. 현실은 달랐다. MoE는 토큰마다 활성화되는 “전문가”가 바뀐다. 그래서 모델 전체(65GB)가 메모리에 상주해야 하고, 토큰마다 접근 위치가 비국소적(non-local)으로 흩어진다. 활성 파라미터 5.1B라는 숫자만 보면 훨씬 빨라야 맞다. 실제로 요구되는 메모리 대역폭은 전체 모델 크기에 가깝다는 얘기. 이 비교에서 직접 확인한 결과다. 반면 gemma4:26b 는 Dense 모델. 26B가 전부 계산에 참여한다. 파라미터 수 자체는 많지만 메모리 접근이 선형적이라 Apple Silicon의 통합 메모리 대역폭(546GB/s)을 효율적으로 쓸 수 있다. 같은 하드웨어에서 Dense가 MoE를 앞지르는 지점이 여기. 맥에서 로컬 LLM 고를 때 “MoE니까 활성 파라미터 작으면 빠르겠지” 하는 직관이 깨지는 순간. 테스트 환경 하드웨어는 Mac Studio M4 Max, 통합 메모리 128GB, 메모리 대역폭 546GB/s. 런타임은 Ollama 0.20.7 (llama.cpp 기반). 동일 프롬프트 3종 — 짧은 한국어, 짧은 수학, 긴 코드 생성. Cold start(첫 로드)와 Warm(모델 올라간 상태)을 분리 측정. 결과 4-way 비교표. 단위 tokens/second(tok/s). Prompt eval은 프롬프트 입력 처리 속도(초당 토큰 몇 개를 읽어들이는가), Generation은 응답 생성 속도(초당 토큰 몇 개를 출력하는가). 모델 크기(디스크) 활성 파라미터 Cold Load ...
자세한 내용 보기

Claude Code로 블로그 발행 15분을 1줄로 — 해고 후 첫 자동화 경험

Claude Code로 블로그 자동 발행 스크립트를 만드는 방법이다. 마크다운 파일을 터미널에서 명령어 한 줄로 Blogspot에 발행한다. Google Cloud Console 설정 10분, Claude Code에 지시 20분, 테스트 5분이면 끝난다. 코드를 직접 쓰지 않고 Claude Code에게 지시만 해서 만들었다. Claude Code가 뭔가 터미널에서 “블로그 발행 자동화해줘”라고 치면 스크립트를 만들어주는 AI 코딩 도구다. Anthropic이 만들었다. IDE 플러그인이 아니라 독립 CLI 도구다. 프로젝트 폴더 전체를 읽고, 파일을 직접 생성하고 수정하고 실행까지 한다. 블로그 글 1편 올리는 데 15분이 걸렸다 Blogspot에 글을 올리려면 마크다운 → HTML 변환 → Blogger 접속 → 제목 입력 → HTML 모드 전환 → 본문 붙여넣기 → 라벨 설정 → 검색 설명 → 미리보기 → 발행. 1편에 15분. 한 달에 30편이면 7시간 이상을 “올리는 작업”에만 쓰는 셈이다. 글 쓰는 시간보다 올리는 시간이 더 길었다. 이걸 Claude Code에게 맡겼다. Claude Code에게 한 지시 터미널에서 Claude Code를 열고 이렇게 말했다: “마크다운 파일을 Blogger API v3으로 자동 발행하는 Python 스크립트를 만들어줘. frontmatter에서 제목, 라벨, 슬러그를 읽고, 마크다운을 HTML로 변환한 뒤, OAuth 2.0으로 인증해서 Blogger에 POST해줘. dry-run 옵션도 넣어줘.” Claude Code가 만든 것: publish.py 메인 스크립트 (약 200줄) requirements.txt 의존성 목록 config.json 설정 파일 OAuth(구글 로그인 인증) 흐름 (최초 1회 브라우저 인증 → 이후 자동) dry-run 모드 (발행 없이 HTML 미리보기) ...
자세한 내용 보기