본문 바로가기

마이크로소프트웨어

스크럼(Scrum) 기반의 프로젝트 관리

ALM 모듈에서 가장 쉽게 적용할 수 있으나, 가장 큰 효과를 볼 수 있는 것 중의 하나가 코드 리뷰이다. 소프트웨어의 품질을 보장하기 위한 활동은 테스팅, 일일 빌드, 프레임워크의 사용, 개발 패턴 등과 같이 수 없이 많은 방법들이 있다. 그 중에서 개인적으로 생각하건데, 코드 리뷰만큼 적은 투자로 큰 효과를 얻을 수 있는 기법은 없는 것 같다. 이 글에서는 코드 리뷰에 대한 몇 가지 기법을 정리하고, 더불어 그 적용 방법을 소개하기로 한다.

조대협 bwcho75@gmail.com, http://bcho.tistory.com|자바스터디 운영자이며 한국 자바 개발자 협회(JCO)의 초대 부회장. 자바 개발자 사이트(http://www.javastudy.co.kr)의 초대 시삽을 맡았으며 현재 BEA Systems Korea를 거쳐 Oracle Korea Consulting에서 Principal Consultant로 근무하고 있다. 주요 분야는 SOA, EAI, EP와 같은 Enterprise Architecture와 TP Monitor, J2EE WAS와 같은 미들웨어이며, 이 글에서 소개되는 ALM과 같은 소프트웨어 개발 프로세스에 대한 컨설팅도 수행하고 있다.

코드 리뷰의 시초는 Fagan에 의해 소개된 코드 인스펙션에서 기인한다. 소프트웨어의 개발이 끝난 후에, 전문 인스펙션 팀이 정해진 프로세스와 패턴에 따라서 코드를 검증하고 Defect를 찾는 프로세스를 코드 인스펙션이라고 한다.

코드 리뷰란 ‘코드를 실행하지 않고 사람이 검토하는 과정을 통해 코드 상에 숨어있는 잠재적인 결함(Defect)을 찾아내고 이를 개선하는 일련의 과정’으로 정의한다. 테스팅의 범주에서는 정적인 분석에 속한다. Formal한 코드 리뷰 기법일수록 결함의 발견에 집중하고 소프트웨어 개발 주기의 후반에 위치하지만, Lightweight한 코드 리뷰 기법은 결함의 발견뿐만 아니라, 같은 로직을 여러 관점에서 생각하는 아이디어 회의나 주니어 개발자에게로의 지식 전달 등의 부가적인 목적들도 함께 가지고 있다.

코드 리뷰 스펙트럼

코드 리뷰 기법을 나누는 방법은 크게 얼마나 정석적이고 프로세스적(정형성)이냐에 따라서 Formal/Lightweight 방법으로 나눌 수 있고, 오프라인(Offline)에서 직접 커뮤니케이션을 하는지 또는 메신저, 이메일이나 기타 자동화된 코드 리뷰 도구를 사용하는지에 따라 온라인 리뷰와 오프라인 리뷰로 나눌 수 있다.

먼저 정형성에 따라서 대표적인 리뷰 방법을 나열해보면 다음과 같다(코드 리뷰 기법 중에는 Pair Programming이 종종 언급되곤 하지만, 본인의 개인적인 견해 상 엔터프라이즈 애플리케이션 개발에서 Pair Programming을 실제로 적용하는 것은 매우 어렵다고 판단되므로, 코드 리뷰 스펙트럼에서는 제외한다).

코드 인스펙션

코드 인스펙션(Code Inspection)은 코드 리뷰 기법 중에서 가장 정형화된 패턴의 기법이다. 전문화된 코드 리뷰팀이 시스템이 어느 정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다. 인스펙션 팀은 크게 네 가지 역할을 가지고 구성된다.

[인스펙션의 역할]
● Moderator
Moderator는 인스펙션 팀의 실제적인 매니저로 생각하면 된다. 인스펙션 팀과 그 대상이 되는 코드를 작성한 개발팀간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다. 또한 인스펙션에 대한 프로세스 정의와 산출물의 정리를 담당한다. 예를 들면, 인스펙션 팀이 계정 업무를 인스펙션을 하다가 업무에 대한 지식이나 코드가 왜 이렇게 짜여져 있는지에 대한 자료가 필요하다면 Moderator가 요청해서 담당 개발자를 섭외하거나 소프트웨어 설계 문서 등을 받아다가 인스펙션 팀에 전달한다.

