좋은 프롬프트만으로 에이전트가 루프를 따르게 할 수 있지 않나요?

프롬프트는 루프를 설명할 뿐, 강제하지 못합니다. 두 에이전트가 같은 작업을 맡는 것을 막지 못하고, 죽은 에이전트가 쥔 작업을 풀어 주지도 못합니다. Weft에서는 맡기가 서버가 소유한 리스이므로, 에이전트가 지시를 기억했든 아니든 그런 경우가 처리됩니다.

에이전트가 중간에 죽으면 어떻게 되나요?

하트비트가 멈춥니다. 마지막 report_progress로부터 20분 뒤 실행이 stale로 표시되고, 리스 토큰이 지워지고, 작업이 다시 미배정이 되므로 다른 에이전트나 사람이 가져갈 수 있습니다. 카드가 일주일 동안 Doing에 머물지 않습니다.

끝난 작업은 모두 내 검토를 기다리나요?

아닙니다. 기본적으로 완료된 작업은 결과와 증거와 함께 곧바로 Done으로 갑니다. 작업에 검토가 필요하거나 검증 확인이 실패한 경우에만 받은편지함에 멈춰 수락, 재작업, 나중에, 폐기를 기다립니다.

왜 에이전트가 일을 거절당하기를 바라야 하나요?

그렇지 않으면 당신이 확인할 시간도 없는 것을 계속 만들어 내기 때문입니다. 사람을 기다리는 항목이 5개(팀은 10개) 또는 검토 약 45분에 이르면, start_task가 attention_queue_full을 돌려주고 에이전트에게 여전히 할 수 있는 일을 알려 줍니다. 대기열을 비우면 다시 풀립니다.

Hypertask에도 리스가 있습니다. 왜 MCP가 중요한가요?

Hypertask의 리스는 그들 자신의 문서에 따르면 REST 엔드포인트이고(MCP 개요), CLI로도 맡을 수 있습니다. 스크립트로 돌아가는 에이전트에 맞는 방식입니다. 편집기나 채팅에서 MCP 도구로 일하는 에이전트는 그곳에서 리스를 쓸 수 없지만, Weft에서는 씁니다. start_task, report_progress, complete_task가 MCP 도구이기 때문입니다.

블로그

AI 에이전트 작업 관리: 프롬프트가 아니라 계약으로서의 작업 맡기 루프

서버가 강제하는 작업 맡기 루프로 AI 에이전트의 작업을 관리하는 법: 리스, 하트비트, 질문, 영수증, 그리고 사람의 주의에 거는 한도.

Weft는 1인 창업자와 소규모 팀을 위한 AI 작업 관리 도구입니다.

모든 글

글쓴이: Andrei Finogeev · 2026년 10월 27일

AI 에이전트 작업 관리는 프롬프트가 아니라 보드가 루프를 쥘 때 제대로 돌아갑니다. 에이전트는 무엇을 할지 묻고, 조용해지면 만료되는 리스로 작업 하나를 맡고, 사람에게는 그 사람의 몫인 결정만 묻고, 누군가 확인할 수 있는 영수증으로 마무리합니다. Weft에서는 각 단계가 서버가 확인하는 MCP 도구이므로, 단계를 건너뛴 에이전트는 조용히 어긋나는 대신 거절당하거나 작업을 잃습니다.

Weft는 우리가 만듭니다. 다른 제품에 대한 사실은 2026년 10월 27일에 확인한 공식 페이지에서 가져왔습니다.

채팅에 붙여 넣은 작업 목록은 왜 결국 안 통할까?

작업을 채팅에 붙여 넣는 것은 누구나 처음 해 보는 방법이고, 반나절은 잘 됩니다. 그러다 채팅이 끝나면 상태도 함께 끝납니다. 에이전트는 어떤 항목을 끝냈는지, 어떤 것을 포기했는지, 무엇이 확실하지 않은지 알고 있었습니다. 이제는 아무도 모릅니다.

목록을 붙여 넣은 사람이 중계자가 됩니다. 결과를 진짜 보드로 다시 옮겨 적고, 맡았다는 표시가 없어서 두 번째 세션이 가져간 일을 다시 합니다.

