생물정보학 입문자는 보통 samtools, bcftools, tabix, pysam 같은 도구 이름부터 배우지만, 실제 분석 현장에서 더 중요한 것은 그 밑바닥을 공통으로 받치고 있는 라이브러리 계층이다. htslib는 바로 그 공통 계층이다. HTSlib 논문은 이 라이브러리를 SAM, BAM, CRAM, VCF, BCF, FASTA 같은 고처리량 시퀀싱 데이터 형식에 대한 읽기·쓰기와 인덱싱을 제공하는 통합 C 라이브러리로 설명한다. 즉 samtools는 정렬 파일 조작 도구이고, bcftools는 변이 파일 조작 도구이지만, 실제 파일을 열고 압축 블록을 읽고 인덱스를 따라가며 원격 자원을 처리하는 핵심 기능의 상당 부분은 htslib가 담당한다 (Bonfield et al. 2021).
이 구조가 중요한 이유는 도구 하나하나를 따로 고치는 대신, 공통 라이브러리 하나를 개선함으로써 생태계 전체의 능력이 함께 올라가기 때문이다. 예를 들어 로컬 디스크 파일만 다루던 도구 집합이 있다고 하자. 이 도구들이 모두 htslib의 파일 접근 계층을 사용한다면, htslib가 HTTP, HTTPS, S3 같은 원격 백엔드를 이해하는 순간 같은 생태계에 속한 도구들도 비교적 적은 수정으로 원격 데이터 접근 능력을 얻게 된다. 학생이 이 점을 이해하면 “왜 어떤 프로그램은 클라우드 파일을 바로 열고, 어떤 프로그램은 꼭 먼저 복사해야 하는가”라는 차이를 도구 이름이 아니라 라이브러리 계층의 차이로 읽을 수 있게 된다.
또한 htslib는 파일 형식을 읽는 파서에 그치지 않는다. 압축, 인덱스, 좌표 기반 질의, 참조 서열 접근, 원격 전송 프로토콜까지 함께 다룬다. 이 때문에 htslib를 배운다는 것은 단순히 C 라이브러리 하나를 소개받는 것이 아니라, 현대 유전체 분석이 파일을 어떻게 표현하고 어디에서 어떻게 읽는지에 대한 운영 원리를 배우는 일에 가깝다. 1장에서 보았던 bring compute to data라는 원칙이 실제 생물정보학 도구 내부에서 어떻게 구현되는지를 보여 주는 대표 사례가 바로 htslib다.
Table 1은 학생이 자주 접하는 도구와 htslib의 관계를 단순화한 것이다. 중요한 점은 “모든 도구가 정확히 같은 방식으로 htslib를 쓴다”는 뜻이 아니라, 공통 파일 접근 계층이 넓게 공유된다는 사실이다. 이 공통 계층 덕분에 S3 plugin의 의미도 단순한 부가 기능이 아니라 생태계 수준의 변화로 읽을 수 있다.
Table 1. htslib 생태계의 기본 구성
| 계층 | 대표 도구 또는 형식 | 역할 |
|---|---|---|
| 응용 도구 | samtools, bcftools, tabix, pysam, rsamtools |
사용자가 직접 실행하거나 호출하는 분석 도구 |
| 공통 라이브러리 | htslib |
파일 열기, 압축 블록 처리, 인덱스 탐색, 원격 접근 |
| 데이터 형식 | SAM, BAM, CRAM, VCF, BCF, BGZF, FASTA | 정렬, 변이, 참조 서열, 압축 표현 |
| 저장 위치 | 로컬 디스크, HTTP/HTTPS, S3, HealthOmics S3 URI | 데이터가 실제로 놓이는 위치 |
클라우드 스트리밍을 이해하려면 먼저 왜 BAM이나 vcf.gz가 “부분 읽기”에 적합한지 알아야 한다. 여기서 핵심은 BGZF와 인덱스다. HTSlib 논문은 BGZF를 GZIP과 호환되면서도 블록 단위 접근을 허용하는 압축 방식으로 설명한다. 일반적인 gzip 파일은 앞에서부터 순서대로 풀어야 하므로 파일 뒤쪽의 특정 좌표만 읽고 싶어도 사실상 앞부분을 모두 지나가야 한다. 반면 BGZF는 압축 데이터가 비교적 작은 블록들로 나뉘어 있어, 인덱스가 가리키는 블록부터 바로 찾아갈 수 있다. 이것이 유전체 좌표 기반 질의가 가능한 기술적 출발점이다 (Bonfield et al. 2021).
인덱스는 이 출발점을 실제 분석 동작으로 바꾸는 지도다. BAM에는 보통 BAI나 CSI, BGZF 압축 VCF에는 TBI나 CSI, CRAM에는 CRAI나 CSI가 함께 사용된다. 이 인덱스는 “염색체의 어느 구간이 파일의 어느 압축 블록 근처에 있는가”를 기록한다. 따라서 사용자가 chr1:1000000-1010000 같은 범위를 요청하면, 도구는 파일 전체를 읽지 않고도 관련 블록만 찾아가서 필요한 부분만 해제할 수 있다. 학생은 이 원리를 “파일 전체를 여는 것”이 아니라 “좌표를 바이트 범위로 번역하는 것”으로 이해하는 편이 좋다.
이 지점에서 로컬 접근과 클라우드 접근이 연결된다. 로컬 디스크에서는 인덱스가 디스크 seek를 줄여 준다. 클라우드 객체 스토리지에서는 같은 원리가 네트워크 전송량을 줄여 준다. 즉 인덱스 기반 랜덤 접근은 원래도 중요했지만, S3 같은 원격 저장소에서는 그 가치가 훨씬 커진다. 분석자가 한 유전자 주변만 보고 싶다면, 수백 기가바이트 BAM 전체를 복사하는 대신 필요한 바이트 범위만 요청하는 편이 훨씬 합리적이기 때문이다. 이때 파일 형식의 설계와 저장 방식의 설계가 맞물리면서 “클라우드 친화적” 접근이 가능해진다.
Table 2는 자주 쓰는 형식과 인덱스의 관계를 학습용으로 정리한 것이다. 실제 현장에서는 더 많은 예외와 세부 옵션이 있지만, 입문 단계에서는 어떤 형식이 어떤 인덱스를 통해 부분 읽기를 지원하는지만 먼저 이해해도 충분하다. 특히 인덱스가 없으면 원격 스트리밍의 장점이 크게 줄어든다는 점을 먼저 익혀 두자.
Table 2. 대표 형식과 인덱스 기반 부분 접근
| 데이터 형식 | 흔한 압축 또는 저장 방식 | 대표 인덱스 | 부분 접근의 의미 |
|---|---|---|---|
| BAM | BGZF 기반 바이너리 정렬 파일 | BAI, CSI |
특정 유전체 구간의 read만 빠르게 조회 |
| CRAM | 참조 기반 압축 정렬 파일 | CRAI, CSI |
더 작은 저장 크기와 구간 단위 접근 |
| VCF.gz | BGZF 압축 텍스트 변이 파일 | TBI, CSI |
특정 염색체 구간의 variant만 조회 |
| BCF | 바이너리 변이 파일 | CSI |
대규모 cohort 변이 질의에 유리 |
| tab-delimited genomics file | BGZF + 좌표 정렬 | TBI, CSI |
BED, GFF 같은 좌표 파일의 구간 조회 |
htslib의 S3 plugin은 겉보기에는 단순하다. 문서에 따르면 이 plugin은 s3://bucket/path/to/file 형태의 URL을 이해하고, 필요한 인증 정보는 URL, 환경 변수, AWS 자격 증명 파일, 또는 s3cfg 파일에서 가져올 수 있다. 그러나 교육적으로는 이 간단함이야말로 핵심이다. 사용자는 더 이상 “먼저 S3에서 로컬로 복사한 뒤 도구를 실행한다”는 사고방식에만 머물 필요가 없다. 응용 프로그램이 htslib의 파일 함수를 쓰고 있다면, 같은 함수 호출이 로컬 파일 경로뿐 아니라 S3 URI에도 적용될 수 있기 때문이다 (HTSlib 2025).
이 변화는 기술적 번역 계층 덕분에 가능하다. samtools view local.bam과 samtools view s3://bucket/sample.bam은 사용자가 보기에는 입력 문자열만 다르지만, 내부에서는 htslib가 적절한 backend를 선택해 파일 열기, 인증, 요청, 블록 읽기, 인덱스 탐색을 처리한다. 즉 S3 plugin은 “S3 전용 새 프로그램”을 만드는 것이 아니라, 기존 프로그램이 파일 API를 그대로 유지한 채 S3를 이해하게 만드는 방식이다. 이런 설계는 생물정보학에서 특히 강력하다. 많은 연구용 도구가 파일 경로를 인자로 받는 오래된 인터페이스를 유지하고 있기 때문이다.
인증과 권한 측면에서도 plugin은 클라우드 운영 원칙과 잘 맞는다. htslib S3 plugin manual은 환경 변수와 ~/.aws/credentials, AWS_PROFILE, 임시 자격 증명, 만료 시간 갱신 같은 메커니즘을 설명한다. 이는 액세스 키를 코드에 하드코딩하지 않고, 실행 환경에 맞는 자격 증명 체계를 사용하라는 2장의 원칙과 정확히 연결된다. 다시 말해 S3 plugin의 가치는 단순히 원격 파일을 여는 편의성에 있지 않고, AWS 권한 모델과 연구 도구를 자연스럽게 연결해 준다는 데도 있다.
최근 AWS HealthOmics 문서는 이 점을 더욱 실용적으로 보여 준다. HealthOmics는 활성 read set을 Amazon S3 URI로 접근할 수 있게 하며, 이 문서에서 HTSlib 1.20 이상은 Amazon S3 Access Point를 원활하게 지원한다고 설명한다. 구버전에서는 HTS_S3_HOST 설정이나 presigned URL, 혹은 Mountpoint 같은 우회 경로가 필요할 수 있지만, 최신 라이브러리에서는 S3 URI 접근이 더 직접적인 표준 경로가 되었다. 이는 S3 plugin이 더 이상 실험적 보조 기능이 아니라, 클라우드 오믹스 도구 체계의 정식 일부가 되었음을 보여 준다 (AWS HealthOmics 2026).
이제 개념을 실제 분석 장면으로 바꿔 보자. 연구자가 BAM 파일을 S3에 두고 특정 유전자 근처 정렬 상태만 확인하고 싶을 때, 이상적인 경로는 간단하다. 인덱스가 함께 존재하고, 도구가 htslib를 통해 S3에 접근할 수 있다면, 필요한 좌표 범위만 읽어 와서 즉시 화면이나 파이프라인 다음 단계로 넘기면 된다. 이때 중요한 것은 “원격 파일을 열었다”가 아니라 “원격 파일의 필요한 일부만 읽었다”는 점이다. 클라우드 스트리밍의 경제성은 바로 여기에 있다.
CRAM에서는 한 가지 생각을 더해야 한다. CRAM은 참조 기반 압축 형식이므로, 구간을 해석하려면 참조 서열 접근 전략도 함께 설계해야 한다. 참조 FASTA를 로컬 캐시에 둘 수도 있고, 같은 S3나 공유 파일시스템에서 읽을 수도 있다. 따라서 CRAM 스트리밍은 BAM보다 저장 효율이 좋을 수 있지만, 참조 자원 위치까지 포함한 운영 설계가 필요하다. 학생은 이를 형식 비교 문제로만 볼 것이 아니라, 파일 + 인덱스 + 참조라는 세 요소가 함께 움직이는 시스템 문제로 이해해야 한다.
VCF와 BCF의 경우도 논리는 같다. 브라우저나 bcftools가 특정 locus의 변이만 확인할 때, 실제로는 vcf.gz 전체를 모두 옮기는 것이 아니라 인덱스를 따라 필요한 BGZF 블록만 읽어 온다. 따라서 cohort-scale VCF를 다룰수록 “클라우드에 두고 필요한 범위만 읽는 전략”이 더욱 자연스러워진다. 특히 공용 참조 변이 자원이나 반복해서 재사용되는 annotation 자산은 매번 프로젝트별로 복제하기보다, 공용 위치에 두고 질의하는 편이 훨씬 운영 친화적이다.
Table 3은 대표 파일 형식에서 스트리밍 접근이 특히 유리한 장면을 정리한 것이다. 이 표를 외우기보다, 어떤 분석 질문이 전체 파일 재작성인지, 어떤 질문이 특정 좌표 구간 조회인지를 구분하는 훈련이 더 중요하다.
Table 3. 클라우드 스트리밍이 잘 맞는 대표 사례
| 파일 형식 | 필요한 부속 자산 | 스트리밍이 유리한 작업 | 주의할 점 |
|---|---|---|---|
| BAM | .bai 또는 .csi |
특정 locus read 점검, QC spot check, IGV 시각화 | 인덱스 없으면 장점이 크게 줄어듦 |
| CRAM | .crai 또는 .csi, 참조 FASTA |
대형 정렬 자산의 저장비 절감과 구간 조회 | 참조 접근 경로를 함께 설계해야 함 |
| VCF.gz | .tbi 또는 .csi |
유전자 주변 variant 확인, 대상 구간 annotation | 압축과 인덱스가 함께 있어야 효율적 |
| BCF | .csi |
cohort-scale binary variant 질의 | 하위 도구의 BCF 지원 범위를 확인해야 함 |
클라우드 스트리밍이 항상 정답은 아니다. 가장 잘 맞는 상황은 분석 질문이 좁고, 파일이 크며, 여러 사용자가 같은 공용 자산을 반복해서 참조할 때다. 예를 들어 특정 변이 주변 read를 확인하거나, 패널 유전자 목록만 빠르게 훑거나, 브라우저에서 일부 구간만 시각화하는 작업은 스트리밍이 매우 자연스럽다. 같은 맥락에서 대형 reference BAM, CRAM, VCF를 여러 작업자가 공유한다면, 매번 로컬 복사본을 만들기보다 공용 S3 경로에서 필요한 부분만 읽는 편이 훨씬 간결하다.
반대로 전체 파일을 여러 번 순차 스캔해야 하거나, 도구가 htslib의 원격 접근을 제대로 지원하지 않거나, 같은 파일을 매우 자주 재사용하면서 네트워크 왕복이 병목이 되는 경우에는 한시적 로컬 staging이 더 나을 수 있다. 예를 들어 대규모 전수 계산에서 입력 파일 전체를 반복해 읽는다면, 한 번 내려받아 EBS나 로컬 scratch에 두는 편이 더 예측 가능한 성능을 보일 수 있다. 즉 문제는 “스트리밍 대 다운로드”의 이념 대결이 아니라, 접근 패턴과 반복 횟수와 도구 호환성의 문제다.
교육적으로 가장 중요한 결론은 다음과 같다. htslib의 S3 접근은 파일을 어디에 둘 것인가의 문제를 다시 쓰게 만들었다. 예전에는 클라우드 객체를 분석 도구가 직접 읽지 못하면, 사실상 모든 데이터 전략이 로컬 복사로 수렴했다. 이제는 공용 자산은 S3에 두고, 인덱스를 붙이고, 필요한 부분만 읽고, 정말 필요할 때만 로컬로 stage하는 혼합 전략이 훨씬 자연스럽다. 이 전환을 이해하면 다음 장에서 다룰 S3 마운트 도구가 왜 편리하면서도 근본 해결책은 아닐 수 있는지도 더 잘 보이게 된다.
samtools, bcftools, tabix, pysam 등 많은 도구가 공유하는 파일 접근 핵심 계층이다.