담당 업무와 책임 범위
수집 데이터의 의미와 매핑·도출 규칙을 확인합니다. 변수 이름을 표준에 맞추는 작업과 분석 질문에 맞는 자료를 만드는 작업은 다르므로 정의와 근거를 연결합니다.
검증에서 발견된 차이가 코드·사양·통계적 의사결정 중 어디에서 생겼는지 구분합니다. 불명확한 규칙을 편의상 결정해 분석 결과에 숨기지 않고 해당 책임자에게 확인합니다.
최종 패키지에는 데이터·프로그램·출력·메타데이터·검증과 버전의 관계를 남깁니다. 변경 시 관련 본문·결과·다른 데이터에 미치는 영향과 재전달을 관리합니다.
현장에서 쓰는 말
현장에서는 영어 약어를 그대로 쓰는 경우가 많아요. 메일·회의·문서에서 이 직무가 자주 듣는 말을 정리했어요.
| 용어 | 뜻 | 이 직무에서는 |
|---|---|---|
| SDTM / ADaM | 제출용 / 분석용 데이터 표준 | CDISC 표준 데이터셋 작성 |
| Define-XML | 데이터 정의서 | 데이터셋·변수 설명 제출 문서 |
| Spec | 프로그래밍 사양서 | 데이터셋·TLF 작성 기준 |
| Double programming | 독립 이중 프로그래밍 | 두 사람이 따로 만들어 결과 대조(QC) |
| Pinnacle 21 | 데이터 표준 검증 도구 | SDTM·ADaM 적합성 확인 |
| Dry run | 사전 실행 | DB lock 전 가자료로 TLF 미리 돌려보기 |
| Validation log | 검증 기록 | 이중 프로그래밍 대조 결과와 수정 이력 기록 |
| Macro | 공통 프로그램 | 반복되는 TLF 작성용 재사용 코드 |
| Traceability | 추적 가능성 | 원자료→SDTM→ADaM→TLF 연결이 보이게 작성 |
하루 업무는 어떻게 흘러가나요?
하루는 원천 자료와 사양을 확인하고 변환·도출·TFL 프로그램을 작성·실행·검토하는 작업으로 구성될 수 있습니다. 통계 프로그래머(Statistical Programmer)는 코드 실행뿐 아니라 사양의 모호함과 자료의 예외를 찾아 STAT·DM과 해결합니다. 의도하지 않은 필터·중복·결측 처리와 분모 차이가 없는지 살핍니다.
한 달 단위로 살펴볼 일
월 단위로 분석 일정·자료 갱신·표준 라이브러리·독립 검증·사양 변경을 조율합니다. 잠정·중간·최종 산출물의 범위와 자료 기준일을 구분하고 반복 실행의 차이가 자료 변경인지 코드·사양 변경인지 설명합니다. 검토 이슈와 해결 근거를 남겨 최종 패키지의 재현성을 확보합니다.
시험 단계별로 달라지는 업무
- 준비 · 표준·사양·개발 환경 준비
- 수행 · 변환·분석 프로그램 개발·검증
- 종료·후속 · 최종 출력물·패키지 전달
| 단계 | 업무 | 인계할 근거 |
|---|---|---|
| 준비 | 표준·사양·개발 환경 준비 | 범위·정의·선행 조건·승인된 계획 |
| 수행 | 변환·분석 프로그램 개발·검증 | 실제 수행·중요 변경·미결과 결정 |
| 종료·후속 | 최종 출력물·패키지 전달 | 최종 산출물·제한·보관·후속 책임 |
주로 쓰는 시스템과 자료
SAS·R과 버전 관리·이슈 추적·배치 실행 도구 등을 사용합니다. 표준 검증 도구와 메타데이터 관리 환경을 함께 쓰기도 합니다. 자료·코드·라이브러리·실행 환경·로그·출력 식별을 연결하고 비눈가림 프로그램과 출력에 대한 접근을 통제합니다.
대표 산출물·관리 자료
- 데이터셋·메타데이터
- 분석 프로그램
- TFL·검증 기록
다른 직무와 무엇을 주고받나요?
DM에서 전달된 데이터와 STAT의 분석 계획을 기반으로 협업한다.
| 상대 직무·조직 | 주고받는 자료 | 전달할 때 중요한 내용 |
|---|---|---|
| STAT | SAP·도출 사양·목업·질문 | 분석 정의·예외·분모·표시의 확정 |
| DM·표준 담당 | 원천·SDTM·변환·결측 정보 | 매핑과 추적성·예상치 못한 자료 패턴 |
| 독립 검증자·MW | 프로그램·검증 기록·TFL | 재현·불일치 해결·본문과 출력 일치 |
실무에서는 이렇게 나누어 운영해요
같은 업무라도 회사와 시험 규모에 따라 운영 방식이 갈려요. 많이 쓰는 방식을 비교하면 이렇습니다.
| 운영 방식 | 구체적인 모습 | 장점 | 주의할 점 |
|---|---|---|---|
| 이중 프로그래밍 | 별도 구현 결과를 비교합니다. | 독립적인 계산 검증에 유리합니다. | 같은 사양 오해가 공유될 수 있어 의미 검토도 필요합니다. |
| 코드 검토·표적 검증 | 코드와 중요한 도출을 집중 검토합니다. | 위험과 복잡도에 맞춰 자원을 씁니다. | 검토 범위·근거·표본의 한계를 명확히 합니다. |
| 표준 프로그램 활용 | 공통 도출과 표 형식을 재사용합니다. | 일관성과 반복 실행 효율을 높입니다. | 시험별 예외와 라이브러리 변경을 검증해야 합니다. |
실무에서 작업을 풀어가는 방법
자료를 처음 받는 방법
파일 식별·관측 범위·변수 구조·형식·중복·결측과 이전 판 차이를 확인합니다. 예상과 다른 패턴은 원천 오류인지 사양의 전제 문제인지 구분해 질의합니다. 데이터를 보기 좋게 만들려고 행을 임의 삭제하거나 값의 단위를 추정하지 않으며 분석에 쓰인 입력본을 실행 기록과 연결합니다.
도출을 구현하는 방법
사양의 입력·조건·우선순위·예외를 작은 예시 자료로 확인한 뒤 전체에 적용합니다. 방문 창·기준값·재검사 선택·집단과 분모가 계획과 맞는지 검토합니다. 코드 주석만으로 분석 결정을 대신하지 않고 변경된 정의를 사양과 연결하여 다른 프로그램과 검증자도 같은 근거를 사용할 수 있게 합니다.
검증과 출력 배포를 하는 방법
로그·자료 비교·독립 구현·표적 검토 등 계획된 방법을 적용하고 발견과 해결을 기록합니다. 숫자 일치 외에 제목·주석·단위·집단·자료 기준을 봅니다. 잠정 출력과 승인된 최종 출력을 구분하고 누구에게 어떤 범위를 배포했는지 관리합니다. 비눈가림 결과가 불필요한 운영 담당자에게 퍼지지 않게 합니다.
이런 상황이라면 어떻게 진행할까요?
가상의 분석에서 같은 방문의 검사 결과가 여러 행 존재해 집계 분모가 예상과 달라졌습니다. 프로그래머는 원천 식별과 조인·선택 규칙을 확인하고 STAT에 모호한 재검사 선택 사양을 질의합니다. 결정된 규칙을 사양과 코드에 반영하고 독립 검증자가 예시와 전체 출력의 일치를 확인합니다. 숫자만 맞추려고 중복 행을 임의 삭제하지 않습니다.
처음 맡으면 어디서 막히나요?
처음에는 로그 오류가 없으면 결과도 맞다고 생각하기 쉽습니다. 조인으로 생긴 행 증가·중복 제거·결측의 비교·분모·기준값 선택을 실제 예시 자료로 검토해야 합니다. 모호한 사양을 임의로 해석해 코드에 숨기지 말고 질의와 결정 기록으로 연결합니다.
필요한 역량
SAS·R 등 구현, CDISC·메타데이터·도출, 검증·재현성과 버전 관리
어떤 경력으로 이어질 수 있나요?
시험 프로그래밍에서 표준·검증·자동화·프로그램 리드·자료 엔지니어링으로 확장할 수 있습니다. 통계 직무로 이동하려면 별도의 방법론과 설계 역량이 필요할 수 있습니다. 언어 문법 외에 임상 자료·분석 목적·추적성과 재현성의 경험이 중요합니다.
실무에서 자주 묻는 질문
코드가 실행되면 검증이 끝인가요?
실행 성공은 의미와 결과의 적절성을 보증하지 않습니다. 사양 일치·원천 추적·분모·도출·예외와 출력의 해석을 검토해야 합니다.
SAP가 모호하면 알아서 구현하나요?
통계 판단과 수집 정의가 필요한 부분은 관련 책임자에게 질의합니다. 결정과 이유를 남겨 다른 분석과 보고서에도 일관되게 반영합니다.
최종 출력 파일만 보관하면 되나요?
사용 자료·사양·코드·환경·실행과 검증 근거를 연결해야 재현할 수 있습니다. 최종 출력이 어느 조합에서 생성되었는지 식별 가능하게 보존합니다.
인계 전에 확인하세요
- 담당 범위와 승인·상향 경로가 명확한가
- 자료·문서·시스템의 사용본과 접근을 확인했는가
- 중요 위험·미결·다음 조치의 담당자가 있는가
- 종료·보관·후속 책임이 끊기지 않는가
인계할 때는 파일 위치만 넘기지 말고 미결 이슈, 그렇게 결정한 이유, 다음에 확인할 일을 한 장으로 정리해 넘기세요. 그래야 새 담당자가 같은 질문을 다시 하지 않고, 의뢰자나 실시기관에도 같은 설명을 반복하지 않게 돼요.