보드 접근은 스냅숏 문제를 해결할 뿐, 나머지는 해결하지 못합니다. 도구가 “카드 옮기기”와 “댓글 달기”뿐이라면, 루프는 여전히 에이전트가 지시문에 적힌 관례를 따르는지에 달려 있습니다. 관례는 정확히 일이 꼬일 때 깨집니다. 에이전트가 실행 도중 죽거나, 두 에이전트가 같은 순간에 시작할 때.

계약으로서의 작업 맡기 루프는 어떤 모습일까?

Weft에서 루프는 다섯 단계이고, 각 단계는 하나의 MCP 엔드포인트 https://letsweft.com/api/mcp 위의 별도 도구입니다. 단계 사이의 상태는 서버가 보관하므로, 루프는 어떤 채팅이 끝나도 살아남습니다.

get_my_work: 고르기 전에 묻기. 답에는 이 클라이언트가 이미 쥔 것, 사람을 기다리는 것, 기한이 지났거나 곧 다가오는 것, 그리고 무언가를 새로 시작할 여유가 있는지가 담깁니다.
start_task: 리스로 맡기. 맡기는 20분 유지되고 작업을 Doing으로 옮깁니다. 응답에는 runId, leaseToken, renewEverySeconds: 300이 들어 있습니다. 같은 작업을 시도한 두 번째 클라이언트는 already_claimed와 함께 일을 중복하지 말라는 힌트를 받습니다.
report_progress: 하트비트. run id와 lease token으로 호출할 때마다 리스가 갱신됩니다. 에이전트가 죽으면 하트비트가 멈추고, 20분 뒤 실행이 stale로 표시되며 작업은 누구나 가져갈 수 있게 미배정으로 돌아갑니다. 리스를 잃으면 lease_lost로 답하므로, 에이전트는 자신이 더 이상 그 일을 갖고 있지 않다는 것을 압니다.
request_input: 사람의 몫인 결정에만. 최대 500자의 질문과 최대 10개의 선택지. 에이전트가 기다리는 동안 맡은 상태는 유지됩니다.
complete_task: 영수증으로 마무리. outcome, artifacts(URL, 커밋, 파일 해시 같은 증거), notDone, unknowns, nextStep.

왜 상태가 아니라 리스일까요? 죽은 에이전트가 보낼 수 있는 신호는 침묵뿐이기 때문입니다. Doing에 있는 카드는 누군가 한때 그것을 작업했다는 뜻입니다. 리스는 누군가 지금 작업하고 있다는 뜻이고, 그것이 더 이상 사실이 아니게 되면 스스로 그 말을 멈춥니다.

맡기 자체는 고유 인덱스로 보호되는 단 한 번의 데이터베이스 삽입입니다. 두 에이전트가 경쟁하면 누가 이기는지는 데이터베이스가 정하므로, 둘 다 작업을 얻을 수는 없습니다. 반면 1초 차이로 달린 “맡았음” 댓글 두 개는 둘 다 유효한 댓글입니다.

에이전트는 언제 request_input을 호출해야 할까?

사람만 결정할 수 있는 일에 닿았을 때입니다. 돈, 게시, 프로덕션, 법률처럼 되돌릴 수 없는 일, 또는 합리적인 기본값이 없는 진짜 갈림길. 계속해도 되는지 허락을 구하려고 쓰는 것이 아닙니다.

이 절제가 중요한 이유는, 질문 하나가 끝난 작업 하나와 똑같은 사람의 주의를 쓰고, Weft에서는 같은 한도에 포함되기 때문입니다. 질문은 받은편지함에 도착하고, 모바일 푸시가 가며, 20분 이상 기다린 항목에는 이메일 알림도 갑니다. Weft는 에이전트를 다시 호출하지 않습니다. 답은 에이전트의 다음 start_task나 get_my_work에 도착합니다. 질문이 열려 있는 동안 에이전트는 60분간 작업을 쥐고 있고, 그 뒤에는 리스가 풀리지만 질문은 남습니다.

complete_task 호출에는 무엇이 들어갈까?

짧은 결과, 증거, 그리고 경계에 대한 정직한 설명입니다. 버그 수정의 현실적인 페이로드는 이렇습니다.

