Runops (YC W21) 출시: 프로덕션 앱을 위한 개선된 클라우드 셸

안녕하세요 HN! Runops.io의 Andrios입니다. 저희는 터미널에서 실행하는 명령어에 Git 기능, Slack에서의 코드 리뷰, 그리고 결과에서 민감한 데이터를 제거하는 기능을 추가하는 프록시를 구축하고 있습니다. 이는 GCP/AWS의 클라우드 셸과 유사하지만, 더 많은 기능을 제공하며 사용자의 로컬 zsh/bash 터미널을 이용합니다.

사용자가 AWS CLI 명령어를 터미널에서 실행하면 Runops로 전달되고, 이 명령어는 AWS로 전송되기 전에 Git에 추가되고 (필요한 경우) Slack에서 동료 리뷰를 거칩니다. 실행된 후에는 민감한 데이터가 모두 마스킹되어 결과가 터미널로 다시 제공됩니다. 이는 AWS, Kubernetes, 데이터베이스 등 다양한 환경에서 작동합니다.

저는 한 핀테크 회사(pismo.io/en)의 인프라 팀을 이끌었으며, 모든 개발자에게 프로덕션 환경에서의 자율성을 부여하고 싶었습니다. 하지만 규정 준수 요구 사항 때문에 직접적인 접근 권한을 줄 수 없었습니다. 해결책은 소수의 사람들(제 팀)이 프로덕션 시스템에 '전체 접근 권한'을 갖는 것이었습니다. 엔지니어들은 프로덕션에서 일회성 스크립트를 실행해야 할 때 저희에게 요청했습니다. 우리의 목표는 다른 팀들이 무언가를 하도록 저희에게 요청할 필요가 없도록 자동화를 제공하는 것이었습니다. 규정 준수, 보안 및 신뢰성을 갖추면서 그들이 직접 수행할 수 있는 방법을 구축하고자 했습니다.

하지만 잘 되지 않았습니다. 우리는 요청 대기열을 처리하는 데 80%의 시간을 쓰고, 자동화 구축에 20%만 쓸 수 있었습니다. 백로그는 항상 증가했고, 팀은 번아웃 상태였습니다. 엔지니어들은 자신들의 요청 처리에 시간이 오래 걸리는 것에 불만을 느꼈고, 고객들 역시 그들에게 화를 냈습니다.

하지만 이 과정에서 몇 가지 좋은 자동화가 나왔습니다. 예를 들어, 잘못된 쿼리를 방지하기 위해 임시 프로덕션 데이터베이스 읽기 작업을 검토해야 했습니다. 그래서 우리는 Flyway를 사용하여 코드 리뷰 후 Git으로부터 SQL 쿼리를 실행하는 Jenkins 파이프라인을 구축했습니다. 이제 모든 엔지니어는 누가, 언제, 왜 해당 쿼리를 했는지에 대한 추적 기록과 함께 프로덕션에서 쿼리를 실행할 수 있게 되었습니다.

유사한 기업의 친구들과 이야기를 나누면서, 이 문제가 훨씬 더 심각하다는 것을 알게 되었습니다. 그들 중 일부는 자동화를 시도조차 하지 않고 있었고, 이미 이러한 스크립트를 실행하기 위한 전담 인력, 즉 운영 팀 (Ops team)을 별도로 두고 있었습니다. 저는 더 나은 방법이 있다는 것을 알았기에, 그것을 만들기 위해 나섰습니다. 저는 작년 중반에 직장을 그만두었고, 다시 직장을 구해야 하기 전까지 이 일을 성공시키기 위해 약 8개월 치의 저축액을 가지고 시작했습니다. 저는 엔지니어였기에 영업, 마케팅, 제품 관리 (Product management)를 실전에서 직접 배워야 했기에 초기에는 힘들었지만, 첫 몇 명의 고객을 확보한 후에는 상황이 나아지기 시작했습니다.

