유전체 분석이 클라우드를 필요로 하게 된 첫 번째 이유는 데이터의 크기와 구조가 동시에 바뀌었기 때문이다. 한 사람의 전장유전체서열 분석(whole-genome sequencing, WGS)도 원시 FASTQ와 정렬 결과, 변이 파일, 품질 관리 결과를 모두 합치면 쉽게 수십에서 수백 기가바이트 규모가 된다. 여기에 RNA-seq, single-cell RNA-seq, 공간전사체(spatial transcriptomics), 장기 보관용 원본 데이터까지 더해지면 문제는 단순한 저장 공간 부족을 넘어선다. 같은 데이터를 여러 번 복사하고, 서로 다른 서버에서 서로 다른 버전의 참조 유전체와 소프트웨어를 쓰고, 분석이 끝난 뒤에도 중간 산물을 정리하지 못하는 일이 연구실의 일상이 된다. 즉 오늘날의 병목은 계산 속도만이 아니라 데이터 이동, 환경 관리, 그리고 반복 가능한 분석 구조에 있다.
예전에는 파일을 한 번 내려받아 연구실 서버에서 오래 붙잡고 분석하는 방식이 어느 정도 통했다. 그러나 코호트 규모가 커지고 공용 데이터 자원이 확대되면서 이 모델은 점점 비효율적이 되었다. gnomAD처럼 대규모 참조 자원을 객체 스토리지에 두고 공개하는 사례나, NCBI SRA가 클라우드 안에서 직접 접근하는 방식을 제공하는 사례는 공통된 메시지를 보여 준다. 핵심은 데이터를 사용자 컴퓨터로 모두 가져오는 것이 아니라, 데이터가 이미 존재하는 클라우드 환경으로 계산을 가져가는 것이다. 이른바 bring compute to data라는 사고방식은 단순한 유행어가 아니라, 대규모 오믹스학이 실제로 작동하기 위한 운영 원칙이 되었다 (gnomAD team 2020; NCBI 2024).
온프레미스(on-premises) 서버는 연구실이나 기관이 직접 구매하고 운영하는 계산 자원이다. 이런 방식은 장기간 안정적으로 돌아가는 파이프라인, 엄격한 내부 보안 통제, 예측 가능한 연중 상시 workload에 강점이 있다. 반면 초기 구축 비용이 크고, 갑자기 수백 개 샘플이 몰리거나 특정 프로젝트에서만 매우 큰 메모리와 CPU가 필요할 때 유연하게 확장하기 어렵다. 반대로 AWS 같은 클라우드는 필요한 시점에만 인스턴스를 켜고, 일이 끝나면 끌 수 있다는 점에서 탄력성이 크다. 초보자가 흔히 오해하듯 클라우드는 “남의 서버를 빌리는 일”에 그치지 않고, 저장, 권한, 로그, 워크플로, 자동 확장, 공용 데이터 접근이 하나의 운영 체계로 묶인 환경이다 (AWS 2024a; NIH Cloud Lab 2024).
Table 1은 온프레미스와 AWS를 연구 운영 관점에서 단순화해 비교한 것이다. 여기서 중요한 점은 어느 한쪽이 항상 더 낫다는 결론이 아니라, 어떤 문제를 풀고 있는지에 따라 적합한 선택이 달라진다는 사실이다. 예를 들어 매주 비슷한 수의 샘플을 처리하는 임상 파이프라인은 온프레미스나 하이브리드 구성이 더 경제적일 수 있다. 반면 공개 데이터 자원을 바로 읽어야 하거나, 짧은 기간에 수백에서 수천 개의 작업을 병렬로 돌려야 하는 연구 프로젝트는 클라우드가 훨씬 자연스럽다. 실제 연구 현장에서는 둘 중 하나만 쓰기보다, 원본 보관과 일부 민감 데이터는 기관 내부에 두고 대규모 계산과 공개 데이터 활용은 클라우드에서 수행하는 혼합 구조가 자주 사용된다.
Table 1. 온프레미스 서버와 AWS의 비교
| 항목 | 온프레미스 서버 | AWS 클라우드 |
|---|---|---|
| 초기 비용 | 서버, 스토리지, 네트워크를 먼저 구매해야 함 | 사용량 기반으로 시작 가능 |
| 확장성 | 증설에 시간과 구매 절차가 필요함 | 필요 시 즉시 확장 가능 |
| 공개 데이터 접근 | 외부 데이터 반입과 저장이 병목이 되기 쉬움 | 같은 클라우드의 공개 데이터에 직접 접근 가능 |
| 운영 부담 | 패치, 하드웨어, 장애 대응을 직접 담당 | 인프라 운영 일부를 관리형 서비스로 이전 가능 |
| 적합한 상황 | 예측 가능한 상시 workload, 내부 규제 중심 환경 | 변동성 큰 연구 workload, 대규모 병렬 처리, 공용 데이터 활용 |
클라우드를 이해하는 가장 좋은 방법은 서비스 이름부터 외우는 것이 아니라, 저장과 계산과 협업과 재현성이라는 네 가지 질문으로 나누어 보는 것이다. 먼저 저장 관점에서 보면, 현대 오믹스 연구는 운영체제가 설치된 로컬 디스크와 장기 보관용 데이터 저장소를 분리해야 한다. Amazon S3 같은 객체 스토리지(object storage)는 FASTQ, BAM, CRAM, VCF, 보고서, 참조 데이터처럼 오래 보관하고 여러 서비스가 함께 읽어야 하는 자산에 적합하다. 반면 계산 노드에 직접 붙는 디스크는 정렬 중간 파일이나 임시 작업 공간처럼 짧은 시간 동안 높은 I/O가 필요한 작업에 더 어울린다. 학생이 처음 AWS를 배울 때 파일을 어디에 둘 것인가와 어떤 저장소가 어떤 접근 패턴에 맞는가를 구분하는 습관을 들이는 것이 중요하다.
계산 관점에서는 더 명확한 변화가 보인다. 로컬 워크스테이션에서는 사용 가능한 CPU 수와 메모리가 고정되어 있고, 동시에 여러 사람이 같은 자원을 쓰면 병목이 즉시 드러난다. AWS에서는 Amazon EC2로 직접 서버를 띄울 수도 있고, AWS Batch로 샘플 단위 작업을 큐에 넣을 수도 있으며, Amazon EMR이나 AWS HealthOmics처럼 더 높은 수준의 관리형 분석 계층을 선택할 수도 있다. 이 차이는 단순히 “더 큰 컴퓨터”를 얻는 데 있지 않다. 오히려 계산 자원을 프로젝트의 길이와 크기에 맞추어 켰다 끄는 운영 방식, 그리고 같은 파이프라인을 다른 규모로 반복 실행할 수 있는 구조가 핵심이다. 따라서 클라우드는 계산 능력 자체보다 계산을 조직하는 방법을 바꾸는 도구라고 이해하는 편이 더 정확하다 (AWS 2024a; Data Carpentry 2024).
협업과 재현성의 의미도 달라진다. 예전에는 각 연구실 구성원이 자기 서버에 파일을 복사하고, 조금씩 다른 경로와 버전의 스크립트를 사용하며, 나중에 분석을 재현하지 못하는 일이 흔했다. 클라우드에서는 같은 S3 경로, 같은 컨테이너 이미지, 같은 입력 manifest, 같은 워크플로 정의를 공유함으로써 출발점을 맞추기 쉬워진다. 특히 권한을 IAM Role처럼 실행 주체에 붙이고, 로그와 메타데이터를 중앙에서 관리하면 “누가 언제 어떤 입력으로 어떤 분석을 돌렸는가”를 훨씬 명확하게 추적할 수 있다. 재현성(reproducibility)은 논문을 쓸 때만 필요한 덕목이 아니라, 협업 규모가 커질수록 비용과 시간을 줄여 주는 실용적 운영 기술이라는 점을 초반부터 이해할 필요가 있다 (AWS 2024b).
초보자는 AWS 서비스 이름이 너무 많아서 어디서부터 시작해야 할지 막막해한다. 이때 중요한 것은 모든 서비스를 다 배우는 것이 아니라, 어떤 층(layer)의 문제를 푸는 서비스인지 이해하는 것이다. 유전체 분석에서 자주 만나는 AWS 서비스는 크게 데이터 저장, 계산 실행, 워크플로 자동화, 질의와 해석, 시각화와 개발 보조의 다섯 층으로 나눌 수 있다. 이 가운데 AWS HealthOmics는 유전체와 오믹스 workflow를 위해 설계된 purpose-built service이고, 나머지 다수는 범용 AWS 서비스를 유전체 문제에 맞게 조합하는 방식이다. 즉 유전체 분석을 AWS에서 한다는 말은 “유전체 전용 서비스만 쓴다”는 뜻이 아니라, 범용 클라우드 도구와 생명과학 특화 서비스를 함께 엮어 쓴다는 뜻이다.
Table 2는 이 책에서 반복해서 등장할 서비스를 교육용으로 단순화한 지도다. 처음부터 모든 세부 기능을 외울 필요는 없다. 다만 어떤 서비스가 데이터 저장 계층이고, 어떤 서비스가 실행 계층이며, 어떤 서비스가 질의와 해석 계층인지만 알아도 책의 뒤쪽 장을 훨씬 쉽게 따라갈 수 있다. 예를 들어 S3, EC2, IAM Role만 이해해도 가장 기초적인 AWS 기반 유전체 분석은 시작할 수 있다. 그 위에 Batch, EMR, HealthOmics, Athena, SageMaker, Bedrock 같은 계층을 차례로 얹는다고 생각하면 전체 구조가 훨씬 단순해진다.
Table 2. 오믹스 입문자를 위한 AWS 서비스 지도
| 층 | 대표 서비스 | 책에서의 역할 |
|---|---|---|
| 저장 | Amazon S3, S3 Glacier storage classes, Amazon EBS | 원본 데이터, 결과 파일, 장기 보관, 임시 작업 디스크 |
| 데이터 이동 | AWS DataSync | 시퀀싱 센터, 병원, 로컬 HPC, 다른 클라우드에서 데이터 반입 |
| 직접 계산 | Amazon EC2 | 분석 서버, 노트북 환경, 맞춤형 도구 실행 |
| 배치와 오케스트레이션 | AWS Batch, Amazon EKS, AWS ParallelCluster | 대규모 병렬 처리, Kubernetes 운영, Slurm/HPC 스타일 클러스터 |
| 분산 분석 | Amazon EMR | Spark 기반 cohort-scale 데이터 처리 |
| 전용 오믹스 실행 | AWS HealthOmics | Nextflow, WDL, CWL 기반 관리형 오믹스 workflow |
| 질의와 요약 | Amazon Athena, Amazon Quick | S3 위 데이터 SQL 질의, cohort 요약과 시각화 |
| ML/AI | Amazon SageMaker, Amazon Bedrock | 모델 학습, 추론, 생성형 AI 기반 해석 |
| 개발 보조 | Kiro | 코드 작성과 workflow 설계 보조 |
초보자가 가장 먼저 버려야 할 오해는 클라우드가 무조건 비싸다는 생각이다. 클라우드는 잘못 쓰면 분명 비싸질 수 있지만, 반대로 몇 달에 한 번 있는 대형 분석을 위해 상시 서버를 미리 사 두는 방식도 결코 싸지 않다. 비용은 자원 자체보다 운영 방식에서 갈리는 경우가 많다. 필요한 동안만 계산 자원을 켜고, 중간 파일을 정리하고, 같은 리전에 데이터를 두고, 적절한 인스턴스를 선택하면 클라우드는 오히려 비용 구조를 더 투명하게 만든다. 이 책의 후반부에서 다루겠지만, 실제 대규모 WGS 프로젝트의 비용 누수는 “고성능 컴퓨터를 썼기 때문”보다 incomplete upload, request cost, intermediate data explosion, 불필요한 데이터 이동에서 더 자주 발생한다.
두 번째 오해는 AWS를 쓰려면 모든 데이터를 반드시 내 버킷으로 옮겨야 한다는 생각이다. 실제로는 공용 자원과 직접 연결하는 방식이 점점 더 중요해지고 있다. gnomAD, SRA, AWS Open Data 같은 사례는 클라우드 시대의 분석이 download -> analyze보다 query -> access in place -> compute에 가깝다는 점을 보여 준다. 세 번째 오해는 AWS가 대기업이나 전문 엔지니어만의 도구라는 생각이다. 실제로는 EC2 한 대와 S3 한 버킷, 그리고 적절한 IAM Role만으로도 매우 많은 교육용 실습과 중소 규모 연구를 시작할 수 있다. 마지막으로 버려야 할 오해는 모든 서비스를 다 알아야만 시작할 수 있다는 생각이다. 처음에는 EC2, S3, IAM Role이라는 세 가지 축만 제대로 이해하고, 이후 필요에 따라 Batch, EMR, HealthOmics, SageMaker로 확장해 가면 충분하다.
AWS는 오믹스 연구를 자동으로 더 똑똑하게 만들어 주는 마법 도구가 아니다. 대신 데이터가 커지고, 협업이 복잡해지고, 공용 자원이 클라우드에 존재하는 시대에 맞는 연구 운영 방식과 분석 구조를 제공한다. 따라서 AWS를 배운다는 것은 서비스 이름을 많이 외우는 일이 아니라, 어떤 데이터를 어디에 두고, 어떤 계산을 언제 켜고, 누구와 어떤 방식으로 같은 출발점을 공유할 것인지 설계하는 일에 가깝다. 이런 관점으로 접근하면 뒤이어 나올 EC2, S3, gnomAD, SRA, EMR, HealthOmics 장이 서로 분리된 서비스 설명이 아니라 하나의 연구 인프라 이야기로 연결되기 시작한다.
download -> analyze보다 bring compute to data가 더 중요해졌는가?