나는 287,000페이지 웹사이트를 만들었다. 여기 내가 Programmatic SEO에 대해 배운 점

발행: (2026년 3월 10일 AM 10:37 GMT+9)
13 분 소요
원문: Dev.to

Source: Dev.to

Most SEO advice boils down to the same thing

  • 키워드를 선택한다.
  • 글을 작성한다.
  • 3개월을 기다린다.
  • 반복한다.

If you want 10× the traffic, you write 10× the content. That math doesn’t work when you’re a one‑person team.

A different approach

About a year ago I started experimenting with a programmatic method:

  • Instead of writing articles one by one, I built a system that generates pages programmatically.
  • One template + one data pipeline = thousands of output pages.
  • Each page targets a specific long‑tail keyword.

The effort goes into building the machine, not feeding it.

프로젝트: 주식 비교 엔진

  • 입력 – 두 개의 티커 심볼.
  • 출력 – 나란히 비교: 재무, 배당금, 성장 지표 등.
  • 규모12개 언어에 걸친 모든 의미 있는 주식 쌍.

결과: 287,000 페이지를 한 사람이 구축. 콘텐츠 팀 없음.

Source:

실제로 일어난 일

기술 스택

구성 요소역할
Astro정적 사이트 생성 – 빠르고 SEO 친화적이며 수천 개의 라우트를 처리
Supabase PostgreSQL데이터 레이어
yfinance API금융 데이터 가져오기
Local Llama 3각 페이지에 대한 서술 섹션 생성
Cloudflare CDN정적 파일 제공

월간 총 비용: $50 이하.

핵심 인사이트

데이터프레젠테이션을 분리한다.

  • 데이터베이스는 8,000개 이상의 티커에 대한 구조화된 금융 데이터를 저장한다.
  • 템플릿은 해당 데이터를 비교 페이지로 렌더링하는 방식을 정의한다.
  • AI가 빈틈을 메우며, 각 쌍에 고유한 인간 친화적인 분석을 생성한다.

아키텍처 다이어그램

Data Layer (Supabase PostgreSQL)

ETL Pipeline (Python + yfinance)

Content Generation (Llama 3 – local)

Static Site Generator (Astro)

CDN (Cloudflare)

각 레이어가 독립적이어서 교체(예: Astro → Next.js, Llama 3 → Claude)가 손쉽다.

롱테일 커버리지

  • 모든 주식 쌍에 대한 페이지를 만들면 다른 사람이 타깃으로 하지 않는 검색을 포착한다.
  • 예시: “랜덤 소형주 vs 다른 랜덤 소형주”는 거의 경쟁이 없다.
  • 개별 페이지 트래픽은 작지만, 287k 페이지 전체의 합산 트래픽은 크게 증가한다.

다국어 지원

  • 템플릿과 데이터 파이프라인이 준비되면 12개 언어로 번역하는 것은 주로 템플릿 문자열을 번역하고 페이지를 다시 생성하는 일이다.
  • 숫자, 티커, 퍼센트는 그대로 유지한다.
  • 초기 번역은 AI로 수행하고, 가장 중요한 페이지는 수동으로 다듬었다.

대규모 스키마 마크업

  • 모든 페이지에 FinancialProduct, FAQ, BreadcrumbList 스키마가 포함된다.
  • 프로그래밍 방식이므로 스키마를 한 번 작성하면 287k 페이지 모두에 적용된다 – 수작업으로는 불가능한 규모다.

안정성

  • 빌드 파이프라인은 정적이며 구조화된 데이터에서 생성되므로 런타임에 문제가 발생할 여지가 거의 없다.
  • 사이트는 순수 HTML 파일을 제공 – 서버‑사이드 처리, 페이지 로드 시 DB 조회, 크래시 위험이 전혀 없다.

