티켓으로 받던 똑닥 서버·Kafka·AWS 권한 요청을 개발자가 직접 신청하고 운영자가 승인하면 곧 기존 ArgoCD·Terraform 파이프라인으로 배포되게 만든 사내 인프라 플랫폼 배럭의 PoC와 고도화 기록입니다. ||
안녕하세요, 비브로스 DevOps 박진홍입니다.
똑닥 서비스를 운영하다 보면 "토픽 하나 만들어 주세요", "서버 하나 올려 주세요", "이 버킷 권한 좀 주세요" 같은 인프라 요청이 매일 티켓으로 DevOps에 들어옵니다. 하나하나는 어렵지 않지만, 그때마다 운영자가 코드를 고치고 PR을 올리고 배포하는 일을 반복해 왔습니다.
배럭(Barracks) 은 개발자가 이 요청을 직접 신청하고, 운영자가 승인하면 곧바로 배포까지 이어지도록 만든 사내 인프라 플랫폼입니다. 배포 시스템을 새로 만들지는 않았습니다. 이미 운영 중인 ArgoCD(약 400개 Apps 운영)와 Terraform 파이프라인(AWS, Kafka, QueryPie, GitHub, MongoDB)은 그대로 두고, 그 앞에 신청과 승인 단계를 붙여 개발자가 직접 요청할 수 있게 했습니다. 올해 7월, 2주 완성을 목표로 PoC를 시작했고, 지금은 똑닥 서버 배포, Kafka 토픽·ACL, AWS·MongoDB 권한, 배치와 피크타임 스케일까지 포털에서 처리합니다.
이번 글에서는 왜, 어떻게 만들었는지 와 그래서 무엇이 좋아졌는지 를 중점적으로 다루고, PoC부터 현재 진행 중인 고도화 작업까지의 과정을 정리하였습니다.
인프라 티켓 또 너야?
똑닥 인프라는 무엇으로 돌아가나
먼저 비브로스가 어떤 인프라 위에서 똑닥을 운영하고 있는지부터 짚고 가겠습니다. 똑닥 서비스는 AWS EKS 위에서 Helm 차트와 ArgoCD로 배포하고, 인프라 리소스는 Terraform과 GitHub Actions로 관리합니다. 그 위에 오토스케일링(Karpenter·HPA), 모니터링(Prometheus·Thanos·Grafana), 로깅(Loki), 트레이싱(Tempo), 시크릿·DNS·인증서 관리(External Secrets·External DNS·Cert-Manager) 같은 오픈소스를 올려 쓰고 있습니다. 데이터 쪽은 Kafka를 Confluent Cloud와 Amazon MSK로, 데이터베이스는 MongoDB Atlas와 RDS를 사용합니다.
구성 요소가 많다 보니 개발팀이 새 기능을 만들 때마다 인프라 쪽에도 손이 갑니다. 새 서버를 올리려면 ArgoCD App과 Helm values를 만들어야 하고, 이벤트를 하나 발행하려면 Kafka 토픽과 ACL이 필요하며, S3나 MongoDB·RDS에 접근하려면 그 서비스에 맞는 권한을 붙여야 합니다.
반복되는 인프라 요청
개발팀이 DevOps에 요청하는 인프라 작업은 대부분 비슷한 모양을 하고 있습니다.
똑닥 서버 배포 — 새 API 서버, 컨슈머, 배치를 클러스터에 올리기 위한 ArgoCD App과 Helm values 구성
Kafka 토픽 생성과 ACL 부여 — 새 이벤트를 발행하거나 구독할 때마다
AWS 권한·MongoDB 권한 부여 — 서비스가 S3·SQS 같은 AWS 리소스나 MongoDB Atlas에 접근할 때마다
요청은 JIRA 티켓 또는 Slack으로 받고, 운영자가 Terraform 코드나 매니페스트를 직접 고쳐 PR을 올리고 배포하는 방식이었습니다. 운영자가 자리에 있으면 짧게는 5분 만에 끝나지만, 회의 중이거나 부재중이면 하루 이상 걸리기도 했습니다.
무엇이 문제였나
리드타임보다 더 크게 느낀 문제는 네 가지였습니다.
운영자의 시간이 반복 작업에 묶입니다. 난이도는 높지 않은데 빈도가 높은 일들이 안정성이나 아키텍처 고도화에 써야 할 시간을 계속 잘라먹었습니다.
요청자는 진행 상황을 알 수 없습니다. 내 요청이 어디까지 왔는지 확인할 방법이 티켓 댓글과 DM뿐이었습니다.
작업 방법이 사람에게 묶여 있습니다. 담당자가 퇴사하거나 부재중일 때 다른 사람이 그 작업을 이어받으려면, 지난 PR 히스토리와 테크 문서를 뒤지며 "지난번에는 어떻게 했


