유전체 샘플당 비용? 시퀀싱 시도당 비용을 고려해 보세요

만약 당신이 생물정보학 (bioinformatics) 플랫폼 리드, ML 인프라 엔지니어, 또는 현재 클라우드에서 GPU 가속 워크플로 (GPU-accelerated workflows)를 실행 중인 유전체 예산 책임자라면 주목하십시오. 거의 모든 유전체 인프라 팀이 지불하고 있지만, 실제로 측정하는 팀은 거의 없는 숨겨진 비용 문제가 있습니다. 여기서의 관찰은 생산 유전체 환경에서 여전히 지배적인 데이터 유형인 숏리드 시퀀싱 (short-read sequencing) 워크플로에 특화되어 있습니다.

당신의 유전체 파이프라인은 아마도 30%의 확률로 실패하고 있으며, 당신은 그 모든 비용을 지불하고 있을 것입니다. 이 기사는 거의 모든 유전체 인프라 팀이 지불하고 있지만, 실제로 측정하는 팀은 거의 없는 숨겨진 비용 문제에 대해 다룹니다. 본격적인 논의에 앞서: 이 대화는 생산 유전체 워크플로에서 여전히 지배적인 데이터 유형으로 남아 있는 숏리드 시퀀싱 (short-read sequencing) 데이터에 초점을 맞춥니다.

차세대 시퀀싱 (NGS) 워크플로의 표준인 숏리드 시퀀싱 (short-read sequencing) 파이프라인[DB1]은 과거에는 CPU 집약적이었습니다. 클러스터에서 실행하면 정렬 (alignment)과 변이 호출 (variant calling)을 수행하며 몇 시간 동안 고군분투했고, 병목 현상은 CPU 처리량 (throughput)이었습니다. GPU 가속은 주요 화두가 아니었습니다.

상황이 바뀌었습니다. AI 기반 변이 호출 (variant calling), Parabricks와 같은 GPU 가속 정렬 (alignment) 도구, 그리고 시퀀싱 데이터 위에서 실행되는 딥러닝 (deep learning) 모델들이 모두 GPU로 이동했으며, 이는 팀들이 처음으로 본격적인 GPU 인프라를 관리하게 되었음을 의미합니다.

GPU 클라우드와 함께 따라오는 비용 모델은 CPU 클러스터와 확연히 다르며, 사람들은 파이프라인 신뢰성과 비용 회계에 대한 CPU 시대의 가정을 GPU 환경으로 가져오고 있습니다. 그러한 불일치가 비용 손실을 초래하고 있습니다.

우리는 이러한 많은 팀과 협력하고 있으며, 인프라 비용에 대해 물어보면 그들은 거의 항상 동일한 수치를 먼저 제시합니다: 샘플당 비용 (cost per sample). 그것이 상부에 보고되는 수치이며, 예산에 반영되는 수치입니다. 하지만 그 수치가 숨기고 있는 부분이 바로 흥미로운 지점입니다.

파이프라인이 실패할 때

전형적인 short-read germline variant calling (생식선 변이 호출) 파이프라인은 대략 10개에서 15개의 별도 처리 단계를 거칩니다. 시퀀서(sequencer)에서 나온 raw FASTQ 파일로 시작하여, 품질 관리 (quality control), 정렬 (alignment), 중복 마킹 (duplicate marking), 염기 품질 점수 재보정 (base quality score recalibration), 변이 호출 (variant calling), 주석 달기 (annotation) 과정을 거치며, 각 단계는 다음 단계로 결과물을 넘겨줍니다.

이러한 파이프라인은 대부분 Nextflow 또는 Snakemake와 같은 워크플로 매니저 (workflow manager) 상에서 실행되며, 이들은 실패한 작업을 재개할 수 있는 내장 메커니즘을 갖추고 있습니다. Nextflow에는 처음부터 다시 시작하는 대신 11단계 중 8단계부터 다시 시작할 수 있도록 설계된 플래그 (flag)가 있습니다. 원칙적으로 이는 정확히 올바른 해결책입니다.

실제적인 문제는 설정 (configuration)에 있습니다. 해당 플래그가 작동하려면 Nextflow가 캐시 디렉토리 (cache directory)—어느 단계가 성공적으로 완료되었는지 기록하는 폴더—를 찾아야 합니다. 만약 솔루션 아키텍트 (solutions architect)가 해당 캐시를 위한 지속성 디스크 공간 (persistent disk space)을 적절히 구성하지 않고 컴퓨팅 환경을 구축했다면, 필요할 때 파일이 존재하지 않게 되고 파이프라인은 결국 1단계부터 다시 시작하게 됩니다. 이는 도구의 한계라기보다는 설정의 실패이지만, 결과는 같습니다. 결과물을 얻지 못한 컴퓨팅 비용을 지불하게 된 것입니다.

