Offcanvas

How To / 리더십|조직관리 / 소프트스킬 / 애플리케이션 / 자기계발

'건강한 비평의 고효율성'··· 동료 코드 평가제를 도입할 이유

2015.06.24 Jonathan Hassell  |  CIO
만약 기존의 자원만 이용해서도 소프트웨어 개발 프로젝트의 품질과 타임라인을 개선할 수 있다면 어떨까? 그런데 그러한 비법이 존재한다.

바로 동료 평가(peer review)다.

동료 평가는 버그 찾기와 수정에 쓰이는 작업(코드 평가)의 시간을 최소화하면서 개발 인력을 최대한 활용할 수 있는 훌륭한 방법이다.

작업 과정은 어떤 것일까? 개발자가 동료들과 팀을 이뤄 다른 개발자의 코드를 검토하고 품질을 확인하고 중복 코드 제거 및 개선 작업을 하게 된다. 개발자는 그의 코드를 따라가면서 작업해온 그의 논리와 이야기를 설명하고 그 개념을 어떻게 개발했는지 보여준다. 동료 개발자들은 오류가 어디에 있을지 추정해보고 까다로운 문제 해결에 도움을 주고 일반적으로 코드의 품질을 개선시키게 된다.



동료 평가를 새로운 표준으로 만들기
동료 평가가 과학적 학문적 출판계에 있어서는 필수적 요소였다. 그러나 적어도 코드 수천 줄로 이뤄져서 수천 가지 오류 가능성이 잠재된 소프트웨어 개발업계에서는 최근에서야 조금씩 활용되고 있다.

성공적인 동료 평가는 품질의 중요한 지표이며 정기적으로 활용되면 수많은 시간과 돈을 절약해줄 수 있다. 만약 오류가 식별되고 차후 빌드에 통합되기 이전에 수정되면 결함이 줄어들고 프로젝트는 더 빠르게 마무리될 것이다.

“코드 컴플리트(Code Complete)”라는 서적에는 “동료 평가를 시행한 이후 에트나 보험사에서는 검사를 활용한 프로그램으로 오류의 82%를 찾아냈고, 개발 자원을 20% 감축시킬 수 있었다” 라고 기술돼 있다.

만약 이를 시작하고자 한다면 서로와 프로세스를 존중하는 두 명의 프로그래머를 한 조로 묶어서 조용히 시행해보고 다른 개발자들이나 팀이 이 두 명의 코드 향상 품질에 어떻게 반응하는지 살펴볼 수 있을 것이다. 아니면 톱-다운 접근방식을 통해 단순히 동료 평가의 문화를 새로운 표준으로 시행해버릴 수도 있을 것이다.

반대 이유 5가지와 그 극복 방안
하지만 그렇게 동료 평가 프로그램을 시작한다면 당연히 불평 불만이 따라오기 마련이다. 몇 가지 가장 흔한 불만사항들은 다음과 같다:

- 동료 평가는 시간 낭비고 그냥 방해만 된다. 안타깝게도 당신의 팀 멤버 일부는 동료 평가에 대해 공포와 미루기로 반응할 수 있다. 그러나 이런 직원들이야말로 정기적인 동료 평가를 통해 가장 혜택을 볼 수 있는 취약한 개발자들일 확률이 높다.

이런 문제를 해결하려면 여러 사람의 검토를 거치는 게 한 사람보다 낫고 그 결과 코드 품질이 향상되고 그런 품질 향상이 회사 내 모든 이들에게 중요하다는 점을 설명해야 한다.

- 나는 비판에 잘 대처하지 못한다. 사실 동료 평가는 코드에 대한 비평을 의미하는데, 몇몇 개발자들은 분명 개인적인 감정을 배제한 채 비판하는 것에 대해 어려움을 느낄 것이다.

그러나 이는 시간이 지나면서 나아지는 능력이다. 이런 세션을 더욱 생산적으로 만들려면 테스트 사례, 테스트 계획, 요건, 사용자 이야기, 심지어 아키텍처 토론까지 활용해 프로세스 초반에 동료 평가를 시작해서 실제 코드만이 검토되는 요소가 아니게 만드는 게 좋다. 그렇게 하면 당신의 팀은 항상 사고 프로세스 공유와 개선을 편안하게 받아들이게 된다.


- 나는 우리 팀 다른 사람을 평가할만한 실력이 안 된다. 동료 평가가 시작되면 누구는 많이 나서고 누구는 소극적이 되는 게 사실이다. 이런 불균형은 첫해가 지나면 평준화된다. 특히 보너스가 추가될수록 이런 유형의 정기적 검토는 연례 성과 검토를 더 쉽게 만들어준다. 최고이자 가장 똑똑한 인재를 식별하는 경영 업무 역시도 누가 당신의 팀에 기여할 능력이 있고 누가 재배치나 퇴사할 필요가 있는지가 훨씬 분명해질 것이다.

- 스케줄에 여유가 없다. 또 마감 시한이 이런 유형의 검토 시간을 낼 수 없게 해서 동료평가를 할 시간이 없다. 급박한 마감시한이 검토를 수행하지 않을 이유가 되지 않아야 한다. 잘못된 시간에 하는 게 될 수 있더라도(예를 들어 수정에 야근이 필요한 빌드가 파괴된 이후) 언제나 검토는 있어야 한다. 알맞은 시간은 초기 종종 수행하는 것이고, 일반적으로 동료 코드 평가가 제대로 수행되면 프로젝트가 조기에 마무리되는 게 일반적이다. 한번 알아보라.

- 누구랑 조를 짜야 될지 모르겠다. 이는 당신의 직속 상관이 아마 결론을 내야 하는 종류의 문제지만, 개발자들이 그들끼리 이 문제를 해결할 수 있도록 여유를 줘야 한다. 경력 많은 전문가와 신참을 한데 묶어서 조를 짜주는 게 좋다. 이유는 다 알 수 있을 것이다.

다른 문화적 변화들처럼 동료 평가도 시간이 걸린다. 하지만 경영진의 지지와 참여가 성공으로 이어질 수 있다.

최고 개발자들은 고품질 코드가 동료 평가의 요점이라는 점에 감사할 것이고 당신의 신참 코더들은 더 경력이 많은 프로그래머들이 코드를 보고 능력을 향상시킬 수 있을 것이다. 그리고 오류 디버깅에 자원 활용을 줄이고, 똑같은 인력으로 프로세스에서 더 많은 일을 처리함으로써 시간과 돈을 절약할 수 있을 것이다.

하지 않을 이유가 있을까?

*Jonathan Hassell은 컨설팅 기업 82벤처스 경영자다. ciokr@idg.co.kr 
추천 테크라이브러리

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.