지난 2년간 엔터프라이즈 TYPO3 설치를 헤드리스 아키텍처로 마이그레이션하면서 항상 나오는 질문이 있습니다. TYPO3를 유지하고 EXT:headless로 헤드리스로 갈 것인가, 아니면 Supabase 같은 것과 Next.js로 전환할 것인가? 꽤 막혀있는 질문이지 않나요? 대부분의 아키텍처 결정과 마찬가지로 답은 "상황에 따라 다르다"는 것으로 귀결됩니다. 하지만 정확히 무엇에 달려있는지 자세히 살펴봅시다.

이것은 나에게 학문적인 것이 아닙니다. 저는 두 가지 접근 방식 모두로 프로덕션 사이트를 출시했고, 그 까다로운 엣지 케이스들을 헤쳐 나갔으며, 팀들이 각 스택에서 성공하거나 고군분투하는—때로는 극적으로—것을 봤습니다. 제가 얻은 것들을 이야기해봅시다.

두 가지 접근 방식 이해하기

먼저 무엇을 비교하고 있는지 명확히 하겠습니다. 이 둘은 완전히 다른 영역입니다.

TYPO3 + EXT:headless (분리형)

이 방식에서는 TYPO3가 CMS로 남아있고 모든 콘텐츠 관리 백엔드 작업을 처리합니다. 트릭은 구식의 Fluid/TypoScript 렌더링을 JSON API로 바꾸는 것입니다. 반짝반짝한 새 프론트엔드? React, Vue, 원하는 것들을 사용해 그 API를 활용할 수 있습니다. TYPO3는 모델, 권한, 워크플로우 같은 좋은 것들 관리를 계속 유지합니다.

EXT:headless 확장은? 그것은 TYPO3의 렌더링 프로세스에 접근해 HTML 대신 JSON을 출력하는 VIP 백스테이지 패스입니다. 일종의 애드온 API가 아닙니다—TYPO3의 콘텐츠 내부와 직접 작동하는 진짜 거래입니다.

Next.js + Supabase (완전히 헤드리스)

다른 한편, Next.js가 프론트엔드와 서버 사이드 로직을 관리합니다. Supabase (PostgreSQL, 인증, 파일 스토리지, 그리고 실시간 기능의 야생 조합)가 백엔드를 정렬합니다. 여기에는 TYPO3가 전혀 없습니다, 사람들이여. 당신은 순수한 유연성과 현대적인 JS 네이티브 설정을 위해 구식 CMS를 버리고 있습니다.

EXT:headless 실제 작동 방식

ext:headless를 TYPO3에 붙이면 새로운 페이지 유형을 등록해 모든 것을 변경합니다. 더 이상 Fluid 템플릿을 통해 콘텐츠를 전달하지 않습니다. 대신 JSON을 제공합니다.

다음은 얻을 것의 샘플입니다:

{
  "id": 42,
  "type": "textmedia",
  "content": {
    "header": "Welcome to our site",
    "headerLayout": 2,
    "bodytext": "<p>Some rich text content here</p>",
    "media": [
      {
        "publicUrl": "/fileadmin/images/hero.webp",
        "properties": {
          "width": 1920,
          "height": 1080,
          "alt": "Hero image"
        }
      }
    ]
  },
  "appearance": {
    "layout": "default",
    "frameClass": "default",
    "spaceAfter": "medium"
  }
}

그런 다음 프론트엔드가 이 점들을 React/Vue 컴포넌트에 연결합니다. 컴포넌트 기반 CMS로 뭔가 만들어봤다면 이것이 좋아하는 낡은 스웨터처럼 느껴질 것입니다.

EXT:headless 설정

일반적인 설정은 이렇게 시작합니다:

composer require friendsoftypo3/headless

그리고 TypoScript에서:

plugin.tx_headless {
  settings {
    debug = 0
  }
}

page = PAGE
page {
  typeNum = 0
  10 = USER
  10.userFunc = FriendsOfTYPO3\Headless\ContentObject\JsonContentObject->render
}

