안녕하세요 HN! 저희는 인프라 자동화 플랫폼인 Massdriver(https://www.massdriver.cloud/)의 창업자 Cory, Dave, Chris입니다. Massdriver는 조직의 표준을 강제하고 일관되며 규정을 준수하는 배포를 제공합니다. 더 이상 끝없는 승인 절차, 관료주의적 규제(red tape), 또는 망가진 Terraform 플랜은 필요 없습니다.

데모 영상은 여기 있습니다: https://www.youtube.com/watch?v=m6T5p0qXcFE&t=4s

코드형 인프라 (Infrastructure as Code (IaC)) 워크플로우는 개발자를 돕기 위해 설계되었으며 소규모 팀에게는 잘 작동하지만, 조직이 확장됨에 따라 병목 현상, 복잡성, 그리고 끝없는 문제 해결(firefighting)을 야기합니다.

운영(ops) 및 플랫폼 엔지니어링 분야에서 수십 년을 보내며, 저희는 똑같은 문제들에 계속 직면했습니다. 즉, 취약한 파이프라인(Terraform 변수와 입력 확인은 너무 늦기 전까지 오류를 잡아내지 못함), 미흡한 규정 준수(compliance) 통합(문제가 CI/CD 단계에서 발견되지만, 그때는 이미 지연과 재작업이 불가피함), 그리고 개발자들이 강제로 배워야만 하는 도구들의 짜깁기(Terraform, Kubernetes 매니페스트, 클라우드 API)입니다. 이는 더 많은 업무를 추가하고, 개발자들이 가치를 전달해야 할 시점에 주니어 데브옵스(devops) 엔지니어로 전락하게 만듭니다.

저희는 사이드 프로젝트를 진행하던 중 스파이더맨이 서로를 가리키는 밈(Spider-Man pointing-meme) 같은 상황을 겪게 되었습니다. 두 명의 숙련된 운영 전문가가 모두 인프라를 건드리고 싶어 하지 않는 상황이었죠. 저희는 왜 그런지 묻기 시작했습니다. '지루한 부분들'은 단순히 지루한 것이 아니라, 특히 규모가 커질수록 시간이 많이 소요되고 오류가 발생하기 쉬웠습니다. 만약 우리가 단순히 프로비저닝(provisioning)을 자동화하는 것을 넘어, 모든 번거로운 작업들(권한, 규정 준수, 네트워킹, 보안 그룹)을 사전에 처리한다면 어떨까요? 그때 저희는 운영 지식을 모듈에 직접 인코딩하여 개발자들이 그 모듈을 기반으로 작업할 수 있게 만들 수 있다는 것을 깨달았습니다.

어려운 점은 단순히 기술적인 문제만이 아니라, 사회 기술적 (socio-technical)인 문제입니다. Conway’s Law (콘웨이의 법칙)는 피할 수 없으며, 개발, 운영, 그리고 클라우드 API가 교차하는 지점에서 그 영향이 가장 고통스럽게 나타납니다. 모두가 클라우드의 복잡성에 대해 이야기하지만, 진짜 과제는 도구, 팀, 그리고 프로세스가 뒤섞인 복잡한 교차점을 헤쳐 나가는 것입니다. 운영 (Ops) 팀은 통제권을 원하고, 개발자 (Devs)는 속도를 원하며, 컴플라이언스 (Compliance)는 그들 사이에서 마찰을 일으킵니다.

전통적인 해결책은 GitOps나 사후적 가드레일 (retroactive guardrails)과 같은 임시방편적인 솔루션이었지만, 이러한 방식은 복잡성을 제거하기보다 단순히 위치를 옮기는 경향이 있습니다. 이는 종종 끊임없이 확장되는 CI/CD 툴체인 (toolchain)으로 이어지며, 팀들은 정책을 강제하고 인프라를 검증하기 위해서만 복잡한 워크플로우를 유지해야 하므로, 마찰을 줄이기보다는 오히려 가중시키게 됩니다. 저희는 진짜 과제가 개발자에게는 충분히 단순하면서도 운영 팀에게는 충분히 강력한 추상화 (abstractions)를 설계하는 것이라고 생각합니다.

Massdriver를 통해 운영 팀은 프로비저닝 (provisioning), 권한 (permissions), 컴플라이언스 (compliance), 그리고 비용 제약 조건을 모두 처리하는 재사용 가능한 인프라 모듈을 정의할 수 있습니다. 개발자는 IaC (Infrastructure as Code)를 작성하거나 클라우드 API를 탐색할 필요가 없습니다. 그저 아키텍처를 설명하는 다이어그램을 그리면, Massdriver가 해당 모듈을 사용하여 리소스를 프로비저닝합니다. 컴플라이언스와 보안 규칙은 선제적으로 강제되며, 휘발성 (ephemeral) CI/CD 파이프라인이 자동으로 생성됩니다. 그 결과, 더 이상 취약한 파이프라인이나 막바지에 급히 적용하는 가드레일은 필요하지 않습니다.

작동 방식:

(1) 저희는 IaC를 기능적 모듈로 전환합니다: Terraform/OpenTofu, Helm 또는 CloudFormation과 같은 도구를 사용하여 시각화 및 셀프 서비스 (self-service)를 위한 메타데이터, 정책, 내장된 검증 기능이 포함된 재사용 가능한 모듈을 생성합니다.

(2) 파이프라인을 통해 IaC 코드를 계속 밀어넣는 방식 중단: Git 저장소에서 구성 변경 사항을 관리하는 대신, 패키징되어 배포 준비가 된 '릴리스(release)'로서 모듈을 생성합니다. 각 릴리스에는 IaC와 정책 도구(예: Checkov, OPA)가 모두 포함되어 있어, 개발자가 별도의 워크플로우를 복사하거나 유지 관리할 필요가 없습니다. 이러한 검증은 Massdriver의 일시적(ephemeral) CI/CD 프로세스의 일부로 자동 적용되므로, 이를 우회하는 것이 불가능합니다.

(3) API 및 시각적 도구를 통한 셀프 서비스 (self-service): 저수준(low-level) IaC 코드나 취약한 YAML 파이프라인을 직접 다룰 필요 없이, 사전 승인된 모듈과 상호작용하여 인프라를 프로비저닝(provision)합니다.

Massdriver는 현재 운영 중이며, IaC 문제에 대한 저희의 접근 방식에 대한 여러분의 의견을 듣고 싶습니다. 저희가 구성 관리(configuration management)를 어떻게 단순화하는지 더 자세히 알고 싶으시다면, 데모 영상을 확인해 주세요. 링크는 다음과 같습니다: https://www.youtube.com/watch?v=m6T5p0qXcFE&t=4s

읽어주셔서 감사합니다. 여러분의 생각을 듣게 되어 매우 기쁩니다!