자유
[개발후기] 유튜버 특가만 모아서 사이트 만들어봤습니다 (feat. 비개발자 + Claude Code)
조회 1,941 · 공감 0 · 댓글 5
유튜브 보다 보면 유튜버들이 "설명란에 할인코드 있어요" 하는데,
정작 그 영상을 나중에 다시 찾아서 설명란 뒤지는 게 은근히 귀찮더라고요.
할인 기간 지나서 못 쓴 적도 많고요.
그래서 유튜버 협찬 영상 속 할인코드/특가 정보를 한곳에 모아서 보여주는
사이트를 만들어봤습니다. 딜로(dealo.kr)라고 합니다.
저는 개발자가 아니고, VS Code에 Claude Code를 붙여서
"이런 기능 만들어줘" → 확인 → 승인 방식으로 지금까지 몇 달째 개발해오고 있어요.
[기술 스택]
Next.js 14 + Supabase + Vercel. 카카오 로그인, PWA Web Push 알림 지원합니다.
[재미있었던 디테일들]
- 유튜버가 협찬 영상을 올리면 YouTube Data API로 자동 감지해서 후보로 모으는데,
완전 자동으로 등록은 안 하고 사람이 마지막에 확인하게 만들어놨어요
(엉뚱한 영상이 잘못 걸리는 걸 방지하려고요).
- 최근엔 Supabase 무료 플랜의 기본 행 제한(Max Rows 1000)에 걸려서
관리자 통계가 조용히 틀리게 나오는 버그를 잡느라 며칠 고생했네요.
로그가 쌓일수록 언젠가 터지는 종류의 버그라 재밌었습니다.
온라인 가격비교로 최저가 검증을 하고 있어요.
*용량 차이로 가격이 비싸 보이지만 실제로 더 저렴
상품을 검색하는 사용자들에게 AI 브리핑에 활용 되고 있어요.
그리고 제품 판매처보다 더 상단에 노출 되어 있네요. 럭키비키!!
아직 다듬을 게 많지만, 비개발자가 AI 에이전트로 여기까지 만들 수 있다는 게
저 스스로도 신기해서 공유해봅니다. 써보시고 의견 주시면 감사하겠습니다.
댓글 5
설정 이름은 Supabase 쪽 Max rows 지만 실제로 도는 건 그 아래 PostgREST 입니다. Supabase 문서에도 Supabase provides a RESTful API using PostgREST, a thin API layer on top of Postgres 라고 되어 있고, PostgREST 문서의 해당 설정 db-max-rows 설명은 A hard limit to the number of rows PostgREST will fetch from a view, table, or function 입니다. 테이블과 뷰만이 아니라 function 이 같이 들어 있어서, 통계를 SQL 함수로 빼서 rpc 로 부르는 식으로 우회해도 같은 벽에 다시 부딪힙니다. 저 자리는 보통 우회로로 먼저 떠올리는 곳이라 미리 아시는 게 나을 것 같습니다.
그래서 총계는 행을 받아 길이를 세는 대신 count 로 받는 쪽이 안전합니다. PostgREST 문서에 To get the exact count, use Prefer: count=exact 라고 되어 있고, 값은 본문이 아니라 응답 헤더에 Content-Range: 0-24/3573458 형태로 옵니다. supabase-js 라면 select 두 번째 인자에 count 를 exact, head 를 true 로 주면 본문 없이 헤더만 받아서 행 제한과 무관해집니다.
한 가지 더, count 를 estimated 로 쓰면 정확한 값과 추정값이 갈리는 임계값이 The threshold is defined by db-max-rows 라고 되어 있습니다. Max rows 를 올리는 방향으로 푸시면 그 경계도 같이 움직여서 통계 정확도 쪽이 따라 흔들립니다.
지금 관리자 통계는 목록을 받아 클라이언트에서 세는 구조인가요, 아니면 count 로 받는 구조인가요. 목록 화면 쪽도 range 로 페이징을 잡아두셨는지 궁금합니다.
말씀하신 두 가지 다 맞는 얘기더라고요.
1) Max Rows, 뷰/테이블뿐 아니라 함수(RPC)에도 똑같이 걸린다는 점 — 이거 진짜 놓치기 쉬운 부분인데, 확인해보니 저희는 통계용 RPC들 만들 때 애초에 SQL 안에서 group by로 미리 다 집계해서 소수 행만 리턴하게 짜놔서 다행히 이 문제는 피해있었어요. (근데 말씀 안 해주셨으면 다시 들여다볼 생각도 안 했을 것 같아요 😅)
2) 총 개수는 count(exact)로 뽑고 실제 행은 안 끌고 오는 방식 — 이것도 방문자 수 비교나 대기 건수 같은 단순 합계 뽑는 곳엔 이미 그렇게 쓰고 있었더라구요.
근데 말씀 덕분에 겸사겸사 관리자 화면들도 싹 다시 훑어봤는데, 딜 목록 관리 화면 하나가 페이징 없이 조건에 맞는 딜을 전부 긁어오는 구조인 걸 발견했어요. 지금은 딜 개수가 70개 정도라 당장 문제될 건 없는데, 나중에 딜 수 늘어나면 말씀하신 것과 똑같은 함정에 걸릴 수 있어서 미리 손봐두려고요.
이렇게 실제 경험 바탕으로 짚어주시는 분들 덕분에 서비스가 조금씩 더 단단해지는 것 같습니다. 다시 한번 감사드려요! (클로드의 도움을 받아 작성했습니다)