Glide, 23시간 배포를 14분으로 단축

요약

Glide는 개발 절차를 에이전트 중심으로 개편해 배포 시간을 23시간에서 14분으로 줄였습니다.
에이전트가 코드를 쏟아내자 사람이 승인 도장만 찍는 검토 병목이 나타났습니다.
인공지능 전환의 본질은 도구 도입이 아니라 검증과 배포 시스템의 근본적인 재설계입니다.

에이전트가 빨라져도 배포가 늦어지는 역설

많은 기업이 개발 과정에 인공지능을 도입하면서 예상치 못한 벽에 부딪힙니다. 인공지능 에이전트가 코드를 만들어 내는 속도는 눈부시게 빨라졌지만, 실제 고객에게 기능이 전달되는 속도는 거의 달라지지 않기 때문입니다. 코드가 쏟아져 들어올수록 사람이 변경 사항을 검토하는 코드 검토 단계에는 대기열이 길게 늘어섭니다. 시험용 서버인 스테이징 환경에서 일일이 동작을 확인하고, 관리자가 배포 버튼을 누를 때까지 코드는 멈춰 섭니다. 결국 사람 중심의 기존 개발 절차가 인공지능의 발목을 잡는 거대한 병목이 됩니다.

자연어로 인공지능 애플리케이션을 만드는 플랫폼인 GlideOS를 개발하던 노코드 앱 플랫폼 기업 Glide도 똑같은 문제에 부딪혔습니다. 이 내용은 Glide의 Simon Fletcher가 기술 블로그를 통해 공개한 실제 경험입니다. Glide는 사람 중심의 전통적인 방식으로 GlideOS 1세대를 만들 때 무려 8개월을 보냈습니다. 하지만 개발 절차를 에이전트 중심으로 완전히 다시 설계한 내부 파이프라인인 Slipstream을 구축한 뒤, 다음 세대 제품은 단 90일 만에 동일한 기능 수준에 도달시켰습니다. 개발 시간을 60%나 줄인 것입니다. 이들은 더 뛰어난 언어 모델을 쓰거나 코딩 도구를 바꾸지 않았습니다. 일하는 방식과 엔지니어링 시스템 전체를 에이전트에 맞춰 완전히 뜯어고쳤을 뿐입니다.

사람이 치는 도장으로 전락한 코드 검토

Glide가 처음 에이전트를 도입했을 때, 시스템의 뼈대는 여전히 사람의 손작업을 기준으로 짜여 있었습니다. 에이전트가 작성하는 코드의 양은 폭발적으로 늘어났지만, 그 코드가 실제 서비스 환경인 프로덕션으로 나가는 길목은 꽉 막혀 있었습니다.

가장 먼저 무너진 곳은 풀 리퀘스트(PR, 코드 변경 요청) 검토 단계였습니다. 에이전트가 만들어 낸 코드는 문법적으로 일관되고 전반적인 품질도 대체로 무난했습니다. 그러다 보니 엔지니어들은 깊이 있는 기술적 판단을 내리기보다, 화면을 대충 훑어보고 승인 버튼만 누르는 형식적인 승인 도장 찍기를 반복하게 되었습니다. 읽어야 할 코드가 감당하기 힘들 정도로 쏟아지자 엔지니어들은 극심한 피로를 호소했고, 급기야 코드 검토 부담을 줄여 달라고 회사에 요구하기 시작했습니다.

배포와 문제 대처 방식도 여전히 과거에 머물러 있었습니다. 코드를 하나로 합치는 머지 작업이 끝난 뒤에도 실제 배포는 사람이 하루에 한 번 수동으로 승인하는 릴리스 트레인 방식을 기다려야 했습니다. 이 때문에 이전 G2 릴리스 트레인 체제에서는 코드를 합친 뒤 프로덕션에 반영되기까지 걸리는 시간의 중앙값이 23시간에 달했습니다. 게다가 코드 변경 요청 100건을 빨리 끝난 순서로 세웠을 때 75번째 건이 걸린 시간을 뜻하는 PR 사이클 타임(p75)은 무려 21시간이 걸렸습니다. 시스템에 문제가 생겨도 사람이 우연히 이상 징후를 발견하거나 고객이 장애를 신고하기 전까지는 이전 상태로 되돌리는 롤백조차 시작되지 않았습니다.

