이노크라스의 AWS HealthOmics 기반 임상 유전체 파이프라인 운영 효율화 방안

서론

정밀의료 시대에 바이오마커 기반 표적치료는 암 치료의 핵심 전략으로 자리 잡고 있습니다. 실제 임상에서는 유전체 분석 결과를 바탕으로 치료 방침이 결정되기 때문에, 유전체 분석 검사의 신뢰성(Reliability)과 신속한 결과 제공(Turnaround Time, TAT)은 단순한 운영 성과 지표(KPI)가 아닙니다. 이는 환자의 치료 일정과 의료진의 임상 의사결정에 직접적인 영향을 미치는 핵심 제약 조건입니다. 그 사이를 채우는 것은 시퀀서가 생성한 수백 GB의 raw data를 환자 리포트로 전환하는 복잡한 멀티스텝 바이오인포매틱스 파이프라인이며, 이 과정에서 사람이 개입하는 모든 단계(실행 지시, 파라미터 적용, 실패 처리)는 샘플 누락과 지연의 잠재적 원인이 됩니다. 이러한 맥락에서 분석 파이프라인은 백엔드 인프라가 아니라 제품의 일부입니다.

이노크라스(Inocras)는 암 환자의 전장유전체 데이터를 분석해 암 진단과 치료 결정에 필요한 정보를 제공하는 기업으로, 이 제약을 조직의 운영 규율이 아니라 엔지니어링 요구사항으로 다룹니다. 이노크라스는 CancerVision™과 MRDVision™이라는 임상 진단 솔루션을 세계 각지의 의료진에게 제공하며, 이를 위하여 AWS HealthOmics를 포함한 AWS의 한국과 미국 리전에서 임상 분석 파이프라인을 운영하고 있습니다. 앞서 이노크라스는 AWS HealthOmics로 마이그레이션하여 분석 비용 72% 절감과 처리 속도 47% 개선을 달성한 바 있습니다(관련 블로그).

이번 블로그에서는 비용 절감과 속도 개선을 매일 반복 가능하게 만든 설계를 다루고자 합니다. “무엇을 달성했는가”를 넘어 이노크라스가 실제로 HealthOmics를 어떻게 구현하고 효율적으로 운영하는가에 초점을 맞춘 기술 심화편으로, 프로덕션 환경에 적용 중인 네 가지 요소를 소개합니다:

1. Amazon S3, Amazon EventBridge, HealthOmics를 결합한 End-to-End 관리 : TAT 준수와 휴먼 에러 최소화가 목표입니다.
2. Bitbucket + AWS CodePipeline + HealthOmics Git 통합을 활용한 GitOps 기반 배포 운영 : 워크플로 배포 과정에서도 사람의 개입을 최소화합니다.
3. 위 두 자동화 체계 위에서 확보하는 의료 데이터 보안·규제 컴플라이언스(HIPAA/PIPA).
4. HealthOmics Run Analyzer + Amazon Aurora MySQL을 결합한 지속가능한 비용 최적화.

아키텍처 개요

아래 다이어그램은 이노크라스의 Cancer Genomics 분석 플랫폼 전체 아키텍처를 보여줍니다.

다이어그램은 네 개의 평면으로 구성됩니다:

• 데이터 평면(자동화): Sequencer → S3 Input(SSE-S3) → EventBridge → Lambda(StartRun) → HealthOmics Workflow(Secondary → Tertiary → Annotation → QC) → S3 Output(SSE-S3) → 결과 전달/알림(SNS)
• 배포 평면(GitOps): Bitbucket → AWS CodeConnections → CodePipeline(lint → dry-run → 버전 생성) → HealthOmics Workflow Version
• 횡단 관심사(컴플라이언스): KMS 암호화, VPC Endpoint(PrivateLink), AWS SSO(IAM Identity Center) 기반 접근 통제, CloudTrail Data Events, EventBridge DLQ/Archive
• 최적화 평면(비용): HealthOmics Run Status Change 이벤트 → Lambda → ECS Fargate(Run Analyzer) → Aurora MySQL(KMS 암호화) → CloudWatch 대시보드

Section 1. TAT 준수와 휴먼 에러 최소화 : EventBridge 기반 End-to-End 관리

과제

이노크라스의 CancerVision™ 파이프라인은 단순한 실험과 연구가 아닌 실제 의료현장에서 활용되는 진단 리포트를 생성하는 데 사용됩니다. 이노크라스는 다음 두 가지를 자동화의 핵심 목표로 삼았습니다:

