What is *Building Secure and Reliable Systems* about?

*Building Secure and Reliable Systems* provides a framework for integrating security and reliability into every stage of system design, implementation, and maintenance. Co-authored by Google experts Heather Adkins, Betsy Beyer, and others, it combines real-world case studies with principles like defense in depth, least privilege, and automation. The book emphasizes cultural shifts, crisis management, and proactive strategies to create resilient infrastructure.

Who should read *Building Secure and Reliable Systems*?

The book targets developers, IT professionals, site reliability engineers (SREs), and organizational leaders involved in system architecture or operations. It’s particularly valuable for teams adopting DevOps, DevSecOps, or hybrid cloud models, as it addresses shared responsibility across roles. Managers seeking to foster security-first cultures will also benefit from its governance and incident response insights.

Is *Building Secure and Reliable Systems* worth reading?

Yes—it’s a comprehensive guide grounded in Google’s battle-tested practices, offering actionable steps for improving system resilience. Readers gain access to advanced mitigation strategies, legacy code modernization techniques, and frameworks for balancing security with usability. Its emphasis on automation and cultural alignment makes it relevant for enterprises scaling secure infrastructure.

What are the key principles in *Building Secure and Reliable Systems*?

- **Defense in Depth**: Layered security controls to mitigate risks. - **Least Privilege**: Restrict access to minimize breach impact. - **Automation**: Reduce human error via CI/CD pipelines and automated incident response. - **Simplicity**: Prioritize understandable systems over complex designs.

How does *Building Secure and Reliable Systems* address crisis management?

The book outlines proactive incident response planning, including automated alert systems and post-mortem analysis protocols. It stresses building “cultures of inevitability” where teams anticipate failures and rehearse mitigation. Real-world examples demonstrate balancing rapid recovery with forensic integrity during breaches.

What does *Building Secure and Reliable Systems* say about legacy systems?

It advocates refactoring legacy code to consolidate exemptions, reduce technical debt, and enforce modern security policies. Strategies include incremental updates, strict access controls, and avoiding overengineering (applying the YAGNI—“You Aren’t Gonna Need It”—principle).

How does the book recommend designing secure infrastructure?

- Use **safe proxies** to enforce access policies and audit trails. - Implement **zero-trust networks** to limit lateral movement during breaches. - Conduct regular threat modeling and red-team exercises to identify vulnerabilities.

What quotes from *Building Secure and Reliable Systems* are most impactful?

- **“Security and reliability are inherent properties of a system”**: Highlights the need for integrated design. - **“A culture of inevitability… leads to better resilience”**: Encourages preparing for failures rather than avoiding them. - **“Everyone is responsible”**: Rejects siloed accountability in favor of organization-wide ownership.

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약

Best Practices for Designing, Implementing, and Maintaining Systems

Heather Adkins & Betsy Beyer & Paul Blankinship & Piotr Lewandowski & Ana Oprea & Adam Stubblefield

3.87(190 Reviews)

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 개요

Google의 엔지니어링 마스터클래스에서 기술 거대 기업이 절대 실패하지 않는 시스템을 구축하는 방법이 공개됩니다. 매일 수십억 명의 사용자를 보호하는 보안 전략은 무엇일까요? 업계 리더들은 이를 DevSecOps의 "필수 요소"라 부르며, 그 영향력은 데이터 엔지니어링에서 의료 정보 보안에 이르기까지 여러 도메인에 걸쳐 확장되고 있습니다.

전달 방식을 선택하세요

다양한 학습 방식으로 신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 살펴보기

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

자물쇠공의 악몽

구글의 한 엔지니어가 금고 앞에 서 있습니다. 금고 안에는 스마트 카드가 들어 있죠. 이 카드는 하드웨어 보안 모듈을 열 수 있는 유일한 열쇠를 품고 있습니다. 그리고 그 보안 모듈은, 구글 전사의 와이파이가 마비되는 대참사를 막아주는 유일한 방어선입니다. 그런데 문제가 하나 생겼습니다. 금고 비밀번호를 아는 사람이 아무도 없다는 겁니다. 이 일은 2012년에 실제 일어났던 사건입니다. 당시 구글은 직원들에게 와이파이 비밀번호를 자동으로 배포하는 시스템을 만들어 두었습니다. 보안을 위해 주기적으로 비밀번호를 바꿔주는 구조였죠. 그런데 이 자동 교체 작업에 오류가 생겼습니다. 시스템을 정상화하려면 보안 모듈에 접근해야 했고, 그러려면 수년 동안 아무도 열지 않았던 그 금고를 열어야만 했습니다. 결국 어떻게 했을까요? 누군가 전동 드릴을 들고 와서 금고를 뚫어야 했습니다. 잠시 이 장면을 떠올려 보세요. 우리가 하려는 이야기의 모든 핵심이 이 작은 사건에 들어 있습니다. 좋은 의도로 만든 보안 장치가, 오히려 시스템 전체의 안정성을 위협하는 대형 사고로 이어진 겁니다. 열쇠를 너무 안전하게 보관하려다 보니, 정작 필요할 때 돌릴 수가 없게 된 거죠. 이건 엔지니어의 실력이 부족해서 생긴 일이 아닙니다. 보안 팀은 이쪽에, 안정성 팀은 저쪽에 따로 떨어진 채, 중간에 무언가가 터지기 전까지는 서로 대화조차 하지 않아서 생긴 문제입니다. 대부분의 기업이 자신도 모르게 세우고 마는 거대한 장벽 때문인 거죠. 구글의 헤더 애드킨스와 베시 바이어, 그리고 동료 저자들은 바로 이 경계선에서 수십 년을 보냈습니다. 애드킨스는 구글 보안 팀의 창립 멤버이고, 바이어는 대규모 시스템 운영의 패러다임을 바꾼 사이트 신뢰성 공학 관련 서적들을 써낸 인물입니다. 이들은 폴 블랭킨십, 피오트르 레반도프스키, 아나 오프레아, 아담 스터블필드와 힘을 합쳐 구글의 실제 현장 경험을 책으로 정리했습니다. 추상적인 지침이 아니라, 바로 사용할 수 있는 실행 체계로 말이죠. 시스템을 어떻게 설계하고, 코드를 어떻게 작성해 배포하며, 문제가 터졌을 때 어떻게 대응하고, 조직이 자체 무게를 견디지 못해 무너지지 않도록 하려면 어떻게 해야 하는지를 담았습니다. 오늘 이 시간 동안 여러분이 얻어가실 수 있는 명확한 결론이 있습니다. 보안과 안정성은 서로 다른 두 개의 부서가 아닙니다. 하나의 질문을 바라보는 두 개의 시선일 뿐입니다. 그 질문이란 바로 이것입니다. "누군가, 혹은 무언가가 이 시스템을 망가뜨리려 할 때도, 시스템이 원래 의도대로 작동할 것인가?" 이 관점을 이해하고 나면, 파편화되어 있던 여러 관리 실무가 하나의 정교한 규율로 꿰어지기 시작합니다. 오늘 우리는 구글이 구축한 이 규율의 핵심을 함께 짚어볼 겁니다. 시스템을 위협하는 존재를 바라보는 시각부터, 장애를 최소화하는 설계, 신뢰할 수 있는 코드의 배포, 그리고 마침내 비상 경보가 울렸을 때 현장을 지휘하는 법까지 차근차근 살펴보겠습니다. 먼저 우리의 적이 누구인지부터 시작해 보죠.

2장

누구에 맞서 시스템을 만드는지 파악하기