{
  "id": "9b2f6c1e-4d7a-4c3b-8e21-5a0f3d9c7b14",
  "runId": "d41e8a90-2f6b-4e17-9c3a-71b5e0a4c8f2",
  "leaseToken": "lt_3f9a…",
  "outcome": "Fixed the 500 on /api/invoices when the customer has no billing address. Fix is in PR #418; the route now returns 422 with a field error.",
  "artifacts": [
    { "kind": "url", "uri": "https://github.com/acme/app/pull/418" },
    { "kind": "commit", "uri": "a1c9e07" },
    { "kind": "url", "uri": "https://preview-418.acme.dev/api/invoices/health", "httpStatus": 200 }
  ],
  "claims": [
    "Added a test for an empty billing address; the invoices test file passes locally"
  ],
  "notDone": [
    "Did not merge the PR",
    "Did not backfill the 14 invoices that failed last week"
  ],
  "unknowns": [
    "Whether the mobile app shows the 422 message or a generic error"
  ],
  "nextStep": "Merge PR #418 to main"
}

산출물은 에이전트의 말을 믿지 않고도 사람이 확인할 수 있는 것입니다. notDone과 unknowns는 고백이 아닙니다. 믿고 쓸 수 있는 결과와 diff를 보며 다시 짜 맞춰야 하는 결과를 가르는 것입니다. 증거가 없다고 호출이 실패하지는 않습니다. 끝낸 일을 잃는 것이 검증되지 않은 채로 기록하는 것보다 나쁘기 때문입니다. 이런 영수증을 읽는 법은 내 AI 에이전트는 무엇을 했을까에 더 있습니다.

카드를 옮기고 댓글을 다는 것과는 무엇이 다를까?

같은 루프에 관한 Hypertask의 가이드(맡기, 갱신, 보고, 닫기)는 그 습관을 잘 설명합니다. 그들의 MCP식 맡기는 작업을 불러와 작업 중 구역으로 옮기고 맡았다는 댓글을 다는 것이며, 팀이 에이전트 지시문에 써 넣는 프롬프트가 그것을 안내합니다. 같은 루프를 단계별로 보면 이렇습니다.

루프 단계	관례에만 기대는 보드(에이전트가 카드를 옮기고 댓글을 닮)	Weft가 강제하는 것과 그 MCP 도구
일 고르기	에이전트가 작업을 나열하고 고릅니다. 사람이 이미 검토에 파묻혀 있다는 것을 알려 주는 것은 없습니다.	`get_my_work`는 이 클라이언트가 이미 쥔 것, 사람을 기다리는 것, 기한이 지난 것, 그리고 무언가를 새로 시작할 여유가 있는지를 돌려줍니다.
맡기	카드를 Doing으로 옮기고 “맡았음”을 남깁니다. 두 에이전트가 같은 순간에 이렇게 하면 둘 다 자기가 맡았다고 믿습니다.	`start_task`는 고유 인덱스로 보호되는 한 번의 데이터베이스 쓰기로 20분 리스를 잡습니다. 진 쪽은 작업 id와 제목이 담긴 `already_claimed`를 받습니다.
살아 있음 알리기	에이전트가 기억한다면 진행 댓글. 죽은 에이전트는 카드를 Doing에 무기한 남깁니다.	`report_progress`가 리스를 갱신합니다(에이전트는 5분마다 하라는 안내를 받습니다). 20분 동안 조용하면 실행이 stale로 표시되고 작업이 다시 풀립니다.
묻기	“막힘:” 댓글. 에이전트는 멈추거나 추측하고, 카드는 여전히 진행 중처럼 보일 수 있습니다.	`request_input`이 최대 10개의 선택지가 있는 질문을 사람의 받은편지함에 넣고 맡은 상태를 유지합니다(대기 중 60분). 답은 `start_task`나 `get_my_work`로 돌아옵니다.
보고	자유 형식의 마지막 댓글. 그 모양은 프롬프트가 얼마나 좋았는지에 달려 있습니다.	`complete_task`는 이름이 정해진 필드를 받습니다: `outcome`, `artifacts`, `notDone`, `unknowns`, `nextStep`.
닫기 또는 검토	에이전트가 프롬프트에 적힌 대로 카드를 Review나 Done으로 옮깁니다.	기본적으로 작업은 Done으로 갑니다. 검토가 필요하거나 검증 확인이 실패하면 받은편지함에 멈춰 수락 / 재작업 / 나중에 / 폐기를 기다립니다.
과부하	아무것도 없습니다. 에이전트는 계속 일을 시작하고 Review 컬럼은 불어납니다.	사람을 기다리는 항목이 5개(1인) 또는 10개(팀), 또는 검토 45분에 이르면 `start_task`가 `attention_queue_full`로 거절합니다.