여기 중요한 부분은: TYPO3의 각 커스텀 콘텐츠 요소마다 JSON 직렬화기가 필요합니다. 예를 들어 소수의 커스텀 요소가 있는 사이트라면? 당신은 2-3일의 작업을 보고 있습니다. 수십 개의 요소가 있는 대규모 엔터프라이즈 설정? 자신을 준비하세요—이것은 몇 주가 걸릴 수 있습니다.

TYPO3 헤드리스가 잘하는 것

  • 에디터 경험이 그대로 유지됩니다. TYPO3의 친숙한 백엔드는 콘텐츠 편집자를 위한 재교육이 필요 없다는 의미입니다.
  • 기존 콘텐츠 보존. 당신의 설정이 사라지지 않습니다. 모든 콘텐츠, 번역, 미디어? 그들은 남아있습니다.
  • 다국어 지원이 훌륭합니다. TYPO3는 제가 본 최고의 언어 처리를 가지고 있습니다.
  • 엔터프라이즈급 기능. 워크스페이스에서 예약된 발행까지 모든 것이 준비되어 있습니다.

EXT:headless의 함정

  • TYPO3가 어디든지 갈 것이 없습니다. TYPO3를 이해하는 PHP-능숙한 사람들이 필요하며, 그들은 정확히 어디에나 있지 않습니다.
  • 복잡한 호스팅. 당신은 PHP (TYPO3)와 Node.js (당신의 프론트엔드)를 저글링하고 있습니다. 더블 더 재미, 더블 더 복잡성.
  • 제한된 API 인터페이스. 그것은 JSON이지 GraphQL이 아닙니다. 커스터마이제이션은 TYPO3 확장 개발로 돌아가는 것을 의미합니다.
  • 미리보기 골칫거리. TYPO3와 Next.js로 실시간 미리보기를 통합하시나요? 약한 마음을 위한 것이 아닙니다.

TYPO3 Headless Mode vs Next.js + Supabase: A Real Comparison

Next.js + Supabase: 완전히 헤드리스 스택

레이아웃

이 설정에서 Next.js는 애플리케이션 레이어를 처리하고 Supabase는 모든 데이터베이스 및 백엔드 작업에 뛰어듭니다.

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Next.js   │────▶│   Supabase   │────▶│ PostgreSQL  │
│  (App Router)│     │   (BaaS)     │     │  (Database)  │
└─────────────┘     └──────────────┘     └─────────────┘

TYPO3 없이 콘텐츠 관리

여기가 까다로워집니다. 에디터들이 콘텐츠를 어떻게 관리합니까?

  1. 커스텀 관리자 패널. 생각하는 것보다 더 많은 작업입니다.
  2. Supabase Studio. 개발자에게는 좋지만 편집자는 싫어할 수 있습니다.
  3. CMS 추가. 이제 3개 서비스를 관리합니다.
  4. 자신의 데이터베이스가 있는 Payload를 사용하십시오. 제 생각에는 꽤 우아합니다.

당신이 볼 수 있도록, 여기 Supabase를 사용한 기본 콘텐츠 가져오기 구현입니다:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

export async function getPage(slug: string) {
  const { data, error } = await supabase
    .from('pages')
    .select(`
      id,
      title,
      slug,
      meta_description,
      content_blocks (
        id,
        type,
        content,
        sort_order
      )
    `)
    .eq('slug', slug)
    .eq('status', 'published')
    .single()

  if (error) throw error
  return data
}

Next.js + Supabase가 빛나는 것

  • 하늘 높이의 성능. 정적 생성, ISR, 엣지 렌더링—속도를 위한 당신의 놀이터.
  • 개발자 풍부한. JavaScript/TypeScript 사람들은 어디에나 있습니다.
  • Supabase의 Row Level Security. 당신이 엄격한 제어를 원할 때 정말 멋집니다.
  • 실시간 기능. 라이브 업데이트를 쉽게 통합합니다.
  • 쉬운 배포. Vercel을 Next.js용으로 사용하고 Supabase Cloud를 백엔드용으로 사용하거나 원하면 자체 호스팅합니다.