공격자가 누구이고 무엇을 원하는지 명확히 알지 못하면, 안전한 시스템을 설계할 수 없습니다. 너무나 당연한 말 같지만, 수많은 조직이 여전히 이 단계를 그냥 넘어가곤 합니다. 1986년, 클리포드 스톨이 수행했던 조사와 훗날 '교활한 해커 추적하기'라는 글로 정리된 이야기는 오래되었지만 아주 좋은 출발점입니다. 컴퓨터 시스템의 아주 작은 회계 오차 하나를 그냥 지나치지 않았던 스톨은, 끈질기고 침착하게 흔적을 추적한 끝에 침입자를 밝혀냈습니다. 이 사건은 방어자가 의지만 있다면 공격자의 흔적을 찾아낼 수 있다는 사실을 전 세계에 알렸죠. 구글에도 이상 징후를 감시하다가 겪은 아주 황당한 사건이 있습니다. 2012년, 벨기에의 한 데이터센터에서 이상 활동이 감지되었습니다. 원인을 조사해 보니, 데이터센터 안으로 몰래 들어온 고양이 한 마리가 센서를 건드린 것이었습니다. 이상 징후가 모두 공격자의 소행은 아닙니다. 하지만 공격이라고 가정하고 조사해 보기 전까지는 알 수 없는 법이죠. 공격자들의 모습은 천차만별입니다. 그저 재미나 명성을 위해 공격하는 사람이 있는가 하면, 정치적 신념이나 오직 돈을 노리고 움직이는 이들도 있습니다. 특정 국가의 지시를 받는 집단도 있죠. 북한의 사이버 공작과 연계된 박진혁 같은 인물이 대표적입니다. 정부의 자금과 끈질긴 지원을 받는 공격자들로, 심심해서 해킹을 시도하는 1대 청소년과는 차원이 다른 위협입니다. 그 사이에는 단순 취미 활동가, 기업의 허점을 먼저 찾아 보상을 받는 버그 바운티 연구원, 합법적으로 공격을 시도하는 레드팀, 시리아 전자군이나 어노니머스 같은 해커티비스트 그룹, 그리고 랜섬웨어나 스토커웨어로 수익을 올리는 범죄 조직들이 존재합니다. 하지만 감정적으로 가장 대비하기 어려운 위협은 따로 있습니다. 바로 내부자입니다. 불만을 품은 직원, 지나치게 많은 권한을 가진 외주업체 직원, 혹은 계정을 가져서는 안 될 협력사 관계자 같은 사람들입니다. 특정 인물이 누구냐가 중요한 게 아닙니다. 진짜 핵심은 여러분의 위협 모델에서 '내부자'를 별도의 위험 요소로 다뤄야 한다는 점입니다. 경계선 방어 체계는 적법한 접근 권한을 이미 가진 사람을 막도록 설계되지 않았기 때문입니다. 여기서 경험 많은 팀조차 빠지기 쉬운 함정이 있습니다. "우리같이 작은 조직을 굳이 노리겠어?"라고 생각하는 겁니다. 2012년 어도비가 침해를 당했던 건, 해커들이 오직 어도비만을 표적으로 삼았기 때문이 아닙니다. 접근하기 쉬웠고, 털었을 때 얻을 이익이 충분히 컸기 때문입니다. 기술이 화려하다고 해서 공격에 반드시 성공하는 것도 아닙니다. 아주 기초적인 방어조차 되어 있지 않아 허망하게 뚫리는 경우가 수없이 많으니까요. 게다가 진짜 범인을 찾아내는 일은 거의 불가능에 가깝습니다. 페티야나 낫페티야 악성코드 사태가 대표적입니다. 엄청난 조사 인력이 투입되었음에도 공격의 주체가 누구인지 끝내 명확히 밝혀지지 않았죠. 구글은 2009년, 아주 쓰라린 경험을 통해 위협 모델링의 교훈을 얻었습니다. 프로세스상의 실수로 인해 "이 사이트는 컴퓨터에 해를 끼칠 수 있습니다"라는 경고 태그가 수많은 정상 사이트에 잘못 부착된 사건이었습니다. 악의적인 공격자가 아니라 내부의 실수로 일어난 일이었죠. 여러분에게 찾아올 최악의 날 중 일부는 공격이 아니라 내부의 실수에서 비롯됩니다. 위협 모델에는 악의적 공격과 인간의 실수 모두를 위한 자리가 있어야 합니다. 정체를 명확히 파악했다면, 이제 이들을 실제로 막아낼 수 있는 시스템 설계로 넘어갈 차례입니다.

들리는 모든 단어를 눈으로 확인하세요

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

누구에게도 필요 이상의 권한을 주지 않는 설계

설계의 첫 번째 원칙은 '최소 권한의 원칙'입니다. 모든 사람과 시스템에 꼭 필요한 최소한의 권한만 주고, 그 이상은 절대 주지 않는 것입니다. 당연한 소리처럼 들리지만, 실제 기업들에서 권한이 어떻게 부여되는지 보면 그렇지 않습니다. 관리가 편하다는 이유로 기본 권한을 너무 넓게 주고, 한 번 준 권한을 회수하는 일은 거의 없죠. 구글이 제시하는 대규모 해결책은 '제로 터치 프로덕션'이라는 철학입니다. 이 철학의 중심에는 '세이프 프록시'라는 내부 메커니즘이 있습니다. 세이프 프록시는 엔지니어와 실제 운영 시스템 사이에서 작동하는 통제된 중계 시스템입니다. 엔지니어가 운영 환경을 직접 변경할 수 있는 상시 권한을 갖는 대신, 규칙을 강제하는 프록시를 거치도록 하는 것이죠. 이 변경을 수행할 자격이 있는지, 승인해 줄 제3자가 필요한지, 작업 속도가 제한되어 있는지, 감사 로그에 남는지 등을 프록시가 검증합니다. 예컨대 구글 내부의 툴 프록시는 전체 서버를 관리하는 시스템인 보그의 특정 명령어에 대해 '다자 승인'을 요구합니다. 어떤 엔지니어도 위험한 명령을 혼자서 실행할 수 없게 막고, 다른 누군가의 승인을 반드시 받도록 한 겁니다. 이 조치의 효과를 보여주는 놀라운 숫자가 있습니다. 구글은 전체 서비스 장애의 약 13%를 제로 터치 프로덕션 통제만으로 예방할 수 있었을 것으로 추정합니다. 코드를 더 잘 짜서가 아닙니다. 테스트를 더 많이 해서도 아닙니다. 단 한 명의 인간이 운영 시스템에 대해 독단적이고 검증되지 않은 권한을 갖지 못하게 막은 것만으로 얻어낸 결과입니다. 물론 비용도 듭니다. 세이프 프록시를 구축하고 유지하는 데는 많은 자원이 들어갑니다. 프록시 자체가 고장 나면 업무 전체가 마비되는 단일 실패점이 될 수도 있죠. 프록시의 설정이 잘못되면 공격자를 막는 게 아니라 정당한 업무까지 막아버릴 수 있습니다. 엔지니어들의 반발도 큽니다. 권한을 제한하는 번거로운 절차가 자신들의 역량을 신뢰하지 않는 것처럼 느껴지기 때문입니다. 그래서 설계 작업은 매우 정교해야 합니다. 최소 권한 원칙은 일률적인 규제가 아니라 위험도를 분류하는 작업입니다. 데이터를 공개 데이터, 민감 데이터, 극비 데이터로 나누고, 각 등급에 맞는 통제 조치를 적용해야 합니다. 광범위한 권한을 주는 대신 딱 한 가지 일만 수행하는 작고 전용화된 API를 만들어야 합니다. 구체적인 하나의 기능만 수행하는 인터페이스가 분석하기 훨씬 쉽고 무단 오용도 어렵기 때문입니다. 정말 비상한 상황에서 규칙을 우회할 수 있는 '비상 탈출 메커니즘'도 마련해야 합니다. 위기 상황에서 정당하게 규칙을 넘어서는 방법이 없으면, 사람들은 비공식적인 편법을 찾게 되고 그게 훨씬 더 위험하기 때문입니다. 그리고 모든 접근 요청에는 단순한 형식적 승인이 아닌, 구체적이고 감사 가능한 사유가 기록으로 남아야 합니다. 이 모든 타협을 한마디로 요약하면 이렇습니다. 당장의 속도와 편의성을 조금 희생하는 대신, 나중에 문제가 터졌을 때 피해가 번지는 범위를 획기적으로 줄이는 것입니다. 이 '피해 범위', 즉 '폭발 반경'이라는 개념을 잘 기억해 두시기 바랍니다. 이제 이어질 모든 시스템 설계의 핵심 개념이 될 테니까요.

