[B급 프로그래머] What makes a good engineering culture?

Quora에 다음과 같은 질문이 올라왔다.

Quora and Facebook both have strong, well-known engineering cultures. What makes a "good" engineering culture - free time to commit to projects, a commitment to open source, or is it the leadership being technical by trade?

한글로 번역하자면... "쿠오라와 페이스북에는 강력하고 잘 알려진 공학적인 문화가 있습니다. '훌륭한' 공학적인 문화를 만드는 요인은 무엇일까요? 프로젝트에 전념하기 위한 시간? 오픈 소스에 대한 기여? 전문가가 되기 위한 리더십?"

여러 가지 다양한 의견이 나왔지만, 질문의 당사자(아니 해당 회사)로 쿠오라 엔지니어인 Edmond Lau가 직접 대답한 내용이 대박이다. 그냥 읽고 넘어가기에 좋은 정보이기에(라 쓰고 '나중에 참조할 목적으로'라고 읽는다. ㅋㅋ) 간략하게 요점을 정리해보았다

1. 반복 속력을 최적화한다: 빠른 반복 속력은 작업 동기와 흥미를 유발한다. 코드 배포와 기능 출시를 방해하는 구조적이며 관료적인 장벽은 엔지니어가 회사를 떠나는 이유 중에 가장 짜증나며 공통적인 요인으로 작용한다. 조직적인 관점에서 보면, 빠른 반복 속력은 엔지니어와 디자이너에게 매일 일어나는 결정을 허가를 얻지 않고 자율적이고 유연하게 내리도록 만든다. 반복 속력은 또한 제품 개발을 시작하기 위한 잘 정의된 프로세스가 정립되어 투자가 많이 일어났을 경우에 개발 취소가 기대치 않은 방식으로 일어나지 않음을 의미한다. 팀 관점에서, 빠른 반복 속력은 팀 노력을 조율하고 이끌어내기 위한 강력한 리더십을 의미한다.
2. 무지막지하게 자동화를 추구한다: 제품이 커저나감에 따라, 엔지니어당 운영 부하도 커져나간다. 페이스북은 엔지니어당 백만 가입자를 뒷받침하는 확장 측정 기준을 내세우는 것으로 유명하다. 자동화와 스크립트화는 개발팀이 실제 제품에 전념하도록 만들어주므로, 단기적인 땜빵이라는 유혹에서 벗어나 장기적인 수정과 테스트에 집중해야 한다.
3. 올바른 소프트웨어 추상화를 이룬다: MIT 교수인 다니엘 잭슨은 소프트웨어 추상화의 중요성을 다음과 같이 말했다. "올바른 추상화를 고른다면, 설계부터 자연스럽게 프로그램이 흘러가도록 만들며, 모듈을 작고 단순한 인터페이스로 유지하며, 새로운 기능은 광범위한 재조직화 없이 기존 틀에 맞아 떨어지게 된다." 팀이 땜방질 해법으로 추상화를 조각내는 대신 소수의 핵심 추상화에 집중하게 되면 공통 라이브러리가 좀더 튼튼해지며, 모니터링이 지능화되며, 성능 지표를 쉽게 이해할 수 있게 되며, 포괄적인 테스트가 가능하게 된다.
4. 코드 검토로 고품질 코드에 집중한다: 고품질 코드 기반을 유지하면 전체 엔지니어링 팀의 생산성을 높인다. 깨끗한 코드는 이해하기 쉽고, 개발하기 쉽고, 변경하기 쉽고 버그를 (미리) 노출하기 쉽다. (커밋 전이 되었든 커밋 후가 되었든) 시의 적절한 코드 검토를 위한 프로세스 수립은 코드 품질을 여러 가지 방식으로 개선한다. 누군가 코드를 검토한다는 사실이 엉망인 코드 작성에 대한 유혹을 강하게 압박하며, 코드 검토자와 코드 작성자가 더 나은 코드를 작성하는 방법을 배울 기회가 생기기 때문이다.
5. (서로) 존중하는 작업 환경을 유지한다: 동료 사이의 존중은 열린 의사 소통의 토대를 형성한다. 서로의 생각에 도전하는 행위가 다연스러운 장소에서 건전한 아이디어가 나온다. 서로 물고 뜯는 환경에서는 제대로 된 피드백이 존재하지 않는다. 엔지니어들은 다양한 범위에서 전문가이며, 모든 사람이 각 분야마다 경험치가 다르다. 강력한 팀은 특정 분야에는 강하지만 다른 분야에는 약한 개인들로 구성되지만, 서로 존중하는 문화가 강점을 살려준다.
6. 코드의 소유권을 공유하자: 코드 소유권을 공유할 경우, 유지 보수 담당이 자리를 비운 상황에서도 유지 보수 담당과 해당 팀원의 스트레스가 줄어든다(백업 요원이 있기 때문에). 또한 팀원들이 특정 분야에 너무 깊이 빠져들지 않기에(예: 난 이 모듈만 책임진다!) 참신한 통찰력을 제공할 수 있게 된다. 마지막으로 전략적인 목표를 빨리 끝내야 할 필요가 있는 시급한 문제를 여러 명이 함께 해결할 수 있게 된다.
7. 자동화된 테스트에 투자하자: 단위 테스트 커버리지와 통합 테스트 커버리지는 끊임없이 빌드나 제품을 깨먹지 않고서도 대규모 개발자들이 대규모 코드 기반을 관리하도록 만드는 확장 가능한 유일한 방법이다. 자동화 테스트는 팀이 커짐에 따라 지속적인 배포 작업이 가능하도록 만드는 핵심이다.
8. 20% 시간을 할당하자: 구글, 아틀라시안, 페이스북, 쿠오라는 모두 엔지니어들에게 20%의 시간을 줘서 일반적인 프로젝트 이외에 하고 싶은 뭔가를 하도록 유도한다. 미친 듯이 보이는 아이디어를 실행할 수 있는 시간을 주게 되면 뭔가 색다른 결과를 만들어내며, 장기적으로는 서비스나 제품에 많은 도움을 준다.
9. 지속적인 개선과 학습 문화를 만들자: 주간 기술 회의는 엔지니어들에게 설계안과 작성 중인 코드를 공유하는 장을 만들어줘서 엔지니어들이 자신들의 작업에 긍지를 느끼고 팀이 당면한 작업 범위를 벗어나 넓게 볼 기회를 제공한다. 배우는 문화를 구축하려면 기초적인 알고리즘, 시스템, 제품 기술을 모든 직원이 보유할 수 있도록 멘터링하고 훈련하는데 집중한다. 엔지니어링 조직이 커지고 사람을 뽑는 노력이 더 들어갈 수록 멘터링과 훈련에 투자하는 노력도 커진다. 새로 뽑은 신입에 대해 매일 한 시간씩 멘터가 시간을 투자하는 행위가 부담으로 느껴질지 모르겠지만, 신입이 성공을 위한 준비를 마치는 과정에서 상당히 큰 지렛대 구실을 한다.
10. 최고 개발자를 고용하자: 스티브 잡스는 다음과 같이 말했다. "A급은 A급을 뽑고, B급은 C급을 뽑는다" 페이스북 Yishan Wong은 "최고 개발자를 고용하는" 것과 "인터뷰한 최고 후보를 고용하는" 것 사이에는 차이가 있음을 강조한다. 쿠오라도 처음에는 엄청난 고객 요청에 압도 당해 고용 기준을 낮출뻔 했지만 그렇게 하지 않았다. 낮은 품질의 코드와 취약한 엔지니어로 기인한 기술 빚은 팀과 제품을 망가 뜨리기 때문이다.

이 정도면 아주 좋은 출발점으로 보인다. 하지만 훌륭한 문화를 만들기 위해서는 무엇보다 _실천_이 우선이다. 아무리 좋아도 이론은 이론일 뿐이니까. 그런 의미에서 바쁘다는 핑계로 차일피일 미루던 (사내 정보 공유를 위한) 수요 기술 세미나를 내주부터 다시 열어야 겠다. :)

EOB