B.1 실험 설계의 원칙
실험은 질문에서 시작한다. 답하고자 하는 질문이 분명할수록 설계가 명료해지며, 측정해야 할 변수와 통제해야 할 변수의 구분도 쉬워진다.
독립변수·종속변수·통제변수
의도적으로 변화시키는 변수가 독립변수, 그에 따라 변화를 관찰하는 변수가 종속변수, 결과에 영향을 줄 수 있어 일정하게 유지해야 하는 변수가 통제변수이다. 실험 계획서에는 세 종류의 변수를 각각 명시적으로 기술해 두는 것이 좋다.
대조군과 무작위화
처리(treatment)의 효과를 가늠하려면 그것이 적용되지 않은 대조군과 비교해야 한다. 같은 집단을 처리 전후로 비교하는 것보다, 같은 시점의 다른 집단과 비교하는 편이 시간적 변동의 영향을 분리하기에 좋다. 대상의 배정은 가능한 한 무작위화하여, 분석 시점에 알지 못하는 잠재변수의 영향을 평균적으로 상쇄시킨다.
표본 크기와 검정력
탐지하고자 하는 효과 크기, 허용 가능한 1종·2종 오류율, 데이터의 분산을 함께 고려해야 적절한 표본 크기가 결정된다. 탐지하기에 너무 적은 표본을 쓰면 실제 효과가 있어도 놓칠 수 있고, 지나치게 큰 표본은 자원의 낭비이자 실용적으로 무의미한 차이를 통계적으로 유의하게 만들 위험이 있다.
B.2 데이터 처리와 검증
데이터는 측정된 그 순간부터 분석이 끝날 때까지 끊임없이 변형된다. 어떤 변형이 가해졌는지가 분명히 기록되어야 결과를 신뢰할 수 있다.
원자료의 보존
가장 처음의 측정값(원자료, raw data)은 그 어떤 가공도 거치지 않은 상태로 별도 보존하는 것이 원칙이다. 모든 후속 변형은 사본에 대해 수행되며, 어떤 단계에서도 원자료 파일은 덮어쓰지 않는다. 파일에는 측정 일시, 장비, 조건이 메타데이터로 포함되어 있어야 한다.
이상치 처리
이상치(outlier)를 단순히 제거하는 행위는 결과를 왜곡할 위험이 크다. 이상치로 판단되는 점이 측정 오류인지, 모형이 설명하지 못하는 실제 현상인지를 별도로 검토해야 하며, 어느 쪽이든 제외 기준을 사전에 정해 두고 분석 보고서에 명시적으로 기술해야 한다.
단위와 좌표계 검증
과학·공학의 현장 사고는 단위 혼동에서 비롯되는 경우가 적지 않다. SI 단위를 일관되게 사용하고, 수치 계산 도중 단위를 함께 끌고 가는 습관(예: 차원 해석)은 단순하면서도 강력한 자기 검증 도구이다. 좌표계나 부호 규약 역시 문서 전체에서 일관해야 한다.
B.3 분석 워크플로
분석은 한 번의 작업이 아니라 반복 가능한 워크플로로 구성하는 것이 바람직하다. 각 단계의 입력과 출력을 코드와 파일로 명시함으로써, 같은 결과를 누구나 재생산할 수 있게 만든다.
탐색적 데이터 분석
분석에 앞서, 데이터의 분포·결측·이상치·상관 구조를 그래프와 요약 통계량으로 살펴보는 단계를 둔다. 이 단계의 목적은 결론을 내는 것이 아니라, 본 분석에서 어떤 가정이 합리적인지를 판단할 정보를 얻는 것이다. 성급하게 모형을 적용하기 전에 데이터를 충분히 들여다보는 습관이 후속 오류를 줄여 준다.
모형 적합과 진단
모형을 적합한 다음에는 잔차 분포, 적합도 통계량, 영향력 큰 관측치 등 모형 진단(model diagnostics)을 반드시 수행한다. 같은 R²라도, 잔차가 무작위로 흩어져 있는 모형과 체계적인 패턴을 남기는 모형은 신뢰도가 전혀 다르다. 진단 결과가 만족스럽지 않다면 변수 변환, 모형 구조 수정, 더 일반적인 모형으로의 교체를 고려한다.
불확정도의 전파
측정량을 조합해 다른 양을 계산할 때, 입력의 불확정도가 출력에 어떻게 전파되는지를 함께 계산해야 한다. 선형 근사의 오차 전파 공식, 몬테카를로 시뮬레이션이 일반적인 도구이다. 최종 결과는 항상 추정치와 함께 합리적인 신뢰구간 또는 표준 불확정도를 동반해야 한다.
B.4 재현성과 기록
실험과 분석은 다른 연구자(또는 미래의 자신)가 같은 단계를 따라 같은 결과에 도달할 수 있을 때 비로소 완성된다. 재현성은 결과의 진위뿐 아니라 그 결과를 만든 과정 전체의 투명성을 요구한다.
실험 노트와 버전 관리
측정과 분석의 모든 결정은 실험 노트(또는 디지털 실험 노트)에 시간 순서대로 기록한다. 분석 코드는 Git 같은 버전 관리 시스템에 보관하고, 결과 그림이나 표는 어떤 커밋의 어떤 코드로 생성되었는지를 함께 남긴다.
의존성 명시
분석에 사용된 프로그래밍 언어, 라이브러리, 운영체제의 버전을 명시해야 한다. 같은 코드라도 라이브러리 버전이 다르면 수치 결과가 미세하게 달라질 수 있으며, 그 차이가 결론에 영향을 줄 수 있다. 도커 컨테이너, 가상 환경, lock 파일 같은 도구가 이 문제를 줄여 준다.
공개와 재사용
가능한 한 데이터, 코드, 분석 노트를 공개 저장소에 함께 올리는 것이 재현 가능성과 과학 공동체에 대한 기여 측면에서 권장된다. 민감한 데이터의 경우, 익명화와 접근 통제를 거친 뒤 메타데이터와 분석 스크립트만이라도 공개하는 것이 차선책이 된다.
본 부록의 내용은 일반론에 가깝다. 분야마다 측정 장비, 표준 절차, 보고 양식이 다르므로, 실제 실무에서는 해당 분야의 표준 문서와 학회 가이드라인을 반드시 함께 참고하기를 권한다.