4장

직관적으로 이해할 수 있는 시스템 설계

추상적으로 들릴 수 있지만, 전체 프레임워크에서 가장 강력하고 실용적인 도구 중 하나가 있습니다. 바로 '이해 가능성을 고려한 설계'입니다. 이해 가능한 시스템이란, 어떤 상황에서도 변하지 않아야 하는 원칙인 '불변성'을 활용해 시스템의 행동을 예측하고 실제로 그렇게 작동하는지 검증할 수 있는 상태를 말합니다. 지메일이 아주 좋은 예시입니다. 지메일처럼 거대한 시스템은 내부에 수많은 복잡성을 품고 있습니다. 사용자, 기기, 저장소, 스팸 필터링, 메일 발송 보장 메커니즘이 끊임없이 상호작용하죠. 엔지니어링의 목표는 이 복잡성을 완전히 없애는 게 아닙니다. 그건 불가능하니까요. 목표는 복잡성을 일정한 틀 안에 가두는 것입니다. 그래서 한 명의 엔지니어가 시스템 전체를 머릿속에 다 담고 있지 않아도, 특정 변경 작업이 안전한지 판단할 수 있게 만드는 것이죠. 이 복잡성을 가두는 도구가 바로 고전 보안 공학에서 가져온 '신뢰 기반 시스템', 즉 TCB입니다. 여러분의 TCB는 보안 보장이 유지되기 위해 '반드시 신뢰해야만 하는' 최소한의 코드, 시스템, 사람의 집합을 의미합니다. TCB 내부의 무엇인가가 뚫리면, 사용자에게 했던 모든 보안 약속이 깨집니다. 반대로 TCB 바깥에 있는 요소들은 오작동을 일으켜도 시스템 전체의 보안을 위협하지 못합니다. 설계의 목표는 명확합니다. TCB를 가능한 한 작게 만드는 것입니다. 온라인 쇼핑몰을 만든다고 가정해 봅시다. 비즈니스 로직을 단 한 줄도 쓰기 전에, 여러분이 선택한 아키텍처의 구조가 TCB의 크기를 결정해 버립니다. 시스템을 하나의 거대한 단일 구조로 만들면, 전체 애플리케이션이 사실상 하나의 TCB가 됩니다. 메모리와 신뢰, 실패를 모두 공유하기 때문에 어디 한 곳만 뚫려도 시스템 전체가 위험해지죠. 반면 마이크로서비스 구조로 나누면 신뢰 덩어리가 작은 단위들로 쪼개집니다. 추천 엔진이 공격당했다고 해서 결제 시스템까지 자동으로 뚫리지는 않는 겁니다. 여기서 한 단계 더 나아가 웹 오리진을 분리하고, 브라우저상에서 서로 다른 신뢰 영역을 물리적으로 격리하면, 브라우저 자체의 보안 모델을 활용해 격리 효과를 높일 수도 있습니다. 똑같은 제품이지만, 구조에 따라 "전체의 안전을 위해 어디까지 신뢰해야 하는가?"라는 질문의 답은 완전히 달라집니다. 식별 체계 역시 중요합니다. 이해 가능성은 코드에만 국한되지 않고, 지금 이 순간 내 시스템 안에서 누구 혹은 무엇이 움직이고 있는지 아는 것을 포함하기 때문입니다. 구글의 운영 환경 식별 모델은 관리자, 기기, 워크로드, 고객의 정체성을 명확히 구분합니다. 시스템을 통과하는 모든 요청에는 "이 요청의 진짜 주체는 누구인가?"에 대한 검증 가능한 답이 항상 따라다닙니다. 그 밑바탕이 되는 ALTS라는 전송 레이어는 내부 서비스 간의 인증을 자동으로 처리해 줍니다. 엔지니어가 매번 수동으로 신뢰 여부를 확인할 필요 없이, 구조적으로 신뢰가 강제되는 것이죠. 일반적인 코드 수준에서 이해 가능성은 '타입 시스템'으로 나타납니다. 프로그래머가 URL을 정화하거나 SQL 쿼리의 이스케이프 처리를 매번 기억해서 해주기를 바라는 대신, 규칙 자체를 타입 시스템에 집어넣는 겁니다. 예컨대 SafeHtml 같은 프레임워크는 안전하지 않은 HTML을 실수로 만들어내는 것 자체가 어렵도록 설계되어 있습니다. 배포 직전 엔지니어의 기억력에 의존하는 대신, 컴파일러가 알아서 불변성을 강제해 주는 겁니다. 아키텍처, 식별 체계, 그리고 타입 안전성까지. 이 모든 것을 관통하는 하나의 맥락은 같습니다. 이해 가능성은 있으면 좋은 옵션이 아니라, 우리가 한 모든 보안 약속을 실제로 검증할 수 있게 해주는 기반이라는 점입니다. 직관적으로 이해할 수 없는 시스템에 대해서는 그 어떤 보안도 보장할 수 없습니다. 하지만 변화 없이 멈춰있는 시스템은 취약해지기 마련이고, 현실의 그 어떤 시스템도 가만히 정지해 있지 않습니다. 그렇다면 힘들게 구축한 안전성을 깨뜨리지 않으면서, 시스템을 계속 변화시켜 나가려면 어떻게 해야 할까요?

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

끊임없이 변화하는 세계에서 살아남기

변화 그 자체가 안전한 시스템의 적은 아닙니다. 나쁘게 관리된 변화가 적일 뿐이죠. 여기서 필요한 원칙은 모든 업데이트가 점진적이고, 기록되며, 테스트되고, 격리되고, 검증을 거쳐 단계별로 진행되도록 시스템을 설계하는 것입니다. 그래야 변경 과정에서 문제가 생겼을 때, 정확히 어떤 변경 때문에 문제가 발생했는지 즉시 파악하고 해당 부분만 골라낼 수 있으니까요. 이 개념을 명확히 보여주는 세 가지 실제 사례가 있습니다. 소프트웨어에서 발견된 치명적 결함이었던 셸쇼크 사태는 단기적인 신속 대응을 요구했습니다. 공격받을 수 있는 시간을 줄이기 위해 즉시, 그리고 전면적으로 패치를 적용해야 했죠. 반면 더 강력한 인증을 위한 물리적 장치인 피도 보안 키 도입은 중기적 과제였습니다. 하룻밤 사이에 강제할 수 없기에 온 조직이 시간을 두고 계획을 세워 단계적으로 도입해야 했습니다. 웹 전체를 HTTP에서 HTTPS로 전환한 과정은 거대한 장기전이었습니다. 전체 인터넷의 기본 표준을 바꾸기 위해 수년에 걸쳐 지속적인 설득과 도구 개발, 그리고 인내심이 필요했던 작업이었습니다. 이 모든 변화 속에서 살아남을 수 있게 해준 아키텍처는 앞서 이해 가능성에서 다루었던 원칙과 같습니다. 바로 작고 격리된 컴포넌트 구조입니다. 구글 내부 서비스 앞단에서 트래픽을 처리하는 구글 프런트엔드는, 한 부분의 변경이 다른 부분으로 예측 못 할 파급 효과를 일으키지 않도록 설계되어 있습니다. 컨테이너와 마이크로서비스는 단순한 기술 트렌드가 아닙니다. 작고 자주 일어나는 배포를 두려움이 아닌 안전한 작업으로 만들어주는 도구입니다. 딱 하나의 격리된 영역만 건드리는 배포라야 배포하기 전에 안정성을 제대로 예측할 수 있기 때문입니다. 하트블리드 사태는 우리가 꼭 기억해야 할 경고입니다. 깔끔한 이론 분석에서는 놓치기 쉬운 세심한 교훈, 즉 압박 속에서 급하게 변화를 추진할 때 생기는 위험을 잘 보여주기 때문입니다. 하트블리드는 OpenSSL의 취약점이었는데, 이 소프트웨어가 인터넷 곳곳에 너무 깊게 박혀 있어서 어디에 쓰이고 있는지조차 제대로 파악하기 어려웠습니다. 이런 위기 상황에서는 누구나 가능한 한 가장 빠르게 움직이고 싶어 합니다. 하지만 안전한 격리와 단계별 배포 체계가 미리 갖춰져 있지 않은 상태에서 속도만 내다가는, 첫 번째 불을 끄기도 전에 또 다른 사고를 치고 맙니다. 교훈은 "천천히 움직이라"는 게 아닙니다. 비상사태가 터지기 전에 안전하고 빠른 변화를 가능하게 하는 기반 시설이 이미 마련되어 있어야 한다는 뜻입니다. 불이 난 와중에는 격리와 단계별 검증 체계를 새로 만들 수 없으니까요. 자, 그렇다면 다음 질문이 생깁니다. 변화는 계속 일어납니다. 공격도 들어오고, 실수도 발생합니다. 이 중 그 무엇도 완전히 피할 수는 없습니다. 이제 질문은 "어떻게 모든 실패를 완벽히 막을 것인가"에서 조금 더 정직한 질문으로 바뀌어야 합니다. "장애가 발생했을 때, 어떻게 해야 시스템 전체가 무너지는 것을 막을 수 있을까?"

