오늘 QCP 작업을 마무리하다가 꽤 재미있는 걸 다시 느꼈다.

“AI 에이전트에게 도구가 많으면 좋다”는 말은 많이 한다. 그런데 실제로 중요한 건 도구 개수가 아니었다.

진짜 중요한 건 이거였다.

상황에 맞는 스킬을 언제 꺼내 쓰느냐

이번 QCP-5442 작업은 딱 그 예시였다.

처음에는 Jira 티켓 하나를 분석하는 일이었다. 그런데 흐름이 점점 커졌다.

Jira 이슈 분석
→ QueryPie 코드 원인 추적
→ Front + Engine 패치
→ 실제 브라우저 검증
→ Heroshot 증빙 이미지
→ dev-scripts 재현 기반 정리
→ 블로그 발행

이걸 그냥 머릿속 기억과 즉흥 명령으로만 하면 금방 꼬인다.

그래서 관련 스킬들을 “작업별 동료”처럼 불러서 썼다.

1. jira: 티켓의 문을 여는 담당자

QCP나 QPD 번호가 나오면 제일 먼저 필요한 건 Jira 맥락이다.

QCP-5442가 무슨 이슈인지
고객이 어떤 현상을 말했는지
어떤 컴포넌트가 관련 있는지
현재 상태가 무엇인지

이때 jira 스킬이 출발점이다.

이 스킬은 단순히 Jira API를 호출하라는 의미가 아니다. “Jira 이슈를 다룰 때 어떤 방식으로 접근해야 하는지”를 알려주는 작업 규칙에 가깝다.

예를 들면 이런 태도를 강제한다.

- QCP/QPD 번호가 나오면 Jira 맥락부터 본다
- 고객 정보나 민감값은 함부로 노출하지 않는다
- 댓글/상태/필드는 필요한 만큼만 확인한다
- 추측하지 않고 이슈의 실제 내용을 기준으로 분석한다

즉 jira는 문지기다.

“일단 티켓부터 정확히 읽고 들어가자”라고 말해주는 동료다.

2. querypie-qcp-ticket-analysis: 사건 현장 감식반

Jira 이슈를 읽었다고 바로 코드를 고치면 위험하다.

QCP는 보통 이런 질문들이 숨어 있다.

이게 실제 버그인가?
재현 조건은 뭔가?
영향 범위는 어디까지인가?
고객 설명과 코드 흐름이 맞는가?
패치가 필요한 곳은 UI인가, API인가, Engine인가?

여기서 querypie-qcp-ticket-analysis가 등장한다.

이 스킬은 QCP를 “티켓 하나”가 아니라 “분석해야 할 사건”으로 보게 해준다.

이번 QCP-5442에서도 핵심은 단순히 “password required 추가”가 아니었다.

진짜 질문은 이거였다.

username만 바꾸고 password를 비우면,
기존 저장 password와 새 username이 결합될 수 있는가?

이 질문을 잡아야 패치 방향이 선명해진다.

그래서 이 스킬은 감식반 같다.

현장 사진만 보고 결론 내리지 않고, 발자국과 동선과 원인을 하나씩 맞춰보게 만든다.

3. querypie: 동네 지리를 다 아는 선배

QueryPie는 모듈이 많다.

DAC
SAC
KAC
ACP
API
Engine
ARiSA
Front
Envoy
local runtime

처음 보는 사람이면 어디 로그를 봐야 하는지, 어떤 포트를 봐야 하는지, 어떤 디렉터리가 의미 있는지 찾다가 시간이 다 간다.

이때 querypie 스킬은 동네 지리를 다 아는 선배처럼 움직인다.

API 로그는 어디 있는지
Engine gRPC는 어디로 붙는지
로컬 비밀번호는 무엇인지
QCP 문서는 어디에 남겨야 하는지
런타임은 어떤 표준 스크립트를 써야 하는지

이런 기본 지식이 있으면 작업 속도가 확 올라간다.

중요한 건 이 스킬이 “코드를 대신 읽어준다”는 게 아니라, “어디부터 읽어야 하는지”를 알려준다는 점이다.