여기에 여러 개의 독립된 저장소로 쪼개진 폴리레포 구조도 걸림돌이었습니다. 에이전트는 자신이 다루는 저장소 밖의 상황을 알지 못했기 때문에, 한 곳을 고쳤을 때 다른 서비스에 어떤 영향을 미치는지 전체적인 맥락을 파악할 수 없었습니다. 에이전트의 속도를 시스템 구조가 따라가지 못하는 상태였습니다.

에이전트가 일할 수 있도록 인프라의 바닥부터 바꾸다

Glide는 단순히 업무 절차를 조금 손보는 수준에 그치지 않았습니다. 에이전트가 사람의 개입 없이도 스스로 소프트웨어를 다룰 수 있도록 기초 기술 기반 네 가지를 먼저 개편했습니다.

첫 번째는 여러 저장소로 나뉘어 있던 코드를 하나의 거대한 단일 저장소인 모노레포로 통합한 것입니다. 에이전트가 시스템 전체의 연관 관계와 아키텍처를 한눈에 내려다볼 수 있게 만들어, 변경 사항이 다른 모듈에 미치는 영향을 스스로 파악하도록 돕기 위함이었습니다.

두 번째는 인프라를 Cloudflare로 이전한 결정이었습니다. 인프라 관리를 프로그래밍 코드로 자동 제어할 수 있는 환경을 만들어, 에이전트가 사람 손을 거치지 않고도 필요한 테스트 환경을 직접 띄우고 회수할 수 있도록 환경을 조성했습니다.

세 번째는 기능 플래그를 기본 원칙으로 확립한 것입니다. 기능 플래그는 코드를 시스템에 배포하는 일과 그 기능을 사용자에게 보여주는 노출을 엄격하게 분리하는 제어 장치입니다. 코드가 실제 서비스에 배포되더라도 스위치를 켜기 전까지는 사용자에게 노출되지 않기 때문에, 별도의 스테이징 환경을 거치지 않고 곧바로 프로덕션에 코드를 올려도 위험하지 않은 환경이 마련되었습니다.

네 번째는 머지 큐의 도입이었습니다. 사람이 눈치껏 순서를 맞추며 코드를 합치던 방식을 없애고, 검증이 끝난 코드가 대기열을 따라 자동으로 질서 있게 합쳐지도록 만들어 병목을 지웠습니다.

세 개의 정거장과 공장식 리콜 체계

기반 공사를 마친 Glide는 Slipstream이라는 새로운 배포 파이프라인을 구축했습니다. 모든 기능 개발은 에이전트가 주도하는 세 개의 정거장을 순서대로 통과합니다.

첫 번째는 Build 정거장입니다. 사람이 업무용 메신저인 Slack에서 Slipstream 에이전트를 불러 자연어로 요구 명세를 입력하면 작업이 시작됩니다. 에이전트는 사내 규약과 코딩 규칙에 맞춰 처음부터 완성도 높은 코드를 작성합니다. 나중에 사람이 코드를 다듬는 수고를 덜기 위해 처음부터 규칙을 철저히 준수하도록 설계했습니다.

두 번째는 Gate 정거장입니다. 여기서는 코드를 작성한 에이전트와 완전히 분리된 별도의 검증 에이전트가 투입됩니다. 이 검증 에이전트는 시스템 평가와 서비스 전체의 흐름을 확인하는 종단간(E2E) 테스트를 수행합니다. 이 단계에서도 사람의 승인이 필요하지만, 개발자가 코드를 한 줄씩 뜯어보며 문법을 검사하지 않습니다. 사람은 오직 “요청한 대로 동작하나?”라는 질문 하나만 확인하고 승인합니다. 기계적인 검증은 에이전트에 넘기고, 사람은 비즈니스 목적이 달성되었는지만 판단하는 방식입니다.

세 번째는 Ship 정거장입니다. 검증을 통과한 코드는 머지 큐를 거쳐 기능 플래그 뒤에 숨겨진 상태로 프로덕션에 즉시 배포됩니다. 배포가 완료되는 순간부터는 롤아웃 감시 에이전트가 시스템의 건강 상태를 실시간으로 지켜봅니다.

만약 배포 후 예상치 못한 결함이 발생하면 자동차 공장의 리콜 체계를 본뜬 4단계 자체 복구 회로가 작동합니다.

