5장. EC2에서 시작하는 실전 분석 환경

학습 목표

오믹스 분석용 EC2 인스턴스를 선택하는 기본 기준을 설명할 수 있다.
스토리지와 네트워크를 고려한 실전 환경 구성을 이해할 수 있다.
SSH, 키 페어, 보안 그룹, 스크래치 디스크 운용의 기본을 설명할 수 있다.

핵심 질문

작은 실습과 대형 WGS 분석은 어떤 인스턴스가 다른가
임시 작업 디스크와 영구 저장 공간은 어떻게 나누는가
분석이 끝난 뒤 어떤 자원은 끄고 어떤 자원은 남겨야 하는가

EC2를 처음 다룰 때 초보자가 가장 자주 하는 실수는 “일단 큰 서버를 하나 띄워 보자”라고 생각하는 것이다. 그러나 실전에서는 인스턴스 크기보다 먼저 분석의 모양을 정리해야 한다. 지금 하려는 일이 유전체 정렬처럼 CPU를 오래 잡아먹는 작업인지, Hail이나 대형 annotation join처럼 메모리를 많이 쓰는 작업인지, 아니면 Jupyter와 소규모 QC처럼 균형형 자원으로 충분한 작업인지에 따라 출발점이 달라지기 때문이다. 따라서 첫 번째 EC2 인스턴스를 만든다는 말은 콘솔에서 버튼을 누르는 일이 아니라, 어떤 데이터를, 어느 리전에서, 어떤 저장소와 연결해, 얼마 동안 돌릴지를 먼저 결정하는 일에 가깝다.

오믹스 분석에서는 데이터와 계산을 같은 리전에 두는 것이 특히 중요하다. S3 버킷이 ap-northeast-2에 있는데 EC2는 다른 리전에 띄우면, 지연 시간과 데이터 이동 비용이 늘어나고 운영도 복잡해진다. 따라서 실습 단계부터 데이터가 있는 리전에서 계산을 띄운다는 원칙을 습관으로 만드는 편이 좋다. 첫 환경은 대개 다음과 같은 조합으로 충분하다. 운영체제는 범용 Linux AMI, 인스턴스는 m 또는 c 계열의 중간 크기, 루트 디스크와 작업용 EBS, 그리고 S3에 접근할 수 있는 IAM Role이다. 처음부터 화려한 구성을 만들기보다, 작게 시작해서 병목을 확인한 뒤 자원을 키우는 편이 훨씬 안전하다.

또 하나 중요한 점은 EC2를 “서버 한 대”로만 이해하지 않는 것이다. EC2 인스턴스는 계산 그 자체이고, 그 주변에는 키 페어, 보안 그룹, IAM Role, EBS 볼륨, CloudWatch 로그, S3 경로가 함께 움직인다. 즉 실전 분석 환경은 인스턴스 단품이 아니라, 계산·저장·권한·접속이 묶인 실행 단위다. 이 관점을 초기에 이해하면 나중에 Batch, ParallelCluster, HealthOmics 같은 상위 계층을 배우더라도 훨씬 자연스럽다.

인스턴스 패밀리 읽기 - `m`, `c`, `r`, `i`, `f`, `hpc`

Amazon EC2 인스턴스 이름은 복잡해 보이지만, 실은 병목을 어떻게 가정하는가를 드러내는 약속어에 가깝다. AWS 공식 문서는 인스턴스를 범용형, 컴퓨트 최적화형, 메모리 최적화형, 스토리지 최적화형, 가속형, HPC형으로 나눈다. 오믹스 분석자는 모든 세부 옵션을 외울 필요는 없지만, 적어도 m, c, r, i, f, hpc가 각각 어떤 종류의 병목을 겨냥하는지는 읽을 수 있어야 한다 (AWS 2026a).

가장 무난한 시작점은 m 계열이다. 노트북 서버, 소규모 샘플 테스트, 경량 QC, 교육용 실습처럼 CPU와 메모리 요구가 한쪽으로 심하게 기울지 않은 작업에 적합하다. 정렬, 단순 variant calling, batch QC, permutation test처럼 코어 수가 늘수록 비교적 곧바로 처리 시간이 줄어드는 작업은 c 계열이 더 잘 맞는다. 반대로 cohort aggregation, joint genotyping, 대형 annotation join, Hail 집계처럼 메모리가 먼저 바닥나는 단계는 r 계열을 우선 고려하는 편이 좋다. 즉 인스턴스 선택은 “더 비싼 서버를 사는 일”이 아니라, 병목이 CPU인지 메모리인지 I/O인지 판단하는 일이다.

