TYPO3에서 Drupal로 마이그레이션: 콘텐츠, 사용자 및 URL 유지
TYPO3 캐시 재빌드를 마친 스테이징 서버에서 2초 정도 걸려야 하는 콘텐츠 변경이 43초가 걸립니다. 프론트엔드 개발자가 브라우저를 새로 고쳐 업데이트를 확인하고 스탠드업에서 반복하면 안 될 TypoScript에 대해 중얼거립니다. 이 장면은 20년간 정부 포털과 기업 사이트에 전력을 공급해 온 TYPO3를 사용하는 유럽 전역의 엔터프라이즈에서 매일 반복됩니다. CMS는 기술적으로는 여전히 작동합니다. 하지만 Drupal의 컴포넌트 중심 아키텍처, 헤드리스 툴킷, 10배 더 큰 기여자 기반은 마이그레이션 논의를 불가피하게 만듭니다. 질문은 이전할지 여부가 아니라 8,000개 페이지를 이동하고 20년의 URL 자산을 유지하며 전환 중에 콘텐츠 편집자를 정신적으로 유지하는 방법입니다. 지난 18개월 동안 이 방법을 6번 실행했으며, 깔끔한 마이그레이션과 재앙 사이의 차이는 첫 주에 내릴 4가지 결정으로 귀결됩니다.
지난 몇 년간 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이 정말 통증 지점을 해결할 것임을 확인하세요. 2026년 현재 상황입니다:
| 기능 | TYPO3 v13 | Drupal 11 |
|---|---|---|
| 콘텐츠 모델링 | 유연하지만 TCA에 의존 | 엔티티/필드 시스템과 필드 관리 UI |
| 다중 언어 | 뛰어난 기본 지원 | 동등하게 뛰어난 기본 지원 |
| 다중 사이트 | 콘텐츠 트리가 있는 표준 다중 사이트 | 가능, Domain Access 또는 별도 설치로 더 나음 |
| 헤드리스/API | 헤드리스 확장 포함 | JSON:API 핵심, GraphQL 기여 |
| 템플릿 | 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 (파일 추상화 계층)은 미디어를 다룹니다. 이를 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 또는 Sitebulb와 같은 콘텐츠 감사 도구를 사용하여 다음을 찾으세요:
- 지난 1년간 트래픽이 없는 페이지
- 중복되거나 거의 동일한 콘텐츠
- 끊어진 내부 링크
- 고아 미디어 파일
일반적으로 큰 TYPO3 마이그레이션에서는 30-50%의 콘텐츠가 삭제됩니다. 페이지가 적을수록 마이그레이션이 빠릅니다.
콘텐츠 모델링: TYPO3을 Drupal에 매핑
소매를 걷어 올리세요. 이것이 무거운 지적 노력입니다. TYPO3과 Drupal은 콘텐츠를 매우 다르게 처리합니다.
TYPO3의 모델
TYPO3은 페이지를 중심으로 회전합니다. 모든 것이 페이지 트리에 숨겨져 있습니다. 콘텐츠 요소 (tt_content의 레코드)는 페이지의 열 (colPos)에 들어갑니다. Extbase 모델 또는 TCA를 통해 정의된 사용자 정의 레코드는 별도 테이블에 있지만 일반적으로 페이지에서 연결됩니다.
Drupal의 모델
Drupal은 엔티티 중심입니다. 콘텐츠 유형 (노드 번들)을 만들고 각각에 전용 필드가 있습니다. 페이지는 많은 콘텐츠 유형 중 하나일 뿐입니다. 분류법, 단락 (단락 모듈 사용), 레이아웃 빌더는 구조화된 콘텐츠 구성을 마스터합니다.
매핑
나의 나침반으로 사용하는 일반적인 매핑 테이블입니다:
| TYPO3 개념 | Drupal 등가물 |
|---|---|
| Page (doktype: standard) | Node (content type: Page) |
| Page (doktype: shortcut) | URL redirect |
| Page (doktype: link) | 링크 필드가 있는 노드 또는 리디렉션 |
| Content element (CType: text) | 단락 유형 또는 본문 필드 |
| Content element (CType: image) | 미디어 엔티티 참조 |
| Content element (CType: textpic) | 텍스트 + 미디어가 있는 단락 유형 |
| Content element (CType: gridelements) | 레이아웃 빌더 섹션 |
| FAL file reference | 미디어 엔티티 |
| sys_category | 분류법 항목 |
| fe_users | Drupal 사용자 엔티티 |
| be_users | 관리자 역할이 있는 Drupal 사용자 엔티티 |
| TypoScript template | Twig 템플릿 |
| Extbase plugin | 사용자 정의 Drupal 모듈 |
| Mask/DCE content elements | 단락 유형 |
가장 큰 변화는? 콘텐츠 요소를 단락으로 이동합니다. TYPO3은 페이지 열에 콘텐츠 요소를 쌓으며, 이는 Drupal의 단락 모듈에 잘 매핑됩니다. 편집자는 재사용 가능한 단락 유형에서 페이지를 쌓습니다. 놀랍게도 매끄럽습니다.
마이그레이션 도구 및 기술 접근법
Drupal의 마이그레이션 API는 훌륭합니다. 하지만 알아두세요, 기본 TYPO3 소스 플러그인이 부족합니다. TYPO3 데이터베이스에서 가져오기 위해 일부 사용자 정의 소스 플러그인을 직접 작성해야 합니다.
접근법 1: 직접 데이터베이스 마이그레이션
Drupal의 마이그레이션 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 | 핵심 콘텐츠 유형 + Views |
| powermail | Webform 모듈 |
| solr (ext:solr) | Search API + Solr |
| realurl / routing | Pathauto + 핵심 라우팅 |
| gridelements | 레이아웃 빌더 또는 단락 |
| mask | 단락 |
| tt_address | 사용자 정의 콘텐츠 유형 또는 CiviCRM |
| ke_search | Search API |
| femanager | 사용자 모듈 + 사용자 정의 |
| cal/events | 사용자 정의 콘텐츠 유형 + Views |
사용자 정의 Extbase 확장을 Drupal 모듈로 재작성해야 합니다. 지름길이 없습니다. 확실히 예산을 책정하세요.
URL 구조 및 SEO 보존
이것을 망치면 유기 트래픽을 잃습니다. 잘못 처리된 리디렉션으로 인해 마이그레이션 후 검색 트래픽의 최대 40%를 잃은 조직을 목격했습니다.
단계
- TYPO3에서 모든 URL을 내보냅니다. 모든 인덱싱된 URL에 대해 CLI 도구 또는 크롤러를 사용합니다.
- 이를 Drupal URL에 매핑합니다. Drupal의 Pathauto를 사용하여 URL 별칭 생성, 기존 URL에 가깝게 유지합니다.
- 변경된 모든 항목에 대해 리디렉션을 만듭니다. Drupal에서 리디렉션 모듈을 배포합니다. 많은 리디렉션의 경우 CSV로 가져옵니다.
- 언어 접두어를 처리합니다. TYPO3은
/de/,/en/,/fr/을 사용합니다. Drupal의 언어 설정이 이를 반영하는지 확인합니다. - Google Search Console에 업데이트된 사이트맵을 제출합니다. 즉시 제출합니다.
# Drupal의 리디렉션 모듈에 대한 리디렉션 가져오기 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 에코시스템은 번창하고 있습니다.
분리된 접근법을 검토하고 있다면, 2026년에는 대부분의 콘텐츠 기반 사이트에서 고려할 가치가 있으며, 우리는 /solutions/headless-cms-development에서 철저하게 다루었습니다.
Drupal과 인기 있는 프론트엔드를 쌍을 이루기:
- Next.js — 최고의 선택. Chapter Three의
next-drupal이 일을 쉽게 합니다. /capabilities/nextjs-development에서 광범위하게 다룹니다. - Astro — 클라이언트가 너무 많지 않은 콘텐츠가 풍부한 사이트에 완벽합니다. /capabilities/astro-development를 참조하세요.
- Nuxt — Vue가 당신의 놀이터라면.
먼저 Drupal로 마이그레이션하는 아름다움은 Drupal의 기본 Twig 프론트엔드로 출시하는 것입니다. 나중에 분리된 것으로 전환할 수 있습니다. 두 이동을 동시에 시도하지 마세요. 그것은 프로젝트 혼란을 요청하는 것입니다.
타임라인, 비용 및 인력 추정
내가 참여했거나 정확한 데이터가 있는 프로젝트 (최근 연도)의 실제 숫자:
| 사이트 규모 | 페이지 | 타임라인 | 예산 범위 | 팀 |
|---|---|---|---|---|
| 소규모 | <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 및 편집자 교육? 또 다른 달을 계산합니다. 복잡한 다중 언어, 다중 사이트 설정과 사용자 정의 확장의 경우 9-12개월을 본다면 놀라지 마세요.
TYPO3 콘텐츠를 자동으로 마이그레이션할 수 있나요, 아니면 수동인가요?
페이지, 뉴스 레코드, 카테고리 같은 구조화된 콘텐츠? 절대 Drupal의 마이그레이션 API를 사용하여 자동화할 수 있는 일입니다. 하지만 TYPO3의 복잡한 렌더링 로직 콘텐츠는 일부 수동 작업이 필요할 수 있습니다. 대부분의 마이그레이션? 약 70-80% 자동화, 20-30% 수동입니다.
마이그레이션 중에 Google 순위를 잃을까요?
리디렉션에 주의하면 아닙니다. 모든 URL 변경에 대해 301s를 설정하고, URL 구조를 최대한 고수하고, 업데이트된 사이트맵을 즉시 제출합니다. 아마도 2-6주의 하락이 보일 것입니다. 하지만 반등은 전형적입니다. 사이트는 보통 마이그레이션 전 수준으로 반등하기까지 4-8주, 개선된 성능으로 인해 3개월 후 향상을 종종 보입니다.
Drupal은 콘텐츠 편집자에게 TYPO3보다 배우기 어렵나요?
더 어렵지는 아니고 다릅니다. TYPO3의 페이지 트리 모델에 익숙한 사람은 Drupal의 엔티티 중심 접근법에 시간이 필요할 수 있습니다. 단락 모듈은 어느 정도 유사한 콘텐츠 구축 경험을 제공합니다. 편집자와 콘텐츠 유형, 워크플로우 특정 문서에 대해 약 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개월 내에 손익분기점에 도달해야 합니다.