LaunchRepo모더레이션이 있는 디렉터리에는 출시 3–4주 전에 제출하고, 날짜를 직접 고르게 해 주는 플랫폼은 출시 주가 정해진 뒤에만 예약하세요. 한 문장으로 요약한 타이밍 전략의 전부입니다. 이것이 통하는 이유는 디렉터리 등록이 제출하는 순간 공개되지 않기 때문입니다. 각 디렉터리가 처리할 때 공개되며, 무료 경로에서는 몇 주가 걸릴 수 있습니다. 출시가 여기저기 흩어지지 않고 한 주에 모이길 원한다면 하한선이 필요합니다. 그 날짜 이전에는 아무것도 예약할 수 없는 가장 이른 날짜입니다. 이 글은 그 이유를 보여 주고, 주별 계획을 제시하며, LaunchRepo 트래커가 하한선을 어떻게 강제하는지 보여 줍니다.
무료 등록이 생각보다 늦게 공개되는 이유
디렉터리의 무료 경로로 제품을 제출해 본 적이 없다면 소요 기간에 놀랄 것입니다. 다음은 이 사이트의 공개 현장 가이드에서 가져온 내용으로, 모두 2026년 9월 13일에 관찰했습니다.
- SaaSHub는 제출 직후 공개적으로 접근 가능한 페이지를 만들었고, 거기에는 “Pending approval”(승인 대기)이라는 표시가 붙어 있었습니다. 접근 가능하다고 승인된 것은 아니므로, 트래커는 그 표시가 사라질 때까지 검토 대기로 유지합니다.
- Pitchwall은 제출을 “Under Review”(검토 중)로 받았고, 검토 예상 기간은 30일 이상이었습니다.
- TinyLaunch는 무료 Standard 경로에서 이후 주간 슬롯을 제시했고, 날짜를 고른 뒤에도 여전히 “Waiting for approval”(승인 대기)을 표시했습니다. 예약됨이지만 승인은 아직 남은 상태입니다.
- Uneed는 관찰한 무료 경로에서 계정당 대기 중인 런칭을 하나만 허용했으므로, 두 번째 제품은 첫 번째가 처리될 때까지 기다립니다.
- Product Hunt는 런칭 날짜와 시간대를 확정해 주었습니다. 그것은 날짜를 확정한 것이지, 홈페이지 노출을 확정한 것이 아닙니다.
이는 불평이 아닙니다. 무료 등급은 대기열을 가진 사람들이 검수하고, 등급이 무료이기 때문에 대기열이 깁니다. 툴킷의 런북은 에이전트에게 많은 무료 디렉터리가 며칠이 아니라 몇 주가 걸린다고 미리 알려 주고, 플랫폼이 밝히지 않은 검토 기간을 절대 지어내지 말라고 지시합니다. 각 상태의 의미는 등록 상태 항목에서 설명합니다.
두 종류의 플랫폼, 두 개의 시계
사용하려는 모든 디렉터리는 두 그룹 중 하나에 속하며, 두 그룹은 정반대의 타이밍이 필요합니다.
| 모더레이션이 있는 디렉터리 | 날짜를 고르는 플랫폼 | |
|---|---|---|
| 공개 시점을 누가 정하나 | 디렉터리의 검토 대기열 | 내가 슬롯을 골라서 정함 |
| 제출 후 흔한 신호 | “Pending approval”, “Under Review”, 대기열 순번 | 확정된 날짜와 시간대 |
| 행동할 때 | 일찍: 출시 3–4주 전 | 늦게: 출시 1–2주 전, 하한선을 정한 뒤 |
| 트래커 상태 | submitted_pending_review 또는 queued |
날짜와 함께 scheduled |
| 타이밍을 잘못 잡으면 생기는 위험 | 출시 열기가 지난 뒤에 등록이 나타남 | 출시 페이지가 준비되기 전에 등록이 공개됨 |
| 하한선이 적용되나? | 아니요: 제출은 게시가 아님 | 예: 하한선 이전 슬롯은 불가 |
이 표가 전략 전체를 설명합니다. 모더레이션이 있는 디렉터리는 느리고 내가 통제할 수 없으므로 먼저 시작합니다. 날짜를 고르는 플랫폼은 빠르고 완전히 내 통제 아래 있으므로 출시 주가 정해질 때까지 미뤄 둡니다.
목표 날짜와 하한선
목표 날짜는 일이 일어났으면 하는 때입니다. 하한선은 무엇이든 일어날 수 있는 가장 이른 때입니다. 디렉터리는 목표를 믿을 수 없게 만들고 하한선은 손쉽게 만듭니다. 내가 통제하는 것은 두 가지, 언제 제출하는지와 언제 예약하는지뿐이기 때문입니다.
목표만 있는 경우를 생각해 보세요. 출시 주에 등록이 공개되길 원합니다. 검토에 몇 주가 걸리니 에이전트는 4주 일찍 시작합니다. 그러면 대부분의 모더레이션 디렉터리는 자기 일정대로 게시합니다. 하루 만에 게시하는 곳도, 출시 후에 게시하는 곳도, 끝내 게시하지 않는 곳도 있습니다. 주간 런칭 보드나 Product Hunt의 캘린더처럼 날짜를 고르게 해 주는 플랫폼은 에이전트가 처음 본 빈 슬롯을 기꺼이 받아 줍니다. 그 슬롯이 다음 주 월요일일 수 있고, 그러면 가장 좋은 런칭 플랫폼이 랜딩 페이지, 변경 내역, 공지가 준비되기도 전에 공개되어 버립니다.
하한선을 출시 주 월요일로 정하면 이 문제는 사라집니다. 제출은 게시가 아니고 하한선은 제출에 적용되지 않으므로, 에이전트는 여전히 모더레이션 디렉터리에 일찍 제출할 수 있습니다. 하지만 하한선 이전에는 아무것도 예약할 수 없습니다. 트래커가 거부하기 때문입니다.
4주 출시 타임라인
하한선이 전제로 하는 계획은 이렇습니다. 날짜는 예시이며, 하한선은 2026년 11월 9일 월요일입니다.
−4주: 하한선을 정하고 온보딩하기. 무엇이든 공개될 수 있는 가장 이른 날짜를 정해 온보딩 중에 입력하세요. 제품 정보와 표현 브리핑을 마무리해서, 에이전트가 폼을 건드리기 전에 승인된 문구를 갖게 하세요. 창업자 소개가 잘못된 채로 공개된 등록은 늦게 공개된 등록보다 나쁩니다.
−4주–−2주: 모더레이션 디렉터리에 제출하기. 캘린더가 없는 플랫폼입니다. 검토 대기열, “Pending approval” 페이지, “Under Review” 예상 기간이 있는 곳입니다. 가장 느리고 내가 조종할 수 없으므로 먼저 진행합니다. 모든 결과를 기록하세요. 검토 대기와 대기열 상태를 예상하고, 일부는 출시 주가 지나도 그 상태로 남을 것도 예상하세요. 괜찮습니다. 하한선은 애초에 그들을 위한 것이 아니었습니다.
−2주–−1주: 날짜를 고르는 플랫폼 예약하기. 슬롯이 있는 런칭 보드, Product Hunt, 날짜와 시간대를 확정해 주는 모든 곳입니다. 에이전트에게 하한선과 선호하는 요일을 알려 주세요. 에이전트는 플랫폼이 확정한 날짜와 함께 scheduled를 기록하고, 트래커는 하한선보다 이른 날짜를 거부합니다. 슬롯은 확정되었지만 승인이 아직 대기 중이라면 메모에 그렇게 적습니다.
출시 주: 확인한 뒤 게시하기. 당일 에이전트는 live를 기록하기 전에 예약된 각 등록 페이지를 열어 봅니다. 캘린더의 날짜는 공개 페이지의 증거가 아닙니다. Hacker News 같은 커뮤니티는 폼이 아니라 커뮤니티 규칙에 따라 직접 쓰는 게시물이며, 이 주에 속합니다. 그 게시물이 가리킬 등록 페이지가 이미 존재하는 때이기 때문입니다.
+1주–+4주: 대기열 후속 확인. 밝혀진 검토 기간이 지난 대기 중인 제출은 다시 확인하되, 새치기하려고 다시 제출하지는 않습니다. 늦게 도착한 등록도 하한선 이후에 도착하므로 여전히 의미가 있습니다. 하한선이 약속한 것은 그것뿐입니다.
트래커가 하한선으로 하는 일
2026년 9월 15일 릴리스부터 제품 파일 product.json에는 earliest_launch_date라는 필드가 있습니다. 비워 두면 하한선이 없습니다. 날짜를 넣으면 트래커 스크립트 record.py는 --launch-date 없이 scheduled를 기록하는 것을 거부하고, 하한선보다 이른 날짜도 거부합니다. 온보딩은 무엇이든 제출하기 전에 이 값을 묻고, 로컬 대시보드는 제품 옆에 하한선을 보여 줍니다. 릴리스 노트는 변경 내역에 있습니다.
다음은 2026년 9월 30일에 예시 제품에서 하한선을 2026-11-09로 두고 실제로 실행한 결과입니다.
$ python3 scripts/record.py --project projects/my-product tinylaunch scheduled --note "Slot offered" --next-action "Pick a date"
Tracker rejected input: scheduled requires --launch-date as YYYY-MM-DD
$ python3 scripts/record.py --project projects/my-product tinylaunch scheduled --launch-date 2026-10-26 --note "First free slot" --next-action "Pick a later week"
Tracker rejected input: launch_date is earlier than the owner-authorized earliest_launch_date
$ python3 scripts/record.py --project projects/my-product tinylaunch scheduled --launch-date 2026-11-09 --note "Waiting for approval" --next-action "Verify on launch day"
Recorded tinylaunch: scheduled
$ python3 scripts/record.py --project projects/my-product pitchwall submitted_pending_review --note "Under Review" --next-action "Recheck after 30 days"
Recorded pitchwall: submitted_pending_review날짜 없는 예약은 거부되고, 하한선 이전 슬롯도 거부되며, 하한선 당일 슬롯은 받아들여지고, 검토 대기 제출은 하한선보다 몇 주 앞서 기록됩니다. 정확히 의도한 대로입니다.
하한선이 하지 않는 일
하한선은 디렉터리가 더 빨리 게시하게 만들지 않습니다. 디렉터리가 언제 게시할지는 에이전트가 정하지 않습니다. 검토 대기나 대기열 상태의 제출에도 적용되지 않습니다. 그것들은 플랫폼의 시계로 움직이기 때문입니다. 무료 경로에서 즉시 게시하는 것으로 알려진 플랫폼이라면 몇 주 전이 아니라 출시 기간 안에 제출하세요. 그리고 하한선은 선택 사항입니다. 이미 출시한 제품이라면 비워 두고, 지출 없는 출시 계획 가이드처럼 꾸준한 리듬을 쓰세요.
하한선은 어떤 플랫폼이 제출할 만한지도 정하지 않습니다. 그것은 제품마다 따로 답해야 할 질문이며, 날짜가 아니라 선정 방법으로 답합니다.
실제로 하한선 정하기
Claude Code 설정이나 다른 에이전트로 시작하면 온보딩 중에 에이전트가 묻습니다. 날짜로 답하거나 “하한선 없음”이라고 말하세요. 나중에 바꾸려면 제품의 product.json에서 earliest_launch_date를 수정하고 에이전트에게 알리거나, 대시보드의 제품 화면에서 바꾸세요. 단계별 가이드에서 두 방법을 모두 보여 줍니다. 기존 scheduled 행은 다시 쓰이지 않습니다. 확인은 새 기록에만 적용됩니다. 이미 확정된 슬롯보다 뒤로 하한선을 옮긴다면, 에이전트의 다음 세션 전에 트래커를 읽고 플랫폼에서 일정을 다시 잡을지 결정하세요.
두 가지 습관이 이것을 작동하게 합니다. 플랫폼이 날짜를 확정할 때마다 시간대도 확인하세요. Product Hunt 현장 가이드가 존재하는 이유 중 하나가 바로 그것입니다. 그리고 감사 화면은 있는 그대로 받아들이세요. 게시됨도 예약됨도 아니고, 그저 폼의 끝입니다. 차이는 예약 등록 항목에서 설명합니다.
LaunchRepo는 이것을 1회성 라이선스와 함께 제공합니다. 그 질문을 하는 온보딩, 답을 강제하는 트래커, 그리고 어떤 플랫폼이 날짜를 받고 어떤 플랫폼이 그냥 제 속도대로 가는지 문서화한, 2026년 9월 24일 기준 활성 플레이북 299개입니다.
자주 묻는 질문
출시 얼마 전에 디렉터리에 제출해야 하나요?
무료 검토는 몇 주씩 걸리는 경우가 많으므로, 모더레이션 디렉터리에는 출시 3–4주 전에 제출하세요. 런칭 보드처럼 날짜를 고르는 플랫폼은 출시 주가 정해진 뒤 1–2주 전에 예약하세요.
출시일 하한선이 제출을 늦추나요?
아니요. 하한선은 내가 정한 날보다 이른 날짜를 예약하는 것만 막습니다. 제출은 게시가 아니므로 모더레이션 디렉터리에는 원하는 만큼 일찍 제출할 수 있습니다.
디렉터리가 출시일 전에 내 등록을 게시하면 어떻게 하나요?
모더레이션 디렉터리는 검토가 끝나면 게시하며, 하한선은 그것을 막을 수 없습니다. 무료 경로에서 즉시 게시하는 것으로 알려진 플랫폼이라면 몇 주 전이 아니라 출시 기간 안에 제출하세요.
출시일이 바뀌면 어떻게 되나요?
earliest_launch_date를 바꾸고 에이전트에게 알리세요. 새로운 예약 기록은 새 하한선을 따라야 합니다. 이미 확정된 슬롯은 그대로 남으므로 트래커를 확인하고 필요한 플랫폼에서 일정을 다시 잡으세요.
이미 출시한 제품에도 하한선이 필요한가요?
아니요. 기본값은 빈 하한선입니다. 이미 시장에 나온 제품에는 조율된 출시 주보다 매주 몇 건씩 꾸준히 제출하는 리듬이 더 잘 맞습니다.
출처: LaunchRepo 툴킷의 ONBOARDING.md, RUNBOOK.md, DASHBOARD.md, CHANGELOG.md(2026년 9월 15일 릴리스), 2026년 9월 30일의 record.py 실행, 그리고 2026년 9월 13일에 관찰한 이 사이트의 공개 현장 가이드.