i 계열과 d 계열처럼 로컬 스토리지 성능을 강조하는 인스턴스는 scratch-heavy workflow에서 강점을 보인다. 대용량 정렬 중간 파일, 반복적인 sort, shard 기반 분할 작업, 대형 temporary matrix 변환 같은 단계는 루트 디스크만으로 처리할 때보다 훨씬 안정적일 수 있다. 다만 여기서 중요한 점은 로컬 scratch가 곧 영구 저장소가 아니라는 사실이다. 빠르다는 이유로 모든 산물을 여기에 두면, 인스턴스 종료와 함께 결과를 잃거나 정리되지 않은 중간 파일만 쌓일 수 있다.

가속형 인스턴스는 더 조심해서 이해해야 한다. f 계열은 FPGA 같은 가속기를 활용하는 인스턴스인데, “가속기가 있으니 무조건 빠르다”는 뜻이 아니다. DRAGEN처럼 FPGA를 활용하도록 설계된 파이프라인은 최근 AWS HPC 블로그의 F2 평가 사례에서 매우 좋은 성능과 비용 효율을 보였지만, 일반적인 스크립트나 대부분의 오픈소스 도구는 자동으로 이 이득을 얻지 못한다 (AWS 2026f). hpc 계열 역시 모든 NGS 파이프라인의 기본 선택지가 아니라, EFA와 긴밀한 노드 간 통신이 중요한 계산이나 특수한 분산 알고리즘에 더 가깝다. 대부분의 연구실은 m 또는 c에서 시작해 실제 병목을 본 뒤 r, i, f, hpc로 이동하는 편이 더 현실적이다.

같은 패밀리 안에서도 세대와 접미사에 따라 실제 성능과 가격 구조가 달라진다. 예를 들어 c5는 Xeon 기반 5세대, c6i는 Ice Lake 기반 6세대, c7g는 Graviton3 기반 7세대, c8gd는 Graviton4 기반에 로컬 NVMe SSD가 포함된 최신 세대를 뜻한다. 표준 bwa/GATK 실행에는 c6i.8xlarge나 c7g.16xlarge가 무난하고, 정렬 sort와 shard 중심 작업에는 c7gd.8xlarge나 c8gd.16xlarge처럼 로컬 NVMe가 붙은 변형이 실질적인 차이를 만든다. 인스턴스 이름을 읽는 규칙과 구체적인 세대별 예시는 2장에서 자세히 다루므로, 실제 인스턴스 이름을 고를 때 그 표를 참고하면 된다.

Table 1. 오믹스 분석에서의 EC2 인스턴스 패밀리 첫 선택

인스턴스 패밀리	주된 병목	대표적인 유전체 작업
`m`	균형형	Jupyter, 소규모 QC, 교육용 분석 서버, 경량 파이프라인
`c`	CPU	정렬, 일반 variant calling, batch QC, permutation test
`r`	메모리	joint genotyping, cohort aggregation, Hail join, 대형 annotation
`i` / `d`	로컬 I/O	sort, shard 처리, scratch 중심 intermediate workflow
`f`	가속기	DRAGEN 같은 FPGA 활용 파이프라인
`hpc`	노드 간 통신	MPI형 계산, 특수한 tightly coupled 병렬 작업

보안 그룹, 키 페어, IAM Role 연결

초보자가 EC2를 어렵게 느끼는 이유 중 하나는 계산 자원보다 오히려 접속과 권한 구조가 낯설기 때문이다. 하지만 이를 세 부분으로 나누면 생각보다 단순하다. 키 페어는 서버에 SSH로 접속하기 위한 신분증이고, 보안 그룹은 어떤 네트워크 트래픽을 허용할지 정하는 방화벽이며, IAM Role은 인스턴스가 AWS 자원에 접근할 때 쓰는 권한 묶음이다. 세 요소는 서로 다른 문제를 해결한다. 키 페어가 “누가 서버 안으로 들어오느냐”를 정한다면, 보안 그룹은 “어떤 문을 열어 둘 것이냐”를 정하고, IAM Role은 “서버가 밖에 나가 무엇을 할 수 있느냐”를 정한다.