여기서의 어려움

  • DIY CMS. 다른 헤드리스 CMS를 섞지 않으면 기본적으로 당신 것을 굴리고 있습니다.
  • 편집 검은 구멍. 기본 워크플로우가 없습니다. 초안 상태, 예약된 발행? 당신이 그것을 만들어야 합니다.
  • 언어 관리. 다국어 콘텐츠 지원? 당신은 그것을 사내에서 구축하는 것을 땀낼 것입니다.
  • 미디어 관리의 고통. Supabase 스토리지는 디지털 자산에 맞춰 설계되지 않았습니다. 그것을 명심하십시오.

헤드투헤드 비교

그들이 어떻게 쌓이는지 봅시다:

기능 TYPO3 + EXT:headless Next.js + Supabase
편집 UX 우수 커스텀 또는 추가 CMS
다국어 네이티브 DIY 구현
워크플로우 내장 커스텀 빌드 필요
성능 좋음 우수
API 제한됨 완전 제어
실시간 없음 지원됨
인증 레거시 현대적이고 유연
복잡성 높음 중간
인재 풀 부족 풍부
콘텐츠 마이그레이션 불필요 전체 마이그레이션
기능 내장 빌드 또는 구매
설정 시간 2-4주 4-8주
비용 (호스팅) €150-500 €45-200

성능 벤치마크

내가 테스트한 사이트의 숫자를 봅시다—기업 사이트, 200개 페이지, 다국어 지원:

지표 TYPO3 Headless + Next.js Next.js + Supabase (SSG)
TTFB (캐시되지 않음) 280ms 45ms
TTFB (CDN 캐시됨) 35ms 32ms
LCP 1.8s 1.2s
CLS 0.02 0.01
Lighthouse 점수 92 98
빌드 시간 (전체) 4m 20s 1m 45s
API 응답 (p95) 180ms 22ms

결론? Supabase를 사용한 캐시되지 않은 TTFB가 더 나은 반면, CDN 캐싱은 거의 필드를 평평하게 합니다. 둘 다 올바르게 설정되면 최종 사용자에게 충분히 빠릅니다.

TYPO3 Headless Mode vs Next.js + Supabase: A Real Comparison - architecture

개발자 경험 및 팀 고려사항

TYPO3로 뛰어들기

헤드리스 프로젝트를 위해 여전히 TYPO3 전문가가 필요합니다. PHP 직렬화기, 테스트 업그레이드, 호환성 문제 처리를 생각해 보세요. 2025년에 이 전문가들은 €80-120/시간을 청구할 수 있습니다. 그리고 일부 개발자는 헤드리스 설정에 대해 만족하지 않습니다—Fluid 템플릿의 기쁨을 빼앗습니다.

Next.js + Supabase Club

JavaScript 개발자는 풍부하지만 콘텐츠 관리 시스템 설계가 모든 사람에게 쉬운 것은 아니라는 것을 기억하세요. Supabase의 개발자 경험은 꽤 매끄럽습니다: 자동으로 생성된 TypeScript 유형, 실시간 구독, 견고한 인증 도우미. 하지만 모든 데이터 모델링 및 아키텍처 결정? 그것들은 모두 당신의 것입니다.

이 경로를 고려 중입니까? 우리 팀은 Next.js 개발에서 전문성을 연마하여 당신이 안 좋은 놀라움을 피하도록 도울 수 있습니다.

마이그레이션 전략

전통적인 TYPO3에서 TYPO3 헤드리스로

낮은 위험, 콘텐츠는 그대로 유지됩니다. 주로 프론트엔드 다시 쓰기입니다.

  1. EXT:headless 롤아웃
  2. 콘텐츠 요소를 JSON에 매핑
  3. Next.js/Nuxt 프론트엔드 제작
  4. 미리보기 통합 정렬
  5. 라이브로 가기!

기간: 괜찮은 규모의 기업 사이트의 경우 8-16주.

TYPO3에서 Next.js + Supabase로

