당신의 CTO가 오전 9시 47분에 슬랙 메시지를 보냅니다: "TYPO3로 헤드리스 전환이 가능할까, 아니면 Next.js로 다시 만들어야 할까?" 2018년부터 같은 TYPO3 모놀리식 구조를 유지해왔습니다—TypoScript 템플릿, Fluid 부분, 40개 이상의 커스텀 모듈이 들어있는 extensions 폴더. 이제 누군가 디커플링 아키텍처에 관한 블로그 글을 읽었고, 당신의 로드맵은 그냥 사라졌습니다. 지난 2년간 6개의 엔터프라이즈 TYPO3 사이트를 헤드리스 스택으로 옮겼습니다—3개는 EXT:headless를 통해 TYPO3를 유지했고, 3개는 Next.js + Supabase로 마이그레이션했습니다. 의사 결정은 대부분의 에이전시가 간과하는 3가지 변수에 따라 결정되며, 첫 번째 변수는 성능과 무관합니다.

이것은 저에게 학문적인 것이 아닙니다. 두 가지 접근 방식 모두 프로덕션 사이트를 런칭했고, 그 귀찮은 엣지 케이스들을 헤쳐나갔으며, 팀들이 각 스택에서 성공하거나 때로는 극적으로 실패하는 것을 봤습니다. 제가 습득한 것들에 대해 이야기해봅시다.

두 가지 접근 방식 이해하기

먼저 우리가 뭘 비교하고 있는지 명확히 하겠습니다. 이 둘은 완전히 다른 짐승입니다.

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 직렬변환기가 필요합니다. 예를 들어, 몇 가지 커스텀 요소가 있는 사이트의 경우? 당신은 며칠 정도의 일을 보고 있습니다. 수십 개의 요소가 있는 거대한 엔터프라이즈 설정? 자신을 준비하세요—이것은 몇 주가 걸릴 수 있습니다.

TYPO3 헤드리스가 잘하는 것

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

EXT:headless의 함정

  • TYPO3는 어디로도 가지 않습니다. PHP에 정통하고 TYPO3를 이해하는 사람들이 필요하며, 그들은 정확히 어디에나 있지 않습니다.
  • 복잡한 호스팅. 당신은 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의 행 수준 보안. 당신이 단단한 제어를 원할 때 진지하게 멋집니다.
  • 실시간 기능. 라이브 업데이트를 쉽게 통합합니다.
  • 쉬운 배포. Next.js는 Vercel을 사용하고 백엔드는 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 | | 라이트하우스 점수 | 92 | 98 | | 전체 빌드 시간 | 4m 20s | 1m 45s | | API 응답(p95) | 180ms | 22ms |

밑줄? 캐시되지 않은 TTFB는 Supabase에서 더 낫지만, CDN 캐싱은 거의 필드를 수평으로 만듭니다. 둘 다, 제대로 설정되면, 최종 사용자에게 충분히 빠르게 집니다.

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

개발자 경험 및 팀 고려사항

TYPO3에 들어가기

당신은 여전히 헤드리스 프로젝트를 위해 TYPO3 전문가가 필요할 것입니다. PHP 직렬변환기, 업그레이드 테스트 및 호환성 문제 처리를 생각하세요. 2026년에 이러한 전문가들은 당신을 €80-120/시간으로 설정할 수 있습니다. 그리고 일부 개발자들은 헤드리스 설정에 대해 기뻐하지 않습니다—그것은 Fluid 템플릿의 즐거움을 빼앗습니다.

Next.js + Supabase 클럽

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 개발과 같은 선택지를 가벼운 콘텐츠 많은 사이트에 고려하고 있다면, 그것은 한번 보는 것이 좋습니다.

당신의 특정 필요에 대해 채팅하고 싶으신가요? 우리는 당신의 고유한 시나리오에 대해 무엇이 합리적인지 평가하는 데 도움을 드리고 있습니다—연락하세요, 그리고 우리는 "당신이 아는 것을 고수"인 경우에도 정직한 평가를 약속합니다.

자주 묻는 질문

2026년에 TYPO3 EXT:headless가 프로덕션 준비가 되어 있나요? 네, 절대적으로. EXT:headless는 버전 3.x 이후로 안정적이고 적극적으로 지원됩니다. 버전 4.x는 TYPO3 v12 및 v13을 견고한 콘텐츠 직렬화, 메뉴 생성 및 양식 처리로 다룹니다. 수많은 큰 엔터프라이즈 사이트는 정부 및 금융 부문을 포함한 독일과 오스트리아의 프로덕션 설정에서 그것을 실행합니다.

