Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

1년 반 정도의 원격 근무 경험

Automattic을 포함해서(바지 벗고 일하면 안 되나요? 참고) GitHub 등 많은 해외의 많은 회사가 언젠가부터 원격근무를 중심으로 일하면서 어느새 나한테도 원격근무로 일하는 건 하나의 목표가 되었다. 오픈소스를 보면서 개발자가 원격으로 일하면서도 좋은 소프트웨어를 만드는 것은 많이 보았고 원격근무를 중심으로 일하는 회사들이 많이 생겨났기 때문에 가능하다는 것은 알고 있었다. 하지만 해본 적은 없었으므로 상상만 했지 현실적인 부분은 잘 몰랐다.

그러다가 지난 회사에서 1년 반 정도 원격근무를 병행해서(100% 원격은 아니니까) 일했고 그 경험을 정리해 보려고 한다. 원격근무를 해보고 나니 더욱 원격근무의 지지자가 되었다. 앞으로 원격근무를 더 많이 할 기회가 생기면(그러기를 기대한다) 원격근무에 대한 생각이 어떻게 발전할지 모르지만, 지금의 생각을 정리해 보기로 했다.

이해를 돕기 위해 설명하자면 내가 있었던 조직은 100% 원격으로 근무한 것은 아니고 사무실에 내 자리가 있지만 필요할 때는 공유하고 원격근무를 하고 얼굴을 보고 일해야 할 일이 있거나 하면 사무실로 나가기도 하는 등 원격근무와 자율출근이 섞인 형태로 일했다. 사무실에 나가는 것도 원격 근무의 일부라고 생각하기에 나는 그냥 원격근무라고 부르고 싶다.

원격 근무? 재택 근무?

사람마다 용어를 다르게 쓰는데 나는 "원격 근무"라는 용어를 더 선호하는 편이다. 핵심은 물리적인 공간에 모이지 않은 상태로 일을 한다는 것인데 재택근무는 "집에서 일한다"라는 느낌이 너무 강해서 핵심이 전달 안 되는 느낌이다. 원격 근무를 하면 같이 일하는 사람이 한 곳에 있지 않을 뿐 집에 있든지 카페에 있든지 어떤 코워킹 스페이스에 있든지 상관없다. 심지어 사무실에 있을 수도 있다.

원격 근무는 복지일까? 아닐까?

전에 같이 일하던 동료들하고도 이런 얘기를 여러 번 나누었는데 나는 복지라고 생각하는 편이다. 내가 HR은 아니라 정확한 복지의 의미를 생각해 본 적이 없어서 제대로 정의할 수 있는지도 모르겠지만 내가 생각하는 회사의 복지는 "직원이 업무에 더 집중하고 잘할 수 있게 회사가 제공하는 것"이다. 예를 들면 대출이나 보험 같은 건 개인 일 때문에 업무에 지장이 생기는 것을 줄여주는 것이고 식대 지원이나 리프레시 휴가 같은 건 만족도나 행복감을 높여주어서 직원들이 더 일을 잘 할 수 있게 하는 것이다.

이런 맥락에서 원격 근무는 복지다. 전에는 너무 당연하다고 생각해서 깨닫지 못했지만, 원격 근무를 하고 나서 내가 불필요한 일에 스트레스를 많이 받고 있었다는 것을 깨달았다.

예를 들어 아침에 일어났는데 눈이 너무 많이 왔거나 비가 너무 많이 오면 그냥 원격근무를 했다. 길 가면서 넘어질까 조심하거나 옷 다 젖으면서 사무실에 가느니 그냥 집에서 일하거나 동네 카페에서 일하는 게 훨씬 편했기 때문이다. 아니면 잠시 병원을 가야 하거나 개인적인 볼일로 어디 들려야 할 때는 예전 같으면 반차나 휴가를 써야 했기에 내가 언제 휴가를 쓸 수 있고 이런 일 때문에 내 휴가 쓰는 것도 신경 쓰이니까 다른 일정과 맞추기도 하고 여러 가지로 신경 써야 했는데 원격근무를 할 때는 그냥 일하다가 얘기하고 갔다 오거나 좀 늦게부터 일한다고 공유하면 그만이었다. 이 볼일이 먼 곳에 있어도 크게 신경 쓸 것 없이 그냥 볼일 보고 그 근처 카페 같은 곳에서 일하면 끝이었다. 사소하게는 업무 중에 집중이 안 되거나 너무 졸리거나 하면 얘기하고(중요하다!) 좀 쉬거나 잠시 눈 붙인 후에 다시 집중해서 일하면 그만이었다.

심지어 나는 왜 모든 회사가 9~10시 사이에 모두가 사무실로 나오도록 해서 생기는 이득이 무엇인지 의문이 들었다. 난 출퇴근 거리가 가까운데도 출퇴근 안 하는 것만으로도 스트레스가 크게 줄어서 출퇴근이 먼 사람의 이득은 훨씬 클 거로 생각한다. 내가 가장 회의감을 느낄 때가 아침에 출근하는데 배가 아파서 지하철을 내렸다 가면 시간 내에 갈 수 있을지 아니면 사무실까지 참을 수 있을지를 고민할 때이다.

