목표에 도달했나요? SRE팀의 성숙도 평가에 대한 고찰

고객 신뢰성 엔지니어(Customer Reliability Engineers, CRE), 즉 Google Cloud 고객이 조직에서 직접 관행을 개발하는 데 도움을 주는 Google 사이트 안정성 엔지니어(Google Site Reliability Engineer ,SRE)가 담당하는 업무에는 운영팀 또는 SRE팀이 운영 성숙도를 높이도록 자문을 제공하는 일이 포함됩니다. 이러한 논의에서 반복적으로 제기되는 질문이 있는데 일반적으로 "지금 우리가 하는 일이 'SRE 업무'인가요?" 또는 "우리를 SRE라고 부를 수 있나요?"라는 보다 존재론적인 요소가 가미된 같은 표현이 사용됩니다. 

이전에는 그러한 질문에 SRE 통합문서의 관행 목록으로 답변했습니다. 하지만 목록에는 업무에 대한 내용은 많지만 팀의 존재 이유에 대한 설명은 적어 정체성 위기를 겪고 있는 팀에서 받아들이기는 어렵습니다. 그래서 Google에서는 SRE팀 운영에 있어 필수적이라고 생각하는 원칙에 대해 논의하여 그러한 질문에 답하는 데 도움을 드리고자 합니다. 운영 원칙이 중요한 이유를 살펴보고 원칙을 구현하는 과정에서 팀의 위치를 파악할 수 있는 질문을 제시하겠습니다. 

목표에 도달했나요?

이 질문은 갖은 이유로 인해 다양한 방식으로 던질 수 있으며 고객이 운영하는 환경이 다양하기 때문에 이 질문에 답하기가 매우 어려울 수 있습니다. 더불어 CRE와 Google은 조직의 'SRE'가 무엇인가에 대해 최종 정의를 내릴 수 없기 때문에 권위 있는 답이 존재한다 하더라도 그 답을 제공할 수 없습니다. Google에서는 대면 상담 또는 책자와 블로그 게시물을 통해 의견과 경험을 제시하여 사용자와 커뮤니티에 영향을 줄 수 있을 뿐입니다. 

게다가 이 주제에 대한 논의는 'SRE'라는 용어가 다음과 같은 세 가지 의미로 혼용되기 때문에 복잡해지는 경향이 있습니다.

1. 서비스나 제품의 안정성을 유지하는 데 주력하는 직종

2. 조직 내에서 일반적으로 위의 직종을 담당하는 집단

3. 위 담당자가 서비스 안정성을 개선하는 데 사용할 수 있는 원칙 및 관행 집합

"우리를 SRE라고 부를 수 있나요?"라는 질문을 Google에서는 위의 세 가지 정의를 연결지으려는 시도라고 해석합니다. 이 해석을 보다 명확하게 표현하면 "우리 집단의 직종을 SRE라고 정의해도 합당할 정도로 원칙과 관행을 충분히 적용하고 있나요?"라는 질문이 될 수 있습니다. 

SRE로 인정받을 만한 일을 하기 위한 원칙과 관행을 활용하기 위해서는 먼저 직종이나 팀이 명확히 정의되어야 한다는 의미가 아님을 분명히 밝힙니다. 조직이 성장함에 따라 직종과 팀은 보다 유연한 책임 집합을 통해 구체화됩니다. 하지만 구체화 과정 속에서 담당자들은 어디까지 책임을 져야 하는지에 대해 다소 확신을 잃게 되고 '목표에 도달했는가?'라는 질문을 하게 됩니다. 여기서 존재론적인 의문이 비롯된다고 생각합니다.

주요 SRE 지표

Google Cloud의 CRE팀에서는 "목표에 도달했나요?"라는 질문을 통해 SRE팀에 방향을 제시하는 핵심 원칙에 대한 다양한 의견을 도출했습니다. 하나의 단서를 달고 대략적인 합의에 도달했습니다. 바로, 이 질문에 대한 답은 팀이 지원하는 서비스에 관여하는 방식에 부분적으로 좌우된다는 것입니다.

프로덕션 단계의 서비스를 직접 지원하는 SRE로 활동하는 집단에서 지켜야 할 원칙을 중심으로 게시물을 작성했습니다. 리트머스 테스트처럼 본 게시물은 정확한 답을 제공하지는 않습니다. 다만 Google의 집단적인 의견은, 적어도 아래 소개된 대부분의 원칙에 부합한다면 사이트 안정성 엔지니어링팀이라고 부를 수 있는 관행을 실천하고 있다는 좋은 신호라고 할 수 있다는 것입니다.

직접적으로 개입하는 SRE팀은 일반적으로 서비스 안정성에 대한 책무(RACI 용어 측면)가 있으며 SRE팀과 개발팀이 책임을 공유한다고 간주됩니다. 팀이 직접 지원을 제공하는 정도가 덜하다면 이러한 지표를 적용하기 어려울 수 있습니다. 그렇더라도 팀이 처한 환경에 맞게 원칙을 조정할 수 있기를 바랍니다. 