숨겨진 문제: Google이 새 도메인에서 287k 페이지를 색인하지 않음

  • 색인된 페이지: 약 2,500개 (≈ 0.9 % 색인 비율).
  • 근본 원인:
    1. 도메인 권한 부족 – 백링크 0개, 브랜드 인지도 없음.
    2. 콘텐츠 유사성 – 서술이 비슷한 패턴을 따라 Google의 “유용한 콘텐츠” 필터에 걸려 얇은 페이지로 판단됨.
    3. 크롤 예산 – Googlebot이 하루에 200‑500 페이지만 방문; 이 속도로는 모든 페이지를 크롤링하는 데 수년이 걸리며, Google은 가치가 낮다고 판단한 페이지를 크롤링하지 않음.

직관에 반하는 해결책: 더 많은 페이지가 아니라 적은 페이지

  1. 페이지를 과감히 축소

    • 287k에서 언어당 5 k–30 k 페이지로 감소.
    • 실제 검색 수요가 있는 비교 쌍만 남김 (Search Console 및 키워드 도구를 통해 검증).
  2. 남은 페이지를 풍부하게

    • 섹터 컨텍스트, 역사적 추세 분석, 배당 심층 분석, 각 주식 쌍에 특화된 맞춤 AI‑생성 인사이트 추가.
    • 각 페이지가 독립적인 유용한 리소스로서 기능하도록 목표 설정.
  3. 백링크 구축

    • 디렉터리 제출부터 시작 (지루하지만 필요).
    • 산업‑특화 디렉터리로 확대.
    • **Domain Rating 15+**를 6개월 이내에 달성하도록 타깃 아웃리치 진행.
  4. 크롤 예산 최적화

    • 방대한 사이트맵을 주제별 작은 사이트맵으로 분할.
    • 내부 링크 구조를 개선해 Googlebot이 사이트 구조를 통해 중요한 페이지를 발견하도록 함 (사이트맵에만 의존하지 않음).
    • 가치가 낮은 페이지에는 noindex 태그 사용.

현재 메트릭 (투명 스냅샷)

메트릭현재
총 페이지 수287,000
색인된 페이지~2,500
색인 비율0.9 %
도메인 평점0
백링크0
월간 수익$0
월간 비용~ $50

보기 좋지는 않지만 인프라가 작동합니다:

  • 데이터 파이프라인 ✅
  • 콘텐츠 생성 ✅
  • 사이트 로드가 빠르고 Core Web Vitals를 통과합니다 ✅
  • 모든 페이지에 올바른 스키마 마크업 ✅

유일하게 깨진 것은 Google의 신뢰이며, 이는 해결 가능한 문제입니다.

Programmatic SEO – Lessons Learned & Playbook

1. Indexing & Growth

  • Indexing is the bottleneck. Once pages start getting indexed, growth compounds quickly. → 색인은 병목 현상이다. 페이지가 색인되기 시작하면 성장 속도가 급격히 가속된다.
  • Each indexed page targets low‑competition keywords (virtually nobody else is ranking). → 각 색인된 페이지는 경쟁이 낮은 키워드를 목표로 한다(실질적으로 다른 사이트가 순위에 오르지 않는다).
  • With 12 languages the addressable market is massive. → 12개 언어로 접근 가능한 시장 규모가 방대하다.

2. Start Smaller

“If I could do it over, I’d launch with 5 000 pages instead of 287 000.” → “다시 할 수 있다면, 287 000 페이지 대신 5 000 페이지로 시작했을 텐데.”

  • Get a modest set of pages indexed first. → 먼저 적당한 수의 페이지를 색인시키자.
  • Prove the model works before scaling. → 규모를 확대하기 전에 모델이 작동함을 증명하라.
  • Launching with hundreds of thousands of pages on a brand‑new domain is essentially asking Google to ignore you. → 신규 도메인에 수십만 페이지를 한 번에 올리는 것은 구글에게 무시당하도록 요청하는 것과 같다.

3. Your Data Source = Your Moat

  • Anyone can copy a template; the real advantage is a comprehensive, hard‑to‑replicate data source. → 누구든 템플릿을 복제할 수 있지만, 진정한 강점은 포괄적이고 복제하기 어려운 데이터 소스이다.
  • Example: Financial data via yfinance – free, structured, covers thousands of entities. → 예시: yfinance를 통한 재무 데이터 – 무료이며 구조화돼 있고 수천 개의 기업을 포괄한다.
  • Ask yourself: What data can I obtain that others can’t easily replicate at scale? → 스스로에게 물어라: 다른 사람들이 대규모로 쉽게 복제할 수 없는 데이터는 무엇인가?

