첫 On-call을 자축하며
개발자가 스웨덴으로 이직한 썰 11
소프트웨어 엔지니어가 새 팀에 안전하게 착륙했다고 볼 수 있는 지표가 몇 가지 있다.
처음으로 문의에 답변했다, 개발한 기능이 처음으로 배포되었다, 처음으로 버그나 장애를 만들었다, 처음으로 장애를 해결했다...
소프트웨어 개발은 무언가를 만드는 일이며 따라서 이 과정에서 고장내고 고치는 일이 불가피하다. 개발자는 사람이기 때문에 실수하며 모든 것을 한꺼번에 알 수 없으므로. 그러므로 새 시스템에 깊숙하게 관여하려면 이해하고-만들고-고장내고-고치는 사이클을 최소한 한 번은 돌아야 한다고 생각한다. 그중에 가장 어려운 것은 다른 사람이 만든 문제를 내가 처리하는 일일 것이다.
팀이 장애를 다루는 방식은 전 회사와 지금 회사가 상당히 다르다. 근무 시간이라면 큰 문제가 아니지만 근무 시간이 아닌 때에는 누군가 개인 시간을 써야 한다. 바로 누가 어떻게 자기 시간을 쓸 것인가에 대한 입장 차이다.
전에는 알림도 다 같이 받고 장애도 같이 처리하는 문화였다. 운이 나쁘게 또는 고맙게 상황을 가장 빨리 확인한 누군가가 앞장서서 일을 하면서 현상을 전파시키고 서로 도우면서 상황이 종료될 때까지 자리를 지켰다.
단순하게 보면 많은 사람의 개인 시간을 뺏는 효율적이지 못한 방식으로 생각할 수 있다. 하지만 똑같은 문제를 '혼자 해결한다'라고 상상해보면 여러 명이 함께이므로 가능한 순기능을 오히려 감사하게 생각하게 된다. 여럿의 지식이나 오랜 경험에서 오는 직감은 원인 파악을 앞당기고, 도움을 받을 수 있다는 안정감을 공유할 수 있기 때문이다.
하지만 이 구조는 어쩔 수 없이 당연히 업무시간 외 근무에 대한 문제를 낳는다. 개인 시간을 더 칼 같이 구분하는 환경에서는 보통 on-call이라고 부르는, 팀에서 업무 시간 외에 문제를 해결할 사람을 로테이션으로 지정하는 문화를 사용한다. on-call은 회사에서 내가 느끼는 큰 차이 중 하나다.
ON CALL 이란
Employees who work on-call are expected to be available at any time of day or night, usually with short notice, to carry out their working duties.
- Wikipedia On call shift
쉽게 말해서 전화를 받을 사람이다. 그 사람은 전화를 받으면 상황을 판단하고 가능하다면 해결해야 한다.
모니터링 알람과 다른 점
on-call이 모니터링 알람을 전부 처리하는 것은 아니다. 알람의 중요도에 따라 메신저, 메일, 전화 중 어떤 수단을 이용할지 결정하고 업무 시간이 아니더라도 꼭 개발자의 개입이 필요한 알람만 전화로 받는다. 메신저나 메일로 온 내용은 혹시 주말에 확인을 했더라도 출근해서 처리해도 괜찮다고 보는 것이 일반적인 입장이다.
PagerDuty pages me.
우리 회사는 PagerDuty라는 시스템을 사용한다.
예를 들어 내가 생산해야 하는 데이터가 최대 1시간 지연 SLO를 가지고 있다고 하자. PagerDuty에는 우리 팀의 on-call 스케줄이 들어있다. 모니터링 툴이 SLO가 깨졌음을 감지하면 PagerDuty에 중요도나 내용을 알려주고, PagerDuty가 정해진 방법으로 on-call 담당자를 'page'한다.
나는 여기 와서 배운 말인데 사람을 호출하거나 안내 방송을 하는 것을 'page'라고 표현한다. 그래서 모니터링 전화를 받았을 때 'I get paged.'라고 말하면 된다.
첫 on-call은 왜 축하의 대상인가
입사하고 PM과 첫 면담에서 받은 질문 중 하나는 '언제쯤 혼자 on-call을 할 수 있을 것 같아?'였다. 이 질문을 받았을 때 순간 나는 마음에 있는 답을 그대로 말해도 되는지, 아니면 더 방어적으로 기간을 늘려서 말해야 하는지 고민했다. 머뭇거림은 on-call이 혼자서 어느 정도 일을 처리해야 한다는 문제로부터 기인한다.
아직 모르는 것이 많지만
우리 팀의 서비스는 안정기에 접어들었기 때문에 장애는 생각보다 자주 발생하지 않고 코드 때문에 발생한 문제는 업무 시간에 대부분 해결된다.
오히려 가장 걱정한 부분은 커뮤니케이션이었다. 외부 문제인 것 같을 때 어디에 물어봐야 하고 우리 문제를 어디에 알려야 하나? 데이터는 회사의 여러 서비스를 거쳐서 우리 팀으로 도달하는데 그 엮여있는 체인 중에는 아직 내가 제대로 이해하지 못하는-누가 무슨 일을 하는지- 부분이 많다.
팀은 너무나 많고 이름으로 의미를 알 수 없는 경우가 많아 그들이 하는 업무는 무작정 마음으로 받아들여야 하고 심지어 업무<->팀을 매칭할 수 있는 방법도 없다. 이 회사의 선배들이 적재적소의 팀을 이리저리 찌르고 다니는 것은 신기할 지경이다.
일단 시작해보자
배려 깊은 동료들의 도움으로 몇 번의 on-call 연습을 할 수 있었다. 사실 제일 중요한 것은 다른 사람들이 어떻게 일하는지 보는 것이다. 문제를 해결하는 것은 경험으로 배우는 비중이 커서 A일 때는 B를 한다는 식으로 칼같이 정의하기 힘들 수도 있고 심지어 당사자는 자기도 모르게 무언가를 하고 있을 수도 있다. 자꾸 물어보면서 경험을 전해받아야 한다.
우선 다른 사람이 on-call 일 때 나도 똑같이 알람을 받도록 buddy가 되는 것부터 시작했다. on-call buddy는 인터뷰를 shadowing(이끌지 않고 지켜보는 일)하는 것과 비슷하다. 조용한 한 주였지만 on-call의 역할이 무엇인지 처음으로 직접 느꼈다. 전화를 제때 받는 것이 중요한 이유도 그중에 하나다. 전화를 받으면 문제를 인지했다고 ACK 할 수 있는데 정해진 시간 안에 ACK이 안되면 팀원 전체에게 전화가 간다고 한다.
이렇게 저렇게 많은 것을 배우며 입사하고 4개월 만에 처음으로 혼자 on-call을 맡았다! 다행인지 불행인지 큰 사건은 일어나지 않았지만 한 번을 잘 끝냈다는 것만으로도 뿌듯한 경험이 아닐 수 없다.
출처 https://xkcd.com/386/무엇을 배웠나
팀으로 일하는 것의 의미
내가 shadowing 하던 동료에게 '처음이라 부담스럽다'라고 했을 때 '혼자가 아니니까 걱정하지 말아라'라는 말을 들은 것이 고마웠던 기억이 있다. 그리고 그 이후로 우리가 일하는 것을 지켜본 바, 팀 사람들은 주말의 이른 아침이라도 가능하다면 기꺼이 도와준다. 임시로 코드를 수정해야 하는 경우 누군가는 +1을 준다.
on-call는 장애 상황을 '알리는 유일한 지점'인 것이지 장애를 '혼자서 처리하는' 사람이 아니므로 필요하다면 당당히 도움을 구해도 괜찮다. 내가 여태까지 만난 개발자들 중 그런 행동이 나쁘다고 말할 사람은 한 명도 없다고 생각한다. 우리 모두 비슷한 고민을 하고 도움을 받으며 성장해왔기에.
사실 질문에 열려있고 팀으로 일하는 것은 내가 개발자라는 직업을 생각할 때 가장 좋아하는 특징 중 하나다.
핸드폰은 항상 가까이에
핸드폰을 의식적으로 항상 가까이에 두는 것도 사소하지만 중요한 것 같다. 또 on-call일 때 (당연히) 술을 많이 마시지 않는 것은 암묵적인 룰이어서 회식을 하러 가더라도 누가 on-call인지 서로 체크를 한다.
나는 술보다 아침에 요가 수련을 할 때가 고민이었다. 핸드폰은 라커에 두고 오는 것이 수련할 때 약속이자 예의이기 때문에 핸드폰을 들고 샬라에 들어가는 것이 눈치가 보였으나... 이것도 내 직업의 일부니까 제대로 하지 않으면 요가원을 등록할 돈을 벌 수 없다는 생각으로(^^) 이 시기에는 최대한 벽 쪽에 붙어 핸드폰이 울리더라도 방해가 덜 가도록 하고 있다.
깨뜨리지 않으면 전부 볼 수 없다
내가 처음으로 우리 팀 데이터를 지연시킨 것은 막 on-call 예행연습을 하고 있을 즈음이었다. 그전까지 운이 좋았는지 딱히 문제라고 부를만한 일들은 만들지 않다가 공통 로직을 수정하면서 처음으로 파이프라인을 깨뜨렸다. 하필 그 부분이 우리끼리 테스트가 필요하다고 종종 말하던, 테스트가 없고 만들기 까다로운 부분이었다. 전에도 코드 실수는 한두 번이 아니었는데 나는 신입으로 돌아간 듯 어쩔 줄을 몰랐다.
동료 한 명과 앉아서 에러 로그, 배포와 커밋 로그를 따라 내려갔다. 그 날을 회상하면 내 커밋이 문제라고 전혀 생각하지 못했던 뻔뻔함부터 생각난다. 배포 전후 코드 변경을 확인하는 것은 기본 중에 기본인데 생각을 못한 것이 부끄러웠고, 내가 수정한 부분과 문제가 생긴 부분을 빨리 연결시켜 생각하지 못한 것도 부끄러웠다.
하지만 어쩔 수 없다, 망각이었다면 다시 기억하는 수밖에. 한 번의 망가뜨림으로 정말 많은 것을 순식간에 무의식에서 걷어올린 순간이었다.
20th December 2018
#개발자 #스웨덴 #해외취업