이를 실행하는 방법을 설명하기 위해 원칙별로 모범적으로 활동 중인 SRE팀에 반대되는 예를 제시했습니다. 이들은 주제 전문가로서 서비스 안정성에 대해 책임과 책무가 있는 개발팀으로부터 자문을 받습니다.

참여 모델이 스펙트럼 상에 있다면, 조직의 나머지 부서로부터 서비스 안정성에 대해 공동 책임을 지고 있는 팀 또는 안정성 주제 전문가로 간주되는 것은 SRE임을 판단할 수 있는 주요 지표입니다.

제1원칙: SRE는 현재와 미래의 이슈를 완화합니다

이 원칙은 일반적으로 서비스 안정성에 대한 책임 및 책무의 기저를 이룹니다. 이 세상에서 아무리 꼼꼼한 엔지니어링과 규제라도 특히 복합 분산 시스템에서의 안정성을 보장할 수 없으며 예상치 못한 오류가 발생하는 경우에는 대응하고, 완화하고, 바로잡는 수밖에 없습니다. SRE는 이러한 상황에서 신속하게 서비스를 복구하는 권한과 기술적 역량을 모두 갖추고 있습니다.

하지만 당면한 문제를 완화하는 것만으로는 부족합니다. 내일 문제가 다시 발생할 수 있고 심지어 오늘보다 상황이 더 나쁠 수 있기 때문에 SRE는 이슈 촉발 요소를 이해하고 담당하는 인프라 내 모든 등급의 문제를 방지하는 변경사항을 제안해야 합니다. 다음 달에 똑같은 식의 서비스 중단이 다시 발생해서는 안 됩니다.

서비스 중단이 얼마나 특별한 경우에 해당하나요? 다음을 자문해 보세요.

• 개발팀의 전문 지식이 없어도 이슈 대부분을 완화할 수 있나요?
• 교육 자료를 보존하고 이슈 대응 시나리오를 훈련하나요?
• 중대한 서비스 중단이 발생한 후 문제의 진정한 원인을 분명하게 밝히고 서비스 중단을 방지할 방법을 파악하는 주요 담당자에 해당하나요?

이제 반대 예를 알아보겠습니다. 많은 조직에서 SRE는 희소 자원에 해당하며 이슈 대응에 주력하기보다 기업 전반의 경쟁력을 강화하기 위한 플랫폼 및 권장사항을 개발함으로써 가치를 더할 수도 있습니다. 따라서 대대적인 서비스 중단 발생 시 컨설팅 SRE팀이 이슈 대응에 협력하도록 호출을 받더라도 대부분의 이슈 완화에 직접 관여하지 않을 가능성이 있습니다. 교육 자료를 작성하고 사후 분석을 진행하는 대신 자문을 받은 팀이 작성한 자료를 검토하는 업무를 담당합니다.

제2원칙: SRE는 적극적으로 서비스 안정성을 관리합니다

안정성 목표와 피드백 신호는 SRE 업무에 동기를 부여하고 개발 작업 우선순위에 영향을 주는 기본적인 요소입니다. Google에서는 안정성 목표를 서비스 수준 목표, 피드백 신호를 오류 예산이라 하며 자세한 활용 방식은 사이트 안정성 통합문서를 참조하시기 바랍니다. 

안정성 신호가 조직의 우선순위에 영향을 미치나요? 다음을 자문해 보세요.

• 자신이 지원하는 조직의 서비스 안정성 목표에 동의하며 목표 대비 성과를 실시간으로 추적하나요?
• 최근 서비스 안정성을 바탕으로 조직 활동을 조율하는 피드백 루프를 수립했나요?
• 안정성 목표를 추구하는 과정에서 조직 내 변화에 영향을 줄 권한이 있나요?
• 서비스가 현재의 안정성 목표를 달성하지 못할 가능성이 있는 변경사항을 요청받았을 때 거절하거나 목표를 완화하는 협상을 진행할 대행사가 있나요?

각 질문은 이전 질문에 기반합니다. 잘 정의되고 측정된 안정성 목표가 없다면 데이터 기반 피드백 루프를 수립하기란 거의 불가능한 일입니다. 유의미한 목표를 수립하려면 SRE는 목표를 뒷받침할 역량을 갖춰야 합니다. 서비스 안정성이 떨어지는 기간에는 미래 프로덕션 변경의 총 위험을 일시적으로 완화하고 안정성을 회복하는 것으로 엔지니어링 우선순위를 변경해야 합니다. 

서비스 안정성 유지와 새롭지만 안정성이 떨어지는 기능의 출시 사이에서 선택을 내려야 할 때 SRE는 '반대'할 수 있어야 합니다. 이러한 반대는 데이터에 기반한 결정이어야 합니다. 오류 예산에 여유가 없을 경우 사용자 불만족을 야기하는 것에 대한 타당한 비즈니스 이유가 있어야 합니다. 물론 타당한 이유가 있는 경우도 있을 것입니다. 이때에는 안정성 요건을 완화한 느슨한 새 SLO 목표를 통해 수용할 수 있습니다.