사소한 출퇴근 문제부터 개인 볼일까지 원격 근무를 하니까 회사 출퇴근과 충돌해서 신경 써야 하는 많은 일에 대한 스트레스가 거의 사라지면서 업무 강도가 높더라고 내 만족도는 크게 높아졌다. 앞으로는 연봉이 더 낮아도 원격 근무가 가능하다면 충분히 고려할만한 정도가 되었다.

결국, 회사는 직원들이 더 일을 잘 할 수 있게 여러 가지 복지를 제공하는 것인데 국내의 수많은 회사가 왜 원격 근무에 대한 고민이나 실험은 하지 않는지 궁금할 뿐이다. 다른 복지에 비교해서 돈이 많이 드는 일도 아닌데... 노파심에 말하자면 복지도 회사마다 다르듯이 원격 근무가 모든 조직이나 업무형태에 다 좋다고 얘기하는 것은 아니다.

죄책감

원격 근무를 오래 꿈꿔왔음에도 처음 원격근무를 했을 때 내가 당황했던 것은 죄책감(?)이었다. 사무실로 출근해도 때로는 팀원들과 수다를 떨기도 하고 중간에 좀 휴식을 취하기도 하고 어느 날은 너무 집중이 안 돼서 어영부영 보내기도 한다. 아니면 올림픽이나 사회적 큰 이슈가 있으면 방송이나 글을 틈틈이 보기도 한다. 회사 경영자 처지에서는 온종일 일만 열심히 하기를 바랄지도 모르겠지만 사람이 개인 일도 있고 기분의 기복도 있는데 어떻게 그렇게 되겠는가? 아무튼, 회사에 출근해서 오늘 일을 제대로 못 했다고 하더라도 일정에 큰 문제가 있지 않으면 퇴근 시간이 되면 퇴근을 하게 된다. 혹은 퇴근은 못 했다고 하더라도 퇴근 시간이 지난 후에 야근한다는 개념으로 일을 하게 된다.

사무실에 앉아있다고 하더라도 누가 내 모니터를 감시하거나 내가 얼마나 일하고 있는지 시간별로 다 보고 있는 것은 아님에도 막상 카페에 혼자 앉아 있으니 죄책감(?)이 꽤 컸다. 이건 성격에 따라 다를 수도 있긴 한데 아마 이 죄책감은 다른 사람들이 내가 얼마나 일한다고 생각할까 하는 것에 대한 불안감이라고 생각한다.

개발 같은 경우 3~4시간 열심히 개발했지만, 완성이 안 되거나 처음에 생각을 잘못해서 했던 작업을 다 버리고 새로 하는 일도 꽤 많이 있다. 사무실에서는 이런 일들이 그냥 다시 해야 해서 짜증 나는 정도의 일이었는데 카페에서 채팅도 안 하고 3~4시간 작업하다가 이런 상황을 만나면 엄청 당황하게 되었다. 왜냐하면, 다른 사람으로서는 내가 3~4시간 열심히 일했는지 침대에 누워서 잤는지 알 수 없는 일이기 때문이었다. 그래서 초반에는 이런 상황에 빨리 간단한 일을 찾아서 커밋을 올리면서 내가 일하고 있음을 알리거나 괜히 채팅에 3~4시간 일했던 게 날아갔음을 투정 부리면서 "나 놀지 않았어요"를 최대한 어필하려고 노력했다.

내 경우에는 이런 죄책감이 완전히 사라지는데 한 6개월 정도가 걸렸던 것 같다. 사람에 따라 처음부터 괜찮은 사람도 있는 것 같은데 나는 최소한 그랬다. 생각해 보면 이 죄책감은 이상한 게 사무실에 있다고 하더라도 옆 사람이 어떤 작업을 현재 하고 있고 어떻게 실패했고 하는 것을 다 알지는 않는다. 이슈 단위나 큰 일정에 따라 확인은 하지만 개별 개발자가 시간마다 어떤 작업 하고 있는지는 당연히 모르고 관리자가 아니라 동료라면 더욱 그렇다. 그러므로 이런 죄책감은 실제로 필요한 것이라기보다는 익숙한 사무실 출근을 안 하고 원격으로 일해서 생기는 것으로 보인다.

원격 근무를 도입한 조직이라면 팀원들한테 이런 죄책감을 느끼지 않아도 된다는 메시지를 충분히 주어서 신뢰가 생기게 만들어야 한다고 본다. 참고로 동료와 업무 공유를 할 필요가 없다는 얘기가 아니다. 사실 업무 공유는 원격 근무에서 훨씬 더 중요한데 이건 뒤에서 더 얘기하겠다.

오버워크

국내에는 아직 원격 근무가 많지 않고 평균적으로는 근무환경이 좋지 않다 보니 원격 근무를 쉬면서 일하는 것처럼 생각하는 느낌이 있다. REMOTE 책(국내 번역서는 "리모트 : 사무실 따윈 필요 없어!")을 보면 "관리자들은 원격근무를 하면 사람들이 일하지 않을까 봐 걱정하지만, 열정 있는 직원들이라면 오히려 원격근무에서 너무 많이 일해서 걱정이라고 한다."라는 얘기가 나오는데 실제로 해보니 그랬다. 원격 근무에 출퇴근 시간이 정해져 있는 게 아니다 보니까 특별한 일이 없으면 그냥 계속 일을 하게 되었다.

