3  재현가능한 연구

앞 장에서 살펴본 HWP 생태계의 구조적 문제와 재현성 위기는 단순한 도구의 문제가 아니라 연구 패러다임의 문제다. 이제 그 해법인 재현가능 연구(reproducible research)를 구체적으로 살펴보자.

재현가능 연구(reproducible research)는 다른 연구자들이 동일한 데이터와 과정을 통해 원래 연구 결과를 재현할 수 있게 하는 것을 목표로 한다. 이를 위해서 독립적인 과학기술 연구자들이 같은 조건, 재료, 절차를 사용해 원래 연구 결과를 재현하거나 재창조하고 일관된 결과를 얻어야 한다. 연구와 관련된 모든 데이터, 문서, 코드, 작업흐름은 철저히 문서화되어 있어야 하며, 문서를 통해 다른 연구자들이 연구를 재현할 수 있어야만 된다. 따라서, 연구 참여자들은 자신(미래의 본인 포함)과 타 연구자들을 위해 자세하고 구체적인 문서를 작성하는 것이 필요하다. 과학기술 연구 과정에서 이루어진 모든 단계는 다른 연구자가 이해할 수 있고, 컴퓨터가 실행할 수 있는 형태로 명확히 기술되어야 한다.(Curty 기타, 2024) 1

3.1 재현성의 중요성

미국 국립과학재단(NSF) 과학분야 복제 가능성(replicability) 소위(2015)에 따르면, 과학은 출판된 문헌형태로 중요한 역할이 기대되는 발견에 대해 재현가능성을 정기적으로 평가해야 한다. 재현을 가능하고(possible), 효율적(efficient), 유익하게(infromative) 만들기 위해, 연구자들은 데이터 수집, 관찰한 결과를 분석 가능한 데이터로 변환,데이터 분석에 사용된 절차 세부사항을 충분히 문서화해야만 한다.

재현성은 원래 연구자가 동일한 재료를 사용하여 이전 연구 결과를 복제할 수 있는 능력으로 볼 수 있다. 다시 말해, 다른 연구자가 원본 데이터와 동일한 분석 파일을 사용하고 같은 통계 분석을 수행하여 동일한 결과를 도출할 수 있어야 한다. 재현성은 과학적 발견이 엄격하고 신뢰할 수 있으며 유익한 것으로 간주되기 위한 최소한의 필요 조건이다.

노트HWP 생태계가 만든 재현성 장벽

기존 HWP 환경의 한계: - 실험 수행방법과 데이터 생성 과정에 대한 상세한 문서화 부족 - 연구에서 원래 결과를 도출하기 위해 사용된 데이터에 접근 불가능 - 결과를 만들어낸 원본 소프트웨어 접근 불가능 (연간 630만원 라이선스) - 원본 결과를 생성할 때 사용된 소프트웨어 환경(패키지, 버전) 재현 어려움 - 바이너리 파일 형식으로 인한 버전 관리 불가능 - 국제 협업 시 파일 호환성 문제

문서 코드화의 해법: - 모든 분석 과정이 코드로 기록되어 완전한 투명성 확보 - 플레인 텍스트 기반으로 Git 버전 관리 가능 - 무료 오픈소스 도구로 경제적 부담 해결 - 국제 표준 형식으로 글로벌 협업 지원

3.2 재현성, 복제성, 강건성, 일반화

재현성(reproducibility)은 최소한의 요구 사항으로, “충분히 좋은” 컴퓨팅 방식으로 해결될 수 있다. 하지만, 과학적 발견에 대한 복제성(replicability)/강건성(robustness)/일반화(generalizability)는 연구 부정 행위, 의심스러운 연구 관행(p-해킹2, HARKing3, 선별 취사4), 부주의한 방법론, 기타 의식적 또는 무의식적 편향을 포함하여 더 큰 우려사항이다.

