의사결정을 객관적으로 하는 방법

이 이야기는 팀의 성장함에  따라 세가지 주요 프로세스를 추가하는 것에 대한 내용이고 기술적 세부 사항뿐 아니라 행동 기대치를 설정해둘 때 세 가지 프로세스가 모두 가장 잘 동작한다는 이야기를 하는 것이다. 

책 "개발7년차, 매니저 1일차" 의 내용 중 두고 두고 읽으면서 참고해야할 내용이라 손쉽게 볼 수 있는 블로그에 옮겨본다. 또한 나의 팀에도 적용을 해보고 싶은 방법이다. 

 

코드리뷰 

코드리뷰는 좋든 나쁘든 최신 표준이다. 특정 인원으로 특정 크기의 팀이 꾸려지면, 코드 리뷰는 안정성과 장기적인 코드 품질을 보장하는 유용한 도구가 된다.

하지만 업무를 완수하기 위해서는 프로세스가 간단하고 효율적이기를 바랄 것이다. 

게다가 어떤 개발자는 코드 리뷰 과정에서 무례하게 행동하곤 한다. 동료를 비판하거나 비현실적인 기준을 적용하려고 코드 리뷰를 한다.

코드리뷰를 원활하게 진행하는 좋은 예시를 몇 가지 소개한다. 

코드 리뷰 기대치를 명확하게 잡자. 대부분의 코드 리뷰는  버그를 잡지 못한다. 버그는 테스트로 잡는 것이다. 하지만 예외가 있다. 코드 리뷰를 통해 누락된 코드 주석이나 문서 업데이트를 확인하거나, 빠져 있는 기능을 확인할 수 있다. 

가끔은 코드 리뷰어가 부적절한 테스트 방법을 지적해줄 수도 있다. 코드 리뷰는 크게 보면 공유 활동이고, 여러 팀의 팀원들은 변경된 코드가 있다는 사실을 알 수 있다. 

 

스타일 문제는 린터(linter)를 사용하라. 스타일 특히 코드 포맷에 대한 질문으로 터무니없는 시간을 낭비할 수 있다. 이는 코드 리뷰에서 논할 문제가 아니다. 

린터는 스타일을 결정하고 서식을 자동으로 잡아준다. 린터에 스타일을 적용하라. 코드 리뷰 때 스타일 이야기를 하게 되면, 비생산적인 사소한 말다툼과 비판이 발생하고, 최악의 경우에는 괴롭힘으로 이어진다. 

 

리뷰 백로그를 주목하라. 어떤 회사는 한 사람에게 할당할 수 있는 미해결 리뷰 요청 개수를 제한한다. 한 직원이 너무 많은 요청을 처리하는 경우, 그 직원이 리뷰 요청을 받을 수 없도록 막는다. 이 요청들을 시스템을 통해 어떻게 처리할지, 어떻게 모두가 적당한 시간 동안 코드를 작성할 수 있을지 생각해보자. 

 

 

장애 사후 분석(Postmortem)

장애 관리의 세세한 부분까지는 설명하지 않겠지만, '사후 분석' 과정은 좋은 개발을 위한 필수 요소이다. 사실 최근에는 많은 사람들이 사후분석 대신에 '학습 검토(learning review)'라고 부르기 시작했다. 사후 분석을 하는 목적이 장애의 원인을 찾아 내기 위해서가 아니라 장애를 통해 배우기 위해서이기 때문이다. 이에 관한 많은 글이 있지만 규모가 작은 팀에 중요한 부분 몇 가지만 강조해보겠다. 

 

비난하거나 지적하고 싶은 충동을 억제하라. 모두에게 스트레스였던 장애가 처리되면, 왜 행동의 결과를 예측하지 못했는지 직원들에게 따지고 싶고 손가락질하고 싶은 충동이 엄청나게 일어난다. 직원들은 왜 그 장비에서 명령을 실행시켰을까? 왜 테스트를 하지 않았을까? 왜 경고를 무시했을까? 안타깝게도 이런 비난은 직원들이 실수를 두려워하게 만들 뿐이다. 

 

