워크플로로서의 인프라: 정적인 Terraform을 넘어서

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Day 2 클라우드 운영을 관리합니다. 인프라를 상태를 가진 장기 실행 비즈니스 프로세스로 다루는 방법.

"코드형 인프라"의 한계: Day 1 대 Day 2

우리는 Terraform(IaC)을 사랑합니다. 이는 "Day 1" 프로비저닝 문제를 해결했습니다. 원하는 상태(EC2 인스턴스 10개, RDS 1개, VPC 1개)를 기술하고 terraform apply를 실행하면, 클라우드 프로바이더가 이를 실현해 줍니다. 이는 정적 리소스에 완벽합니다. 선언적이고, 멱등성이 있으며, 버전 관리가 가능합니다. 현대 DevOps의 초석입니다.

하지만 클라우드 운영의 현실은 복잡성이 존재하는 곳이 바로 Day 2라는 것입니다. Day 1은 결혼식이고, Day 2는 결혼 생활입니다. Day 2는 단순한 리소스(Resources)가 아니라 프로세스(Processes)에 관한 것입니다. 시스템이 시간이 지남에 따라 변화하는, 살아 숨 쉬는 생애주기에 관한 것입니다.

중요한 데이터베이스 업그레이드의 생애주기를 생각해 보세요. 이는 정적인 이벤트가 아니라 워크플로입니다:

1. 준비: 안전을 위해 프라이머리 DB를 S3에 스냅샷합니다.

2. 대기: 스냅샷이 완료될 때까지 기다려야 합니다. 수 테라바이트 규모의 대형 데이터베이스라면 30~45분이 걸릴 수 있습니다.

3. 프로비저닝: 스냅샷에서 새 엔진 버전을 사용해 새 DB 인스턴스를 구동합니다.

4. 대기: 새 인스턴스가 "사용 가능(Available)" 및 "정상(Healthy)" 상태가 될 때까지 기다립니다.

5. 마이그레이션: 새 인스턴스에 연결해 스키마 마이그레이션 스크립트(Flyway 또는 Liquibase)를 실행합니다. 1시간이 걸릴 수 있습니다.

6. 검증: 새 DB에 대해 일련의 스모크 테스트를 실행해 데이터 무결성을 확인합니다.

7. 전환: 성공하면 DNS CNAME을 업데이트해 새 DB를 가리키도록 합니다.

8. 롤백: 어느 단계라도 실패하면 DNS를 되돌리고 손상된 인스턴스를 폐기해야 합니다.

Terraform은 이를 표현할 수 없습니다. 이는 명령형이 아니라 선언형입니다. "30분 동안 대기"하는 방법이나 "SQL 스크립트를 실행하고 종료 코드를 확인"하는 방법을 알지 못합니다. 이를 처리하기 위해 팀들은 보통 Terraform을 Jenkins 파이프라인, CircleCI 작업, 또는 Python 스크립트로 감싸는 방식을 택합니다. 우리는 다시 "글루 코드 위기"(1부)로 돌아가지만, 이번에는 인프라를 위한 것입니다. 이러한 스크립트들은 취약하고 상태를 갖지 않으며, 4시간짜리 작업 도중에 실패하면 디버깅이 불가능합니다.

운영을 영속적 워크플로로 다루기

SchemaBridge에서는 인프라 운영이 곧 비즈니스 워크플로라고 믿습니다. 결제 처리 흐름과 동일한 요구사항, 즉 신뢰성, 감사 가능성, 상태 관리, 오류 복구가 필요합니다.

Day 2 운영을 SchemaBridge로 이전하면 클라우드를 위한 영속적 오케스트레이터의 힘을 얻게 됩니다:

"컨트롤 플레인" 패턴: AWS, K8s, Terraform과의 통합

SchemaBridge는 Terraform을 대체하지 않습니다. 이를 조율합니다. 우리는 컨트롤 플레인 패턴(Control Plane Pattern)을 사용해 정적인 세계와 동적인 세계를 통합합니다.

1. 트리거: 개발자가 코드를 커밋하거나 내부 개발자 포털(Backstage)에서 "개발 환경 프로비저닝" 워크플로를 수동으로 트리거합니다.