Hypertask에 공정하게 말하자면, 그들에게도 진짜 리스가 있습니다. 문서에는 리스 맡기, 하트비트, 해제 엔드포인트가 나와 있고, 알려진 제한 표에는 작업 리스, 증거, 에스컬레이션이 설계상 REST 엔드포인트로만 제공된다고 적혀 있습니다(Hypertask MCP 개요). 도구 레퍼런스의 MCP 도구 21개 중에는 리스 도구가 없습니다(도구 레퍼런스). CLI도 선택 명령으로 맡을 수 있습니다(변경 기록, CLI 레퍼런스). 그러니 Hypertask에서 스크립트로 돌아가는 에이전트는 리스를 쥘 수 있지만, Claude Code나 Cursor에서 MCP로 일하는 에이전트는 누군가 REST 호출을 연결하지 않는 한 카드와 댓글 방식을 쓰게 됩니다.

에이전트가 스크립트와 CI 작업으로 돌아간다면 Hypertask의 CLI와 REST API는 진짜 장점이고, Weft에는 둘 다 없습니다. CLI도, 공개 REST API도, 웹훅도 없습니다. Weft는 MCP 클라이언트 안에 살면서 그곳에서 루프가 지켜져야 하는 에이전트를 위한 도구입니다.

사람에게는 무엇이 보일까?

대부분은 Done에 있는 카드입니다. 기본적으로 완료된 작업은 결과와 증거가 붙은 채로 곧바로 그곳에 갑니다.

작업에 검토 필요 표시가 있거나 검증 확인이 실패하면, 작업은 사람의 받은편지함에 멈춥니다. 거기서 사람은 네 가지 답 중 하나를 고릅니다.

수락: 작업 결과를 인정합니다. 에이전트가 nextStep을 넘겼다면 사람은 버튼 위에서 그것을 봅니다(“수락하면 에이전트는 …”). 수락은 정확히 그 단계만 승인하고, 그 이상은 승인하지 않습니다. 승인은 72시간 동안 유효하며 get_my_work나 start_task로 에이전트에게 돌아갑니다.
재작업: 무엇이 잘못됐는지 적은 메모와 함께 되돌려 보냅니다.
나중에: 지금은 아님. 폐기: 이 작업을 그만둠.

받은편지함은 웹에 있고, 무언가 들어오면 Weft 모바일 앱으로도 푸시가 갑니다. nextStep 주고받기 덕분에 에이전트는 “괜찮아 보인다”를 병합, 배포, 발송의 허락으로 여기지 않습니다. 승인된 한 단계만 실행한 뒤 작업을 다시 완료합니다.

에이전트가 일을 더 시작하는 대신 거절당하는 이유는?

부족한 자원은 일이 아니라 주의이기 때문입니다. 사람이 하나를 검토하는 동안 에이전트는 열 가지를 시작할 수 있습니다.

Weft는 사람을 기다리는 것, 즉 검토를 기다리는 작업과 열린 질문을 셉니다. 그것이 1인 워크스페이스에서 5개, 팀에서 10개, 또는 예상 검토 시간 약 45분 중 먼저 닿는 쪽에 이르면, start_task가 attention_queue_full로 거절합니다. 한도는 요금제가 아니라 워크스페이스의 인원수에 따라 정해집니다.

거절은 막다른 길이 아니라 지시입니다. 대기열 크기, 가장 오래된 항목의 나이, 여전히 허용되는 호출(report_progress, get_my_work, get_board_state, search)을 알려 줍니다. 사람이 그 카드에서 이미 승인한 단계는 예외이므로, 수락된 “PR #418 병합”은 대기열 때문에 막히지 않습니다.

