Xinics Skill Plugin

같은 Jira 이슈를 맡겨도 에이전트의 결과는 일정하지 않았습니다. 원인은 모델 자체보다 단계, 입력과 완료 조건이 정의되지 않은 실행 구조에 있었습니다.

기술 조사부터 설계, 구현, 리뷰, 검증과 보고까지 책임과 진입 조건을 나눴습니다. 사람이 직접 실행하든 에이전트에 맡기든 같은 산출물과 검증 절차를 거치도록 했습니다.

Night Worker에서도 같은 단계 정의를 재사용해야 했습니다. 대화 유무와 상관없이 중단 조건과 검증 명령이 동작하도록 스킬 계약을 구조화했습니다.

내부 Bitbucket 인증을 유지할 수 있도록 로컬 마켓플레이스로 배포했습니다. 저장소에서 변경을 받은 뒤 plugin update로 적용하는 절차도 팀 문서에 남겼습니다.

기술 탐색, 계획, 구현, 리뷰와 검증을 서로 다른 책임과 진입 조건으로 분리했다. 오케스트레이터가 Jira 이슈 상태와 이전 산출물을 읽어 다음 단계로 연결하고, 검증 근거가 없으면 완료로 처리하지 않습니다.

기억할 대상은 대화가 아니라
다시 쓸 수 있는 판단입니다.

이전 작업에서 확인한 제약과 실패 원인을 다음 이슈에서 다시 찾고 설명해야 했습니다. 반대로 대화 전체를 넣으면 오래된 규칙과 불필요한 맥락이 함께 검색됐습니다.

6월에는 완료된 작업에서 재사용할 판단만 남긴다는 가설로 기억 계약을 설계했고, 7월에는 Xinics Brain으로 구현해 플러그인에 추가했습니다. 저장 단위는 결정, 불변 조건, 실패 패턴, 검증 근거와 고객사별 판단 주의사항입니다.

고객사별 기억에는 배포 제약, 승인 조건, 피해야 할 구현 패턴처럼 작업 판단에 필요한 주의사항도 담았다. 고객사와 프로젝트 범위를 조회의 첫 조건으로 두어 다른 환경의 규칙이 섞이지 않게 했고, 팀 범위 기억에는 출처를 필수로 두었다. 비밀 정보와 개인 정보는 수집 대상에서 제외했다. 충돌하거나 낡은 기억은 조용히 누적하지 않고 대체 이력을 남긴다. 덕분에 에이전트가 과거 결정을 무조건 따르는 대신, 현재 작업에 적용 가능한 근거인지 사람이 추적할 수 있다.

계획, 구현, 리뷰, 검증, 커밋, 보고 단계와 각 산출물을 한 흐름에서 추적할 수 있게 됐다. 실행 기록으로 어느 단계와 검증 명령을 거쳤는지 확인할 수 있다.

Night Worker에서는 같은 단계 정의를 비대화형 작업에 사용한다. 완료된 작업은 커밋과 보고 산출물을 남기지만, 병합과 배포 전에는 사람이 결과를 검토한다.

verify 스킬은 QA 시나리오와 테스트 결과를, report 스킬은 비기술적 변경 요약을 산출한다. 이 산출물은 검토를 돕지만 코드의 정확성이나 테스트 완전성을 보장하지 않는다.

Xinics Brain은 이전 작업의 결정과 실패 패턴, 고객사별 판단 주의사항을 현재 이슈에 재사용하고, 각 기억을 Jira·Confluence·커밋·테스트 근거까지 추적할 수 있게 했다. 다만 기억이 검색됐다는 사실이 현재 맥락에서의 정답을 뜻하지 않으므로, 적용 범위와 검증 게이트는 그대로 유지한다.

정량적인 품질 변화는 아직 측정하지 않았습니다. 다음 과제는 동일한 이슈 표본에서 반복 질문, 오래되거나 잘못 검색된 기억, 문맥 토큰 사용량과 검증 실패율을 도입 전후로 비교하는 일입니다.