보안 그룹은 넓게 열어 둘수록 편해 보이지만, 실전에서는 최소한으로 열어 두는 습관이 중요하다. 예를 들어 개인 실습 서버라면 SSH 포트만 허용하고, 가능하면 특정 IP 범위로 제한하는 편이 낫다. 웹 기반 노트북이나 서비스가 필요할 때도 공개 인터넷 전체에 열기보다, 프록시나 제한된 접근 경로를 먼저 고려해야 한다. 유전체 데이터는 민감 정보를 포함할 수 있기 때문에, “어차피 테스트니까 대충 열어 둔다”는 습관은 나중에 더 큰 문제로 이어진다.

IAM Role은 더욱 중요하다. 여전히 많은 초보자가 액세스 키를 설정 파일이나 노트북에 직접 넣는 방식을 먼저 떠올리지만, AWS의 기본 권장 방식은 실행 주체에 Role을 붙여 임시 권한을 부여하는 것이다. 예를 들어 어떤 인스턴스가 s3://my-input-bucket/을 읽고 s3://my-output-bucket/에 결과를 쓰기만 하면 된다면, 그 범위만 허용하는 Role을 붙이는 것이 맞다. 이렇게 하면 장기 자격 증명을 파일에 보관할 필요가 없고, 누가 어떤 권한으로 작업했는지도 더 명확해진다 (AWS 2026c). 오믹스 분석에서 Role을 초반부터 정확히 익히는 것은 보안 문제를 넘어서 재현성과 운영 안정성을 위한 기본기다.

Table 2. EC2 실전 운영의 세 가지 기본 보안 구성요소

구성요소	역할	초보자가 자주 하는 실수
키 페어	SSH 접속용 인증 수단	키 파일을 여러 사람과 무분별하게 공유함
보안 그룹	인바운드/아웃바운드 네트워크 제어	SSH나 애플리케이션 포트를 전체 인터넷에 과도하게 개방함
IAM Role	인스턴스의 AWS 자원 접근 권한	액세스 키를 파일이나 코드에 하드코딩함

EBS 볼륨과 임시 스크래치 공간 운용

실전 분석 환경에서 저장소를 설계할 때 가장 중요한 질문은 “무엇을 오래 보관할 것인가”와 “무엇을 빨리 처리하고 버릴 것인가”를 구분하는 일이다. EBS는 EC2에 붙는 블록 스토리지이므로 운영체제 디스크, 분석 도구 설치, 작업 중 생성되는 중간 파일에 적합하다. 반면 장기 보관과 공유가 필요한 FASTQ, BAM, CRAM, VCF, 보고서, reference 자산은 S3에 두는 편이 자연스럽다. 초보자는 모든 데이터를 인스턴스 안에 넣고 시작하기 쉽지만, 그렇게 하면 서버가 곧 저장소가 되어 버리고, 분석이 끝났을 때 무엇을 지우고 남길지 판단하기 어려워진다.

실전에서는 최소한 세 층으로 나누어 생각하면 훨씬 단순해진다. 첫째, 루트 볼륨은 운영체제와 기본 도구를 위한 공간이다. 둘째, 별도 EBS 또는 로컬 NVMe scratch는 정렬·sort·temporary shard처럼 I/O가 많은 작업을 위한 작업대다. 셋째, S3는 원본과 결과를 남기는 영구 계층이다. 이 구조를 이해하면 “왜 인스턴스를 종료하기 전에 결과를 S3로 밀어야 하는가”가 자연스럽게 연결된다. 빠른 scratch는 계산을 위한 공간이지, 연구 자산을 영구 보관하는 장소가 아니다.

EBS의 볼륨 타입도 무작정 크게만 잡으면 되는 문제는 아니다. 일반적인 부팅 디스크나 보통의 분석 작업은 범용 SSD 기반 볼륨으로 충분한 경우가 많지만, IOPS와 처리량이 뚜렷한 병목인 workflow에서는 더 높은 성능의 볼륨 구성이 필요할 수 있다 (AWS 2026b). 그러나 교육 단계에서 더 중요한 것은 볼륨 타입의 세부 옵션보다 데이터 배치 원칙을 정확히 익히는 일이다. 즉 “원본은 S3, 실행 중 작업은 EBS 또는 scratch, 종료 전 결과는 S3”라는 기본 구조가 먼저다.