또는 인스펙션된 결과에 대해 테스트가 필요할 때, 테스팅 환경을 확보하고 인원(DBA나 벤더 엔지니어)을 섭외하는 것도 Moderator의 역할이다. 필요하다면 고객이나 개발자와 함께 인스펙션 미팅을 주선하고 주최하는 역할도 가진다. 가장 중요한 역할 중의 하나는 인스펙션이 언제 끝날 것인지(Exit Criteria)를 정의하는 것이다.

● Reader
Reader는 각종 산출물들을 읽고, 인터뷰 등을 통해 전체 시스템을 이해해 인스펙션 팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 지시하며, 시스템에 대해 팀 내에서 가장 많은 도메인 지식을 갖는 사람이다. Reader는 시스템의 큰 흐름과 구조를 잘 이해하고 있어야 하고, 상황에 따라 문제가 발생할 수 있는 지점을 미리 예측해낼 수 있어야 한다. 실제 인스펙션은 이 Reader의 방향성에 따라 인스펙션을 진행하게 된다.

● Designer/Coder
Designer나 Coder는 Reader가 지시한 방향에 따라 코드를 검증하고 잠재적인 결점의 발견 및 권장 수정 방안을 만들어 낸다.

● Tester
Tester는 인스펙션이 진행 중인 모듈에 대해 테스트를 수행하고 결점을 찾아내는 역할을 수행하며, 이외에 Designer나 Coder가 권장한 수정 코드 안에 대한 검증을 비롯해 실제 업무 개발자가 수정해 온 코드에 대한 검증 작업을 수행한다.

이처럼 인스펙션 팀은 위의 네 가지 역할을 가지고 있으며    <그림 2>와 같이 6단계로 진행된다. 그럼 그 각각의 단계를 살펴보자.

[인스펙션 6단계]
● Planning
전체 코드 인스펙션에 대한 계획을 수립한다. 기간, 대상, 종료 조건(금액 기준, 목표 TPS를 성취하는지, 시간에 따른 종료 조건 등). 그리고 인스펙션 팀이 이때 셋업(SET UP)된다.

● Overview
이 단계에서는 인스펙션 팀에 시스템과 구성 제품 등에 대한 교육이 이뤄지고, 팀원 간의 역할이 정의된다.

● Preparation
인스펙션을 하기 위한 사전 준비 단계로 각자의 역할별로 필요한 문서를 습득해서 이해하고 필요하다면 인터뷰도 진행한다. 또 이 단계에서는 필요에 따라서 툴(테스팅 툴이나 profiler, Application Performance Monitoring 도구)과 환경(독립된 테스트가 요구되는 경우 테스트 환경을 구축)이 마련된다.

● Meeting(Inspection)
각자의 역할에 따라서 인스펙션을 수행한다. 인스펙션을 통해 결함을 발견하고, 모든 결함은 기록된다. 기록된 결함은 실 업무 개발자에게 전달되어 FIX되도록 하고 필요에 따라서는 권장 수정안을 전달하기도 한다.

● Rework
보고된 결함을 수정한다.

● Follow-up
보고된 모든 결함이 수정되었는지 확인한다.

팀 리뷰

팀 리뷰는 코드 인스펙션보다 좀 덜 정형화되었지만 그래도 일정한 계획과 프로세스를 따른다. 코드 인스펙션 프로세스의 단계(Planning, Overview, Preparation 등의 사전 준비 단계는 생략) 역할은 중복되거나 생략될 수 있는데, 발표자(Author)와 Moderator는 필수적으로 구성된다. 리뷰 시간에는 발표자(코드를 만든 사람)가 코드에 대해 설명하고 팀원은 결함이나 개선안을 찾는다.

Moderator는 리뷰의 주제를 선정해 리뷰를 진행하고, 리뷰에서 나온 의견을 정리해서 Action Item으로 기록한다. 이 Action Item들은 프로젝트 관리자가 실제 프로젝트 Task로 관리해야 한다(일정에 반영되어야 함). Moderator는 프로젝트 관리자(PM이나 PL)가 될 수도 있으나, 팀 내에서 기술적인 실력이 가장 좋은 시니어 개발자가 그 역할을 맡는 것을 권장한다. 일주일에 한 번 정도 팀 리뷰를 수행하는 것이 좋으며, 특정 모듈이나 기능이 완료되는 시점(Short Release)에 수행하거나, 테스트 결과를 가지고 리뷰하는 것도 좋은 방법이 된다.