사건의 상황을 살펴보고 맥락을 이해하라. 장애가 발생한 요인을 찾고 이해하고 싶을 것이다. 문제를 사전에 감지할 수 있었던 테스트나 장애 관리를 더 원활하게 진행할 수 있는 도구도 찾고 싶을 것이다. 장애요인 목록을 잘 정리해두면, 개선을 위한 패턴이나 개선이 필요한 부분을 알 수 있고 학습 검토에서 진짜 학습이 일어난다.

 

중요하게 가져가야할 것과 그렇지 않은 것에 대해 현실적으로 접근하라. 팀원들의 업무 과정에서 발견된 모든 문제를 해결해야 한다는 인상을 주지 않도록 하라. 수많은 학습 검토는 길고 긴 '개선 목록'을 정리하고서야 끝나지만 모든 것을 해낼 수 없을 것이다.

사실, 모든 것을 다하려고 한다면 아무것도 끝내지 못할 것이다. 정말 위험한 문제와 향후에 상당히 문제가 될 수 있는 두 가지만 선택하라. 그리고 나머지는 내려놓아야 한다. 

 

 

아키텍처 검토 

팀이 만들고자 하는 모든 주요 시스템과 도구의 변화를 아키텍처 검토에 포함시킬 것이다. 아키텍처 검토의 목표는 팀이 겪게 될 변화를 공유하고 변화에 따르는 위험을 명확히 하기 위해서다. 미리 다음과 같은 질문을 공유하고, 참석자에게 답변을 준비해 오라고 요청할 수 있다. 

• 얼마나 많은 팀원들이 새 시스템을 사용하고 새 언어로 작성하는 것을 편하게 느끼는가? 
• 변화에 대한 적절한 프로덕션 표준이 있는가? 
• 변화를 확산하기 위한 프로세스는 무엇이고 팀원들은 어떤 교육을 받아야 하는가? 
• 이를 사용하기 위해 운영 시 추가로 고려할 사항이 있는가? 

 

다음은 몇 가지 가이드라인이다. 

 

아키텍처 검토가 필요한 변경 사항의 종류를 명시해둔다. 대게 아키텍처 검토에는 새로운 언어, 프레임워크, 스토리지 시스템과 개발 도구가 포함된다. 사람들은 종종 신규 기능을 부실하게 설계하지 않도록 아키텍처 검토를 한다. 하지만 작은 회사에서 신규 기능 설계의 오류를 초기 단계에서 발견하는 것은 쉽지 않으며 규모가 큰 회사에서도 마찬가지다. 또한 아키텍처 검토로 인해 업무 속도도 많이 느려진다. 앞서 지적한 것처럼 기능 설계와 같은 일반적인 업무에 무거운 프로세스를 적용하고 싶지 않을 것이다. 

 

아키텍처 검토의 가치는 검토 준비 과정에 있다. 팀원들에게 시스템의 큰 변경 사항이나 추가 사항에 대한 검토를 요청하면 변화가 필요한 이유에 대해 생각하게 될 것이다. 다시 강조하지만, 이런 과정을 통해 팀원들이 생각지 못한 위험을 인식하도록 하는 것이 중요하다. 우선 변경이 필요한 이유를 팀원들이 먼저 설명하게 해도 좋고 그렇지 않아도 괜찮다. 팀원들이 변경에 대한 요구사항을 정하는데 참여하려고 하고, 또 그럴 수 있다면, 변경이 필요한 이유는 명백히 드러난다. 

 

검토 위원회를 현명하게 선택하라. 늘 선정되는 구루 그룹이 아닌 변경으로 인해 팀에 가장 영향을 받는 사람들이 검토 위원회에 포함되는 것이 좋다. 모든 기술적 결정이 이루이지는 책임이 막중한 자리에서 당신이 빠지는 것도 목표 중 하나다. 또 다른 목표는 결정에 따른 결과를 처리해야 하는 사람들을 위원회에 포함하는 것이다. 가능한 많은 팀원들이 결정에 참여하고 그들이 결정된 것을 수용하도록 하는 것이 좋다. 회사 전체를 고려할 필요는 없다. 결정을 내리는 위원회는 가장 많은 영향을 받는 사람들로 구성되는 것이 좋다. 전혀 무관한 사람들이 프로젝트를 거부하는 것만큼 팀원들의 사기를 떨어뜨리는 일은 없다.