6장

작은 불씨가 대형 화재로 번지지 않게 막기

이것이 바로 회복탄력성의 원칙이며, 가장 이해하기 쉬운 접근법은 '다중 방어'라는 고전적인 개념입니다. 정탐, 침투, 실행, 장악으로 이어지는 트로이 목마 작전의 단계를 생각해 보세요. 여러 겹의 방어선이 구축되어 있다면 이 과정 중 어느 단계에서든 침입자를 잡아낼 수 있습니다. 단 하나의 경계선만 있는 시스템은 한 번만 뚫려도 완패하고 맙니다. 하지만 겹겹이 층을 쌓아둔 시스템은 침입을 당하더라도 피해를 일부 영역으로 가둘 수 있습니다. 구글의 앱 엔진은 다중 방어가 실제 현장에서 어떻게 작동하는지 보여줍니다. 앱 엔진에서 실행되는 코드는 민감한 자원에 접근하기 전에 여러 겹의 샌드박스 레이어를 거쳐야 합니다. 위험도가 높다고 판단된 API는 추가적인 감시와 강력한 격리 조치를 받습니다. 격리된 환경에서 네이티브 코드를 안전하게 실행하는 네이티브 클라이언트 기술이나, 시스템 수준에서 프로세스의 동작을 정밀 감시하는 ptrace 같은 기술이 존재하는 이유가 바로 이것입니다. 한 겹의 방어선이 무너지더라도, 바로 다음 방어선이 그 이상 행동을 즉시 감지해 내도록 하기 위함입니다. 하지만 회복탄력성은 공격을 막는 것만을 의미하지 않습니다. 트래픽이 폭주하거나 시스템에 과부하가 걸렸을 때, 유연하게 성능을 줄여가며 견디는 능력도 포함됩니다. 핵심 기능을 보호하기 위해 중요도가 낮은 작업을 의도적으로 버리는 '부하 절단'이나, 시스템이 붕괴하지 않도록 요청 처리 속도를 누르는 '요청 제한' 메커니즘을 미리 설계해 두어야 합니다. 그리고 중요한 결정을 내릴 때 우연에 맡기지 말고 의도적으로 선택해야 합니다. '안전 우선'으로 갈 것인가, 아니면 '보안 우선'으로 갈 것인가를 말이죠. '안전 우선'은 문제가 생기면 일단 통과시켜 서비스의 가용성을 높이는 방식입니다. 반면 '보안 우선'은 문제가 생기면 일단 차단하여, 비록 서비스가 중단되더라도 보호를 최우선으로 하는 방식입니다. 정답은 없습니다. 병원 시스템과 결제 시스템은 서로 전혀 다른 선택을 할 수 있습니다. 진짜 문제는 아무런 선택도 하지 않은 채, 코드가 당황해서 나오는 대로 결과를 방치하는 것입니다. 이 프레임워크에서 가장 깊이 있는 회복탄력성 개념은 격리를 통해 폭발 반경을 직접 통제하는 것입니다. 역할별로 격리하여 한 계정이 뚫려도 다른 권한을 행사할 수 없게 하고, 지역별로 격리하여 한 지역의 장애나 침해가 전 세계로 퍼지지 않게 하며, 시간별로 격리하여 인증 정보와 접근 권한이 영원히 유지되지 않고 만료되도록 하는 것입니다. 구글은 위치 기반 신뢰와 암호화 격리 기술을 활용해, 한곳에서 발생한 문제가 정책이 아닌 구조적으로 그 지역에만 머물도록 강제합니다. 그리고 이 모든 것 밑바탕에는 장애 도메인 분리와 다중화라는 정교한 설계를 갖추고 있습니다. 모든 요소에 똑같은 공을 들일 필요는 없습니다. 어떤 컴포넌트는 갑작스러운 트래픽을 흡수할 수 있는 대용량 처리가 필요하고, 어떤 컴포넌트는 전체 서비스의 기반이 되므로 극도로 높은 가용성이 필요합니다. 또 어떤 컴포넌트는 다른 곳에 의존하지 않고 스스로 동작하게 만들어, 고장이 나도 다른 시스템을 끌어들이지 않도록 해야 합니다. 이 모든 것은 저절로 얻어지지 않습니다. 실제 운영 환경에 의도적으로 장애를 주입하고, 실제 트래픽을 테스트 환경으로 복제하며, 암호화 키를 정기적으로 교체해 프로세스가 정상 작동하는지 끊임없이 검증해야만 얻을 수 있습니다. 회복탄력성이 "어떻게 타격을 견뎌낼 것인가"에 대한 답이라면, 버티는 것과 원상태로 돌아가는 것은 또 다른 문제입니다. 연기가 잦아들거나 상황이 정리되고 나면, 시스템을 다시 완전히 신뢰할 수 있는 정상 상태로 돌려놓아야 합니다. 이건 또 다른 영역의 기술이며, 생각보다 훨씬 까다롭습니다.

들리는 모든 단어를 눈으로 확인하세요

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

정상 상태로의 확실한 복구