아무래도 업무 시간이 나한테 다 맡겨졌으니 그에 대한 책임을 더 느끼게 되었고 원격 근무라는 게 내가 가장 집중하고 생산성이 높을 때 일을 할 수 있다 보니까 그런 상태에 들어갔을 때 더 많이 하게 되는 느낌이었다. 일이 잘 안될 때는 조금 일찍 들어가기도 하지만 일이 잘 될 때는 원래도 퇴근 시간이라는 개념이 크지 않으므로 그냥 일을 끝낼 때까지 계속하게 되었다. 또 개발은 코드를 작성하다가 갑자기 멈추기 싫을 때가 많은데 이런 때는 시간에 상관없이 계속하게 되었다.

앞의 죄책감과 비슷한 부분일 수도 있는데 원격으로 일하면 내가 어느 정도로 평가받고 있는지 잘 모르게 된다. 어떻게 보면 전에도 몰랐는데 원격 근무를 하면 실제로 커밋한 코드나 논의 등 일로만 평가받으니까 더 신경 쓰게 되는 것 같다. 그래서 약간 일을 더 해서 충분히 일을 잘하고 있다고 어필하게 되는 것 같다.

원격 근무는 비동기 협업을 의미한다

원격 근무에 대한 어떤 규칙은 없었지만 1년 반 정도 원격근무를 하면서 원격으로 더 일을 잘하기 위해서 논의도 많이 하고 조금씩 불편할 부분을 개선하고 실험하다 보니 원격 근무를 점점 많이 하게 되었다. 내가 속한 개발 조직은 15~20명 정도였는데 나중에는 하루에 팀의 10~30% 정도만 사무실로 출근을 했다.

원격 근무의 핵심은 비동기로 일하는 것으로 생각한다. 그래서 원격 근무를 하면 단순히 사무실에 안 나오는 것이 아니라 일하는 방식 자체를 바꾸어야 한다. 같은 시간 같은 장소에 팀원들을 모아두는 것은 동기 방식으로 일하기 위함인데 나도 필요할 때 옆 사람한테 말 걸고 도움을 청하는 경우도 많긴 하지만 동기 방식은 요청하는 사람(대부분은 관리자?)의 관점에서 편한 방식이라고 생각한다. 내가 한참 집중해서 코딩하고 있는데 PM이 날 찾아온다거나 어떤 회의 중에 나보고 들어오라고 하면 내가 뭘 하고 있든 간에 멈추어야 한다. 내 경험상 이런 인터럽트 때문에 생기는 실무자들의 비효율을 고민하는 조직은 많지 않았다.

원격 근무로 일하면 자연스럽게 비동기가 된다. 일단 바로 부르고 싶어도 자리에 없으니까 부를 수가 없다. 그렇다 보니 회의할 때도 보통 먼저 오늘 사무실에 나왔는지를 물어보는 메시지가 오면서 내가 가능한 시간을 물어보고 회의시간을 잡아서 진행하게 된다. 보통 회의는 그렇게 잡지 않냐고 할 수도 있겠지만 빈도수 자체가 다르다. 그렇다 보니 오히려 일이 많을 때는 원격근무를 많이 하게 되었다. 정량적으로 검증은 못 해봤지만 원격으로 일할 때는 실제 인터럽트도 없고 내가 그 인터럽트도 제어할 수 있어서 훨씬 개발을 많이 할 수 있었다. 반대로 좀 여유가 있어서 사람들과 수다도 떨 수 있을 때 사무실을 나가게 되었다.

원격 근무를 하면 비동기 방식이 강제되지만, 원격 근무를 더 잘하려면 공격적으로 비동기 방식을 도입해야 한다. 비동기로 일한다는 것은 꽤 많은 부분이 달라진다. 보통은 Slack, GitHub, Jira 등을 사용할 텐데 비동기 방식으로 일하면 이러한 도구들이 완전히 업무의 중심이 되어서 모든 논의, 진행 상황, 결과가 다 어딘가에 기록으로 남아야 한다. 같은 시간에 다 있는 것도 아니고 또 일하고 있어도 채팅을 보고 있는 것은 아니므로 Slack으로 논의하고 GitHub이나 Jira에 기록으로 남겨서 나중에라도 확인하고 따라갈 수 있게 해야 한다. 기록은 나중에 합류한 팀원들에게도 도움이 되는 문서화인데 비동기로 일하면서 이런 부분을 신경 쓰면 자연스럽게 문서화가 된다. 조직 차원에서 이런 기록은 엄청나게 중요한 부분이다.

그리고 원격보다 비동기를 강조한 것은 업무 형태 자체를 이쪽으로 가야 한다고 생각하기 때문이다. 그래서 딱 한 명 빼고 모두 사무실에 나왔다고 하더라도 비동기로 일해야 한다. 채팅으로 얘기하고 기록을 남기거나 사무실에서 회의하고 논의한 얘기는 다시 회의록으로 만들어서 공유해서 팀에서 진행 상황을 놓치는 사람이 없게 해야 한다. 아직 사무실에서 출근하는 게 보통 더 익숙하므로 이런 부분은 팀원 전체가 계속 신경 쓰고 노력하지 않으면 쉽지 않은 부분이다. 다시 생각해 보면 당연한 부분이다. 원격 근무를 하지 않아도 휴가를 가거나 사무실에 있어도 모든 회의에 참여하는 것은 아니므로 당연히 기록을 남기고 모두가 알 수 있게 해야 한다. 하지만 사무실에 모두 있으면 불편하지 않기 때문에 간과하기 쉽다.