Table 3. 오믹스 분석에서의 데이터 배치 원칙

데이터 종류	우선 위치	이유
원시 FASTQ, 최종 BAM/CRAM, VCF	S3	장기 보관, 공유, 재사용에 유리함
정렬 중간 파일, sort 임시 파일	EBS 또는 로컬 scratch	높은 I/O와 짧은 수명에 적합함
운영체제, 패키지, 컨테이너 캐시	루트 EBS	인스턴스 부팅 및 실행 환경에 필요함
최종 리포트 사본, 로그 아카이브	S3	인스턴스 생명주기와 분리해 보존 가능함

비용을 아끼는 습관

EC2 비용 절감은 특별한 비법보다 운영 습관에서 갈리는 경우가 많다. 첫 번째 습관은 중지(stop)와 종료(terminate)를 구분하는 것이다. 인스턴스를 중지하면 계산은 멈추지만 EBS 볼륨은 그대로 남아 비용이 계속 발생한다. 따라서 다음 날 바로 이어서 작업할 서버라면 중지가 유용하지만, 분석이 끝났고 같은 환경을 다시 띄울 수 있다면 종료가 더 적절하다. 반대로 종료를 습관처럼 눌렀다가 scratch에만 있던 결과를 잃는 경우도 많다. 결국 비용 관리와 데이터 관리가 같은 문제라는 뜻이다.

두 번째 습관은 Spot Instance를 “싸지만 불안정한 자원”으로 정확히 이해하는 것이다. Spot은 온디맨드보다 훨씬 저렴할 수 있지만, 언제든 회수될 수 있으며 일반적으로 2분 interruption notice가 제공된다 (AWS 2026d; AWS 2026e). 따라서 긴 대화형 분석 서버나 중간 상태를 자주 저장하지 않는 작업에는 부적합할 수 있다. 반면 정렬 batch, permutation, Monte Carlo, 샘플 단위 QC처럼 중단에 견딜 수 있는 작업에는 매우 강력하다. 초보자는 보통 “싼 것이면 무조건 좋다”거나 “불안정하니 절대 쓰면 안 된다”는 두 극단으로 가는데, 실전에서는 작업 성격에 따라 나누어 쓰는 것이 핵심이다.

세 번째 습관은 눈에 보이지 않는 잔여 자원을 정리하는 것이다. 인스턴스를 껐는데도 EBS 스냅샷, 사용하지 않는 볼륨, 오래된 AMI, 불필요한 Elastic IP, 복사만 해 둔 대형 intermediate가 남아 비용을 만들 수 있다. 특히 오믹스 분석은 파일 크기가 크기 때문에 한 번의 정리 소홀함이 곧 큰 저장 비용으로 이어진다. 그래서 좋은 실전 규칙은 간단하다. 인스턴스 시작 전에는 무엇을 S3에 둘지를 정하고, 실행 중에는 중간 산물을 얼마나 오래 보관할지를 정하며, 종료 전에는 다음 주에도 필요한 자원인지를 점검하는 것이다.

Table 4. stop과 terminate의 실전 구분

선택	언제 적합한가	주의점
`stop`	내일 다시 접속해 같은 서버를 이어서 써야 할 때	EBS 비용은 계속 발생하고, 임시 scratch 전략이 흐려질 수 있음
`terminate`	분석이 끝났고 환경을 다시 만들 수 있을 때	인스턴스 내부에만 있던 파일은 사라지므로 먼저 S3로 내보내야 함

EC2를 잘 쓰는 사람은 가장 큰 인스턴스를 고르는 사람이 아니라, 병목에 맞는 인스턴스를 고르고, 저장 계층을 분리하고, 권한을 Role로 관리하고, 끝난 자원을 정리할 줄 아는 사람이다. 즉 실전 AWS 운용의 출발점은 화려한 서비스 조합이 아니라, 계산, 저장, 권한, 생명주기를 분리해 생각하는 습관이다. 이 기본기가 있어야 다음 장에서 다룰 자동화와 대규모 오케스트레이션도 비용과 재현성을 모두 잡는 방향으로 이어질 수 있다.