2. 프로비저닝: SchemaBridge가 Terraform Cloud API를 호출하거나(또는 보안 워커 내에서 terraform apply를 실행하여) 물리적 리소스를 생성합니다.

3. 대기: 워크플로는 실행이 안전하게 "적용됨(Applied)" 상태가 될 때까지 Terraform API를 폴링합니다. 클라우드의 비동기적 특성을 처리합니다.

4. 프로비저닝 이후 ("로직 계층"): 인프라가 존재하게 되면, SchemaBridge는 새 Kubernetes 클러스터에 연결해 DB 마이그레이션을 실행하고, 테스트 데이터를 시딩하며, 인수 테스트를 실행합니다.

이 패턴을 통해 리소스는 HCL(HashiCorp Configuration Language)로 정의된 채로 유지하면서, 운영 로직은 시각적 그래프로 정의할 수 있습니다.

임시 환경: 개발자 속도의 성배

모든 현대적인 엔지니어링 팀은 임시 환경(Ephemeral Environments)—모든 풀 리퀘스트(PR)마다 프로덕션의 완전한 복제본—을 원합니다. 이를 통해 진정한 격리가 가능해지고, 버그가 main 브랜치에 병합되기 전에 방지할 수 있습니다.

전통적인 접근 방식은 정리가 어렵기 때문에 실패합니다. PR-123을 위해 리소스를 구동했지만, 개발자가 PR 닫기를 잊어버리거나 정리 스크립트가 실패합니다. "좀비 RDS 인스턴스"와 "고아가 된 로드 밸런서"로 클라우드 비용이 폭증합니다.

SchemaBridge에서는 환경이 정의된 생애주기를 가진 워크플로입니다.

1. 시작: 리소스(RDS, Redis, ECS 서비스)를 구동합니다.

2. 대기: 워크플로가 대기 상태로 진입합니다. PR이 병합되거나 미리 정의된 TTL(예: 24시간)이 경과할 때까지 기다립니다.

3. 정리: 신호가 도착하거나 타이머가 만료되면, 워크플로는 자동으로 깨어나 terraform destroy를 실행합니다.

정리 로직이 생성 로직과 동일한 영속적 워크플로 인스턴스의 일부이기 때문에, 잊어버리는 것이 불가능합니다. SchemaBridge 클러스터 전체가 재시작되더라도, 오후 5시에 PR-123의 환경을 폐기해야 한다는 사실을 기억합니다. 이는 "클라우드를 위한 가비지 컬렉션"입니다.

사례 연구: 고빈도 매매를 위한 무개입 블루/그린 배포

우리는 핵심 매칭 엔진을 단 1마이크로초의 다운타임도 없이 업데이트해야 하는 고빈도 매매(HFT) 회사와 협업했습니다.

과제

표준 Kubernetes 롤링 업데이트는 충분히 안전하지 않았습니다. 트래픽을 전환하기 전에 새 버전의 재무적 정확성을 실시간 데이터로 10분간 검증해야 했기 때문입니다. 그들에게는 복잡한 "섀도 모드(Shadow Mode)" 배포가 필요했습니다.

SchemaBridge 솔루션

그들은 SchemaBridge에서 "블루/그린 배포 워크플로"를 구축했습니다:

1. 그린 배포: 기존 버전(Blue) 옆에 새 버전의 엔진(Green)을 구동합니다.

2. 섀도 트래픽: API 게이트웨이(9부)를 구성해 실시간 트래픽의 일반 복사본을 Green으로 전송합니다(파이어 앤 포겟 방식). Green의 응답은 사용자에게 전달되지 않지만 캡처됩니다.

3. 검증: 워크플로는 10분 동안 Green의 로그를 관찰했습니다. JSONata를 사용해 Green과 Blue(실시간 버전)의 재무적 출력을 비교했습니다.

4. 의사 결정 지점:

5. 전환: 워크플로가 로드 밸런서를 업데이트해 실제 사용자 트래픽을 Green으로 전환합니다.

6. 정리: 손쉬운 롤백을 위해 1시간을 더 기다린 후 Blue를 폐기합니다.

결과