그래서 원격 근무를 하려면 전사적으로 비동기로 일해야 한다. 이전에 있던 곳에서는 개발조직이 다른 부서와 밀접하게 닿아서 하지 않는 일이 많아서 개발조직이 원격 근무를 더 잘 할 수 있었다. 개발, 디자인, 기획, QA, 운영 같은 부분은 비동기로 일하는 게 충분히 가능하다고 생각하지만 다른 부서들은 내가 업무형태를 정확히 알지 못하므로 뭐라 말하기는 어렵다. 그 부서는 성격상 모여서 일하더라도 팀 간의 협업은 최소한 비동기가 되어야 회사가 원격으로 일할 수 있어야 한다.

스포카처럼 점진적인 원격 근무 도입을 하는 경우가 아니라면 일주일이나 한 달에 한번 원격 근무 같은 규칙은 무의미하다고 본다. 원격 근무를 하려면 협업 형태가 완전히 비동기가 되어야 하는데 일주일이나 한 달에 한번 같은 규칙은 오히려 휴가나 일찍 퇴근하는 날처럼 비쳐서 일하는 방식은 안 바뀌고 좀 쉬는 날 정도로 받아들여질 가능성이 크다.

관리의 문제

난 관리자는 아니지만 연차가 오르다 보니 관리에 대해서도 관심을 끌게 되었다. 원격 근무를 떠나서 국내에서 관리 대한 고민이나 경험은 그리 성숙하지 못했다는 게 내 생각이다. 여기서 관리는 팀원 관리, 프로젝트 관리, 일정 관리 등을 모두 포함하는데 막상 관심을 가지니 너무 복잡하고 어려운 문제라서 관리만 전문적으로 하는 스페셜리스트가 왜 이렇게 없는가 싶을 정도다. 까놓고 말하면 일정 정해놓고 압박하고 비난하기 바빴지 체계적인 관리에 대해서 심각하게 고민하고 업계에 그 경험이 쌓이게 하는 노력은 거의 없었다고 본다.

사무실에 있을 때 관리자들이 어떤 관리하는지 모르지만, 원격 근무는 얼굴을 보지 않고 일하다 보니 관리가 더 중요하다. 단적으로 특정 팀원이 몸이 안 좋거나 집안일로 고민이 많은 경우 사무실에 있으면 눈치챌 수 있지만, 원격으로는 본인이 얘기하지 않으면 알아차리기가 어렵다. 그 외 업무적으로나 회사 내 인간관계가 힘든 경우도 자연히 알아낼 방법이 없으므로(사무실에 있다고 자연히 알게 되는 건 아니지만...) 이런 부분에 신경을 써야 한다.

해외의 원격 근무 경험 글을 보면 정기적으로 팀원끼리 잡담하는 시간을 만들거나 업무와 상관없이 개인의 상황만 물어보고 챙겨주는 관리자들이 존재한다. 사실 업무 외의 부분만 챙겨주는 관리자는 원격 근무가 아니더라도 외국 회사들에는 꽤 있다. 이런 경험을 못 해서 정확히 어떤 느낌인지는 모르겠지만 원격 근무를 하면 이런 시도가 필요하다

관리는 평가로도 이어질 수 있는데 원격으로 일하면 평가할 수 있는 내용이 실제로 한 일, 기록에 남은 일이 대부분이라서 훨씬 더 공정하다고 생각한다. 불필요하게 사무실에 오래 앉아있거나 눈치 보지 않고 일을 더 잘하는 것에 모두 집중할 수 있다. 물론 이건 개념상으로만 그런거고 실제로 진행되면 객관적인 평가 기준을 마련하기 위해서 팀 내에서 많은 고민과 노력이 필요할 것이다. 평가에 대해서도 내 경험이 짧아서 어렴풋이 생각한 정도만 정리한 것이긴 하다.

신규 입사자, 신입에 대한 지원

사무실로 출퇴근하는 것이 너무 당연해서인지 개개인의 성격에 따라 다른지 모르지만, 아직 국내에서 원격 근무로 일하는 방식이 맞는 사람이 있고 아닌 사람이 있다고 생각한다. 그래서 팀원을 뽑을 때도 원격 근무에 맞는지를 뽑아야 한다. 이건 누가 좋고 나쁘냐가 아니라 팀에 맞냐 안 맞냐에 대한 얘기이다. 원격 근무를 하려면 시간에 대해 관리를 해주거나 감시해주는 사람이 없으므로 자기 주도적으로 일할 수 있어야 하고 비동기로 일하는 부분에 어느 정도 동의가 있어야 한다. 그렇다 보니 어느 순간부터는 면접 때 이런 부분도 물어보곤 했다.

