아이디어를 갖고 있는 것과 그것을 제품으로 검증하는 것 사이엔 생각보다 큰 거리가 있다. 특히 프론트엔드 개발자에게 그 거리는 종종 '어디서부터 시작하지?'라는 막막함으로 나타난다. 최근 dev.to에 올라온 두 가지 사례—Next.js + SQLite로 1,800개 페이지를 혼자 만든 프로그래매틱 SEO 프로젝트와, Tinder 스타일 스와이프 UX를 온디바이스 ML에 얹은 사진 정리 앱—는 그 거리를 좁히는 실용적인 패턴을 선명하게 보여준다.
데이터에서 페이지로: 프로그래매틱 SEO의 실전 구조
'닭 허벅지살 조리 시간'을 검색하면 25분이라는 페이지와 40분이라는 페이지가 공존한다. 어느 쪽도 왜 그 숫자인지 설명하지 않는다. 개발자 farcrak은 이 단순한 불만에서 출발해 Next.js App Router 기반으로 약 1,800개의 계산기 페이지를 생성했다. 핵심 설계 원칙은 단순하다. 숫자를 하드코딩하는 대신 USDA 공식 안전 내부 온도를 기준점으로 두고, 조리 시간을 두께나 무게의 함수로 정의했다. 두께가 두 배라고 시간도 두 배가 아니라는 열확산 물리학까지 반영한 파워 법칙(thickness^1.2)을 적용한 것이다.
기술 스택은 의도적으로 단순하다. SQLite + Prisma로 읽기 전용 데이터셋을 관리하고, Next.js의 generateMetadata와 동적 sitemap.ts로 엔티티 하나당 페이지 하나를 생성한다. 이 구조의 진짜 강점은 데이터와 뷰가 완전히 분리된다는 점이다. TSV/JSON으로 버전 관리되는 원본 데이터가 진실의 원천이고, SQLite는 그 캐시에 불과하다. 배포도 git pull + pm2 restart로 끝난다. 솔로 프로젝트에서 인프라 복잡도를 최소화하면서도 수천 개의 인덱서블 페이지를 만들어낼 수 있다는 것을 실증한 사례다.
하지만 이 글에서 더 인상적인 부분은 실수 고백이다. lastmod를 new Date()로 설정했다가 모든 URL이 배포마다 '변경됨'으로 찍혀 크롤러 신뢰를 잃었고, hreflang의 x-default가 잘못된 로케일을 가리켜 영어 쿼리 트래픽을 날렸다. 둘 다 한 줄 수정으로 해결됐지만, 이 '한 줄의 대가'가 실제 검색 트래픽이었다는 점이 중요하다. 프로그래매틱 SEO는 코드가 아니라 크롤러와의 신뢰 계약이다.
스와이프 한 번으로 결정하게 만드는 UX의 설계 의도
Swipe Cleaner는 다른 종류의 문제를 풀었다. 스마트폰에 3,000장의 사진이 쌓여 있지만 아무도 정리하지 않는 이유—그건 AI 분석이 없어서가 아니라 인터페이스가 결정을 너무 어렵게 만들기 때문이다. 체크박스 그리드를 스크롤하면서 삭제 여부를 판단하는 방식은 인지 부하를 극대화한다. Tinder 스타일의 스와이프는 그 반대다. 오른쪽은 유지, 왼쪽은 삭제. 선택지가 두 개뿐이고, 손동작이 판단을 즉각 실행한다. 이건 UI 트렌드가 아니라 의사결정 심리학의 적용이다.
기술적으로 더 주목할 부분은 온디바이스 처리 아키텍처다. 이미지 분석, 중복 탐지, 유사도 매칭이 모두 Apple의 Core ML과 Vision Framework로 로컬에서 실행된다. 단 한 픽셀도 서버로 나가지 않는다. 이 선택이 단순한 프라이버시 마케팅이 아닌 이유는, Apple이 Private Cloud Compute와 온디바이스 ML로 플랫폼 방향을 명확히 잡고 있기 때문이다. 클라우드로 올리면 더 강력한 모델을 쓸 수 있지만, 플랫폼 방향과 사용자 신뢰를 동시에 잃는다. 트레이드오프를 명시적으로 인식한 아키텍처 결정이다.
두 사례가 공유하는 검증 패턴
표면적으로 두 프로젝트는 달라 보인다. 하나는 SEO 중심의 콘텐츠 엔지니어링이고, 다른 하나는 모바일 앱의 UX 설계다. 그런데 둘 다 같은 질문에서 출발했다. '이 문제를 가장 정직하게 푸는 최소 단위는 무엇인가?' 조리 시간 계산기는 '신뢰할 수 있는 단일 엔티티 페이지'가 그 단위였고, 사진 정리 앱은 '스와이프 한 번의 결정'이 그 단위였다. 복잡한 대시보드나 다기능 인터페이스 대신, 검증 가능한 최소 인터랙션을 먼저 설계했다.
프론트엔드 개발자 관점에서 이 패턴이 중요한 이유는, 아이디어 검증의 병목이 대부분 기술이 아니라 범위 설정에 있기 때문이다. '1,800개 페이지 계획'으로 시작한 게 아니라 '요리 시간 계산기 하나'로 시작했고, 데이터 모델이 확장 가능한 구조였기 때문에 1,800개가 됐다. Swipe Cleaner도 마찬가지다. 온디바이스 ML 전체 파이프라인을 먼저 설계한 게 아니라, 스와이프로 삭제하는 단순한 UX 흐름이 먼저였을 것이다.
지금 만들고 있다면
AI 도구가 코드 생성 속도를 극적으로 높이면서, 오히려 '무엇을 빠르게 만들 것인가'의 판단이 더 중요해졌다. 프로그래매틱 SEO 구조처럼 데이터 모델 하나가 수천 개의 페이지로 확장될 수 있고, Tinder 스타일 스와이프처럼 마이크로인터랙션 하나가 제품의 핵심 가치 명제가 될 수 있다. 빠른 프로토타이핑의 진짜 기술은 도구를 잘 쓰는 것이 아니라, 검증할 최소 단위를 먼저 정의하는 것이다. 두 사례 모두 그 단위를 정확히 찾았기 때문에 복잡도를 억제하면서 실제로 동작하는 제품을 만들 수 있었다.