[번역] How Google Tests Software - A Break for Q&A

근 한 달만의 포스팅입니다.

거의 매일 새벽이 되어서야 집에 들어가는 생활이 이어지다 보니 블로그는 거의 신경을 쓰지 못했습니다.
그 와중에도 제임스 휘태커의 “How Google Tests Software” 시리즈는 계속 올라오고 있네요.
잠시 짬을 내어 Q&A 포스트를 번역해 봤습니다.

 

개인적으로는 “관리자가 되는 것은 기술적인 리더가 되는 것이다”라는 말이 무척 인상 깊네요.

자세한 내용은 포스트를 참조해 주세요.

 

Ps> 짤방은 제가 여기서 5초만에 작성한 코드… ㅎㅎ

How Google Tests Software – A Break for Q&A

Wednesday, May 04, 2011 2:27 PM

 

By James Whittaker

 

이 연작의 다음 포스트들이 올라오는 데는 점점 더 많은 시간이 걸릴 것 같다. 드디어 내가 진심으로 포스팅 하기 원했던 부분인 구글이 내부적으로 사용하는 툴에 대해서, 그리고 구글의 인프라스트럭쳐가 어떻게 움직이는지에 대해서 포스팅 하려고 한다. 이 주제에 대한 포스팅을 작성하는 것은 시간도 오래 걸릴 뿐더러,  외부에 보여지기 전에 내부적으로 보안과 관련된 일부 과정을 거쳐야만 한다. 그래서 그 사이에 잠시 시간을 내어 이 연작에 대해 던져진 몇 가지 질문에 답하려 한다.

 

Lilia의 질문부터 시작해보겠다(그녀가 닐 영(Neil Young)을 좋아한다고 언급한 것이 그녀의 질문이 선택된 가장 큰 이유이기는 하지만, 그녀가 나보다 더 많은 것을 이룰 가능성이 높다는 것도 크게 작용했다. 이 두 가지 요소가 결합해 그녀는 내게 무척 깊은 인상을 남겼다). 그녀는 SET에서 SWE로 전환(conversion)되는 경우와 그 반대의 경우에 대해서 물어보고, 이 두 가지 중 어떤 경우가 더 자주 발생했는지 물어보았다. 이 질문은 넓게 본다면 SET로서 가질 수 있는 캐리어 패스의 한계가 무엇인가에 대해 물어보는 것이었다.

 

SET와 SWE는 동일한 연봉 수준과 사실상 동일한 직위를 가진다. 두 역할 모두 100% 코딩 업무를 수행하지만 SET는 테스트 코드를, SWE는 기능을 개발한다는 점에서 차이가 있다. 코딩이라는 측면에서 본다면 이들이 사용하는 스킬들은 큰 차이가 없다. 테스팅의 측면에서 본다면 SET가 테스팅 분야에서 더 많은 능력을 발휘할 것이라고 본다. 이렇게 충분한 테스팅 능력에 코딩 능력이 더해지면, SET들 역시 충분히 SWE 역할을 수행할 수 있을 것이다. 그 반대의 경우, 즉 SWE가 테스팅 능력을 더 가진다면 SET 역할을 수행하는 것도 가능해진다. 내 개인적으로는 이러한 전환들이 가능한 환경을 만들어 주는 것이 아주 중요하다고 생각한다. 내가 본 최고의 코더 중에는 전직 SET 출신도 있었고, 또 전직 SWE 중에서도 최고 수준의 테스터가 나오는 것도 경험할 수 있었다. 이들은 본받을 만한 좋은 선례로 남아있다. 우리 팀에서는 이런 전환이 아직도 계속 일어나고 있다. 그러나 구글 전체로 따진다면 아마도 SWE로 전환되는 SET가 더 많은 것 같다.

 