어떻게 설정할까?

클라이언트를 연결하고 브라우저로 로그인하세요. 복사할 키는 없습니다. Weft는 리프레시 토큰을 발급하므로 클라이언트가 스스로 로그인을 갱신합니다. Claude Code에서는 명령 하나, claude mcp add --transport http weft https://letsweft.com/api/mcp입니다(설정 페이지). Cursor는 클릭 한 번으로 설치하고(Cursor), Codex는 설정 항목과 codex mcp login weft가 필요하며(Codex), ChatGPT에는 무료를 포함한 모든 요금제에 게시된 Weft 앱이 있습니다(ChatGPT). 서버가 에이전트에게 루프를 직접 설명하므로, 생명 주기 프롬프트는 필요 없습니다.

Claude Code 따라 하기는 Claude Code를 위한 작업 보드를 보세요. 리스와 already_claimed가 가장 중요해지는, 한 보드 위의 여러 에이전트는 여러 AI 에이전트, 하나의 보드를 보세요. 프로토콜 자체는 modelcontextprotocol.io에 문서화되어 있고, 다른 MCP 보드는 MCP 작업 관리 도구에서 비교합니다.

여기서 Weft가 하지 않는 것은?

CLI, 공개 REST API, 웹훅이 없으므로 cron 작업과 CI 파이프라인은 MCP 클라이언트 밖에서 루프를 움직일 수 없습니다.
GitHub이나 Slack 연동이 없습니다. 증거는 에이전트가 artifacts에 링크한 것입니다.
내장 AI가 없습니다. 생각은 당신의 AI 클라이언트에서 일어나며, 그래서 Weft에는 AI 크레딧이 필요 없습니다.

무료는 작업 50개와 월 200회 AI 호출을 포함합니다. Pro는 좌석당 월 $7 또는 좌석당 연 $60입니다(요금).

좋은 프롬프트만으로 에이전트가 루프를 따르게 할 수 있지 않나요?: 프롬프트는 루프를 설명할 뿐, 강제하지 못합니다. 두 에이전트가 같은 작업을 맡는 것을 막지 못하고, 죽은 에이전트가 쥔 작업을 풀어 주지도 못합니다. Weft에서는 맡기가 서버가 소유한 리스이므로, 에이전트가 지시를 기억했든 아니든 그런 경우가 처리됩니다.
에이전트가 중간에 죽으면 어떻게 되나요?: 하트비트가 멈춥니다. 마지막 report_progress로부터 20분 뒤 실행이 stale로 표시되고, 리스 토큰이 지워지고, 작업이 다시 미배정이 되므로 다른 에이전트나 사람이 가져갈 수 있습니다. 카드가 일주일 동안 Doing에 머물지 않습니다.
끝난 작업은 모두 내 검토를 기다리나요?: 아닙니다. 기본적으로 완료된 작업은 결과와 증거와 함께 곧바로 Done으로 갑니다. 작업에 검토가 필요하거나 검증 확인이 실패한 경우에만 받은편지함에 멈춰 수락, 재작업, 나중에, 폐기를 기다립니다.
왜 에이전트가 일을 거절당하기를 바라야 하나요?: 그렇지 않으면 당신이 확인할 시간도 없는 것을 계속 만들어 내기 때문입니다. 사람을 기다리는 항목이 5개(팀은 10개) 또는 검토 약 45분에 이르면, start_task가 attention_queue_full을 돌려주고 에이전트에게 여전히 할 수 있는 일을 알려 줍니다. 대기열을 비우면 다시 풀립니다.
Hypertask에도 리스가 있습니다. 왜 MCP가 중요한가요?: Hypertask의 리스는 그들 자신의 문서에 따르면 REST 엔드포인트이고(MCP 개요), CLI로도 맡을 수 있습니다. 스크립트로 돌아가는 에이전트에 맞는 방식입니다. 편집기나 채팅에서 MCP 도구로 일하는 에이전트는 그곳에서 리스를 쓸 수 없지만, Weft에서는 씁니다. start_task, report_progress, complete_task가 MCP 도구이기 때문입니다.