당신의 자리를 잡으세요, 이건 완전한 재구축입니다.

  1. 현재 콘텐츠 설정 감사
  2. PostgreSQL 스키마 스케치
  3. 마이그레이션 스크립트 작성
  4. 미디어 및 파일 참조 이동
  5. 편집 도구 빌드 또는 다른 CMS 통합
  6. 프론트엔드를 위해 다시 빌드
  7. URL 리디렉션 처리
  8. 다국어 콘텐츠 전파

기간: 16-32주. 복잡한 헤드리스 개발? 생활을 더 쉽게 하려면 전문가를 데려오세요.

비용 분석

중간 규모 기업 설정을 위해 계산해 봅시다: 200페이지, 3개 언어, 5명 편집자, 월 50K 방문자.

TYPO3 헤드리스 — 1년 비용

항목 비용
TYPO3 호스팅 (관리됨) €3,600/년
Next.js 호스팅 (Vercel Pro) €240/년
프론트엔드 개발 €25,000-45,000
EXT:headless 통합 €8,000-15,000
총 1년 €36,840-63,840
지속적인 연간 €5,000-8,000

Next.js + Supabase — 1년 비용

항목 비용
Supabase Pro €300/년
Vercel Pro €240/년
CMS 추가 (필요하면) €0-3,600/년
콘텐츠 마이그레이션 €10,000-20,000
프론트엔드 + 백엔드 개발 €40,000-70,000
편집 도구 €10,000-25,000
총 1년 €60,540-119,140
지속적인 연간 €2,000-6,000

완전히 헤드리스로 가면 처음에 큰 비용이 들지만, TYPO3 호스팅을 버리기 때문에 월간 비용을 줄입니다. 단지 상단에 추가 CMS 빌드를 과소평가하지 마세요.

어느 것을 언제 선택할 것인가

TYPO3 + EXT:headless

  • 레거시 콘텐츠 및 설정된 워크플로우와 함께 유지합니다.
  • 친숙한 편집 설정과 풍부한 기능을 유지합니다.
  • 정교한 네이티브 다국어 지원으로부터 혜택을 받습니다.
  • TYPO3 개발자를 유지합니다.

Next.js + Supabase

  • 처음부터 시작할 때.
  • 애플리케이션이 많은 대화형 기능이 필요합니다.
  • 당신의 개발 팀이 이미 JavaScript에 중점을 두고 있습니다.
  • 최고 성능 유지가 핵심 초점입니다.
  • 헤드리스 CMS를 추가하는 것이 편합니다.

세 번째 각도를 고려해 보세요

섞는 것이 당신의 마음에 교차했을 수도 있습니다? Next.js, 헤드리스 CMS, 그리고 앱 데이터용 Supabase는 최고를 결합할 수 있습니다. TYPO3 짐없이 잘 반올림된 편집 도구를 제공합니다. Astro 개발과 같은 옵션도 고려 중인 가벼운 콘텐츠 기반의 사이트의 경우 살펴볼 가치가 있습니다.

당신의 구체적인 필요에 대해 이야기하고 싶습니까? 우리는 당신의 독특한 시나리오에 무엇이 합리적인지 평가하는 것을 돕기 위해 여기 있습니다—연락해 주세요, 그리고 우리는 "당신이 아는 것을 유지하세요"라고 해도 정직한 평가를 약속합니다.

FAQ

2025년에 TYPO3 EXT:headless가 프로덕션 준비가 되어 있습니까?

네, 절대적으로. EXT:headless는 3.x 버전 이래로 안정적이며 활발하게 지원되고 있습니다. 4.x 버전은 TYPO3 v12 및 v13을 견고한 콘텐츠 직렬화, 메뉴 생성 및 양식 처리와 함께 다룹니다. 일단의 거대한 엔터프라이즈 사이트들이 정부 및 은행과 같은 부문을 포함하여 독일과 오스트리아의 프로덕션 설정에서 그것을 실행합니다.

TYPO3 헤드리스 프론트엔드에 Next.js를 사용할 수 있습니까?