필자의 경우 프로젝트를 수행할 때, 일주일에 한 번 정도 팀 리뷰를 진행했으며 Short Release에 의해 완성된 부분이나 Risk가 비교적 큰 부분이라고 판단하는 부분에 대해 팀 리뷰를 진행하도록 개발자에게 지시했다. 리뷰 과정에서 나온 의견은 팀 Wiki 페이지에 ‘코드 리뷰 결과’라는 분류를 따로 만들어서 관리했고, 각 의견은 TASK로 생성되어 스케줄에 포함되었다.


 
웍쓰루(Walkthrough)

웍쓰루는 단체로 하는 코드 리뷰 기법 중에서 가장 비정형적인 방법 중에 하나이다. 발표자가 리뷰의 주제와 시간을 정해 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 갖는다.

주로 사례에 대한 정보 공유나 아이디어 수집을 위해 사용될 수 있다. 개발을 위한 프로세스에서보다는 ‘Bug 사례에 대한 회의’와 같은 정보 공유 성격에 유리하다. 유일하게 발표자만이 리뷰를 주관하고 발표하는 역할을 가지며, 다른 참여 인원들은 아무런 책임이나 역할을 가지지 않고 자유롭게 의견을 개진한다. 웍쓰루는 정기적으로(주일에 한번) 진행할 수도 있으며, 또는 정보 공유나 아이디어 수집이 필요할 경우 비정기적으로도 진행할 수 있다(정기적으로 진행하는 것이 참여율이나 집중도가 더 높다).
 
Peer Review or Over the shoulder review

피어리뷰나 Over the shoulder Review는 2~3명(주로 2명)이 진행하는 코드 리뷰의 형태이다. 코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 결함을 발견하는 방법이다. 사전 준비 등이 거의 필요 없고, 필요할 때마다 자주 사용할 수 있는 리뷰 방법이다.

주로 시니어 개발자(사수)가 주니어 개발자를 멘토링할 때 사용할 수 있으며, 주니어 개발자에 대한 교육과 함께 주니어 개발자가 양산한 코드에 대한 품질을 관리할 수 있다. 그러나 이 기법은 시니어 개발자의 리뷰 역량에 따라서 결과물의 품질이 달라질 수 있고, 시니어 개발자의 시간 투여량이 많은 만큼 시니어 개발자의 참여도가 떨어질 수 있다(형식적으로 될 수 있다). 그래서 프로젝트 관리 관점에서 Peer Review에 대해서도 프로젝트 스케줄 상의 Task로 잡아주고, 하나의 독립된 업무로서 시간과 노력을 투자할 수 있도록 해야 한다.

실제로 예전 프로젝트에서 신입 사원에게 비교적 난이도가 높은 모듈의 개발을 맡겨야 할 상황이 있었고, 그때 이 Peer Review를 진행하도록 했다. 결과적으로 만족할 만한 품질을 얻었다. 하지만, 시니어 개발자에게 리뷰에 대해 Task를 지정하고 스케줄링을 했음에도 불구하고, 시니어 개발자에게는 결코 적지 않은 워크로드가 되었던 경험이 있었다. 그러므로 팀원 간의 실력 편차와 난이도에 따른 시간 배분과 함께 경험적인 작업량 측정이 필요하다(3~4일 해보면 실제 작업량에 대한 예측이 좀 더 정교해진다).

Passaround
코드 리뷰 스펙트럼에는 포함시키지 않았지만 사용되는 경우가 있어서 소개한다. Passaround는 번역하자면 돌려보기이다. 온라인보다는 오프라인 위주로 진행되는 리뷰인데, 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해 등록하면, 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다. 특정 장소에 모여서 같은 시간에 진행해야 하는 기존의 리뷰 방식과는 달리 시간과 장소에 구애받지 않는 방식으로, 리모트에서 작업하는 팀의 경우 유리한 리뷰 방식이지만 반대로 소유권(Ownership)이 애매해서 원하는 결과가 나오지 않는 경우가 많다. 또한 실시간이 아닌 비동기적인 커뮤니케이션으로 인해 커뮤니케이션 속도가 매우 느리다는 단점도 가지고 있다.

