들어가며: 유전체 데이터, 왜 서버리스인가?
유전체 데이터는 인류의 건강과 질병을 이해하는 핵심 열쇠입니다. 하지만 그 규모는 상상을 초월합니다. 수천 명의 유전체를 분석하려면 테라바이트급 데이터를 다뤄야 하고, 연구자들은 이 거대한 데이터에서 특정 변이를 빠르게 찾아내야 합니다.
호주 국립과학기관 CSIRO는 이 문제를 서버리스(Serverless) 아키텍처로 해결했습니다. 바로 sBeacon(Serverless Beacon) 입니다. 이 글에서는 sBeacon이 어떻게 AWS의 관리형 서비스를 활용해 확장성, 비용 효율성, 보안을 동시에 달성했는지 분석합니다.
이 글은 AWS 아키텍처 블로그의 근거자료를 바탕으로 실무 인사이트를 재구성했습니다.

sBeacon 아키텍처 핵심: 데이터 온보딩과 쿼리 분리
sBeacon은 크게 데이터 온보딩(Data Onboarding) 과 데이터 쿼리(Data Querying) 두 프로세스로 나뉩니다. 핵심은 유전체 원본 데이터는 S3에 그대로 두고, 메타데이터만 인덱싱한다는 점입니다.
데이터 온보딩 흐름
- 사용자가 API Gateway로 유전체 데이터 위치와 메타데이터를 전송합니다.
- Lambda가 메타데이터를 ORC 포맷으로 S3에 저장합니다.
- Athena의 CTAS(CREATE TABLE AS SELECT) 쿼리로 메타데이터 테이블을 생성합니다.
- 온톨로지 인덱스(질병명, 해부학적 위치 등)를 별도로 구축합니다.
# Athena CTAS 쿼리 예시 (메타데이터 테이블 생성)
CREATE TABLE genomic_metadata
WITH (
format = 'ORC',
external_location = 's3://sbeacon-metadata/orc/'
) AS
SELECT * FROM raw_metadata
WHERE dataset_id = '1000genomes';
쿼리 실행 흐름 (Variant Querying Module)
사용자가 특정 유전 변이를 조회하면, Lambda가 팬아웃(fan-out) 방식으로 VCF 파일들을 병렬 처리합니다.
# performQuery Lambda의 핵심 로직 (의사코드)
def perform_query(vcf_s3_url, region):
# bcftools를 서브프로세스로 호출, S3에서 바이트 범위만 읽음
result = subprocess.run([
'bcftools', 'view',
vcf_s3_url,
'-r', region # 예: 'chr1:1000000-1010000'
], capture_output=True)
return parse_variants(result.stdout)
주목할 점은 bcftools가 S3 URL을 직접 읽는다는 것입니다. htslib의 HTTP 바이트 범위 요청을 활용해 쿼리당 약 1KB만 읽으므로, Lambda 메모리에 전체 VCF를 로드할 필요가 없습니다.

비용과 성능: 실제 숫자로 보는 sBeacon
1000 Genomes 프로젝트의 1번 염색체(2,504명 샘플)를 기준으로 측정한 결과입니다.
| 항목 | 측정값 | 비용 (USD) |
|---|---|---|
| 데이터 온보딩 (1회) | 18초 | 0.00052 |
| 쿼리 응답 시간 | 1.5초 내외 | 0.00013 / 쿼리 |
| 월간 유휴 비용 (메타데이터) | - | 0.000025 |
| 전체 게놈 저장 (S3) | - | 약 0.425 / 월 |
💡 실무 포인트: 쿼리 결과 변이 수가 4개에서 400개로 늘어나도 응답 시간은 1.5초 내외로 일정합니다. 팬아웃 구조 덕분에 병렬성이 확보되기 때문입니다.
보안: 제로 트러스트 모델
sBeacon은 Cognito 그룹 기반 RBAC를 적용합니다. 사용자 등급에 따라 반환되는 정보의 세분화 수준이 달라집니다.
boolean-access: 변이 존재 여부만 (true/false)count-access: 집계된 개수만record-access: 변이 상세 정보 + 샘플명admin-group: 데이터셋 관리 권한
이 설계의 핵심은 Lambda가 요청된 세분화 수준만 계산한다는 점입니다. boolean 등급 사용자의 요청에는 샘플 레벨 데이터가 아예 계산되지 않습니다.

주의사항 및 실무 적용 조언
한계와 주의점
- 전체 게놈 범위 쿼리는 타임아웃: API Gateway의 29초 제한에 걸립니다. 염색체 단위 이하의 범위 쿼리를 설계해야 합니다.
- Lambda 동시성 관리 필수: 팬아웃 쿼리가 계정의 동시성 풀을 고갈시킬 수 있습니다.
ConcurrentExecutions메트릭을 반드시 모니터링하세요. - 동기 호출의 함정: Lambda 동기 호출은 스로틀 시 자동 재시도가 없습니다.
Throttles메트릭에 CloudWatch 알람을 설정해 429 응답으로 인한 결과 유실을 방지해야 합니다. - 콜드 스타트: 유휴 후 버스트 쿼리 시 지연이 발생할 수 있습니다. 프로비저닝된 동시성을 고려하세요(비용 증가 주의).
국내 개발 생태계에서의 적용 맥락
국내 바이오/헬스케어 스타트업이나 병원 연구팀이 유전체 데이터를 다룰 때, sBeacon 아키텍처는 특히 유용합니다. 규제상 민감한 의료 데이터를 중앙 집중화하지 않고 각 기관이 소유한 S3 버킷에 그대로 두면서 연합 쿼리가 가능하기 때문입니다. 다만 국내 개인정보보호법과 생명윤리법 요건을 충족하려면 Cognito 인증 체계 위에 추가적인 감사 로깅과 접근 이력 관리가 필요합니다.
다음 단계 학습 방향
- GA4GH Beacon 프로토콜 스펙을 읽어보고, 자체 API 설계에 응용해 보세요.
- Terraform으로 인프라를 코드화하는 패턴을 익히면, 유사한 서버리스 데이터 서비스 구축에 바로 적용할 수 있습니다.
- 대규모 데이터셋을 다룬다면, AWS의 NVIDIA TensorRT Edge-LLM 분석처럼 도메인 특화 최적화 사례도 함께 살펴보시길 권합니다.
함께 보면 좋은 글
- Claude가 Azure에 공식 입성! Microsoft Foundry에서 바로 쓰는 법과 실무 포인트
- NVIDIA TensorRT Edge-LLM 자율주행과 휴머노이드 로봇을 위한 엣지 AI 런타임 완전 분석
유전체 데이터처럼 크고 민감한 데이터를 다룰 때, 서버리스 아키텍처는 강력한 선택지입니다. 다만 동시성, 타임아웃, 보안 경계를 명확히 설계해야 실무에서 안정적으로 운영할 수 있다는 점, 꼭 기억하세요! 😊