확실합니다, 그것은 고전적인 조합입니다. TYPO3의 JSON API로부터 정보를 수집하기 위해 Next.js App Router를 서버 컴포넌트와 함께 활용할 것입니다. 미리보기 통합은 가장 까다로운 부분입니다: 드래프트 모드를 설정하고 TYPO3가 미리보기 URL을 통해 이를 호출하도록 지시합니다. 운 좋게도, 커뮤니티의 도움이 되는 문서가 당신을 Next.js 페어링을 통해 안내합니다.

Supabase와 TYPO3의 데이터베이스 설정을 어떻게 비교합니까?

오, 이것들은 사과와 오렌지입니다. TYPO3는 TCA에 의해 관리되는 더 엄격한 스키마가 있는 Doctrine DBAL에서 실행됩니다. Supabase는 Row Level Security를 가진 그 멋진 PostgreSQL 자유를 제공합니다. Supabase는 유연하고 강력한 쿼리 능력을 제공하지만 TYPO3는 편집자가 실수로 도입할 수 있는 실수를 방지하도록 주의 깊게 구조화되어 있습니다. 그것은 모두 제어 대 보안에 관한 것입니다.

헤드리스 TYPO3를 사용한 SEO 우려? 메타 태그 및 구조화된 데이터 처리?

EXT:headless는 메타 태그 및 Open Graph 데이터와 같은 페이지 속성을 직렬화합니다. 당신의 프론트엔드는 그것들을 HTML 태그로 렌더링해야 합니다. Next.js의 Metadata API를 레이아웃에서 사용하세요. 당신의 TYPO3 설정이 견고하면 SEO 데이터도 따라갑니다. EXT:yoast_seo와 같은 확장을 통합하면 헤드리스 구성과 잘 작동할 것입니다.

Supabase가 엔터프라이즈 수준의 콘텐츠 전달까지 가능합니까?

확실합니다. AWS에서 실행되는 Supabase Cloud는 Pro 플랜에서 99.9% 가동시간, Team 플랜에서 99.95%로 상향합니다 (2025년 요금 확인). CDN 캐싱 (Vercel의 Edge Network, Cloudflare)의 경우, Supabase는 주로 쓰기 및 실시간 기능 신뢰성을 보장합니다. 중요한 엔터프라이즈 사용의 경우 최대 제어를 위해 Supabase를 자체 호스팅합니다.

TYPO3 없이 이미지 처리를 어떻게 해결합니까?

TYPO3는 네이티브로 이미지를 처리합니다—자르기, 크기 조정, 형식 뒤집기. 그것 없이 이미지 워크플로우를 설정합니다. 2025년의 최고 경쟁사는: Next.js Image Optimization (내장, Vercel-지원), Cloudinary (자유롭게 시작, 진지한 사용은 유료 플랜 요구), 또는 imgix (€100+/월로 시작). Supabase Storage는 원본을 처리하지만 변형을 처리하지 않습니다.

TYPO3 Headless에서 완전히 헤드리스로 점진적으로 마이그레이션할 수 있습니까?

절대적으로, 부드러운 계획처럼 생각하세요. 헤드리스 TYPO3로 시작해 프론트엔드를 격리합니다. 천천히 TYPO3에서 Supabase 또는 선택한 CMS로 콘텐츠를 전환합니다—더 간단한 유형으로 시작하세요. 단계 동안 Next.js 프론트엔드는 두 원본의 데이터로 작동합니다.

TYPO3 팀이 Next.js + Supabase로 전환할 때의 학습 곡선은 어떻습니까?

현실적인 램프업은 약 3-6개월입니다. 그렇긴 하지만, 도전은 JavaScript 또는 TypeScript가 아닙니다—패러다임 전환입니다. TYPO3 개발자들은 프레임워크가 콘텐츠 구조, 캐싱, 경로를 조종하는 것에 익숙합니다. Next.js + Supabase 모델에서 그 호출들은 당신의 것입니다. 자유로우면서도 처음에는 압도적입니다. 숙련된 Next.js 사람들과 쌍 프로그래밍하면 이 도약이 훨씬 더 매끄럽습니다.