TYPO3에서 Drupal로 마이그레이션: 실무 개발자 가이드
TYPO3에서 Drupal로의 마이그레이션: 실무 개발자 가이드
TYPO3 백엔드를 보면서 "더 나은 방법이 있을 텐데"라고 생각한 적이 있다면, 당신만 그런 게 아닙니다. TYPO3의 강점은 인정합니다. 20년 이상 유럽의 수많은 엔터프라이즈 및 정부 사이트의 CMS로 사랑받아 왔습니다. 하지만 솔직히 말해서, 개발자 생태계는 많이 변했습니다. 많은 조직들이 Drupal이 더 현대적인 설정, 더 강한 커뮤니티, 헤드리스/디커플 아키텍처로의 더 쉬운 전환을 제공한다는 것을 발견하고 있습니다.
지난 몇 년 동안 TYPO3에서 Drupal로의 마이그레이션에 몸담아 있었고, 실제 콘텐츠 모델을 풀어내는 것은 꽤 험난한 여정이었습니다. 보통 복잡하게 얽혀 있습니다. 이 가이드는 첫 번째 마이그레이션 전에 누군가가 건네줬으면 좋았을 것입니다. 모든 세세한 기술 세부사항, 계획 필수 사항, 그리고 타이밍을 망칠 수 있는 까다로운 함정들을 다룰 것입니다.
목차
- TYPO3를 떠나는 이유
- TYPO3 vs Drupal: 솔직한 비교
- 마이그레이션 전 감사 및 계획
- 콘텐츠 모델링: TYPO3를 Drupal에 매핑하기
- 마이그레이션 도구 및 기술 접근
- TYPO3 TypoScript 및 확장 처리
- URL 구조 및 SEO 보존
- 마이그레이션 후 헤드리스로 전환하기
- 타임라인, 비용 및 인력 추정
- 마이그레이션 후 체크리스트
- FAQ
TYPO3를 떠나는 이유
명확히 말하자면, TYPO3는 나쁜 CMS가 아닙니다. 매우 유연하고, 멀티사이트, 멀티언어 설정을 기본적으로 처리하며, 특히 DACH 지역에서 열렬한 팬층을 자랑합니다. 그렇다면 왜 사람들은 떠날까요?
매번 거의 같은 이유들을 듣습니다:
개발자 가용성. 중부 유럽 외에서 TYPO3 개발자를 찾는 것은 건초 더미에서 바늘을 찾는 것만큼 어렵습니다. 반면 Drupal은 Drupal.org의 2024 커뮤니티 리포트에 따르면 전 세계적으로 약 130만 명의 개발자를 보유하고 있습니다. TYPO3는 그렇지 않습니다. 시니어 TYPO3 개발자들이 떠나가기로 결정하면, 그 자리를 채우는 데 영원히 걸릴 수 있습니다.
생태계 모멘텀. 2024년 말의 Drupal 11 출시와 함께 관리자 UI, 새로운 레시피 시스템, 킬러급 API 우선 기능에서 엄청난 발전이 있었습니다. 확실히 TYPO3 v13은 견고하지만, 특히 헤드리스 설정 주변에서 Drupal의 혁신 속도는 눈에 띄게 빠릅니다.
헤드리스/디커플 아키텍처. 멋진 Next.js나 Astro 프론트엔드에 콘텐츠를 제공할 계획이신가요? Drupal의 JSON:API와 GraphQL 플러그인은 숙련된 전문가들입니다. TYPO3도 헤드리스 확장을 가지고 있지만, 더 미성숙하고 지원이 적습니다.
총소유비용. TYPO3 호스팅은 일반적으로 지갑에 더 큰 타격을 줍니다. 전문화된 인프라는 더 많은 비용을 쓰게 될 수 있습니다. Drupal은 Pantheon에서 Acquia까지, 기본적인 LAMP 스택도 문제없이 돌아갑니다.
TYPO3 vs Drupal: 솔직한 비교
무턱대고 이전하기 전에, Drupal이 정말 당신의 문제를 해결할지 확인하세요. 2025년 기준 상황은 다음과 같습니다:
| 기능 | TYPO3 v13 | Drupal 11 |
|---|---|---|
| 콘텐츠 모델링 | 유연하지만 TCA 의존적 | Entity/Field 시스템과 필드 관리 UI |
| 멀티언어 | 뛰어난 기본 지원 | 똑같이 뛰어난 기본 지원 |
| 멀티사이트 | 콘텐츠 트리가 있는 표준 멀티사이트 | 가능, Domain Access나 별도 설치로 더 잘됨 |
| 헤드리스/API | 헤드리스 확장 보유 | JSON:API 코어, GraphQL contrib |
| 템플릿 | Fluid 템플릿 + TypoScript | Twig 템플릿 실행 |
| 확장/모듈 생태계 | TER에 약 1,800개 확장 | Drupal.org에 50,000개+ 모듈 |
| 관리자 UI | 강하지만 오래됨 (v13에서 개선 중) | Drupal 11에서 세련되고 현대적 |
| 개발자 커뮤니티 | 약 500명의 활동적인 기여자 | 8,000명 이상의 활동적인 기여자 |
| 호스팅 옵션 | 자체 호스팅 또는 전문 호스팅 | 자체 호스팅, Pantheon, Acquia, Platform.sh, Lagoon |
| PHP 요구사항 | PHP 8.2+ | PHP 8.3+ |
| 일반적인 에이전시 요금 | €100-180/시간 (DACH 지역) | $80-200/시간 (글로벌) |
TYPO3의 페이지 트리 모델은 희귀한 보석입니다. TYPO3에서 복잡한 페이지 계층 구조를 관리하는 데 익숙한 편집자들은 Drupal의 스타일(콘텐츠 타입과 분류법의 조합)이 조정을 필요로 한다는 것을 알 수 있습니다. 편집자 교육을 계획하여 전환을 용이하게 하세요.
마이그레이션 전 감사 및 계획
이 단계가 대부분의 마이그레이션의 운명을 결정합니다. 기술 시간이 아니라 계획이 중요합니다.
콘텐츠 인벤토리
TYPO3 설정의 모든 것을 감시하여 시작하세요:
- 페이지: 페이지 트리를 뽑아내서 모든
doktype(페이지 타입)을 문서화하세요. - 콘텐츠 요소: 모든
CType(콘텐츠 타입)이 주의가 필요합니다. 텍스트, 텍스트와 이미지, HTML, 또는mask나content_defender를 통한 커스텀 요소 등입니다. - 확장: 모든 확장을 메모하세요. Drupal 동등품이 있는지 알아보세요.
- 파일 참조: TYPO3의 FAL (File Abstraction Layer)은 미디어를 다룹니다. 이를 Drupal의 미디어로 매핑하세요.
- 백엔드 사용자 및 권한: TYPO3의 페이지와 필드 레벨 접근 제어가 있는 복잡한 백엔드 사용자 그룹을 Drupal 역할과 권한으로 깔끔하게 번역하세요.
TYPO3 데이터베이스에서 콘텐츠 요소 개요를 위한 편리한 SQL 쿼리는 다음과 같습니다:
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
이것으로 당신이 다루고 있는 콘텐츠 타입을 빠르게 살펴볼 수 있습니다. 한 경우에 저는 40개 이상의 커스텀 콘텐츠 요소 타입을 가진 TYPO3 인스턴스를 발견했는데, 단 12개만 적극적으로 사용되고 있었습니다. 죽은 무게를 끌어다니지 마세요.
무엇을 유지하고 무엇을 버릴지
이것이 당신의 청소 기회입니다. Screaming Frog나 Sitebulk 같은 콘텐츠 감사 도구를 사용하여 다음을 찾아내세요:
- 지난 1년간 트래픽이 없는 페이지
- 중복되거나 거의 동일한 콘텐츠
- 끊긴 내부 링크
- 고아 미디어 파일
일반적으로 대규모 TYPO3 마이그레이션에서는 30-50%의 콘텐츠 삭감이 이루어집니다. 페이지가 적을수록 마이그레이션이 빠릅니다.
콘텐츠 모델링: TYPO3를 Drupal에 매핑하기
팔을 걷어붙이세요. 이것이 무거운 지적 작업입니다. TYPO3와 Drupal은 콘텐츠를 매우 다르게 다룹니다.
TYPO3의 모델
TYPO3는 페이지를 중심으로 회전합니다. 모든 것이 페이지 트리 안에 숨겨져 있습니다. 콘텐츠 요소 (tt_content의 레코드)는 페이지의 열(colPos)에 슬롯됩니다. Extbase 모델이나 TCA를 통해 정의된 커스텀 레코드는 별도 테이블에 있지만 보통 페이지에서 연결됩니다.
Drupal의 모델
Drupal은 엔티티가 전부입니다. 콘텐츠 타입(노드 번들)을 만들고, 각각 전용 필드를 가집니다. 페이지는 많은 콘텐츠 타입 중 하나일 뿐입니다. 분류법, 단락(Paragraphs 모듈 사용), 레이아웃 빌더가 구조화된 콘텐츠 구성을 마스터합니다.
매핑
다음은 내가 나침반으로 사용하는 일반적인 매핑 테이블입니다:
| TYPO3 개념 | Drupal 동등품 |
|---|---|
| 페이지 (doktype: standard) | 노드 (콘텐츠 타입: 페이지) |
| 페이지 (doktype: shortcut) | URL 리디렉션 |
| 페이지 (doktype: link) | 링크 필드 또는 리디렉션이 있는 노드 |
| 콘텐츠 요소 (CType: text) | 단락 타입 또는 본문 필드 |
| 콘텐츠 요소 (CType: image) | 미디어 엔티티 참조 |
| 콘텐츠 요소 (CType: textpic) | 텍스트 + 미디어가 있는 단락 타입 |
| 콘텐츠 요소 (CType: gridelements) | 레이아웃 빌더 섹션 |
| FAL 파일 참조 | 미디어 엔티티 |
| sys_category | 분류 용어 |
| fe_users | Drupal 사용자 엔티티 |
| be_users | 관리자 역할이 있는 Drupal 사용자 엔티티 |
| TypoScript 템플릿 | Twig 템플릿 |
| Extbase 플러그인 | 커스텀 Drupal 모듈 |
| Mask/DCE 콘텐츠 요소 | 단락 타입 |
가장 큰 변화는? 콘텐츠 요소를 단락으로 이동시키는 것입니다. TYPO3는 콘텐츠 요소를 페이지 열에 스택하고, 이는 Drupal의 Paragraphs 모듈에 잘 매핑됩니다. 편집자는 재사용 가능한 단락 타입에서 페이지를 스택합니다. 놀랍도록 원활합니다.
마이그레이션 도구 및 기술 접근
Drupal의 Migrate API는 멋집니다. 하지만 주의, TYPO3 소스 플러그인이 기본으로 없습니다. TYPO3의 데이터베이스에서 당겨올 커스텀 소스 플러그인을 직접 만들어야 합니다.
접근 1: 직접 데이터베이스 마이그레이션
Drupal의 Migrate API를 TYPO3 MySQL/MariaDB 데이터베이스에 직접 연결하세요:
// TYPO3 페이지를 위한 예제 마이그레이션 소스 플러그인
namespace Drupal\typo3_migrate\Plugin\migrate\source;
use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;
/**
* @MigrateSource(id = "typo3_pages")
*/
class Typo3Pages extends SqlBase {
public function query() {
return $this->select('pages', 'p')
->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
->condition('p.deleted', 0)
->condition('p.hidden', 0)
->condition('p.doktype', [1, 4], 'IN');
}
public function fields() {
return [
'uid' => $this->t('Page ID'),
'title' => $this->t('Page title'),
'slug' => $this->t('URL slug'),
'abstract' => $this->t('Abstract/summary'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// 관련 콘텐츠 요소 로드
$pid = $row->getSourceProperty('uid');
$content = $this->select('tt_content', 'tt')
->fields('tt')
->condition('tt.pid', $pid)
->condition('tt.deleted', 0)
->orderBy('tt.sorting')
->execute()
->fetchAll();
$row->setSourceProperty('content_elements', $content);
return parent::prepareRow($row);
}
}
나는 이 접근을 좋아합니다. 완전한 제어를 가지고 TYPO3의 특이한 점(소프트 삭제 및 워크스페이스 오버레이 같은)을 코드베이스에서 처리할 수 있습니다.
접근 2: JSON이나 XML을 통한 내보내기/가져오기
일부 팀은 TYPO3 콘텐츠를 구조화된 형식으로 내보내기(커스텀 TYPO3 확장이나 CLI 명령어를 통해)를 선택하고 이를 Drupal로 가져옵니다. 확실히 한 단계 더 추가되지만 마이그레이션 중에 직접 데이터베이스 연결 유지에 대해 걱정할 때 편합니다.
접근 3: 수동 검토와 혼합
더 작은 사이트(500페이지 미만)가 있으신가요? 자동으로 구조화된 데이터 마이그레이션을 하면서 핵심 랜딩 페이지를 손으로 만드는 것이 잘 작동할 수 있습니다. 원시적으로 보일 수 있지만, 콘텐츠가 TYPO3 특정 렌더링 로직과 얽혀 있을 때, 자동화된 마이그레이션은 종종 말도 안 되는 결과를 냅니다.
TYPO3 TypoScript 및 확장 처리
TypoScript
단도직입으로, TypoScript는 마이그레이션되지 않습니다. 이것은 TYPO3 특정 설정 언어이며, 다른 곳에서 실제 대응물이 없습니다. 당신의 일은 각 TypoScript 템플릿이 무엇을 하는지 일반인 용어로 문서화한 다음 이를 Twig 템플릿과 Drupal 설정으로 재구성하는 것입니다. 고통스럽지만 필요합니다.
확장
일반적인 TYPO3 확장과 Drupal 동등품의 편리한 비교입니다:
| TYPO3 확장 | Drupal 동등품 |
|---|---|
| news | 코어 콘텐츠 타입 + 뷰 |
| powermail | Webform 모듈 |
| solr (ext:solr) | Search API + Solr |
| realurl / routing | Pathauto + 코어 라우팅 |
| gridelements | 레이아웃 빌더 또는 단락 |
| mask | 단락 |
| tt_address | 커스텀 콘텐츠 타입 또는 CiviCRM |
| ke_search | Search API |
| femanager | 사용자 모듈 + 커스텀 |
| cal/events | 커스텀 콘텐츠 타입 + 뷰 |
커스텀 Extbase 확장은 Drupal 모듈로 재작성이 필요합니다. 지름길은 없습니다. 이를 위해 예산을 책정해야 합니다.
URL 구조 및 SEO 보존
이를 망치면 유기 트래픽을 잃습니다. 마이그레이션 후 리디렉션 처리 부실로 인해 검색 트래픽의 40%를 잃은 조직들을 봤습니다.
단계
- TYPO3에서 모든 URL을 내보내세요. CLI 도구나 크롤러를 사용하여 모든 색인된 URL을 가져오세요.
- 이를 Drupal URL로 매핑하세요. Drupal의 Pathauto를 사용하여 URL 별칭 생성, 기존 URL에 가깝게 유지하세요.
- 변경되는 모든 항목에 대해 리디렉션을 만드세요. Drupal에서 Redirect 모듈을 배포하세요. 많은 리디렉션의 경우 CSV에서 가져오세요.
- 언어 접두사를 처리하세요. TYPO3는
/de/,/en/,/fr/을 사용합니다. Drupal의 언어 설정이 이를 반영하는지 확인하세요. - 업데이트된 사이트맵을 즉시 Google Search Console에 제출하세요.
# Drupal의 Redirect 모듈을 위한 리디렉션 가져오기 CSV 형식의 예
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de
팁: 마이그레이션 후 최소 3개월 동안 구 TYPO3 인스턴스를 읽기 전용이지만 활성 상태로 유지하세요. 놓친 URL을 발견할 것입니다.
마이그레이션 후 헤드리스로 전환하기
Drupal은 디커플 프론트엔드로의 경로에서 빛납니다. Drupal 11과 함께, JSON:API 모듈은 견고하고, 헤드리스 Drupal 생태계는 번성하고 있습니다.
헤드리스 접근을 고민 중이라면(그리고 2025년에, 대부분의 콘텐츠 중심 사이트에서는 검토할 가치가 있습니다), 우리는 /solutions/headless-cms-development에서 이를 철저히 다루었습니다.
인기 있는 프론트엔드를 Drupal과 페어링하기:
- Next.js — 최선봉. Chapter Three의
next-drupal이 것들을 쉽게 해줍니다. 우리는 /capabilities/nextjs-development에서 광범위하게 논의합니다. - Astro — 콘텐츠 많은 사이트에 완벽한데 클라이언트 복잡성이 크지 않을 때 좋습니다. /capabilities/astro-development을 보세요.
- Nuxt — Vue가 당신의 놀이터라면.
먼저 Drupal로 마이그레이션하는 아름다움은 Drupal의 기본 Twig 프론트엔드로 시작한다는 것입니다. 나중에 디커플된 것으로 전환할 수 있습니다. 두 이동을 동시에 시도하지 마세요. 이것은 프로젝트 혼돈을 요청하는 것입니다.
타임라인, 비용 및 인력 추정
제가 참여했거나 정확한 데이터를 가지고 있는 프로젝트의 실제 숫자 (2024-2025):
| 사이트 크기 | 페이지 | 타임라인 | 예산 범위 | 팀 |
|---|---|---|---|---|
| 소규모 | <500 페이지 | 2-3개월 | $30,000-60,000 | 2-3명 개발자 |
| 중규모 | 500-5,000 페이지 | 4-6개월 | $60,000-150,000 | 3-5명 개발자 |
| 대규모 | 5,000-50,000 페이지 | 6-12개월 | $150,000-400,000 | 5-8명 개발자 |
| 엔터프라이즈 | 50,000+ 페이지 | 12-18개월 | $400,000-1,000,000+ | 8-15명 개발자 |
여기에는 발견, 콘텐츠 모델링, 마이그레이션, 프론트엔드 테마, QA, 편집자 교육이 모두 포함됩니다. 지속적인 유지보수는 여기에 포함되지 않습니다.
큰 비용 요소는 단순히 페이지 수가 아닙니다. 30개의 커스텀 콘텐츠 타입과 4개의 언어가 있는 2,000페이지 사이트는 간단한 10,000페이지 사이트보다 더 많은 비용이 들 것입니다.
당신의 경우에 특정한 세부사항을 고려 중인가요? /pricing을 확인하거나 직접 연락하세요.
마이그레이션 후 체크리스트
이 체크리스트를 건너뛰지 마세요. 날 믿으세요.
- 모든 리디렉션을 확인하세요. 301인지 확인하세요.
- Google Search Console을 새 사이트맵으로 업데이트하세요.
- 모든 양식을 테스트하세요: 연락처, 뉴스레터, 로그인.
- 각 언어에 대한 멀티언어 콘텐츠 정확성을 확인하세요.
- 미디어 파일이 정확히 마이그레이션되었는지 alt 텍스트 및 메타데이터를 확인하세요.
- 각 역할에 대한 편집자 권한을 확인하세요.
- 성능 지표를 캡처하세요 (Core Web Vitals).
- 분석 추적을 확인하세요 (GA4 이벤트, 목표).
- CDN/캐싱을 구성하고 테스트하세요.
- 보안 헤더를 활성화하세요 (CSP, HSTS).
- 백업 및 재해 복구 시스템을 테스트하세요.
- 편집자 교육을 완료하고 문서를 제공하세요.
- 구 TYPO3 인스턴스를 읽기 전용 모드로 계속 사용 가능하게 유지하세요.
FAQ
TYPO3에서 Drupal로의 마이그레이션에는 일반적으로 얼마나 오래 걸립니까?
중간 규모 사이트 (500-5,000 페이지)의 경우 시작부터 출시까지 약 4-6개월입니다. 첫 달? 순수하게 발견 및 콘텐츠 모델링입니다. 마이그레이션 스크립팅은 보통 6-8주의 작업입니다. QA 및 편집자 교육? 추가로 1개월을 계산하세요. 복잡한 멀티언어, 멀티사이트 설정 및 커스텀 확장이 있다면, 9-12개월을 보고 있습니다.
TYPO3 콘텐츠를 자동으로 마이그레이션할 수 있거나, 수동입니까?
페이지, 뉴스 레코드, 또는 카테고리 같은 구조화된 콘텐츠? 확실히 Drupal의 Migrate API를 사용한 자동화된 작업입니다. 하지만 TYPO3의 복잡한 렌더링 로직 콘텐츠는 약간의 수동 손질이 필요할 수 있습니다. 대부분의 마이그레이션? 약 70-80% 자동, 20-30% 수동입니다.
마이그레이션 중에 Google 순위를 잃을까요?
리디렉션에 철저하면 안 됩니다. URL 변경에 대해 301을 설정하고, URL 구조를 최대한 유지하고, 업데이트된 사이트맵을 바로 제출하세요. 2-6주의 하락을 볼 수 있을 것입니다. 하지만 반등은 전형적입니다. 사이트는 보통 4-8주 내에 마이그레이션 전 수준으로 반등하고 종종 3개월 후에는 더 나은 성능으로 인한 개선을 봅니다.
Drupal을 학습하는 것이 콘텐츠 편집자에게 TYPO3보다 더 어렵습니까?
다르지만, 더 어렵지는 않습니다. TYPO3의 페이지 트리 모델에 익숙한 사람들은 Drupal의 엔티티 중심 접근법에 적응하는 데 시간이 필요할 수 있습니다. Paragraphs 모듈은 어느 정도 유사한 콘텐츠 구축 경험을 제공합니다. 편집자와 직원을 위해 약 2-3일의 교육을 예산으로 계획하고 콘텐츠 타입 및 워크플로우 특정 문서를 제공하세요.
마이그레이션 중에 TYPO3 확장은 어떻게 됩니까?
모든 확장은 개별적 평가가 필요합니다. 많은 것들은 직접적인 Drupal 동등품을 가집니다 (예: powermail → Webform, ext:news → 커스텀 콘텐츠 타입 + Views, ext:solr → Search API + Solr). 커스텀 Extbase 확장? 이들은 Drupal 모듈로 완전히 재작성이 필요합니다. 컨버터는 없습니다. 커스터마이징이 필요합니다.
TYPO3에서 Drupal로 마이그레이션할 때 헤드리스로 가야 합니까?
당신의 목표와 타임라인에 따릅니다. 당신의 이동이 개발자 또는 유지보수성 관심사에 의해 동기가 부여된다면, Drupal의 Twig 테마로 간단하게 시작하고 나중에 헤드리스를 목표로 하세요. 하지만 프론트엔드 팀이 React나 유사한 설정을 좋아하고, 현대적 배달 아키텍처를 원한다면, 처음부터 헤드리스를 계획하는 것을 고려하세요. 두 마이그레이션을 동시에 수행하는 것을 기억하세요? 이것은 고위험 영역입니다.
마이그레이션에서 멀티언어 콘텐츠를 어떻게 처리합니까?
TYPO3의 언어 설정 (sys_language_uid, l10n_parent)은 Drupal의 콘텐츠 번역 모듈과 잘 맞춥니다. 트릭은? 스크립트에서 언어간 매핑을 못 박고 대체 기능이 당신의 기대와 일치하는지 확인합니다. 부분적으로 번역된 콘텐츠에 조심하세요. TYPO3의 언어 오버레이 모드 (자유, 연결, 엄격)는 정확한 Drupal 대응물이 없습니다. 불완전한 번역에 대한 편집상 결정이 필요할 수 있습니다.
TYPO3에서 Drupal로 마이그레이션하는 ROI는 무엇입니까?
ROI는 어디에 있습니까? 주로 개발자 비용 절감과 기능 출시 속도 향상에서 나옵니다. 역사적으로, 내가 안내한 팀들은 주로 더 쉬운 인재 충원과 더 큰 모듈 풀로 인해 커스텀 개발의 필요성을 줄이는 덕분에 1년차에 약 20-40%의 개발 비용 절감을 봅니다. 초기 마이그레이션 비용은 가팔랐을 수 있지만, 대부분 18-24개월 내에 손익분기점에 도달해야 합니다.