이를 방지하기 위해서는 참석자들의 업무 역할에 코드 리뷰라는 역할이 명시적으로 지정되어야 한다. 필자가 일했던 글로벌 회사의 경우에는 버그 수정이나 제품 기능 개선의 경우 개발팀에서 버그 수정과 개선만을 맡는 개발자가 개발팀에 속해 있었기 때문에 원활한 Passaround 리뷰가 가능했고 이슈(버그) 트랙킹 시스템(Atlassian사의 JIRA와 같은)과 소스 코드 Viewing system(Atlassian사의 Fisheye)이 많은 도움이 되었다.

지금까지 간단하게나마 코드 리뷰의 기법에 대해 살펴봤다. Formal한 리뷰(코드 인스펙션) 등에 대한 설명이 많은 것은 꼭 Formal한 리뷰가 좋아서라기보다는 정형화되어 있기 때문에 그만큼 프로세스에 대한 설명이 많이 필요하기 때문이다. 회사의 성격(SI, 게임, 임베디드, 인하우스 개발, 오픈소스 등)이나 팀의 구조나 성숙도에 따라서 리뷰의 기법은 변형되어 적용되어야 한다.

언제 어떤 코드 리뷰 기법을 사용해야 하는가?
그러면 이런 많은 코드 리뷰 기법 중에서 어떤 기법을 사용해야 할까?

코드 인스펙션

코드 인스펙션의 전제는 전문성을 가지고 있는 인스펙션 팀이 일정한 프로세스와 패턴에 따라 개선안을 찾는 작업이다. 즉, 고도로 훈련됨 팀과 기간이 필요하고 어느 정도 개발이 완료되어 있는 인스펙션 대상(시스템)이 있는 것을 전제로 한다. 인스펙션의 시기는 시스템이 개발되어 있는 시점인 릴리즈가 유용하다.

필자는 두 번의 인스펙션을 권장하는데, 개발 초기에 비기능적인 구현을 끝낸 경우 1차 인스펙션을, 그리고 개발이 끝난 후 시스템 테스트(성능, 확장성, 안정성 등)를 수행하는 것이다.

1차 릴리즈는 주로 비기능적이고 Risk가 높은 부분을 구현하는 단계인데, 이 구현체는 전체 시스템 아키텍처의 큰 틀이 되며, 추후 개발에도 이 아키텍처는 크게 변경되지 않는다(1차 릴리즈 다음에 변경하려면 후반으로 갈수록 많은 리소스가 소요된다). 그래서 1차 릴리즈 후에 정밀 인스펙션을 해서 아키텍처의 안정성을 검증할 필요가 있다.

개발 후반의 시스템 테스트는 주로 비기능적인 요건(성능, 안정성 등)에 대한 성능 테스트가 이뤄지는 단계이므로 테스트 시나리오가 미리 잡혀 있고 테스터와 테스트 시나리오가 명확하게 정의되어 있다. 그러므로 인스펙션을 수행하기 용이하며 최종 점검이라는 관점에서 매우 유용하다.

그럼 인스펙션을 수행하는 주체는 누가 좋을까? 전문 SI사 Task Force를 운영해 프로젝트를 돌아다니면서 인스펙션을 수행할 수 있고, 여러 개의 솔루션을 인하우스 개발하는 업체들은 QA 조직내에 자체적으로 인스펙션 팀을 운영하는 것을 권장한다. 그 외의 일반 업체(갑)나 기업의 경우 인스펙션 팀을 운영하기보다는 인스펙션 프로세스를 전체 개발 프로세스와 프로젝트 비용 산정에 포함하고 SI나 벤더 컨설팅을 활용하는 것을 권장한다.

인스펙션의 결정 주체는 주로 PMO(Project Management Office)와 AA(Application Architect)가 되는 것이 좋다. 대체로 개발 주체 조직 외부에서 인력을 데려 오고, 여러 팀이 함께 인스펙션에 참여해야 하며 일정에 대한 조정과 인스펙션 결과에 대한 반영이 필요하기 때문에 프로젝트 관리 조직 측면에서 접근하는 것이 바람직하다.

