|
Code Review를 통한 소프트웨어 품질 향상
김성 sung21.kim@samsung.com｜삼성소프트웨어멤버십 회원으로 활동한 바 있고, 현재는 삼성전자에서 근무하고 있다. Enterprise Architecture 개발과 관련된 실무 경험을 갖고 있으며 소프트웨어 공학 분야에 많은 관심을 갖고 있다.
옛말에 ‘소 잃고 외양간 고친다’라는 속담이 있는데 소프트웨어 개발 관점에서 봐도 우리에게 중요한 교훈을 준다. 비용 측면에서 볼 때 소 잃고 외양간을 고치는 것과 소 잃기 전에 외양간을 고치는 것 중 어떤 것이 더 적은 비용이 들까? 당연히 소 잃기 전에 외양간을 고치는 것이다. 소를 잃고 외양간을 고치는 것은 소를 잃은 것에 대한 손실뿐만 아니라 외양간이 다 부서져서 많은 부분을 고쳐야 하기 때문에 소를 잃기 전 외양간의 일부를 고치는 것보다 더 많은 비용을 지불해야만 한다. 외양간이 가지고 있는 조그마한 잠재 결함을 미리 발견하고 고칠 수 있다면 소가 뛰어 나가며서 엄청나게 큰 문제로 확대되고 번져가는 것을 막을 수 있을 것이다.
결함과 비용 관계
소프트웨어에서도 마찬가지로 개발 시 조그마한 잠재 버그가 다른 모듈에 영향을 주어 다른 모듈로 문제가 번져가면서 의존성을 갖는 모든 소프트웨어의 버그로 이어질 수 있다. 이러한 버그를 개발 단계에 해결하지 못하고 출시되어 사용자가 이용하는 시점에서 발생한다면 엄청난 비용을 사용해 문제를 해결해야 할 뿐만 아니라 신뢰도도 땅에 떨어지게 될 것이다.
버그의 발생시점에 따라 해결 비용에 많은 차이를 가지게 된다. 개발 시점에 버그가 발생되면 소스 코드 수정만으로 끝난다. 그러나 테스트 시점에 발생하게 되면 소스 코드 수정 이외에 패키징하는 작업, 테스트 팀으로 릴리즈하는 작업, 테스트 작업, 버그를 리포팅하는 작업, 디버깅하는 작업 등 많은 부가적인 작업이 필요하게 된다. 또한 출시되어 사용자 이용 시점에 발생된 버그는 소스 코드 수정과 테스트 시점에 버그 발생으로 수행했던 작업 이외에 업그레이드를 위한 릴리즈 작업, 업그레이드 작업 등 더 많은 부가적인 작업이 필요하게 된다. 이러한 부가적인 작업은 품질을 떨어뜨리며 비용을 증가시킬 뿐만 아니라 사용자로부터 소프트웨어에 대한 신뢰를 잃게 된다. 그러므로 얼마나 결함을 빨리 발견하느냐가 비용에 밀접한 관련을 갖게 된다.
‘결함의 발견시점이 빠를수록 비용은 낮아진다.’
결함을 걸러내는 필터
소프트웨어 속에 숨어 있는 결함을 완벽하게 찾아 낼 수 있을까? 결함을 완벽하게 찾아내는 것은 불가능하다.
우리는 보통 결함을 찾는 데 테스트에 많은 부분을 의지하고 있다. 그러므로 프로젝트에서 테스트와 유지보수가 차지하는 비중이 높을 수밖에 없다. 테스트에 많은 부분을 의지할수록 결함을 발견하는 시점이 늦어지고 그 결과 결함 해결 비용이 높아지게 된다. 테스트라는 것은 필터와 같아서 모든 문제를 찾기에는 한계가 있다.
이러한 한계를 극복하기 위해 다양한 방법으로 다양한 값으로 테스트를 진행해 보지만 테스트 케이스가 커버할 수 있는 수준에 한계가 있는 것이다. 또한 동일한 테스트 케이스로 반복적으로 똑같은 테스트가 이뤄지므로 찾아지지 않는 결함은 계속해서 찾기 힘들게 된다.
.jpg)
<그림 1> 결함을 걸러내는 필터
그렇다면 테스트에만 의지할 것이 아니라 테스트 전에 결함을 찾을 수 있는 방법을 찾아야 한다. 결함을 걸러내는 필터를 구현 단계에서도 적용한다면 더 많은 필터가 생겨나게 되고 그 결과 더 많은 결함이 걸러지게 될 것이다. 그러한 방법 중의 하나가 바로 코드 리뷰이다. 개발자가 개발한 코드를 리뷰해 코드에 잠재된 결함을 빨리 찾아 해결하므로 결함이 확대되고 옮겨가는 것을 막을 수 있어 추가적인 결함의 증가를 막을 수 있다. 뿐만 아니라 결함을 빨리 찾아내어 적은 비용으로 쉽게 결함을 해결할 수 있게 된다.
코드 리뷰가 하나의 필터 역할을 하게 되면 많은 결함을 찾아 해결할 수 있다. 최종적인 결과물에 대한 결함의 수를 많이 줄여줄 수 있으며 이를 통해 품질의 확보와 비용을 줄일 수 있게 된다.
코드 리뷰에 따른 결함 수와 비용
10명의 개발자가 개발한 10,000라인의 프로젝트의 코드 리뷰 전과 후의 결과를 비교해 보면 <그림 2>와 같다.
.jpg)
<그림 2> 코드 리뷰와 결함수의 관계
코드 리뷰를 하지 않고 사용자에게 배포된 소프트웨어는 194개의 버그가 발견되었지만 코드 리뷰를 하고 사용자에게 배포된 소프트웨어는 32개의 버그만이 발견되었듯이 코드 리뷰의 유무에 따라 버그의 수에 많은 차이를 보이고 있다. 이 결과와 같이 코드 리뷰에서 미리 많은 버그를 발견하고 해결함으로써 테스트 시점과 사용자 이용 시점에 발생하는 버그가 상대적으로 줄어들게 되는 것이다.
또한 버그의 발생 시점은 버그를 해결하는 비용과 밀접한 관련이 있다. 늦게 발견된 버그일수록 버그를 해결하는 데 더 많은 비용이 들어가게 된다. 그러므로 코드 리뷰 전에 수치적으로 162개에 이르는 추가 발생 버그는 사용자 이용 후 발생해 전 단계에서 발생한 버그를 해결하는 비용보다도 더 많은 비용을 지불해야 한다.
코드 리뷰와 비용의 관계를 보면 <그림 3>과 같다. 코드 리뷰를 하지 않게 되면 요구분석과 설계 단계에서 발생하는 결함의 수는 코드 리뷰를 할 때보다 상대적으로 적은 결함이 발생하지만 개발, 테스트, 릴리즈 단계에서는 더 많은 결함이 발생한다. 또한 리뷰를 하지 않게 되면 결함이 발생하는 기간도 길어지게 되어 비용이 계속적으로 증가하는 원인이 된다. 그 결과 비용 증가뿐만 아니라 프로젝트 지연으로도 이어질 수 있다.
.jpg)
<그림 3> 코드 리뷰와 비용의 관계
코드 리뷰 성공 요소
코드 리뷰의 성공 요소로는 체크리스트, 충실한 준비 과정, 데이터 수집이 있다. 구현된 코드에서 정확하지 않은 부분에 대해서는 요구사항을 다시 체크한다. 로직에 사용한 알고리즘을 적절하게 사용했는지 체크해야 한다. 그리고 적용된 메커니즘이 시스템에 맞게 정확하게 적용되었는지, 코딩 룰을 지켰는지, 확장성은 있는지, 구조는 적절한지 등 코드에 대해 여러 측면에서 최대한 많은 검토가 이뤄져야 한다. 체크할 항목을 미리 정해놓고 체크리스트를 만들어 수행 때마다 체크하는 형태로 진행하는 것도 효과적이다. 체크리스트 항목은 Requirement, Algorithm, Data Structure, Performance, Usability, Extensibility, Scalability, Best Practice, Coding Guideline 준수, 프로그램 구조의 적절성, Library Function의 적절한 사용, Code Reuse 가능성 등의 항목으로 필요한 사항을 정리해 체크리스트 만들어 진행할 수 있다. 충실한 준비 과정을 위해 일관성, 적정성, 함축성이 적용된 산출물을 준비하고 충분한 검토 시간을 할당해 코드 리뷰를 진행해야 한다. 데이터의 수집은 각 단계에 소요되는 시간, 결함의 형태에 따른 결함 수, 보완에 소요된 시간 등의 정보를 수집한다. 이를 통해 체크리스트를 보완하고 리뷰 프로세스를 개선해 표준화하는 데 활용하게 된다.
코드 리뷰 방법
코드 리뷰에는 사람 구성에 따라 세 가지 형태가 있을 수 있다. 첫째는 혼자 하는 Self Code Review이다. 이는 개발자가 당일 개발한 소스 코드를 매일 개발자 자신이 검토하는 방식을 의미한다. 매일 자신의 코드에 대한 리뷰를 통해 하루 동안 자신이 작업한 소스가 논리적으로 이상은 없는지를 평가하고 문제점을 찾는다. 적은 비용으로 효율적으로 결함을 발견하고 조기에 문제를 해결할 수 있다. 혼자서 리뷰를 진행하므로 시간적 제약도 없어 자신이 리뷰 가능한 시간대에 코드 리뷰를 진행할 수 있는 장점이 있다. 또한 문제가 발생하면 바로 해결해 반영하므로 문제에 대한 빠른 해결과 반영이 가능하다.
두 번째는 2명이 함께하는 Peer Code Review이다. 이는 개발된 소프트웨어를 짝이 되는 개발자와 함께 리뷰하면서 서로의 의견을 교환하고 함께 잘못된 부분을 찾아 수정하는 작업을 하게 된다. 상대방을 통해 혼자 작업할 때 보지 못했던 버그를 많이 발견할 수 있는 것이 장점이다.
세 번째는 여러 사람이 함께하는 Team Code Review이다. 이는 정기적으로 코드 리뷰 회의를 통해 개발한 코드에 대해 리뷰한다. 리뷰 결과에 대해 의견을 교환하고 소스 코드의 수정과 추가가 이뤄지게 된다. 개발된 소프트웨어를 상위 개발자와 함께 리뷰한다면 상위 개발자의 조언을 얻고 함께 잘못된 부분을 찾고 해결할 수 있어 효율적이다. 코드 리뷰의 목적은 적은 비용을 들여 효율적으로 결함을 발견하고 조기에 문제를 해결하는 데 있으므로 현재 자신의 환경에 맞는 적절한 방법을 선정해 진행하는 것이 좋다.
Formal Inspection
여러 명의 참가자가 프린트물 또는 프로젝터를 이용해 진행한다. 참가자는 ‘moderator’ 또는 ‘controller’가 있으며 회의를 조직하고 리뷰를 컨트롤하며 분쟁을 조정하는 역할을 수행한다. 모든 참가자는 리뷰를 준비하기 위해 사전에 문제를 읽고 참석하게 되며 각 참석자는 고유의 롤이 할당되는데 리뷰를 하는 사람은 결함이 발견되면 자세한 사항을 남겨놓게 된다. 남겨놓는 정보는 위치, 심각성, 타입(알고리즘, 문서화, 데이터 사용, 에러 처리), 에러가 발생한 시점(개발자 시점, 디자인 시점, 요구사항 시점) 등의 정보를 주기적으로 리뷰하며 상세히 남기게 된다. 이렇게 발견된 결함은 Rework 작업을 통해 수정하고 반영한다.
.jpg)
<그림 4> Formal Inspection Process
효과적인 코드 리뷰가 되기 위해서는 다른 정보에 대한 통계도 갖는 것이 좋다. 리뷰 시 남겨 놓은 리뷰 시간, 리뷰율, 문제 발생 개수에 대한 통계는 리뷰를 통해 얻은 효과를 확인 할 수 있으며 다음 리뷰에 대한 방향을 제시한다. 효과적인 리뷰를 위해서는 교육이 필요하며 이것은 추가적인 시간과 비용을 요구한다.
Over-The-Shoulder
개발자가 코드를 변경하는 작업을 지켜보면서 키보드와 마우스를 이용해 다양한 파일을 열고 변경된 부분을 가리키고 설명하면서 리뷰를 진행한다. 리뷰를 진행할 때 툴을 이용한다면 변경된 내용에 대해 쉽게 확인할 수 있고 이전 버전과의 차이점을 쉽게 비교할 수 있다. 데스크톱 공유 소프트웨어를 통한 코드 리뷰는 원거리에서도 코드 리뷰를 가능하게 한다. 그러나 리뷰하는 사람이 서로 원거리에 떨어져 있다면 스케줄을 서로 맞춰야 하고 전화로 커뮤니케이션해야 하는 어려움이 따른다. 특별한 절차가 없고 많은 사람들이 리뷰에 참여하지 않으므로 실행이 간단하고 누구든지, 어디에 있던지 교육 없이 실행할 수 있다. 리뷰를 서로 떨어져 진행한다면 함께 리뷰해 얻을 수 있는 이점을 잃게 되므로 가능하면 같은 장소에서 함께 코드 리뷰를 진행하는 것이 좋다.
.jpg)
<그림 5> Over-The-Shoulder Process
Email-Pass-Around
일반적인 코드 리뷰 방식으로 오픈소스 프로젝트에서 선호하는 방식이다. 전체 파일과 변경된 내용은 작성자에 의해 패키징되어 리뷰하는 사람에게 메일로 전달되고 리뷰하는 사람은 작성자나 다른 개발자와 토의하고 질문해 변경할 내용에 대해 제안하고 파일을 실험한다. 버전 컨트롤 시스템의 도움을 받는다면 버전 컨트롤 시스템에 체크인함으로써 체크인 코드와 관련된 사람에게 메일을 보내는 등의 편리한 기능을 이용할 수도 있다.
파일을 얻어오기 위한 시간은 더 걸리지만 Over-The-Shoul der와 같이 쉽게 가능하다.
.jpg)
<그림 6> Email-Pass-Around Process
Pair-Programming
버그 찾기와 지식 전달이라는 두 마리 토끼를 한꺼번에 잡을 수 있는 매우 효율적인 방법이다. 리뷰하는 개발자는 소스 코드에 깊이 있게 관여하게 되며 그 과정에서 버그를 함께 찾고 해결하면서 서로의 지식이 전달된다. 또한 이러한 과정은 자동적으로 개발자간의 소스 백업으로 이어진다. 그러나 가장 큰 불만은 시간이 너무 많이 소요된다는 것이다. 또한 같은 장소에 있어야 한다는 장소적 제약이 크다. 그러나 처음에는 두 사람이 하나의 작업을 같이 하므로 시간이 많이 소요되는 것처럼 느껴지지만 발생 가능한 결함을 미리 찾아 해결하거나 결함이 발생하지 않도록 함으로써 프로젝트 후반부에서는 발생하는 결함 수를 줄이고 이를 통해 프로젝트 전체 기간의 관점에서 시간을 더 줄일 수 있다. 어떤 개발자는 Pair-Programming을 싫어하는데 그 이유는 누가 파트너가 되는지가 큰 비중을 차지하기 때문이다. 그러므로 협업이 잘 될 수 있는 환경과 서로간의 성격도 충분히 고려해야 한다. 코드 리뷰에 가장 많은 시간이 소요되지만 가장 많은 결함을 찾을 수 있는 방법이다.
Tool-Assisted
코드 리뷰에 특화된 툴을 사용하는 방법이다. Automated file gathering 툴은 버전 컨트롤 시스템과 통합(integration)되어야 하며 현재 버전과 이전 버전의 차이를 쉽게 얻어올 수 있어야 한다. 툴은 이미 체크인된 버전과 체크인되지 않는 버전을 확인 가능해야 한다. Combined display가 있는데 리뷰하는 사람과 개발자는 특정 파일과 라인 수를 이용해 이야기할 수 있도록 돕게 된다. 그러므로 툴은 파일을 디스플레이하고 이전 이후 파일의 차이를 볼 수 있어야 한다. Automated metrics collection 툴은 리뷰에 대한 정확한 측정치를 수집하므로써 리뷰 프로세스에 대한 이해와 평가를 가능하게 한다. 툴을 통해 시간당 리뷰 라인 수(kLOC/hour, inspection rate), 시간당 오류 검출률(defect/hour, defect rate), 오류 분포(defects/kLOC, defect density) 정보를 얻을 수 있다.
참고 자료
1. Jason Cohen, Best Kept Secrets of Peer Code Review, 2006
2. 인사이트, 익스트림 프로그래밍 2판, 2006
3. WILEY, Architecting Enterprise Solutions, 2004
