SRE(Site Reliability Engineering) 이라고 부르는게 요새 자주 들린다. 모든 내용을 다 아는건 아니지만, 이것저것 살펴보고 난 후 웃음이 났다. 그동안 내가 바라보는 관점이 그대로 같았기 때문이다. 나는 오래전부터 인프라 시스템, 좁게는 리눅스를 개발자 관점에서 다룰 수 있어야 한다고 생각해왔다.

나는 오랫동안 인프라 분야에 몸 담았다. 이렇게 말을 하면 대부분 서버, WAS 등을 다루는 것으로 생각할지 모른다. 실제로 내가 지원하는 분야는 TA 인데, 각 프로젝트마다 다르지만 그래도 TA 하면 인프라적인 요소를 많이 생각한다.

하지만 나는 적어도 인프라를 그야말로 전통적인 운영(Traditional Organizations) 을 지향하지 않았다. 대학교때에는 리눅스(Linux) 에 미쳐살았지만 그것을 벗어나 PHP 웹 개발하면서 취업도 개발자로 했다. 그러던 것이 인프라 팀으로 적을 옮겼는데, 정확하게는 인프라 개발팀이였다. Python 을 그때 배웠다. 그리고 인프라 백엔드 개발과 서버운영을 같이하는 일을 하게되면서 자연스럽게 OSS 와 인프라 개발을 위한 각가지 프로그래밍을 익혔다.

SRE 을 한국에 적용한다면 “인프라 개발팀” 이 가장 현실적이다. SRE 의 정의는 대략 다음과 같다.

https://newrelic.com/sites/default/files/2021-08/site-reliability-engineering-handbook.pdf

Google defines an SRE as an operationally minded software engineer, but what does that mean? At Google, SRE teams are responsible for both capacity planning and provisioning. The teams are different from purely operational teams in that they seek software engineering solutions to problems.

소프트웨어 엔지니어 마인드로 운영을 다룬다는 것인데, 오래전부터 개발자 관점에서 인프라 시스템을 바라보고 다루어야 한다고 생각했었다.

문제는 현실이 그렇지 않다는 것이다. 더군다나 프리랜서 직업에서 프로젝트에 투입되보면 대부분 OS, WAS, 최근에는 Cloud 까지 구축과 운영을 하는 경우가 많았다. 이런 경우에 소프트웨어 엔지니어, 더나가 개발자적 시각으로 일을 할만큼 여건이 되지 않았다. 그리고 그런걸 원하지도 않았다. 전통적인 운영과 구축이였다.

한국의 상황이 안타까움이 있다. TA 직군에서 계약을하고 프로젝트를 하게되면 기술적인 부분에 있어서 그런대로 최근의 트랜드를 따라가긴 한다. 자동화, IaC, 데이터 분석등이 그런 것이다. 문제는 기술적인 부분만 강조할 뿐, 이것을 기반으로 SRE 까지는 가지 못한다는데 있다.

TA 들도 문제다. TA 들은 전통적인 구축, 운영에 적어 있다. 이들에게 Python 정도는 할 줄 알아야 하지 않느냐는 질문에 “그걸 왜 우리가 알아야 하냐?” 식의 답변이 대부분이다. OS 를 명령어를 통해서 세팅하고, WAS 서버를 세팅하고 로그 분석하고 JVM 설정과 덤프 분석등이 그들이 하는 일이라고 생각한다. 그러다보니 Python 은 고사하고 Cloud 에서 많이 쓰이는 Terraform 과 같은 툴을 익히는데 게을리 한다. 어떤 문제가 발생하면 서버에 직접 접속해서 봐야 속이 시원하고 JVM 덤프를 떠서 분석을 해야지만 뭔가 일을 제대로 하는 것마냥 생각한다.

이제 TA 도 소프트웨어 엔지니어를 넘어서 개발자가 되어야 한다. 진정으로 개발을 하는 건 아니지만 적어도 자신이 자신있게 하나 정도의 언어는 능숙하게 다룰 수 있어야 한다.

구글의 SRE 는 팀의 Role 이다. 정확하게는 운영에 대한 Role. 그래서 작금의 TA 직업군에게 적용되어지는 대상이다.

https://newrelic.com/sites/default/files/2021-08/site-reliability-engineering-handbook.pdf

To enforce this, Google caps the amount of time SREs spend on purely operational work at 50%. This means that, at a minimum, 50% of a Google SRE’s time should be allocated to engineering tasks, such as automation and improvements to the service.

문제는 편견과 돈…

지금까지 TA 경력으로 일해오면서 한 마디 했다가 바보 된 경우가 있었다.

100% 장애 안나는 시스템은 없습니다. 대충 해봐도 90%정도 가동률을 보이면 진짜 잘한 겁니다. 장애 안나게 어떻게 시스템을 만듭니까?

특히나 금융 프로젝트에 투입된 상황에서 저런말을 하면 십중팔구 고객으로부터 짐 쌓라는 말을 들을 수 있다. 공공 프로젝트는 더 하지 않나? 100% 장애 안나는 시스템을 구축해야 하는거지, 금융 시스템 운영하다가 장애 날껄 생각하면서 구축하냐?

하지만 SRE 는 100% 장애를 커버하지 않는다. 이것도 나의 생각과 동일 했었는데, 장애 발생하더라도 서비스에 영향이 없다면 어떨까? 장애라는 것이 특정 서버가 다운되거나 네트워크 장비가 이상이 생길 수 있다. 이런 상황에서도 고객 서비스에 아무런 영향을 주지 못했다면 그 시스템은 신뢰성이 높다고 할 수 있지 않을까? 신뢰성(Reliability) 라는 말이 가지는 함의가 이와 같다고 생각한다.

돈.. 기업은 항상 돈을 먼저 생각한다. 기업이 힘들면 IT 부서가 먼저 짤린다는 슬픈 이야기는 더 이상 슬픈 이야기도 아니다. 100% 장애가 나지 않도록 해야지만 고객에 대한 보상도 없을 것이니 장애 발생이 가능할 수도 있다는 말을 꺼내는 순간 돈이 나갈 수 있다는 생각을 먼저 하게 된다. 장애가 나면 그것을 분석하고 장애를 예방하기 위한 일련의 활동이 필요한데, 그렇게 되면 전문가가 항시 있어야 한다. 언제 생길지도 모르는 장애 때문에 전문가를 고용한다는 건 기업에서는 있을 수 없는 일이다.

구축 프로젝트가 끝나면 대부분의 인력이 철수를 한다. 운영으로 넘어가게 되면 안타갑게도 인프라 관련 전문 인력은 뽑지도 않는다. 인프라 담당자를 뽑아 놨다고 하지만 그냥 용어만 잘 알고 있을뿐 실무적인 익숙함도 없는 사람들인 경우가 많다. 어짜피 구축된 시스템은 100% 장애가 발생하지 않도록 구축되었다는 신념이 있기 때문에 운영은 그냥 모니터링 요원정도로만 생각하는 것이다.