하나의상시 지침은 사람이 일일이 요청하지 않아도 Coroid가 어떤 작업을 수행할지 정해 둔 상시 지침입니다. 목표, 적용 프로젝트, 주간 또는 월간 예산, 작업을 중단할 시점이 여기에 포함됩니다. 작업 접수 API, 자동화, 연동, 모니터링 등 시스템에서 들어오는 요청은 활성화된 상시 지침에 따라 접수됩니다. 사람이 직접 요청한 작업은 해당되지 않습니다. 자세히 알아보세요.상시 지침이 적용되는 요청.
Coroid가 결정하는 사항과 사용자가 직접 관리하는 사항Coroid가 결정하는 것과 사용자가 직접 결정하는 것.
상시 지침이 유용한 경우
작업 접수 Coroid를 통해 오류를 보고하는 오류 추적 도구 또는 모니터링 시스템;
- API에서 생성되는 이슈나 Slack, Telegram, Jira 메시지 등이
- GitHub 이슈, Slack, Telegram, Jira 메시지 또는 한 번에 하나씩 결과를 등록하는 스캐너나 CI 작업자동화 기능이 요청으로 전환됩니다;고객이 제기하는 의견이나 지원 요청을 전달하는 도구;
- 결과를 하나씩 기록하는 스캐너나 CI 작업.
- 한 번에 하나씩 결과를 등록하는 스캐너나 CI 작업.
요청의 처리 과정
요청 처리 과정
사람 없이 도착한 요청
- 오류 추적기에서 발생한 경고로, 신규 작업 접수용 API로 전달되어 신호가 전달됩니다.
- 자격 검증 자동화를 통해 생성된 GitHub 이슈입니다.
- 지원 도구를 통해 들어온 고객 보고서로, 신규 작업 접수용 API를 통해 처리됩니다.
New Work에서 누군가 제출한 요청도 자격 검증을 거치지만, 이를 제한하는 지침은 없습니다.
자격 검증
데이터 정제, 현재 릴리스 확인, 중복 제거, 검증, 평가 및 라우팅이 진행됩니다.
접수
API 경로에 처리되지 않은 예외가 발생하지 않도록 관리하세요.
- 프로젝트
- 청구용 API
- 예산
- 주당 100 USD 및 에이전트 작업 시간 10시간
- 지침 할당량
- 2개 중 1개 사용 중, 4개 에이전트 슬롯 중 절반 할당됨
- 동일한 사건이 이미 다른 프로젝트에서 처리 중인가요?
- 평가 결과 해당 동작이 의도된 것인가요?
- 지침에서 할당한 슬롯 중 사용 가능한 것이 있나요?
- 이번 주에 남은 예산이 있나요?
- 결과를 측정할 수 있는가요? 그렇지 않으면 지침에서 해당 작업을 허용하지 않습니다.
해당 작업은 예약된 슬롯과 주간 예산의 일부를 할당받아 생성됩니다.
이미 처리 중인 작업과 연동됩니다. 새로 생성되는 항목은 없습니다.
해당 동작이 의도된 것입니다. 새로 생성되는 항목은 없습니다.
매분마다 다시 확인됩니다. 슬롯이나 예산이 확보되면 접수되고, 일주일이 지나면 처리가 종료됩니다.
접수 이후
작업
일반적인 작업과 마찬가지로 사양, 계획 및 코드가 포함됩니다.
검증
테스트, 품질 게이트, QA 및 리뷰가 진행됩니다.
풀 요청
별도의 브랜치에서 작성되어 사용자의 브랜치와 비교됩니다.
결과 계약
해당 경로에서 500회의 요청이 발생한 후 24시간 동안 이 사건에 대한 새로운 이벤트가 없어야 합니다.
작업 접수 API작업 접수 API작업 분류
- 는 다른 요청과 동일한 절차를 따릅니다. 기밀 정보와 개인 데이터를 제거하고 현재 배포 버전을 확인하며 중복 여부를 검사하고 보고 내용을 검증한 뒤 평가를 진행합니다.요청 수락
- 접수은 Billing API을 담당하는 상시 지침을 찾아 다음 항목을 순서대로 확인합니다. 같은 이슈가 현재 또는 다른 프로젝트에서 이미 처리 중인지, 평가 결과 해당 동작이 의도된 것인지, 상시 지침에 할당된 두 슬롯 중 하나가 비어 있는지, 이번 주 예산에 여유가 있는지, 결과를 측정할 수 있는지를 확인합니다.
- 접수되면요청은 예약된 슬롯과 주간 예산 일부가 할당된 작업이 됩니다. 사양 작성, 코딩, 테스트, 품질 검사, QA, 리뷰의 일반적인 절차를 거쳐 pull request으로 완료됩니다.
- 해당 작업의결과 계약 은 병합 후 달성해야 할 목표를 기록합니다. 즉, 해당 경로에서 500건의 요청이 발생한 뒤 24시간 동안 동일한 이슈가 다시 발생하지 않는 것입니다.동일한 알림이 다시 발생하면 두 번째 요청은
같은 알림이 다시 발생하면 두 번째 요청은이미 해결됨그리고 첫 번째 작업과 연결됩니다. 잘못된 배포로 한 번에 6개의 새로운 이슈가 발생하더라도, 동시에 명령에 따라 처리되는 작업은 2개를 넘지 않으며 나머지는연기됨, 그 후 명령의 슬롯이 비워질 때마다 하나씩 접수됩니다. 다른 두 개의 에이전트 슬롯은 귀사 팀에서 요청하는 '새 작업'을 위해 남겨둡니다.
명령 예시
운영 환경의 오류가 쌓이는 것을 방지하기
귀사의 API 서비스는 오류를 오류 추적기에 보고하며, 오류 수정 작업은 담당자가 시간이 있을 때 진행됩니다.
| 설정 | 값 |
|---|---|
| 유형 | 진행 중 |
| 목표 | 결제 정보 API의 경로에 처리되지 않은 예외가 발생하지 않도록 관리하기 |
| 프로젝트 | 결제 정보 API |
| 예산 | 주당 100 USD 및 에이전트 작업 시간 10시간 |
| 결과를 측정할 수 없는 작업 접수하기 | 꺼짐 |
| 리뷰 날짜 | 4주 후 |
오류 추적기를 통해 작업 접수 API로 요청이 들어오며, 각 요청에는 추적기의 이슈 ID, 경로 및 요청 건수가 포함됩니다.signal이 이름은 추적기의 이슈 ID, 경로 및 요청 건수를 나타냅니다. 각 이슈는 최대 한 개의 작업으로 처리되며, 이슈가 여러 번 발생하더라도 마찬가지입니다. 한 주 동안의 비용은 최대 100 USD로 제한됩니다. 경로 없이 전송된 알림은 즉시 시작되지 않고 대기 상태로 유지되는데, 이는 수정 결과를 확인할 방법이 없기 때문입니다. 경로를 함께 전송하거나결과를 측정할 수 없는 작업 접수하기.
GitHub에 보고된 버그를 처리하기
사용자가 웹 애플리케이션의 저장소에 이슈를 등록하는 속도가 누구보다도 빠르지만, 이를 분류하는 작업은 뒤처집니다.
| 설정 | 값 |
|---|---|
| 유형 | 진행 중 |
| 목표 | 웹 애플리케이션에서 사용자가 보고한 버그를 수정하기 |
| 프로젝트 | 웹 애플리케이션 |
| 예산 | 월 200달러 및 에이전트 시간 30시간 |
| 결과를 측정할 수 없는 작업을 허용하기 | 켜짐 |
하나의작업 검증하기GitHub에서 생성된 새 이슈마다 자동화가 각각의 작업을 처리합니다. 이를 통해 중복 이슈를 방지하고, 현재 릴리스에서 이미 수정된 사항에 대해서는 해당 이슈를 종결하며 재현할 수 없다고 보고합니다. 측정 가능성 스위치가 켜져 있는데, 이는 이슈에 경로나 트래픽 정보가 명시되지 않아 결과에 대한 계약을 측정할 수 없기 때문입니다. 이 스위치를 끄면 모든 이슈가 대기 상태에 머무르게 됩니다. 쓰기 권한이 있는 사용자가 연 이슈는 자동으로 시작되며, 그 외의 이슈는 누군가 시작할 때까지 대기하는데, 이에 대한 설명은 다음에서 확인할 수 있습니다.작업이 시작될 때.
고객이 보고한 내용에 따라 조치하기
지원 도구가 고객으로부터 보고서를 수집하지만, 긴급한 보고서는 엔지니어링 팀에 늦게 전달됩니다.
| 설정 | 값 |
|---|---|
| 유형 | 진행 중 |
| 목표 | 고객 포털에 보고된 내용을 수정하기 |
| 프로젝트 | 고객 포털 |
| 예산 | 주당 150달러 및 에이전트 시간 15시간 |
| 결과를 측정할 수 없는 작업을 허용하기 | 켜짐 |
지원 도구가 서비스 계정을 이용해 API를 통해 각 보고서를 작업으로 등록합니다. 검증 과정에서 재현할 수 없는 항목은 제외되며, 할당량 규칙에 따라 과도한 보고서로 인해 에이전트 시간이나 예산의 절반 이상이 소진되는 것을 방지합니다.
마감일 전에 정리 작업 완료하기
사용 중인 결제 SDK가 다음 분기에 지원이 종료되며, 더 이상 사용하지 않는 호출 코드가 두 개의 서비스에 걸쳐 분산되어 있습니다.
| 설정 | 값 |
|---|---|
| 유형 | 한정적 |
| 목표 | 더 이상 사용하지 않는 결제 SDK에 대한 모든 호출 코드를 제거하기 |
| 대상 | 더 이상 사용하지 않는 SDK 호출 최대 0회 |
| 프로젝트 | 결제 API 및 청구 |
| 예산 | 월 300달러 및 에이전트 시간 40시간 |
| 결과를 측정할 수 없는 작업을 허용하기 | 켜기 |
CI 작업은 호출 지점당 하나의 요청을 생성하며, 파일과 줄 번호를 신호 지문으로 사용합니다. 다음 실행 시 동일한 호출 지점이 다시 발견되면 이미 해당 작업을 처리 중인 요청에 연결됩니다. Coroid는 아직 대상 내용을 읽지 않습니다. 마지막 호출이 사라지면완료직접 수행하세요.
권한이 필요하지 않을 때
- 사람들이 요청하는 작업새 작업에서 생성되거나 가져온 요청은 조건을 충족하면 즉시 승인되며, 절대 연기되지 않고 권한의 예산도 사용하지 않습니다.
- 일정 및 후속 작업 처리이 요청들은 자격 검증 없이 직접 작업을 생성하므로 권한의 제한을 받지 않습니다. 대신 더 낮은 우선순위를 부여하세요. 자세한 내용은일정.
- 일회성 프로젝트형태와 종료 시점이 명확한 작업은 계획이며, 권한이 아닙니다.
- 중첩된 권한동일한 프로젝트를 여러 활성 권한이 담당하는 경우 가장 오래된 권한이 해당 요청을 관리합니다. 각 프로젝트는 하나의 권한에만 할당하세요.
권한의 위치
열기품질 관리 → 권한. 품질 관리 내의 모든 범위—조직 기본 설정 및 각 프로젝트—는 동일한 목록에 연결됩니다. 권한은 조직에 속하며 직접 프로젝트를 지정하기 때문입니다. 프로젝트의 범위를 열어도 목록이 필터링되지는 않습니다.
소유자와 관리자는 권한을 생성하고 변경할 수 있습니다. 멤버는 권한 내용을 확인할 수 있으며, 에이전트와 서비스 계정은 권한을 전혀 변경할 수 없습니다.
권한에 포함되는 내용
유형 한정적권한은 목표가 정해져 있으며 달성 시 종료됩니다. 예를 들어 ‘열린 보안 취약점을 0개로 줄이기’와 같은 경우입니다.지속적권한은 유지보수용으로, ‘프로덕션 경로에 처리되지 않은 예외가 발생하지 않도록 하기’와 같으며 목표 대신 검토일이 정해져 있습니다.
목표달성해야 할 상태를 한 문장으로 설명한 내용입니다. 이는 권한을 이해하는 기준이 되며, 요청 승인은 범위, 예산 및 상태를 기준으로 이루어집니다.
기준선권한의 성과를 측정하는 지표 및 그 출처입니다. 지표 이름은 사용자가 지정하며, 측정값은 Coroid가 자동으로 수집하며 직접 입력할 수 없습니다. 설정 내보내기 시에도 포함되지 않습니다. 새로 생성된 권한에는아직 측정값 없음.
목표값한정적 권한의 경우: 완료를 의미하는 지표와 그 값입니다.
우선순위한 줄에 하나씩 입력합니다. 작업 간에 자원 경쟁이 발생하면 첫 번째 우선순위가 적용됩니다.
범위
- 프로젝트이 명령어가 적용되는 프로젝트들입니다. 체크박스를 선택하지 않으면 조직의 모든 프로젝트에 적용되며, 이후에 생성되는 프로젝트도 포함됩니다. 원하는 프로젝트를 선택하세요. 특정 저장소를 대상으로 하는 명령어의 경우 해당 프로젝트를 명시해야 합니다.
- 영역.해당 프로젝트 내의 경로 패턴으로, 각각 줄 단위로 입력하며 예시는 다음과 같습니다.
apps/api-*/src/**. 비워두면 어디든 적용됩니다. - 변경 클래스.이 명령어가 적용되는 변경 유형으로, 예를 들어 다음과 같습니다.
exception_fix. - 결과를 측정할 수 없는 작업을 허용합니다.기본적으로 비활성화되어 있습니다. 비활성화된 경우, 해당 요청의결과 계약을 측정할 수 없으면 시작하지 않고 대기합니다.
예산.각 기간에 Coroid이(가) 해당 권한에 사용할 수 있는 예산입니다. 미국 달러와 에이전트 시간으로 표시하며, 주별 또는 월별로 설정할 수 있습니다. 주간 기간은 월요일 00시에 시작됩니다.:00UTC 기준이며 월은 그 첫날에 시작됩니다. 예산은 자동으로 다시 활성화됩니다.
중단 조건.예산이 소진되거나 목표에 도달하거나 연속적으로 결론이 나지 않는 결과가 일정 횟수 발생하거나 지정된 날짜에 도달하면 중단됩니다.
리뷰 날짜.진행 중인 명령어의 경우: 담당자가 갱신하거나 종료하는 날짜입니다.
편차 규칙.진행 중인 명령어의 경우: 기준 메트릭에 대한 한도입니다. 해당 기간에 이 한도를 초과하면 소유자에게 알림이 발송됩니다.
상태 및 버전
명령어는 처음에는초안. 게시하면활성상태가 되며, 활성 명령어만 작업을 허용합니다.
| 작업 | 효과 |
|---|---|
| 일시 중지 / 재개 | 작업 접수를 중단했다가 다시 시작합니다. 이미 실행 중인 작업은 완료됩니다. |
| 일시 중단 | 원인을 확인할 때까지 접수를 중지합니다. |
| 완료 | 목표가 달성된 명령을 종료합니다. |
| 폐기 | 영구적으로 종료합니다. 폐기된 명령은 다시 활성화할 수 없으며, 해당 버전과 이력은 그대로 유지됩니다. |
게시된 명령을 변경하면 새 버전이 게시됩니다. 이전 버전은 게시한 사람과 시점 정보와 함께 보존됩니다.
모든 게시 및 상태 변경은 명령 내의 의사결정입니다.출처, 작성자를 포함하며 조직의 감사 로그에 기록된 이벤트와 함께 제공됩니다 (mandate.created, mandate.published,
mandate.paused등등).
명령이 적용되는 요청 항목
명령은 Coroid에 사용자가 없는 요청에 적용됩니다: 업무 접수 API, GitHub 또는 Jira 이슈 같은 자동화 및 연동 기능, 그리고 모니터링에서 발생하는 요청에 적용됩니다.
사용자가새 작업에서 생성하거나 가져온 요청은 명령의 적용을 받지 않습니다. 해당 요청은 조건을 충족하면 항상 접수되며, 연기되지 않고 명령의 예산도 사용하지 않습니다. 사용자가 직접 요청했으므로 에이전트 슬롯에 그대로 대기열로 추가됩니다.
관리자 개입 없이 들어온 요청은 요청이 속한 프로젝트를 포함하거나 모든 프로젝트에 적용되는 가장 오래된 활성 명령과 매칭됩니다. 명령의 적용을 받지 않는 요청은 일반 요청으로 처리됩니다.
접수 시 결정 사항
접수는자격 검토. 모델 기반 판단은 이루어지지 않습니다. 각 요청에 대해 다음 중 하나로 결정됩니다:
- 접수됨.작업이 생성되며, 에이전트 슬롯과 명령에 할당된 예산의 일부가 예약됩니다. 이후 작업 시작 여부는 출처에 따라 결정되며, 자세한 내용은 작업 시작 시점.
- 이미 해결됨.동일한 신호—즉, 추적 시스템이나 모니터링에 나타나는 동일한 문제 또는 장애—가 조직의 다른 프로젝트에서 이미 처리 중인 경우, 해당 요청은 기존 작업에 연결되며 새로 생성되지는 않습니다.
- 변경 필요 없음.자격 검토 결과 보고된 현상이 정상적인 동작임이 확인되었습니다. 따라서 새로 생성되는 항목은 없습니다.
- 연기됨.요청은 접수 가능하지만 현재 시작할 수 없습니다: 명령에서 할당된 에이전트 슬롯이 이미 사용 중이거나 해당 기간의 예산이 소진되었거나, 결과를 측정할 수 없어 명령에서 허용하지 않는 경우입니다.
각 결정 사항과 그 사유는 요청과 함께 기록됩니다.
연기된 요청
Coroid는 매분마다 연기된 요청을 다시 확인하여, 슬롯이나 예산이 확보되는 즉시 이를 수락합니다. 이는 현재 버전의 명령에 따른 것입니다. 명령의 예산을 늘리거나, 슬롯을 점유 중인 다른 명령을 일시 중단하면 다음 확인 시점에 연기된 요청이 처리될 수 있습니다. 직접적으로 처리하도록 하는 우회 방법은 존재하지 않습니다.
명령에서 정한 기간(1주 또는 1개월)보다 더 오래 대기했거나, 명령이 더 이상 활성화되지 않은 요청은 작업 없이 종료됩니다.
명령 기반 작업이 용량을 어떻게 공유하는가
명령 기반 작업은 조직 전체의 최대 절반까지만에이전트 슬롯을 동시에 사용할 수 있으며, 여기에는 이미 실행 중인 작업과 수락되었지만 아직 시작되지 않은 작업도 포함됩니다. 나머지 슬롯은 사람들이 요청하는 작업을 위해 남겨집니다. 플랜에 무제한 슬롯이 포함된 경우에는 월별 지출 예산에 대해서도 동일한 비율이 적용됩니다.
수락된 요청은 작업이 시작될 때까지 30분간 예약 상태를 유지합니다. 그 이후에는 예약이 만료됩니다. 작업이 아직 생성되지 않은 요청은 연기된 상태로 돌아가고, 이미 존재하는 작업은 다른 작업과 마찬가지로 슬롯을 기다립니다.
설정 내보내기에서는
명령은 "설정 내보내기"에 포함됩니다: 종류, 목표, 대상, 우선순위, 범위, 예산, 중단 조건, 검토 날짜 및 편차 규칙. 프로젝트는 고유 키로 매칭되고, 소유자는 역할로 식별됩니다. 기준선은 절대 함께 전송되지 않으며, 이는 해당 기준선이 생성된 조직에 대한 측정값일 뿐입니다. 새로운 목표를 가진 명령은 게시를 위해 초안 형태로 전달됩니다. 기존 명령과 목표가 일치하는 경우에는 초안이면 초안으로, 그렇지 않으면 새로 게시된 버전으로 업데이트됩니다.