하지만 그래도 해결 안 된 부분은 새로 들어온 사람이나 주니어에 대한 지원이다. 그나마 경력자는 잘 작성해 놓은 문서를 제공하고 사무실에 갔을 때 몇 번 설명해 주면 되지만 신입 지원은 여전히 잘 모르겠다. 보통 사무실에 출퇴근할 때 신입이 입사하면 정기적으로 일부 시간을 빼서 같이 페어 코딩을 하거나 옆에서 지속해서 가르쳐 주면 된다. 하지만 원격 근무라고 생각하면 신입이 새로 회사에 왔는데 정작 자기랑 일할 사람은 아무도 사무실에 없다거나 무엇을 해야 할지 모르겠는데 물어볼 사람도 없는 문제가 발생할 수 있다. 사무실에서도 편하게 물어보라고 해도 신입 입장에서는 당연히 하나도 안 편할 텐데 얼굴도 보지 않은 상태에서는 더 쉽지 않을 것이다. 그리고 신입을 어느 정도 지도를 해주면서 빨리 업무 능력이 향상되도록 도와주어야 하는데 원격 근무로 이 부분을 얼마나 효율적으로 할 수 있는지는 여전히 고민인 부분이다.

우리가 했던 시도

원격 근무를 계속하면서도 아직 모르는 부분이 많았기 때문에 논의하면서 계속 개선해 나갔다. 원격 근무 경험도 많지 않고 팀에 맞는 방법도 찾아야 하므로 지속해서 팀에서 더 좋은 방법을 논의하는 것이 중요하다. 전에 있던 조직은 새로운 방법을 도입하자고 얘기 나오면 논의가 활발하게 진행되는 편이었고 진행을 했다가도 비효율적이면 바로 이슈 제기를 하는 편이라서 더 편하게 의견을 말하고 실험할 수 있었다. 가장 좋은 방법을 한 번에 찾는 것보다는 좋았던 방법이 팀 상황에 따라 안 좋아질 수도 있으므로 지속해서 개선할 수 있는 조직이 훨씬 건전하다고 생각한다.

일하는 상태에 대한 공유

출퇴근과 원격 근무가 섞여 있다 보니 처음에는 원격 근무를 하는 사람만 Slack과 캘린더로 공유하고 사무실로 나오는 사람은 그냥 나왔다. 출퇴근 시간도 정해져 있는 것은 아니라서 다른 사람이 언제 일하고 있는지 몰라서 생기는 불편함을 줄이기 위해 일을 시작하면 채팅으로 시작했음을 같이 일하는 사람들에게 알리고 퇴근할 때도 알리고 퇴근했다. 이는 사무실에 나오는 사람도 사무실에 나옴을 알리고 퇴근할 때는 말하고 퇴근해서 사무실에 나오냐 안 나오냐의 차이를 없앴다.

이 공유는 중간에 자리를 비울 때도 마찬가지로 잠시 자리 비움을 알리고 돌아와서 업무 재개를 하면 다시 알렸다. 추가로 집중해서 개발하고 싶을 때도 2~3시간은 채팅 안 볼 것이라고 얘기하기도 해서 서로 일하기가 편해졌다.

정기적인 만남의 자리

원격 근무가 활성화되면서 사무실에 안 나오는 일이 많다 보니 서로 얼굴을 보기 어려워졌다. 타이밍이 안 맞으면 일주일에 한 번도 못 보는 일도 생기곤 해서 한 달에 한 번씩 다 같이 모여서 점심을 먹는 자리를 만들었다. 이때 그냥 수다를 떨기도 하고 전체가 다 같이 논의할 얘기를 하기도 했다. 물론 이러한 모임은 필수는 아니었다.

Slack의 스탠드업 미팅

스탠드업 미팅을 좋아하진 않는데 다른 사람이 진행하는 업무를 어느 정도 공유하기 위해서 슬랙에서 스탠드업 미팅을 진행했다. 스탠드업 미팅은 보통 서서 아주 짧게 하라지만 길어지는 경우가 허다하고 같은 시간에 모이지 않는 우리에겐 적합하지 않았다. 슬랙봇 서비스가 많은데 우리는 standup-slack-bot를 사용해서 스탠드업 미팅을 진행했다.

이런 봇은 대부분 비슷한데 아침에 bot한테 "어제 한 일", "오늘 할 일", "일을 방해하는 요소", "목표"를 적으면 봇이 이 내용을 모아서 정해진 시간에 전체가 볼 수 있게 공유한다. 아침에 출근하면 보통 오늘 할 작업을 대부분 정리하므로 어차피 해야 할 일이고 그걸 bot에 적어놓으면 몇 분 걸리지 않으면서 전체가 다른 사람이 현재 어떤 일을 하고 어떤 일로 고생 중인지를 알게 되었다. 이는 팀이 커짐에 따라 더 작은 단위로 나누거나 팀 성격에 따라서는 진행 안 하기도 했다.

컨퍼런스 콜

사무실에도 출근할 수 있다 보니 채팅으로 논의하다가 주제가 커지거나 하면 항상 다음 회의 일정을 잡아서 논의하곤 했다. 이렇게 하다 보니 회의가 많아지기도 했고 바로 진행해도 될 일이 회의 잡아서 진행될 때까지 미뤄지는 느낌도 있어서 간단한 일부터 시작해서 논의가 시작되면 바로 컨퍼런스 콜로 진행해서 끝내버리는 일이 많아졌다. 시간이 지나면서 컨퍼런스 콜이 더 자연스러워지니 대부분의 회의도 항상 컨퍼런스 콜을 연결해서 사무실에 안 나온 사람도 회의 내용을 들을 수 있게 했다.