• TAT(Turn-Around-Time) 준수: 시퀀싱 데이터 도착 후 정해진 시간 내 결과 전달
• 휴먼 에러 최소화: 파이프라인 실행·체이닝·실패 처리 단계에 사람이 수동으로 개입함으로써 발생하는 오작업의 가능성을 최소화합니다.

이 두 목표를 달성하기 위해 다음 요구사항을 아키텍처에 반영했습니다:

• 무중단 운영: 다운타임 및 수동 개입을 최소화함으로써 달성
• 이벤트 유실 방지: 임상 결과 파이프라인은 단 한 건의 이벤트 드롭도 미처리 샘플로 이어져서는 안 됨

이벤트 기반 아키텍처 구현

이노크라스는 Amazon EventBridge를 활용하여 시퀀서 데이터 도착부터 환자 결과 전달까지 끊김 없이 이어지도록 하는 이벤트 기반 파이프라인을 구축했습니다.

파이프라인 흐름:

1. 데이터 수신: 시퀀서 또는 외부 검사실에서 FASTQ 파일이 Amazon S3 입력 버킷에 업로드됩니다. 입력 버킷은 SSE-S3(Amazon S3 관리형 키)로 암호화하며, 업로드 경로는 VPC Endpoint(PrivateLink)를 통해 퍼블릭 인터넷을 경유하지 않습니다.
2. 자동 트리거: 입력 버킷에서 Amazon EventBridge로의 이벤트 전송을 활성화하면(S3 버킷 속성의 “Amazon EventBridge” 옵션), 객체 생성 이벤트가 EventBridge로 발행됩니다. EventBridge 규칙이 접두사(prefix)·접미사(suffix) 조건으로 대상 FASTQ만 필터링하여 AWS Lambda 함수를 호출하고, Lambda가 HealthOmics 워크플로 실행(StartRun API)을 시작합니다.

참고 : S3 이벤트 전달 방식 두 가지: 과거의 “S3 Event Notification → Lambda 직접 호출” 방식과, 2021년 도입된 “S3 → EventBridge 통합” 방식이 있습니다. 이노크라스는 후자를 사용하여 EventBridge 규칙에서 세밀한 필터링과 팬아웃(fan-out)을 구현합니다(참고).

3. Secondary Analysis + 실행 태깅: StartRun 호출 시 run에 태그(workflow_type: secondary, sample_id: <익명 샘플 ID>)를 부여합니다. 이 태그는 이후 워크플로 체이닝의 분기 기준이 됩니다. HealthOmics가 정의된 컴퓨팅 자원을 on-demand로 프로비저닝하여 alignment, variant calling 등 secondary analysis가 수행될 수 있도록 합니다.
4. 워크플로 체이닝(run 구분 포함): HealthOmics는 run 상태가 바뀔 때마다 Run Status Change 이벤트를 EventBridge로 발행합니다. 다음 단계(tertiary analysis, annotation, QC)를 직전 secondary run이 완료됐을 때만 기동하려면, 계정 내 모든 완료 이벤트를 구분 없이 받아서는 안 됩니다. 이노크라스는 EventBridge 규칙으로 1차 필터링(status=COMPLETED, run ARN prefix)한 뒤, Lambda가 이벤트의 detail.arn으로 GetRun API를 호출해 태그(workflow_type)를 확인하고 체이닝 여부를 분기합니다.
5. 결과 전달 및 알림: 최종 분석이 완료되면 결과가 S3 출력 버킷(SSE-S3)에 저장되고, Amazon SNS를 통해 완료 알림이 전송됩니다.
6. 실패 처리: 워크플로 실패 시(status=FAILED) 즉시 알림이 발송됩니다. 아울러 EventBridge 규칙 대상과 Lambda 모두에 DLQ(Dead Letter Queue)를 연결하여, 다운스트림 오류(Lambda throttling, 권한 문제 등)로 인한 이벤트 유실을 방지합니다.

HealthOmics가 발행하는 두 가지 이벤트 구분

체이닝·완료 처리에는 Run Status Change를, GitOps 배포 검증(신규 워크플로 버전 생성 확인)에는 Workflow Status Change를 사용합니다. 두 이벤트를 혼동하면 잘못된 트리거로 이어지므로 규칙 설계 시 명확히 구분합니다(HealthOmics EventBridge 공식 문서).

