LaunchRepo디렉터리가 제출을 받았지만 아직 결정하지 않았다면 그 제출은 대기 중입니다. 처음 보는 사람이 등록 페이지를 열 수 있고 페이지 어디에도 “대기 중”이라는 표시가 없다면 게시됨입니다. 예약됨은 플랫폼이 출시 날짜를 확정했다는 뜻입니다. 제출됨은 그것만으로는 버튼을 눌렀다는 뜻일 뿐입니다. 이 네 단어는 서로 다른 네 순간을 가리키며, 이를 “완료” 열 하나에 몰아 저장하는 트래커는 누구도 설명할 수 없는 합계를 보고하게 됩니다. 이 글은 각 상태가 무엇인지, 무엇이 증거가 되는지, 그리고 디렉터리 출시를 흔들리지 않는 숫자로 보고하는 방법을 설명합니다. 이 상위 개념의 짧은 정의는 등록 상태 항목을, 매일의 루틴은 디렉터리 제출 추적 가이드를 보세요.
열 하나, 질문 다섯 개
디렉터리에 제품을 제출하면, 결과에 관심 있는 사람들은 서로 다른 것을 알고 싶어 합니다.
- 내 쪽 작업은 끝났나? 모든 항목을 채우고 버튼을 눌렀나?
- 플랫폼이 받았나? 감사 페이지, 이메일, 계정 안의 항목.
- 무언가를 기다리고 있나? 모더레이션, 대기열 자리, 승인, 날짜.
- 누구나 볼 수 있나? 로그인하지 않은 사람에게도 열리고 “대기 중” 표시가 붙지 않은 URL.
- 내가 해야 할 일이 있나? CAPTCHA, 2단계 인증 요청, 내 웹사이트의 배지, 유료 경로에 대한 결정.
“완료”는 첫 번째 질문에 답하면서 네 번째 질문까지 슬그머니 주장합니다. 그래서 40이라고 적힌 스프레드시트가 결국 6을 뜻하게 됩니다. 처음 두 질문의 차이는 따로 항목이 있습니다: 초안 vs 제출됨.
대기 중 vs 게시됨, 예약됨 vs 제출됨
사람들이 가장 많이 헷갈리는 쌍들입니다. 각 행은 상태를 바꾸기 전에 던져야 할 질문입니다.
| 쌍 | 차이 | 다음 단계로 넘기는 증거 |
|---|---|---|
| 제출됨 vs 검토 대기 | 제출됨은 내 행동이고, 검토 대기는 모더레이션이 시작됐다는 플랫폼의 확인입니다 | 플랫폼의 접수 증거: 완료 페이지, 이메일 또는 대시보드 항목 |
| 검토 대기 vs 게시됨 | 검토 대기는 결정을 기다리고, 게시됨은 공개되어 아무 표시도 없습니다 | 로그아웃 상태에서 공개 URL이 열리고 “대기 중” 표시가 없음 |
| 예약됨 vs 게시됨 | 예약됨에는 확정된 날짜가 있고, 게시됨에는 공개 페이지가 있습니다 | 그 날짜나 그 이후에 페이지를 열어 봄 |
| 대기열 vs 예약됨 | 대기열은 줄에서의 자리가 있고, 예약됨은 날짜가 있습니다 | 플랫폼이 날짜를 명시함 |
| 게시됨 vs 이미 등록됨 | 게시됨은 이번 제출에서 나왔고, 이미 등록됨은 시작하기 전부터 있었습니다 | 기존 등록이 있는지 먼저 확인 |
마지막 행은 보기보다 중요합니다. 디렉터리에 이미 내 제품이 등록되어 있다면, 다시 제출하는 것은 플랫폼이 거부하거나 삭제할 수 있는 중복을 만듭니다. 그래서 트래커에는 이를 위한 별도의 상태가 있습니다.
답하는 질문별로 묶은 11가지 상태
LaunchRepo 트래커(submissions.json에 기록하는 record.py, 그리고 로컬 대시보드의 같은 규칙)는 11가지 상태를 씁니다. 각 상태는 기록하기 전에 최소한의 관찰을 요구합니다. 대시보드는 모든 플랫폼을 정확히 하나의 버킷에 분류하므로, 버킷을 모두 더하면 항상 시도한 플랫폼 수와 같습니다.
| 질문 | 상태 | 대시보드 버킷 | 다음 행동 |
|---|---|---|---|
| 내 쪽 작업 | draft |
draft |
마무리해서 제출하거나 폐기 |
| 내 쪽 작업 | prepared_needs_human |
needs_you |
지정된 단계 수행: CAPTCHA, 2FA, 배지, 결정 |
| 접수됨 | submitted_pending_review |
pending |
명시된 검토 기간이 지나면 다시 확인 |
| 접수됨 | queued |
queued |
대기열을 기다리며 다시 확인하되, 절대 재제출하지 않기 |
| 접수됨 | scheduled |
scheduled |
확정된 날짜에 등록 페이지 열기 |
| 공개 | live |
live |
없음. URL 보관 |
| 공개 | already_listed |
already_listed |
없음. 다시 제출하지 않기 |
| 중단 | blocked |
problem |
자격 조건이나 계정 제한을 해결하거나 제외 |
| 중단 | unavailable |
problem |
경로가 작동할 때 다시 시도 |
| 중단 | deferred_paid |
parked |
내가 결정: 실행 밖에서 결제하거나 건너뛰기 |
| 중단 | not_a_fit |
parked |
없음 |
11가지는 많아 보입니다. 실제로는 각 상태가 이웃 상태와 합쳐졌을 때 적어도 한 번은 잘못된 보고를 낳았기 때문에 존재합니다. 결과 기록 가이드에 상태별 정확한 명령어가 나와 있습니다.
예시 1: SaaSHub, 공개됐지만 대기 중
공개된 SaaSHub 현장 가이드에 기록된 SaaSHub 제출은 링크만 있으면 누구나 열 수 있는 제품 페이지를 만들었습니다. 동시에 그 페이지에는 눈에 보이는 표시가 있었습니다: Pending approval(승인 대기).
열 하나짜리 트래커는 페이지가 열리니까 이를 완료로, 심지어 게시됨으로 기록합니다. LaunchRepo의 규칙은 정반대입니다: 공개적으로 접근할 수 있다는 사실만으로는 승인의 증거가 되지 않습니다. 페이지에 대기 중이라고 적혀 있는 동안 등록은 submitted_pending_review에 머뭅니다. 누군가 다시 열어 보고, 대기 표시가 없는 것을 확인하고, 명시적인 확인 플래그와 함께 URL을 기록한 뒤에야 live로 넘어갑니다. 제출 당일 게시됨 개수는 늘지 않았고, 대신 그 행에는 다시 확인할 날짜가 생겼습니다.
예시 2: TinyLaunch, 승인이 남은 채 예약됨
TinyLaunch 현장 가이드에 기록된 TinyLaunch는 무료 Standard 경로에서 이후 주간 출시 슬롯을 제시했습니다. 날짜를 확정한 뒤 대시보드에는 그 옆에 Waiting for approval(승인 대기)이 표시되었습니다.
이를 잘못 기록하는 방법은 두 가지입니다. 캘린더에 날짜가 있으니 live로 기록하거나, 승인이 남았으니 submitted_pending_review로 기록하는 것입니다. 트래커는 확정된 날짜와 함께 scheduled를 기록하고, 남은 승인은 메모에 남깁니다. 두 사실이 모두 살아남습니다. 날짜는 존재하고, 그 날짜가 지켜지지 않을 수도 있습니다. 트래커는 제품의 출시일 하한선보다 이른 scheduled 날짜도 거부하므로, 다음 주 월요일의 무료 슬롯이 출시 페이지가 준비되기 전에 공개될 수 없습니다. 예약 등록 항목은 이 상태를 한 단락으로 설명합니다.
트래커가 거부하는 것
페이지에 적힌 규칙은 건너뛰기 쉽습니다. 다음 규칙들은 스크립트가 강제합니다. 아래는 2026년 9월 30일에 새 워크스페이스에서 예시 제품으로 실제 실행한 결과입니다. 공개 현장 가이드를 그대로 반영한 결과 6개를 기록한 다음, SaaSHub를 게시됨으로 올리려고 시도했습니다. buckets.py는 이 글을 위해 작성한 네 줄짜리 보조 스크립트로, 대시보드 자체의 버킷 함수가 반환하는 값을 출력합니다.
$ python3 scripts/record.py --project projects/my-product saashub submitted_pending_review --note 'Public page labelled Pending approval' --next-action 'Recheck the label after the review window'
Recorded saashub: submitted_pending_review
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 2, "scheduled": 2, "problem": 2}
$ python3 scripts/record.py --project projects/my-product saashub live --note 'Page loads' --next-action None
Tracker rejected input: Public states require a reviewed URL and --confirmed-public
$ python3 scripts/record.py --project projects/my-product saashub live --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Tracker rejected input: Platform exists: inspect the record and use --replace intentionally
$ python3 scripts/record.py --project projects/my-product saashub live --replace --public-url https://www.saashub.com/my-product --confirmed-public --note 'Pending label gone' --next-action None
Recorded saashub: live
$ python3 scripts/buckets.py
{"attempted": 6, "submitted": 4, "pending": 1, "scheduled": 2, "live": 1, "problem": 2}여기서 세 가지가 일어납니다. “페이지가 열린다”는 live에 충분하지 않습니다. 트래커는 검토한 공개 URL과 확인 플래그를 요구합니다. 기존 행은 절대 조용히 덮어써지지 않습니다. 바꾸려면 의도적으로 --replace를 써야 합니다. 그리고 SaaSHub를 올리면 플랫폼 하나가 대기 중에서 게시됨으로 옮겨 가지만 제출됨은 4로 그대로입니다. 상태 변경은 새 제출이 아니기 때문입니다. 게시된 등록 페이지가 기록되면, 그 행에는 누구나 확인할 수 있는 URL이 담깁니다.
합계 하나 대신 세 개의 숫자
좋은 보고는 숫자 하나만 내놓지 않습니다. 세 개를 내놓고, 각각은 다른 질문에 답합니다.
- 제출됨: 제품을 받은 플랫폼 수. 대시보드에서는
pending+queued+scheduled+live입니다. - 게시됨: 오늘 링크할 수 있는 공개 등록 페이지 수.
- 내 조치 필요: 사람을 기다리는 행의 수.
같은 규칙이 실행 목표에 무엇이 포함되는지도 결정합니다. 툴킷의 런북은 플랫폼이 submitted_pending_review, queued, scheduled, live 중 하나에 처음 도달할 때 한 번 셉니다. 초안, 사람에게 넘긴 일, 유료 경로, 거절된 후보, already_listed는 목표를 올리지 않으며, 같은 플랫폼의 이후 업데이트도 다시 세지 않습니다. 실제로 제출했지만 나중에 모더레이션에서 거절된 제출은 제출됨으로 계속 셉니다. 실수로 기록한 접수만 --invalidate-run-confirmation으로 바로잡습니다.
우리 파일럿이 이 구분이 왜 중요한지 보여 줍니다. 창업자 페이지에 공개한 2026년 9월 14일의 SeoMap 로그에는 제출 시도 211건이 있었습니다. 게시됨 20건, 검토 대기 97건, 예약됨 24건입니다. 나머지 70건은 이 세 상태 중 어디에도 도달하지 못했습니다. “211건 완료”는 한 가지 의미에서는 사실이지만, 쓸모 있는 모든 의미에서는 틀린 말이었을 것입니다.
에이전트에게 이것이 나보다 더 필요한 이유
디렉터리 다섯 곳에 직접 제출한다면 어느 곳이 대기 중이고 어느 곳이 캘린더를 보여 줬는지 기억할 수 있습니다. 세션을 실행하고 닫았다가 내일 다시 시작하는 AI 에이전트는, 그것도 어쩌면 다른 컴퓨터의 다른 에이전트로 시작한다면, 기억하지 못합니다. 에이전트는 먼저 트래커를 읽고 상태에 따라 결정합니다.
prepared_needs_human행과 확인할 때가 된scheduled출시가 먼저입니다.- 명시된 검토 기간이 지난
submitted_pending_review행은 다시 확인합니다. 새치기를 위한 새 제출이 아니라 기존 기록을 확인합니다. live행은 그대로 둡니다.
상태가 틀리면 이 결정은 모두 틀립니다. 첫날 SaaSHub를 게시됨으로 기록했다면 아무도 승인 여부를 확인하지 않았을 것입니다. TinyLaunch를 그냥 제출됨으로 기록했다면 아무도 출시일에 페이지를 확인하지 않았을 것입니다. 상태는 에이전트의 기억이고, 로컬 대시보드는 그 기억을 읽는 곳입니다.
직접 실행을 준비한다면 LaunchRepo 작동 방식에서 트래커가 워크플로의 어디에 있는지 볼 수 있고, SaaS 창업자 페이지는 실제 출시 캘린더가 있는 제품을 다룹니다. 트래커, 대시보드, 그리고 활성 플레이북 299개(2026년 9월 24일 기준)는 1회성 라이선스에 포함됩니다.
자주 묻는 질문
대기 중과 게시됨의 차이는 무엇인가요?
대기 중은 디렉터리가 제출을 받았지만 검토를 끝내지 않았다는 뜻입니다. 게시됨은 등록 페이지가 공개되어 있고 대기 표시가 없다는 뜻입니다. 열리는 페이지도 여전히 대기 중일 수 있으므로 URL만이 아니라 표시를 확인하세요.
예약된 등록은 이미 게시된 건가요?
아니요. 예약됨은 플랫폼이 출시 날짜를 확정했다는 뜻입니다. 등록 페이지는 그 날짜에 공개되며, 승인이 아직 남아 있을 수도 있습니다. 게시됨으로 기록하기 전에 그 날짜나 그 이후에 페이지를 열어 보세요.
감사 페이지가 뜨면 제출이 승인된 건가요?
아니요. 감사 페이지는 폼이 전송되었다는 것을 보여 줄 뿐입니다. 기껏해야 접수를 증명하므로, 플랫폼이 등록 페이지를 게시할 때까지 상태는 검토 대기입니다.
제출은 얼마나 오래 대기 중으로 남나요?
플랫폼의 검토가 걸리는 만큼입니다. 무료 경로는 느린 경우가 많고, 이 사이트의 한 현장 가이드는 30일이 넘는 예상 기간을 기록하고 있습니다. 플랫폼이 밝힌 기간을 쓰고, 밝히지 않았다면 후속 확인 날짜를 정해 두세요.
등록이 계속 대기 중이면 다시 제출해야 하나요?
아니요. 검토 기간이 지난 뒤 기존 제출을 다시 확인하고, 플랫폼 규칙이 허용하면 플랫폼에 문의하세요. 다시 제출하면 중복이 생길 수 있고, 대기열에서 순서가 앞당겨지지도 않습니다.
출처: LaunchRepo 툴킷 1.9.0의 RUNBOOK.md(상태 표, 집계 및 수정 규칙), scripts/record.py, scripts/dashboard_status.py; 2026년 9월 30일의 실제 트래커 실행; 공개된 SaaSHub와 TinyLaunch 현장 가이드(2026년 9월 13일 관찰); 창업자 페이지의 2026년 9월 14일 SeoMap 로그.