그들은 배포 위험을 거의 0에 가깝게 줄였습니다. SRE 팀은 배포를 트리거하고 점심을 먹으러 갈 수 있었습니다. 워크플로가 복잡한 검증, 모니터링, 롤백 로직을 자동으로 처리한다는 것을 알고 있었기 때문입니다. 그들은 주당 1회 배포에서 하루 10회 배포로 전환했습니다.

비용 관리: FinOps의 "워크플로"

클라우드 비용 최적화(FinOps)는 흔히 개발자에게 리소스를 끄라고 잔소리하는 수동적인 프로세스입니다. SchemaBridge는 이러한 거버넌스를 자동화할 수 있게 해줍니다.

야간 파수꾼 패턴

매일 저녁 8시에 실행되는 "야간 파수꾼(Night Watchman)" 워크플로를 배포할 수 있습니다.

1. 스캔: 비프로덕션으로 태그된 모든 리소스를 격리합니다.

2. 활동 확인: 지난 1시간 동안 CPU 사용률이 5% 미만인지 CloudWatch 메트릭을 확인합니다.

3. 종료: 유휴 상태라면 인스턴스를 중지합니다(종료하지 않고).

4. 알림: 소유자에게 Slack 메시지를 보냅니다: "비용 절약을 위해 개발 서버를 일시 중지했습니다. 재개하려면 여기를 클릭하세요."

5. 재개: 아침에 개발자가 버튼을 클릭하면, 신호(7부)가 워크플로를 깨워 인스턴스를 다시 시작합니다.

이 간단한 워크플로 덕분에 한 엔터프라이즈 고객사는 AWS EC2 비용에서 월 4만 달러를 절감했습니다.

비교: Jenkins/GitLab CI 대 SchemaBridge 운영

| 기능 | CI/CD 파이프라인 (Jenkins) | SchemaBridge 운영 |

| :--- | :--- | :--- |

| 상태 | 일시적 (재시작 시 손실) | 영속적 (수년간 유지) |

| 지속 시간 | 분/시간 | 일/주/개월 |

| 로직 | 스크립트 (Bash/Groovy) | 시각적 (그래프) |

| 승인 | 기본 (UI 버튼) | 다양함 (Slack/이메일/Webhook/모바일) |

| 복구 | 처음부터 재시도 | 실패 지점에서 재개 |

| 병렬성 | 실행자 수에 제한됨 | 서버리스 스케일링 (3부) |

운영 자동화를 위한 전문가 체크리스트

운영 스택을 현대화하려면 다음 휴리스틱을 따르세요:

1. 대기 로직을 스크립트로 작성하지 마세요: ALB를 기다리기 위해 bash에서 sleep 60을 작성하고 있다면 잘못하고 있는 것입니다. 영속적 워크플로 내에서 폴링 루프를 사용하세요.

2. 삭제를 먼저 자동화하세요: 생성 로직 이전에 정리 로직을 작성하세요. 모든 생성 이벤트에 대응되는 폐기 경로가 있는지 확인하세요.

3. 승인 게이트를 사용하세요: 고위험 액션에 사람을 개입시키는 것을 두려워하지 마세요. "승인을 위한 일시 정지"는 버그가 아니라 기능입니다.

4. 운영자를 감사하세요: 누가 환경을 트리거했고 왜 그랬는지 기록하세요. 워크플로 컨텍스트를 사용해 요청자의 User_ID로 리소스를 태그하세요.

5. 운영을 코드로 다루세요: 애플리케이션 코드와 마찬가지로 운영 워크플로도 버전 관리하세요. SchemaBridge의 git 통합을 사용해 배포 로직의 변경 사항을 검토하세요.

결론: 클라우드는 상태 기계다

여러분의 인프라는 정적인 서버 더미가 아니라, 비즈니스의 살아 숨 쉬는 구성 요소입니다. 이를 상태 기계로 다룸으로써, SRE 팀의 삶을 소모하는 복잡한 다단계 운영 절차를 자동화할 수 있습니다. "티켓 기반 운영"에서 안전과 영속성이 내장된 "셀프서비스 운영"으로 전환할 수 있습니다.

12부에서는 "콜드 스타트 신화"를 살펴보고, 서버를 계속 워밍업 상태로 유지하지 않고도 서버리스 이벤트 아키텍처에서 밀리초 미만의 지연을 달성하는 방법을 다룹니다.

살펴보기