Multica Docs

작업

모든 에이전트 실행의 작업 단위로, 명확한 상태 머신, 타임아웃, 재시도 규칙을 갖추고 있습니다.

작업은 모든 에이전트 실행의 단위입니다 — 에이전트에게 이슈를 할당하거나, 댓글에서 에이전트를 @-멘션하거나, 채팅에서 메시지를 보내거나, 오토파일럿이 예약된 시각에 실행되면 모두 작업이 생성됩니다. Multica는 이를 대기열에 넣고, 데몬이 가져가 해당 AI 코딩 도구에 넘긴 다음, 완료되면 결과를 서버에 다시 기록합니다.

작업과 이슈는 서로 다른 두 객체입니다. 하나의 이슈는 여러 번 할당되거나 @-멘션되거나 수동으로 재실행될 수 있으며 — 그때마다 새로운 작업이 생성됩니다.

작업이 거치는 상태

Rendering diagram…
  • Queued(대기 중) — 작업이 막 생성되어 데몬이 가져가기를 기다리는 상태
  • Dispatched(파견됨) — 데몬이 작업을 점유하고 AI 코딩 도구를 시작하는 중
  • Running(실행 중) — AI 코딩 도구가 실제로 작업을 수행하는 중
  • Completed(완료) — 성공적으로 끝났으며, 산출물(댓글, 코드 커밋, 상태 변경)이 서버에 다시 기록됩니다
  • Failed(실패) — 오류 또는 타임아웃으로 중단됨; 실패 사유가 재시도 가능한 경우 작업은 자동으로 queued 상태로 돌아가 다시 시도됩니다
  • Cancelled(취소됨) — 사용자가 취소한 경우

작업이 타임아웃되면 일어나는 일

Multica 서버는 30초마다 스캔합니다. 두 종류의 타임아웃이 실패를 유발합니다:

상황타임아웃
파견되었으나 시작되지 않음(데몬이 가져갔지만 AI 도구를 실행하지 않음)5분
너무 오래 실행됨2.5시간

두 타임아웃 모두 실패 사유로 timeout을 사용하며 자동으로 재시도됩니다(다음 섹션). 관련된 런타임 누락 검사는 데몬과 런타임 → 런타임이 오프라인으로 표시되는 시점을 참고하세요.

어떤 실패가 자동으로 재시도되고 어떤 실패는 그렇지 않은지

실패는 두 가지 범주로 나뉩니다: 재시도 가능재시도 불가.

재시도 가능(Multica가 자동으로 다시 대기열에 넣음):

  • runtime_offline — 작업이 파견된 후 데몬이 사라짐
  • runtime_recovery — 데몬이 충돌 후 재시작되어 끝내지 못한 작업을 회수함
  • timeout — 런타임 또는 파견 타임아웃

재시도 불가(작업이 실패 상태로 유지됨):

  • agent_error — AI 코딩 도구 자체가 오류를 보고함(API 오류, 할당량 초과, 내부 버그). 근본적인 문제는 재시도하지 않습니다 — 무한 반복될 수 있기 때문입니다.

자동 재시도에는 두 가지 추가 조건도 있습니다:

  1. 최대 2회 시도 — 원본 1회 + 재시도 1회. 재시도도 실패하면 사유가 재시도 가능하더라도 더 이상 재시도하지 않습니다.
  2. 이슈 및 채팅으로 트리거된 작업에만 해당 — 오토파일럿으로 트리거된 작업은 자동으로 재시도되지 않습니다.

오토파일럿 작업은 자동으로 재시도되지 않습니다 — 의도된 설계입니다. 오토파일럿은 자체적인 실행 주기(예: 매일)를 갖고 있으며, 실패 시 자동 재시도가 일어나면 다음 예약 실행과 겹치게 됩니다. 실패 후 즉시 재실행이 필요하다면 수동 재실행을 사용하세요(다음 섹션).

오토파일럿 작업이 실패했음을 알 수 있는 방법: 인박스에 알림이 도착하고, 연관된 이슈의 상태가 in_progress에서 다시 todo로 되돌아갑니다. 오토파일럿 페이지에서도 오토파일럿별 최근 실행 결과를 확인할 수 있습니다.

