eCTD v4.0 전환: 한국 제약·바이오텍이 글로벌 제출 인프라를 바꾸는 90일 실행 가이드
FDA는 2024년 9월부터 eCTD v4.0을 받기 시작했고, EMA와 PMDA도 2026~2027년 의무화를 앞두고 있다. 한국 스폰서가 eCTD v3.2.2에서 v4.0으로 전환할 때 바꿔야 할 프로세스, 소프트웨어, 인력 구조를 정리한다.
왜 지금 eCTD v4.0을 준비해야 하나
eCTD(Electronic Common Technical Document)는 전 세계 규제기관이 의약품 허가 자료를 받는 표준 전자 형식이다. 2017년 FDA가 eCTD v3.2.2를 의무화한 이후, 한국 제약·바이오텍도 대부분 eCTD로 제출하고 있다. 그런데 이 구조가 v4.0으로 바뀐다.
FDA는 2024년 9월 16일부터 새로운 신청서(NDA, BLA, ANDA, IND, DMF)에 대해 eCTD v4.0 접수를 시작했다. PMDA는 2026년까지 eCTD v4.0을 의무화하겠다고 발표했다. EMA는 2024~2025년 파일럿을 거쳐 2027년경 의무화를 예고했다. 한국 식약처도 2026년부터 eCTD 제출을 단계적으로 도입하겠다고 밝혔다.
한국 스폰서가 이 전환을 미루면 세 가지 리스크가 생긴다. 첫째, 글로벌 제출이 지연된다. 둘째, 기존 v3.2.2 제출 이력을 v4.0으로 마이그레이션하는 비용이 누적된다. 셋째, 내부 RA팀과 등록 대행사(CRO) 간 업무 프로세스가 괴리된다.
이 글은 eCTD v4.0 전환을 앞둔 한국 제약·바이오텍 RA 담당자가 90일 안에 무엇을 확인하고 무엇을 바꿔야 하는지 정리한다.
eCTD v3.2.2와 v4.0의 핵심 차이
| 항목 | eCTD v3.2.2 | eCTD v4.0 |
|---|---|---|
| 구조 | 모듈별 개별 XML 백본 (M1 지역별 + M2-M5 ICH) | 단일 XML 메시지로 M1-M5 통합 |
| 문서 관리 | "Leaf" 단위로 파일 위치 고정 | "Context of Use"(COU)로 문서 목적·수명주기 관리 |
| 메타데이터 | 제한된 제어 어휘 | 제어 어휘(Controlled Vocabularies) 확대, 데이터 중심 구조 |
| 통신 | 단방향(스폰서→기관) | 양방향 메시지 기반(질의·답변 포함) |
| 라이프사이클 | 파일 단위 버전 관리 | 모듈·문서 단위 독립 업데이트 가능 |
| 중복 제거 | 동일 문서를 여러 제출에 반복 첨부 가능 | 동일 문서를 한 번만 등록하고 여러 제출에서 참조 |
가장 큰 변화는 단일 XML 백본과 Context of Use다. v3.2.2에서는 모듈마다 별도 XML 백본을 만들었지만, v4.0에서는 제출 전체가 하나의 XML 메시지로 묶인다. 이 때문에 기존 제출 소프트웨어와 내부 SOP가 상당 부분 바뀌어야 한다.
글로벌 규제기관별 eCTD v4.0 전환 일정
| 규제기관 | 현재 상태 | v4.0 의무화 예상 시점 | 비고 |
|---|---|---|---|
| FDA (미국) | 2024년 9월부터 v4.0 접수 개시 | ~2029년 예상 | 신규 신청서만 v4.0 허용. 기존 v3.2.2 제출의 forward compatibility는 아직 미지원 |
| EMA (EU) | 2024~2025년 파일럿 진행 | ~2027년 예상 | 중앙허가(CAP), 상호인정(MRP), 분산절차(DCP) 순차 적용 예정 |
| PMDA (일본) | v4.0 자발적 접수 중 | 2026년 의무화 예정 | JP 1.0에서 v4.0으로 전환. 단일 XML 백본 도입 |
| HSA (싱가포르) | 2026년 4월부터 eCTD 접수 개시 | 단계적 의무화 예정 | SG-HSA eCTD v1.1 표준 |
| MFDS (한국) | eCTD 도입 발표 | 단계적 도입 | 품목허가·변경허가 등에서 eCTD 접수 시작 예정 |
한국 기업이 미국·EU·일본에 동시 제출하는 경우, 가장 먼저 v4.0을 의무화하는 PMDA에 맞춰 준비하는 것이 현실적이다. FDA는 아직 v3.2.2와 v4.0을 병행 접수하므로 즉각적인 전환 압력은 낮지만, 2029년경 v4.0 단독 의무화가 예상되므로 미리 준비해야 한다.
한국 스폰서가 90일 안에 해야 할 일
1~30일: 현황 파악
내부 제출 현황 정리
- 현재 eCTD v3.2.2로 관리 중인 제품 목록과 제출 건수를 파악한다.
- 각 제품의 제출 이력(초회, 변경, 보충자료)을 v3.2.2 백본 구조로 정리한다.
- 사용 중인 eCTD 저작 소프트웨어(Lorenz DocuBridge, Extedo eCTD Manager, Veeva Vault RIM 등)가 v4.0을 지원하는지 확인한다.
등록 대행사(CRO)와 협의
- 글로벌 제출을 CRO에 위탁하는 경우, CRO의 v4.0 대응 현황을 확인한다.
- 기존 계약에 v4.0 전환 비용이 포함되어 있는지 점검한다.
- 전환 기간 동안 v3.2.2와 v4.0을 병행 관리할 수 있는지 합의한다.
31~60일: 파일럿 제출
신규 신청서 1건을 v4.0으로 시범 제출
- FDA의 경우 2024년 9월 이후 신규 IND나 DMF를 v4.0으로 제출할 수 있다. 가장 간단한 신청서(예: DMF 갱신)를 v4.0으로 시범 제출해본다.
- PMDA 파일럿에 참여할 수 있는지 확인한다. PMDA는 v4.0 자발적 접수 기간 동안 기술적 피드백을 제공한다.
- v4.0 제출 시 발생하는 기술적 검증(technical validation) 에러를 기록한다.
내부 SOP 개정
- eCTD 저작·검토·제출 절차를 v4.0에 맞게 개정한다.
- QA 검토 체크리스트에 v4.0 항목(Context of Use, 제어 어휘, 단일 XML 구조)을 추가한다.
- 변경관리(change control) 문서에 v4.0 전환을 기록한다.
61~90일: 전환 계획 수립
제품별 전환 로드맵 작성
| 제품 | 현재 제출 버전 | 다음 제출 예정 | 전환 시점 | 우선순위 |
|---|---|---|---|---|
| 제품 A | v3.2.2 | 2026 Q3 PMDA 변경허가 | 2026 Q3 전환 | 높음 |
| 제품 B | v3.2.2 | 2027 Q1 FDA 보충자료 | v3.2.2 유지 | 보통 |
| 제품 C | 신규 | 2027 Q2 EMA MAA | v4.0 시작 | 높음 |
인력 교육
- RA팀에 eCTD v4.0 교육을 실시한다. ICH M8 가이드라인과 각 규제기관의 지역별 M1 사양을 중심으로 학습한다.
- eCTD 저작 소프트웨어 벤더가 제공하는 v4.0 교육을 이수한다.
- CRO 담당자와 v4.0 관련 업무 분담을 재확인한다.
자주 생기는 오해
"v4.0으로 바꾸면 기존 v3.2.2 제출 이력을 다시 제출해야 하나?"
아니다. FDA는 기존 v3.2.2 제출 이력을 유지하면서 새로운 제출부터 v4.0을 받겠다는 방침이다. 다만 forward compatibility(기존 v3.2.2 제출 위에 v4.0으로 계속 제출하는 기능)는 아직 구현되지 않았다. 즉, 현재 v3.2.2로 시작한 제품은 당분간 v3.2.2로 계속 제출하고, 신규 제품부터 v4.0으로 시작하는 것이 현실적이다.
"한국 식약처도 eCTD를 의무화하나?"
식약처는 2026년부터 eCTD를 단계적으로 도입하겠다고 발표했다. 의약품 제조(수입)품목허가·신고(변경) 등에 eCTD 접수를 허용할 예정이며, 의무화 시점은 추후 공지된다. 한국 내수용 허가도 eCTD로 전환되면 글로벌 제출과 내수 제출을 동일한 시스템에서 관리할 수 있어 장기적으로 유리하다.
"소프트웨어만 바꾸면 되나?"
아니다. eCTD v4.0은 파일 구조뿐 아니라 제출 프로세스 자체를 바꾼다. Context of Use 개념을 이해하고, 제어 어휘를 올바르게 적용하고, 단일 XML 백본에서 모듈 간 관계를 관리하는 방식을 배워야 한다. SOP 개정과 교육이 반드시 병행되어야 한다.
기술 검증에서 자주 발생하는 에러
FDA의 2024~2025년 데이터에 따르면, eCTD 제출에서 가장 많이 발생하는 기술 검증 에러는 다음과 같다.
| 에러 코드 | 내용 | 원인 | 대응 |
|---|---|---|---|
| 1734 | ts.xpt 파일 누락 또는 Study Start Date 결측 | SEND 데이터 세트에서 시험 개시일 누락 | SEND 데이터 제출 전 ts.xpt 필드 검증 |
| 1735 | 표준 데이터셋에 잘못된 STF 파일 태그 사용 | define.xml 또는 dm.xpt에 부적절한 파일 태그 | 파일 태그 규칙 재확인 |
| 1736 | SEND 데이터에 DM 데이터셋 또는 define.xml 누락 | 필수 데이터 세트 미첨부 | 체크리스트 기반 사전 검증 |
이 에러들은 v3.2.2와 v4.0 모두에서 발생하지만, v4.0으로 전환하면서 제출 소프트웨어가 바뀌면 새로운 유형의 에러가 추가로 발생할 수 있다. 파일럿 제출에서 이 에러들을 미리 경험해보는 것이 중요하다.
eCTD v4.0 전환 체크리스트
- 현재 eCTD v3.2.2 관리 제품 목록 정리
- eCTD 저작 소프트웨어 v4.0 지원 여부 확인
- 등록 대행사(CRO) v4.0 대응 현황 확인
- ICH M8 가이드라인 검토
- 각 규제기관(FDA, EMA, PMDA) 지역별 M1 사양 확인
- v4.0 파일럿 제출 1건 계획
- 내부 eCTD 제출 SOP 개정
- QA 검토 체크리스트 v4.0 항목 추가
- RA팀 v4.0 교육 이수
- 제품별 v3.2.2→v4.0 전환 로드맵 수립
- 기술 검증 에러 대응 프로세스 수립
- 식약처 eCTD 도입 일정 모니터링
다음 90일 실행 순서
- 1~2주차: 현재 제출 인프라 현황 정리. 소프트웨어·CRO·내부 인력 점검.
- 3~4주차: ICH M8과 각 규제기관 v4.0 가이드라인 독해. 내부 워크숍 개최.
- 5~8주차: 파일럿 제출 1건 v4.0으로 준비. 기술 검증 통과 확인.
- 9~12주차: 제품별 전환 로드맵 확정. SOP 개정 완료. 교육 이수.
eCTD v4.0은 단순한 포맷 변경이 아니다. 제출 프로세스, 문서 관리 방식, 규제기관과의 통신 구조가 근본적으로 바뀐다. 한국 스폰서는 PMDA 의무화 시점(2026년)을 기준으로 역산해 지금 준비를 시작해야 한다.