Next.js를 TYPO3 헤드리스 프론트엔드에 사용할 수 있나요? 물론입니다, 이것은 고전적인 조합입니다. Next.js App Router를 TYPO3의 JSON API에서 정보를 수집할 서버 컴포넌트와 함께 활용할 것입니다. 미리보기 통합은 가장 까다로운 비트입니다: 드래프트 모드를 설정하고 TYPO3가 미리보기 URL을 통해 호출하도록 지시합니다. 다행히, 커뮤니티는 Next.js 페어링을 통해 안내하는 유용한 문서를 작성했습니다.

Supabase가 TYPO3의 데이터베이스 설정과 어떻게 비교되나요? 오, 이것들은 사과와 오렌지입니다. TYPO3는 TCA에 의해 관리되는 엄격한 스키마와 함께 Doctrine DBAL에서 실행됩니다. Supabase는 행 수준 보안이 포함된 그 달콤한 PostgreSQL 자유를 제공합니다. Supabase는 유연하고 강력한 쿼리 기능을 제공하지만, TYPO3는 편집자가 실수로 도입할 수 있는 실수를 방지하기 위해 신중하게 구조화됩니다. 그것은 모두 제어 대 보안입니다.

헤드리스 TYPO3에 대한 SEO 문제? 메타 태그 및 구조화된 데이터 처리? EXT:headless는 메타 태그 및 오픈 그래프 데이터와 같은 페이지 속성을 직렬화합니다. 당신의 프론트엔드는 그것들을 HTML 태그로 렌더링해야 합니다. 레이아웃에서 Next.js의 메타데이터 API를 사용합니다. 당신의 TYPO3 설정이 견고하다면, SEO 데이터는 따라야 합니다. EXT:yoast_seo와 같은 확장을 통합하고 헤드리스 구성과 잘 어울립니다.

Supabase가 엔터프라이즈급 콘텐츠 배달까지 확장할까요? 물론입니다. Supabase Cloud(AWS에서 실행)는 Pro 플랜에서 99.9% 가동 시간을 제공하고 팀 플랜에서 99.95%로 부스트합니다(2026년 요금 확인). CDN 캐싱(Vercel's Edge Network, Cloudflare)의 경우, Supabase는 주로 쓰기 및 실시간 기능 안정성을 보장합니다. 중요한 엔터프라이즈 사용의 경우, 최대 제어를 위해 Supabase를 자체 호스트합니다.

TYPO3 없이 이미지 처리를 어떻게 처리할까요? TYPO3는 기본적으로 이미지를 처리합니다—자르기, 크기 조정, 형식 플립. 그것 없으면, 당신의 이미지 워크플로우를 설정합니다. 2026년의 상위 경쟁자들은: Next.js 이미지 최적화(내장, Vercel 지원), Cloudinary(무료로 시작, 심각한 사용은 유료 플랜이 필요함), 또는 imgix(€100+/월부터 시작)입니다. Supabase Storage는 원본을 처리하지만 변환은 하지 않습니다.

TYPO3 헤드리스에서 완전히 헤드리스로 증분 마이그레이션할 수 있을까요? 절대적으로, 부드러운 계획처럼 생각합니다. 헤드리스 TYPO3로 시작하여, 프론트엔드를 격리합니다. 천천히 콘텐츠를 TYPO3에서 Supabase 또는 당신이 선택한 CMS로 전환하세요 — 더 간단한 타입으로 시작합니다. 단계 동안, 당신의 Next.js 프론트엔드는 두 원본에서 데이터를 사용하여 작동합니다.

TYPO3 팀이 Next.js + Supabase로 전환하는 학습 곡선은 어떨까요? 현실적인 경사는 약 3개월에서 6개월입니다. 즉, 도전 과제는 JavaScript나 TypeScript가 아닙니다—그것은 패러다임 변화입니다. TYPO3 개발자들은 프레임워크가 콘텐츠 구조, 캐싱 및 경로를 조종하는 데 익숙합니다. Next.js + Supabase 모델에서, 그 호출들은 당신의 것입니다. 그것은 해방적이지만 처음에는 압도적입니다. 숙련된 Next.js 사람들과 쌍 프로그래밍을 하면 이 도약을 훨씬 부드럽게 만듭니다.