지도 없이 수색하는 것과, 지도를 들고 수색하는 건 완전히 다르다.

4. querypie-hotfix-patch-workflow: 안전모 쓴 현장 감독

코드 패치가 들어가면 리듬이 달라진다.

이제는 분석이 아니라 변경이다.

변경에는 항상 위험이 있다.

작업 브랜치가 맞는가?
worktree를 써야 하는가?
기존 변경을 건드리지 않았는가?
테스트는 무엇을 돌려야 하는가?
검증 증빙은 어디에 남겨야 하는가?
커밋은 어떻게 나눠야 하는가?

이때 querypie-hotfix-patch-workflow는 안전모 쓴 현장 감독이다.

“빨리 고치자”보다 “안전하게 고치자”를 먼저 말한다.

이번에도 제품 코드 패치와 문서/증빙, dev-scripts 정리를 분리했다.

커밋도 나눴다.

fix(apps/engine): Require password when overriding username
docs(qcp): Add QCP-5442 validation evidence toolkit
chore(dev-scripts): Add reusable repro helpers

이렇게 나누면 리뷰할 때 훨씬 편하다.

패치 자체를 볼 사람은 첫 번째 커밋을 보면 되고, 증빙 도구를 볼 사람은 두 번째를 보면 되고, 재현 기반을 볼 사람은 세 번째를 보면 된다.

작업이 커질수록 이런 분리가 정말 중요하다.

5. querypie-user-test-ui-capture: 카메라 든 QA 동료

코드 테스트만 통과했다고 끝이 아니다.

특히 UI 관련 QCP는 이렇게 물어봐야 한다.

실제 브라우저에서 정말 그렇게 보이는가?
사용자가 누르는 흐름 그대로 검증했는가?
증빙 이미지를 고객/PM/QA가 이해할 수 있는가?

여기서 querypie-user-test-ui-capture가 필요하다.

이번에는 Playwright로 실제 Chrome을 실행했다.

Playwright
→ 로컬 Google Chrome
→ QueryPie UI 접속
→ querypie-metadb 선택
→ username=root 입력
→ password 비움
→ Connect 클릭

그리고 결과를 봤다.

Validation visible: True
Engine open request count after click: 0

이 두 줄은 생각보다 강하다.

“화면에 에러가 보였다”뿐 아니라 “실제 Engine 요청이 나가지 않았다”는 뜻이기 때문이다.

그다음 Heroshot으로 증빙 이미지를 만들었다.

처음엔 1440px 이미지라 글씨가 작았다. 그래서 2880px 고해상도 버전으로 다시 뽑았다.

여기서 중요한 교훈 하나.

증빙은 예뻐야 하지만, 읽혀야 한다.

그리고 더 중요한 교훈.

토큰은 절대 예쁘게 노출하면 안 된다.

그래서 qp_access_token=[REDACTED]처럼 민감값은 전부 마스킹했다.

6. secrets-index-workflow: 비밀 위치만 알려주는 금고 관리자

작업하다 보면 결국 secret을 찾게 된다.

Jira token 어디 있지?
elon-api-token은 뭔가?
Slack bot token은 어디에 있지?

이때 가장 위험한 습관은 “일단 grep으로 다 뒤져보자”다.

시크릿은 값보다 위치 관리가 중요하다.

그래서 secrets-index-workflow를 쓴다.

이 스킬의 태도는 명확하다.

- 먼저 secrets-index.md를 본다
- 실제 값이 아니라 위치와 변수명을 확인한다
- 값은 필요한 경우에만 최소한으로 사용한다
- 문서나 커밋에 raw secret을 남기지 않는다

이번에도 elon-api-token과 Jira token을 확인할 때 이 원칙을 따랐다.

결론은 이랬다.

Jira MCP는 OAuth로 이미 연결됨
REST API용 token은 Atlassian API token 페이지나 1Password에서 확인
secrets-index에는 위치만 등록하는 게 좋음

이 스킬은 금고 관리자 같다.

비밀번호를 큰 소리로 읽어주는 사람이 아니라, “금고는 저쪽이고, 열 때는 조용히 열어”라고 말해주는 사람이다.

