당시에는 테스트, 배포, 인프라를 자동화하기 위한 툴의 수도 지금처럼 많지 않았으므로 코드 완성부터 프로덕션 단계에 이르기까지 난관이 많았다. 운영 데이터와 모니터링 툴, 지원 워크플로우가 쉽게 통합되지 않았기 때문에 프로덕션 인프라와 애플리케이션을 모니터링하고 프로덕션 문제의 근본 원인을 찾기 위해서는 기술과 상황 대처 능력, 두 가지 모두 필요했다.
많은 측면에서 지금의 애플리케이션 개발, 테스트, 지원은 예전에 비해 쉬워졌지만 용어와 역할 정의, 실무적 책임을 해석하고 적용하기는 훨씬 더 어려워졌다. 사이트 신뢰성 엔지니어링이 속한 영역은 데브옵스인가, 보완적 서비스인가? CI/CD(지속적 통합/지속적 제공) 파이프라인과 코드형 인프라를 책임지는 사람은 누구인가? 프로덕션 사고가 발생하는 경우 문제를 해결하고 근본 원인을 찾고 최적의 교정안을 구현하기 위한 가장 효율적인 프로세스는 무엇인가?
구글의 문화와 방식, 모든 조직에 맞는 건 아니다
앞서 질문에 대한 보편적인 모범 답안은 없다. 조직의 크기, 규모와 복잡성은 제각기 다르기 때문이다. 10여 명의 엔지니어가 있는 신생 기업에서 통하는 방법과 규제를 받는 업계에서 활동하는 다국적 기업에 적용되는 방법은 다르다. 마찬가지로, 구글, 넷플릭스, 마이크로소프트와 같은 대형 IT 업체에서 효과적인 문화와 관행, 기술이 레거시 시스템과 기술 부채가 많은 다른 산업이나 기업 관점에서는 그림의 떡인 경우가 많다.
그래서 일반적인 이해에 도달하기 위해서는 다음과 같은 5가지 관점에 대한 용어의 정의가 필요하다.
- 조직이 지원하는 미션, 문화, 협업, 사고방식
- 비즈니스 목표, 고객 정의, 가치 제안, 성공 KPI(주요 성과 지표)
- 애플리케이션 개발, 테스트, 배포, 모니터링을 위한 기술적 작업
- 애플리케이션을 계획. 제공, 지원하기 위해 팀에서 사용하는 워크플로우와 실행 방안
- 이 작업을 성공적으로 수행하기 위해 필요한 툴과 자동화
보기에는 간단하지만 실제 환경에서 조직의 운영 방식은 매우 복잡하고 실행 방안 간의 경계도 뚜렷하지 않다. 예를 들어 필자는 애자일 방법론을 워크플로우 실행 방안으로 정의하지만 조직에서 애자일 실행 방안을 어떻게 정의하는지는 비즈니스 목표와 기술 아키텍처, 소프트웨어 개발 라이프사이클, 현행 데브옵스 자동화 방법에 따라 달라진다.
데브옵스의 실행/문화와 사이트 신뢰성 엔지니어의 업무/책임 간의 교차점 역시 마찬가지다. 데브옵스와 SRE(Site Reliability Engineering)에 있어서는 의견이 매우 다양하다. 이 가운데 몇 가지 예를 들면 다음과 같다.
- 구글은 조직 사일로 감소, 실패를 정상으로 받아들이기, 점진적 변화 구현, 툴과 자동화 활용, 모든 것 측정하기를 비롯한 여러 가지 데브옵스 목표를 정의한다. 또한 구글은 포괄적인 헌장을 두는 “만물의 SRE” 모델부터 개발 팀을 위한 컨설턴트 역할을 하면서 코드 수정에는 거의 관여하지 않는 모델에 이르기까지 여러 SRE 운영 모델을 제안한다.
- 컴퓨팅 기기 협회(The Association for Computing Machinery)는 SRE 역할에 대해 운영에 더 초점을 두는 헌장을 규정하고 모니터링, 지표, 응급 대응, 용량 계획, 서비스 관리, 변경 관리, 성능을 SRE의 핵심적인 기능으로 본다.
- 데브옵스와 SRE의 차이점을 설명하는 또 다른 기사에서는 “데브옵스가 일반적으로 무엇에 초점을 두는 반면 SRE는 “어떻게”에 초점을 둔다고 하는데, 필자도 그 말에 동의한다. 기사는 또한 “SRE는 대규모 애플리케이션을 관리하고자 하는 기업과 조직에 적합하다”고 조언한다.
필자는 SRE가 주로 대규모 조직에 적합하다는 의견에는 동의하지 않으며, 맞춤형 애플리케이션, 데이터 통합, 데이터 과학 실험, 머신러닝 모델을 구축하고 지원하는 모든 조직에는 규모와 관계없이 개발 책임을 보완하기 위해 SRE가 필요하다고 생각한다. SRE의 7가지 책임에는 서비스 수준 목표에 따른 관리, 수작업 최소화, 개발자와의 소유권 공유 등이 포함된다. 규모와 상관없이 어느 조직이든 이러한 책임을 소유하고 처리해야 하기는 마찬가지다.
시스템 관리에서 사이트 신뢰성으로 초점 이동
‘드라이빙 디지털(Driving Digital)’에서 필자는 SRE 역할을 “애자일 운영(agile operations)”으로 기술했다. 이 책에서 필자는 “이상적으로, 개발자는 사용자와 함께 새로운 기능을 개발하는 데 시간의 70~80%를 소비하고 지원에는 20~30%만 소비해야 한다”는, 지나치게 단순화되고 비현실적이기도 한 목표를 언급했다. 지원은 CI/CD 파이프라인 자동화부터 코드형 인프라 구현과 애플리케이션 모니터링 자동화에 이르기까지 비기능적인 모든 부분을 포괄한다.
이런 기능은 필수적이긴 하지만 어디까지나 개발의 효율성, 일관성, 신뢰성을 확보하기 위한 비계 작업일 뿐이다. 자동화에는 코딩이 필요하지만 필자라면 이를 구현하기 위한 젠킨스(Jenkins), 서클CI(CircleCI), 애저 데브옵스(Azure DevOps), 퍼펫(Puppet), 셰프(Chef), 앤서블(Ansible)을 비롯한 다양한 데브옵스 플랫폼에 숙련된 엔지니어가 있는 편을 더 선호할 것이다.
그러나 개발, 테스트, 프로덕션에서 안정적이고 성능이 우수하고 확장 가능하고 안전한 애플리케이션을 보장하는 것 역시 중대한 책임이다. 이 작업이 갈수록 작업 과정의 앞쪽으로 이동하면서 개발 및 테스트 단계에서 이러한 부분을 파악해 처리하는 경우가 늘고 있다. 안정성 보장은 팀 전체의 책임이지만 필자라면 팀원 일부가 방법과 툴을 익혀 구현을 책임지는 편을 더 선호할 것이다.
10년 전의 업계에서는 이 책임을 시스템 관리 또는 시스템 엔지니어링으로 지칭했다. 지금은 클라우드 인프라, 툴 프로비저닝, 자동화를 통해 더 효율적인 인프라 패턴이 실현되고 시스템 작업이 줄어들었다. 마찬가지로, 변경 관리와 같은 자동화 및 통제 수단 덕분에 수작업 일부가 줄어들면서 관리 작업도 대폭 줄었다.
애플리케이션 신뢰성을 위해 개발자와 SRE의 협업 필요
과거 “시스템 관리” 또는 “시스템 엔지니어링”으로 불렸던 책임을 지금 관점에서 더 적절한 표현하면 “사이트 신뢰성 엔지니어링”이다. 이 역할을 맡는 사람은 인프라부터 최종 사용자 경험에 이르기까지의 성능을 두루 파악해야 한다. 이들은 사고가 발생할 때 최전선 방어를 담당하며, 근본 원인을 찾아 문제를 교정하기 위한 리더십과 기술적 책임감도 갖춰야 한다.이런 부분은 SRE의 사후 대응 책임에 속하지만 사전 대응에 해당하는 중요한 기술과 작업도 많다. 이러한 책임과 툴의 형태는 애플리케이션의 속성에 따라 다르다. 침투 테스트 자동화, 코드 리뷰, 성능 테스트, 성능과 신뢰성 또는 확장성에 영향을 미치는 비기능적 기술 부채가 있는 코드의 리팩터링 등이 포함될 수 있다.
개발자 협업의 시작은 SRE 역할, 그리고 개발 책임이 끝나고 SRE 책임이 시작되는 경계를 이해하는 것이다. 또한 이 점을 이해한다 해도 대부분의 조직에서 SRE의 수는 개발자에 비해 훨씬 적으므로 SRE가 어디에 위치하고 누구에게 보고하며 애자일 팀에 속하는지 또는 외부 서비스 공급자로 활동하는지 여부에 관계없이 협업은 필요하다. SRE는 개발자와 동일한 툴과 개발 실천 방안을 사용해야 하지만 이들에게 할당되는 작업과 개발자에 의해 구현되는 패턴이나 모범사례는 많은 측면에서 다르다.
이것이 왜 중요한가? 최종 사용자와 고객에게 영향을 미치는 사고와 끊임없이 맞서 싸우는 일은 아무도 원하지 않기 때문이다. editor@itworld.co.kr
함께 보면 좋은 콘텐츠
Sponsored
Surfshark
“유료 VPN, 분명한 가치 있다” VPN 선택 가이드
ⓒ Surfshark VPN(가상 사설 네트워크, Virtual Private Network)은 인터넷 사용자에게 개인 정보 보호와 보안을 제공하는 중요한 도구로 널리 인정받고 있다. VPN은 공공 와이파이 환경에서도 데이터를 안전하게 전송할 수 있고, 개인 정보를 보호하는 데 도움을 준다. VPN 서비스의 수요가 증가하는 것도 같은 이유에서다. 동시에 유료와 무료 중 어떤 VPN을 선택해야 할지 많은 관심을 가지고 살펴보는 사용자가 많다. 가장 먼저 사용자의 관심을 끄는 것은 별도의 예산 부담이 없는 무료 VPN이지만, 그만큼의 한계도 있다. 무료 VPN, 정말 괜찮을까? 무료 VPN 서비스는 편리하고 경제적 부담도 없지만 고려할 점이 아예 없는 것은 아니다. 보안 우려 대부분의 무료 VPN 서비스는 유료 서비스에 비해 보안 수준이 낮을 수 있다. 일부 무료 VPN은 사용자 데이터를 수집해 광고주나 서드파티 업체에 판매하는 경우도 있다. 이러한 상황에서 개인 정보가 유출될 우려가 있다. 속도와 대역폭 제한 무료 VPN 서비스는 종종 속도와 대역폭에 제한을 생긴다. 따라서 사용자는 느린 인터넷 속도를 경험할 수 있으며, 높은 대역폭이 필요한 작업을 수행하는 데 제약을 받을 수 있다. 서비스 제한 무료 VPN 서비스는 종종 서버 위치가 적거나 특정 서비스 또는 웹사이트에 액세스하지 못하는 경우가 생긴다. 또한 사용자 수가 늘어나 서버 부하가 증가하면 서비스의 안정성이 저하될 수 있다. 광고 및 추적 위험 일부 무료 VPN은 광고를 삽입하거나 사용자의 온라인 활동을 추적하여 광고주에게 판매할 수 있다. 이 경우 사용자가 광고를 보아야 하거나 개인 정보를 노출해야 할 수도 있다. 제한된 기능 무료 VPN은 유료 버전에 비해 기능이 제한될 수 있다. 예를 들어, 특정 프로토콜이나 고급 보안 기능을 지원하지 않는 경우가 그렇다. 유료 VPN의 필요성 최근 유행하는 로맨스 스캠은 인터넷 사기의 일종으로, 온라인 데이트나 소셜 미디어를 통해 가짜 프로필을 만들어 상대를 속이는 행위다. 이러한 상황에서 VPN은 사용자가 안전한 연결을 유지하고 사기 행위를 방지하는 데 도움이 된다. VPN을 통해 사용자는 상대방의 신원을 확인하고 의심스러운 활동을 감지할 수 있다. 서프샤크 VPN은 구독 요금제 가입 후 7일간의 무료 체험을 제공하고 있다. ⓒ Surfshark 그 외에도 유료 VPN만의 강점을 적극 이용해야 하는 이유는 다음 3가지로 요약할 수 있다. 보안 강화 해외 여행객이 증가함에 따라 공공 와이파이를 사용하는 경우가 늘어나고 있다. 그러나 공공 와이파이는 보안이 취약해 개인 정보를 노출할 위험이 있다. 따라서 VPN을 사용하여 데이터를 암호화하고 개인 정보를 보호하는 것이 중요하다. 서프샤크 VPN은 사용자의 개인 정보를 안전하게 유지하고 해킹을 방지하는 데 유용하다. 개인정보 보호 인터넷 사용자의 검색 기록과 콘텐츠 소비 패턴은 플랫폼에 의해 추적될 수 있다. VPN을 사용하면 사용자의 IP 주소와 로그를 숨길 수 있으며, 개인 정보를 보호할 수 있다. 또한 VPN은 사용자의 위치를 숨기고 인터넷 활동을 익명으로 유지하는 데 도움이 된다. 지역 제한 해제 해외 여행 중에도 한국에서 송금이 필요한 경우가 생길 수 있다. 그러나 IP가 해외 주소이므로 은행 앱에 접근하는 것이 제한될 수 있다. VPN을 사용하면 지역 제한을 해제해 해외에서도 한국 인터넷 서비스를 이용할 수 있다. 따라서 해외에서도 안전하고 편리하게 인터넷을 이용할 수 있다. 빠르고 안전한 유료 VPN, 서프샤크 VPN ⓒ Surfshark 뛰어난 보안 서프샤크 VPN은 강력한 암호화 기술을 사용하여 사용자의 인터넷 연결을 안전하게 보호한다. 이는 사용자의 개인 정보와 데이터를 보호하고 외부 공격으로부터 사용자를 보호하는 데 도움이 된다. 다양한 서버 위치 서프샤크 VPN은 전 세계 곳곳에 여러 서버가 위치하고 있어, 사용자가 지역 제한된 콘텐츠에 액세스할 수 있다. 해외에서도 로컬 콘텐츠에 손쉽게 접근할 수 있음은 물론이다. 속도와 대역폭 서프샤크 VPN은 빠른 속도와 무제한 대역폭을 제공하여 사용자가 원활한 인터넷 경험을 누릴 수 있도록 지원한다. 온라인 게임, 스트리밍, 다운로드 등 대역폭이 필요한 활동에 이상적이다. 다양한 플랫폼 지원 서프샤크 VPN은 다양한 플랫폼 및 디바이스에서 사용할 수 있다. 윈도우, 맥OS, iOS, 안드로이드 등 다양한 운영체제 및 디바이스에서 호환되어 사용자가 어디서나 안전한 인터넷을 즐길 수 있다. 디바이스 무제한 연결 서프샤크 VPN은 무제한 연결을 제공하여 사용자가 필요할 때 언제든지 디바이스의 갯수에 상관없이 VPN을 사용할 수 있다.