이전까지는 난 항상 카페에서 원격 근무를 했는데 컨퍼런스 콜을 하면서 처음으로 원격을 해도 카페가 아닌 업무 공간이 필요하다는 생각을 했다. 카페는 너무 시끄러워서 마이크가 있어도 말할 수가 없었다.

에필로그

원격 근무를 얘기하면 보통 걱정을 더 많이 하는데 문제는 해결하는 방향으로 나아가면 되는 거 아닌가 싶다. 원격 근무에 대한 걱정에 대한 질문에 대한 내 대부분의 대답은 "그럼 사무실에 있을 때는 어떻게 했나요?"가 되는데 사무실에서 일하다가 프로젝트 일정이 망가졌을 때 아무도 사무실에 모여있는 게 문제인가는 생각하지 않는데 원격 근무에 대한 걱정은 대부분 원격 근무 자체가 문제가 아닐까 생각하는 경우가 많은 것 같다.

난 원격 근무를 지지하게 되었지만, 원격 근무가 모든 회사나 업무에 맞는다고는 생각하지 않는다. 그리고 사람들이 동의하지 않으면 진행하기 어려운 부분이기도 하다. 해외에서는 더 좋은 인력을 데려오려고(거리나 위치 때문에 입사를 안 하는 경우도 많으므로) 원격 근무를 도입하는 때도 많은데 국내에서도 이런 추세가 많이 생겨서 경험이 더 많이 누적되기를 바랄 뿐이다.

2018/03/05 04:05 2018/03/05 04:05

[Book] 사이트 신뢰성 엔지니어링

사이트 신뢰성 엔지니어링

사이트 신뢰성 엔지니어링 - 10점
벳시 베이어 외 지음
장현희 옮김
제이펍


이 책은 구글의 "사이트 신뢰성 엔지니어링(Site Reliability Engineering)" 즉, SRE가 무엇인지 설명하는 책이다. 구글에서는 10년 이상 전부터 SRE라는 역할을 가진 사람들이 있었다고 하는데 그 경험을 가지고 SRE를 외부에 소개하기 위해서 웹사이트를 만들고 내부 SRE들의 경험을 모아서 책으로 공개했다. 이 책은 구글이 공개한 이 책을 번역한 책이다.

소프트웨어 엔지니어링도 마찬가지로 제품을 출시한 이후보다는 출시하기 전에 더 많은 노력이 필요한 것처럼 보이지만, 사실 시스템의 총비용 중 어림잡아 40%~90%가 제품을 출시한 이후에 발생한다. 현재 소프트웨어 업계에서는 프로덕션 환경에 배포가 완료되어 실제로 동작하는 소프트웨어를 '안정화된' 것으로 생각하고 소프트웨어 엔지니어들이 이에 대해 비교적 신경을 덜 쓰는 형태가 정착되어 있는데, 이는 완전히 잘못된 것이다. 이 관점에 따라 소프트웨어 엔지니어링이라는 것이 주로 소프트웨어 시스템을 디자인하고 개발하는 데 초점을 맞춘 것이라면, 소프트웨어 객체를 처음부터 배포와 운영, 개선, 그리고 폐기에 이르기까지 전체 생명주기를 다루는 방법 또한 존재해야 한다.

나는 이전에 있던 회사에서 SRE팀을 만들면서 SRE에 대해서 본격적으로 관심을 가지기 시작했다. "SRE가 어떤 일을 하는가?"에 대해서 설명을 하다 보면 대부분은 "DevOps구나"라고 받아들인다. 꼭 틀린 말은 아니라고 생각하지만 요즘 관심 분야기도 하고 구글은 SRE라는 역할을 어떻게 보고 만들어왔는지가 궁금해서 이 책이 나오자마자 사서 읽게 되었다. 페이지가 500페이지가 넘는데 이렇게 두꺼운 책을 보는 건 오랜만이지만 재미있게 읽었다.

업계 표준 용어인 데브옵스를 다른 의미를 가진 단어로 간주한다. 분명히 코드로서의 인프라스트럭처에 무게 중심을 두기는 하지만, 우리에게 가장 중요한 것은 신뢰성이기 때문이다.

이 책은 SRE가 무엇인지 장황하게 설명하기보다는 실제로 구글 내에서 SRE가 어떻게 일을 하는지를 구체적으로 설명하고 있다. 그래서 각 장의 저자들은 다 다른 사람들이고 이렇게 에세이처럼 작성된 많은 글을 분야별로 묶어서 하나의 책으로 낸 것이다. 다 읽고 나서도 그래서 SRE는 무엇이지? 우리 조직에서는 어떻게 해야 하지?에 대한 명확한 답을 얻지 못할 수도 있다고 생각한다. 대신 쉽게 알지 못하던 구글 내에서 SRE가 어떻게 일하는지를 자세하게 살펴보고 있고 이런 접근방식에서 많은 생각을 하게 될 수 있을 것 같다. 내가 SRE로 일한다면 이 책에 나온 부분과 비슷한 사례를 겪으면 책을 다시 한번 참고하고 접근방식에 대해서 다시 한번 고민해 보면 많은 것을 얻을 수 있을 것 같다.

추가로 이 책을 읽으면서 계속 든 생각은 "내가 있는 조직은 구글이 아니다."라는 점이었다. 이 책에 나오는 수많은 사례에서 "이 정도 까지 고민하고 이런 부분까지 개선하는구나!" 싶으면서도 내가 속한 조직에서 이렇게까지 할 일이 있을지, 혹은 그런 노력을 들일 여유가 있을지 하는 생각이 들었다. 구글과 똑같이 할 여력은 대부분 없으니 구글의 SRE는 어떤 마인드로 일하는가에 더 집중해야 할 것 같다.