수동 재실행 vs. 자동 재시도

수동 재실행은 CLI 또는 API(POST /api/issues/{id}/rerun)에서 직접 트리거하는 것입니다:

multica issue rerun <issue-id>

동작:

  • 기본적으로 이슈의 현재 에이전트 담당자를 대상으로 합니다 — 이전 작업을 누가 실행했는지와 무관하게 재실행이 현재 할당을 따르도록 하고 싶을 때 유용합니다.
  • 실행 로그의 특정 행에 있는 재시도 버튼은 해당 행의 작업 ID를 함께 전송하므로, 재실행은 현재 담당자가 아니라 바로 그 작업을 실행했던 에이전트를 대상으로 합니다. 덕분에 스쿼드 워커, 병렬 @-멘션 에이전트, 또는 재할당으로 인해 에이전트가 교체된 행에 대해서도 행 단위 재시도가 의미를 갖게 됩니다.
  • 이 이슈에 대한 대상 에이전트의 대기 중이거나 실행 중인 작업을 취소합니다(있는 경우). 같은 이슈에서 다른 에이전트가 소유한 작업(예: 병렬 @-멘션 실행)은 그대로 둡니다.
  • 완전히 새로운 작업을 생성합니다 — 원본 작업이 시도 횟수 상한에 도달했더라도 시도 횟수가 1로 재설정됩니다.
  • 새로운 에이전트 세션을 시작합니다 — 이전 세션 ID는 상속되지 않습니다. 수동 재실행은 이전 산출물이 나빴다고 판단했다는 의미이므로, 같은 대화를 이어가면 오염된 상태를 그대로 재생하게 됩니다. (반면 자동 재시도는 세션을 상속합니다 — 그 경로는 잘못된 산출물이 아니라 인프라 장애를 위한 것입니다.)

비교:

항목자동 재시도수동 재실행
트리거시스템, 실패 사유 기반사용자, 수동
상한2회 시도제한 없음
적용 가능한 소스이슈, 채팅에이전트 담당자가 있는 이슈
선택되는 에이전트실패한 작업과 동일한 에이전트소스 작업의 에이전트(UI 행 단위 재시도) 또는 이슈의 현재 담당자(CLI / task_id 없음)
세션 상속예(이전 세션 재개)아니요(새 세션)

실패한 작업이 이슈 상태에 미치는 영향

이슈가 에이전트에게 할당되어 트리거된 작업이 실패하면(그리고 자동 재시도가 성공하지 못하면), 이슈의 상태가 in_progress에서 todo로 자동으로 되돌아갑니다 — 그래서 보드를 열면 "이건 다시 봐야겠다"는 것을 즉시 알 수 있습니다. 이슈와 프로젝트를 참고하세요.

작업이 이전 컨텍스트에서 이어질 수 있는지

가능합니다 — AI 코딩 도구가 세션 재개를 지원하는 한 그렇습니다.

Multica는 작업 중에 세션 ID를 두 번 고정합니다: 시작 시 한 번(AI 도구가 첫 번째 시스템 메시지를 반환할 때), 종료 시 한 번(완료 또는 실패 시). 첫 번째는 데몬이 실행 도중 충돌하더라도 복구할 수 있게 해주고, 두 번째는 다음 자동 재시도를 위해 예약되어 그 ID를 다시 전달함으로써 에이전트가 이전 대화와 파일 상태를 이어받을 수 있게 합니다. 수동 재실행은 의도적으로 이 단계를 건너뛰고 새 세션을 시작합니다 — 수동 재실행 vs. 자동 재시도를 참고하세요.

하지만 실제로 어떤 AI 코딩 도구가 이를 지원하는지는 크게 다릅니다:

  • 실제 지원 — Antigravity, Claude Code, Copilot, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Pi
  • ⚠️ 코드는 있지만 사용 불가 — Codex, Cursor
  • 지원 안 함 — Gemini

제공자 매트릭스 → 세션 재개를 참고하세요.

다음