복구는 회복탄력성과는 별개의 독립된 원칙입니다. 장애를 견뎌내는 것과 장애가 남긴 피해를 복구하는 것은 완전히 다른 일이기 때문입니다. 시스템에 발생하는 오류는 무작위 하드웨어 결함, 사람의 실수, 악의적인 공격, 단순 코드 버그 등 다양한 원인이 있으며, 원인마다 복구 방법도 달라집니다. 배포 오류를 복구하는 것과 탈취당한 서명 키를 복구하는 것은 전혀 다른 문제입니다. 복구를 위한 설계에는 몇 가지 핵심 메커니즘이 필요합니다. 지침에 따라 관리되는 신속한 배포 체계가 있으면 패치를 빠르게 적용할 수 있습니다. 단, 이 역시 일반적인 변경 작업과 똑같이 통제되고 검증된 경로를 거쳐야 합니다. 조급하게 적용한 수정 패치가 또 다른 사고를 치지 않도록 말이죠. 격리되고 처리 속도가 제한된 마이크로서비스 구조 덕분에, 한곳에서 수행한 복구 작업이 순식간에 다른 곳으로 사고를 번지게 하지 않습니다. 그리고 시스템이 현재 시각에 너무 의존하지 않도록 만드는 것도 중요합니다. 에포크나 단조 증가 보안 버전 번호인 MASVN 같은 개념을 사용하면, 시스템이 "무엇이 신뢰할 수 있는 최신 버전인가"를 판단할 때 모든 기기의 시계가 초 단위로 일치해야만 하는 취약한 전제에 의존하지 않아도 됩니다. 문제가 생겼을 때 이전 버전으로 그냥 돌아가는 롤백 작업에도 숨겨진 위험이 있습니다. 어떤 소프트웨어의 6번 버전에서 보안 패치가 적용되었는데, 다른 버그를 피하겠다고 5번 버전으로 롤백하면 어떻게 될까요? 겨우 막아둔 보안 구멍을 다시 열어주는 꼴이 됩니다. 보안 버전 번호체계가 존재하는 이유가 바로 이 때문입니다. 이전 버전이 정상적인 복구 대상처럼 보이더라도, 시스템이 일정 보안 기준 이하로는 롤백되지 않도록 거부하는 겁니다. 서명 키 교체나 펌웨어 업데이트에도 같은 로직이 적용됩니다. 복구 메커니즘에는 "이 인증 정보, 이 키, 이 버전은 더 이상 신뢰할 수 없다"고 중앙에서 명확히 선언하는 실효 처리 기능이 있어야 합니다. 그리고 이 확인 과정 자체에 접근할 수 없을 때는, 시스템이 안전을 위해 자동으로 대상을 '신뢰할 수 없음'으로 간주하는 정적 차단 방식을 취해야 합니다. 물론 시스템의 원래 '정상 상태'가 어떤 모습인지 명확히 알지 못하면 이 모든 것은 불가능합니다. 너무나 당연한 말 같지만, 대규모 시스템에서 호스트 설정, 기기 펌웨어 버전, 글로벌 서비스 상태, 백업의 상태를 지속적으로 추적하여 '정상 상태'를 단순한 추측이 아닌 검증 가능한 사실로 유지하는 것은 매우 어려운 기술적 과제입니다. 복구 절차 역시 회복탄력성과 마찬가지로 끊임없이 테스트해야 합니다. 비상시 접근 권한, 통로, 압박 속에서 담당자들이 취할 행동까지 미리 신중하게 설계해야 합니다. 진짜 위기가 찾아왔을 때 비상 계획이 평화로운 상황에서만 작동한다는 사실을 깨닫는 것만큼 절망적인 순간은 없으니까요. 이제 복구와 회복탄력성의 세계에서 아주 특별한 공격 하나를 다뤄보겠습니다. 겉에서 보기에는 보안 침해처럼 보이지도 않고, 그저 갑자기 너무 많은 사용자가 한꺼번에 몰려오는 것처럼 보이는 공격입니다.

8장

트래픽 자체가 무기가 될 때

서비스 거부 공격, 즉 디도스는 기술적인 문제이기 전에 경제적인 문제입니다. 즉, 공급할 수 있는 용량을 초과하는 수요가 한꺼번에 몰리는 현상이죠. 공격자는 시스템 안으로 뚫고 들어올 필요조차 없습니다. 그저 시스템이 처리할 수 없을 만큼 수많은 요청을 퍼붓기만 하면 됩니다. 공격자들은 감염시켜 통제하에 둔 기기들의 네트워크인 봇넷을 활용하고, 작은 요청으로 엄청나게 큰 응답을 유도하는 증폭 기술을 사용합니다. 이를 통해 자신들이 가진 자원보다 수십, 수백 배 큰 파괴력을 만들어내죠. 따라서 방어도 단순히 반응하는 수준을 넘어 아키텍처 차원에서 이루어져야 합니다. 다중 방어로 부하를 여러 지점으로 분산시켜 단일 병목 지점이 생기지 않도록 해야 합니다. 애니캐스트 라우팅을 이용하면 트래픽이 한곳의 서버로 몰리지 않고 전 세계 여러 지역으로 자연스럽게 분산되어 흡수됩니다. 공용 인프라가 주는 경제적 이점도 큽니다. 구글의 프로젝트 쉴드는 독립 언론이나 인권 단체처럼 취약한 사이트들에 이런 방어망을 제공합니다. 거대한 공용 인프라를 활용해 공격을 흡수하는 것이, 작은 단체가 혼자서 방어하는 것보다 비용 면에서 비교할 수 없을 정도로 저렴하기 때문입니다. 서비스 단에서의 방어란, 공격자가 악용할 수 있는 요청 수와 대역폭을 최소화하도록 설계하는 것을 의미합니다. 공격적인 캐싱을 통해 반복되는 요청이 가장 비용이 많이 드는 내부 시스템까지 도달하지 않도록 막아야 합니다. 캡차처럼 사람과 봇을 구분하는 자동화된 완화 조치를 도입하고, 방어 메커니즘 자체가 혼란에 빠졌을 때는 일단 차단하여 안전을 도모하는 정적 차단 철학을 유지해야 합니다. 여기서 아주 흥미로운 사실 하나를 짚고 넘어가겠습니다. 때로는 우리가 우리 자신을 공격하기도 한다는 점입니다. 갑작스러운 지진이 발생하면 수많은 사람이 같은 순간에 동일한 정보 출처로 몰려듭니다. 독일의 한 예능 프로그램에서는 시청자들에게 화면의 안내에 따라 동시에 특정 행동을 하도록 유도해 순식간에 트래픽 폭주를 일으킨 적도 있습니다. 이 두 가지 모두 악의적인 공격은 아니었습니다.하지만 시스템 입장에서 보면 디도스 공격과 완전히 똑같이 보입니다. 동시다발적으로 폭주하는 트래픽의 특성은 그것이 봇넷에서 나오든, 놀란 사람들에게서 나오든 똑같기 때문입니다. 더 나쁜 것은 우리 시스템 스스로가 당황할 때입니다. 요청에 실패한 클라이언트들이 일시에 다시 요청을 퍼붓는 '클라이언트 재시도 폭풍'은, 작은 해프닝을 순식간에 대형 장애로 악화시킵니다. 이 문제를 해결하는 '지터를 포함한 지수 백오프'는 재시도 간격을 무작위로 넓혀주는 아주 작은 코드입니다. 이 작은 코드가 사용자들의 선의가 스스로를 공격하는 무기가 되지 않도록 막아줍니다. 지금까지 이야기한 모든 내용은 설계, 즉 코드를 배포하기 전 시스템의 구조에 관한 것이었습니다. 하지만 잘 설계된 시스템이라도 결국 사람이 작성하고, 검토하고, 배포하는 코드 위에서 돌아갑니다. 마감 직전 새벽 2시에, 동료의 40초짜리 건성 승인을 받고 배포되는 그 코드 말이죠. 이제 그 다음 단계로 넘어가 보겠습니다.

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

내가 만드는 코드에 대한 확신