감지 단계: 시스템의 각종 지표와 로그를 수집하는 텔레메트리가 오류, 보안 취약점, 비정상적인 트래픽, 코드 품질 저하를 실시간으로 포착합니다.
알림 단계: 문제를 일으킨 서비스 영역을 특정해 GitHub 이슈를 자동으로 생성하고 담당 팀에 배정합니다.
진단 및 수리 단계: 전담 수리 에이전트가 투입되어 원인을 분석하고 버그를 수정한 PR을 스스로 엽니다.
복귀 단계: 엔지니어는 “이 수정은 내보내도 안전한가?”라는 안전성 관점의 질문만 검토한 뒤 승인하고, 수정된 코드는 일반 Ship 정거장을 통해 즉시 다시 배포됩니다.

만약 배포 직후 치명적인 문제가 감지되었는데 당직 엔지니어가 알림에 즉각 응답하지 못하면, 롤아웃 감시 에이전트가 사람을 기다리지 않고 스스로 즉각 롤백을 단행합니다. Glide의 최고기술책임자(CTO) Shay Frendt는 시스템이 스스로 판단해 실행한 첫 번째 자동 롤백을 두고 매우 기뻐하며 성공적인 안착으로 평가했습니다.

Glide Slipstream 파이프라인

에이전트가 개발과 배포를 주도하고 사람은 핵심 질문만 확인해 병목을 줄입니다. (출처: Glide Engineering Blog)

실제 현장에서는 이 전체 흐름이 매우 정교하게 맞물려 돌아갔을 것입니다. 비개발자나 엔지니어가 Slack 채널에서 명령어를 입력하면, Slipstream 오케스트레이터가 작업용 격리 환경을 즉시 생성하고 코드를 작성했을 것입니다. Gate 정거장에서는 가상 브라우저 환경을 띄워 화면 캡처와 테스트 결과를 Slack 스레드에 보여주었을 것이며, 사람은 화면의 결과물만 보고 승인 버튼을 눌렀을 가능성이 높습니다. 이 과정에서 Build 에이전트는 .cursorrules와 ESLint 설정, 타입 정의 같은 저장소 규칙을 먼저 읽어 들인 뒤 코드를 작성했을 것입니다. 이어지는 Gate 에이전트는 격리된 미리보기 환경을 구성해 Playwright 같은 헤드리스 브라우저 도구로 E2E 테스트를 수행하고, 테스트 통과 여부와 함께 화면을 직접 확인할 수 있는 미리보기 URL을 Slack 스레드에 공유했을 가능성이 높습니다.

또한 롤아웃 감시 에이전트는 배포 후 일정 시간 동안 오류율과 응답 속도를 집중 관찰했을 것입니다. 오류율이 기준치를 넘어서는데도 지정된 시간 안에 당직자의 응답이 없으면, 기능 플래그 스위치를 즉시 끄거나 코드를 되돌리는 복구 작업을 자동으로 처리했을 것으로 보입니다.

리콜 회로의 수리 에이전트는 문제가 감지되면 Sentry 같은 관측 도구에서 오류 스택 추적과 로그를 수집했을 것입니다. 에이전트는 스택 추적에 기록된 파일 경로와 줄 번호를 최근 병합된 커밋의 변경 내역과 대조해 회귀를 일으킨 지점을 좁혀냈을 가능성이 큽니다. 그다음 오류를 재현하는 실패 테스트를 먼저 작성하고, 이 테스트를 통과할 때까지 코드를 수정한 뒤 자동으로 PR을 등록했을 것입니다. 해당 PR 설명에는 근본 원인 요약과 재현 테스트 기록, 코드 수정 내용이 담겨 있어, 엔지니어가 전체 코드베이스를 뒤지지 않고도 안전성을 빠르게 검증할 수 있었을 것입니다.

23시간에서 14분으로, 측정된 결과들

2026년 8월 6일 기술 블로그를 통해 발표된 Glide의 운영 지표는 다음과 같은 변화를 보여주었습니다. 이 지표들은 시스템 전환이 한창 진행되던 롤아웃 중간 시점에 측정한 수치입니다.

코드를 합친 뒤 실제 서비스에 배포되기까지 걸리는 시간의 중앙값은 기존 G2 릴리스 트레인 기준 23시간에서 단 14분으로 대폭 줄었습니다. 과거 하루에 단 한 번 사람이 모여 배포하던 방식에서 벗어나, 이제는 시스템이 15분마다 안전하게 배포를 수행합니다.

