배럭: 인프라 요청을 폼과 봇 PR로 바꾼 사내 플랫폼¶

출처: 사내 인프라 플랫폼 배럭 구축기
저자: 박진홍 (비브로스 DevOps)
발행: 2026-10-05, 비브로스 기술 블로그 (최종 수정 2026-10-06)
환경: AWS EKS + Helm + ArgoCD(약 400개 App), Terraform + GitHub Actions(AWS, Kafka, QueryPie, GitHub, MongoDB 대상), Kafka는 Confluent Cloud와 Amazon MSK, DB는 MongoDB Atlas와 RDS
배럭 스택: React(Vite + TypeScript) SPA, Go API 서버와 워커, PostgreSQL, Google 로그인
읽은 날짜: 2026-10-07
태그: #PlatformEngineering #GitOps #ArgoCD #Terraform #셀프서비스 #승인게이트 #DevOps

한 줄 요약¶

배포 시스템은 새로 만들지 않고, 기존 ArgoCD·Terraform 파이프라인 앞에 신청 폼과 승인 단계를 붙였다. 배럭은 신청을 봇 PR로 바꾸고 승인 뒤 머지만 하며, 자격증명을 들고 있지 않다. 저자의 표현으로 "배럭은 컨트롤 플레인이지 배포 엔진이 아니다."

문제: 반복되는 인프라 티켓¶

개발팀 요청은 대부분 세 가지 모양이었다.

똑닥 서버 배포: 새 API 서버, 컨슈머, 배치를 올리기 위한 ArgoCD App과 Helm values 구성
Kafka 토픽 생성과 ACL 부여
AWS 권한과 MongoDB 권한 부여

JIRA 티켓이나 Slack으로 받아 운영자가 Terraform 코드나 매니페스트를 고쳐 PR을 올렸다. 운영자가 자리에 있으면 5분, 회의나 부재면 하루 이상 걸렸다.

저자는 리드타임보다 아래 네 가지가 더 큰 문제였다고 쓴다.

문제	내용
운영자 시간	난이도는 낮고 빈도는 높은 일이 안정성·아키텍처 작업 시간을 잠식
진행 상황 불투명	요청자가 확인할 수단이 티켓 댓글과 DM뿐
작업 방법의 사람 의존	담당자 부재 시 지난 PR 히스토리와 문서를 다시 뒤짐
AI가 만든 PR	개발자가 AI 도구로 올린 인프라 PR이 컨벤션을 어기거나 확인 항목을 놓침

Backstage는 이미 쓰고 있었지만 실제로 쓰는 기능은 문서, API 문서, 서비스 카탈로그 정도였고, 신청·승인·배포 흐름을 그 위에 맞춰 짜기 어려워 별도 플랫폼을 만들었다. 이때 세운 원칙은 "기존에 하던 일을 그대로 UI에 붙이지 않는다" 이다. 티켓 양식을 웹 폼으로 옮기지 말고 무엇을 물어야 하는지부터 다시 정했다.

배럭이 하는 일과 하지 않는 일¶

구분	내용
신청 카탈로그	유형별 폼. 네이밍 규칙과 환경별 기본값은 폼이 채운다
승인과 배포	신청 즉시 봇 PR 생성, 운영자 승인 뒤 기존 파이프라인이 배포
배포 이후 운영	앱 상태, 파드 로그, 배포 이력, 롤백, 배치 실행 모니터링
하지 않는 일	Terraform apply와 Kubernetes 리소스 생성을 직접 실행하지 않음. 클라우드 자격증명을 보유하지 않음

설계 판단 다섯 가지¶

1. 직접 실행하지 않고 기존 파이프라인에 맡긴다¶

기준	배럭이 직접 배포	기존 파이프라인에 위임 (채택)
흐름	단순, 결과를 즉시 앎	결과를 GitHub Actions·ArgoCD 상태 폴링으로 추적
보안 경계	AWS 자격증명과 클러스터 권한을 보유	자격증명 미보유
검증	plan 리뷰, state 잠금, ArgoCD diff, 변경 이력을 다시 만들어야 함	기존 검증을 그대로 이어받음
장애 격리	배럭 장애가 곧 배포 경로 장애	배럭이 멈춰도 배포 경로는 살아 있음
추가 부담	없음	여러 신청이 같은 파일을 고칠 때 Git 충돌 처리