이렇게 역할을 바꾸는 가장 주요한 이유는 과연 무엇일까? 구글의 경우라고 한정한다면, 일단 돈 문제는 아닌 것 같다. 또한 구글이 SET보다 더 많은 SWE들을 보유하고 있어서, 그로 인한 어떤 혜택이 더 있어서도 아니다. 오히려 이런 점 때문에 SET들이 SWE로 전환된다고 해도 눈에 띄는 성과를 내기 힘들다는 단점도 있다. 구글에서 SET들이 부족한 현실은 그들에 대한 어떤 환상을 만들어 버렸다. ‘우리가 작성한 코드를 이렇게 건강하게 유지하고, 개발 프로세스를 원활하게 만드는 이런 일을 하는 이 희귀한 사람들은 도대체 어떤 사람들일까?’라는 의문이 들게 만드는 것이다. 실제로 대부분의 SWE들은 SET를 만족시키고, SET들이 그들의 일을 원활하게 수행할 수 있도록 해주는 것에 많은 관심을 기울이고 있다. 개발팀에서 새로운 기능 개발자를 추가하는 것보다 적합한 SET 후임자를 찾는 것이 훨씬 힘들다는 것을 잘 알면서도, 훌륭한 개발자들을 SET에서 SWE로 전환시키려고 하겠는가? SWE들은 그렇게 멍청한 사람들이 아니다.

 

자, 다른 이야기는 잠시 접어두고, SET보다 SWE들에 숙련된 인원들이 더 많은 점에 대해서 솔직하게 한 번 말해보자. 비율로만 따져도 조직의 하부나 중간 부분보다 더 위로 올라갈수록 우리 테스트 인력들의 비율이 적은 것이 현실이다. 하지만 시작할 때부터 개발자들의 머릿수가 테스터들보다 더 많았다는 것도 명심해야 한다. 구글이 설립되었을 때부터 지금까지 재직중인 개발자도 있다. 하지만 테스터들은 분명 그보다 적은 근속 기간을 가지고 있을 것이다.

 

이런 상황에서 TE는 과연 지금 어느 정도의 위치에 와있는 걸까? TE라는 역할은 분명 SET보다 나중에 생겨나기는 했지만, 이미 어느 정도의 직급 이상을 가지고 있는 사람들도 있으며 오랜 경험을 가진 TE들은 회사 내의 주요한 포지션으로 꾸준히 승진도 하고 있다. 아직 어떤 한계에 다다른 것은 아니다. 단지 TE 중에서 회사의 최고 요직에 이르는 사람이 나오기까지 조금 더 시간이 걸리는 것 뿐이다.

 

Raghev와 다른 분들은 캐리어 패스와 함께 실무자들이 결국에는 관리자가 되는 것 외에 다른 옵션은 없는지에 대해 질문해 주셨다. 이 질문을 받고 나서 난 좀 복잡한 감정을 느꼈다. 나 스스로는 관리자로서 이 역할에 대해 자부심을 가지고 있다. 하지만 여러분들이 내게 정말 묻고 싶었던 것은 ‘정말 관리자가 되는 것 밖에는 방법이 없었느냐?’인 것을 잘 알고 있기 때문이다. 오케이, 나도 딜버트(Dilbert)가 재미있는 만화인 것은 인정한다. 하지만 관리자가 된다고 해서 무조건 몹쓸 사람이나 악마가 되는 것은 아니다.  

 

일단 나의 경우, 관리자가 됨으로써 나의 경험과 판단을 나보다 경험이 적은 사람들에게 전수해 줄 수 있는 기회를 가질 수 있었고, 그보다 더 중요한 것은 실무자들로부터 기술적으로 더 많은 것을 배울 수 있었다는 것이다. 경험 많은 관리자로서의 비전과 실무자가 가지고 있는 기술적인 스킬의 조합은 엄청난 힘을 만들어냈다. 그럼에도 불구하고, 관리직을 수행하기 싫어하는 사람이 그렇게 하기를 강요 받아야 하는 이유는 과연 무엇인가?

 

일단 운 좋게도, 구글에서는 우리에게 선택을 강요하지 않았다. 구글은 관리자들이 실무자로서 수행하던 업무를 계속 수행할 것을 요구한다. 단순한 관리자가 아니라, 기술적인 면에서 다른 사람들을 리딩할 수 있는 기술적 리더가 되는 것을 요구하는 것이다. 그리고 우리 실무자들 역시 개별적인 업무 영역에만 집중하는 것이 아니라, 관리자로서의 소양을 양성하도록 장려된다. 숙련된 실무자나 임원이 된다는 것은 곧 기술적인 리더가 된다는 것에 다름아닌 것이다. 어떤 리더들은 관리보다는 리딩에 더 집중하고, 또 어떤 리더들은 리딩보다는 관리에 더 집중한다.

 

위에서 본다면 이 두 방법이 모두 똑같이 여러 사람이 관리자 한 명의 지시에 따르는 것처럼 보일 것이다. 그 사람이 관리를 하던, 그렇지 않던 말이다.