4. Template + AI Hybrid – The Sweet Spot

ApproachProsCons
Pure template‑based pagesFast, cheapThin content → flagged by Google
Pure AI‑generated pagesHighly uniqueExpensive, inconsistent quality
Hybrid (structured data + AI narrative)Scalable, unique, higher qualityRequires careful orchestration
  • Render structured data with templates. → 구조화 데이터를 템플릿으로 렌더링한다.
  • Use AI to generate narrative sections that add value and uniqueness. → AI를 사용해 가치와 독창성을 더하는 내러티브 섹션을 생성한다.
  • Great content won’t earn links automatically when the domain has zero authority. → 도메인 권한이 전혀 없을 때 훌륭한 콘텐츠가 자동으로 링크를 얻지는 않는다.
  • Make backlink acquisition a core part of the launch plan, not an afterthought. → 백링크 획득을 런칭 계획의 핵심으로 삼고, 사후 고려사항이 되지 않게 하라.

6. Patience Is a Must

  • Programmatic SEO is not a “launch and rank tomorrow” strategy. → 프로그램식 SEO는 ‘출시하고 내일 바로 순위 상승’ 전략이 아니다.
  • Think of it as building an infrastructure that compounds over time. → 시간에 따라 복리 효과가 나는 인프라를 구축하는 것으로 생각하라.
  • The first 6 months will feel slow—that’s normal. → 첫 6개월은 느리게 느껴질 것이다—이는 정상이다.

7. Documentation & Transparency

  • I’m documenting everything:
    • Full technical architecture → 전체 기술 아키텍처
    • Every prompt used for content generation → 콘텐츠 생성에 사용된 모든 프롬프트
    • Monetization roadmap → 수익화 로드맵
    • Mistakes and lessons learned → 실수와 배운 교훈

8. The Programmatic SEO Blueprint

A complete guide that includes:

  1. Niche selection → 1. 틈새 시장 선택
  2. Data architecture → 2. 데이터 아키텍처
  3. AI content generation workflow → 3. AI 콘텐츠 생성 워크플로우
  4. Astro/Next.js implementation details → 4. Astro/Next.js 구현 세부사항
  5. SEO infrastructure & indexing solutions → 5. SEO 인프라 및 색인 솔루션
  6. Monetization strategy → 6. 수익화 전략
  7. All code examples are MIT‑licensed모든 코드 예시는 MIT 라이선스

9. Final Thoughts & Call to Action

  • If you’re thinking about building a programmatic SEO site, go for it—just start smaller. → 프로그램식 SEO 사이트 구축을 고민 중이라면, 도전해라—단, 작게 시작하라.
  • Follow me for more updates on building programmatic SEO sites and on how the indexing situation evolves. → 팔로우해 더 많은 프로그램식 SEO 사이트 구축 업데이트와 색인 상황 변화 소식을 받아라.

Prepared by the author of the Programmatic SEO Blueprint.

0 조회
Back to Blog

관련 글

더 보기 »

Archify 소개: 아키텍처 아이디어에서 Spring Boot 코드까지

