Engineering

“배포해줘” 한 줄로 끝나는 배포 — 전 직원이 쓰는 사내 플랫폼 구축기

2026년 9월 17일

"배포해줘" 한 줄로 끝나는 배포 --- 전 직원이 쓰는 사내 플랫폼 구축기

글. 이단비(Tabie) / Service Factory팀

안녕하세요, 여기어때컴퍼니 Service Factory팀 타비입니다.

올해 초 팀을 옮긴 후 받은 첫 과제는 바이브코딩으로 서비스를 하나 만들어보는 것이었습니다. 여행 유튜브 영상을 AI가 요약해서 숙소 검색까지 이어주는 작은 웹 서비스를 단 며칠 만에 완성했습니다. 하지만 진짜 문제는 다 만든 다음이었습니다. 팀원들에게 결과물을 보여주려면 노트북 화면 공유만으로는 한계가 있었습니다. 결국 외부 호스팅 서비스에 결과물을 배포하고 링크를 공유했지만, 마음 한구석이 계속 불편했습니다. '사내에서 만든 결과물을 사외 서비스에 올려도 괜찮은 걸까' 하는 의문 때문이었습니다.

문득 둘러보니 이는 저 혼자만의 문제가 아니었습니다. 당시는 회사가 전사적으로 AI와 바이브코딩을 막 확산하기 시작한 시기였습니다. 사외 서비스에 배포된 개인 작업물 링크들이 사내에 파편화되어 공유되는 모습이 눈에 들어왔고, 처음에는 이를 한곳에 모아두는 '갤러리 플랫폼'을 떠올렸습니다. 하지만 기획을 파고들수록 사외 서비스 파편화의 본질이 보였습니다. 바이브코딩 덕분에 비개발자 동료들도 서비스 '구축'까지는 가능해졌지만, 정적 웹 하나조차 사내망에 띄우지 못해 결국 사외 호스팅을 찾고 있었던 것입니다. 개발자인 저에게도 인프라 신청 절차가 높은 허들로 느껴지는데, 비개발 직군 동료들에게 배포는 넘을 수 없는 장벽이자 인프라 지식을 갖춘 개발자만의 영역으로 남아있었습니다.

갤러리에 모으는 건 다음 문제였습니다. 애초에 비개발자 동료들이 만든 결과물을 사내에 어떻게 쉽게 배포할 것인가가 먼저 풀어야 할 진짜 숙제였습니다. 목표가 완전히 바뀌었습니다. 지금 필요한 것은 갤러리가 아니라 '배포' 그 자체였습니다. 외부 서비스를 빌리지 않고 딸깍 한 번으로 배포되는 사내 전용 플랫폼, 그렇게 바이브독 프로젝트가 시작되었습니다.

이 글에서는 사내 배포 플랫폼 바이브독을 만들고 운영해 온 과정을 정리합니다. 배포 과정에서 사용자가 느껴온 허들을 어떻게 하나씩 허물었는지, 그 편의를 위해 시스템은 무엇을 감당해야 했는지 차례로 이야기해 보겠습니다.

첫 커밋에서 첫 사용자 유입까지 7일

4월 초 전체 아키텍처의 밑그림을 그리고 인프라 구성을 요청했습니다. 복잡한 쿠버네티스 환경을 구축하는 대신, 서버 한 대에 바이브독을 올리는 심플한 정적 웹 호스팅 구조로 시작했습니다. 예상 트래픽이 사내 규모에 불과했고, 잠깐 서버가 멈춰도 고객 서비스에는 영향이 없는 내부용 워크로드였기 때문입니다.

초기 아키텍처를 잡을 때 위협 모델(Threat Model)도 함께 정의했습니다. 대전제는 '사용자는 신뢰할 수 있는 사내 구성원이며, 주된 위협은 외부의 악의적 공격보다 실수나 호기심에서 비롯된 보안 누출'이라는 점이었습니다. 이에 따라 제로 트러스트나 오토스케일링 같은 오버스펙은 과감히 덜어내고 당장 필요한 배포 기능에만 집중했습니다. 인프라 세팅이 완성되기를 기다리지 않고 바로 개발에 착수해 4월 8일 첫 커밋을 올렸고, 정확히 일주일 뒤인 15일에 개발 환경을 오픈했습니다.

