자동화는 구글러에게만 해당되는 이야기가 아니다
Site Reliability Engineering (2016)
구글에서 시행하는 대부분의 자동화는 문제가 많다. 그 이유는 자동화가 핵심 시스템과는 별개로 유지보수되므로, 일종의 불일치, 즉 기반 시스템이 변경되었음에도 불구하고 자동화 시스템은 그에 따라 변경되지 않음으로써 발생하는 문제로 골머리를 앓기 십상이기 때문이다.
그 의도가 무엇이든 간에, 두 시스템의 결합도가 강할수록 우선순위가 애매해지고, 그에 따라 제품 개발자가 모든 변경사항에 대해 필요한 배포 요구사항을 테스트하는 데 거부감을 갖게 되어 결국 더 빈번한 실패를 경험하게 된다.
게다가 자동화는 그 중요성에 비해 어쩌다가 한 번 실행되므로 테스트가 어렵고 피드백을 받는 주기가 늘어져서 문제가 더 빈번하게 발생할 가능성이 크다.
그래서 자동화의 혁신은 다음과 같은 단계를 밟는다.
1. 자동화를 하지 않는 단계
- 작업자가 수동 작업을 실행한다(자동화 없음).
2. 별도로 관리되며 시스템에 특화된 자동화를 수행하는 단계
- 작업자가 시스템에 맞게 작성한 자동화를 실행한다.
3. 별도로 관리되는 범용 자동화를 수행하는 단계
- 외부에서 관리하는 범용 자동화를 실행한다.
4. 내재화되었지만 시스템에 특화된 자동화를 수행하는 단계
- 내부에서 시스템에 맞게 작성한 자동화(스크립트)를 실행한다.
5. 자동화가 불필요한 시스템을 도입하는 단계
- 사람의 개입이 필요하지 않은 자동화된 시스템을 구축한다.
물론 효과적인 장애 대응을 위해서는, 전체 시스템을 관리하는 사람도 시스템의 자기 분석에 사용되는 내부 동작의 상세정보에 접근할 수 있어야 한다. 비컴퓨터 분야(예를 들면 항공사나 산업용 애플리케이션)에서의 자동화 논의들은 종종 고효율적 자동화의 단점에 대해 지적하고는 한다. 시간이 흐르면서 자동화가 더 많은 부분을 담당함에 따라, 운영자들이 점차 긴장을 늦추게 된다는 것이다. 그러면 여지없이 자동화 프로세스가 실패했을 때 운영자들이 시스템을 성공적으로 운영하지 못하게 된다.
운영자들이 제대로 대응하지 못하는 이유는 실전 경험의 부족과 더불어, 그들이 생각하는 시스템의 동작이 실제 시스템의 동작과 일치하지 않기 때문이다. 이런 상황은 시스템의 자율성이 비교적 떨어지는 경우에 더 자주 발생한다. 즉, 자동화가 수동 작업을 대체하고, 수동 작업은 언제나 그랬듯이 항상 수행이 가능할 것이라는 것을 전제하는 상황에서 발생한다는 뜻이다. (중략)
우리 역시 자동화 때문에 여러 고초를 겪었지만, 구글의 경험상, 자동화나 자율적 동작을 필요로 하는 시스템은 계속해서 늘어나고 있다. 규모가 커지는 것 역시 마찬가지 경우이긴 하지만, 규모에 관계 없이 시스템에 자율성을 추가하는 것에 대해서는 여전히 논란이 있다. 신뢰성이란 근본적인 기능으로, 자율적이면서 탄력적으로 구현되었을 때 그 빛을 발한다.
설명한 여러 예시들을 읽고 자동화든 뭐든 하려면 먼저 구글 정도의 규모가 되어야 한다고 생각할지도 모르겠다. 하지만 그런 생각은 다음 이유 때문에 옳다고 볼 수 없다.
자동화는 시간을 절약하는 것 이상의 가치를 제공하므로, 단순히 자동화에 투입하는 시간과 그로 인해 절약되는 시간을 비교하는 것만으로는 판단하지 않았으면 한다. 가장 큰 영향은 사실 디자인 단계에서 나타난다. 신속하게 제품을 출시하고 또 개선하는 과정을 반복하다 보면, 아직은 탄력적인 시스템을 구현하지는 못했을지라도 기능을 더 빠르게 구현할 수 있다.
대형 시스템의 자율적 동작을 적절한 형태로 개선하는 것은 어렵지만, 소프트웨어 엔지니어링에서 통상적으로 강조하는 원리들, 예를 들면 서브시스템의 결합도를 낮춘다든가, API를 추가한다거나, 부작용을 최소화하는 것 등은 큰 도움이 된다.
- Niall Murphy, John Looney, Michael Kacirek 작성, 장현희 번역