모든 변경이 PR로 남으므로 리뷰와 롤백이 기존 방식 그대로 된다.

2. AI-DLC로 설계부터 코드까지¶

AWS가 공개한 AI-DLC(AI-Driven Development Life Cycle)를 썼다. 요구사항, 유저 스토리, 설계, 유닛 분해를 AI와 진행하되 단계마다 저자가 승인했다. 설계 약 5시간, 유닛 4개 구현 8일. 커밋의 절반 이상이 설계·결정 기록이었고, 그 문서를 관리하는 데에도 품이 들었다고 적었다.

3. 컨벤션은 문서가 아니라 폼이 강제한다¶

도메인 유형을 고르면 규칙에 맞는 도메인이 채워짐
차트 버전은 최신이 기본값
수정·제거는 실제로 존재하는 리소스 목록에서만 선택
제출 전 "신청 확정" 창에서 현재 값과 신청 값을 비교
중복 신청 자동 감지

목표는 잘못된 신청을 사람이 걸러내는 것이 아니라 잘못된 신청 자체가 만들어지지 않게 하는 것이다.

4. 승인은 사람이, 그 이후는 자동으로¶

자동화의 목적을 "승인을 없애는 것이 아니라 승인 이후를 사람 손에서 떼는 것"으로 정의했다.

신청 ─▶ 봇 PR 생성 ─▶ 운영자 담당자 배정 ─▶ PR diff·Terraform plan 확인 ─▶ 승인(코멘트 필수)
                                                                              │
             ┌────────────────────────────────────────────────────────────────┘
             ▼
  서버·피크타임   : PR 머지 ─▶ ArgoCD Sync ─▶ Healthy 확인 (운영 환경은 마지막 Sync를 사람이 누름)
  Kafka·AWS·Mongo : PR 머지 ─▶ 환경별 게이트 ─▶ Terraform apply
                    관리 ─▶ 개발 ─▶ 스테이지 ─▶ 운영 (앞 환경이 실패하면 뒤 환경은 시작하지 않음)

처음엔 스테이지·운영에 2인 승인을 두려 했으나 승인 지연이 포털 사용 자체를 막을 것으로 보고 운영자 승인 1회로 바꿨다. 대신 기본 동작으로 안전장치를 넣었다.

안전장치	동작
담당자 배정 + 코멘트 필수	둘 다 있어야 승인·반려 버튼이 동작. 운영자가 자기 신청을 승인하면 감사 기록에 따로 표시
plan 게이트	Terraform plan 성공 전에는 승인 버튼이 열리지 않음 (fail-closed)
변경 감지(drift) 재승인	승인 때 본 plan과 배포 직전 plan의 요약이 다르면 다시 승인
배포 직렬화	같은 저장소·같은 환경 배포는 한 번에 하나
부분 실패 보존	여러 환경 중 실패한 환경만 재개

실패 처리: 일시 오류는 최대 3회 자동 재시도. 그래도 실패하면 "생성 실패"(승인 전)와 "배포 실패"(승인 후)로 나눠 원인 범주와 GitHub Actions 링크를 보여 준다. 운영자는 실패한 환경만 사유를 남기고 재실행한다.

5. 구성은 단순하게, 권한은 좁게¶

역할 분리: 화면 응답은 API 서버, 봇 PR 생성·배포 트리거·상태 폴링 같은 오래 걸리는 외부 작업은 워커
이력은 한 곳에: 신청마다 JIRA 티켓을 만들던 연동을 이력이 두 곳에 갈린다는 이유로 제거. 브랜치명과 PR 본문으로 배럭 요청을 역추적
알림: 사내 인프라 알림 서버를 거쳐 Slack으로. 배럭은 Slack 봇 토큰을 갖지 않는다. 승인·배포·권한 결정은 포털에서만
접근 제어: 사내 Google 계정 로그인 후 기본 권한 없음. 역할은 운영자만 부여하고 본인 권한은 스스로 못 바꿈. 사내망에서만 접근