Part 1 소개

SRE란 운영팀을 위한 소프트웨어 엔지니어를 말한다.

SRE가는 용어가 아직 많이 알려주지 않으므로 1부에서는 SRE에 대해 설명한다.

기본적으로 SRE팀은 엔지니어링에 초점을 맞춘다는 점이 가장 중요하다. 끊임없이 엔지니어링을 추구하지 않으면 업무 부담이 증가하여 그 부담을 나누기 위해 더 많은 인력이 필요하게 되고 결국에는 서비스의 크기에 따라 전통적인 운영 업무를 담당하는 인력이 기하급수적으로 늘어나게 된다.
...중략...
이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다. 그렇지 못하면 늘어나는 일감에 파묻히게 될 뿐이다. 그래서 구글은 SRE팀에 티켓, 전화 응대, 수작업 등, 소위 '운영' 업무에 최대 50%의 시간만 투입하도록 정해두고 있다.

SRE가 접근하는 방법에 거의 동의하는 편이다. 구글이 사내에서 어떻게 SRE가 시간을 사용하는지 추적하는지가 궁금하긴 했지만...

사실 우리가 원하는 것은 시스템이 자동화되는(automated) 것이 아니라 자동적(automatic)이 되는 것이다.

Part 2 원리와 원칙들

그동안 SRE를 운영하면서 쌓아온 경험을 바탕으로 한 원칙들이 2부에 정리되어 있다.

사용자들은 주로 적절하게 높은 수준의 신뢰성과 극대화된 신뢰성의 차이를 알아차리지 못한다. 왜냐하면, 사용자의 경험이란 모바일 네트워크나 그들이 사용하는 장비처럼 신뢰성이 낮은 컴포넌트들에 의해 좌우되기 때문이다.
...중략...
SRE는 이런 점을 고려하여 업타임을 극대화하는 대신, 서비스가 다운될 수 있는 위험 요소와 빠른 혁신과 효과적인 서비스 운영 사이의 균형을 찾음으로써 사용자의(기능, 서비스, 그리고 성능에 대한) 전체적인 만족도를 향상시키는 것에 집중된다.

처음부터 그랬는지 진행하면서 개선되어 있는지는 모르지만, 구글이 꽤 큰 조직임에도 실용성을 유지하고 있음이 느껴졌다. 말로만 하면서 실용성이 떨어지는 것이 아니라 실제로 더 나아지도록 많은 고민을 한 걸 알 수 있었다.

우리의 목표는 서비스에서 발생 가능한 위험 요소 중 기업이 기꺼이 부담할 용의가 있는 위험 요소들을 찾아내는 것이다. 우리는 충분히 신뢰할 수 있는 서비스를 구현하기 위해 노력하지만, 필요 이상의 신뢰성을 확보하려고는 하지 않는다.

SLO는 서비스 수준 목표(Service Level Objectives)를 의미하며, SLI에 의해 측정된 서비스 수준의 목표 값 혹은 일정 범위의 값을 의미한다. 그래서 SLO는 SLI <= 목표치 또는 최소값 SLI <= 최댓값으로 표현할 수 있다.

책 전체에서 SLO 얘기가 계속 나오는데 SRE가 이 수치를 큰 목표로 하고 있음을 알수 있었다. 이런 수치를 목표로 작업해 본 적은 없기는 한데 운영 관점에서 상태를 파악하기 좋은 수치라는 생각이 들었다.

삽질이란 프로덕션 서비스를 운영하는 것과 직접적으로 연관이 있지만, 수작업을 동반하고, 반복적이며, 자동화가 가능하고, 사후 대처가 필요하며(tactical), 지속적인 가치가 결여되어 있으면서도 서비스의 성장에 따라 지속적으로 늘어나는 업무들을 말한다.

우리는 소프트웨어 기반의 자동화는 대부분의 상황에서 사람이 직접 수행하는 작업보다 우수하다고 생각하기는 하지만, 이 두 가지보다 더 나은 방법은 둘 다 필요치 않은 고수준의 시스템, 즉 자율(autonomous) 시스템을 디자인하는 것이다.

결국, 우리의 임무는 시스템의 신속함과 안정성 사이의 균형을 유지하는 것이다.

Part 3 사례

3부에서는 구체적인 프로젝트나 사례를 가지고 설명한다. 구글에서 SRE가 어떤 일을 처리하고 어떻게 접근하는지를 볼 수 있고 구글의 시스템을 엿볼 수 있어서 개발자로서도 재미있는 부분이었다. 개별 사례를 정리하기는 무리이니 인상적인 부분만 정리한다. 특히 앞에서 얘기한 "우린 구글이 아니다"를 많이 생각한 부분이기도 한데 분산 크론을 구현하거나 마이크로서비스에서 연속적인 장애를 막기 위해 처리하는 사례에서 많이 놀랐다.

우리는 'SRE'에서 'E'가 우리 조직의 특성을 정의한다고 믿고 있으므로 최소 50%의 시간을 엔지니어링에 투자하려고 노력한다. 남은 50% 중에서는 25% 정도를 비상대기에 사용하고 나머지 25%는 프로젝트 업무가 아닌 다른 운영 업무에 할애한다.

