Codex로 만든 Hnrepos, 첫 웹앱은 실시간 서비스여야 할까요?

핵심 요약 (TL;DR)

처음부터 모든 자료를 실시간으로 모을 필요는 없습니다. 11월 3일 한국 시간에 소개된 Hnrepos는 Hacker News에서 언급된 코드 저장소를 모아 보여 주는 사이트입니다. 제작자는 Codex를 활용했고, 정적 캐시를 최대한 이용하며 수집 범위를 제한해 공개했다고 설명했습니다.[1] 바이브코딩도 공개할 범위부터 정해 보세요.

어떤 목록을 만들었나요?

공개 사이트에서는 저장소 이름과 설명, 토론 건수, 주제 표시를 확인했습니다. 검색 입력과 주제 탐색도 제공하며, 자료의 근거는 Hacker News에서, 저장소 정보는 각 호스트에서 온다고 안내합니다.[2] 이번 확인은 공개 화면 열람이며 전체 데이터나 검색 성능의 검증은 아닙니다.

제작자는 묵혀 둔 도메인을 실제로 공개하기 위한 도전이었다고 소개합니다. 일정 수준 이상 언급된 저장소만 다루고, 더 긴 꼬리의 자료는 나중에 다시 볼 수 있다고 설명했습니다.[1] 수집 범위를 줄인 선택은 전체를 대표한다는 보장과는 구분해야 합니다.

왜 첫 버전에 실시간 기능을 줄였을까요?

제작자는 Cloudflare의 정적 캐시를 활용하고 보안 문제를 과하게 늘리고 싶지 않았다고 밝혔습니다.[1] 이를 ‘정적 사이트라면 안전하다’는 일반 법칙으로 읽을 필요는 없습니다. 이번 사례에서 참고할 것은 원하는 목록을 보여 주는 데 꼭 필요한 구성부터 선택한 태도입니다.

여러분이 자주 쓰는 도구 목록을 만든다면, 우선 직접 확인한 이름과 설명, 링크를 작은 자료 파일로 준비해 보세요. 방문자가 새 항목을 등록하는 기능이나 외부 계정 연결은 첫 버전에서 제외할 수 있습니다. 자료가 바뀌면 어떻게 고칠지는 별도 절차로 남겨 두시면 됩니다.

첫 프롬프트에는 무엇을 적으면 좋을까요?

“제가 준 도구 목록을 보여 주는 한 페이지를 만들어 주세요. 이름으로 찾고 분류별로 볼 수 있게 하되, 계정과 방문자 등록 기능은 제외합니다. 항목마다 원문 링크를 유지하고 검색 결과가 없을 때도 안내해 주세요.”라고 요청해 보세요. 이 문장은 원작의 실제 프롬프트가 아닌 실습용 예시입니다.

화면이 완성되면 아는 항목을 검색하고, 없는 이름도 입력합니다. 분류를 바꿨다가 검색어를 지웠을 때 목록이 돌아오는지 확인하세요. 보기 좋은 카드가 있다는 사실과 원하는 항목을 찾을 수 있다는 사실은 다릅니다. 수정 요청에는 기대한 결과와 실제로 보인 결과를 함께 적으면 좋겠습니다.

목록의 숫자는 어떤 의미로 보여 줘야 할까요?

Hnrepos의 공개 화면은 저장소 옆에 토론 건수를 표시합니다.[2] 그 숫자를 다운로드 수나 품질 점수로 바꿔 읽으면 의미가 달라집니다. 여러분의 앱에서도 수치 옆에 무엇을 셌는지 짧게 적어 주세요. 자료 범위와 갱신 시점을 설명하는 문장은 첫 버전에도 필요합니다.

그다음 공개 주소에서 목록과 원문 링크를 다시 확인합니다. 다른 사람에게 도구 하나를 찾아 원문으로 이동하게 하고, 멈춘 위치를 기록해 보세요. 첫 검증의 목표는 모든 자료를 갖추는 것이 아니라 준비한 범위 안에서 찾기와 이동이 이어지는지 확인하는 데 있습니다.

FAQ: Codex가 만들었다면 자료도 모두 검증됐나요?

제작자가 Codex 활용을 공개한 사실은 개별 자료의 정확성을 보증하지 않습니다.[1] 수집과 분류, 화면 구현을 나누어 확인하고, 잘못된 설명을 발견했을 때 수정할 경로도 남겨 두세요.

FAQ: 정적 목록으로 공개하면 MVP로 부족하지 않나요?

어떤 가설을 확인하는지에 달려 있습니다. 사람들이 원하는 항목을 찾고 링크를 이용하는지 확인하려는 단계라면, 작은 목록으로 먼저 시험해 볼 수 있습니다. 이 글의 제안이며 Hnrepos의 시장 성과를 입증한 것은 아닙니다. 검색과 출처를 확인한 뒤 실제 요구가 생기는 기능부터 넓혀 보시길 권합니다.

출처
[1] https://news.ycombinator.com/item?id=50342272
[2] https://hnrepos.com/
관찰: 2026-11-04 KST