첫 커밋 이후 단 7일 만에 배포가 되는 최소한의 뼈대만 만들어 열었던 셈입니다. 당장 동작하는 결과물로 사용자의 실제 반응을 보며 방향을 잡아나가는 바이브코딩의 철학을 그대로 적용했습니다. 첫 버전에 탑재한 핵심 기능은 코드를 받아 빌드하고 배포된 서비스 URL을 돌려주는 것 하나였으며, 이 단순한 시작은 이후 두 가지 큰 줄기로 발전하게 됩니다.

**배포:**코드를 받아 서비스로 띄워주는 역할
**API 프록시:**그 서비스가 외부 API나 DB를 호출할 때 대신 인증해 불러주는 역할

CLI에서 "배포해줘"로

개발 환경을 오픈한 날 비개발자 동료에게 CLI 배포 방법을 안내했지만, 이는 또 하나의 큰 장벽이었습니다. 표면적으로는 두 줄의 명령어였지만 터미널을 열고, 도구를 설치하고, 인증을 거치는 기반 환경 구축 자체가 '배포'가 아닌 또 다른 학습 과제였기 때문입니다. 사용자 피드백을 통해 복잡한 사전 절차의 허들을 하나씩 낮춘다는 확실한 원칙을 세우고 개선에 착수했습니다.

가장 먼저 배포 도구부터 바꿨습니다. 바이브코딩을 진행하는 AI 도구 안에서 배포가 끝나도록 MCP(Model Context Protocol)를 연결했습니다. 이제 채팅창에 "지금 작업한 거 바이브독에 배포해줘" 한 줄만 치면 됩니다. AI가 알아서 파일을 바이브독으로 보내고 빌드가 끝나면 서비스 URL을 돌려주므로, 사용자는 결과물을 확인하기만 하면 끝납니다.

두 번째로 깃랩(GitLab) 계정의 허들을 허물었습니다. 비개발자가 계정을 직접 발급받는 대신 바이브독 서버가 시스템 권한으로 커밋을 대신 수행합니다. 4개월 뒤 129명의 사용자 중 95%(122명)가 git push를 한 번도 쓰지 않았고, 깃랩 계정 자체가 없는 사용자도 54%(70명)에 달했습니다.

마지막으로 AI를 통한 배포 속도와 토큰 문제도 해결했습니다. 초기에는 파일 내용을 파라미터로 넘겨 AI가 수많은 코드를 한 글자씩 읽어내느라 배포에 10분이 넘게 걸렸습니다. 이를 해결하기 위해 순서를 뒤집어 바이브독이 파일을 직접 업로드할 수 있는 임시 주소를 먼저 발급 하도록 바꿨습니다. 대용량 파일 전송이 AI 대화 맥락(Context)을 우회하면서 소모 토큰은 0에 수렴했고, 배포 소요 시간도 수 초 단위로 단축되었습니다.

사용자의 요구가 바이브독을 고도화했습니다

5월 4일 상용 오픈 이후, 정적 웹을 넘어 백엔드 배포, DB 테이블 신청, 도메인 연결 등 동료들의 실제 요구사항에 맞춰 자동화 영역을 유연하게 넓혀나갔습니다.

특히 백엔드 배포 지원은 고려해야 할 요소가 훨씬 많았습니다. 백엔드 인프라로는 AWS Lambda(람다)를 채택했습니다. 바이브독에 올라오는 사내 프로토타입은 대부분 수십 명의 동료가 가끔 들르는 규모라, 상시 서버를 띄워두면 유휴 시간의 비용과 관리 부담이 크기 때문입니다. 람다는 요청이 올 때만 실행되므로 사용하지 않을 때의 비용은 0에 수렴하고, 서비스가 수백 개로 늘어나도 직접 관리해야 할 인스턴스가 늘어나지 않습니다.

이 과정에서 가장 고심했던 과제는 '권한 분리'였습니다. 바이브독 서버가 백엔드 배포 권한을 상시 보유하면 서버 탈취 시 대형 보안 리스크로 이어질 수 있기 때문입니다. 이를 해결하기 위해 DevOps팀에 지원을 요청했고, DevOps팀에서 표준 CI 파이프라인에 Lambda 배포 템플릿 을 구축해 준 덕분에 배포 실행을 안전하게 위임하는 풀스택 배포 체계를 완성할 수 있었습니다. 코드 배포 권한은 파이프라인만 가지도록 격리해 바이브독 서버의 리스크를 차단했고, 동료들은 복잡한 권한 매핑을 몰라도 평소처럼 코드를 올리는 것만으로 안전하게 배포할 수 있게 되었습니다.

