1 Code Review는 왜 필요한가?
Code Review에 대한 사람들의 의견이나 진행 방법은 천차만별입니다. 많은 경우 개발자가 짬을 내서 한다는 인식이 많았습니다(적어도 한국에서는). 이번 포스팅은 Code Review에 대한 최근의 동향을 정리해서 개인적인 결론을 내보려고 합니다.
먼저 현대 Code Review가 어떤 의미인지 생각해 보겠습니다. 많은 사람들이 알고 있는 Code Review의 이점은 좋은 Code를 만들고 유지보수성을 높이고 오류가 적은 코드를 만드는 것입니다. 이러한 이점 이외에도 Code Review는 다른 목적 또는 이유를 내포하고 있습니다. 이 목적을 이해 한다면 많은 개발자들이 지금 보다는 조금더 적극적인 태도로 Code Review에 참여 할 것입니다. Code Review는 ‘Code 작성자가 Code를 전적으로 책임지는 것이 아니라 팀이 함께 책임지는 것’입니다. Code Review의 가장 큰 목적인 공동 책임에 대한 이해가 부족하다면 Code Review가 잘 진행되지 않거나 형식적으로 진행될 것입니다. 그럼 자세히 이야기 해 볼까요?
1.1 Code Review 그 동상이몽(同床異夢)에 대해서
얼마 전까지만 해도 필자인 저도 Code Review라고 하면 그 과제 또는 그 Code를 잘 알고 있는 선배/동료가 문제가 발생하지 않도록 가이드 해주는 것이라 생각했습니다. 조금 딴 이야기 같지만 전설처럼 전해지는 이야기 중에 ‘I’ 뭐 비엠 회사의 메인프레임의 핵심 코드는 몇명의 개발자만이 유지 보수가 가능해서 그 몇명이 핵심 개발자로 남아 있었고 자연사(?)의 걱정이 늘 있었다고 합니다. 예전의 Code Review는 이런 분들이 탁탁 집어 주는 신묘한 것이라고 생각했었죠. 그 정도의 경지(?)는 아니더라도 Code를 잘 아는 개발자의 리뷰가 Code Review라는 의견이 지배적이었습니다. 2000년도 초반 Au*****의 Database 서버를 수천대에서 수백대로 줄여준 전설의 DBA 이야기에 등장하는 그런 분들이 필요한 것이 Code Review라는 생각이었죠.
오랜 시간 동안 Expert들의 도움이 필요했었고 앞으로도 그럴 것입니다. 이렇게 Domain Expert Group이 주도해서 진행되는 Code Review가 최신 Code Review로 넘어 오면서 Readability Group이 주도하는 Code Review로 변경이 되고 있습니다. Readability는 Domain 지식이 없더라도 Programming 언어에 대해 잘 알고 있어서 Code의 구성이 이해 하기 쉽게 작성 되었는지 판단 할 수 있는 Group을 말합니다.
2 Readability와 Code 작성 원칙
최근에는 고정된 팀이 하나의 거대한 프로그램을 오래동안 유지 보수 하는 것이 개발의 표준 모델이 아닌 경우가 종종 있습니다. 팀의 구성이 지속적으로 변경되는 것이 가장 큰 이유라고 생각됩니다. 미국 실리콘밸리는 노트북 들고 옆건물 다른 회사로 옮겨가는 것이 이직이라는 우스갯 소리가 있는걸 보면 개발자의 이동이 꽤나 빈번한 것 같습니다. 개발자의 이동이 수시로 발생하지 않는다고 하더라도 신규 인력 합류하는 경우도 있습니다. 팀의 구성이 지속적으로 변경이 된다면 Source Code의 유지보수성이 높어야 합니다. 그렇지 않다면 프로그램이나 프로젝트의 유지에 많은 어려움이 따르기 때문입니다. 인력 구성의 변화 뿐 아니라 Pair Programming등의 기법을 위해서는 Code의 유지보수성이 높아야 하는 것도 새로운 기술 트렌트임은 틀림 없는 사실입니다. Code의 유지 보수성을 높이기 위해서는 어떻게 해야 할까요? 다음과 같이 정리 해 보았습니다.
- 어느 누구나 빠르게 코드를 ‘이해’할 수 있어야 한다.
- 어느 누구나 빠르게 코드를 ‘수정’할 수 있어야 한다.
이 두가지 정리가 제가 개인적으로 생각하는 최근의 Code Review의 목적이자 방법이라고 생각합니다. 높은 유지보수성을 가지는 코드가 적합한 세상이 되었죠. Code Review에 대한 정의, 유지보수정에 대한 생각은 이견이 있을 수 있습니다. 코멘트로 의견 주시는것 대환영 합니다.
그럼 이제 Code Review의 목적이자 방법을 하나씩 자세히 이야기 해 보겠습니다.
2.1 누구나 빠르게 ‘이해’할 수 있는 Code
앞에서 정리한 ‘어느 누구나’는 전세계 어느 누구나가 아닌 해당 개발 언어를 개발할 수 있는 개발자를 말하는 것입니다. 누구나 빠르게 ‘이해’하기 위한 전제가 Readability(가독성)과 Coding Convention(코딩 규칙) 입니다. Readability와 Coding Convention 두가지는 Code를 이해할 수 있는 Frame을 제공하여 보다 쉽게 Source Code를 이해할 수 있게 해줍니다. 하지만 Readability와 Coding Convention은 심리적 저항감이 꽤 높습니다. 개발 경력이 많고 적고를 떠나서 개발자들은 자신만의 습성이 있기 때문입니다. 저도 아직까지 받아 들이기 힘든(사실 딱히 이유는 없는) 몇 가지가 있는데 예를 들면 Single line 코드를 가진 if문에 {} 사용하는 것과 tab step을 space 2또는 4로 지정하는 것입니다. 헝가리언 표기법부터 Coding Convention을 받아 들인 저에게는 매우 넘기 힘든 심리적 저항선입니다. (당시에는 Single line 조건문은 {}을 사용하지 않고 Indent는 tab으로 통일되어 있었습니다.)
if (false == test_condition)
printf("This is not good!\n"); // Incorrect
if (ture == test_condition) {
printf("This is good!\n"); // Correct
}하지만 개인이 자유롭게 개발할 때는 상관 없겠지만 팀이 함께 개발 할때는 팀에서 정한 규약을 지켜야 합니다. Readability와 Coding Convention은 그 조직 또는 프로젝트가 가지고 있는 언어의 습관이 공통의 규칙이기 때문에 Code를 이해할 수 있는 기초를 제공해 주기 때문입니다. 변수 선언 방식이나 함수 선언 방식 등은 그 조직의 언어 패턴이나 약어가 있는 것입니다. Readability와 Coding Convention은 절대적인 정답은 없습니다. 해당 조직의 구성원(특히 초기 구성원)의 패턴에 맞춰 정의 하면 됩니다. 절대적인 정답이 없는 것이기 때문에 맞다, 틀리다의 문제가 아닌 선택의 문제입니다. 초기에 Coding Convention을 정할때 많은 논란이 있습니다. 절대적인 정답이 없다는 말을 꼭 명심하고 다툼이 아닌 합의로 도출되어야 합니다.
2.2 누구나 빠르게 ‘수정’할 수 있는 Code
누구나 쉽게 이해하는 Source Code는 쉽게 이해 할 수 있다고 생각됩니다. 너무 생소한 방법은 아니기 때문이죠. 하지만 누구나 빠르게 수정할 수 있는 Source Code를 만드는 방법은 머리속에 잘 떠오르지 않습니다. 누가나 빠르게 수정할 수 있도록 하려면 어떤 방법이 있을까요? Source Code를 수정하는 것은 개인의 역량에 따라 많이 좌우 되기 때문에 어떤 방법이 있을지 아리송하기도 합니다.
제가 생각하는 누구나 쉽게 수정할 수 있는 방법은 수정된 Source Code를 빠르고 자동적으로 확인할 수 있는 방법과 수정을 하는 방향성에 대한 공통의 이해를 만드는 방법 2가지 입니다. 두가지를 각각 시스템적, 제도적이라고 할 수 있습니다. 두가지 방법에 대해서 이야기해 보겠습니다.
2.2.1 자동화 테스트 또는 테스트 주도 개발론 활용
Source Code 수정 이후 의도대로 동작하는지 자동화 테스트를 진행하는 것입니다. GitHub 등의 Plug-in을 사용하여 Build Test 및 TC가 동작할 수 있게 할 수 있을 것입니다. GitHub과 같은 시스템을 사용하면 관리되는 Source branch에는 테스트 완료된 Commit 만 merge될 수 있습니다. 테스트 자동화는 Code 수정 후 발생할 수 있는 Side effect를 시스템적으로 막아주는 방식입니다. Gatekeeping을 통한 사후처리로 수정된 코드의 오류를 검출 하는 방법입니다. 조금은 수동적인 방식이지만 효과는 매우 좋습니다. 다만, 사후 처리라는 점 때문에 Cost가 높은 방법입니다.
테스트 자동화와 누구나 쉽게 수정할 수 있는 코드가 어떤 상관이 있을까요? 테스트 자동화를 통해 정상 동작하지 않는 수정 된 Source Code가 Main branch에 합쳐지는 것을 방지할 수 있습니다. 기능 테스트뿐 아니라 Code Complexity, White Box, Black Box 테스트 등으로 통해서 Code Quaility도 함께 검사합니다. 수정이 필요한 Feature, Error를 누구나 수정 후 자동화 테스트를 통해서 적용 여부가 자동으로 결정 되고 Source Code의 품질을 담보할 수 있다면 일정에 맞는 또는 기여를 원하는 개발자가 쉽게 Source Code를 수정하고 적용할 수 있을 것입니다.
2.2.2 Design Pattern과 Architecture Style 활용
자동화 테스트로 사후처리가 되는 것도 좋지만 사전에 통일된 방식으로 코드가 작성이 될 수 있는 규칙이나 가이드 라인이 존재 한다면 누구나 빠르게 수정할 수 있는 Code가 될 수 있을 것입니다. Readability와 다르게 Writability라는 용어가 잘 사용되지 않는 것은 Code 작성은 규격화 하기 어렵기 때문일 것입니다. 아주 구체적인 Source Code 작성을 규격화 할 수는 없지만 정해진 흐름을 강제 하거나 큰 틀을 정해 놓고 활용한다면 Source Code 작성이 어느 정도 표준화가 될 수 있을 것입니다.
우리가 익히 알고 있는 Design Pattern과 Architecture Style을 활용하는 것이 하나의 방법일 것입니다. Code 작성자에 따라 구현의 디테일을 다를 수 있지만 Design Pattern과 Architecture Style을 활용 한다면 함수나 클래스의 목적에 따라 일정한 틀 안에서 구현될 수 있기 때문에 다른 개발자가 빠르게 Code를 파악하고 일정한 규칙이나 틀안에서 수정할 수 있을 것입니다.
Design Pattern과 Architecture Style을 사용한다고 하더라도 내부 로직은 개인 별로 다르기 때문에 공산품을 만들어 내는 느낌보다는 Guide를 잡아 주는 것이라고 생각하면 됩니다. 요리 가이드 북을 보고 만든다고 해서 모두의 음식이 똑같이 나오지 않지만 비슷한 느낌이나 요리의 큰 틀이 바뀌지 않는 것이라고 생각하면 됩니다.
3 사람의 문제가 아니라 ‘Code 문제’, 그리고 공동의 책임
Code의 유지보수성을 높이기 위한 두가지 방법인 누구나 빠르게 ‘이해’ 할 수 있고 ‘수정’할 수 있는 방법을 알아 보았습니다. 제가 제시한 방법들이 누구나 빠르게 ‘이해’ 하고 ‘수정’할 수 있는 방법으로 완벽하지는 않을 수 있겠지만 코드의 유지보수성을 높이기 위한 좋은 가이드가 될 것이라 생각합니다. 마지막으로 현대 Code Review의 가장 중요한 철학에 대해서 이야기 해보도록 하겠습니다. 앞의 두가지 원칙은 방법에 조금 더 초점이 맞춰져 있다면 지금 이야기할 철학은 Code Review를 우리가 왜 해야 하는지를 정의 하는 것입니다. 이 철학을 이해한다면 바쁘다고 Code Review를 대충하는 것이 얼마나 큰 손해 인지, 다양한 개발자(다른팀, Readability 그룹 등)들의 Code Review를 내용을 모른다고 의미 없다고 생각하는 행동들이 얼마나 위험한지 인지하게 될 것입니다.
Code Review는 ‘Code’를 리뷰하는 것이고, Review에 참여한 모든 사람들은 작성자를 바꾸려는 것이 아니라 Source Code를 공동의 이해에 맞도록 조정하는 것이다.
이 명제는 매우 중요한 명제 입니다. Code에 대한 수정 요청이나 오류 지적을 Code의 문제로 보는 것이 아니라 ‘자신에 대한 공격’으로 받아 들이는 경우가 많습니다. Code 작성자가 야기한 문제이기 때문에 그런 반응을 보이는 것은 어찌 보면 자연스러운 일이지도 모르지만, 그런 생각이 굳어 지면 Code Review는 기피해야 할 제도처럼 굳어지게 됩니다. 그렇게 되면 Code Review가 형식적으로 흐를 수 밖에 없고, 의미 없는 Gate keeping이 되고야 말겠죠.
현대적 Code Review의 또 다른 철학은 아래 문장 처럼 정의 할 수 있을 것입니다.
Code Review는 개발자가 작성한 Code에 대해서 작성자의 잘못을 여러 Reviewer가 발견하는 것이 목적이 아니라, Review에 참여한 사람들이 Code에 대해서 함께 논의 하고 Review한 Code를 공동 책임을 지는 과정이다.
이번 포스트에서 전달하고자 하는 한가지의 문장이 있다면 바로 이 문장입니다. Code Review는 개발자가 혹시 했을지 모를 실수를 막는 1차원적인 것이 아니라 Source Code를 프로젝트에 참여한 다양한 이해 당사자가 함께 책임 지는 것입니다. 다음편 포스트에서 이야기 하겠지만 Code Review는 프로젝트에 직접 관련 있는 개발자만이 참여하는 것이 아닙니다. Readability Group이 아닌 다른 프로젝트의 개발자들도 참여가 필요합니다. 자세한 내용은 다음 포스트를 읽어봐주세요.
다시 주제로 돌아 가면 Code Review의 진정한 의미와 힘은 잘못을 찾아내는 과정과 책임 함께 나누는 것입니다. 이 점이 인지가 된다면 Code Review는 형식적으로 넘어가는 과정이 아닌 Review를 받고 나면 안심이 되는 과정이 될 것입니다.
4 마치며
Code Review는 문화라고 합니다. 좋은 원칙이 조직에 스며들어 모두가 원칙을 따를때 문화가 될 수 있습니다. 이를 위해서는 모두에게 도움이 되는 과정이라는 점을 인지할 수 있어야 할 것입니다. 이번 포스팅에 이어서 다음 포스팅에서는 Code Review를 어떻게 해야 하고, 왜 그렇게 해야 하는지를 구글의 사례와 관련 논문들을 통해서 확인해 보겠습니다.
※ 본문에 사용된 이미지는 모두 https://pixabay.com/을 통해서 다운로드 받은 무료로 사용할 수 있는 이미지입니다.