운영 업무의 부족은 SRE팀에게 있어서는 당황스러운 부분이다. 프로덕션 환경을 너무 오래 접하지 못한다면 자신감이 너무 지나치거나 혹은 부족해질 수 있으며, 더 큰 문제는 실제 환경과 SRE가 보유한 지식 간의 차이가 장애가 발생한 후에야 비로소 드러난다는 점이다.

우리의 규모와 변화의 속도를 고려하면 사건 사고는 필연적인 것이다.
...중략...
이런 장애들로부터 계속해서 학습할 수 있는 정규화된 절차를 갖지 않는다면 이런 장애들은 무한정 반복될 것이다.

SRE가 엔지니어링에 많은 투자를 하고 있기는 하지만 소프트웨어 개발 조직은 아니므로 운영에 대한 부분에도 계속 신경 쓰고 있다는 것을 알 수 있다. 추측건대 전통적인 운영조직을 SRE로 바꾸면서 엔지니어링을 강조하게 되지만 실제로는 운영업무가 나머지 반이므로 지금은 운영업무에 대해 감이 너무 적어지지 않도록 계속 유지하는 것 같다. 특히 운영에 문제가 없어서 잘 동작하는 경우 SRE가 개입할 일이 적어지면 프로덕션에 대해 감이 멀어져서 생기는 잠재적인 문제를 해결하기 위해 노력하는 것도 인상적이었다.

어떤 종류의 장애도 발생할 수 있다는 생각보다는 모든 것이 잘못될 수 있다는 생각을 갖는 것은 실제로 발생할 긴급 사태를 대비하기 위한 중요한 과정이다. 가능한 모든 재난의 조합과 각 재난에 대응하기 위한 계획을 세워두면 적어도 하룻밤의 숙면을 보장한다.

한편으로는 SRE나 DevOps에 관심이 있지만 나는 소프트웨어 엔지니어로서의 경력을 계속 가져왔기 때문에 대부분 접근방법도 소프트웨어 엔지니어링에 치중되어 있다는 생각이 들었다. 각종 사례를 읽다 보니 나는 좀 더 운영 쪽 마인드와 접근방법을 배울 필요가 있겠다 싶었다.

무언가를 배우는 데 있어 과거에 있었던 일을 문서로 남기는 것보다 나은 방법은 없다. 기록은 다른 누군가의 실수를 바탕으로 학습을 하는 것이다.

포스트모텀은 SRE에게는 필수적인 도구다.
...중략...
포스트모텀은 불이익을 주기 위한 것이 아니다. 회사 전체가 실패로부터 새로운 것을 배울 수 있는 기회인 것이다.
...중략...
서로를 비난하지 않는 포스트모텀은 SRE 문화의 신조다. 실제로 포스트모텀 과정에서 누군가를 비난하는 상황을 완전히 방지하려면 어떤 개인이나 팀의 실수나 부적절한 조치를 지목하지 않고 장애를 유발한 원인을 판단하는 데 집중해야 한다.

포스트모텀이나 문서로 남기는 부분은 그동안 해온 접근이 틀리진 않았구나 하는 생각과 구체적인 사례를 보니 더 개선할 부분도 꽤 있겠다는 생각도 들었다.

Part 4 관리

4부에서는 SRE 조직은 운영하고 다른 팀과 협업하는 관리 측면을 얘기하는데 내가 관리자는 아니다 보니 확 다가오진 않았다. 나중에 비슷한 고민을 할 때 참고해 보면 좋을 것 같기는 하다. 특히 다른 팀과 SRE의 협업 관점은 생각해 볼 만한 부분도 많고 구글도 개발조직이 SRE를 호의적으로 받아들이지 않는다는 느낌도 있었다.

SRE 지원자는 찾기도 어려울 뿐 아니라 효과적으로 면접을 진행하기는 더욱 어렵다.

구글에서도 어려운 거 보면 아직은 SRE는 역할이 업계에 제대로 자리 잡은 건 아닌 것 같다. 아마 시간을 들여서 책을 쓰고 사이트도 만들고 하는 것이 이런 이유 때문이 아닐까 싶다.

엔지니어들은 산만한 주변 환경으로 인해 여러 가지 방식으로 인지적 몰입 상태를 이루지 못한다.
...중략...
주의가 분산되는 상황을 최소화하기 위해서는 컨텍스트 전환(context switching)을 최소화해야 한다. 일부 방해 요소는 불가피하다.





막연하게 SRE라는 용어만 사용하고 있었는데 책을 다 읽고 나니 많이 구체화한 느낌이다. 아직도 그래서 SRE가 뭐야? 라고 하면 너무 많은 생각이 스쳐 지나가서 잘 정리 안 되긴 하지만....


마지막으로 Google에서 올린 What's the Difference Between DevOps and SRE?라는 영상을 공유한다. 5분짜리 영상이지만 DevOps와 SRE가 어떻게 다른지를 이해하기 쉽다고 생각한다. "If you think about DevOps as a philosophy, SRE is a prescriptive way of accomplishing that philosophy."가 핵심이라고 생각하고 있다.

“class SRE implements DevOps”

2018/03/03 18:22 2018/03/03 18:22