손이 많이 가던 DB 테이블 신청 역시 개선했습니다. 기존 DDL 표준 규칙뿐만 아니라 실제 신청 과정에서 자주 피드백받던 유의사항들을 함께 보완해 AI 스킬로 제공했습니다. 덕분에 사용자의 AI가 이 스킬을 기반으로 수정 요청을 줄인 스키마 초안과 신청서를 알아서 채우게 되었습니다. 나아가 배포된 서비스를 동료의 AI와 연동되는 MCP 서버(/api/mcp)로 활용할 수 있도록 인증 중계 기능까지 확장했습니다.

이 모든 변화는 사전 로드맵이 아닌, 현장에서 부딪힌 사용자들의 실제 요구사항이 만들어낸 결실이었습니다.

복잡함은 바이브독이 처리합니다

지원 범위가 넓어져도 사용자가 새로운 배포 지식을 학습하거나 복잡한 설정을 신경 쓸 필요가 없도록 만들었습니다. AI 도구, 버튼 클릭, git push 등 여러 배포 입구를 하나의 통합 파이프라인으로 모았기에 가능한 구조였습니다.

지원 범위가 백엔드까지 넓어지면서 신경 써야 할 설정도 늘어났습니다. 하지만 바이브독은 저장소 내에 api/ 폴더가 감지되면 이를 백엔드 코드로 자동 인식합니다. 백엔드 구동에 필요한 SAM 정의 파일(template.yml)과 CI/CD 설정 파일 역시 바이브독이 백그라운드에서 직접 생성해 커밋하므로, 사용자는 이런 설정의 존재조차 알 필요가 없습니다.

환경변수 역시 비개발자 동료들이 그 메커니즘을 일일이 이해하고 설정하기에는 상당한 허들이었습니다. 대신 Vite, Next.js 등 프론트엔드 프레임워크 규약(접두사)을 활용해 시스템이 자동 분기하고, 토큰 형태의 값이 들어오면 저장을 거부하도록 안전장치를 마련했습니다.

표에 표기된 커넥터(Connector)는 외부 API 호출에 필요한 토큰을 바이브독 화면에 미리 등록하는 기능입니다. 설정을 마친 배포 서비스는 토큰 없이 바이브독이 제공하는 프록시 주소만 호출하면 되므로, 토큰이 코드나 브라우저에 전혀 남지 않습니다.

반면 백엔드 함수가 쓰는 시크릿은 바이브독이 사내 시크릿 저장소인 SecretHub에 대신 신청해 승인을 받으며, 이 값은 코드 저장소를 거치지 않고 함수가 구동되는 런타임 시점에 안전하게 주입됩니다.

바이브독이 감당한 보완 장치와 보안 게이트

배포 허들을 극적으로 낮춘 대신, 바이브독 내부에서는 그에 비례하는 기술적 복잡성을 감당해야 했습니다. "사용자를 대신해 서버가 커밋을 수행한다"는 결정 하나만으로도 세 가지 후속 과제가 따라왔습니다.

감사 로그(Audit Log): 커밋 주체가 서버가 되면서 Git 기록만으로는 개별 사용자의 행위를 추적하기 어려워졌습니다. 커밋 작성자 정보는 실제 사용자로 남기되, 플랫폼 내 행위를 별도로 추적하는 감사 로그 체계를 구축했습니다.
Git 프록시: GitLab 계정이 없는 비개발자가 동료의 코드를 클론(clone)할 수 있도록, 바이브독 단에서 읽기 전용 권한의 내부 프록시를 제공했습니다.
3-Way 자동 병합: Git 개념을 모르는 여러 동료가 공통 프로젝트를 동시에 수정할 때 코드가 덮어씌워지는 문제를 막기 위해, 서버 단에서 커밋 시점의 HEAD를 비교해 3-Way 병합(merged / conflict / retry)을 알아서 수행하도록 구현했습니다.

이러한 시스템적 보완과 더불어 배포 직전 단계에는 단일 보안 게이트를 두었습니다. 담당자의 실수로 하드코딩된 토큰이 코드에 섞여 들어가는 경우를 대비해 빌드 직후 정적 스캔을 돌립니다.

로그로 인한 2차 유출을 막기 위해 시크릿 전문은 마스킹 처리(앞 6자리와 전체 길이만 표기)하고 올바른 수정 가이드를 남깁니다.

흥미로운 점은 AI 대화형 배포에서 이 게이트가 자가 수정 루프(Self-Correction Loop)로 작동한다는 사실입니다. 시크릿 차단 에러가 발생하면 AI 모델이 마스킹된 로그와 수정 가이드를 스스로 읽어낸 뒤, 코드를 수정하여 즉시 재배포를 시도합니다. 사람이 개입하지 않아도 보안 문제를 스스로 바로잡는 셈입니다. 상용 오픈 이후 코드에 시크릿이 하드코딩된 채 배포하려던 사례가 19건 있었지만, 이 게이트가 모두 사전에 차단했습니다.

