구글의 소프트웨어 엔지니어링 (2/5)

2. 유지 보수와 관리자

하이럼 법칙

구글의 엔지니어이자 책의 저자 중 한명인 Hyrum 이 말한 법칙입니다.

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

> API를 사용하는 유저가 충분히 많다면, 여러분이 어떤 의도를 가지고 API를 설계했든, 여러분의 시스템에서 관측 가능한 모든 행동들은 사용자에 의해 결정됩니다.

 

문맥에 따라 의역을 하자면 이렇습니다. API를 사용하는 사용자가 많아지면 API 문서에 뭐라고 적어두었는지는 더 이상 크게 중요하지 않다는 것을 의미합니다. 사용자가 API를 사용하면서, API 통해 기대하는 동작이 있을 것이고 이것들이 모여 API 문서와는 별개로 '암묵적인 인터페이스 규약'이라는 것이 생깁니다.

 

대표적인 예시로 xkcd에서 나온 코믹스 사례를 예시로 들었습니다. CPU의 스페이스바를 누르면 CPU 가 과열되는 문제가 있었는데, 이 버그를 수정하자 오히려 항의 메일을 받았다는 겁니다. 누군가는 스페이스바를 누를 때 CPU 가 과열된다는 사실을 이용해서 프로그램을 개발하고 있었고 결국 이를 옵션으로 켜고 끌 수 있도록 해달라 했다고 합니다.(참조 : https://xkcd.com/1172/)

 

결국 우리는 이 '암묵적인 인터페이스 규약'조차도 지킬 수 있어야 한다고 말합니다. 암묵적이어도 규약이기 때문입니다. 그리고 만약 API에 버그가 있었다면 이를 그냥 수정하고 문서만 바꾸기만 해서는 안 된다고 합니다. 더 나아가 구글에서는 버그를 위한 버그 하위 호환성도 지킬 수 있어야 한다고 말합니다.

 

하이럼 법칙은 사용자 수가 많고, API 가 노출되는 뮤든 곳에서 발생할 수 있다고 말합니다. 하이럼 법칙 때문에 확장이나 축소가 어려워지는 경우도 많이 셍깁니다. 그리고 확장 축소와 관련해서 하이럼 법칙이 문제가 되었던 실제 사례를 중간중간 많이 이야기하고 있습니다. 그렇기 때문에 하이럼 법칙을 API deprecation 이나 수정하기 어려운 이유 중 하나로 들고 있습니다.

 

---

The bus factor

이 내용은 좀 재미있는 내용같아서 가져와봤습니다. Bus factor 란 "프로젝트 멤버 중 일부가 갑작스럽게 버스에 치여서 입원해야하느라 프로젝트를 하게 될 수 없는 경우, 몇 명까지 버스에 치여도 프로젝트가 중단되지 않을 수 있는가?" 입니다. 다시말해 프로젝트가 중단되지 않고 유지될 수 있게 하는 사람의 수가 몇이냐라는 의미입니다.

 

bus라고 하길래 네트워크에서 말하는 bus를 의미하는 줄 알았는데 실제 물리적인 버스를 의미하더라고요.

 

책에서 bus factor를 설명하면서 이야기하는 요점은 간단합니다. bus factor를 늘리라고 합니다. 프로젝트의 모든 짐을 혼자 감당하는 슈퍼 개발자가 되려한다면 프로젝트가 좌초될 확률이 높다 합니다. 그리고 bus factor 를 높이기 위해 본인이 가진 지식과 노하우를 팀원들에게 공유해서 분담하라고 말합니다.

 

---

관리자라는 말 자체가 시대착오적이다.

개인적으론 이 주장도 꽤나 신선했습니다. 책에서 주장하는 바에 따르면 회사에서 쓰이는 관리자라는 말의 의미는 산업혁명에서 나온 것이라고 합니다. 산업혁명 시대에서 관리자란 말 그대로 노동자들이 일을 제대로 하고 있는지를 관리 감독하기 위한 사람을 칭하기 위해 사용했습니다. 노동자들은 빈번히 교체되기 일쑤였기 때문에, 관리자는 노동자들에게 잘 대우해 주거나 환경 개선해 줄 필요성을 느끼지 못했습니다.

 

당연하게도 그 시절의 관리자 개념을 현대에 갖고 오면 문제가 많아집니다. 그리고 가장 중요한 건 관리자라는 단어 자체가 주는 오해입니다. 관리라는 단어를 듣자 어떤 느낌이 드셨나요? 누군가에게 업무를 지시 하고, 제대로 일을 하고 있는지, 내 생각대로 일을 처리하고 있는지 확인해야 할 것 같은 기분이 들지 않았나요? 이러한 오해는 관리자라는 직책을 가졌을 때 뿐만 아니라 '관리'라는 업무를 지시 받았을 때 빈번히 발생합니다.

 

문제는 이런 방식이 조직을 확장하는데 용이하지 않다는 겁니다. 시간이 지나면서 조직이 확장되면 인력이 추가되고, 조직은 필연적으로 관리자가 더 이상 감당할 수 없는 수준으로 커집니다. 이러한 상황에서 중앙에 있는 관리자가 사라지면 조직은 방향성을 잃게 됩니다. 대표적인 예를 들어봅시다. 혹시 관리 일을 하고 계시다면, 휴가 신청을 했음에도 업무와 관련된 문의 메일을 받으신 적 없으신가요? 휴가는 업무에서 완전히 벗어나 온전히 쉴 수 있어야 하는 시간인데, 휴가 중 한 번씩 신경써야하는 업무 때문에 적절한 리프레시를 얻지 못하게 됩니다. 이는 위에서 언급한 bus factor 하고도 일부 연결되는 의미라고 생각합니다.

 

관리자가 지시를 내리는 업무 형태를 그림으로 표현하면 아래와 같습니다.

 

이런 방법보다, 구글에서 제시하는 더 나은 방법은 전통적 의미의 관리를 하지 말라고 합니다. 관리자는 모든 직원의 성과, 생산성, 행복에 대한 책임을 질 수 있어야 한다 합니다. 세부적인 개발을 지시하지 말고 팀원에게 맡기라고 합니다.

 

그리고 이 대목을 읽고 문득 OOP가 떠올랐습니다. 책에서 말한 관리의 형태를 보면 아래와 같이 표현할 수 있을겁니다.

관리자는 방향을 제시하고 세부 구현은 팀원에게 맡깁니다. 곰곰이 생각해 보니 이 그림 어디선가 많이 본 그림입니다. 인터페이스를 제시하고, Concrete 클래스를 개발하는 그림. 구글은 조직 자체가 OOP스럽게 일하는구나라고 실감했습니다.

 

책에서는 Manager, Tech leader, TLM 등에 대해 상세히 구분하는데, 자세한 내용은 넘어가도록 하겠습니다.

 

---

피터의 법칙

관리 이야기가 나와서 이 키워드도 재밌었어서 적어봅니다. 로렌스 피터 교수가 발표한 경영 이론이라는데, 이 책에서는 이 이론을 무능한 관리자가 왜 탄생하는가에 대한 설명을 하기 위해 사용합니다.

 

아무리 훌륭한 회사에서도 꼭 무능한 관리자가 한 명씩 있었다고 합니다. 생각해 보면 이와 관련된 내용은 실제 사례도 금방 찾을 수 있을 것 같습니다. 그런데 대기업이라는 높은 취업 문턱을 뚫고 들어오는 사람들이, 성과를 보이고 승진을 거듭해 오른 자리인데, 어떻게 무능한 관리자가 있을 수 있을까요?

 

여기에 대한 답은 사람들이 본인이 감당할 수 없는 수준까지 승진을 하기 때문이라고 합니다. 이렇게 말하니 무슨 승진을 하지 말라는 것처럼 들리는데, 그건 아닙니다. 개발자 관점에서 해석하자면 개발자와 관리자는 완전히 다른 영역이고 관리자가 되면 업무의 종류가 바뀐다는 겁니다.

 

책에서는 이에 대한 간단한 예를 듭니다. 신입사원으로 뽑힌 엔지니어 A 씨를 뽑았다고 합시다. A씨는 연차가 쌓이면서 개발자로서의 훌륭한 역량을 보여왔습니다. 시간이 흘러 당당히 미들급 개발자가 되었고, 주변에서는 이제 한번 관리직을 맡아보는 게 어떻겠냐는 제의를 받습니다. A씨는 이 제안을 승락하고 관리자가됩니다.

 

그런데 여기서 문제는 A씨는 개발자로서 훌륭한 역량을 보여왔던 것이지, 관리자로서는 아무것도 보여주고 역량을 쌓은게 없다는 겁니다.

 

또 다른 예시로 7년 차 개발자가 조직에 지원서를 낸 상황이라 합시다. 면접관들은 개발자를 뽑기 위해 엔지니어링 역량을 물어봅니다. 개발 능력, 이전의 프로젝트, 코딩 스타일 모든 게 만족스럽습니다. 지원자는 합격했고, 회사에 입사합니다. 회사에서는 이제 입사자 분을 어떤 직책에 놓을지 고민합니다. 고민해보니 연차를 고려해보면 중간급 관리자로 역할을 주면 좋을 것 같네요!

 

이게 오류라는 겁니다. 관리자를 뽑으려 했으면서 면접때 했던 개발 질문은 무슨 의미가 있었던걸까요?

 

책의 표현을 빗대자면 이렇습니다.

조직 입장에서는 훌륭한 엔지니어를 잃고 무능한 관리자를 얻는 상황

 

결과적으로 팀원을 관리자로 승진시키거나, 관리자를 뽑을 때는, 관리자로서의 역량을 볼 수 있어야하고 요구해야 한다 합니다. 그리고 구글에서는 관리자로 승진해야할 시기가 되면 이전부터 관리 업무를 요구하기 시작한다고 합니다. 조직원들은 이를 통해 역량을 쌓고, 성과를 보이며 성장할 수 있도록 한다고 합니다.

 

물론 반드시 높은 직급이 관리자를 의미하는 것은 아닙니다. 문화적으로 국내에서는 높은 급여를 받기 위해선 반드시 승진해야하니 이 부분은 잘못 말하면 조금 오해가 있을 수 있을 것 같습니다. 이 내용은 여기까지만 적겠습니다. 상세한 내용은 책을 읽어보시는 것을 추천드립니다.

 

* 경영 이론인데다 책이나 검색을 통해 얻은 지식이 대부분입니다. 일부 내용이 틀릴 수 있습니다.

 

* 파킨슨 법칙: 피터의 법칙을 이야기하면 함께 나오는 경영 이론입니다. 관리자에 대한 내용은 아니고 이것도 꽤나 재미있는 키워드였기 때문에 같이 적습니다. 공무원 수는 왜 계속 늘어나는가에 대한 내용인데, 너무 잘 정리된 내용이 있어서 링크를 달아둡니다.