EventBridge 규칙 예시(체이닝 1차 필터):

{
    "source": ["aws.omics"],
    "detail-type": ["Run Status Change"],
    "detail": {
      "status": ["COMPLETED"],
      "arn": [{ "prefix": "arn:aws:omics:ap-northeast-2:<ACCOUNT_ID>:run/" }]
    }
}

EventBridge 규칙 단계에서는 run 태그를 직접 필터링할 수 없습니다. 따라서 위 규칙으로 리전·계정·완료 상태까지 1차 필터링한 뒤, Lambda에서 GetRun으로 workflow_type 태그를 확인해 secondary → tertiary 여부를 최종 분기하는 2단계 필터링을 사용합니다.

신뢰성 강화 : 이벤트 유실 방지와 재처리

임상 파이프라인은 이벤트 한 건의 유실이 미처리 샘플로 이어질 수 있으므로, 다음 안전망을 함께 구성했습니다:

• DLQ(SQS): EventBridge 규칙 타겟과 Lambda 비동기 호출 실패 시 이벤트를 DLQ에 보관하여, 재시도 소진 후에도 이벤트가 사라지지 않도록 합니다.
• EventBridge Archive & Replay: 완료 이벤트를 아카이브에 보관하여, 파이프라인 버그 수정 후 지난 기간의 이벤트를 재생(replay)해 안전하게 재처리할 수 있습니다.
• Step Functions 오케스트레이션(선택적 진화 방향): secondary → tertiary → annotation → QC의 4단계 체이닝은 EventBridge 규칙만으로는 상태 추적·에러 핸들링·부분 재시도가 복잡해집니다. AWS는 여러 HealthOmics 워크플로를 대규모로 오케스트레이션할 때 Step Functions을 오케스트레이터로 두고 HealthOmics를 실행자로 분리하는 패턴을 권장합니다. 단계가 늘어날수록 이 패턴의 이점이 커집니다.

옵저버빌리티 : TAT 모니터링

임상 TAT 준수를 정량적으로 관리하기 위해 CloudWatch 대시보드로 run 완료 시간, 큐 대기 시간, 태스크별 지연을 시각화합니다. 워크플로 로그(/aws/omics/WorkflowLog)와 CloudWatch·Athena를 결합한 관찰 가능성 패턴은 Enhance monitoring and observability for AWS HealthOmics workflows를 참고했습니다.

기존 아키텍처와의 차별점

Section 2. 자동화된 배포 시스템 : GitOps 기반 워크플로 운영

과제

파이프라인 실행 자동화만으로는 충분하지 않습니다. 워크플로 자체를 업데이트하는 배포 과정에서는 버전 불일치·설정 누락 같은 휴먼 에러가 발생할 위험이 있습니다. 이노크라스는 한국과 미국에 걸친 multi-account 환경에서 워크플로의 일관성과 안정성을 유지해야 하며, 특히 파이프라인의 변경은 검사 결과에 영향을 줄 수 있으므로 배포 자동화 자체가 신중하게 설계되어야 합니다.

GitOps 기반 CI/CD 구현

이노크라스는 프로덕션 수준의 시스템 안정성과 multi-account 간 일관성 유지를 위해 전체 시스템에 CodePipeline 기반 GitOps를 운영하고 있습니다.

구성 요소:

• 소스 관리: Bitbucket 프라이빗 리포지토리에 워크플로 정의(WDL), 파라미터 템플릿, 테스트 데이터를 관리합니다.

참고 — 워크플로 정의 언어: HealthOmics는 WDL, Nextflow, CWL을 모두 지원하지만, 이노크라스는 모든 파이프라인을 WDL로 정의합니다. 다만 HealthOmics Run Analyzer의 자동 config 생성 기능(--write-config)은 현재 Nextflow 워크플로만 지원하므로, 이노크라스는 Run Analyzer가 산출한 추천 자원값(recommendedCpus/recommendedMemoryGiB)을 WDL 태스크의 runtime 블록에 직접 반영하는 방식으로 right-sizing을 적용합니다.