봇 PR 규칙은 PR만 보고 출처 신청을 알 수 있게 짜여 있다.

브랜치: chore/<서비스>-<유형>-<작업>-<요청ID 8자리>     예) chore/dd-sample-api-api-create-a1b2c3d4
제목:   [인프라] <서비스> <유형> <작업> (<환경>)
본문:   barracks 셀프서비스 포털이 자동 생성한 PR입니다. 승인은 포털에서 진행됩니다(요청자↔승인자 분리).

신청 카탈로그¶

PoC 목표는 가장 잦은 요청 세 가지(서버 배포, Kafka, AWS·MongoDB 권한)를 2주 안에 셀프서비스로 만드는 것이었다. 진행하며 서버를 API·Consumer·Batch로 나누고 피크타임 스케일을 더해 카드가 6종이 됐다.

그룹	신청 유형	하는 일
서버	API, Consumer, Batch	서버 배포·수정·제거, 오토스케일링·AWS 권한 구성, 배치 잡 추가·수정·제거
Kafka	Kafka 리소스	토픽(이름·파티션·보존기간)과 ACL, 네이밍·파티션 정책 검증
AWS	AWS 권한, MongoDB 권한	서비스의 AWS 리소스·MongoDB Atlas 접근 권한, 환경별 순차 적용
AWS	피크타임	요일·시간대별 파드 수 예약 스케일 (운영 전용)

고도화: 큰 설계 대신 피드백으로 넓히기¶

PoC 직후 2주 동안 피드백 40여 건을 반영했다. 주요 변화는 다음과 같다.

배치: 신청만 받던 것에서 Argo Workflows 배치 조회, 즉시 실행·일시정지·재시도, Grafana 연동 실행 모니터링까지
신청 확장: 서버 신청 시 ECR 레포지토리 동시 생성, 권한 제거, 스테이지 MSK 토픽 신청
되돌릴 수 없는 작업의 확인 강화: MSK 토픽 삭제는 이름 재입력과 프로듀서·컨슈머·커넥터 정리 확인을 거쳐야 진행
편의 기능: Viewer 역할, 즐겨찾기, 여러 서비스 일괄 Sync

효과¶

지표	값	측정 기준
승인까지 시간	개발자 신청의 절반 이상이 5분 안에 머지	봇 PR이 열린 시점부터 머지까지. 운영자 본인 신청 제외
누적 처리량	약 65건	PoC 이후 석 달, 테스트 신청 제외
월별 처리량	8건, 19건, 37건	월별
최다 유형	배치 서버 (전체의 약 절반)	서버 신청은 9월부터 본격 유입

정성적 변화로 저자가 가장 크게 꼽은 것은 역할 경계다. 신청자 일은 "제출"에서 끝나고, 운영자 일은 "신청이 만든 PR을 보고 판단"으로 줄었다. 담당자가 바뀌어도 신청·PR·승인 기록이 포털에 남는다.

앞으로의 계획¶

Backstage에서 보던 문서, API 문서, 서비스 카탈로그를 배럭으로 통합
통합 보안 플랫폼 연계와 시스템 정책 점검
운영 지표: 비용, 이상 탐지, DORA 메트릭
인프라 AI Agent: 신청과 운영 질문을 대화로 처리. 이 플랫폼 위에서 진행할 계획

마치며: 가장 어려웠던 것¶

자동화 자체보다 배럭이 알고 있는 인프라와 실제 인프라를 맞추는 일이 어려웠다고 한다. 운영 환경 Sync 정책처럼 사람에겐 당연한 것이 배럭에겐 하나하나 확인할 전제였고, 전제가 어긋날 때마다 "모르면 추측하지 않고 멈춘다"는 안전장치(plan 게이트, 변경 감지 재승인)를 늘렸다.

