문서

작업 시작 방법

Coroid로 작업이 유입되는 경로, 요청의 적격성 평가 방법 및 최종적으로 도달하는 네 가지 결과를 설명합니다.

작업은 포털, Slack 또는 Telegram 내 사용자, 귀하의 시스템 및 보조 도구, 그리고 Coroid의 자동화 기능을 통해 Coroid로 유입됩니다. 포털에서 작업을 등록하는 '새 작업'도 이러한 경로 중 하나입니다. 이 모든 경로는 동일한 실행 경로로 수렴됩니다.사양, 계획, 빌드, 검증, 리뷰, 풀 요청.

경로사용 시점
새 작업누군가 무언가를 원하며 이를 직접 설명하려는 경우
이슈 가져오기요청이 이미 Jira, Linear, Trello 또는 GitHub Issues에 존재하는 경우
Coroid에 문의하기대화 형태로 설명하는 것을 선호하는 경우
Slack 또는 Telegram누군가 채팅에서 요청을 하는 경우
API 작업 접수제품 내 기능 요청 양식과 같은 다른 시스템에서 요청이 등록되는 경우
이벤트 자동화GitHub, Slack, Telegram 또는 Jira 내의 무언가가 작업으로 전환되어야 하는 경우
Coroid MCPHermes, Codex 또는 Claude Code와 같은 보조 도구나 에이전트가 작업을 관리하는 경우
일정트리거는 시간입니다
후크트리거는 플랫폼 이벤트입니다
보고서 및 결과보고서나 품질 검사에서 수정해야 할 문제가 발견된 경우

요청

  • 신규 작업

    누군가가 설명합니다

  • 이슈 가져오기

    추적 도구에서 가져옵니다

  • API를 통한 요청 수집

    제품 또는 에이전트

  • 이벤트 자동화

    pull request, 댓글 또는 메시지

자격 검증

요청을 화면에 표시하고 중복을 제거하며 검증한 뒤, 처리 경로를 결정합니다. 통과하기 전까지는 아무것도 생성되지 않습니다.

최종 결과

  • 작업
  • 계획
  • 보고서
  • 일정

원하는 항목을 선택하거나, '생성'을 자동으로 설정하여 Qualification이 결정하게 하세요.

자격 검증은 이 항목들을 확인하지 않습니다. 이 항목들은 직접 작업을 생성합니다:Coroid에게 문의하기 · 대화 중에 요청됩니다일정 관리 · 시간에 맞춰 발생합니다Hook · 플랫폼 이벤트에 의해 발생합니다보고서 및 분석 결과 · 수정해야 할 문제Coroid MCP · 외부 에이전트

작업 및 계획: 명세, 계획 수립, 빌드, 검증, 리뷰, pull request

요청은 생성되기 전에 반드시 검증을 거치며, 이후 작업, 계획, 보고서 또는 일정으로 전환됩니다. 작업과 계획은 동일한 경로를 따라 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 → 리뷰는 특정 작업에 할당되지 않은 테스트 실패 항목을 나열합니다.수정는 이를 수정 작업으로 전환합니다.

이러한 작업들은 모두 실제 에이전트 슬롯과 모델 사용 비용을 소모합니다. 자동화된 작업의 우선순위는 사람이 기다리는 작업보다 낮게 설정하세요 – 자세히 알아보기용량 및 에이전트 슬롯.

이 섹션에서