SDTM 구축을 위한 SAS와 R의 절차를 단계별로 비교합니다. 전처리·매핑·검증·제출까지 실무 체크리스트 제공.
SDTM을 위한 SAS와 R의 절차적 활용 완벽 가이드
— 원천 데이터에서 XPT v5, 검증(P21), 제출 문서까지 단계별 비교
왜 ‘절차’가 모든 것을 좌우하는가
임상시험 데이터 표준화는 단순 변환이 아닙니다. 프로토콜–CRF 설계–데이터 수집–표준 매핑–검증–제출 문서화까지 잇는 전 과정 관리입니다. 규제기관(FDA 등)은 **SDTM(Study Data Tabulation Model)**과 같은 표준 준수를 요구하며, 성공 여부는 “어떤 언어를 쓰느냐”보다 **“절차가 얼마나 견고하고 재현 가능한가”**에 달려 있습니다. 본 글은 SAS와 R을 각각 선택했을 때의 실제 진행 절차를 단계별로 설명하고, 혼합 전략까지 제시해 현업 적용성을 극대화합니다.
1. 전체 로드맵(10단계) – SAS와 R 공통 프레임
- 프로젝트 세팅: 폴더·명명 규칙·접근권한·메타데이터 저장소 설계
- 원천 데이터 수집·적재: EDC/CSV/DB 추출, 수집 사양과 데이터 카탈로그 정비
- 전처리 표준화: 식별자(USUBJID), 날짜/시간(ISO 8601), 단위·코드 일치
- 매핑 스펙 수립: 도메인별 변수·파생 규칙·값수준 메타데이터(VLM) 정의
- 도메인 생성: DM/AE/LB/CM/EX 등 주요 도메인 작성
- 보조 도메인/관계: SUPPxx(로컬 변수), RELREC(도메인 간 링크), CO/TV/TS 등
- CT(Controlled Terminology) & 품질 사전점검: 용어 일치·논리 검증
- 제출 포맷 생성(XPT v5): 길이·라벨 등 포맷 제약 충족
- 검증(Validation): Pinnacle 21 등 검증 도구 실행·오류 수정 루프
- 제출 패키징: define.xml, SDRG(Reviewer’s Guide), aCRF, 로그·버전 문서화
이제 각 단계에서 SAS 중심 절차와 R 중심 절차를 나란히 비교합니다.
2. 프로젝트 세팅: 거버넌스와 재현성의 기초
SAS 중심
- **표준 운영 절차(SOP)**와 사내 표준 매크로/템플릿을 초기 로딩 절차에 포함합니다.
- 폴더 구조(원천/메타/중간/결과/검증/문서)를 조직 표준에 맞춰 고정하고, 로그·감사 추적 경로를 분리합니다.
- Clinical Standards Toolkit(CST) 또는 조직의 레거시 템플릿을 기준으로 도메인 기본 골격(필수 변수·라벨 규칙·데이터 타입)을 일관화합니다.
- 접근권한(읽기/쓰기/승인)과 변경관리(Change Control) 문서를 사전에 배포합니다.
R 중심
- 재현성이 핵심입니다. 패키지 버전 고정(예: 패키지 록 파일), 파이프라인 러너 도입, 실행 환경(서버/컨테이너) 표준화를 초기 단계에서 확정합니다.
- 메타데이터 주도 개발(MDD): 메타데이터(도메인 사양, 변수, 라벨, 값수준 규칙)를 단일 저장소(Excel/CSV/JSON/DB)에 보관하고, 모든 단계가 이를 참조하도록 설계합니다.
- 데이터·문서·검증 로그의 영속 보관 경로를 정하고, 배포 권한(승인 후 배포 구조)을 명문화합니다.
공통 포인트: 프로젝트 시작 미팅에서 표준 버전(SDTM IG, CT 릴리스), 용어/코딩 사전(MedDRA/WHO-DD), 타임존/날짜 처리 기준, 명명 규칙을 확정합니다.
3. 원천 데이터 수집·적재: 카탈로그와 스키마 정합성
SAS 중심
- EDC/DB/CSV 등 **원천 스키마를 인벤토리(데이터 카탈로그)**로 문서화합니다.
- 임시 영역으로 적재 후 형식·결측·코딩 상태를 스크리닝합니다.
- 동일 변수라도 스터디/사이트별 포맷 차이를 표준 포맷 라이브러리로 강제 정렬합니다.
R 중심
- 데이터 카탈로그를 테이블 사전(필드명·타입·도메인 매핑 후보) 형태로 정리합니다.
- 적재 즉시 타입 캐스팅 규칙(문자↔숫자, 날짜 문자열)을 적용하고, 다국어 인코딩/특수문자 이슈를 체크리스트로 처리합니다.
- 메타데이터 저장소와 자동 동기화(필요 변수 누락, 타입 불일치 알림)를 걸어 둡니다.
공통 포인트: 데이터 소유자(EDC·벤더)와 데이터 전달 주기/버전/변경 알림 절차를 계약 수준에서 명확히 합니다.
4. 전처리 표준화: 식별자·시간·단위
SAS 중심
- USUBJID 생성 규칙(사이트-피험자 결합)을 SOP로 고정합니다.
- 날짜/시간을 ISO 8601로 변환하고, 불완전 날짜(YYYY-MM/—) 처리 방침을 문서화합니다.
- 단위 변환 표(예: SI 변환)를 도입해 LB/VS 등 측정값 표준화를 체계화합니다.
- 결측 코드 규칙(N/A, UNK 등)과 표시 정책을 일괄 적용합니다.
R 중심
- 동일 원칙을 따르되, 파이프라인 단계에 전처리 표준화 태스크를 고정하여 항상 같은 결과가 나오도록 합니다.
- 유효성 규칙(날짜 역전 금지, 범위 제한, 코드 목록 일치)을 전처리 단계에 붙여 초기 오류를 조기 차단합니다.
공통 포인트: 전처리에서 만든 표준화 규칙 문서는 이후 매핑/검증/리포팅 전 과정의 기준이 됩니다.
5. 매핑 스펙 수립: 도메인별 단일 진실 소스
SAS 중심
- 사내 표준 매핑 스펙 템플릿(보통 Excel 기반)에 다음을 기록합니다:
- 도메인(DM/AE/LB/CM/EX 등)
- 변수 속성(이름, 라벨, 타입, 길이, 역할)
- 필수/권장/허용 구분
- 파생 규칙(조건·계산식·출처)
- VLM(테스트 코드·단위·허용범위)
- CT 매핑 규칙(코드 리스트/용어 사전)
- 승인 프로세스(작성→리뷰→승인)를 운영해 변경 이력을 관리합니다.
R 중심
- 동일 정보를 메타데이터 저장소(Excel/CSV/DB)로 중앙화하고, 파이프라인이 이 저장소를 직접 참조합니다.
- 이렇게 하면 스펙이 바뀌면 코드가 아니라 메타데이터를 고치고 재실행만으로 전체가 갱신됩니다.
핵심: 매핑 스펙은 도메인 생성의 청사진입니다. 어떤 언어든 스펙이 먼저이며, 코드는 스펙의 실행 수단일 뿐입니다.
6. 도메인 생성: DM/AE/LB 등 핵심부터
SAS 중심
- 조직 표준에 따라 **핵심 도메인(DM/AE/LB)**을 우선 완성합니다.
- 순번 변수(예: –SEQ) 부여 규칙, **키 조합(USUBJID+SEQ)**의 유일성 관리, 불완전 날짜 처리 등을 SOP대로 일관 적용합니다.
- 코딩 사전(MedDRA·WHO-DD) 조인으로 표준 용어(예: AEDECOD, AESOC)를 채웁니다.
R 중심
- 동일 우선순위로 도메인 생성 순서를 정하고, 파이프라인에 태스크로 분해하여 병렬/증분 실행이 가능하도록 설계합니다.
- 값 파생 로직은 가독성 높은 단계 분리(정제→파생→정렬→키 부여)로 나누어, 리뷰가 쉬운 산출 로그를 남깁니다.
- 코딩 사전 매핑 결과의 버전·릴리스를 메타데이터에 기록해, 변경 시 영향 분석이 가능하도록 합니다.
공통 포인트: 도메인 생성 직후 도메인별 필수 변수 점검, 키 유일성 검사, 날짜 논리 검사를 바로 시행하여 오류를 조기에 발견합니다.
7. 보조 도메인·관계: SUPPxx, RELREC, CO 등
SAS 중심
- 표준 SDTM에 없는 로컬 변수는 SUPPxx로 분리해 QNAM/QVAL 구조로 관리합니다.
- 도메인 간 인과/동시성 관계는 RELREC에 RELID/IDVAR/IDVARVAL 형태로 연결합니다.
- 코멘트/특수 케이스는 CO에 기록해 리뷰어가 이해할 수 있는 맥락을 제공합니다.
R 중심
- 동일 원칙을 따르며, SUPPxx·RELREC 생성 규칙을 메타데이터 기반으로 자동화합니다.
- 관계 정의는 테이블로 선언(예: AE–EX 링크 규칙)해 스크립트 변경 없이 확장 가능하게 유지합니다.
핵심: 보조 도메인/관계는 리뷰어에게 데이터 해석의 다리를 놓습니다. 누락되면 리뷰 시간이 늘고 리스크가 커집니다.
8. CT·VLM·사전 품질 점검: 오류는 초기에, 규칙은 중앙에서
SAS 중심
- CT(컨트롤드 텀) 리스트와 매칭 실패 항목을 리스트업하고, 스폰서/벤더와 정합성 회의를 운영합니다.
- VLM(값수준 메타데이터): 테스트 코드에 따라 허용 단위/범위가 달라지는 규칙을 적용하고, 예외 목록을 관리합니다.
- 사전 점검 매크로로 필수 변수·타입·길이·코드 일치·날짜 논리를 일괄 체크합니다.
R 중심
- 동일 체크를 파이프라인 태스크로 넣어, 매 실행마다 자동 보고서가 생성되도록 합니다.
- 실패 항목은 이슈 트래킹(티켓)으로 생성해 담당자·기한·해결 로그를 연결합니다.
공통 포인트: CT/VLM 정합성은 규제 검증의 핵심입니다. *“경고니까 괜찮겠지”*가 아니라, 왜 경고가 났는지, 위험은 없는지를 문서화하세요.
9. 제출 포맷 생성(XPT v5): 제약 준수 체크리스트
언어와 무관하게 SAS XPORT v5 형식으로 내보낼 때 준수해야 할 핵심 제약은 다음과 같습니다.
- 변수명·라벨 길이 제한 준수
- 문자 인코딩 일관성
- 데이터 타입/길이 적합성
- 도메인 단위 파일 분리 및 명명 규칙 준수
- 필수 변수 누락 없음
- 키 유일성 확인(USUBJID+SEQ 등)
SAS 중심
- 제출 포맷 산출은 전통적으로 안정적입니다. 포맷 제약 사전점검을 빌드 단계에 포함하고, 내보내기 결과에 대해 샘플링 확인(라벨/길이/누락)을 문서화합니다.
R 중심
- 동일 제약을 자동 검사 태스크로 넣고, 위반 시 빌드를 실패 처리해 재현 가능한 품질 장벽을 세웁니다.
- 산출 파일의 해시/체크섬을 기록해, 재생성 시 동일성을 보증합니다.
10. 검증(Validation)과 개선 루프: Pinnacle 21 중심
절차(언어 공통)
- 검증 실행: SDTM 규칙 세트 적용(프로젝트 착수 시점에 버전 고정)
- 결과 분류: Error/Warning/Notice를 유형별로 묶고 영향 분석
- 원인 추적: 스펙 오류 vs. 데이터 품질 vs. 변환 로직
- 수정·재실행: 수정 내역 기록, 동일 버전 규칙으로 재검증
- 리포트 보관: 검증 리포트, 실행 로그, 규칙 버전, 데이터 버전(스냅샷) 저장
SAS 중심
- 검증 전·후로 사내 매크로 점검 리포트를 함께 보관하여 감사 추적을 강화합니다.
- 변경관리 위원회(CCB)가 Error/Warning 처리 방침을 문서로 승인합니다.
R 중심
- 검증 실행을 파이프라인 단계에 고정, 실행 때마다 리포트가 버전별로 축적됩니다.
- 실패 기준을 정책화(특정 Warning 이상은 빌드 실패)하여 품질 기준을 자동으로 강제합니다.
11. 제출 패키징: define.xml·SDRG·aCRF·로그
필수 산출물(조직에 따라 가감 가능)
- XPT v5 파일(도메인별)
- define.xml(변수 정의/출처/파생/VLM/메타데이터)
- Study Data Reviewer’s Guide(SDRG)(데이터 특이사항, 처리 방침, 검증 이슈 설명)
- Annotated CRF(aCRF)(CRF 필드 ↔ SDTM 변수 매핑)
- 검증 리포트·실행 로그(버전·날짜·담당자)
SAS 중심
- define.xml/SDRG 템플릿을 기존 자산과 연동하여 자동 채움 비율을 높입니다.
- 마지막 단계에서 **수작업 메모(Assumption, Known Issue)**를 정리해 리뷰어의 이해를 돕습니다.
R 중심
- 메타데이터 저장소를 싱글 소스로 삼아 define.xml 초안을 자동 생성하고, 전문 저작 도구로 마감 품질을 끌어올립니다.
- SDRG·aCRF 역시 템플릿 자동 채움 → 편집 검수 과정을 확립합니다.
공통 포인트: 제출 직전, 표준·규칙 최신판과의 일치 여부를 체크리스트로 재검토하고, 패키지 전체를 버전 태깅하여 보관합니다.
12. SAS vs R 절차 비교 요약(한눈에)
| 구분 | SAS 중심 절차 | R 중심 절차 |
| 초기 세팅 | SOP·레거시 템플릿·CST 로딩 | 재현성/파이프라인·메타데이터 싱글소스 |
| 원천 적재 | 포맷·라이브러리 표준화 | 타입/인코딩 자동 스크리닝·카탈로그 동기화 |
| 전처리 | USUBJID/ISO8601/단위 표준 | 동일 + 자동 유효성 체크 태스크 |
| 매핑 스펙 | Excel 템플릿 중심 승인 절차 | 메타 저장소 직접 참조(변경→재실행) |
| 도메인 생성 | 핵심부터 순차·SOP 일관성 | 태스크 분해·병렬/증분 실행 가능 |
| SUPP/RELREC | 표준 규칙 문서화·관계 테이블 | 메타기반 선언·확장성 우수 |
| CT/VLM 점검 | 사내 점검 리포트 + 회의체 | 자동 보고서·티켓 연동 |
| XPT v5 | 전통적으로 안정·샘플링 검수 | 제약 자동검사·해시 기록 |
| 검증 루프 | 리포트+로그 보관·CCB 승인 | 실패 기준 정책화·자동 차단 |
| 제출 문서 | 템플릿 자동채움 + 수기 보완 | 메타 싱글소스 → 초안 자동 생성 |
13. 혼합 전략: 현실적이고 탄탄한 길
- 데이터 변환·리포팅은 R의 자동화·재현성 이점을 활용
- 최종 검증·특정 제출 산출은 SAS/전용 도구와 병행
- 메타데이터/용어집은 언어 중립 포맷으로 중앙화
- **병행 운영(Parallel Run)**으로 일정 기간 동일 결과를 도출해 리스크를 낮춘 뒤 점진 전환
이 전략은 인력 스킬 분포, 벤더 협업 구조, 시스템 레거시를 고려했을 때 가장 마찰이 적고, 감사 대응에서도 유리합니다.
14. 실무 체크리스트
공통
- SDTM IG/CT 버전, 사전(MedDRA/WHO-DD) 버전 고정
- USUBJID 생성 규칙·타임존·불완전 날짜 처리방침 문서화
- 매핑 스펙(변수·파생·VLM) 승인 라우팅 구축
- 키 유일성, 날짜 논리, 필수 변수 존재 검사
- 검증 규칙 버전·검증 리포트 보관 정책
- define.xml/SDRG 템플릿, aCRF 완성도 점검
SAS 전용
- 레거시 템플릿·CST 최신화 주기 운영
- 표준 포맷 라이브러리/매크로 배포 관리
- Error/Warning 처리방침 CCB 승인 기록
R 전용
- 파이프라인(전처리→매핑→검증→출력) 자동화
- 메타데이터 싱글소스 관리·버전 태깅
- 빌드 실패 기준(경고 등급) 정책화
15. 자주 묻는 질문(FAQ)
Q1. R만으로 SDTM 제출이 충분한가요?
A. 가능합니다. 제출 성공의 본질은 표준 준수(구조·용어·포맷)와 검증 통과에 있습니다. 다만 조직의 SOP·감사 관행, 벤더·파트너 생태계에 따라 혼합 전략이 더 현실적일 수 있습니다.
Q2. define.xml은 어떻게 관리하나요?
A. 메타데이터를 싱글 소스로 두고 초안을 자동 생성한 다음, 전용 저작 도구나 템플릿으로 마감 품질을 확보하세요. 변경 이력(변수 추가/라벨 변경/출처 수정)을 버전으로 관리하는 것이 핵심입니다.
Q3. CT 경고는 어느 수준까지 허용되나요?
A. 규정 위반이 아니더라도 리뷰어 혼동을 줄이기 위해 가능하면 경고도 해소하세요. 해소 불가 사유는 SDRG에 명확히 기록하고 데이터 영향(안전성/유효성 해석)에 대한 언급을 포함해야 합니다.
Q4. 병행 운영(Parallel Run)은 얼마나 해야 하나요?
A. 최소 한 사이클(중간 데이터컷→최종 데이터컷) 이상 권장합니다. 동일 결과 재현을 통해 전환 리스크와 교육 비용을 낮출 수 있습니다.
16. 언어보다 중요한 것
- SAS는 안정적이고 규제 친화적인 절차와 레거시 자산이 강점입니다.
- R은 재현성과 자동화, 비용 효율에서 강력합니다.
- 그러나 진짜 성공 요인은 언어가 아닌 절차입니다.
- 명확한 매핑 스펙
- 일관된 전처리·CT·VLM 적용
- XPT v5 제약 준수
- 검증-수정-재검증 루프
- define.xml/SDRG 등 문서화 완결성
현업에서는 혼합 전략으로 두 세계의 장점을 결합하는 사례가 늘고 있습니다. 오늘 제시한 절차·체크리스트를 기반으로, 팀의 역량·일정·규제 요건에 맞는 현실적 로드맵을 바로 설계해 보세요.
'세상만사 관심 > 기술' 카테고리의 다른 글
| 반도체 제조 공간과 설비 구축 과정 (3) | 2025.11.18 |
|---|---|
| AI의 수도 한국 (3) | 2025.11.11 |
| KF-21 블록 3 해설 (3) | 2025.11.04 |
| AI 시대의 데이터 백업 기술 혁신 (1) | 2025.11.04 |
| 반도체 유리기판 (5) | 2025.10.30 |