작업은 포털, Slack 또는 Telegram 내 사용자, 귀하의 시스템 및 보조 도구, 그리고 Coroid의 자동화 기능을 통해 Coroid로 유입됩니다. 포털에서 작업을 등록하는 '새 작업'도 이러한 경로 중 하나입니다. 이 모든 경로는 동일한 실행 경로로 수렴됩니다.사양, 계획, 빌드, 검증, 리뷰, 풀 요청.
| 경로 | 사용 시점 |
|---|---|
| 새 작업 | 누군가 무언가를 원하며 이를 직접 설명하려는 경우 |
| 이슈 가져오기 | 요청이 이미 Jira, Linear, Trello 또는 GitHub Issues에 존재하는 경우 |
| Coroid에 문의하기 | 대화 형태로 설명하는 것을 선호하는 경우 |
| Slack 또는 Telegram | 누군가 채팅에서 요청을 하는 경우 |
| API 작업 접수 | 제품 내 기능 요청 양식과 같은 다른 시스템에서 요청이 등록되는 경우 |
| 이벤트 자동화 | GitHub, Slack, Telegram 또는 Jira 내의 무언가가 작업으로 전환되어야 하는 경우 |
| Coroid MCP | Hermes, Codex 또는 Claude Code와 같은 보조 도구나 에이전트가 작업을 관리하는 경우 |
| 일정 | 트리거는 시간입니다 |
| 후크 | 트리거는 플랫폼 이벤트입니다 |
| 보고서 및 결과 | 보고서나 품질 검사에서 수정해야 할 문제가 발견된 경우 |
요청
신규 작업
누군가가 설명합니다
이슈 가져오기
추적 도구에서 가져옵니다
API를 통한 요청 수집
제품 또는 에이전트
이벤트 자동화
pull request, 댓글 또는 메시지
자격 검증
요청을 화면에 표시하고 중복을 제거하며 검증한 뒤, 처리 경로를 결정합니다. 통과하기 전까지는 아무것도 생성되지 않습니다.
최종 결과
- 작업
- 계획
- 보고서
- 일정
원하는 항목을 선택하거나, '생성'을 자동으로 설정하여 Qualification이 결정하게 하세요.
작업 및 계획: 명세, 계획 수립, 빌드, 검증, 리뷰, pull request
검증 후 라우팅됨
'새 작업'에서 들어온 요청이나 가져온 요청은 도착하자마자 바로 생성되지 않습니다. 먼저 자격 확인 단계를 거칩니다. Coroid는 민감한 값이 포함되었는지 확인하고, 현재 릴리스와 비교하여 중복 여부를 점검하며, 가능한 범위를 검증하고 최종 처리 방향을 결정합니다. 통과하기 전까지는 어떠한 항목도 생성되지 않습니다. 자세히 보기필요한 사항을 설명하기.
API 작업 접수를 통해 들어온 요청과 이벤트 자동화에서 자격 확인 단계로 보내진 이벤트도 모두 이 과정을 거칩니다.
최종적으로는 네 가지 경로 중 하나로 처리됩니다:
| 경로 | 생성물 |
|---|---|
| 작업 | 단일 작업으로, 하나의 pull request로 완료됨 |
| 계획 | 코드 작성 전에 귀하가 승인하는 단계별 계획 |
| 보고서 | 생성된 보고서 |
| 자동화 | 예약된 시간에 또는 특정 이벤트 발생 시 실행되는 작업 |
새 작업 양식에서 직접 경로를 선택하거나 자동으로 설정해 둘 수 있습니다.자동그리고 Qualification이 선택하도록 할 수 있습니다. 한 경로를 선택했는데 Qualification이 다른 경로를 추천하면, 해당 추천 내용을 확인하고 결정하면 됩니다.
Ask Coroid는 다르게 작동합니다. Assistant 모드에서는 채팅 도우미가 Qualification 없이 직접 작업과 계획을 생성합니다. Prepare Work 채팅, 즉 안내형 SDLC 워크플로우의 경우에는 계획 수립 전에 승인된 사양을 Qualification으로 보냅니다. 자세히 보려면채팅 도우미.
다른 경로들은 Qualification 없이 직접 작업을 생성하며, 각각의 설정에 따라 시작될 항목이 결정됩니다. MCP 서버의 경우에는 해당 승인 규칙과 자동화 정책이 적용됩니다.
작업이 시작될 때
작업 접수 API 또는 이벤트 자동화에서 요청을 기다리는 사람은 포털에서 대기하지 않습니다. Coroid는 Qualification을 통과한 후 몇 분 내에 작업을 생성합니다. 작업이 자동으로 시작되는지 여부는 요청 출처에 따라 달라집니다:
| 출처 | 자동으로 시작 |
|---|---|
| 승인된 작업을 자동으로 시작하도록 설정된 서비스 계정 | 예 |
| GitHub의 pull request 또는 저장소에 대한 쓰기 권한을 가진 작성자가 만든 이슈 | 예 |
| Coroid를 언급하는 GitHub 댓글로, 작성자에게만 적용됨 | 예 |
| 기타 모든 서비스 계정 | 아니요 |
| Slack, Telegram, Jira 및 기타 모든 출처 | 아니요 |
자동으로 시작되지 않는 작업은 누군가가 직접 시작할 때까지 대기합니다. Qualification에서는 해당 요청이 시작을 기다리고 있음을 표시하며, 작업으로 연결되는 링크도 함께 제공됩니다. 계획은 항상 승인을 기다리므로 절대 자동으로 시작되지 않습니다. 예약된 작업도 검토 단계에서 담당자가 실행 시점을 결정할 때까지 대기합니다.
Coroid는 이 목록의 첫 번째 활성 멤버로 작업을 생성합니다. 해당 멤버는 요청을 제출하거나 자동화를 설정한 사람, 서비스 계정을 만든 사람, 프로젝트를 만든 사람, 조직 소유자입니다.
프로젝트가 지정되지 않은 요청은 조직의 유일한 프로젝트로 전달됩니다. 프로젝트가 여러 개인 경우에는 요청이 Qualification에서 검토를 기다리며, 검토자는 요청을 수락할 때 프로젝트를 선택합니다.
작업인가요, 계획인가요?
유용한 기준은 검토 가능성입니다. 완성된 작업이 동료가 한 번에 읽을 수 있는 하나의 pull request라면 작업입니다. 정해진 순서에 따라 여러 차례 변경이 필요하거나, 구현에 앞서 접근 방식을 승인하고 싶다면 계획입니다.
확신이 서지 않는 경우에는 중요한 작업은 모두 계획으로 처리하는 것이 좋습니다. 계획을 사용하면 코드가 존재하기 전에 승인 체크포인트를 확보할 수 있어 의사결정을 변경하기에 가장 저렴한 시점입니다. 작업이 너무 방대해지면 더 이상 진행할 공간이 부족해집니다.
가져온 작업
추적 도구에서 가져온 이슈는 동일한 검증 절차를 거칩니다. 중복된 이슈, 이미 수정된 이슈 및 확인이 불가능한 요청은 해당 단계에서 걸러지며, 나머지는 작업 또는 계획으로 전환됩니다. 백로그는 요청 목록에 불과하므로 가져오기 작업 시에는 다른 어떤 경우보다도 이 필터의 역할이 더욱 중요합니다. 자세히 보기작업 가져오기.
자체 시스템에서 가져오기
다른 시스템에서도 작업 접수용 API를 통해 요청을 제출할 수 있습니다. 예를 들어 자체 제품 내의 기능 요청 양식이나 고객의 요청 내용을 전달하는 지원 도구 등이 해당됩니다.
API를 사용하려면 서비스 계정이 필요하며, 이는 Professional 및 Enterprise 요금제에 포함되어 있습니다. 해당 계정은 '서비스 계정' 메뉴에서 생성할 수 있습니다.설정 → 서비스 계정. 해당 API 키에는 다음 범위가 필요합니다:intake:write. 이 키는 생성 시에만 한 번 표시되며, 서비스 계정을 비활성화하면 관련 키 모두가 사용할 수 없게 됩니다.
각 요청을 API 게이트웨이로 전송하며, 키를 Bearer 토큰으로 사용하세요:
curl -X POST https://api.coroid.ai/api/v1/organizations/work/intake \
-H "Authorization: Bearer ak_…" \
-H "Content-Type: application/json" \
-d '{"title": "Export invoices as CSV", "content": "Customers want to download their invoices as CSV from the billing page."}'| 필드 | 필수 | 설명 |
|---|---|---|
title | 예 | 최대 500자까지 입력 가능한 짧은 이름 |
content | 예 | 최대 20,000자까지 입력 가능한 요청 내용 |
projectId | 아니요 | 작업이 속한 프로젝트 |
workType | 아니요 | task, plan, report또는schedule |
signal | 아니요 | 요청이 발생한 오류, 경고 또는 이슈에 대한 설명(아래 참조) |
작업 유형이 지정되지 않으면 검증 절차에서 적절한 경로를 선택합니다. 검증 절차는 모든 API 요청에 적용되며 건너뛸 수 없습니다.
요청이 모니터링 시스템이나 다른 자동화된 소스에서 발생한 경우 해당 신호를 설명해 주세요. Coroid는 이 정보를 활용하여 어떤 프로젝트에서든 동일한 인시던트가 중복으로 접수되는 것을 방지하고 작업의결과 계약.
signal필드 | 필수 | 설명 |
|---|---|---|
fingerprint | 예 | 오류 추적 도구 내의 이슈 ID와 같이 인시던트를 식별할 수 있는 안정적인 식별자 |
source | 아니요 | 신호가 발생한 출처, 예:glitchtip또는sentry |
routes | 아니요 | 사고가 영향을 미치는 경로는 최대 50개까지입니다. |
minExposure | 아니요 | 결과를 판단하기 위해 해당 경로에서 처리해야 할 요청의 수는 몇 개인가요? |
url | 아니요 | 사고에 대한 링크입니다. |
와 함께routes및minExposure, 계약 내용은 측정 가능합니다: 사고는 반드시 무음 상태를 유지해야 합니다. 그렇지 않으면 측정이 불가능하다는 점이 계약에 기록됩니다.의무는 측정 불가능한 작업을 시작하는 것을 거부할 수 있습니다.
서비스 계정에서 생성된 검증된 작업은 누군가가 시작하기를 기다립니다. 소유자나 관리자는 '서비스 계정' 메뉴에서 이 설정을 변경할 수 있습니다:자격이 확인된 작업을 자동으로 시작하기. 계정으로 제출되는 모든 작업이 신뢰할 수 있는 사람들로부터 온 경우에만 이 기능을 활성화하세요. 자세히 알아보기작업 시작 시점.
GitHub, Slack, Telegram, Jira의 이벤트도 요청으로 전환될 수 있으며, 별도로 다시 입력할 필요가 없습니다. 이벤트 자동화 기능이 이를 '검증' 단계로 보냅니다. 자세히 알아보기트리거 및 대상.
보조 도구를 통해
Hermes, Codex 또는 Claude Code와 같은 사용자가 운영하는 보조 도구나 에이전트는 MCP 서버를 통해 Coroid와 연동할 수 있습니다. 이를 통해 프로젝트 및 작업 내용을 확인하고, 허용된 범위 내에서 작업을 생성·실행·완료할 수 있습니다. 이렇게 생성된 작업은 '검증' 단계를 거치지 않습니다. 자세히 알아보기Coroid를 MCP 서버로 사용하기.
자동 입력
일정 및 훅 기능은 사람의 요청 없이 작업을 시작하며, 트리거 방식만 다릅니다: 시간이나 특정 이벤트 발생 시입니다. 둘 다자동화, 공장 내에 목록으로 표시되며 '새 작업'에서 생성됩니다.
품질 검사는 수정 작업으로도 이어집니다. 품질 정책이 보고서를 검사하여 제품에 문제가 발견되면, Coroid는 이를 위한 수정 작업을 생성합니다.Factory → 리뷰는 특정 작업에 할당되지 않은 테스트 실패 항목을 나열합니다.수정는 이를 수정 작업으로 전환합니다.
이러한 작업들은 모두 실제 에이전트 슬롯과 모델 사용 비용을 소모합니다. 자동화된 작업의 우선순위는 사람이 기다리는 작업보다 낮게 설정하세요 – 자세히 알아보기용량 및 에이전트 슬롯.