얼쑤에서 AI에 푸시를 맡기려면 먼저 무엇을 확인해야 할지 정해야 했습니다. 개발 브랜치가 바뀌었는지, 기존 테스트 결과를 재사용해도 되는지, Jira에는 언제 무엇을 남겨야 하는지가 모두 판단 대상이었습니다. HTTPS 전환 작업에서는 최신 개발 브랜치가 이미 작업 브랜치에 포함돼 검사 19개의 결과를 재사용했습니다. 서버 점검 작업에서는 새 변경을 통합한 뒤 테스트 13개를 다시 실행했습니다. 두 사례를 놓고 보면 팀별 기록 규칙과 검증을 다시 할 조건을 각각 어디에 둘지가 문제였습니다.

저장소 규칙과 스킬 절차

Team Edo는 10월 21일 COCO 0.2.0을 기준으로 저장소 작업 지침을 정리했습니다. 0.2.0 패키지에는 세션에서 다룬 개념이나 설계 결정을 다시 질문할 수 있는 coco-askme도 추가됐습니다. 팀 저장소에 연결하는 과정에서는 구현과 검증을 안내하는 공통 절차를 COCO에 두고, 어떤 Jira 작업에 연결하는지와 브랜치·커밋 이름에 전체 Jira 키를 넣는 규칙은 저장소 지침에 남겼습니다. COCO 0.2.0 소스

구현 중에 바뀌는 계획과 검증 결과는 작업 계획 문서에 쌓았습니다. Jira에는 착수할 때 목적과 범위를 확인하고, 첫 푸시 직전에 결과와 검증을 기록했습니다. 작업 단위의 검증과 커밋은 coco-build에서 다뤘고, 원격 브랜치와의 통합 및 첫 푸시 기록은 coco-push에서 다뤘습니다. 서버 점검 작업의 병합 요청은 초안으로 올려 팀이 검토할 수 있게 했습니다.

재검증이 필요한 조건

HTTPS 전환과 서버 점검의 차이는 마지막으로 검증한 코드에 통합 브랜치의 변경이 새로 들어왔는지였습니다. 푸시 전에 어떤 코드가 검증을 받았는지 대조하면, 테스트를 이미 한 경우에도 결과를 그대로 쓸 수 있는지 판단할 수 있습니다. 두 작업 기록에는 호출한 스킬과 검증 결과가 남아 있습니다. 당시 저장소가 정한 기준은 0.2.0이었고, 각 실행에서 설치된 패키지 버전은 별도로 기록하지 않았습니다.

이 시기의 운영 방식은 Jira와 Git을 사용하던 팀에 맞춰져 있었습니다. 이후 COCO를 다른 프로젝트에도 설치하면서, 팀마다 다른 규칙을 공통 스킬에서 어떻게 다룰지가 다시 과제가 됐습니다.