대규모 작업이 깔끔한 단계 경계가 아닌 실행 중간에 실패할 경우, 적절한 체크포인팅 (checkpointing)조차 당신을 구원하지 못할 것입니다. 왜냐하면 해당 작업을 처음부터 끝까지 다시 실행해야 하기 때문입니다.

측정하기 어려운 문제

Nebius와 함께 작업하는 유전체학 (genomics) 팀들은 파이프라인 실행의 15%에서 40%가 완료 전 최소 한 번 이상의 실패와 재시작을 겪는다고 지속적으로 보고하고 있습니다. 이 수치를 정확하게 특정하기는 어려우며, 우리는 이곳의 현실을 반영하는 확정적인 수치를 가지고 있지 않습니다.

이 범위가 넓은 이유는 인프라 구축의 성숙도에 크게 의존하기 때문입니다. 환경 설정이 잘 된 팀들은 낮은 범위에 속하며, GPU 클라우드에 익숙하지 않거나 중단율이 높은 스팟 인스턴스 (spot instances)에서 실행하는 팀들은 높은 범위에 속합니다.

이것이 눈에 보이지 않는 이유는, 만약 측정 지표가 완료된 샘플당 비용이라면, 결국 완료된 실패한 실행(failed run) 역시 정상 비용의 샘플 하나로 보이기 때문입니다. 재시도(retry) 과정은 보고되는 수치에서 사라집니다.

예를 들어, GPU 가속 전체 유전체 시퀀싱 파이프라인(whole genome sequencing pipeline) — 생식선 변이 호출 (germline variant calling) — 은 H200에서 대략 2 GPU-시간이 소요됩니다. 현재의 온디맨드 (on-demand) 요율을 적용하면 샘플당 컴퓨팅 비용은 약 9달러이며, 이것이 눈에 보이는 비용입니다.

이제 팀들이 보고하는 수치 중 보수적인 범위에 해당하는 25%의 실패율을 적용해 보겠습니다. 4개의 샘플을 완료할 때마다, 한 번의 실행은 실패하여 재시작되었고 처음부터 다시 실행되었습니다. 완료된 샘플당 실제 비용은 더 이상 9달러가 아니라 11.25달러이며, 이는 25%의 숨겨진 추가 비용 (markup)입니다.

이를 한 달에 2,000개의 샘플을 처리하는 팀 규모로 확대해 보면, 눈에 보이는 컴퓨팅 청구서에는 18,000달러라고 적혀 있지만 실제 비용은 22,500달러입니다. 이는 아무런 결과물도 만들어내지 못한 컴퓨팅 비용으로 매달 4,500달러, 즉 연간 54,000달러가 낭비되고 있음을 의미합니다. 중간 규모의 유전체학 (genomics) 팀에게 이는 클라우드 예산의 상당 부분이며, 어디에서도 낭비로 나타나지 않습니다.

이것은 스토리지 (storage)를 고려하기 전의 이야기입니다.

숨겨진 비용

스토리지 상황은 사람들이 예상하는 것보다 더 미묘합니다. 표준 전체 유전체는 대략 200기가바이트 (gigabytes)의 원시 FASTQ 데이터를 생성하지만, 이는 압축되지 않은 수치입니다. 실제로 콜드 스토리지 (cold storage)로 들어가는 거의 모든 데이터는 압축되어 보통 샘플당 약 30기가바이트 정도로 줄어들기 때문에, 샘플당 스토리지 비용은 상당히 관리 가능한 수준입니다.

복잡해지는 지점은 데이터 검색 (retrieval) 단계입니다. 아카이브된 샘플을 재분석하고자 할 때 — 예를 들어, 업데이트된 파이프라인 (pipeline)을 통해 새로운 코호트 (cohort)를 실행할 때 — 압축된 파일들을 다시 불러와야 하며, 이때 인프라 (infrastructure)는 이를 다시 압축 해제 (decompress)해야 합니다. 30기가바이트의 압축 파일이 200기가바이트로 확장되는데, 이는 확장에 따른 디스크 공간과 메모리 여유분 (memory headroom)이 필요함을 의미합니다. 만약 환경이 이에 맞춰 설계되지 않았다면, 압축 해제 단계에서 오류가 발생하거나 심각한 속도 저하가 발생하며, 이는 사전에 거의 고려되지 않는 또 다른 유형의 숨겨진 비용이 됩니다.

암 연구의 경우, 그 수치는 훨씬 더 큽니다. 체세포 변이 호출 (Somatic mutation calling)은 60X에서 100X의 시퀀싱 깊이 (sequencing depth)로 수행되므로, 600기가바이트 크기의 FASTQ 파일은 드문 일이 아닙니다. 우리가 설명한 모든 사항은 이에 따라 규모가 커집니다.

