On-calls

삼성과 아마존에서의 경험 그리고 구글, 넷플릭스 엔지니어와의 교류 경험을 바탕으로 대규모 서비스 운영을 위한 사이트 신뢰성 엔지니어링(SRE, Site Reliability Engineering)에 대한 강의를 했다. 오전에는 이론적인 내용 중심으로 전달했고, 오후 강의 때에는 사례 중심의 강의를 진행했다. 질의 응답을 통해 다른 회사들의 서비스 운영 사례를 나눴으며, 이미 공개되어 있는 내용들과 이 전 회사에서 겪었던 사례들을 섞어서 설명했다. 그 과정에서 다양한 질문들을 받았는데, 그 중 가장 기억에 남는 질문이 있었다. 대략적인 질문의 내용은 이러했다. "강의 내용을 보면 이미 알고 있는 내용들을 언급하고 있고, 런북(Runbook)을 만들어서 운영을 잘 하면 될 것 같다. 그런데 온콜(On-call) 담당자를 새로 뽑으려면 추가 비용이 들고, SRE 모니터링 시스템을 구축하기 위해서는 적지 않은 비용이 필요할 것 같다. SRE가 좋다고 하지만 도입과정에서 어려운 점들이 있을것 같은데". 라는 질문이었다. 이 질문이 뇌리에 남은 이유는 질문자가 강의 주제인 SRE에 대해 제대로 이해하지 못했다는 것을 보여주었기 때문이었다. 질문의 의도와 질문자의 오해에 대하여 다음과 같이 답변했다. 요약하자면, 1/ 온콜은 모든 직원에게 해당하는 책임이며^[각주:1], 아마존, 구글, 넷플릭스가 온콜을 하는 이유는 비용 때문이 아니라 온콜을 하지 않으면 (서비스)사업이 망하기 때문이다. 그리고 2/ 서비스 개발자들은 암묵적으로 온콜에 동의하며, 동의하지 못한다면 다른 팀/회사를 알아봐야 한다. 그리고 3/ 가장 중요한 것은 SRE와 같은 서비스 품질 관리 업무는 잘해야 본전인 경우가 많아서 의사결정권자의 강력한 지지가 필요하다는 것이었다.

온콜은 외주업체가 떠맡아야 하는 저임금 감정노동의 허드렛일이 아니다. 오히려 서비스 품질에 대한 자신감이다. 영화를 보다보면 파인 다이닝에서 음식에 감동받은 손님이 주방장을 불러내어 칭찬하는 장면을 볼 수 있다. 그리고 이러한 찬사는 주방장에게 영광이 된다. 반대로 음식에 문제가 있다면 손님은 항의할 것이다. 온콜도 비슷하다. 운영환경을 제대로 이해하지 못하고 아무렇게나 개발한 소프트웨어라면 계속해서 알람이 울릴 것이다. 반대로 운영 경험이 많은 개발자가 만들고 운영하는 서비스는 문제 없이 잘 동작할 것이고^[각주:2], 대부분의 문제는 예측 가능한 범위안에서 일어날 것이다. 다시 말하면, 온콜은 개발팀이 손님의 피드백을 간접적으로 듣는 행위에 가까우며, 소프트웨어를 잘 만들게 만드는 원동력이다. 온콜을 부담스러운 잡일이라고 생각하는 개발팀과 온콜이 고객에게 서비스를 선보이는 자신감과 자부심의 표현이라고 생각하는 개발팀이 운영하는 서비스 중에서 소비자로서 어떤 선택을 할 지 추측하는 것은 어렵지 않다. 당연히 서비스에 대해 자신감과 자부심을 가진 팀의 서비스를 고를 것이기 때문이다.

---

 

1. 직원 연락처에 온콜 버튼이 있다 [본문으로]
2. 서비스는 잘 동작하는데 코드가 투박해 보이는 경우도 있다. 지식 수준이 낮아서 그렇다고 오해할 수도 있겠지만, 사실은 오랜경험을 바탕으로 누구나 쉽게 예측 가능하도록 실용적으로 설계했기 때문이다. 단순하지만 명확하게 동작하도록 설계하는 것은 서비스 운영의 본질과 목적을 제대로 이해한 사람이 할 수 있는 선택이라고 생각한다. 물론, 때로는, 아름답게 추상화되어있으면서도 깔끔하게 동작하는 코드를 발견하게 되는 때가 있다. [본문으로]