7. sparks-blog-publishing: 이야기로 남기는 편집자

마지막은 블로그 발행이다.

작업이 끝나면 코드와 커밋만 남기기 쉽다. 그런데 어떤 작업은 이야기로 남겨야 다음에 다시 쓸 수 있다.

이번 QCP 작업이 딱 그랬다.

어떤 문제가 있었는지
어떤 스킬을 썼는지
왜 Playwright와 Heroshot을 붙였는지
왜 dev-scripts를 정리했는지
다음 QCP에서 어떻게 재사용할 수 있는지

이걸 블로그로 남기면 개인 회고가 아니라 팀 자산이 된다.

sparks-blog-publishing은 이 과정을 정리해준다.

Markdown 작성
frontmatter 구성
Sparks builder로 HTML 생성
published manifest 업데이트
Cloudflare Pages 배포

즉 작업을 “끝났다”에서 멈추지 않고 “공유 가능한 지식”으로 바꿔준다.

스킬은 치트키가 아니라 작업 동료다

이번에 다시 느낀 핵심은 이거다.

스킬은 마법 주문이 아니다.

이 스킬을 부르면 문제가 자동으로 해결된다

가 아니다.

오히려 스킬은 역할이 뚜렷한 동료에 가깝다.

jira                         티켓 문지기
querypie-qcp-ticket-analysis 사건 현장 감식반
querypie                     동네 지리 잘 아는 선배
querypie-hotfix-patch-workflow 안전모 쓴 현장 감독
querypie-user-test-ui-capture 카메라 든 QA 동료
secrets-index-workflow        금고 관리자
sparks-blog-publishing        편집자

좋은 에이전트 운영은 이 동료들을 적절한 순서로 부르는 일이다.

내가 좋아하는 사용 순서

QCP 하나를 제대로 처리한다면, 나는 보통 이렇게 간다.

1. jira
   티켓 맥락 확인

2. querypie-qcp-ticket-analysis
   재현 조건과 영향 범위 분석

3. querypie
   QueryPie 도메인/런타임/로그 위치 확인

4. querypie-hotfix-patch-workflow
   worktree, 패치, 테스트, 커밋 흐름 정리

5. querypie-user-test-ui-capture
   실제 브라우저 검증과 Heroshot 증빙 생성

6. secrets-index-workflow
   token/credential이 필요할 때 위치만 안전하게 확인

7. sparks-blog-publishing
   작업 내용을 블로그/지식 자산으로 발행

이 순서가 좋은 이유는 단계마다 질문이 달라지기 때문이다.

무슨 문제지?
왜 발생하지?
어디를 고쳐야 하지?
안전하게 어떻게 고치지?
실제로 동작하나?
민감값은 안전한가?
배운 걸 어떻게 남기지?

질문이 바뀌면 필요한 스킬도 바뀐다.

이번 작업의 진짜 수확

QCP-5442에서 남은 건 패치 하나가 아니다.

Front + Engine 이중 방어
Playwright 실제 브라우저 검증
Direct Engine gRPC probe
Heroshot 고해상도 증빙 이미지
Playwright evidence toolkit
dev-scripts qpie_repro 공통 기반
블로그 발행 흐름

이제 다음 QCP에서 우리는 더 빨리 말할 수 있다.

실제 화면에서 돌려봤고,
서버 직접 호출도 때려봤고,
증빙 이미지까지 뽑아놨어요.

이건 단순한 자동화가 아니다.

팀의 신뢰도를 올리는 자동화다.

한 줄 요약

Hermes 스킬은 잘 쓰면 “명령 모음”이 아니라 “작업 동료 팀”이 된다.

티켓을 읽는 동료,
원인을 추적하는 동료,
패치를 안전하게 이끄는 동료,
브라우저로 검증하는 동료,
비밀을 지키는 동료,
마지막에 이야기로 남기는 동료.

이 동료들을 잘 부르면, 버그 하나를 고치는 일이 다음 버그를 더 잘 고치는 시스템으로 바뀐다.

그게 이번 작업에서 제일 신났다.