사람의 기능 승인 시간까지 포함한 PR 사이클 타임(p75)은 21시간에서 5.4시간으로 크게 줄어들며 회사의 목표치였던 6시간 미만을 달성했습니다. 전체 코드 변경 요청 중 사람이 개입하지 않고 에이전트가 검토를 마친 비율은 기존 0%에서 90%로 뛰어올랐습니다. Glide가 설정한 에이전트 검토 비율의 목표치는 100%입니다.

Glide 배포 및 PR 소요 시간 변화

세로축은 로그 눈금이며, Slipstream 도입 후 배포와 PR 처리 시간이 단축되었습니다. (출처: Glide Engineering Blog)

롤아웃 감시 에이전트는 전체 배포의 100%를 실시간으로 감시하고 있으며, 이상 징후가 나타나면 스스로 롤백을 수행하는 수준까지 운영 능력을 증명했습니다.

조직 구성원의 역할에서도 큰 변화가 나타났습니다. 엔지니어가 아닌 일반 직원 10명이 자연어 명세만 작성하여 프로덕션에 37개의 코드 변경 요청을 직접 배포했습니다. 이들은 회사 전체 인원의 25%에 해당하는 인원입니다. Glide의 목표는 조직 전체 인원인 100%가 프로덕션에 직접 배포할 수 있는 환경을 만드는 것입니다. 당시 Glide 전체 직원 중 엔지니어의 비중이 약 30% 수준이었음을 고려하면, 고객의 목소리를 듣고 당일 즉시 제품을 수정해 배포할 수 있는 인력 규모가 회사 전체에서 거의 두 배로 늘어난 셈입니다.

코드를 쓰는 시대에서 시스템을 설계하는 시대로

Glide의 사례는 소프트웨어 엔지니어링의 본질이 코드를 직접 타이핑하는 행위에서 전체 시스템의 흐름을 통제하고 설계하는 일로 이동했음을 보여줍니다. 인공지능 모델이 코드를 작성하는 능력은 갈수록 보편화되고 있습니다. 이제 중요한 과제는 그렇게 생산된 대량의 코드를 어떻게 안전하고 빠르게 검증하여 고객에게 전달할 것인가입니다.

Glide는 사람을 검토 과정에서 완전히 배제하지 않았습니다. 대신 사람이 개입해야 하는 판단의 범위를 명확하게 좁혔습니다. Gate 정거장에서는 “요청한 대로 동작하나?”를 묻고, 장애 수리 단계에서는 “이 수정은 내보내도 안전한가?”만을 묻습니다. 문법 검사와 단순 테스트는 에이전트에게 전적으로 맡기고, 인간의 인지 능력을 비즈니스 의도와 시스템의 안전성을 평가하는 데 집중시킨 것입니다.

또한 코드를 배포하는 행위와 사용자에게 노출하는 행위를 분리하는 기능 플래그와 자동 롤백 인프라는 필수적인 안전망이었습니다. 흔히 개발 단계에서 유지하는 복잡한 스테이징 서버나 긴 배포 주기는 사실 사람의 불안감을 달래기 위한 장치에 불과했습니다. 충분한 자동화 테스트와 즉각적인 복원 체계가 갖춰진다면, 스테이징을 건너뛰고 프로덕션으로 곧바로 나아가는 방식이 훨씬 빠르고 안전할 수 있음을 증명했습니다. 다만 이러한 운영 방식을 적용하려면 폭넓은 E2E 테스트 묶음과 하나로 통합된 모노레포, 정교한 텔레메트리, 자동 롤백 인프라가 갖추어져 있어야 합니다. 테스트 범위가 넓지 않고 기능 플래그 인프라가 충분히 성숙하지 않은 상태에서 스테이징을 건너뛰고 프로덕션에 곧바로 배포를 시도하면 심각한 서비스 장애로 이어질 수밖에 없습니다.

개발 조직을 이끄는 리더라면 도구의 도입률이라는 숫자에 안주하지 말아야 합니다. 아무리 뛰어난 인공지능 도구를 쥐여주어도, 기존의 사람 중심 파이프라인을 그대로 둔다면 개발 속도는 결코 빨라지지 않습니다. 인공지능 에이전트가 자신의 속도대로 달릴 수 있도록 모노레포와 배포 자동화, 실시간 감시 시스템이라는 새로운 도로를 먼저 깔아주는 일, 이것이 진정한 인공지능 전환의 시작입니다.

출처

Glide Engineering Blog — Creating Slipstream: How we rebuilt our software engineering process for AI agents — https://www.glideapps.com/blog/creating-slipstream — 2026-08-06 (Simon Fletcher)