버그는 피할 수 없습니다. 이건 패배주의가 아닙니다. 모든 엔지니어가 매번 모든 규칙을 기억해주길 바라는 대신, 특정 유형의 실수를 구조적으로 자동 차단하는 프레임워크를 만드는 이유입니다. 검증되지 않은 입력값이 실행 가능한 데이터베이스 명령어로 해석되어 버리는 고전적인 취약점인 'SQL 인젝션'을 예로 들어봅시다. 수천 명의 개발자가 참여하는 대규모 코드베이스에서, 모든 엔지니어가 매번 쿼리를 정화해주기만을 바랄 수도 있습니다. 아니면 TrustedSqlString 같은 전용 타입을 만들 수도 있죠. 이렇게 하면 컴파일러 자체가 검증되지 않은 입력으로 만든 쿼리를 거부하게 됩니다. 정해진 안전한 검토 과정을 거치지 않은 쿼리는 실행조차 되지 않는 겁니다. 물론 의도적으로 안전하지 않은 방식을 써야 할 때도 있습니다. 하지만 이 경우 보안 엔지니어의 명시적인 검토와 기록이 남아야만 하도록 만들었습니다. "누군가 깜빡하지 않으면 안전한 상태"였던 기본값을, "누군가 위험을 명시적으로 선택하지 않으면 안전한 상태"로 바꾼 것입니다. 웹에서 발생하는 크로스 사이트 스크립팅을 막아주는 SafeHtml 역시 마찬가지입니다. 개발자의 기억력에 의존하는 대신, 작성 단계부터 안전한 템플릿을 쓰도록 강제합니다. 이것은 매우 중요한 철학적 전환입니다. 코드가 다 작성된 후에 검토로 실수를 잡아내는 게 아니라, 애초에 실수를 코드 형태로 작성하는 것 자체를 어렵게 만드는 것입니다. 코드 작성 후 문제를 찾아내는 린터보다 컴파일 시점의 검사가 훨씬 강력합니다. 컴파일러가 안전하지 않은 코드의 빌드 자체를 거부하는 것이, 다 짜놓은 코드에 태그를 붙여 경고하는 린터보다 훨씬 더 확실한 보장책이기 때문입니다. 더 안전한 코드를 작성하는 것은 절반의 완성일 뿐입니다. 신뢰할 수 있을 만큼 혹독하게 테스트해야 합니다. 이 대목에서 이전 이야기와 연결되는 테스트 기법 하나를 소개합니다. 바로 '퍼즈 테스트'입니다. 퍼즈 테스트는 무작위로 변형되거나 잘못된 엄청난 양의 데이터를 코드에 퍼부어, 시스템의 다운이나 극단적인 예외 상황을 강제로 찾아내는 기법입니다. 인간 테스트는 생각지도 못했던 허점을 찾아내는 것이죠. 앞서 변화 관리 이야기에서 언급했던 OpenSSL의 하트블리드가 바로 이런 기법으로 찾아낼 수 있는 대표적인 결함입니다. 경계선 영역에서 아무도 주의 깊게 보지 않았던 예외 처리를 찾아내는 것이죠. 구글은 클러스터퍼즈라는 연속 퍼징 인프라와 OSS-퍼즈라는 오픈소스 프로젝트를 통해, 구글 내부 코드는 물론 인터넷 전체가 의존하고 있는 오픈소스 소프트웨어에 대해 대규모로 이 테스트를 돌리고 있습니다. 그다음은 배포입니다. 여기서 필요한 원칙은 '바이너리 출처 증명'입니다. 배포되는 모든 소프트웨어가 몇 가지 질문에 대해 검증 가능한 답을 갖고 있어야 합니다. 누가 또는 무엇이 만들었는가? 어떤 입력값이 들어갔는가? 어떤 명령어로 생성되었는가? 어떤 환경에서 빌드되었는가? 그리고 몇 번 버전인가? "이 프로그램이 정말 우리가 생각한 방식으로, 만든 곳에서 온 것이 맞는가?"라는 질문에 추측이 아닌 명확한 증거로 답할 수 있게 만드는 것입니다. 인토토라는 프레임워크가 바로 이 과정을 표준화합니다. 빌드와 배포의 모든 단계에 검증 가능한 암호화 증명을 붙여, 출처가 불분명한 프로그램은 배포 시스템이 실행 자체를 거부하도록 만드는 것입니다. 잘 작성되고, 혹독하게 테스트되고, 출처까지 검증된 코드라 하더라도 가끔은 실패합니다. 새벽 3시에 무언가 이상하게 동작할 때, 누군가는 도대체 무슨 일이 벌어지고 있는지 밝혀내야 합니다. 이건 코드를 작성하는 것과는 완전히 다른 종류의 기술이며, 프레임워크 역시 이를 별도의 영역으로 다룹니다.

10장

도대체 무슨 일이 일어난 걸까

운영 중인 시스템을 압박 속에서 조사하는 것은, 편안하게 책상에 앉아 시간을 갖고 코드를 디버깅하는 것과는 완전히 다릅니다. 이와 관련해 아주 유용한 비유가 있습니다. 바로 "말과 얼룩말" 이야기입니다. 말발굽 소리가 들리면 보통은 흔한 '말'이 나타난 것입니다. 즉, 지루하고 흔한 원인일 확률이 높죠. 하지만 아주 가끔은 정말 희귀하고 이상한 원인인 '얼룩말'일 때가 있습니다. 뛰어난 조사관은 조급하게 결론을 내리지 않고 이 두 가지 가능성을 모두 열어두어야 합니다. 임시 파일 문제로 발생했던 스패너 서비스 장애는 신중하고 체계적인 문제 해결이 무엇인지를 보여주는 아주 좋은 사례입니다. 압박 속에서 짐작으로 때려 맞히는 대신 조사할 시간을 충분히 확보하고, 기억을 믿지 않고 모든 관찰 기록을 남기며, 시스템의 정상 상태가 어떠했는지 정확히 알고 있어 이상 상태를 빠르게 알아채는 것입니다. 추상적인 이론을 늘어놓기보다 실제 문제를 재현해 보고, 상관관계와 인과관계를 철저히 구분해야 합니다. 두 사건이 동시에 일어났다고 해서 반드시 하나가 다른 하나의 원인은 아니기 때문입니다. 조사하다가 막힐 때가 있습니다. 누구나 경험하는 일이죠. 이럴 때 해결책은 이미 가지고 있는 정보를 더 세게 노려보는 게 아니라, 시스템 내부를 들여다보는 시야 자체를 넓히는 것입니다. 단일 요청이 여러 서비스를 거쳐 이동하는 과정을 추적하는 대퍼나 집킨 같은 도구가 만들어진 이유가 바로 이 때문입니다. 문제의 답은 여러분이 가진 로그 안에 있는 게 아니라, 아직 아무도 측정 장비를 달아두지 않은 시스템과 시스템 사이의 연결 고리에 있을 때가 많으니까요. 그리고 하나 더, 정말 중요한 조언이 있습니다. 중간중간 쉬어가는 것입니다. 조사 중간에라도 코드를 정리하세요. 완전히 이해하지 못하는 오래된 유산 시스템은 그냥 우회하지만 말고 삭제하세요. 아무도 제대로 이해하지 못하는 시스템 조각은, 향후 모든 조사 과정에서 두고두고 비용을 치르게 만듭니다. 디버깅 방법이자 교육 도구로 쓰이는 아주 특별한 실무 행위가 하나 있습니다. 바로 '불운의 수레바퀴'입니다. 팀원들이 모여 과거에 있었던 실제 장애 상황을 역할극처럼 단계별로 다시 따라가 보는 연습입니다. 이 연습은 문제 해결 감각을 끌어올려 줄 뿐만 아니라, 과거의 실패 경험과 지식을 그 사건을 직접 겪지 않았던 사람들에게까지 자연스럽게 전달해 줍니다. 보안 조사와 일반적인 디버깅은 실무적으로 큰 차이가 있습니다. 긴급성도 다르고, 목표도 다릅니다. 보안 조사에서는 여러분의 행동을 실시간으로 감시하며 반응하는 진짜 적이 존재할 수 있습니다. 그래서 단순히 시스템을 이해하는 것을 넘어, 내 조사를 방해하려 움직이는 상대방의 심리까지 계산해야 하는 어려움이 있습니다. 이 모든 과정은 필요할 때 제 역할을 해주는 로그 기록에 의존합니다. 하지만 로그 작성에는 명확한 현실적 갈등이 존재합니다. 공격자가 흔적을 지울 수 없도록 로그는 수정 불가능해야 합니다. 하지만 로그는 사생활 보호 문제와 끊임없이 충돌합니다. 얼마나 깊게 기록해야 하는지, 얼마나 오래 보관해야 하는지, 누구에게 접근 권한을 줄 것인지, 민감한 정보는 암호화하거나 익명 처리해야 하는지 등의 문제가 생기죠. 게다가 비용이라는 현실적인 벽도 있습니다. 모든 데이터를 영원히 완벽한 화질로 남길 수는 없습니다. 따라서 시스템에는 로그 출력 수준을 유연하게 줄이는 기능과, 당장 필요한 데이터는 빠르게 조회할 수 있는 온난 저장소에 두고, 나중에 필요할지 모를 데이터는 저렴한 냉동 저장소로 보내는 계층화 구조가 반드시 필요합니다. 조사, 로그, 신중한 디버깅이라는 모든 기초 작업은, 정작 중요한 순간에 딱 하나의 질문에 답하기 위해 존재합니다. "도대체 무슨 일이 일어난 걸까?" 이 질문에 대한 답을 찾는 순간 모든 것이 달라집니다. 무언가 진짜 잘못되었다는 확신이 드는 순간, 여러분은 더 이상 디버깅을 하고 있는 게 아닙니다. 완전히 새로운 모드로 진입하게 되는 것이죠.