반대로 컨설팅 SRE는 팀이 안정성 목표를 작성하는 데 도움을 주고 조직 전반에서 목표를 측정하기 위한 공통 모니터링 인프라를 개발할 수도 있습니다. 사실상 안정성 피드백 루프를 관리하고 이를 뒷받침하는 정책 문서를 유지하는 역할을 합니다. 컨설팅 SRE는 여러 팀 및 서비스와 연결되어 있어 폭넓고 유용한 정보를 얻기 때문에 부서 간 안정성 향상을 촉발할 수 있습니다. 

제3원칙: SRE는 조기에 포괄적으로 참여합니다

앞서 설명한 바와 같이 SRE는 오늘보다 더 나은 미래를 구축할 수 있어야 합니다. 지원하는 코드와 서비스의 구성을 변경할 수 없다면 문제 발생 시 해결할 수 없습니다. 설계 단계에서 SRE를 조기에 참여시키면 값비싼 사후 수정이 필요한 일반적인 안정성 안티패턴을 방지할 수 있습니다. 또한 SRE가 아키텍처 의사 결정에 영향을 줄 수 있는 역량을 갖추면 하나의 서비스 안정성 향상이 회사 전체에 혜택이 되도록 조직 전반을 통합할 수 있습니다.

팀이 오늘보다 더 나은 미래를 위해 적극적으로 활동하고 있나요? 세부적인 부분부터 폭넓고 개략적인 부분까지 아우르는 질문을 자문해 보세요.

• 소스 코드나 구성을 보고 수정하는 것처럼 안정성을 개선하기 위해 현재 서비스를 설계하고 있나요?
• 향후 서비스 반복을 분석하고 설계하는 데 참여하여 안정성/운영성/유지보수성에 대한 관점을 제시하나요?
• 조직의 전반적인 아키텍처 의사 결정에 영향을 줄 수 있나요?

다른 팀에 자문을 제공하다보면 개별 서비스의 구성이나 코드를 직접 수정하는 일이 우선순위에서 밀리게 마련입니다. 하지만 컨설팅 SRE도 일반적인 측정항목 내보내기나 점진적인 서비스 품질 저하 같은 핵심 안정성 기능을 제공하는 공유 라이브러리나 프레임워크를 유지할 수 있습니다. 여러 팀에 폭넓게 관여하기 때문에 개략적인 아키텍처 자문을 제공하여 조직 전반의 안정성을 개선하는 데 적합합니다.

제4원칙: SRE는 반복되는 모든 작업을 자동화합니다

마지막으로 SRE는 기본적으로 컴퓨터가 인간보다 반복 작업에 더 적합하다고 생각합니다. 사람들은 일상 작업의 자동화를 고려할 때 투자수익을 과소평가하는 경우가 많은데 이는 성공적인 서비스를 대규모로 실행하는 데 따르는 기하급수적인 성장 곡선을 고려하지 않은 결과입니다. 게다가 컴퓨터는 같은 작업을 100번 하더라도 주의력이 떨어지거나 실수를 하지 않으며 사기가 저하되어 그만두는 일이 없습니다. SRE를 교육하거나 채용하는 데 많은 비용과 시간이 들기 때문에 SRE 조직의 성공은 지루한 작업을 컴퓨터가 처리하는지에 크게 좌우됩니다.

업무를 충분히 자동화하고 있나요? 다음을 자문해 보세요.

• 유기적 성장이나 지원하는 서비스 수의 증가에 비례하여 운영 부하가 증가하지 않도록 자동화 및 기타 도구를 사용하거나 제작하나요?
• 팀의 반복 작업을 측정하고 시간이 갈수록 반복 작업이 줄어들도록 노력하나요?

생각할 시간

대부분의 블로그 게시물은 행동을 요청하며 마무리됩니다. 이 게시물을 읽은 후 곧바로 변화를 모색하는 대신 시간을 들여 생각해보기를 바랍니다. 이 게시물과 같이 자기 주장이 강한 글에는 위험이 있습니다. 기준선은 성장과 개선이 아닌 구분을 위한 것입니다. 이 게시물은 SRE에 대한 접근을 제어하고 조건에 해당하지 않는 사람을 배제하기 위함이 아닙니다. 이는 무가치한 행동입니다. 하지만 어떤 측면에서 직종이 고안된 이유는 접근을 제어하기 위해서이기도 합니다. 어떤 조직이든 성공에 있어 업무 전문화와 분화는 매우 중요하며 이 때문에 선을 긋는 일을 피하기는 어렵습니다.

스스로 SRE라고 칭하고자 하는 사람이나 SRE라고 규정하는 것에 다른 사람들이 동의하지 않을지도 모른다고 우려하는 사람들에게 이 게시물은 존재론적 부담을 완화하는 역할을 할 수 있을 것입니다.