그림 3.1: 재현성(reproducibility), 복제성(replicability), 강건성(robustness), 일반화(generalizability)
  • 재현성(reproducibility): 동일한 데이터에 동일한 분석 단계를 수행했을 때 일관되게 같은 답이 나오면 그 결과는 재현 가능한 것으로 간주한다.
  • 복제성(replicability): 서로 다른 데이터에 동일한 분석을 수행했을 때 유사한 결과을 얻을 수 있다면, 그 결과는 복제성이 있는 것으로 간주한다.
  • 강건성(robustness): 동일한 데이터을 다른 분석 절차(예를 들어, R 파이프라인과 Python 파이프라인)에 적용하여 같은 연구 질문에 대한 유사하거나 동일한 답을 얻을 수 있다면, 그 결과는 견고한 것으로 간주한다. 견고한 결과는 작업이 특정 프로그래밍 언어의 특수성에 의존하지 않는다는 것을 반증한다.
  • 일반화(generalizability): 복제성과 강건함 결합함으로써 일반화된 결과를 도출할 수 있다. 다른 소프트웨어 구현과 다른 데이터셋을 사용한 분석이 일반화된 결과를 제공하지 않는다는 점에 유의한다. 연구 질문의 다양한 측면에 대해 작업이 얼마나 잘 적용되는지를 알기 위해서 훨씬 더 많은 단계를 필요로 한다. 일반화는 결과가 특정 데이터나 분석 파이프라인 버전에 의존하지 않는다는 것을 이해하는 데 중요한 단계다.

만약 그동안의 논의가 충분히 설득력이 없다고 느껴진다면, 마코베츠(Markowetz, 2015)가 제시한 ‘재현가능한 작업을 해야 하는 이기적인 이유’ 다섯 가지를 문서 코드화 맥락에서 살펴보자:

  1. 데이터 손실과 재난 방지: Git으로 버전 관리되는 플레인 텍스트는 백업과 복구가 용이하다. HWP 파일이 깨져도 텍스트 파일은 언제나 복구 가능하다.

  2. 논문 작성의 혁신적 효율성: Quarto나 R Markdown으로 작성하면 데이터 업데이트 시 그래프와 표가 자동으로 갱신된다. 수동 복사-붙여넣기는 과거의 일이 된다.

  3. 심사자와의 완벽한 소통: GitHub에 공개된 코드와 데이터로 심사자들이 직접 분석을 검증할 수 있다. “재현 불가능”이라는 심사 의견은 더 이상 받지 않게 된다.

  4. 연구의 영속성: 플레인 텍스트 기반 문서는 100년 후에도 읽을 수 있다. 소프트웨어가 사라져도 연구는 영원히 남는다.

  5. 국제적 명성과 영향력: GitHub 기여도와 오픈소스 연구로 글로벌 네트워크를 구축하고, 인용 횟수와 협업 기회가 기하급수적으로 증가한다.

3.3 재현성 구현 시점

재현성과 투명성이 본인 이익에 부합한다고 가정해 보자. 그렇다면 재현성을 고민해야되는 가장 좋은 시기는 언제일까?

정답은 연구 생명주기 전체를 통틀어 첫날부터다! 프로젝트를 시작하기 전에 R, 파이썬, Git 같은 도구를 배워야 할 수도 있다. 분석을 하는 동안 너무 오래 방치한다면, 두 달 전에 무엇을 했는지 기억을 되살리는데 시간을 많이 낭비하게 된다. 논문을 작성할 때는 갱신된 숫자, 표, 그림도 필요하다. 논문의 공동 저자로 참여할 때 본인 이름이 들어간 논문에 제시된 분석이 제대로 구현되었는지 확인하고 싶기도 하고, 논문을 심사할 때는 저자들이 결론에 이르는 과정을 모르면 저자들이 제시한 결과에 대해 제대로 된 판단을 내릴 수도 없다.

알렉산더(Alexander, 2023)는 더 나은 재현성을 향한 3단계를 다음 같이 제안하고 있다.

  1. 전체 작업흐름이 문서화 되어 있는지 확인한다.
  • 원시 데이터는 어떻게 얻었으며, 다른 사람들이 지속적으로 접근할 수 있는가?
  • 원시 데이터를 분석된 데이터로 변환하기 위해 어떤 구체적인 단계를 밟았으며, 다른 사람들과 공유하는 방법은 있는가?
  • 어떤 분석이 이루어졌으며, 어떤 코드/스크립트가 사용되었으며, 공유하는 방법은 무엇인가?
  • 최종 논문이나 보고서는 어떻게 작성되었으며, 제3자가 과정을 어느 정도 따라할 수 있는가?
  1. 다음 요구 사항을 점진적으로 달성하려고 노력한다.
    • 전체 작업흐름을 다시 실행할 수 있는가?
    • 제3자가 전체 작업흐름을 다시 실행할 수 있는가?
    • “미래의 본인”이 전체 작업흐름을 다시 실행할 수 있는가?
    • “미래의 제3자”가 전체 워크플로우를 다시 실행할 수 있는가?
  2. 최종 논문이나 보고서에서 데이터, 방법, 작업흐름 한계에 대한 논의를 포함한다.