조용하지만 확실하게 퍼져나간 과정

개발 환경 오픈 초기에는 제가 속한 실에만 공지했습니다. 그러다 4월 말 외부 호스팅 서비스의 보안 이슈로 사내 전수 조사가 내려왔고, 마침 개발 환경을 열어둔 바이브독이 사내 대체재로 주목받으며 자연스럽게 활용되기 시작했습니다.

이후로는 사용자 주도의 자발적인 유입이 이어졌습니다. 배포된 서비스 링크를 본 동료들이 스스로 플랫폼을 찾아왔고, 한 번 배포를 경험한 동료들은 꾸준한 활성 사용자로 정착했습니다.

현재 바이브독을 사용하는 팀은 전사 100여 개 팀 중 절반에 가까운 58개 팀 입니다. 전체 사용자는 129명으로 팀당 1~2명씩 골고루 흩어져 있습니다. 특정 조직에 치우치지 않은 이 분포는 바이브독이 탑다운 지시가 아닌 개인의 필요에 의해 전파되었다는 증거 입니다. 직군 역시 비개발 직군에서 시작해 개발 부서로 자연스럽게 확대되었으며, 8월 한 달간 실제 배포를 실행한 **월간 활성 사용자(MAU)는 80명(전체 사용자의 약 62%)**에 달합니다.

4개월이 남긴 숫자

지루했던 배포 병목은 사라졌습니다. 아래 지표는 제 테스트 데이터를 모두 제외한 순수 사용자들의 성과입니다. (데이터 기준일: 2026년 9월 1일. 개발자 테스트 계정 제외, 성공한 배포 건수만 집계)

마치며

올해 전사 차원의 AI 도입 덕분에 "내가 만든 걸 대체 어디에 띄우지?"라는 고민이 사내 공통의 페인 포인트로 공감대를 얻을 수 있었습니다. 그동안 프론트엔드 개발을 담당했던 제가 백엔드부터 인프라, 보안까지 아우르는 플랫폼을 기획부터 운영까지 주도할 수 있었던 것도 AI 덕분이었습니다.

하지만 경험 부족으로 미처 예측하지 못한 사각지대도 컸습니다. 초기 설계는 오직 '만든 결과물을 웹상에 띄우는 것'에만 집중했으나, 막상 서비스가 올라가자 사내 API와 DB 연결 요구가 잇따랐고 프록시망, 토큰 커넥터, 보안 설정을 단계적으로 보완해 나갈 수밖에 없었습니다. 수없이 설계를 뜯어고치며 "배포는 프로젝트의 끝이 아니라, 서비스가 살아 숨 쉬기 시작하는 진짜 출발점"이라는 귀중한 교훈을 얻었습니다.

동시에 이 과정은 배포를 바라보는 관점 자체를 바꾸는 계기가 되었습니다. 처음에는 '어떻게 하면 비개발자 동료에게 배포 절차를 쉽게 안내할까'를 고민했다면, 결국 다다른 본질은 '어떻게 해야 배포와 인프라라는 개념 자체를 동료들이 신경 쓸 필요조차 없게 만들 수 있을까'였습니다. CLI를 없애고, Git 계정을 없애고, 환경변수와 보안 통제까지 바이브독이 뒤에서 대신 감당했을 때 비로소 동료들이 인프라에 대한 고민 없이 AI와 만나 자신의 아이디어를 제약 없이 실서비스로 띄우기 시작했습니다.

현장에서 쏟아진 동료들의 피드백, 그리고 이를 안전하게 구현하기 위해 프론트엔드 시절에는 교류가 적었던 인프라, 데이터, 보안 담당 동료들에게 조언을 구하며 함께 협력한 시간이 지금의 바이브독을 만든 진짜 동력이었습니다.

시스템이 더 많은 복잡성을 감당할수록 사용자의 창의성은 비약적으로 폭발합니다. 기존 직무와 역할의 경계를 넘어, 동료들의 진짜 불편을 기술로 풀어가는 시도는 앞으로도 계속될 것입니다. 긴 글 읽어주셔서 감사합니다.

"배포해줘" 한 줄로 끝나는 배포 --- 전 직원이 쓰는 사내 플랫폼 구축기 was originally published in 여기어때 기술블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.