2025년 9월 29일·7분
베르너 보겔스의 “You Build It, You Run It” 해설
‘You Build It, You Run It’의 의미와 적용 방법: 소유권, 온콜, SLO, 사고 대응, 안전한 배포 관행을 설명합니다.
‘You Build It, You Run It’의 의미와 적용 방법: 소유권, 온콜, SLO, 사고 대응, 안전한 배포 관행을 설명합니다.
“You build it, you run it”은 직설적인 문구라 기억에 남습니다. 모티베이션 포스터나 ‘더 데브옵스해지자’ 같은 구호가 아니라 책임에 대한 분명한 선언입니다: 서비스를 배포한 팀이 그 서비스가 프로덕션에서 어떻게 동작하는지에 대해 계속 책임을 진다는 뜻입니다.
실제로는 기능을 설계하고 코드를 작성하는 동일한 제품 팀이 또한:\n
모든 사람이 갑자기 인프라 전문가가 되어야 한다는 뜻은 아닙니다. 중요한 건 피드백 루프가 실질적으로 작동한다는 점입니다: 만약 당신이 배포한 것이 장애, 페이지 노이즈, 고객 불편을 증가시킨다면, 당신의 팀이 직접 그 영향을 느끼고 빠르게 배웁니다.
이 철학은 반복하기는 쉽지만 실행하기는 어렵습니다. 이를 운영 모델로 취급하고 명확한 기대치를 정하지 않으면 안 됩니다. “운영한다”는 것은 보통 어떤 형태로든 온콜을 하고, 사고 대응을 소유하며, 런북을 작성하고, 대시보드를 유지하고, 지속적으로 서비스를 개선하는 것을 포함합니다.
또한 제약을 수반합니다: 팀에게 ‘운영하라’고만 말해선 안 되고, 문제를 고칠 수 있는 도구와 접근권한, 권한을 주어야 하며, 이 작업을 로드맵에 반영할 시간도 제공해야 합니다.
“You Build It, You Run It” 이전에는 많은 회사가 소프트웨어 작업을 릴레이 레이스처럼 조직했습니다: 개발자가 코드를 쓰고, ‘담을 넘어’ 운영팀에게 넘기면 운영팀이 배포하고 유지관리했습니다.
그 단절은 단기적으로는 누군가 경험 있는 사람이 프로덕션을 관찰한다는 문제를 해결했지만, 더 큰 문제를 만들었습니다.
별도의 운영팀이 프로덕션을 소유하면 개발자는 문제를 늦게(혹은 전혀) 알게 됩니다. 버그는 며칠 뒤에 ‘서비스 느려요’ 같은 모호한 티켓으로 나타날 수 있습니다. 그때는 문맥이 사라지고 로그는 롤오버됐으며, 변경을 만든 사람들은 이미 다른 일로 옮겼을지도 모릅니다.
핸드오프는 또한 소유권을 흐리게 만듭니다. 장애가 발생하면 개발팀은 ‘운영팀이 잡아줄 것’이라 생각하고, 운영팀은 ‘개발팀이 위험한 걸 배포했구나’라고 생각합니다. 결과는 예측 가능합니다: 사건 해결 시간이 길어지고, 같은 실패 모드가 반복되며, 팀들이 고객 경험 대신에 각자 로컬 최적화를 하게 됩니다.
“You Build It, You Run It”은 루프를 단축합니다. 동일한 팀이 변경을 배포하고 프로덕션에서의 동작에 책임을 지면 실무적 개선이 상류로 밀려옵니다: 더 명확한 알림, 안전한 롤아웃, 더 좋은 대시보드, 운영하기 쉬운 코드 등.
역설적으로 이는 종종 더 빠른 배포로 이어집니다. 팀이 릴리스 프로세스를 신뢰하고 프로덕션 동작을 이해하면 더 작은 변경을 더 자주 배포할 수 있습니다—이로 인해 실수의 영향 범위가 줄고 문제 진단이 쉬워집니다.
모든 조직이 동일한 인력 배치, 규제 요건, 레거시 시스템을 가진 것은 아닙니다. 이 철학은 방향이지 스위치가 아닙니다. 많은 팀이 공유 온콜, 향상된 관측성, 명확한 서비스 경계 등으로 점진적으로 도입한 뒤 완전한 엔드투엔드 소유권으로 나아갑니다.
아마존의 CTO인 베르너 보겔스는 “You build it, you run it”이라는 문구를 널리 알렸습니다. 그는 소프트웨어를 ‘넘겨주는 프로젝트’가 아니라 ‘운영하는 서비스’로 생각하라고 강조했습니다.
핵심 변화는 기술적인 것만큼 심리적인 것입니다. 팀이 장애로 인해 페이지를 받을 것을 안다면 설계 결정이 달라집니다. 합리적인 기본값, 명확한 알림, 우아한 디그레이데이션, 롤백 가능한 배포 경로에 신경을 쓰게 됩니다. 즉, 빌드에는 현실의 난처한 부분에 대한 계획도 포함됩니다.
AWS 시대의 서비스 사고방식은 신뢰성과 속도를 비타협적 요소로 만들었습니다. 클라우드 고객은 API가 24/7 사용 가능하길 기대하고, 개선이 분기별 대형 릴리스로만 오지 않길 기대합니다.
그 압력은 다음을 촉진했습니다:
이 철학은 더 넓은 데브옵스 운동과 겹칩니다: 개발과 운영의 간극을 좁히고, 핸드오프를 줄이며, 가용성·지연·지원부하 같은 결과물을 개발 루프의 일부로 만드는 것. 또한 독립적으로 배포할 수 있는 작은 자율 팀이라는 개념과도 맞닿아 있습니다.
아마존의 접근을 그대로 복사해 템플릿처럼 적용하기 쉬운데, “You Build It, You Run It”은 조직 구조보다 방향에 가깝습니다. 팀 규모, 규제 제약, 제품 성숙도, 가동시간 요구사항에 따라 조정이 필요합니다(공유 온콜, 플랫폼 지원, 단계적 도입 등).
실무로 옮기는 방법을 원하면 /blog/how-to-adopt-you-build-it-you-run-it-step-by-step 를 참고하세요.
“You Build It, You Run It”은 사실 소유권에 대한 선언입니다. 팀이 서비스를 배포하면 그 팀은 단지 배포일에 테스트를 통과했는지 여부가 아니라, 그 서비스가 실제 환경에서 어떻게 동작하는지의 결과까지 책임집니다.
서비스를 운영한다는 것은 끝에서 끝까지의 결과물을 신경 쓴다는 뜻입니다:
평상시에는 ‘영웅적 대응’보다 일상적 운영이 더 중요합니다:
이 모델은 책임이 ‘우리가 사람을 처벌하겠다’가 아니라 ‘우리가 문제를 고친다’는 의미일 때만 작동합니다. 무언가 깨졌을 때 목표는 무엇이 시스템이 그 상태에 이를 수 있게 했는지를 이해하고(누락된 알림, 불분명한 한계, 위험한 배포 등) 이를 개선하는 것입니다.
서비스가 모호하면 소유권도 엉망이 됩니다. 서비스 경계(무엇을 하는지, 어떤 것에 의존하는지, 무엇을 약속하는지)를 정의하고 이름이 명시된 소유 팀을 지정하세요. 이 명확성은 핸드오프를 줄이고 사고 대응 속도를 높이며, 안정성과 기능이 경쟁할 때 우선순위를 분명히 합니다.
온콜은 “You Build It, You Run It”의 핵심입니다. 변경을 배포한 동일한 팀이 운영상의 영향을 직접 느낄 때(지연 폭주, 실패한 배포, 고객 불만), 우선순위가 분명해집니다: 신뢰성 작업이 ‘다른 사람의 문제’가 아니라 결과적으로 가장 빠른 출하 수단이 됩니다.
건강한 온콜은 예측 가능성과 지원에 관한 문제입니다.
시스템이 모든 사소한 일에 페이지하지 않도록 심각도 수준을 정의하세요.
간단한 규칙: 사람을 깨워도 결과가 바뀌지 않는다면 티켓으로 남겨라.
온콜은 처벌이 아니라 신호입니다. 시끄러운 알림, 반복되는 실패, 수동 수정은 모두 엔지니어링 작업으로 환류되어야 합니다: 더 나은 알림, 자동화, 안전한 릴리스, 페이지 필요성을 제거하는 시스템 변경 등.
“운영한다”가 진짜라면, 팀은 의견 싸움이 아니라 신뢰성에 대해 공통으로 이야기할 방법이 필요합니다. 그것이 SLI, SLO, 에러 예산의 역할입니다: 명확한 목표와 빠르게 이동하는 것과 안정성 사이의 공정한 절충을 제공합니다.
기억하기 쉬운 방식: SLI = 측정, SLO = 목표, SLA = 외부 약속.
좋은 SLI는 구체적이고 사용자 경험과 연결됩니다:
에러 예산은 SLO를 만족하는 동안 허용할 수 있는 ‘나쁜 시간’의 양입니다(예: SLO가 99.9% 가용성이라면 한 달의 에러 예산은 0.1% 다운타임).
서비스가 건강하고 예산 내에 있을 때는 팀이 배포 리스크를 더 감수할 수 있습니다. 예산을 너무 빨리 소모하면 신뢰성 작업이 우선됩니다.
SLO는 신뢰성을 계획 입력값으로 바꿉니다. 예산이 낮으면 다음 스프린트는 레이트 리미팅, 안전한 롤아웃, 불안정한 의존성 수정 같은 작업을 강조할 것입니다—SLO를 놓치는 데는 명확한 비용이 있기 때문입니다. 예산이 넉넉하면 제품 작업을 자신 있게 우선순위에 둘 수 있습니다.
“You build it, you run it”은 프로덕션 배포가 일상적이어야만 작동합니다—하이 리스크 이벤트가 되어선 안 됩니다. 목표는 출시 전 불확실성을 줄이고 출시 후 영향 범위를 제한하는 것입니다.
서비스를 ‘준비됨’으로 간주하기 전에 일반적으로 필요한 운영적 기본은 다음과 같습니다:
모든 걸 한 번에 모두에게 릴리스하는 대신 점진적 전달은 영향을 제한합니다:
롤백을 표준 능력으로 다루세요: 안전하게 되돌리는 속도가 빠를수록 “운영한다”가 현실적입니다.
두 가지 테스트가 ‘알려지지 않은 위험’을 줄입니다:
가볍게 유지하세요: 리포지토리나 티켓 템플릿에 한 페이지 체크리스트(예: “관측성”, “온콜 준비”, “데이터 보호”, “롤백 계획”, “용량 테스트됨”, “런북 링크”)를 두세요. ‘준비 안 됨’ 상태를 정상으로 만들면 프로덕션에서 배우는 것보다 훨씬 낫습니다.
사고는 “운영한다”가 현실이 되는 순간입니다: 서비스가 저하되고 고객이 알아차리고 팀이 빠르고 명확하게 대응해야 합니다. 목표는 영웅적 대응이 아니라 영향 감소와 개선을 낳는 반복 가능한 워크플로입니다.
대부분의 팀은 다음 단계로 수렴합니다:
실무 템플릿을 원하면 경량 체크리스트를 준비해 두세요(예: /blog/incident-response-checklist).
블레임리스 포스트모템이란 ‘아무도 실수를 안 했다’는 뜻이 아닙니다. 시스템과 프로세스가 실수를 프로덕션까지 이르도록 허용한 방식을 중심으로 다루는 것입니다. 그래야 사람들이 초기에 상세한 정보를 공유하고 학습이 가능해집니다.
문서화할 것:
좋은 포스트모템은 구체적이고 소유자가 지정된 후속조치로 끝납니다. 보통 네 가지 범주로 묶입니다: 도구 개선(더 나은 알림/대시보드), 테스트(회귀·엣지 케이스), 자동화(안전한 배포/롤백, 가드레일), 문서화(런북, 더 명확한 운영 단계). 소유자와 기한을 지정하세요—그렇지 않으면 학습은 이론에 머뭅니다.
도구는 “You Build It, You Run It”을 지속 가능하게 만드는 지렛대입니다—그러나 도구가 실제 소유권을 대신할 수는 없습니다. 팀이 운영을 ‘다른 사람의 문제’로 취급하면 가장 멋진 대시보드도 혼란을 기록할 뿐입니다. 좋은 도구는 관찰·응답·학습을 더 쉽고 마찰이 적은 쪽으로 만듭니다.
서비스 소유자는 최소한 자신들의 소프트웨어가 프로덕션에서 무엇을 하는지 보고 빨리 대응할 수 있는 일관된 방법이 필요합니다.
모니터링이 분산되면 팀은 수색에 더 많은 시간을 쓰고 고치기는 적게 하게 됩니다. 통합된 관측성 스토리가 도움이 됩니다(참고: /product/observability).
조직이 성장하면 ‘누가 이것을 소유하나?’가 신뢰성 위험이 됩니다. 서비스 카탈로그나 내부 개발자 포털이 이 문제를 해결합니다: 팀명, 온콜 순환, 에스컬레이션 경로, 런북, 의존성, 대시보드 링크 같은 운영 문맥과 소유권을 한곳에 모읍니다.
핵심은 최신 상태로 유지되는 소유권 메타데이터입니다. 워크플로의 일부로 만드세요: 새 서비스는 소유자가 있어야만 라이브화될 수 있고, 소유권 변경은 코드 변경처럼(리뷰, 추적) 취급됩니다.
최고의 설정은 팀을 건강한 행동으로 유도합니다: 런북 템플릿, SLO에 연동된 자동 알림, ‘사용자가 영향을 받는가?’를 몇 초 안에 답해주는 대시보드 등. 하지만 사람 시스템이 여전히 중요합니다—팀은 이러한 도구를 유지·관리하고 알림을 정리하며 운영 방식을 지속적으로 개선할 시간을 가져야 합니다.
플랫폼 팀은 “You Build It, You Run It”을 실제로 해내기 쉽게 만들어줍니다. 그들의 일은 모두를 대신해 프로덕션을 운영하는 것이 아니라, 제품 팀이 매 스프린트마다 운영을 다시 발명하지 않고도 서비스를 소유할 수 있는 잘 정비된 경로(포장 도로)를 제공하는 것입니다.
좋은 플랫폼은 실수하기 어렵고 채택하기 쉬운 기본값을 제공합니다:
가드레일은 배송을 막지 않으면서 위험한 행동을 방지해야 합니다. ‘기본적으로 안전’하게 설계하세요.
플랫폼 팀은 공유 서비스를 운영할 수 있지만 제품 서비스의 소유권을 뺏어선 안 됩니다.
경계는 단순합니다: 플랫폼 팀은 플랫폼의 가동시간과 지원을 소유하고, 제품 팀은 플랫폼을 사용해 만든 서비스의 사용 방식과 결과를 소유합니다.
팀이 첫날부터 CI/CD, 인증, 비밀 관리를 모두 전문가 수준으로 알 필요가 없을 때, 서비스 동작과 사용자 영향에 집중할 수 있습니다.
예시:
결과는 더 빠른 배포와 적은 ‘커스텀 옵스 스노우플레이크’이며, 핵심 약속은 유지됩니다: 서비스를 만드는 팀이 여전히 그것을 운영합니다.
“You build it, you run it”은 신뢰성과 속도를 개선할 수 있지만 조직이 팀 주변의 조건을 바꾸지 않으면 실패합니다. 슬로건만 도입되고 지원하는 습관이 없으면 실패하는 사례가 많습니다.
다음 패턴이 반복됩니다:
다음 환경에서는 맞춤 접근이 필요합니다:
이 철학은 신뢰성 작업을 ‘여분’으로 취급하면 가장 빨리 실패합니다. 리더십은 다음을 위해 명시적으로 용량을 보호해야 합니다:
그 보호가 없으면 온콜은 세금이 되며—시스템을 개선하는 피드백 루프가 아니라 부담이 됩니다.
롤아웃은 회사 전체 공지보다는 단계적 변화로 하는 것이 좋습니다. 작게 시작해 소유권을 가시화하고 그다음 확장하세요.
경계가 분명한 한 서비스를 고르세요(이상적으로는 사용자가 명확하고 위험이 관리 가능한 서비스).
다음 정의:
핵심: 변경을 배포하는 팀이 그 서비스의 운영 결과도 소유합니다.
더 많은 서비스로 확장하기 전에 파일럿 팀이 영웅적 대응 없이 운영할 수 있는지 확인하세요:
소유권이 출하와 안정성 개선으로 이어지는지 보여주는 소수의 지표를 사용하세요:
“You build it, you run it”을 도입하면서 출하 속도를 높이려 한다면 병목은 종종 동일합니다: 아이디어 → 명확한 소유권과 안전한 롤백 이야기를 가진 프로덕션 준비 서비스까지 가는 과정.
Koder.ai는 채팅 인터페이스로 웹/백엔드/모바일 앱을 만드는 바이브 코딩 플랫폼입니다(웹은 React, 백엔드 Go + PostgreSQL, 모바일은 Flutter). 서비스 소유에 기댈 팀에게 몇 가지 기능이 운영 모델과 잘 맞습니다:
이번 주에 파일럿 서비스를 정하고 60분 킥오프를 예약해 첫 SLO, 온콜 순환, 런북 소유자를 정하세요. 이 모델을 지원할 도구(배포, 롤백, 소유권 주변 워크플로)를 평가 중이라면 /pricing에서 Koder.ai의 무료·프로·비즈니스·엔터프라이즈 플랜과 호스팅·배포·커스텀 도메인 옵션을 확인하세요.
팀이 서비스를 설계하고 빌드하고 배포한 뒤에도 실제로 라이브 상태에서 발생하는 일을 동일한 팀이 책임진다는 뜻입니다: 모니터링, 온콜 응답, 사고 대응 후속조치, 그리고 신뢰성 개선 작업까지 포함됩니다.
이는 도구나 직책 변경이 아니라 책임 모델(명확한 소유권)입니다.
모든 엔지니어가 인프라 전문가가 되어야 한다는 뜻은 아닙니다.
그 의미는 다음과 같습니다:
별도의 운영팀이 있으면 피드백이 지연되고 책임이 흐려집니다: 개발자는 프로덕션 문제를 충분히 체감하지 못하고, 운영팀은 최근 변경의 맥락을 모를 수 있습니다.
엔드투엔드 소유권은 일반적으로 다음을 개선합니다:
“Run it”에는 보통 다음 항목들이 포함됩니다:
인간적인(on-call) 설계를 기본으로 시작하세요:
좋은 온콜 시스템의 목표는 ‘다음 달 페이지를 줄이는 것’이지 영웅담을 정상화하는 것이 아닙니다.
간단한 규칙: 사람을 깨워도 결과가 달라지지 않는다면 티켓으로 처리하라.
실무적으로:
SLO는 신뢰성을 둘러싼 공통의 언어와 가시성을 제공합니다:
예산을 빨리 소진하면 신뢰성 작업을 우선하고, 예산이 충분하면 기능 개발에 더 리스크를 감수할 수 있습니다.
모델을 지속 가능하게 만드는 릴리스 관행:
사고는 ‘실제로 운영한다’가 현실이 되는 순간입니다: 목표는 영웅주의가 아니라 영향 최소화와 개선을 낳는 반복 가능한 워크플로입니다.
사고 대응 흐름:
이후 블레임리스 포스트모템을 작성하되 시스템과 프로세스의 허점에 집중하고, 구체적이고 소유자가 지정된 개선 항목으로 마무리하세요. 경량 체크리스트는 표준화에 도움이 됩니다(예: /blog/incident-response-checklist).
플랫폼 팀은 ‘운영을 대신 해주는’ 역할이 아니라 ‘빨간 길(포장 도로)’을 제공해서 제품 팀이 자체 서비스를 쉽게 소유할 수 있게 해야 합니다.
실무적 경계:
즉, 플랫폼은 템플릿·CI/CD·관성 방지 가드레일을 제공하고, 제품 팀이 최종 책임을 계속 지게 만듭니다.