3.4 문서 코드화 통한 오픈 사이언스

문서 코드화(Document as Code) 패러다임은 앞서 언급한 재현성 문제들을 해결할 수 있는 강력한 해법이다. 이는 단순한 기술적 변화가 아니라 과학 연구 문화의 근본적 전환을 의미한다.

3.4.1 FAIR 원칙의 실현

현대 오픈 사이언스는 FAIR 원칙을 기반으로 한다:

  • Findable(찾을 수 있는): 연구 데이터와 메타데이터를 쉽게 찾을 수 있어야 함
  • Accessible(접근 가능한): 표준화된 프로토콜로 데이터에 접근할 수 있어야 함
  • Interoperable(상호운용 가능한): 다양한 시스템과 도구에서 데이터를 활용할 수 있어야 함
  • Reusable(재사용 가능한): 명확한 라이선스와 메타데이터로 데이터를 재사용할 수 있어야 함

문서 코드화는 이 모든 원칙을 자연스럽게 만족한다. Git으로 버전 관리되는 플레인 텍스트 문서는 GitHub에서 쉽게 검색되고(Findable), 누구나 접근할 수 있으며(Accessible), 다양한 도구에서 처리 가능하고(Interoperable), 명확한 라이선스 하에 재사용할 수 있다(Reusable).

3.4.2 COVID-19 백신 개발

2020년 COVID-19 팬데믹은 오픈 사이언스의 진정한 힘을 보여준 역사적 사건이다. 1월 10일 중국 연구진이 바이러스 유전자 서열을 공개하자, 전 세계 연구자들이 즉시 백신 개발에 뛰어들었다. GitHub에는 매일 새로운 분석 코드가 올라왔고, bioRxiv에는 하루 수백 편의 사전 출판 논문이 게재되었다.

독일 연구자가 밤새 개발한 백신 설계를 아침에 미국 연구자가 실험하고, 그 결과를 저녁에 인도 연구자가 최적화하는 24시간 릴레이 연구가 이어졌다. 그 결과 11개월 만에 백신이 개발되는 기적이 일어났다. 이는 모든 연구 과정이 투명하게 공유되고, 전 세계가 하나의 거대한 연구실처럼 협업했기 때문에 가능했다.

만약 이 연구들이 HWP 파일로 작성되고, SPSS로 분석되고, 각국의 독자적 소프트웨어로 수행되었다면 어떻게 되었을까? 협업은 불가능했을 것이고, 백신 개발은 수년이 걸렸을 것이다.

3.4.3 재현가능한 워크플로우 구축

문서 코드화 환경에서 재현가능한 연구를 위한 핵심 구성 요소는 다음과 같다:

  1. 버전 관리 시스템 (Git): 모든 변경사항을 추적하고 협업을 지원
  2. 컨테이너화 (Docker): 소프트웨어 환경을 완전히 재현 가능하게 만듦
  3. 리터레이트 프로그래밍: 코드, 데이터, 설명이 하나의 문서에 통합
  4. 자동화된 워크플로우: 데이터부터 최종 결과물까지 원버튼 재현
  5. 오픈 데이터 저장소: Zenodo, Figshare 등을 통한 영구적 데이터 보존

이러한 도구들을 조합하면, 연구자가 GitHub에서 코드를 다운받고, Docker로 환경을 구축하고, 한 번의 명령으로 전체 연구를 재현할 수 있는 시스템을 만들 수 있다.

3.4.4 오픈사이언스 도구 체인

그림 3.2 은 앞 장에서 살펴본 HWP 생태계와 문서 코드화를 통한 오픈사이언스 도구 체인을 직접 비교한 것이다. 왼쪽의 체계적인 디렉토리 구조와 오른쪽의 통합된 무료 도구들이 어떻게 조화를 이루는지 보여준다.

