이 페이지는 다른 문서에서 참조하는 기준점입니다. 실행 단계별 명칭이 명시되어 있어 다른 문서에서 특정 작업이 발생하는 위치를 정확히 파악할 수 있습니다.
경로
- 1
사양 정의무엇을 구축할 것인지와 그 작동 여부를 확인하는 방법
설계자귀하가 수정 가능 - 2계획 수립
코드 작성 전에 검토되는 순차적 단계들
설계자귀하가 승인 - 3
구현 및 빌드격리된 작업 공간에서 작성된 코드와 테스트
개발자 - 4
검증 수행귀하의 테스트 스위트와 함께 품질 검증 절차도 포함됨
QA - 5
리뷰 진행차이점에 대한 자동화된 리뷰 과정
리뷰어 - 6풀 리퀘스트 생성
귀하의 저장소 내 브랜치에 위치하며 귀하의 승인을 기다림
귀하가 병합
검증 실패나 수정 가능한 리뷰 결과는 pull request가 생성되기 전에 개발자에게 재작업으로 다시 전달됩니다.
두 가지 작업 실행 방식에서 이 단계들은 동일하게 적용됩니다. 표준 모드에서는 플랫폼이 작업을 한 단계씩 순차적으로 진행합니다. 코디네이터 모드에서는 계획 에이전트가 코디네이터로서 해당 작업을 담당하며, 각 단계를 적절한 에이전트에게 할당하고 각 결과에 따라 다음 진행 방향을 결정하며 작업을 다시 보내는 경우도 포함됩니다. 어떤 방식이든 단계는 해당 단계의 검증 절차를 통과해야 종료됩니다. 자세히 알아보려면에이전트 역할에서 두 모드의 차이점을 확인할 수 있습니다.
사양
Coroid는 사용자의 설명에서 바로 시작되지 않습니다. 먼저 사용자의 설명을사양: 구현할 내용, 명시적으로 범위에서 제외되는 항목, 그리고 작업이 성공했는지 판단하는 수락 기준을 정의합니다.
이러한 수락 기준은 이후 검증 단계에서 테스트의 기준이 되므로 매우 중요합니다. 모호한 사양으로 인해 작업의 적합성을 판단하기 어려워집니다.
작업의 사양은 작업 페이지의사양탭에서 확인 및 편집할 수 있으며, 실행 전에 반영됩니다.
이사양 기반 개발 가이드에서는 테스트 가능한 기준을 작성하는 방법, 범위 경계를 설정하는 방법, 그리고 계획·구현·리뷰 단계에 걸쳐 동일한 성공 정의를 유지하는 방법을 설명합니다.
계획
소규모 변경 사항을 넘어서는 작업의 경우, 사양은계획: 순서가 정해진 단계들의 집합으로, 여러 단계로 구성됩니다. 코드 작성 전에 계획을 승인해야 합니다.
계획을 거부하는 데 드는 비용은 낮으며, 접근 방식이 잘못된 경우에는 이를 거부하는 것이 올바른 선택입니다. 코드 작성 후에 거부하면 비용이 크게 증가합니다. 이 단계에서 사용자의 판단력이 가장 큰 영향력을 발휘합니다.
구축
에이전트는 저장소를 격리된 작업 공간에 복제한 뒤 그곳에서 작업을 수행합니다. 코드를 읽고 변경 사항을 작성하며 테스트를 작성하거나 업데이트합니다.
작업 공간은 일회용이며 작업별로 별도로 제공됩니다. 에이전트의 작업 내용이 기본 브랜치에 영향을 주지 않으며, 동시에 실행되는 두 작업도 서로의 진행 중인 작업 내용을 확인할 수 없습니다.
검증
먼저 사용자 고유의 테스트 스위트가 실행됩니다. 이는 팀에서 이미 중요하다고 판단한 사항을 반영하기 때문에 가장 신뢰할 수 있는 지표입니다.
이 외에도,품질 게이트조직에서 설정한 규칙에 따라 실행됩니다: 코드 커버리지 임계값, 린팅, 보안 스캔, 미리보기 배포 환경에서의 브라우저 테스트 등이 포함됩니다. 차단형 게이트는 작업을 중단시키고, 권고형 게이트는 발견 사항을 기록한 뒤 작업을 계속 진행합니다.
리뷰
리뷰어 에이전트는 동료가 하는 방식과 유사하게 코드 변경 내용을 확인하고 발견 사항을 생성합니다. 수정 가능한 발견 사항은 재작업을 위해 다시 전달되고, 나머지 발견 사항은 pull request에 첨부되어 확인할 수 있습니다.
이러한 이유로 Coroid pull request는 이미 리뷰가 완료된 상태로 제공됩니다. 이는 사용자의 리뷰를 대체하기 위함이 아니라, 사용자의 리뷰가 최초의 검토 단계가 되지 않도록 하기 위함입니다.
풀 요청
브랜치를 푸시하면 기본 브랜치에 대응하는 pull request가 생성되며, 해당 브랜치에는 변경 사항, 테스트 결과, 검증 결과 및 리뷰 내용이 포함됩니다. 만약 코드가 이미 작업 요구사항을 충족한다면 별도로 푸시할 필요가 없습니다. 대신 QA에서 변경되지 않은 코드를 검증하며, 이 경우 pull request 없이 작업이 완료됩니다.
Coroid의 작업 자동화는 여기서 종료됩니다. 병합은 사용자가 직접 수행합니다.
병합 이후
열기릴리스배포할 정확한 커밋을 준비하기 위해 릴리스를 생성합니다. 하나의 릴리스에는 여러 개의 병합된 풀 요청, 직접 커밋, 또는 Coroid 외부에서 병합된 작업이 포함될 수 있습니다. 릴리스 게이트와 승인 절차는 해당 커밋 및 특정 환경을 대상으로 적용됩니다. 파이프라인이 이를 배포하며, Coroid는 배포 성공 여부나 명시적 증명을 기록한 뒤에야 '배포 완료'로 표시합니다. '활성' 상태로 표시된 작업COMPLETED또는 병합된 pull request만으로는 배포가 완료되었음을 입증할 수 없습니다.
작업 상태
작업의 상태는 위의 프로세스에서 현재 진행 중인 단계를 나타냅니다:
| 상태 | 의미 |
|---|---|
PENDING | 접수됨, 사용 가능한 에이전트 슬롯을 기다리는 중 |
IN_PROGRESS | 현재 작업 중 |
PENDING_REVIEW | 작업이 완료되고 리뷰를 거쳤으며, 통합 또는 승인을 기다리는 중 |
COMPLETED | 작업이 완료되었으나 배포는 별도로 추적됨 |
NEEDS_HUMAN_REVIEW | Coroid는 스스로 진행할 수 없어 사용자의 확인을 요청하는 중입니다. |
PAUSED | 일시적으로 중단됨, 재개 가능 |
FAILED | 실행을 완료할 수 없음 |
CANCELLED | 사용자에 의해 중단됨 |
WONT_FIX | 작업을 수행하지 않고 의도적으로 종료됨 |
처리량을 결정하는 요인은 무엇인가요?
하나의에이전트 슬롯는 한 번에 하나의 작업만 실행합니다. 슬롯은 병렬로 처리되는 작업량을 설정할 뿐, 개별 작업의 완료 속도를 높여주지는 않습니다. 작업 자체의 소요 시간은 변경 사항의 규모와 테스트 스위트의 실행 시간에 따라 결정됩니다.
다음
에이전트 역할— 각 작업 단계를 어떤 에이전트가 담당하는지 확인해 보세요. 그 다음에릴리스를 통해 병합 후 환경에서의 배포 경로를 확인할 수 있습니다.