• HealthOmics Git 통합: AWS CodeConnection을 통해 Bitbucket 리포지토리를 HealthOmics에 직접 연결합니다. 이로써 zip 패키징 → S3 스테이징의 수동 단계가 제거됩니다.
• CI/CD 파이프라인: 코드가 커밋되면 AWS CodePipeline이 사람의 개입 없이 자동으로:
  1. 워크플로 정의의 문법 검증(lint)
  2. 테스트 데이터로 dry-run 실행
  3. 새 HealthOmics 워크플로 버전 생성 (Workflow Status Change 이벤트로 생성 성공 확인)
  4. dev 계정에서 검증 후 prod 계정으로 승격

버전 관리 전략:

main (prod) ←── release/v2.3 ←── feature/add-sv-calling

• feature/* → dev 계정 자동 배포 및 테스트
• release/* → staging 계정 검증
• main → prod 계정 배포 (수동 승인 게이트 포함)

추적성의 시작점:

검사실 프로세스에서는 샘플 접수 → 분석 → 보고서 발행의 연계성(chain of custody)이 요구됩니다. GitOps로 관리되는 워크플로 버전 이력은 이 추적성의 출발점이며, 검사실 정보 관리 시스템(LIMS/LIS)과의 연동을 포함한 구체적인 감사 체계는 Section 3에서 다룹니다.

운영 효과:

• HealthOmics의 워크플로 버전 기능을 사용해서 워크플로 수정 시 사람의 수동 대응 없이 즉각 롤백 가능 (이전의 워크플로 버전으로 StartRun 대상 전환)
• 모든 변경 사항의 감사(audit) 추적 (Git 커밋 히스토리 + CodePipeline 실행 기록)
• multi-account 간 워크플로 정의 드리프트(drift) 방지

Section 3. 워크플로 관리 자동화와 GitOps로 확보하는 의료 보안 컴플라이언스

Section 1과 2에서 설명한 이벤트 기반 자동화와 GitOps 운영은 운영 효율을 높이는 데서 그치지 않습니다. 워크플로 운영·관리 과정에 사람의 수동 개입을 최소화하고 모든 실행·배포 이력을 시스템이 자동으로 남기게 함으로써, 환자 유전체 데이터(PHI, 민감정보)를 다루는 파이프라인에 요구되는 컴플라이언스 통제의 기반이 됩니다. HealthOmics 자체는 HIPAA, HITRUST-CSF, FedRAMP Moderate, ISO/CSA STAR 등의 인증을 보유하지만(Compliance Validation), 서비스의 컴플라이언스가 고객 워크로드의 컴플라이언스를 자동으로 보장하지는 않습니다. 이노크라스는 다음 통제를 자동화·GitOps 아키텍처 위에 적용합니다.

계약·법적 기반

• AWS BAA(Business Associate Agreement): PHI를 처리하는 모든 HIPAA-eligible 서비스(HealthOmics, S3, Lambda, Aurora MySQL, EventBridge, SNS, ECS, CloudWatch Logs 등)를 BAA가 체결된 계정에서 사용합니다(HIPAA Eligible Services Reference).
• 한국 PIPA(개인정보보호법): 유전체 정보는 민감정보로 분류됩니다. 정보주체 동의, 처리 목적 제한, 제3자 제공 제한 원칙을 준수하고 한국 서비스용 데이터 거버넌스 정책을 별도로 유지합니다.

데이터 보호 통제

Secure Your Genomic Workflows and Data with AWS HealthOmics에서 제시하는 compute·storage·network 3중 격리 원칙을 기준으로 다음을 적용합니다:

감사 추적 및 데이터 거버넌스

Section 1의 자동화와 Section 2의 GitOps가 남기는 이력을 결합해 다음 감사 체계를 운영합니다:

• CloudTrail Data Events: S3 객체 접근(GetObject/PutObject)을 기록하여 “누가 어떤 샘플에 접근했는가”에 대한 전체 감사 추적을 확보합니다.
• HealthOmics Data Provenance: HealthOmics는 각 run의 입력 → 출력, 컨테이너 버전, 파라미터를 자동 기록합니다. 이 출처 정보를 임상 보고서와 연계하여 결과 재현성과 추적성을 보장합니다.
• GitOps 이력과 LIMS 연동: 워크플로 버전 변경 이력(Git 커밋 + CodePipeline 실행 기록)과 검사실 정보 관리 시스템(LIMS/LIS)의 샘플 접수 이벤트를 연계하여, “어떤 샘플이 어떤 워크플로 버전으로, 언제 분석되었는가”를 추적합니다.
• 환자 ID ↔ 샘플 ID 분리: run 태그·메타데이터·Aurora MySQL 테이블 키에 환자 식별 정보를 직접 사용하지 않고 익명 샘플 ID 체계를 사용합니다. 환자 매핑은 접근 통제된 LIMS에서만 관리합니다.

사람의 접근 통제: AWS SSO(IAM Identity Center)

이노크라스는 사람에게 개별 IAM 사용자 계정을 발급하지 않고, AWS IAM Identity Center(AWS SSO)를 통해 AWS 접근을 통제합니다. 인스턴스 점검 등 꼭 필요한 AWS 리소스 접근도 SSH 키나 별도 장기 자격증명(access key) 없이, AWS Systems Manager(SSM) Session Manager 등을 웹 콘솔에서 사용하는 방식으로만 이루어집니다. 모든 접근 이력은 CloudTrail에 기록되어 “누가 언제 어떤 리소스에 접근했는가”를 감사 가능한 형태로 남깁니다. 이 접근 통제 모델은 Section 1·2의 자동화·GitOps와 마찬가지로, 사람의 수동 개입 지점 자체를 줄여 휴먼 에러와 자격증명 유출 리스크를 함께 낮추는 설계입니다.

Section 4. 지속가능한 서비스를 위한 비용 최적화 : Run Analyzer + Aurora MySQL

과제

자동화(Section 1)와 GitOps(Section 2)로 안정적인 운영 체계를 갖추더라도, WGS 기반 Cancer Genomics 워크로드처럼 샘플당 수백 GB의 데이터를 처리하는 파이프라인은 자원 사용 효율이 서비스의 지속가능성을 좌우합니다. 태스크별 최적 자원 할당이 비용과 TAT에 직접적인 영향을 미치지만, 워크플로 내 개별 태스크의 실제 자원 사용률을 정량적으로 파악하기 어렵고, “경험치” 기반의 자원 할당은 과잉 프로비저닝 또는 OOM(Out of Memory) 실패로 이어집니다. 이노크라스는 지속가능한 서비스 운영을 위해 이 문제를 정량 데이터 기반으로 해결하고 있습니다.

Run Analyzer 활용

HealthOmics Run Analyzer는 오픈소스 CLI 도구로, 각 워크플로 실행(run)의 태스크별 25개 메트릭을 분석하여 최적 자원 할당을 추천합니다.

이노크라스는 Run Analyzer의 비용 예상 기능을 활용해 workflow별 비용·성능 최적화에 활용하고 있습니다.

주요 활용 기능:

Aurora MySQL 기반 비용 대시보드

이노크라스는 Run Analyzer 결과를 단순 일회성 분석에 머물지 않고, 지속적인 비용·성능 모니터링 체계로 확장했습니다.

구현 흐름:

1. 이벤트 수신: HealthOmics 워크플로 완료 이벤트(Run Status Change, status=COMPLETED)가 Lambda 함수를 트리거합니다.
2. Run Analyzer 실행 (ECS Fargate 위임): Lambda는 직접 분석을 수행하지 않고 Amazon ECS Fargate 태스크를 기동(RunTask)하여 Run Analyzer CLI를 실행합니다.

왜 Lambda가 아니라 Fargate인가: WGS 파이프라인은 태스크가 수십~수백 개에 달하고, 배치 분석 모드는 여러 run을 동시에 분석하므로 분석 시간이 Lambda의 15분 실행 한도를 초과할 위험이 있습니다. 또한 aws-healthomics-tools 등 CLI 의존성을 컨테이너 이미지로 관리하기에도 Fargate가 유리합니다. Lambda는 가벼운 “이벤트 수신·디스패처” 역할만 담당하고, 실제 분석은 시간 제약이 없는 Fargate가 수행합니다(Lambda→Fargate 트리거 패턴). 단일 run만 빠르게 분석하는 경우에는 Lambda를 유지하고, 배치 분석은 EventBridge Scheduler로 분리하는 절충안도 가능합니다.

3. Amazon Aurora MySQL 적재: Fargate 태스크가 산출한 태스크별 메트릭(CPU/메모리/스토리지 사용률, 실행 시간, 비용 추정)을 Aurora MySQL 테이블에 적재합니다. workflow_id, run_id, task_name을 복합 인덱스로 구성하여 워크플로별·태스크별 시계열 조회가 가능합니다.
4. 대시보드 및 알림: 적재된 데이터를 기반으로 워크플로별 비용 추이, 자원 사용률 트렌드, 이상치(예: 갑작스러운 비용 급증)를 모니터링합니다.

Aurora MySQL 테이블 스키마 예시:

CREATE TABLE workflow_task_metrics (
  workflow_id             VARCHAR(128) NOT NULL, -- 예: "cancervision-wgs-v2.3"
  run_id                  VARCHAR(64) NOT NULL,  -- 예: "run-abc123"
  task_name               VARCHAR(128) NOT NULL, -- 예: "alignment"
  estimated_cost_usd      DECIMAL(10,4),
  cpu_utilization_pct     DECIMAL(5,2),
  memory_utilization_pct  DECIMAL(5,2),
  storage_utilization_pct DECIMAL(5,2),
  duration_seconds        INT,
  recommended_cpu         INT,
  recommended_memory_gib  DECIMAL(6,2),
  created_at              TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (workflow_id, run_id, task_name),
  INDEX idx_workflow_created (workflow_id, created_at)
);

데이터 보호 주의: 이 테이블은 SSE-KMS(고객 관리형 키, CMK)로 저장 데이터를 암호화합니다. 또한 키·컬럼에 환자 식별 정보(PII/PHI)를 직접 포함하지 않도록 설계합니다. run_id·sample_id는 환자 ID와 분리된 익명 식별자를 사용하며, 환자 매핑은 접근 통제된 별도 시스템(LIMS)에서만 관리합니다(상세는 Section 3 참조).

Right-sizing 적용 사이클:

Run Analyzer 분석 → Aurora MySQL 적재 → 트렌드 분석 →
WDL runtime 블록 업데이트 → GitOps 배포 → 다음 run에서 효과 확인

이 사이클을 통해 이노크라스는 워크플로 버전 업데이트 시마다 정량 데이터에 기반한 자원 최적화를 반복 수행하고 있습니다.

추가 최적화 여지 : HealthOmics 네이티브 기능

Run Analyzer 기반 right-sizing 외에도 다음 HealthOmics 기능을 결합하면 비용·TAT를 추가로 개선할 수 있습니다:

• Run Cache: 동일 입력으로 재실행 시 중간 결과를 재사용합니다. 임상 QC 실패 후 파라미터만 수정해 재실행하는 시나리오에서 재계산 비용과 TAT를 크게 줄일 수 있습니다.
• HealthOmics Sequence Store: 대규모 유전체(게놈) 시퀀싱 데이터를 페타바이트 규모로 안전하고 효율적으로 저장·관리하기 위해 설계된 전용 클라우드 스토리지 공간으로, FASTQ, BAM, CRAM의 저장을 지원하고 파일의 무결성과 출처를 보존하며 자동 아카이빙 및 비용 절감이 가능합니다(기가베이스 기준 비용 부과). FASTQ를 일반 S3 대신 Sequence Store에 저장하면 유전체 특화 스토리지 비용 효율과 CRAM/BAM 관리 이점을 얻을 수 있습니다.
• 스토리지 타입 선택(DYNAMIC vs STATIC): 중간 파일 크기와 변동성이 큰 WGS 워크플로에는 사용량에 따라 자동으로 확장/축소되는 DYNAMIC이, 필요 용량이 예측 가능한 경우에는 고정 용량을 지정하는 STATIC이 유리할 수 있습니다. 워크플로 특성에 맞춰 선택 기준을 문서화하는 것을 권장합니다.

결과 및 교훈

네 가지 요소를 결합해 이노크라스는 다음과 같은 운영 효과를 달성했습니다:

• E2E 자동화: 시퀀서 데이터 도착부터 결과 전달까지 수동 개입을 축소하고, 임상 TAT를 안정적으로 준수하며 휴먼 에러를 최소화. 샘플 물량의 증가가 운영 인력의 증가로 직결되지 않는 구조입니다.
• 운영 안정성: GitOps 체계로 배포 과정의 휴먼 에러를 제거하고, 워크플로 변경에 따른 장애 리스크를 최소화하며, 즉각적 롤백이 가능한 체계 확보. 파이프라인 변경이 진단 결과에 미치는 영향을 버전 단위로 추적하고 되돌릴 수 있습니다.
• 컴플라이언스: 자동화·GitOps가 남기는 감사 추적을 기반으로 KMS 암호화·네트워크 격리·AWS SSO 기반 접근 통제 등 보안 규정 이행 제고. 감사 대응 자료가 별도 프로젝트의 산출물이 아니라 일상 운영이 남기는 부산물이 됩니다.
• 지속가능한 비용 최적화: Run Analyzer 기반 정량 데이터로 지속적 right-sizing 수행, 과잉 프로비저닝 제거. 샘플당 분석 단가를 지속적으로 낮출 여지를 확보해 서비스의 지속가능성을 뒷받침합니다.
• 운영 확장성: 컴퓨팅 자원을 사전 확보하지 않고, run 단위로 on-demand 프로비저닝합니다. 사전 용량 계획 없이 처리량이 크게 변동하는 워크로드까지 동일한 파이프라인으로 소화합니다.

핵심 교훈:

1. 이벤트 기반 체이닝에서는 “완료 이벤트”를 받는 것만으로는 부족하며, 어떤 run이 완료됐는지 구분하는 필터링 전략(태그 + GetRun)이 정확성을 좌우합니다.
2. 배포 자동화(GitOps)는 단순 CI/CD 도구 도입이 아니라, 사람이 개입하지 않고도 감사 가능한 이력을 남기는 것이 핵심이며, 이 이력이 곧 컴플라이언스의 근거가 됩니다.
3. 시간이 오래 걸리는 분석 작업(Run Analyzer 배치)은 Lambda 대신 Fargate로 위임하여 실행 시간 제약을 회피하는 것이 안정적입니다.
4. 임상 파이프라인에서 보안·규제는 후행 과제가 아니라, 자동화와 배포 설계 시점부터 내재되어야 하는 1급 요구사항입니다.

“관리형 서비스로 옮기면서 팀의 시간이 인프라 운영에서 임상 파이프라인의 정확도로 옮겨갔습니다. 워크플로별 비용을 태스크 단위까지 들여다볼 수 있게 되면서 자원 배분은 경험이 아니라 데이터로 결정하게 됐고, 자동화와 GitOps 덕분에 샘플 물량이 늘어도 TAT 약속과 감사 추적이 함께 흔들리지 않습니다.”

— 정다운, DevOps team lead, Inocras

결론

이노크라스가 AWS HealthOmics 위에 구축한 것은 개별 서비스의 조합이 아니라, 임상 등급 요구사항을 시스템의 기본 동작으로 만드는 구조입니다. TAT 준수는 담당자의 성실성이 아니라 이벤트 기반 자동화가 보장하고, 워크플로 버전의 추적성은 별도의 문서 작업이 아니라 GitOps 파이프라인이 남기며, 감사 대응 자료는 사후에 수집하는 것이 아니라 매 실행이 자동으로 축적합니다. 비용 최적화 역시 일회성 프로젝트가 아니라 run이 끝날 때마다 데이터가 쌓이는 상시 사이클로 동작합니다. 이노크라스는 TCGA 프로젝트 8,978 샘플과 유방암 연구 1,364 샘플 같은 대규모 코호트 분석부터, 아시아 전역 100개 이상의 암 전문 기관과 한국 약 30개 병원이 이용하는 서비스까지 모두 이 구조 위에서 운영하고 있습니다.

이 구조의 핵심은 관리형 실행 계층(HealthOmics) 위에 이벤트 기반 오케스트레이션과 GitOps를 올려, 사람의 개입 지점을 줄이는 것이 곧 품질·규제·비용 통제로 이어지도록 만든 데 있습니다. 유전체 분석뿐 아니라 대규모·규제 대상 데이터 처리 파이프라인을 프로덕션 수준으로 운영해야 하는 조직이라면 동일한 원칙을 적용할 수 있습니다.

유사한 유전체·임상 워크로드를 검토하고 있다면 AWS 계정팀에 문의하여 구체적인 적용 방안을 논의할 수 있습니다. AWS HealthOmics를 시작하고 심화하려면 다음 리소스를 참고하세요:

• AWS HealthOmics 시작하기
• HealthOmics Run Analyzer (GitHub)
• HealthOmics 워크플로 모니터링·관찰가능성 강화
• AWS HealthOmics로 유전체 워크플로·데이터 보안 확보하기
• Bioinformatics Workflow Development Using DevOps on AWS
• 이전 블로그: 이노크라스, AWS HealthOmics로 유전체 분석 비용 72% 절감

저자 소개