사내 인프라 플랫폼 배럭 구축기
안녕하세요, 비브로스 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 히스토리와 테크 문서를 뒤지며 "지난번에는 어떻게 했더라"를 다시 찾아야 하는 일이 비일비재하였습니다.
- AI가 만든 PR도 결국 사람이 다시 봐야 합니다. 최근에는 개발자가 AI 도구로 인프라 PR을 직접 만들어 오기도 하는데, 기존 컨벤션을 지키지 않은 경우가 있었고, 개발자와 운영자가 함께 확인해야 할 항목을 놓치는 일도 생겼습니다.
기존 방식(ASIS)과 배럭 도입 후(TOBE)의 요청 흐름
그럼 Backstage는?
사내 개발자 포털이라고 하면 가장 먼저 Backstage가 떠오릅니다. 저희도 Backstage를 이미 사용하고 있습니다. 다만 실제로 쓰는 기능은 문서(docs), API 문서, 서비스 카탈로그 정도였고, 위와 같은 인프라 신청·승인·배포 흐름을 Backstage 위에서 저희 입맛에 맞게 구성하기는 어려웠습니다.
그래서 별도 플랫폼을 직접 만들기로 하였습니다. 이때 기존에 하던 일을 그대로 UI에 붙이지 않는다 는 원칙을 세웠습니다. 티켓 양식을 웹 폼으로 옮기지 말고, 무엇을 물어야 하는지부터 다시 정하자고 했습니다.
배럭이란
이름은 스타크래프트의 배럭(Barracks, 병영)에서 가져왔습니다. 요즘 AI 플루토(Pluto) 덕분에 스타크래프트가 다시 인기인데, 병영에서 유닛을 찍어내듯 똑닥 서버·Kafka 토픽·권한 같은 인프라 리소스를 찍어내는 곳이라는 뜻입니다. 마스코트가 꿀벌인 이유도 열심히 찍어내는 SVC와 같은 의미입니다(?).
배럭은 인프라 요청을 신청 → 승인 → 배포로 잇는 사내 인프라 플랫폼 입니다. 개발자는 포털에서 유형별 폼으로 신청하고, 운영자는 배럭이 만들어 준 PR을 보고 승인하며, 승인 뒤의 배포는 기존 ArgoCD·Terraform 파이프라인이 그대로 수행합니다. 배럭이 하는 일을 정리하면 다음과 같습니다.
- 신청 카탈로그 : 똑닥 서버(API·Consumer·Batch), Kafka 토픽·ACL, AWS 권한·MongoDB 권한, 피크타임 스케일을 유형별 폼으로 신청. 네이밍 규칙과 환경별 기본값은 폼이 채워 줍니다.
- 승인과 배포 : 신청 즉시 봇 PR이 만들어지고, 운영자가 승인하면 기존 파이프라인으로 배포가 진행됩니다. 요청 상태와 이력은 포털 한 곳에 남습니다.
- 배포 이후 운영과 알림 : 앱 상태·파드 로그·배포 이력·롤백과 배치 실행 모니터링까지 포털 안에서 보고, 진행 알림은 사내 인프라 알림 서버를 거쳐 Slack으로 받습니다. 자세한 구성은 뒤에서 설명합니다.
반대로 배럭이 하지 않는 일도 분명합니다. Terraform apply나 Kubernetes 리소스 생성을 직접 실행하지 않고, 클라우드 자격증명도 들고 있지 않습니다. 이 선택이 왜 중요한지는 바로 다음 장에서 설명하겠습니다.
플랫폼 설계 시 고려하였던 점
1. 직접 실행할 것인가, 맡길 것인가
가장 먼저 정해야 했던 것은 "배럭이 배포를 직접 실행할 것인가"였습니다.
배럭이 직접 배포하는 방식
설명 : 배럭이 자격증명을 들고 배포를 직접 실행
장점 : 배포 과정 전체를 통제하므로 결과를 즉시 알 수 있고, 중간 단계가 없어 흐름이 단순함
단점 : 배럭이 AWS 자격증명과 클러스터 권한을 직접 보유해 보안 경계가 넓어지고, 기존 파이프라인의 검증(plan 리뷰, state 잠금, ArgoCD diff, 변경 이력)을 다시 만들어야 하며, 배럭 장애가 곧 배포 경로 장애가 됨
기존 파이프라인에 맡기는 방식
설명 : 배럭은 신청 내용을 코드 변경으로 바꿔 봇 PR을 만들고, 실제 배포는 이미 운영 중인 GitHub Actions(Terraform)와 ArgoCD가 수행
장점 : 검증된 Terraform·ArgoCD의 안정성을 그대로 이어받고, 배럭은 자격증명을 보유하지 않으며, 배럭이 멈춰도 배포 경로는 살아 있고, 모든 변경이 PR로 남아 리뷰·롤백이 가능함
단점 : 배포 결과를 GitHub Actions·ArgoCD 상태 폴링으로 추적해야 하고, 여러 신청이 같은 파일을 고칠 때 Git 충돌을 따로 처리해야 함
DevOps 팀에서는 기존 파이프라인에 맡기는 방식 을 선택하였습니다. 배포 API를 새로 만들지 않고, 지금 운영 중인 ArgoCD와 Terraform 배포 프로세스를 그대로 백엔드로 씁니다.
배럭은 컨트롤 플레인이지 배포 엔진이 아니다.
2. 설계부터 코드까지 AI-DLC로
PoC 기간을 2주로 잡은 만큼 설계와 구현 속도가 중요했습니다. 설계부터 코드까지는 AWS에서 공개한 AI-DLC(AI-Driven Development Life Cycle)로 진행하였습니다. 앞서 AI 모더레이터(유저 인터뷰 에이전트 개발기) 프로젝트에서 AWS의 AI-DLC를 사내 환경에 맞게 다듬어 쓴 적이 있어, 배럭도 같은 방식을 택했습니다.
요구사항 → 유저 스토리 → 설계 → 유닛 분해를 AI와 함께 진행하되 단계마다 제가 승인하는 방식으로, 설계 단계를 약 5시간 만에 마치고 유닛 4개의 코드를 8일 동안 순서대로 완성하였습니다. 결정 근거가 모두 레포에 남는 대신(커밋의 절반 이상이 설계·결정 기록), 그 문서를 관리하는 데에도 품이 들었습니다.
3. 컨벤션은 문서가 아니라 폼으로
네이밍 규칙과 기본값을 문서로 안내하는 대신 폼이 강제 하도록 만들었습니다. 도메인 유형을 고르면 규칙에 맞는 도메인이 채워지고, 차트 버전은 최신이 기본값이며, 수정·제거는 실제로 존재하는 리소스 목록에서 선택 합니다. 제출 전 "신청 확정" 창에서 현재 값과 신청 값을 비교하고 중복 신청은 자동으로 감지합니다. 목표는 잘못된 신청을 사람이 걸러내는 것이 아니라 잘못된 신청 자체가 만들어지지 않게 하는 것이었습니다.
신청 폼 — 도메인 유형을 고르면 규칙에 맞는 값이 자동으로 채워진다
4. 승인은 사람이, 그 이후는 자동으로
자동화의 목적은 승인을 없애는 것이 아니라 승인 이후를 사람 손에서 떼는 것 이라고 정의하였습니다. 신청이 들어오면 배럭은 바로 봇 PR을 만들고 운영자에게 알립니다. 운영자는 자기를 담당자로 배정한 뒤 PR 변경 내용과 Terraform plan을 확인하고, 코멘트와 함께 승인하거나 반려합니다. 승인하면 그다음은 배럭과 기존 파이프라인이 처리합니다.
- 똑닥 서버(API·Consumer·Batch)·피크타임 : 봇 PR 머지 → ArgoCD Sync → Healthy까지 상태 확인
- Kafka·AWS 권한·MongoDB 권한 : 봇 PR 머지 → 환경별 게이트 → Terraform apply. 권한은 관리(사내 운영 도구용) → 개발 → 스테이지 → 운영 순서로 진행하고, 앞 환경이 실패하면 뒤 환경은 시작하지 않음
운영 환경의 서버 배포는 기존 운영 정책 그대로 마지막 Sync를 사람이 한 번 누릅니다.
신청부터 완료까지 6단계 흐름과 요청 상태 (영문은 포털 표기)
처음 기획에서는 스테이지·운영 환경에 2인 승인을 두려 했지만, 승인 지연이 포털 사용 자체를 막을 것으로 판단해 운영자 승인 한 번 으로 바꾸고, 대신 기본 동작으로 안전장치를 넣었습니다.
- 담당자 배정 + 코멘트 필수 : 둘 다 있어야 승인·반려 버튼이 동작합니다. 원칙은 요청자와 승인자의 분리이고, 운영자가 자기 신청을 승인한 경우에는 감사 기록에 따로 표시됩니다
- plan 게이트 : Terraform plan이 성공하기 전에는 승인 버튼이 열리지 않음(판단이 안 되면 막는 쪽으로, fail-closed)
- 변경 감지(drift) 재승인 : 승인 때 본 plan과 배포 직전 plan의 요약이 다르면 다시 승인
- 배포 직렬화 : 같은 저장소·같은 환경에 대한 배포는 한 번에 하나씩
- 부분 실패 보존 : 여러 환경 중 실패한 환경만 재개
실패도 바로 사람에게 넘기지 않습니다. 일시적인 오류는 최대 3회 자동 재시도하고, 그래도 실패하면 "생성 실패"(승인 전)와 "배포 실패"(승인 후)로 나눠 원인 범주와 GitHub Actions 링크를 함께 보여 줍니다. 운영자는 실패한 환경만 사유를 남기고 다시 실행합니다.
요청 상세 — 신청부터 배포까지의 진행 상황과 봇 PR·배포 단계
5. 구성은 단순하게, 권한은 좁게
배럭 아키텍처
- 스택 : React(Vite + TypeScript) SPA, Go API 서버와 워커, PostgreSQL. 화면 응답은 API 서버가, 봇 PR 생성·배포 트리거·상태 폴링처럼 오래 걸리는 외부 작업은 워커가 맡습니다.
- 이력은 포털 한 곳에 : 신청마다 JIRA 티켓을 함께 만들던 연동은 이력이 두 곳에 나뉘어 쌓이는 탓에 제거하였습니다. 브랜치명과 PR 본문에서 배럭 요청으로 거슬러 갈 수 있게 함
- 알림 : 사내 인프라 알림 서버를 거쳐 Slack으로 보내고, 배럭은 Slack 봇 토큰을 보유하지 않음. 새 신청은 운영자 채널 스레드로 이어지고 버튼으로 담당자가 배정되며, 요청자는 접수·결과를 DM으로 받음. 승인·배포·권한 결정은 포털에서만
- 접근 제어 : Google 로그인(사내 계정만) 후 기본 권한 없음. 역할은 운영자만 부여할 수 있으며, 본인 권한은 스스로 바꿀 수 없음. 포털은 사내망에서만 접근
배럭이 만드는 봇 PR은 아래 규칙을 따릅니다. PR만 봐도 어떤 신청에서 왔는지 알 수 있습니다.
# 봇 PR 규칙
chore/<서비스>-<유형>-<작업>-<요청ID 8자리> ex) chore/dd-sample-api-api-create-a1b2c3d4
[인프라] <서비스> <유형> <작업> (<환경>)
barracks 셀프서비스 포털이 자동 생성한 PR입니다. 승인은 포털에서 진행됩니다(요청자↔승인자 분리).
플랫폼을 통한 목표
PoC — 2주 안에 반복 요청 세 가지를 셀프서비스로
PoC의 목표는 개발자가 직접 신청하고, 운영자가 승인하면 곧 배포되는 셀프서비스 를 가장 자주 들어오는 요청 세 가지(똑닥 서버 배포, Kafka 토픽·ACL, AWS 권한·MongoDB 권한)에 대해 2주 안에 완성하는 것이었습니다. 진행하면서 똑닥 서버를 API·Consumer·Batch로 나누고 피크타임 스케일이 더해져, 신청 카드는 6종이 되었습니다.
| 그룹 | 신청 유형 | 하는 일 |
|---|---|---|
| 서버 | API · Consumer · Batch | 똑닥 서버 배포·수정·제거, 오토스케일링·AWS 권한 구성, 배치 잡 추가·수정·제거 |
| Kafka | Kafka 리소스 | 토픽(이름·파티션·보존기간)과 ACL, 네이밍·파티션 정책 검증 |
| AWS | AWS 권한 · MongoDB 권한 | 서비스가 AWS 리소스·MongoDB Atlas에 접근할 권한 부여, 환경별 순차 적용 |
| AWS | 피크타임 | 요일·시간대별 파드 수 예약 스케일 (운영 전용) |
신청 카탈로그
배포 이후의 운영도 포털에서 할 수 있게 하였습니다. ArgoCD 앱 상태와 리소스 그래프, 파드 로그 검색과 실시간 스트림, 배포 이력, 롤백과 재시작을 리소스 관리 화면에서 제공합니다.
리소스 관리 — 리소스 그래프와 파드 로그
고도화 — 운영하며 넓히기
PoC를 마친 뒤에는 큰 기능을 새로 설계하기보다 사용자 피드백을 받아 조금씩 넓히는 방식 으로 고도화를 진행하고 있습니다. 초기 2주 동안 40여 건의 피드백을 반영한 것이 시작이었습니다.
가장 크게 달라진 곳은 배치입니다. 처음에는 배치 서버 신청만 받았는데, 지금은 Argo Workflows 배치를 포털에서 조회하고 즉시 실행·일시정지·재시도할 수 있고, Grafana와 연동한 실행 모니터링 패널도 포털 안에서 봅니다. 신청 쪽에서는 똑닥 서버를 신청하면 ECR 레포지토리가 함께 만들어지고, 권한 제거와 스테이지 MSK 토픽 신청이 새로 들어왔습니다. 되돌릴 수 없는 작업일수록 확인 절차를 두텁게 두어, MSK 토픽 삭제는 이름 재입력과 프로듀서·컨슈머·커넥터 정리 확인을 거쳐야 진행됩니다. 그 밖에 Viewer 역할, 즐겨찾기, 여러 서비스 일괄 Sync 같은 운영 편의 기능이 피드백을 따라 하나씩 추가되었습니다.
그래서 효과는?
티켓 시절에는 요청부터 배포까지 짧게는 5분, 길게는 담당자 부재로 하루 이상 걸렸습니다. PoC 도입 이후는 어떻게 달라졌을까요? 배럭은 신청과 동시에 봇 PR을 만들고 승인되면 바로 머지하므로, 봇 PR이 열린 뒤 머지되기까지가 "검토 → 승인" 시간입니다. 운영자 본인이 아닌 개발자들의 신청을 보면 절반 이상이 5분 안에 머지 되었습니다. 머지 이후 ArgoCD Sync·Terraform apply 시간은 빠져 있고, 티켓 시절은 같은 기준의 수치가 없어 직접 비교하지는 않았습니다.
신청(봇 PR 생성)부터 승인·머지까지 걸린 시간 분포 — 1시간 안에 처리된 요청 기준
PoC 이후 석 달 동안 배럭으로 처리된 요청은 약 65건이고, 월별 처리량은 8건 → 19건 → 37건으로 늘었습니다. 운영 환경 반영 요청도 배럭으로 처리하고 있습니다. 가장 많이 쓰인 유형은 배치 서버(배치 잡 추가·수정·제거) 로 전체의 약 절반이었고, 똑닥 서버 신청은 9월부터 본격적으로 들어오기 시작했습니다.
월별 처리된 요청 수 (테스트 신청 제외)
수치보다 크게 느끼는 변화는 요청자와 운영자의 역할이 분명해졌다는 점입니다.
제출하면 브랜치와 봇 PR이 자동으로 만들어지고 운영자에게 알림이 간다. 여기까지가 신청자가 할 일의 끝이다.
코드를 직접 쓰거나 apply를 직접 돌리는 일은 없다. 신청이 만들어 준 PR을 보고 판단하는 것이 승인 작업이다.
요청자는 요청 상세 타임라인으로 진행 상황을 보고 접수·결과는 Slack DM으로 받습니다. 운영자는 Slack 스레드로 진행 알림을 받고 버튼 한 번으로 담당자가 배정됩니다. 담당자가 바뀌어도 신청 내용과 PR, 승인 기록이 포털에 그대로 있어 히스토리를 뒤질 필요가 없습니다.
앞으로의 목표
다음 고도화 작업으로 생각하고 있는 것들입니다.
- Backstage에서 쓰던 기능 통합 : 지금 Backstage로 보고 있는 문서, API 문서, 서비스 카탈로그를 배럭에서도 볼 수 있게 구현
- 보안 플랫폼 내재화 : 통합 보안 시스템 플랫폼 연계 및 시스템 정책 점검
- 운영 지표 : 비용, 이상 탐지, DORA 메트릭
- 인프라 AI Agent 도입 : AI Agent를 통한 인프라 신청, 운영 질문을 대화로 처리
마치며
배럭을 만들면서 가장 어려웠던 것은 자동화 자체보다 배럭이 알고 있는 인프라와 실제 인프라를 맞추는 일 이었던 것 같습니다. 운영 환경의 Sync 정책처럼 사람은 당연하게 알고 있던 것들이 배럭에게는 하나하나 확인해야 할 전제였고, 그 전제가 어긋날 때마다 "모르면 추측하지 않고 멈춘다"는 안전장치(plan 게이트, 변경 감지 재승인 같은)를 하나씩 늘려 갔습니다.
그래도 이제는 "토픽 하나 만들어 주세요" DM 대신 포털 알림이 오고, 승인 버튼 하나로 배포가 시작됩니다. 담당자가 바뀌어도 신청·PR·승인 기록이 한 곳에 남아 있어 이어받기도 쉬워졌습니다. 그 덕분에 운영자는 반복 작업 대신 다음 단계를 고민할 시간을 조금씩 되찾고 있습니다.
플랫폼을 만들기 전에는 다른 길도 고민했습니다. 개발자가 AI 도구로 인프라 PR을 직접 올리고, 네이밍 규칙이나 환경별 기본값 같은 도메인 지식은 세컨드 브레인(AI가 참조하는 지식 저장소)에 쌓아 두는 방식입니다. 충분히 매력적인 접근이지만, 토큰이 만료되거나 AI 서비스에 장애가 나거나 폐쇄망처럼 AI를 쓸 수 없는 환경에서도 같은 일이 돌아가야 한다고 생각하면, 규칙을 폼과 게이트로 고정해 둔 플랫폼이 여전히 강력한 도구라고 봅니다. 두 방식은 서로를 대체하기보다 보완하는 관계에 가깝고, 앞으로의 AI Agent 도입도 이 플랫폼 위에서 진행할 생각입니다.
사내 인프라 플랫폼을 고민하시는 분들, 특히 이미 Terraform과 ArgoCD 같은 배포 파이프라인을 갖추고 계신 분들께 이 글이 조금이나마 도움이 되었으면 좋겠습니다.
마지막으로 잘못된 정보가 있다면 알려주시면 감사하겠습니다.
감사합니다! 😄