들리는 모든 단어를 눈으로 확인하세요

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

11장

호출 벨이 진짜로 울렸을 때

대부분의 팀이 압박 속에서 혼동하곤 하지만, 프레임워크가 명확히 구분하는 개념이 있습니다. 바로 '일상적인 장애'와 '위기 상황'은 완전히 다르다는 점입니다. 위기 상황에서는 현재 무엇이 위험에 처해 있는지 빠르게 분류하는 우선순위 판단이 필요합니다. 그리고 즉시 현장을 지휘할 단 한 명의 지휘관이 지정되어야 합니다. 똑똑한 사람 여럿이 모여 서로 자기가 이끌겠다고 나서는 상황은, 지휘관이 아예 없는 것보다 훨씬 더 끔찍한 결과를 낳기 때문입니다. 구글은 응급 구조 현장에서 사용하는 긴급 대응 체계를 본뜬 IMAG라는 장애 관리 체계를 도입했습니다. 공포와 당황이 현장을 지휘하지 못하도록 통제하는 법을 수십 년간 연구해 온 전문가들의 노하우를 그대로 가져온 것입니다. 전체 프레임워크가 어떻게 하나로 모이는지 보여주는 실제 사례가 있습니다. 침해당한 엔지니어 계정이 가상화폐 채굴에 악용된 사건이었습니다. 시작은 상황을 빠르게 분류하고 사태의 심각성을 파악하는 것이었습니다. 이후 정식으로 비상 상황을 선포하여 즉흥적인 단체 채팅방 대신 체계적인 대응 구조를 갖추었습니다. 그 과정에서 어떤 대화 채널을 사용할지 결정하는 운영 보안적 판단도 내려야 했습니다. 공격자가 대응 채널을 훔쳐보고 있을 수도 있으므로, 비상 대응 자체도 보호해야 할 대상이 되기 때문입니다. 그리고 분석 기법들이 적용되었습니다. 디지털 증거를 확보하고 메모리를 분석하며 사태를 하나하나 파헤쳤습니다. 사람들이 서로의 발을 밟지 않도록 분석 작업을 여러 조직으로 분산시켜 진행했습니다. 그리고 마침내 복구에 들어갔습니다. 탈취당한 계정을 격리하고, 영향을 받은 시스템을 검증된 정상 상태에서 다시 빌드했으며, 연관된 모든 인증 정보를 교체한 후에야 비로소 상황 종료를 선언했습니다. 이 과정에서 얻을 수 있는 직관에 반하는 중요한 통찰이 하나 있습니다. 비상 대응 작업은 병렬로 진행되어야 한다는 점입니다. 한 사람이 감지부터 해결까지 일렬로 진행하는 것이 아니라, 하나의 지휘 체계 아래에서 여러 작업이 동시에 진행되어야 합니다. 그리고 인수합병 작업, 특히 해가 지지 않는 '팔로우 더 선' 방식의 인수인계가 매우 중요합니다. 내 일과가 끝날 때 다른 시차에 있는 팀에게 사건을 매끄럽게 넘겨주어야 합니다. 그래야 비상 상황이 한 팀의 희생이나 잠을 포기해가며 버티는 무모함에 의존하지 않게 됩니다. 사건을 제대로 마무리 짓는 복구 작업 역시 그 자체로 정교한 기술입니다. 추측이 아닌 정확한 침해 범위를 확정해야 합니다. 내가 복구 작업을 시작하는 순간 공격자 역시 이를 눈치채고 실시간으로 반응할 수 있다는 점을 계산해야 합니다. 빠른 해결을 위한 임시 조치가 향후 수년간 갚아야 할 기술적 부채가 될 수 있음을 인정해야 합니다. 그리고 사건이 끝난 후에는 심리적 안전감이 보장된 상태에서 '비난 없는 사후 분석'을 진행해야 합니다. 누군가를 처벌하기 위한 표적 수사를 하는 대신, 무엇이 왜 잘못되었는지 정직하게 밝혀내고 시스템을 개선해야 합니다. 컬럼비아호 우주복선 참사 조사는, 단순한 기술적 통제뿐만 아니라 조직의 문화가 실패로부터 배움을 얻을지 아니면 위험한 실수를 조용히 반복할지를 결정한다는 점을 보여주는 무거운 경고로 인용됩니다.

12장

이것이 우리에게 던지는 진짜 질문

세이프 프록시, 보안 버전 번호, 바이너리 출처 증명, 비난 없는 사후 분석까지. 이 모든 이야기는 사실 구글이라는 거대한 기업의 규모에 관한 것이 아닙니다. 마음가짐과 태도에 관한 이야기입니다. 공격자가 나보다 더 똑똑할 수 있음을 인정하세요. 내가 제어할 수 없는 일정에 따라 장애는 반드시 찾아온다는 사실을 받아들이세요. 그리고 장애가 찾아왔을 때, 조용하고 영구적인 대참사가 되는 대신 작고, 격리되며, 눈에 보이고, 복구 가능한 수준에 머물도록 시스템을 설계하세요. 구글의 거대한 인프라가 없어도 구글의 감각은 얼마든지 가져다 쓸 수 있습니다. 아주 작은 팀이라도 위험한 변화를 시도하기 전에 물어볼 수 있습니다. "지금 한 사람에게 이 시스템을 무너뜨릴 수 있는 독단적인 권한이 있는가? 그래도 괜찮은가?" 다섯 명으로 시작하는 스타트업이라도, 특정 시스템이 고장 났을 때 일단 통과시킬지 아니면 일단 차단할지를 실제 장애가 터지기 전에 미리 결정해 둘 수 있습니다. 그 어떤 팀이라도 자신들이 가진 장애 기록을 바탕으로 '불운의 수레바퀴' 연습을 해볼 수 있고, 서로를 탓하는 대신 시스템을 개선하는 사후 분석 문화를 만들 수 있습니다. 여기에는 조직의 대화 방식을 바꾸는 것 외에는 단 한 자루의 돈도 들지 않습니다. 이 모든 이야기의 가장 깊은 곳에 있는 아이디어는, 서두에 말씀드렸던 드릴과 금고 이야기 속에 숨어 있습니다. 여러분이 추가하는 모든 보안 통제 장치는, 의도했든 그렇지 않았든 간에 시스템의 안정성에 영향을 미치는 결정입니다. 그리고 여러분이 타협하는 모든 안정성의 편의 조치 역시, 인지했든 그렇지 않았든 간에 보안에 영향을 미치는 결정입니다. 하나를 선택하면서 다른 하나를 선택하지 않을 수는 없습니다. 우리에게 남은 유일한 선택은 이것뿐입니다. 그 타협을 해가 떠 있는 동안 비상 상황이 오기 전에 미리 고민해서 결정할 것인가, 아니면 새벽 3시에 잠긴 금고 앞에 서서 드릴을 찾으며 내가 과거에 무슨 결정을 내렸던 것인지 뒤늦게 깨달을 것인가 하는 점입니다.

★★★★★

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 완독을 축하합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 핵심 주제

site reliability engineering
adversarial threat modeling
systemic resilience design
security reliability intersection
insider threat mitigation

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 명문장

Security and reliability are natural companions.
Simplicity improves both reliability and security.
Attackers choose the simplest, most cost-effective methods.
Defense in depth limits attacker visibility.
Resilience emphasizes preventing or delaying breakage.

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 등장인물