플랫폼 대신 검토한 길도 있었다. 개발자가 AI 도구로 인프라 PR을 직접 올리고, 네이밍 규칙과 기본값 같은 도메인 지식은 AI가 참조하는 지식 저장소(세컨드 브레인)에 쌓는 방식이다. 저자는 토큰 만료, AI 서비스 장애, 폐쇄망처럼 AI를 쓸 수 없는 환경에서도 같은 일이 돌아가야 한다는 이유로 규칙을 폼과 게이트로 고정한 플랫폼을 택했고, 두 방식은 대체가 아니라 보완 관계라고 정리한다.

읽을 때 감안할 것¶

"5분 안에 머지"는 리드타임이 아니다. 봇 PR 생성부터 머지까지만 잰 값으로, 머지 이후 ArgoCD Sync와 Terraform apply 시간은 빠져 있다. 저자도 이를 밝힌다.
비교 기준선이 없다. 티켓 시절은 같은 기준의 수치가 없어 직접 비교하지 않았다고 명시한다. "5분에서 하루 이상"은 서술이지 측정값이 아니다.
분포 그림의 표본이 걸러져 있다. 시간 분포 그림은 "1시간 안에 처리된 요청 기준"이다. 1시간을 넘긴 요청이 빠져 있으므로 그림만으로 꼬리를 판단할 수 없다.
월별 증가에는 기능 추가가 섞여 있다. 8, 19, 37건 증가는 사용 확산과 함께 카탈로그 확장(서버 신청이 9월부터 본격 유입)의 영향을 받는다. 요청당 효과로 읽으면 안 된다. 표본도 3개월 65건으로 작다.
요청자와 승인자 분리는 강제가 아니라 기록이다. 운영자가 자기 신청을 승인하는 것은 막지 않고 감사 기록에 표시만 한다.
비용 측면 정보가 없다. 배럭 자체의 운영·유지 비용, 상태 폴링 부하, Git 충돌 빈도는 다루지 않는다.

가져갈 지점¶

실행 권한은 기존 경로에 남기고, 새 계층은 의도와 승인만 다룬다. 새 시스템이 자격증명을 갖지 않으면 그 시스템의 장애와 침해가 실행 경로로 번지지 않는다. 에이전트가 인프라나 데이터를 바꾸는 도구를 설계할 때도 같은 구조가 적용된다. 에이전트는 변경안(PR)을 만들고, 실행은 검증된 파이프라인이 맡는다.
fail-closed 게이트와 drift 재승인. "승인 시점에 본 것"과 "실행 직전 상태"의 요약을 비교해 다르면 다시 묻는다. 사람 승인을 거치는 에이전트 행동(Human-in-the-loop)에서 승인 뒤 상태가 바뀌는 문제를 그대로 막는 패턴이다.
규칙을 문서가 아니라 입력 단계에 박는다. 존재하는 리소스만 고르게 하고 기본값을 채우면 검토자가 잡아야 할 오류의 종류가 줄어든다. LLM 도구 호출에서 자유 문자열 대신 열거형과 실제 목록을 주는 것과 같은 발상이다.
AI 의존 경로와 결정적 경로의 분리. 저자가 AI 직접 PR 방식을 접은 근거(토큰 만료, 서비스 장애, 폐쇄망)는 결정적 규칙 계층을 바닥에 두고 AI를 그 위에 얹으라는 설계 원칙으로 일반화된다.
추적 키를 산출물 이름에 넣는다. 브랜치명 끝의 요청 ID 8자리 덕분에 별도 연동(JIRA) 없이도 PR에서 원 신청으로 거슬러 갈 수 있다.

결론¶

플랫폼 엔지니어링 사례로 읽으면 화려한 기능보다 경계 설정이 핵심인 글이다. 무엇을 하지 않을지(직접 배포, 자격증명 보유, 2인 승인)를 먼저 정했고, 그 대가로 생긴 공백을 plan 게이트·drift 재승인·직렬화 같은 작은 안전장치로 메웠다. 정량 효과는 기준선과 리드타임 측정이 없어 근거로 쓰기 어렵고, 설계 판단과 안전장치 목록을 참고 자료로 쓰는 것이 맞다.