작업이 pull request로 전환되는 과정

이 페이지는 다른 문서에서 참조하는 기준점입니다. 실행 단계별 명칭이 명시되어 있어 다른 문서에서 특정 작업이 발생하는 위치를 정확히 파악할 수 있습니다.

경로#

your description
   │
   ▼
   specification   what will be built, and how you will know it worked
   │
   ▼
   plan            the ordered steps, reviewed before any code is written
   │
   ▼
   build           code and tests written in an isolated workspace
   │
   ▼
   verify          your test suite, plus checks and quality gates
   │
   ▼
   review          an automated review pass over the diff
   │
   ▼
   pull request    on a branch, in your repository, waiting for you

사양#

Coroid는 사용자의 문장으로 바로 시작되지 않습니다. 먼저 사용자의 설명을사양: 구체적으로 무엇을 개발할지, 범위에서 제외될 항목은 무엇인지, 그리고 작업 성공 여부를 판단하는 수용 기준을 정의합니다.

이러한 수용 기준이 중요한 이유는 이후 검증 단계에서 이를 기준으로 테스트하기 때문입니다. 모호한 사양으로 인해 작업 결과를 판단하기 어려워집니다.

작업의 사양 내용은 작업의 "Specification" 탭에서 확인 및 편집할 수 있습니다.Specification탭에서 실행을 시작하기 전에 해당 내용을 확인하세요.

"사양 기반 개발 가이드테스트 가능한 기준을 작성하고, 범위 경계를 설정하며, 계획·구현·리뷰 단계에 걸쳐 동일한 성공 정의를 적용하는 방법을 설명합니다.

계획#

소규모 변경 사항을 넘어서는 경우, 사양은 "계획": 단계별로 그룹화된 순차적 작업 목록입니다. 코드 작성 전에 이 계획을 승인해야 합니다.

계획을 거절하는 것은 비용이 적게 들며, 접근 방식이 잘못되었을 때 올바른 선택입니다. 코드 작성 후에 거절하는 것은 비용이 많이 듭니다. 이 단계에서 관리자의 판단력이 가장 큰 영향력을 발휘합니다.

구축#

에이전트는 저장소를 격리된 작업 공간에 복제한 뒤 그곳에서 작업합니다. 코드를 읽고 변경 사항을 작성하며 테스트를 작성하거나 업데이트합니다.

작업 공간은 작업별로 별도로 생성되며 일회용입니다. 에이전트의 작업 내용이 기본 브랜치에 영향을 주지 않으며, 동시에 실행되는 두 작업이 서로의 진행 중인 작업을 볼 수 없습니다.

검증#

가장 먼저 자체 테스트 스위트가 실행됩니다. 이는 팀에서 중요하다고 판단한 사항을 반영하기 때문에 가장 신뢰할 수 있는 지표입니다.

이 외에도품질 게이트조직에서 설정한 규칙에 따라 작동합니다: 커버리지 임계값, 린팅, 보안 스캔, 미리보기 배포 환경에서의 브라우저 테스트 등입니다. 차단형 게이트는 작업 진행을 중단시키고, 권고형 게이트는 발견 사항을 기록한 뒤 작업을 계속하도록 허용합니다.

리뷰#

리뷰어 에이전트는 동료가 하는 것과 같이 변경 내용을 확인하고 발견 사항을 도출합니다. 수정이 필요한 발견 사항은 재작업을 위해 다시 전달되고, 나머지는 pull request에 첨부되어 확인할 수 있습니다.

따라서 Coroid pull request는 이미 리뷰를 거친 상태로 제공됩니다. 이는 사용자의 리뷰를 대체하기 위함이 아니라, 사용자의 리뷰가 최초의 검토가 되지 않도록 하기 위함입니다.

Pull request#

브랜치가 푸시되면 기본 브랜치에 대해 pull request가 생성되며, 여기에 변경 사항, 테스트 결과, 검증 결과 및 리뷰 발견 사항이 포함됩니다.

Coroid는 여기서 작업을 마칩니다. 병합은 사용자가 직접 처리합니다.

작업 상태#

작업의 상태를 통해 위에 설명한 프로세스 내에서의 진행 위치를 확인할 수 있습니다:

처리량을 결정하는 요인#

하나의에이전트 슬롯이 동시에 하나의 작업만 처리합니다. 슬롯 수는 병렬로 처리되는 작업량을 결정할 뿐, 개별 작업의 완료 속도에는 영향을 주지 않습니다. 작업의 소요 시간은 변경 사항의 규모와 테스트 스위트의 실행 시간에 따라 결정됩니다.

다음#

에이전트 역할— 각 단계를 담당하는 에이전트와 그에게 허용된 작업 범위를 확인할 수 있습니다.