Heather AdkinsLead author and security engineering expert
Betsy BeyerCo-author and site reliability expert
Paul BlankinshipCo-author and system security specialist
Park Jin HyokNorth Korean operative and security adversary

저자 소개

Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, Adam Stubblefield는 Google의 보안 및 신뢰성 분야를 선도하는 전문가들이자, Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems의 공동 저자들입니다. Google의 보안 및 사이트 신뢰성 엔지니어링(SRE) 팀에서 수십 년간 쌓아온 경험을 바탕으로, 이들은 하이퍼스케일 환경을 위한 회복 탄력성 있는 인프라 구축을 전문으로 합니다. 이들의 연구는 기술적 아키텍처와 조직 문화를 연결하며, 현대 분산 시스템에서 보안과 신뢰성이 어떻게 교차하는지를 강조합니다.

Beyer는 이전에 Google의 기초가 된 Site Reliability Engineering 시리즈를 공동 집필했으며, Adkins는 20년의 재임 기간 동안 Google의 사이버 보안 전략 수립을 도왔습니다. Lewandowski와 Oprea는 각각 적대적 위협 분석과 암호화 시스템 분야의 전문 지식을 기여하고 있습니다. 이 책은 Google의 제도적 지식을 반영하며, 포춘 500대 기업과 클라우드 네이티브 스타트업들이 채택한 실행 가능한 프레임워크를 제공합니다.

O’Reilly의 찬사받는 인프라 시리즈로 출간된 이 가이드는 6개 언어로 번역되어 엔지니어와 아키텍트들을 위한 표준 참조서가 되었습니다. 이 책의 원칙들은 전 세계의 인증 프로그램과 기업 보안 프로토콜의 근간을 이루고 있습니다.

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 다운로드

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Building Secure and Reliable Systems

Heather Adkins & Betsy Beyer & Paul Blankinship & Piotr Lewandowski & Ana Oprea & Adam Stubblefield

How Google Works

Eric Schmidt & Jonathan Rosenberg

Psychological Safety Meets The Culture Code 책 표지

The Culture Code | Summary, Quotes, FAQ, Audio

Psychological Safety at Work: A Comprehensive, Science-Backed Guide for Business Leaders

6 sources

Psychological Safety Meets The Culture Code

AI safety research and why models learn to cheat 책 표지

19 sources

AI safety research and why models learn to cheat

Google Antigravity: The Agentic Shift 책 표지

Build with Google Antigravity, our new agentic development platform

- Google Developers Blog

Introducing Google Antigravity, a New Era in AI-Assisted Software ...

Antigravity Agent | Gemini API | Google AI for Developers

8 sources

Google Antigravity: The Agentic Shift

Google sign-in and the friction of digital security 책 표지

1 source

Google sign-in and the friction of digital security

Google Search and the Monetization Gap 책 표지

The Competitive Effects of Search Engine Defaults

Google Organic CTR 2025 [New Study of 200K Keywords]: Organic CTRs for Position #1 Down 32%

7 sources

Google Search and the Monetization Gap

The Extended Mind: From Firms to Google 책 표지

[ceb385e4-1904-4198-8ac9-bae18ecb0f4f:c0000] 2011-08 - Google Effects on Memory (Sparrow et al).pdf p1-1

[ceb385e4-1904-4198-8ac9-bae18ecb0f4f:c0001] 2011-08 - Google Effects on Memory (Sparrow et al).pdf p1-1

[ceb385e4-1904-4198-8ac9-bae18ecb0f4f:c0002] 2011-08 - Google Effects on Memory (Sparrow et al).pdf p1-1

[ceb385e4-1904-4198-8ac9-bae18ecb0f4f:c0003] 2011-08 - Google Effects on Memory (Sparrow et al).pdf p1-1

25 sources

The Extended Mind: From Firms to Google

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에 관한 자주 묻는 질문

더 알아보기

학습 계획

Google's Global Data Dilemma

In an era of instant global access, engineers must solve the complex challenge of keeping data consistent across continents. This plan is essential for backend developers and system architects looking to master the high-stakes engineering required to power worldwide platforms like Google.

48 m•2 섹션

학습 계획

DevSecOps

As cyber threats evolve, security can no longer be a final checkpoint; it must be embedded into every stage of the software lifecycle. This plan is essential for developers, DevOps engineers, and security professionals looking to build resilient, automated, and compliant delivery pipelines.

5 h 2 m•4 섹션

학습 계획

Architecting Digital Fortresses

This plan is essential for developers and security professionals who need to understand the mathematical foundations of encryption. It provides the practical skills required to defend against modern cyber threats by securing data at every layer of the infrastructure.

2 h•4 섹션

학습 계획

The Hacker Mindset: Security as a Trade-off

In an era of increasing data breaches, understanding the adversarial perspective is essential for building robust defenses. This plan is ideal for aspiring security professionals and developers who want to master authentication, encryption, and network protection.

1 h 30 m•3 섹션

학습 계획

Architecting Secure Agentic Workflows

As AI agents gain autonomy, the risk of unconstrained actions grows, making security architecture a top priority for developers. This plan is essential for software architects and security engineers looking to build resilient, verifiable, and safe agentic systems.

1 h 30 m•3 섹션

학습 계획

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 섹션

학습 계획

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 섹션

학습 계획

Tiered Security Architecture Foundations

In an era of sophisticated cyber threats, moving beyond basic firewalls is essential for organizational resilience. This plan is ideal for network architects and security professionals looking to master identity-centric security and Zero Trust transitions.

2 h•4 섹션

컬럼비아 대학교 동문들이 제작 샌프란시스코에서 개발

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

4.7

평균 평점

앱 평가 7.84천 개 이상

BeFreed Community

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

컬럼비아 대학교 동문들이 제작 샌프란시스코에서 개발

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

4.7

평균 평점

앱 평가 7.84천 개 이상

BeFreed Community

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 개요

다양한 학습 방식으로 신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 살펴보기

자물쇠공의 악몽

누구에 맞서 시스템을 만드는지 파악하기

들리는 모든 단어를 눈으로 확인하세요

누구에게도 필요 이상의 권한을 주지 않는 설계

직관적으로 이해할 수 있는 시스템 설계

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

끊임없이 변화하는 세계에서 살아남기

작은 불씨가 대형 화재로 번지지 않게 막기

들리는 모든 단어를 눈으로 확인하세요

정상 상태로의 확실한 복구

트래픽 자체가 무기가 될 때

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

내가 만드는 코드에 대한 확신

도대체 무슨 일이 일어난 걸까

들리는 모든 단어를 눈으로 확인하세요

호출 벨이 진짜로 울렸을 때

이것이 우리에게 던지는 진짜 질문

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 완독을 축하합니다

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 핵심 주제

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 명문장

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약의 등장인물

저자 소개

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 다운로드

다른 사용자들도 좋아한 책

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에 관한 자주 묻는 질문

What is Building Secure and Reliable Systems about?

Who should read Building Secure and Reliable Systems?

Is Building Secure and Reliable Systems worth reading?

What are the key principles in Building Secure and Reliable Systems?

더 알아보기

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

다양한 학습 방식으로 신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 살펴보기

자물쇠공의 악몽

누구에 맞서 시스템을 만드는지 파악하기

들리는 모든 단어를 눈으로 확인하세요

누구에게도 필요 이상의 권한을 주지 않는 설계

직관적으로 이해할 수 있는 시스템 설계

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

끊임없이 변화하는 세계에서 살아남기

작은 불씨가 대형 화재로 번지지 않게 막기

들리는 모든 단어를 눈으로 확인하세요

정상 상태로의 확실한 복구

트래픽 자체가 무기가 될 때

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약에서 더 많은 것을 얻으세요

내가 만드는 코드에 대한 확신

도대체 무슨 일이 일어난 걸까

들리는 모든 단어를 눈으로 확인하세요

호출 벨이 진짜로 울렸을 때

이것이 우리에게 던지는 진짜 질문

신뢰할 수 있는 시스템 구축을 위한 SRE와 보안 협업 가이드 요약 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기