핵심 요점은 다음과 같습니다. 컴퓨팅 (compute) 자원이 스토리지 (storage)와 어디에 위치하든 관계없이, 콜드 스토리지 (cold storage)로부터의 데이터 검색에는 항상 비용이 발생한다는 점입니다. 일부 플랫폼은 여기에 더해 리전 (region) 간 데이터 송출 (egress) 비용을 부과하기도 합니다. 어떤 방식이든, 재분석 빈도를 실제 예산 항목으로 모델링하지 않은 팀들은 이를 실행할 때 거의 항상 당혹감을 느끼게 됩니다.

추적, 추적, 그리고 추적...

생물정보학 엔지니어 (Bioinformatics engineers)들은 실패율을 잘 알고 있습니다. 왜냐하면 새벽 2시에 작업이 실패하는 것을 지켜보는 당사자들이기 때문입니다. 하지만 그 수치가 예산을 관리하는 사람에게 보고될 때쯤이면, 그것은 그저 "클라우드 비용"으로 뭉뚱그려집니다. "비용은 지불했지만 결과물을 얻지 못한 컴퓨팅 비용"이라는 별도의 항목은 존재하지 않습니다.

서비스 및 인스턴스 유형별 클라우드 과금 방식으로는 이를 드러낼 수 없습니다. GPU 컴퓨팅 지출, 스토리지 지출, 데이터 송출 비용은 보이지만, "이번 달 GPU 지출의 20%가 완료되지 않은 실행에 사용되었다"는 사실은 보이지 않습니다. 이러한 세분화 (decomposition)를 위해서는 의도적인 계측 (instrumentation)이 필요하며, 대부분의 팀은 아직 이를 구축하지 못했습니다.

팀이 샘플당 비용 대신 측정해야 할 것

대신 팀은 몇 가지 사항을 측정해야 합니다. 첫째, 완료율 (completion rate)입니다. 이는 실패나 재시작 없이 완료된 파이프라인 실행 (pipeline runs)의 비율을 의미합니다. 이것이 바로 컴퓨팅 낭비 (compute waste)와 직결되는 파이프라인 신뢰도 점수입니다.

둘째, 시도된 샘플당 비용 (cost per attempted sample) 대 완료된 샘플당 비용 (cost per completed sample)의 비교입니다. 만약 이 수치들이 유의미하게 다르다면, 이는 해결할 가치가 있는 문제입니다.

셋째, 스토리지 검색 빈도 (storage retrieval frequency)와 압축 해제 (decompression)에 따른 인프라 오버헤드입니다. 즉, 아카이브된 데이터를 얼마나 자주 다시 불러오는지, 그리고 이를 위해 디스크와 메모리 여유 공간 (headroom)을 적절하게 산정했는지 여부입니다. 이는 스토리지 청구서상에 저렴해 보이는 비용과 데이터를 실제로 사용하는 데 드는 비용 사이의 간극을 나타냅니다.

유전체 인프라 팀이 지금 당장 해야 할 한 가지

다른 무엇보다도, 지금 당장 파이프라인 실패율 (pipeline failure rate)을 계측 (instrument)하십시오.

수치 그 자체만으로는 아무것도 해결되지 않지만, 문제를 가시화해 줍니다. 컴퓨팅 지출의 15% 또는 25%가 재시작되는 실행에 사용되고 있다는 것을 실제 달러 금액과 함께 보여줄 수 있게 되면, 근본적인 인프라를 개선하는 것에 대한 논의는 매우 쉬워집니다. 사람들은 낭비를 눈으로 확인할 수 있을 때 빠르게 움직입니다.

더 나은 체크포인팅 (checkpointing) 설정, 더 스마트한 스토리지 아키텍처 (storage architecture), 더 안정적인 컴퓨팅 등 다른 모든 것은 그 뒤를 따릅니다. 하지만 먼저 문제를 직시해야 합니다.

헬스케어 및 생명 과학 분야의 AI 미래를 형성하는 혁신을 발견해 보세요. 자세한 내용을 알아보려면 https://nebius.com/solutions/life-sciences-and-healthcare 를 방문하시고, nebius.com/ai-discovery-award 에서 2026 AI Discovery Awards 시상식 등록을 진행하세요.

Anastasia Raskolova는 Nebius의 Healthcare & Life Sciences 부문 시니어 프로덕트 매니저로, 신약 개발 및 임상 AI 워크플로우를 위한 인프라 제품에 집중하고 있습니다. 그전에는 컴퓨터 비전 (computer vision), 추천 시스템 (recommendation systems), 생성형 AI (generative AI) 전반에 걸쳐 ML 제품을 구축하는 경력을 쌓았으며, 매사추세츠 종합병원 (Massachusetts General Hospital) 응급실에서 봉사하며 임상 현장의 현실을 놓지 않고 있습니다.

Nebius 제공.