문제 모든 백엔드 개발자는 이 순간을 경험해 본 적이 있다: 새로운 프로젝트를 시작하면서 이미 아키텍처를 염두에 두고—아마도 간단한 REST 서비스와 몇 개의 엔드포인트만을 생각하고—시작한다. 하지만 프로젝트가 진행될수록 요구사항이 늘어나고, 복잡도가 급격히 증가한다. ### 원인 1. **초기 설계 부족** - 프로젝트 초기에 충분한 도메인 모델링과 데이터 흐름 설계를 하지 않으면, 나중에 구조를 바꾸는 데 큰 비용이 든다. 2. **기능 폭발** - 초기에는 “읽기 전용” API만 필요했지만, 곧 쓰기, 인증, 권한, 실시간 알림 등 다양한 기능이 추가된다. 3. **기술 스택 변화** - 새로운 라이브러리나 프레임워크가 등장하면서 기존 코드를 교체하거나 통합해야 하는 상황이 발생한다. ### 해결책 #### 1. 도메인 중심 설계(Domain‑Driven Design) 적용 - **Bounded Context**를 명확히 정의하고, 각 컨텍스트마다 독립적인 모델과 서비스 계층을 만든다. - **Entity**, **Value Object**, **Aggregate** 등을 활용해 비즈니스 로직을 캡슐화한다. #### 2. 레이어드 아키텍처 도입 - **Presentation Layer** (Controller / Handler) – HTTP 요청을 받아 DTO 로 변환하고, 서비스에 위임한다. - **Application Layer** – 트랜잭션 경계와 워크플로우를 정의한다. - **Domain Layer** – 핵심 비즈니스 로직과 도메인 규칙을 구현한다. - **Infrastructure Layer** – DB, 메시지 브로커, 외부 API 등 기술적 세부 사항을 담당한다. #### 3. 인터페이스와 의존성 역전(Dependency Inversion) - 상위 레이어가 하위 레이어에 의존하지 않도록 **Repository Interface**, **Service Interface** 등을 정의하고, 구현은 인프라 레이어에 둔다. - 스프링에서는 `@Autowired` 대신 **Constructor Injection**을 사용하고, 테스트 시에는 **Mock** 구현체를 주입한다. #### 4. 모듈화와 마이크로서비스 전략 - 시스템이 일정 규모를 넘어가면 **Domain‑Driven Microservices** 혹은 **Modular Monolith** 로 전환한다. - 각 모듈(또는 서비스)은 독립적인 데이터베이스 스키마와 배포 파이프라인을 갖는다. #### 5. 자동화된 테스트와 CI/CD 파이프라인 - **Unit Test**, **Integration Test**, **Contract Test**(예: Spring Cloud Contract) 를 레이어별로 작성한다. - GitHub Actions, GitLab CI 등으로 **빌드 → 테스트 → 배포** 흐름을 자동화한다. #### 6. 문서화와 코드 규칙 - OpenAPI/Swagger 로 API 스펙을 정의하고, **API‑First** 접근법을 채택한다. - 코드 스타일은 **Checkstyle**, **Spotless**, **EditorConfig** 로 일관성을 유지한다. ### 예시 코드 (Spring Boot) ```java // Domain Layer @Entity public class Order { @Id @GeneratedValue private Long id; private LocalDateTime orderDate; @Embedded private Money totalAmount; // 비즈니스 메서드 public void addItem(Product product, int quantity) { … } } // Application Layer @Service @RequiredArgsConstructor public class OrderService { private final OrderRepository orderRepo; private final PaymentGateway paymentGateway; @Transactional public OrderDto placeOrder(CreateOrderCommand cmd) { Order order = new Order(); // 도메인 로직 수행 orderRepo.save(order); paymentGateway.charge(order.getTotalAmount()); return OrderMapper.toDto(order); } } // Infrastructure Layer @Repository public interface OrderRepository extends JpaRepository<Order, Long> {} // Presentation Layer @RestController @RequestMapping('/api/orders') @RequiredArgsConstructor public class OrderController { private final OrderService orderService; @PostMapping public ResponseEntity<OrderDto> create(@RequestBody @Valid CreateOrderCommand cmd) { OrderDto result = orderService.placeOrder(cmd); return ResponseEntity.status(HttpStatus.CREATED).body(result); } } ``` ### 마무리 프로젝트 초기에 **아키텍처 설계**와 **도메인 모델링**에 충분한 시간을 투자하면, 이후 기능 추가나 기술 교체가 훨씬 수월해진다. 레이어드 아키텍처와 DDD 원칙을 적용하고, 의존성 역전 및 자동화된 테스트를 기반으로 하면, 복잡도가 증가해도 유지보수 가능한 코드를 유지할 수 있다. **핵심 포인트** - 초기 설계에 투자 → 장기 비용 절감 - 레이어와 인터페이스로 책임 분리 - 테스트와 CI/CD 로 변경 위험 최소화 - 필요 시 마이크로서비스 혹은 모듈형 모노리식으로 확장