팀 리뷰
팀 리뷰는 각 개발 유닛에서 활용하기 좋은 기법이다. PL (Project Leader)의 역량 아래 수행할 수 있으며, 팀원이 리뷰어가 되기 때문에 팀 단위에서 활용하기가 매우 좋다. 일주일에 한 번 정도, 한 시간 정도 리뷰를 정기적으로 수행하도록 하며, 시니어 개발자나 PL이 리뷰 대상 모듈을 선정하고 개발자에게 리뷰를 준비하도록 한다. 리뷰는 발표자가 리드하도록 하고, 리뷰에서 나온 의견을 Action Item으로 잡아서 PL이 발표자의 스케줄로 조정해주는 작업이 필수적으로 따라야 한다.

팀 리뷰에서 권장하고 싶은 사항은 위에서도 잠깐 언급했지만 위키와 같은 문서 공유 시스템을 이용해 반드시 리뷰의 결과를 남기도록 하고, 리뷰의 결과는 Task Management의 Task로 연결되어야 한다. 리뷰되고 반영된 내용은 그냥 넘어가지 않도록 하고, 재 테스트를 통해 반영 내용을 반드시 검증하도록 한다.

웍쓰루(WalkThrough)
일종의 아이디어 회의 정도로 보면 되며, 비정기적으로 언제나 개최할 수 있다. 팀 리뷰처럼 PL이나 시니어 개발자가 중재하지 않기 때문에 구성원들의 의욕이 낮을 경우 효과가 매우 낮다. 개발팀보다는 QA나 운영팀에서 장애 사례나 버그 수정 사례 등의 정보 교환 목적으로 사용하는 것이 좋다.

Peer Review
신입 개발자 교육이나, 해당 제품 또는 기술에 전문적인 지식이 없는 경우에 Knowledge Transfer(지식 공유)와 품질 유지를 위해 유용하다. 대신 리뷰어의 Task 부담이 가중되기 때문에(예상하는 것보다 많이, 심하게는 50%에 육박할 경우도 있음) 리뷰어에 대한 스케줄 배려가 필요하다.

요약

본인의 경험에 비춰보면 팀 리뷰가 가장 효과가 높다. Peer Review는 팀원 간의 실력 편차가 클 때 탄력적으로 운영했고, 엔터프라이즈 시스템(Enterprise System)과 같이 난이도가 높은 시스템의 경우 인스펙션의 효과가 비교적 크다. 비록 비용이 소요되지만 잘못된 아키텍처로 인해 전체 품질이 떨어져서 비즈니스에서 손해를 보거나 쓸 데 없이 하드웨어 증설을 통한 비용을 생각하면 훨씬 낮은 금액이 아닌가 싶다.

효과적인 코드 리뷰를 막는 요인들

코드 리뷰에서 가장 힘든 점은 한마디로 내가 만든 코드를 남이 잘못되었다고 이야기하는 순간이다. 리뷰의 주요 목적은 결함의 발견과 개선 방안 강구이다. 흔히 농담 삼아서 이 과정을 ‘창던지기’라고 이야기하는데, 발표자는 리뷰어로부터 많은 질문과 공격을 당하기 때문이다. 그래서 실제로 인스펙션을 해보면 개발자는 인터뷰를 당하는 것에 대해 마치 취조 당하는 느낌을 가지게 될 수도 있고 그로 인해 방어적으로 행동할 수도 있다.

그래서인지 팀 리뷰의 경우 감정 싸움으로 번지는 경우가 허다하다. 팀 리뷰나 인스펙션의 경우 리뷰를 중재하는 사람이 있기 때문에, 리뷰어가 아이디어나 결함에 대한 의견을 자유롭게 개진할 수 있도록 해야 하며, 반대로 발표자가 인신공격을 받지 않도록 중재하는 기능도 필요하다. 이건 어떤 프로세스나 시스템으로 될 수 있는 일이 아니라 ‘사람 사이의 관계’에서 발생되는 일이기 때문에 ‘문화’의 변화가 필수적이다.

또한 위에 언급한 대부분의 리뷰 기법들은 리뷰와 그에 대한 후속 처리에 시간과 사람이 필요한 일이기 때문에 프로젝트 운영 관점에서 시간과 리소스에 대한 배려가 이뤄져야 한다.

경험상으로 팀 리뷰가 팀에 자리 잡기 위해서는 좋은 리더가 있다 하더라도 최소한 한 달 정도(통상 2개월)의 기간이 필요하다. 다시 말해 이는 급하게 할 일은 아니라는 것이다.

출처 | 아이마소