그림 3.2: 문서 코드화와 오픈사이언스 도구 체인

가장 눈에 띄는 차이점은 비용이다. HWP 생태계에서 연간 630만원이 필요한 라이선스 비용이 오픈사이언스 환경에서는 완전 무료(₩0)가 된다. 하지만 진짜 혁신은 비용 절약이 아니라 워크플로우의 근본적 변화에 있다.

HWP 생태계에서는 Excel → SPSS → Origin → HWP로 이어지는 각 단계마다 수동으로 파일을 복사하고 붙여넣어야 했다. 하지만 오픈사이언스 도구 체인에서는 R/Python → 통계분석 → 시각화 → Quarto 문서 생성까지 모든 과정이 자동화된 파이프라인으로 연결된다. 데이터가 업데이트되면 한 번의 명령으로 모든 그래프와 표, 최종 문서가 자동으로 갱신된다.

더욱 중요한 것은 국제 표준 호환성이다. GitHub에서 관리되는 연구는 전 세계 누구나 접근할 수 있고, Docker 컨테이너로 패키징된 환경은 어떤 컴퓨터에서도 동일하게 재현된다. 이는 단순히 도구의 변화를 넘어 과학 연구 문화의 패러다임 전환을 의미한다.

노트재현성 피라미드

디지털로 구현되는 논문은 컴퓨터 환경, 코드, 데이터, 문서화, 논문/보고서로 구성되며, 이들은 재현가능한 연구의 다양한 측면을 나타낸다. 이러한 요소들은 모여 피라미드 구조를 이루며, 게재된 논문은 이 피라미드의 꼭대기에 해당된다. 재현가능한 논문/보고서는 각 단계의 재현성에 기여함으로써 연구의 신뢰성과 투명성을 높이는 데 중요한 역할을 합니다.

그림 3.3: 재현성 피라미드

💭 생각해볼 점

지금 진행 중인 연구를 떠올려 본다. 6개월 전 분석한 결과를 정확히 재현할 수 있는가? 동료가 “이 그래프를 어떻게 만들었나요?”라고 물으면 코드를 보여줄 수 있는가? 아니면 “SPSS에서 이렇게 저렇게 클릭했다”는 막연한 설명밖에 할 수 없는가? GitHub에 연구를 공개하여 전 세계 연구자들과 협업할 준비가 되어 있는가?

재현가능한 연구는 단순한 방법론이 아니라 과학자의 윤리이자 책임이다. 문서 코드화를 통해 우리는 HWP의 폐쇄적 성벽을 넘어 오픈 사이언스의 무한한 가능성으로 나아갈 수 있다. Git으로 모든 변경사항을 추적하고, 주피터 노트북으로 코드와 설명을 통합하며, Docker로 재현 환경을 보장하는 것. 이것이 바로 21세기 과학자가 갖춰야 할 핵심 역량이다.

다음 장에서는 이러한 재현가능한 연구를 실제로 구현하는 방법을 배운다. R과 Python을 활용한 리터레이트 프로그래밍, Quarto를 통한 다양한 출력 형식 생성, GitHub Actions를 활용한 자동화된 워크플로우 구축까지. 이론을 넘어 실전으로 나아가는 여정이 시작된다.

  1. The Carpentries에서 인큐베이션하고 있는 RStudio를 사용한 재현가능한 출판 소개(Introduction to Reproducible Publications with RStudio)를 번역하여 작성되었다.↩︎

  2. p-해킹(p-hacking)은 연구자가 데이터를 여러번 분석하여 우연히 유의미한 결과를 얻는 행위를 의미한다. 예를 들어, 연구자가 많은 다양한 통계적 검증을 시도하고 그 중에서만 유의미한 결과를 보고하는 것이 해당된다.↩︎

  3. HARKing (Hypothesizing After the Results are Known, 결과를 알고 난 후 가설 설정)은 연구자가 데이터를 분석한 후 결과를 보고 나서야 가설을 세우는 것을 말한다.↩︎

  4. Cherry-picking (체리피킹)은 연구자가 자신의 주장이나 이론을 지지하는 데이터만 선택적으로 사용하고, 반대되는 데이터는 무시하는 행위를 지칭한다.↩︎