더 많은 모더레이터를 고용하지 않고 커뮤니티 작업을 위임하는 방법
Zealy의 코드에서 읽어낸, 커뮤니티 검토 대기열을 줄이는 세 가지 방법: 작업을 설계로 없애거나, 검토자에게 넘기거나, AI에게 넘기기 — 그리고 각각의 비용.
작성자 Mathis Grosjean

이 페이지에서
대상 독자: 검토 대기열이 팀보다 빠르게 늘어나며 수천 건의 대기 중인 제출물을 바라보고, 답이 두 번째 모더레이터인지, 세 번째인지, 아니면 사직서인지 고민하는 창립자나 커뮤니티 리드.
짧은 답: 아마 또 다른 사람은 아닐 것입니다 — 하지만 듣기 좋은 이유 때문은 아닙니다. 대기열의 대부분은 존재하지 않아야 합니다. Zealy에서는 다섯 가지 작업 유형이 사람이 답을 읽어야 하도록 설계되어 있고 — 날짜 작업도 기본 설정에서 여기에 합류합니다 — 나머지는 모두 멤버가 클레임하는 순간 스스로 처리됩니다. 규칙에 대한 위임이 사람에 대한 위임보다 낫고, 사람에 대한 위임이 기계에 대한 위임보다 낫습니다. 그 순서인 이유는 첫 번째만이 작업을 옮기는 대신 삭제하기 때문입니다.
공개: Zealy가 이 글을 발행하며, Zealy는 이 글에서 설명하는 플랫폼을 판매합니다. Zealy의 동작에 관한 모든 주장은 Zealy의 마케팅 페이지나 문서가 아니라 2026년 8월 16일 Zealy 자체 소스 코드에서 읽어낸 것입니다. 여기에는 Zealy에 명백히 빠진 부분과, 잘못된 Zealy 자체 문서 두 페이지가 포함되며, 이는 이 글과 같은 변경에서 수정하고 있습니다.
최종 확인: 2026년 8월 16일.
모더레이터를 더 고용해야 할까요?
아직은 아닐 가능성이 큽니다. Zealy에서는 다섯 가지 작업 유형이 사람 검토자에게 도달하도록 설계되어 있습니다: 텍스트, URL, 숫자, 파일 업로드, 투표 — 그리고 날짜 작업도 기본 설정에서 여기에 합류합니다. 나머지는 모두 스스로 검증되며 대기열에 들어가지 않습니다. 사람을 추가하기 전에, 어떤 퀘스트가 실제로 답을 읽을 사람을 필요로 하는지 점검하세요.
"제출물에 파묻혔다"는 대화는 거의 항상 처리 능력에서 시작합니다 — 검토자가 몇 명인지, 몇 시간인지, 각 항목을 얼마나 빨리 처리하는지 — 하지만 대기열의 크기는 몇 주 전에 퀘스트 편집기에서 작업 유형을 선택한 사람에 의해 이미 결정되었습니다. 스크린샷을 요구하는 퀘스트는 대기열을 만듭니다. Discord 서버 참여를 요구하는 퀘스트는 그렇지 않습니다. 답이 그 자리에서 Discord와 대조되기 때문입니다. 같은 캠페인, 같은 보상, 전혀 다른 운영 비용.
따라서 정직한 순서는 다음과 같습니다: 작업을 제거하고, 남은 것을 위임하고, 남은 것을 자동화하세요. 팀들은 안정적으로 이를 거꾸로 합니다. 그래서 삭제할 수 있었던 작업의 속도를 높이려고 플랜 업그레이드 비용을 지불하게 되는 것입니다.
검토 대기열을 위임하는 세 가지 방법
검토 대기열은 세 가지 방식으로 위임할 수 있습니다: 작업을 스스로 검증하게 만들어 규칙에 위임하거나, Zealy의 검토자 역할을 사용해 사람에게 위임하거나, AI 검토나 MCP 에이전트를 사용해 기계에 위임하는 것입니다. 규칙은 작업을 제거하고, 사람은 판단을 적용하며, 기계는 작성된 프롬프트를 대량으로 적용합니다.
| 경로 | 잘 처리하는 것 | 할 수 없는 것 | 비용 |
|---|---|---|---|
| 규칙에 위임 — 자동 검증 또는 스스로 검증하는 작업 유형 | 검증 가능한 답이 하나인 모든 것: 방문한 링크, 참여한 서버, 온체인 행동, 퀴즈, 숫자 답 | 어떤 종류의 판단도 불가능합니다. 신중한 답과 게으른 답을 구분하지 못하며, 업로드된 파일에 대한 콘텐츠 검사를 하지 않습니다 | 설계 시간, 그리고 실제 위험: 정답을 비워두면 모든 제출물이 승인됩니다 |
사람에게 위임 — reviewer 역할 | 판단, 어조, 예외 사례, 이의 제기, 틀렸을 때 기여자를 잃게 되는 모든 것 | 하나의 퀘스트나 하나의 모듈로 범위를 제한할 수 없으며, 두 검토자가 같은 클레임을 동시에 여는 것을 막을 수 없습니다 | 클레임당 최대 20,000의 보너스 XP 부여 권한 — 한 번의 호출로 1,000개의 클레임을 처리할 수 있음 — 그리고 이제 수동으로 운영해야 하는 조정 |
| 기계에 위임 — AI 검토 또는 MCP 에이전트 | 작성된 기준에 대한 대량 처리: 이 답이 프롬프트가 요구하는 것을 포함하는가 | 확인할 추천을 제시하지 않습니다 — AI 검토가 직접 판정을 작성하며, 멤버는 모델의 추론을 읽습니다 | AI 검토를 위한 Plus 또는 Enterprise 플랜, 에이전트를 위한 관리자급 신뢰, 그리고 프롬프트가 대규모에서 틀리는 모든 것 |
경로 1: 검토 작업을 설계로 없애기
여기서 시작하세요: 작업을 옮기는 대신 제거하는 유일한 경로입니다. 다섯 가지 Zealy 작업 유형은 사람을 필요로 하도록 설계되어 있습니다 — 텍스트, URL, 숫자, 파일 업로드, 투표 — 그리고 날짜는 기본적으로 같은 방식으로 동작합니다. 나머지는 모두 멤버가 클레임할 때 해결됩니다. 텍스트 작업을 링크 확인으로 다시 작성하면 대기열이 비워집니다.
우리는 퀘스트가 자동 검증되는지 결정하는 함수를 읽고, 퀘스트 서비스의 모든 런타임 검증기를 교차 확인하여 이를 확인했습니다. 그 다섯 가지 — text, url, number, file, poll — 는 작업이 명시적으로 자동 검증으로 설정되지 않는 한 각각 검토 대기 상태를 반환합니다. 나머지는 성공 또는 오류를 동기적으로 반환하므로 기다릴 것도, 기다릴 대기열도 없습니다.
코드가 스스로 모순되기 때문에 정직한 예외 두 가지를 말씀드립니다. 정리하기보다는 그대로 알려드리는 편이 낫습니다:
- 날짜 작업. 한 목록은 이를 항상 자동으로 취급하지만, 실제로 실행되는 검증기는 작업의 자동 검증 설정을 따르며, 편집기는 이를 기본적으로 꺼둡니다. 코드가 스스로 모순되는데 날짜 작업이 자동이라고 말하지는 않겠습니다. 의존하기 전에 하나를 테스트하세요.
- Proof of Humanity. 런타임에서는 자동으로 해결되지만 어느 목록에도 나타나지 않습니다 — 파트너십 퀘스트 유형도 마찬가지입니다 — 따라서 해당 작업만 포함한 퀘스트는 자동 검증되지 않음 으로 보고됩니다. 광고하는 것보다 더 잘 동작합니다. (무엇을 잡아내는지는 파밍되지 않는 에어드롭을 운영하는 방법 에서 다룹니다 — 이는 봇 필터이지 시빌 필터가 아닙니다.)
실제로 대기열을 줄여주는 재작성
먼저 텍스트 작업을 살펴보세요. 대부분은 하나의 정답이 있는 질문을 에세이처럼 표현합니다. "문서에서 무엇을 배웠는지 알려주세요"는 대기열입니다. "트랜잭션 해시를 붙여넣으세요"는 정답이 있는 텍스트 또는 URL 작업이며 스스로 정리됩니다. "포지션을 스크린샷으로 찍으세요"는 대기열이고, 파일 작업은 콘텐츠 검사가 전혀 없으므로검토자가 모든 이미지를 열어봅니다. "이 셋 중 어느 것이 우리의 수수료 모델인가"는 퀴즈이고, 퀴즈는 절대 사람에게 도달하지 않습니다.
우리가 옹호할 경험칙: 답을 미리 적어둘 수 있다면 그 작업은 대기열에 있어서는 안 됩니다. 그럴 수 없다면 프롬프트가 해줄 것처럼 가장하지 말고 사람을 배치하세요.
함정: 빈 정답은 모든 것을 승인합니다
이 글에서 여러분의 힘든 한 주를 구해줄 가능성이 가장 높은 문단입니다. 텍스트, URL, 숫자, 날짜 작업의 자동 검증은 회원의 제출물을 여러분이 설정한 정답과 비교하며, 이 네 가지 비교는 모두 정답이 비어 있을 때 단락됩니다. 실패 시 차단하지도 않고 경고하지도 않습니다. 모든 것을 승인합니다.
대량으로 스위치를 켜기 전에 알아야 할 두 가지 관련 동작이 있습니다. 자동 검증이 켜진 투표는 설계상 모든 것을 승인합니다 — 버그가 아니며, 투표에는 오답이 없기 때문입니다. 하지만 백로그를 정리하려고 모듈 전체에 자동 검증을 켜면 투표 보상이 모두에게 지급됩니다. 그리고 파일 업로드에 자동 검증을 켜면 업로드가 승인되는 것이지 내용이 승인되는 것이 아닙니다. 어떤 파일이든 통과합니다.
이 글에서 운영 습관 하나를 가져간다면 이것으로 하세요: 자동 검증을 활성화한 후, 일부러 틀린 답으로 직접 작업을 클레임하고 실패하는지 확인하세요.
중복 제어 하나는 작업을 줄이고, 다른 하나는 주석만 달아줍니다
검토자 알림 은 제출물을 duplicate (다른 회원이 같은 작업에 같은 내용을 보냄) 또는 reused (이 회원이 이전에 보냄)로 표시하며, 텍스트 및 파일 작업에만 적용되고 180일을 거슬러 조회합니다. 이는 참고용입니다 — 판정을 기록하는 코드 경로는 이를 읽지 않습니다. 사람에게 정보를 줄 뿐, 아무것도 결정하지 않습니다. 그리고 파일 작업에서 매칭은 들리는 것보다 약합니다: 업로드는 저장된 URL로 비교되는데, 모든 업로드가 새 키를 받으므로 동일한 파일을 다시 업로드해도 중복으로 전혀 등록되지 않습니다.
제출 시 중복 거부 는 별도의 선택적 설정으로, 반복된 텍스트 답변이 대기열에 도달하기 전에 오류로 거부합니다. 텍스트 및 URL 작업에서 기본적으로 꺼져 있으며, 트리밍, 공백 축소, 소문자화로 정규화하므로 — 바꿔 쓴 표현은 통과합니다 — 그리고 어떤 회원이든 해당 텍스트를 재사용하는 것을 차단합니다, 처음 작성한 사람 포함. 이것이 대기열을 줄여주는 것입니다.
경로 2: 검토자 역할을 가진 사람에게 위임
Zealy의 검토자 역할은 좁은 위임입니다: Zealy API의 225개 역할 제한 라우트 표면 중 9개를 열어주며, 모두 검토에 관한 것이고, 검토자는 자신의 클레임을 승인할 수 없습니다. 역할, 만료, 최대 사용 횟수를 담은 초대 링크로 부여합니다.
Zealy에는 moderator라는 역할이 없습니다. 역할은 reviewer이며, 총 다섯 개입니다: admin, editor, reviewer, guest 그리고 banned. (Zealy 자체의 회원 관리 문서에는 네 개라고 되어 있습니다. banned가 빠져 있는데, 이는 change-role 엔드포인트가 받아들이는 실제 역할입니다. 해당 페이지는 이 글과 같은 변경에서 수정됩니다.)
다섯 역할은 엄격히 선형인 사다리에 놓입니다 — admin이 editor 위, editor가 reviewer 위, reviewer가 guest 위, guest가 banned 위 — 그리고 제품의 모든 권한 검사는 한 가지 질문을 합니다: 이 회원의 역할이 최소한 이 수준인가? 따라서 Zealy의 권한 모델에 대한 정직한 설명은 그런 것이 없다입니다. 권한 집합도, 사용자 정의 역할도, 역할을 하나의 퀘스트, 모듈, 캠페인으로 범위를 좁힐 방법도 없습니다. 우리는 모델과 데이터베이스 정의에서 permission, ability, grant 개념을 검색했고, 유일한 일치는 무관한 OAuth 컬럼뿐이었습니다.
다음은 그 사다리가 225개 역할 제한 표면에 분배하는 내용입니다:
| 최소 역할 | 해당 수준에서 제한된 표면 | 그것이 주는 것 |
|---|---|---|
admin | 140 | 역할, 초대, 결제 표면, 파괴적 작업을 포함한 모든 것 |
editor | 58 | 퀘스트, 모듈, 스프린트 구성, 미공개 퀘스트, 퀘스트 클레임 초기화 |
guest | 17 | 일반 회원 표면 |
reviewer | 9 | 리뷰 목록, 판정 제출, 검토 알림, 검토 이벤트, 사용자별 검토 통계, 퀘스트 보상 목록, 보상 수령자 |
banned | 1 | 없음 |
사다리가 선형이므로 검토자는 guest 수준에서 제한된 모든 것도 얻습니다. 하지만 그 9개 표면이 위임의 전부이며 모두 검토 작업이므로, 누군가를 도와주게 하려고 admin으로 승격하는 것보다 reviewer로 승격하는 것이 훨씬 나은 답입니다.
editor 행에 주목하세요. Editor는 reviewer보다 훨씬 넓은 권한입니다: reviewer가 할 수 있는 모든 것에 더해 퀘스트, 모듈, 스프린트 구성, 미공개 퀘스트 가시성, 클레임 초기화를 가집니다. Zealy 자체의 회원 문서는 이를 퀘스트, 스프린트, 회원 구성 및 모든 페이지 보기로 설명하는데, 실제보다 좁게 읽힙니다; 해당 페이지는 이 글과 같은 변경에서 수정됩니다. 캠페인을 만드는 사람은 editor로, 제출물만 읽는 사람은 reviewer로 승격하세요.
역할을 부여하는 방법과 그 비용
역할 변경은 admin 전용이며, admin은 자신의 역할을 변경할 수 없습니다. 사용할 만한 메커니즘은 역할, 만료, 최대 사용 횟수를 담은 초대 링크입니다. 세 가지를 모두 사용하세요: 48시간 후 만료되고 최대 1회 사용인 초대는 텔레그램 그룹에 8개월 동안 놓여 있는 링크와 매우 다른 대상입니다.
그런 다음 비용에 대해 정직하세요. 검토자는 승인하는 각 클레임에 최대 20,000 보너스 XP를 붙일 수 있고, 이를 제한하는 역할 검사는 없으며, 단일 일괄 작업으로 1,000개의 클레임을 처리할 수 있습니다 — 따라서 한 번의 승인 작업으로 최대 2,000만 XP가 발행될 수 있습니다. 검토를 위임하는 것은 XP 부여 권한을 위임하는 것입니다. 대부분의 커뮤니티에서는 이는 괜찮고 심지어 바람직합니다. 보너스 XP는 검토자가 뛰어난 제출물에 보상하는 방식이기 때문입니다. 하지만 XP가 토큰을 지급하는 리더보드에 반영된다면, 그 사람에게 지급에 영향을 줄 수단을 준 셈입니다. Zealy는 판정별 전체 감사 기록을 남기므로, 이는 사전에 방지할 수 있는 것이 아니라 사후에 탐지할 수 있는 문제입니다. 후보자가 기여자 프로그램에서 나왔다면, 암호화폐 앰배서더 프로그램을 운영하는 방법 에서 해당 역할의 비용을 다룹니다.
검토자는 자신의 클레임을 검토할 수 없습니다 — 조용히
검토자 자신의 클레임은 승인 가능한 대상에서 제외되며, 서비스 계층에서 그리고 네 개의 별도 SQL 가드에서 다시 강제됩니다. 좋습니다. 흥미로운 부분은 예외 사항입니다: 필터는 조용히 작동합니다. 자신의 클레임이 포함된 배치를 일괄 선택한 검토자는 오류를 받지 않습니다. 해당 클레임은 배치에서 제외되어 대기 상태로 남고, 아무도 통보받지 못합니다. 검토자가 승인했다고 확신하는 항목이 여전히 대기열에 남아 있다면, 먼저 이것을 확인하세요.
한 대기열에 두 명의 검토자가 있으면 충돌합니다
Zealy의 검토 대기열에는 클레임, 잠금 또는 할당 기능이 없습니다. API, 백엔드, 웹앱 전반에서 검토자 잠금, 클레임 선점, 검토 할당, 담당자 개념을 저장소에서 검색했으며, 할당 관련 검색 결과는 전혀 없었습니다. 시스템의 유일한 잠금은 이중 쓰기를 방지하는 짧은 쓰기 뮤텍스이며, 대기열 예약이 아닙니다.
그 결과는 예상과 다릅니다. 같은 대기열의 두 검토자는 동일한 클레임을 보고 동일한 제출물을 읽습니다. 두 사람이 동의하면 두 번째 사람은 오류를 받습니다. Zealy는 이미 해당 상태인 클레임의 상태를 다시 설정하는 것을 거부하며, 그 읽기 시간은 사라집니다. 두 사람이 불일치하면 오류가 전혀 발생하지 않습니다. 두 번째 판정이 첫 번째 판정을 대체하고, 보상은 그에 따라 정리되거나 다시 지급되며, 동료가 이미 결정했다는 사실은 아무에게도 통보되지 않습니다. 조용한 경우는 불일치이며, 이는 가장 표시가 필요한 경우입니다. 또한 특정 퀘스트나 모듈에 검토자를 할당할 방법도 없습니다 — 제품에서 "Ana는 디자인 제출물을, Ben은 온체인 증명을 처리한다"를 표현할 수 없습니다.
Zealy에서 검토자 조율은 현재 사람이 해결해야 할 문제입니다. 팀이 Discord에서 논쟁하며 알게 되기 전에, 팀에게 직접 말하세요. 고정 메시지로 대기열을 분할하세요: 모듈별, 요일별, 또는 한 사람은 오래된 것부터 다른 사람은 최신 것부터 처리하는 방식 — 가장 단순한 분할이지만 여전히 충돌을 줄여줍니다.
일괄 검토: 최대 1,000개 클레임에 하나의 판정
Zealy의 일괄 검토는 단일 호출로 최대 1,000개의 클레임을 처리하며, 제약은 해당 호출이 담는 내용입니다: 전체 배치에 하나의 상태, 하나의 코멘트, 하나의 마크, 하나의 보너스 XP 값. 일괄 작업 내에는 항목별 판정이 없습니다. 이는 동질적인 집합 — 망가진 퀘스트의 모든 제출물, 무효화한 작업의 모든 클레임 — 에는 탁월하지만, 혼합된 집합에는 위험합니다. 1,000명의 멤버가 읽는 코멘트가 동일한 문장이기 때문입니다. 선택하기 전에 철저히 정렬하세요.
경로 3: 판정을 기계에 위임
Zealy의 AI 검토는 2026년 8월 16일 기준 Plus 및 Enterprise 플랜에서, 퀘스트별로 작성한 프롬프트에 대해 Google Gemini 2.5 Flash Lite를 실행합니다. 확인용 판정 권장을 제공하는 것이 아닙니다. 판정을 작성하며, 그 근거가 멤버가 읽는 코멘트가 됩니다.
이를 두 번 읽으세요. Zealy의 자체 검토 문서는 AI 검토를 검토 처리를 돕는 지능형 권장 사항 제공으로 설명했습니다. 이는 잘못되었으며, 이 게시물과 동일한 변경에서 수정됩니다. 코드 경로에는 사람의 확인 단계가 없습니다: 모델이 결과를 반환하면 Zealy는 전용 시스템 계정으로 승인 또는 거부를 기록하고, 모델의 근거가 멤버의 받은편지함에 도착합니다.
이는 AI 지원 검토와는 실질적으로 다른 제품 결정이며, 그에 걸맞은 수준의 주의가 필요합니다:
- 퀘스트별로 켜세요, 퀘스트에서 AI 검토를 활성화하고 비어 있지 않은 프롬프트를 작성하여. 이는 커뮤니티 전체 스위치가 아니며, 이는 올바른 세분화입니다: 판단이 필요한 작업은 자동화하지 않고 대량 작업 하나만 자동화할 수 있습니다.
- 프롬프트를 분위기가 아니라 거부 기준으로 작성하세요. 모델이 멤버에게 표시되는 거부 메시지를 생성하므로, 프롬프트의 모호한 부분은 누군가의 제출물에 대한 모호하고 따라서 격앙된 코멘트가 됩니다.
- 크론이 누락된 항목을 다시 대기열에 넣습니다 15분마다, 검토자 없이 한 시간 이상 대기 중인 AI 검토 클레임을 처리합니다. 백로그가 조용히 방치되지 않습니다.
사용 시 측정 관련 주의 사항 하나. AI 판정은 관리자 역할을 가진 시스템 계정에 귀속되므로, AI 검토를 사용하는 커뮤니티에서는 다른 검토자와 마찬가지로 상위 검토자 분석에 나타납니다. 팀에 사람이 처리한 클레임 수를 알리기 전에 이를 제외하세요.
플랜, 2026년 8월 16일 확인
AI 검토는 Plus 및 Enterprise 플랜에 포함되며, Zealy의 가격 페이지에는 Free 또는 Standard에는 포함되지 않는다고 명시되어 있습니다. 2026년 8월 16일 Zealy의 자체 기능 API를 통해 확인한 무료 커뮤니티에서는 사유 requires_plus_or_enterprise와 함께 사용 불가로 보고되었습니다. 플랜 이름만 보고 가정하지 말고 자신의 커뮤니티에서 기능을 확인하세요.
Plus는 연간 결제 기준 월 $359이며, Enterprise는 맞춤형으로 연간 결제됩니다. Free 플랜은 $0으로 월 1,000건의 퀘스트 클레임과 무제한 멤버를 제공하고, Standard는 연간 결제 기준 월 $149입니다. 가격에는 VAT 및 기타 적용 가능한 판매세가 제외되며, 모든 가격은 다음에서 가져왔습니다: Zealy의 가격 페이지, 2026년 8월 16일 확인.
중요한 결정: 주당 200건의 클레임이라면, 텍스트 과제를 검증 가능한 과제로 전환하는 데 쓰는 오후 한 나절에 비해 자동화를 위한 업그레이드는 나쁜 거래입니다. 주당 수천 건의 개방형 제출이 있고 기준이 문서화되어 있다면, 좋은 거래입니다.
MCP를 통한 에이전트 위임
또 다른 기계 경로는 에이전트입니다. Zealy는 자사의 MCP 서버를 통해 검토를 노출하며, 그 위임의 형태는 의도적으로 사람의 경우보다 더 제한적입니다.
- 에이전트는 한 번의 호출로 최대 1,000건의 클레임을 제출할 수 있으며, 이는 대량 검토와 동일한 상한이며, 배치당 하나의 판정이라는 동일한 제약이 있습니다.
- 에이전트는
admin역할이 필요합니다, 반면 사람 검토자는reviewer만 필요합니다. 공개 검토 경로는 그보다 낮은 권한의 MCP 검토 결정을 거부하므로, 좁은 권한 부여의 에이전트용 버전은 존재하지 않습니다 — 이는 예상했을 최소 권한 모델의 반대입니다. - 모든 쓰기에는 새로운 사람 확인 토큰이 필요합니다. 세션이나 사전 승인이 아니라, 호출마다 새로운 확인입니다.
- 금전은 금지됩니다. 모든 공개 관리자 검토에 대한 검사가 NFT, 토큰, USDC 또는 Zaps 보상을 포함한 클레임이 에이전트에 의해 전환되는 것을 차단합니다. 에이전트는 XP 대기열을 처리할 수 있지만, 지급이 발생하는 클레임은 이동할 수 없습니다. 배포를 운영 중이라면, 활성 커뮤니티 멤버에게 토큰을 배포하는 방법 에서 실제로 누가 무엇을 보내는지 다룹니다.
- 에이전트는 게스트 초대만 발급할 수 있으며, 검토자 초대는 절대 발급할 수 없습니다. 에이전트가 대기열에 인력을 채워줄 수는 없습니다.
답이 진정으로 다른 사람일 때
판단이 곧 제품일 때 고용하거나 모집하세요: 주관적 품질, 커뮤니티 규범, 이의 제기, 엣지 케이스, 그리고 잘못된 거절이 기여자를 잃게 만드는 모든 경우입니다. 대기열에 물량이 아니라 실제 이견이 있을 때 사람을 추가하세요. 물량은 설계 문제이고, 이견은 인력 문제입니다.
검토자를 추가하기 전에 우리가 적용할 테스트: 대기 중인 클레임 20건을 가져와 두 사람이 독립적으로 검토하게 하세요. 19건에 동의하면 대기열은 물량이며, 물량은 규칙과 프롬프트로 해결됩니다. 13건에 동의하면 대기열에 실제 판단이 포함된 것이며, 어떤 자동 검증 설정이나 모델 프롬프트도 그 이견을 사라지게 하지 못합니다 — 보이지 않게 만들 뿐입니다.
사람이 정답이며 우리가 말리지 않을 세 가지 상황:
품질이 보상 기준인 창작 및 장문 제출물. 완료된 작업이 아니라 좋은 작업에 비용을 지불한다면, 누군가 '좋음'의 의미를 반복적으로 결정하고 그것을 옹호해야 합니다.
이의 제기 경로가 있는 모든 것. 불만을 제기하는 거절된 멤버에게는 결정을 번복할 수 있는 사람이 필요하며, 검토를 번복하는 것은 승인으로 이미 부여된 Discord 역할을 제거하는 일이기도 합니다 — 검토자가 클레임을 성공에서 실패로 뒤집는 것도 마찬가지입니다. 그 외에는 그 부여를 다시 확인하는 것이 없습니다; 일회성입니다.
고가 지급. 판정이 누가 토큰을 받는지를 결정한다면, 사람을 배치하세요. Zealy 자체의 에이전트 규칙은 이미 그 의견을 담고 있습니다: 기계는 금전적 보상이 포함된 클레임을 전환할 수 없습니다.
Zealy가 측정하는 것과 측정하지 않는 것
Zealy는 대기 중인 검토 수, 판정별 감사 추적, 물량 및 승인율 기준 상위 검토자, 멤버별 별 및 플래그 합계, 최대 10,000행의 CSV 내보내기를 보여줍니다. 검토 소요 시간, 대기열 지연, SLA, 처리량 지표는 계산하지 않습니다. 우리는 코드베이스에서 그 이름들을 검색했고 아무것도 찾지 못했습니다.
우리가 정확하게 말하는 이유는, 원래 계획했던 이 글의 버전이 검토 대기열 타이밍 데이터를 기반으로 했는데 그 데이터가 존재하지 않기 때문입니다. 우리는 Zealy의 패키지에서 검토 소요 시간, 검토 지연, 평균 검토 시간, 검토 기간, 검토 처리량, 시간당 검토 수를 검색했습니다. 결과 없음, 경과 구간 없음, 처리량 대시보드 없음. 그러므로 벤더가 고객이 검토 시간을 몇 퍼센트 줄였다고 말한다면, 그 숫자를 어떤 시스템이 산출했는지 물으세요. 우리는 우리 숫자를 산출할 수 없었고, 만들어내지 않을 것입니다.
올바르게 읽어야 할 두 가지:
"승인율 기준 상위 검토자"는 승인율이지 정확도가 아닙니다. 이는 검토자의 판정 중 승인 비율이 얼마인지 알려줍니다. 그 판정이 옳았는지에 대해서는 아무것도 말하지 않습니다. 모든 것을 승인하는 검토자는 100%를 받습니다.
검토 소요 시간은 도출 가능하지만, 보고되지는 않습니다. 검토 CSV에는 각 클레임의 생성 및 업데이트 타임스탬프가 있지만 검토 이벤트는 없으므로, 한 번 검토되고 그대로 방치된 클레임의 경우 두 타임스탬프 간의 차이가 검토 소요 시간이며, 중앙값은 스프레드시트 하나 거리에 있습니다. 재검토된 클레임은 정확성을 위해 클레임별 이력을 필요로 합니다. 이는 Zealy의 실제 격차이며, 우리는 이를 우회하기보다 기록해 두고자 합니다.
산술, 산술이라고 명확히 표시된
여기에는 Zealy 데이터가 없으므로, 여러분의 숫자로 채울 틀을 제시합니다. 모든 입력은 우리가 측정한 것이 아니라 여러분이 제공하는 가정입니다.
weekly human-review load
= claims per week
× share of claims on text / URL / number / file / poll tasks
× share of those not auto-validated
× your own seconds per review
주당 2,000건의 클레임, 그중 3분의 1이 사람이 필요한 과제 유형, 자동 검증 없음, 건당 40초를 가정하면: 주당 약 7.4시간이며, 전적으로 여러분이 제공한 숫자로 구성됩니다. 요점은 답이 아닙니다. 두 번째와 세 번째 요소가 가시화된다는 것이며, 그것이 누구도 고용하지 않고 바꿀 수 있는 두 가지입니다.
이 부분에서 다른 도구가 Zealy를 앞서는 곳
Zealy의 Discord 봇은 아무런 관리(moderation)도 하지 않습니다. 누구도 추방, 차단, 타임아웃시키지 않으며, 환영 메시지, 반응 역할, 티켓팅, 로깅 기능도 제공하지 않습니다. Discord 자체의 관리 도구와 이를 기반으로 만들어진 Discord 네이티브 봇이 그 역할을 담당합니다. Zealy의 API 키 역시 사람 역할보다 훨씬 세분화되어 있습니다.
첫 번째 요점에 대해, 우리는 Zealy의 Discord 봇 소스에서 kick, ban, timeout, bulk-delete, guild-ban, AutoMod, moderate-members, audit-log 호출과 환영 메시지, 반응 역할, 음성 채널, 티켓, 로깅을 검색했습니다. 유일하게 일치한 것은 캐싱을 비활성화하는 줄들이었습니다. 설치 시 전체 Administrator 옵션과 함께 제한된 권한 세트도 제공하는데 — Manage Roles, Mention Everyone, Send Messages — 이는 아무것도 관리하지 않을 무언가의 권한 세트와 정확히 일치합니다. 문제가 사람들의 잘못된 행동이라면 in 귀하의 Discord 서버에서, Zealy는 잘못된 도구입니다: 우리의 Discord 참여 및 성장 도구 가이드 가 더 나은 출발점입니다 — 이는 이러한 것들의 상당 부분을 무료로 처리하는 관리 봇과 Discord 네이티브 설정을 다루며 — 그리고 Discord 통합 문서 는 Zealy의 봇이 실제로 하는 일을 설명합니다.
두 번째 요점에 대해, 비교는 민망할 정도로 내부적입니다. Zealy의 API 키 모델에는 40개의 개별 기능이 있으며, 리뷰 읽기, 리뷰 내보내기, 리뷰 쓰기를 위한 별도 기능도 포함됩니다. 그리고 두 가지 퀘스트 빌딩 프리셋은 리뷰 기능을 전혀 갖추지 않습니다. 이는 진정한 최소 권한 모델입니다: Zealy와 통신하는 기계는 리뷰 큐를 읽는 권한은 부여받되 결정하지는 못하도록 할 수 있습니다.
사람은 그럴 수 없습니다. 사람은 5단계 사다리에서 한 위치를 받으므로, 누군가가 승인 없이 분류하고 표시하기를 원한다면 이를 표현할 방법이 없습니다. API는 방법을 알지만 역할 모델은 모릅니다. 사람들이 우리에게 커스텀 역할을 요청할 때, 이것이 그들이 부딪힌 격차이며, 우리 자신의 API 키 모델을 지적하는 것이 이를 인정하는 가장 공정한 방법입니다. 그리고 다시 한 번, 운영적인 이유로: 작업 큐로 만들어진 모든 도구는 할당을 통해 다인 처리량을 해결합니다. Zealy는 팀 채널의 고정 메시지로 해결합니다.
Zealy에서 이를 설정하는 방법, 순서대로
다섯 가지 인간 작업 유형을 사용하는 퀘스트를 감사하세요. 가능한 것을 전환하세요. 정답을 신중히 설정하세요, 빈 정답은 모든 것을 승인하기 때문입니다. 그런 다음 만료되는 제한된 링크로 리뷰어 한두 명을 초대하고, 누가 어떤 모듈을 맡을지 구두로 합의한 후에야 AI 리뷰가 플랜 업그레이드의 가치가 있는지 결정하세요.
1. 큐를 크기가 아닌 작업 유형별로 세세요, 그런 다음 전환되는 것을 전환하세요. 중요한 것은 텍스트, URL, 숫자, 파일, 투표 작업에 얼마나 많은 대기 중인 클레임이 있는지, 그리고 그중 얼마나 많은 것이 알 수 있는 답이 있는 질문을 하는지입니다. 하나의 정답이 있는 질문은 퀴즈나 정답이 있는 텍스트 작업이 됩니다; 당신이 했다는 것을 증명하는 스크린샷은 Zealy가 확인할 수 있는 흔적을 남기는 곳이라면 어디든 온체인, 링크 또는 통합 작업이 됩니다.
2. 활성화하는 모든 자동 검증을 테스트한 후, 복사-붙여넣기가 실패 모드인 곳에서 중복 거부를 켜세요. 잘못된 답으로 직접 작업을 클레임하고 실패하는지 확인하세요; 그 2분 습관이 빈 정답 함정을 잡아냅니다. 중복 거부는 텍스트 및 URL 작업에서 기본적으로 꺼져 있으며 바꿔 말한 것을 잡아내지 못합니다.
3. 제한된 초대 링크로 편집자가 아닌 리뷰어를 승격하세요. 만료와 최대 사용 횟수를 설정하고, 그 역할이 클레임당 최대 20,000 보너스 XP를, 한 번의 작업으로 최대 1,000개의 클레임에 걸쳐 부여할 수 있으며, 당신이 모든 판정을 볼 수 있다는 것을 서면으로 알리세요.
4. 고정 메시지에서 큐를 분할하세요. 모듈별, 요일별, 또는 오래된 것 우선 대 최신 우선으로. 제품이 대신 해주지 않으며, 분할되지 않은 하나의 큐에 두 사람이 있으면 작업이 중복됩니다.
5. 이제서야 AI 리뷰를 고려하세요. 기준을 문서화할 수 있고, 볼륨이 많으며 Plus 또는 Enterprise를 사용 중이라면, 프롬프트를 기꺼이 보낼 수 있는 거부 메시지로 작성하세요, 그것이 바로 프롬프트가 되는 것이기 때문입니다. 하나의 퀘스트에서 시작하고, 다른 곳에서 활성화하기 전에 그것이 작성하는 처음 50개의 댓글을 읽으세요.
6. 매월 내보내고 자신만의 리뷰 소요 시간을 계산하세요. Zealy는 이를 계산하지 않습니다. CSV 내보내기에서 각 클레임의 생성 타임스탬프를 업데이트된 타임스탬프에서 빼세요; 이는 한 번 리뷰된 클레임에는 정확하며, 재리뷰된 클레임은 리뷰 이력이 필요합니다. 스프레드시트에서 10분이면 이 중 무엇이 효과가 있었는지 알 수 있습니다.
관통하는 요점은 "사람을 고용해야 하나"가 거의 항상 잘못된 질문이며, 한 가지 설계 결정을 너무 늦게 묻는 것입니다. 먼저 규칙에 위임하세요, 작업이 옮겨지는 것이 아니라 사라지는 유일한 경로이기 때문입니다. 두 번째로 사람에게 위임하고, XP 권한과 충돌에 대해 그들에게 솔직하세요. 마지막으로 기계에 위임하고, 기준을 문서화할 수 있을 때만 하세요. 더 넓은 맥락은, 커뮤니티 관리 기초 모듈 이 동반 자료이며 Zealy의 리뷰 문서 가 큐 메커니즘을 다룹니다. 그리고 아직 도구를 정하지 않았다면, 우리의 커뮤니티 관리 소프트웨어 조사 가 관리 노동을 포함한 더 넓은 카테고리의 가격을 제시합니다.