Runops의 목표는 보안과 컴플라이언스 (Compliance)를 최대한 자동화하여, 어떤 엔지니어라도 마치 모든 권한을 가진 것처럼 프로덕션 (Production) 환경에서 무엇이든 실행할 수 있도록 하는 것입니다. 인간의 상호작용이 필요한 경우에는 Slack을 사용하여 이를 동기식 (Synchronous)으로 처리합니다. 이제 단일 팀이 병목 현상 (Bottleneck)이 되는 대신, 모든 사람이 프로덕션에서 작업을 수행할 수 있습니다. AWS, Kubernetes, 그리고 데이터베이스에 대한 대부분의 액세스 권한을 가진 팀을 중앙 집중화하는 것은 좋지 않습니다. 이는 Jira나 다른 도구들을 사용하는 느린 변경 관리 (Change Management) 프로세스를 만들고, 마지막에는 수동 실행을 수반하게 합니다. Runops는 전문가(인프라, DBA, 보안 등)의 빠른 검토를 추가할 수 있게 해주며, 실행을 자동화합니다.

주요 인터페이스는 CLI이며, 여기서 SQL 쿼리부터 kubectl exec 및 AWS CLI 명령에 이르기까지 다양한 스크립트를 실행합니다. 저희는 새로운 추상화 (Abstractions)를 만들지 않습니다. 여러분은 기존에 사용 가능한 것과 동일한 명령어와 문서를 사용하며, 저희는 단지 이를 프록시 (Proxy)할 뿐입니다. 좋은 이점 중 하나는 VPN과 오늘날 필요로 하는 10가지의 클라이언트 도구/자격 증명 (Credentials)을 대체할 수 있다는 점입니다. 또한 저희는 다양한 언어로 된 커스텀 액션 (Custom actions)을 위한 템플릿도 지원합니다.

저희는 명령 실행을 위해 Github Actions를 사용하여 이를 구축했습니다. 설정과 자격 증명 (Credentials)은 Actions Secrets로 저장되며, 명령 실행 시 필요한 경우 주입됩니다. Docker 컨테이너에서 실행 가능한 것이라면 무엇이든 15초 미만 내에 실행할 수 있다는 점이 매우 유용합니다. 저희는 실시간 프록시 (Real-time proxy)를 생성하여 Actions를 넘어 기능을 개선할 계획을 가지고 있습니다. 이를 통해 REPL과 유사한 경험을 제공할 수 있을 것입니다.

Runops는 웹 인터페이스를 제공하지 않으며, 이는 의도된 설계입니다. 엔지니어들이 배워야 할 또 하나의 도구가 되고 싶지 않기 때문입니다. 대부분의 상호작용은 저희의 CLI 또는 Slack을 통해 이루어집니다. Retool을 통해 간단한 관리자 UI (Admin UI)를 제공하고 있습니다.

저희는 모든 것을 Lisp을 사용하여 수행합니다. CLI는 Clojurescript를 사용하고, REST API는 Clojure를 사용합니다. 모든 곳에서 동일한 언어를 사용하는 것은 매우 좋으며, Lisp은 또한 환상적인 이점입니다.

현재 대형 핀테크 (Fintechs) 기업들이 Runops를 사용하고 있습니다. 이들은 개발자들이 Kubernetes 포드 (Pods) 내부에서 Rails Runner 및 Elixir IEx, SQL 쿼리, DynamoDB 쿼리를 실행하고, cURL을 사용하여 프라이빗 네트워크 (Private networks) 내에서 내부 API 호출을 수행할 수 있도록 하기 위해 Runops를 사용합니다. 이 제품을 만들면서 가장 좋았던 점 중 하나는 개발자들이 더 많은 프로덕션 (Production) 작업을 수행하는 것을 보는 것이었습니다. 모든 개발자에게 이 정도 수준의 자율성을 부여하는 것을 고려조차 하지 않았던 규제 대상 기업들이 마음을 바꾸고 있습니다. 도구가 문화를 변화시키고 신뢰를 높이는 것을 보는 것은 매우 멋진 일입니다.

이 내용을 여러분 모두에게 보여드릴 수 있게 되어 정말 기쁩니다. 읽어주셔서 감사합니다! 여러분의 생각과 질문을 알려주세요.