한빛출판네트워크

코드 베이스에 수정을 가할 때, 수정이 적용되고 난 이후의 리스크를 고객의 입장에서 변경사항을 바라본다면, 우리는 전체 변경 프로세스를 압축적이고, 견고한 프로세스를 만들 수 있습니다.

코드 리뷰를 진행할 때, 구현된 코드와, 테스트와 문서 중 어느 것을 먼저 살펴보시나요? 이 글을 다 읽고 나면, 우리는 여러분이 이것들 중 어느 것도 먼저 살펴볼 것이 아니라고 대답할 것이라 확신합니다.

최근 몇 년 동안, 저는 상용 프로젝트, 오픈 소스 프로젝트, 그리고 학교에서 진행하는 학기 프로젝트의 수많은 개발자를 위해 수 천 번의 코드 리뷰를 진행하였습니다. 몇몇의 예외를 빼고는, 압도적인 수의 개발자들은 저의 코드리뷰가 그들의 코드 퀄리티를 향상시켜줄 것이라 생각했었습니다. 분명히 의미 있는 목표이지만, 저의 주요한 우선순위는 아니었습니다. 그래서 저는 대부분 리뷰를 받는 사람들이 제 목표가 코드의 퀄리티 향상이 아니라는 것을 알고는 놀라는 것을 종종 보곤 했습니다.

제품 테스팅으로 시작하기

처음으로 제가 요구하는 것은 실제 운용환경과 가장 유사한 환경에서 코드가 돌아가는 것을 보고 싶다고 요구하는 것입니다. 몇몇 경우에는 이 말은 실제 환경에 코드를 배포하는 것을 의미하기도 하고, 개발 환경에 배포하는 것을 의미하기도 합니다. 비디오나 스크린 샷으로 대체가 가능하기도 했지만, 이러한 경우는 제 개인적으로 정말 최후의 경우였습니다.

이 환경에서부터 저는 새로운 기능이나 버그 수정이 제대로 이루어졌는지 확인해보기 위해 간단한 데이터를 입력하고 프로그램을 천천히 살펴봅니다. 이러한 데이터가 전혀 없거나, 제가 예상해서 입력해야 한다면 정말 심각한 경우라고 할 수 있습니다. 만약 입력 데이터의 일부가 남아있거나 간헐적으로 관리되고 있다면, 실제 코드가 배포된 이후에도 실제 상황을 잘 견딜 수 있는 테스트를 했다라고 가정하기 어려운 경우입니다.

가끔 실제 상황에 근접한 테스트 데이터가 있는 경우가 있었는데, 이 경우에는 개발자의 편의를 위해 매우 적은 수로 유지되고 있었습니다. 위와 같은 상황에서는 저는 더 실제 상황에 유사한 데이터 셋을 자동 생성하고, 문제가 발생할 수 있는 상황을 잡아내는 방안을 찾아낼 수 있었습니다. 그러나 정반대의 상황도 있는데, “lorem ipsum”과 같은 테스트용 데이터에서는 환상적으로 동작하지만, 이와 같은 표준화된 데이터가 아닌 데이터를 입력으로 주어지는 케이스를 테스트한다면, 제대로 구현이 되었는지 확인하는 것은 정말 불가능에 가까웠습니다.

사용자의 입장에서 변경사항에 접근하기

이 단계까지 왔다면, 우리는 실제 상황과 거의 유사한 환경과, 실제 상황과 거의 유사한 (그렇다고 믿는) 입력 데이터를 갖고 돌아가는 코드를 가지고 있을 것입니다. 이 단계 이전까지는 변경된 코드 내역을 리뷰 하는 것을 전혀 신경 쓰지 않았었을지도 모르지만, 리뷰를 받는 사람들은 이 단계까지 오는 것 만으로도 많은 버그, 실수, 그리고 예상치 못했던 논리적 구멍들을 매울 수 있는 해결책을 얻을 수 있었습니다.

이제부터는 내가 고객이라면 뭐부터 하려고 할까? 라는 게임을 진행합니다. 이 역할놀이를 위해서는 저는 보통 개발자에게 답을 얻으려 하지 않고, 버그 리포트나 새로운 기능에 대한 노트, 아니면 이 새로운 코드를 수행하는 사람으로써 문제가 무엇인지 이끌어 내려 노력합니다.

이 같은 배경지식에서, 저는 제품을 사용해본다면 어떻게 될까 생각을 해봅니다. 일반적인 유스 케이스, 코너케이스, 문제를 일으킬 만한 실제와 같은 경우를 최대한 많이 고안합니다. 문제를 발생하는 경우, 최악으로 동작하는 경우, 저를 혼란스럽게 하는 경우를 기록해 둡니다.

변경 내용을 배포할 때 리스크를 알아내기

제가 리뷰를 계속 진행하는 것에 있어서 이 과정들이 메이저 이슈를 만들어내지 않는 다면, 이제 처음으로 코드를 살펴봅니다. 가장 처음 살펴보는 부분은 diff 명령어를 사용했을 때 빨간색으로 나타나는 부분, 해당 라인을 수정 혹은 삭제한 부분을 의미합니다. 두 번째로 살펴볼 때에는 설정 파일, 전역 객체의 수정과 같이 새로운 에러를 발생시킬 만한 부분의 변경 사항에 해당하는 영역의 추가된 코드가 다른 시스템 영역에 영향을 미치지는 않는지 확인합니다.

만약 리뷰하는 변경 내역이 완벽하게 독립적이지 않을 때에는, 어떻게 리뷰를 진행해야 할지는 약간 특이합니다. 간단한 케이스는 손수 테스트를 해보아서 변경 내역이 적용되더라도 우리가 원하는 대로 동작하는지 확인합니다. 그리고 나서는 관련되어 있는 자동화 테스트를 살펴보고, 커버리지가 적당한지 살펴보게 됩니다. 더 복잡한 경우에는 리뷰를 받는 사람과 더 많은 의사소통을 통하여 이 변경 사항을 테스트하는 계획이 적절한 결과를 낼 수 있을지 미리 확인하는 작업을 통해 간단한 변경 내역의 리뷰와 같은 프로세스로 진행할 수 있을지 확인합니다.

변경 내역이 독립적인 경우에는, 더 편하지만 그래도 잠재적인 위험이 있음직한 부분을 살펴봅니다. 현업에서는 이러한 과정이 실질적인 위협(유저 입력, 시스템I/O, 이메일 알람, 웹 서비스 콜 등) 지점을 의미합니다. 사용자 입장에서 중요한 기준점도 체크리스트로 만들어서 리뷰 과정 중에 적용합니다.

이 모든 것을 종합해서 특정 변경 사항에 대하여 위험 요소를 평가하는 제 나름의 경험에서 우러나온 방법을 적용합니다. 이 방법은 테스트를 얼마나 소중이 다루는지, 에러 핸들링, 문서화, 전체 코드 퀄리티등을 얼마나 세심하게 다루는지 알게 됩니다. 대부분의 안전한 변경 사항은 몇몇 간결한 질문을 통해서 리뷰가 끝나지만, 더 에러를 발생시킬만한 변경 사항에 대하여는 면밀한 검사를 통해서, “이렇게 하는 것에 안전한 방법이 없을까?”라고 계속해서 의문을 갖고 리뷰를 진행하게 됩니다. 

코드를 리뷰 하더라도, 제품에 집중해야 합니다.

코드 퀄리티와 같은 이슈를 생각하기 전에 제품의 외적인 품질과 관련이 있는 답해보아야 할 질문이 몇 가지 있습니다.

• 이 변경이 정말 사용자의 진짜 문제를 해결해 줄까?
• 이 해결책이 확실한가? 아니면 적당히 적절한가?
• 이 변경 내역이 다른 방법과 비교해서 상대적으로 좋다고 어떻게 알 수 있는가?
• 이 변경의 결과로 어떤 새로운 문제가 발생할 수 있으며, 이 문제들은 어떻게 처리할 것인가?
• 이 변경 내역이 어떤 문제를 쉽게 해결할 수 있도록 도움을 줄 수 있는가?
• 이 변경 사항이 지금 진행중인 유지보수 비용에 연관이 있는가? 있다면 이 유지보수 비용은 무엇인가?

단순히 위의 질문들을 물어보는 것을 통해서 코딩 스타일, 디자인 패턴, 리팩토링의 기회 등과 같이 에너지를 투자 해야 하는 일에 몰두하기 전에 리뷰를 쉽게 할 수 있는 요소들을 발견 할 수 있습니다. 이 과정은 또 여러분의 프로그램을 사용할 사람들에게 매우 관심이 있을 부분에 초점을 맞추게 할 수도 있습니다.

이 리뷰 과정은 거의 자세한 코드 리뷰과정을 통해서 높은 확률로 좋은 코드를 유지하는 것을 보장해줍니다. 또한 코드리뷰를 통해 리뷰 한 부분은 또 다른 리뷰를 낳기 보다는 코드를 깔끔하게 정돈해주기도 합니다.

그러니 새로운 변경사항에 대해서 무엇을 먼저 리뷰 해야 할까요? 답은 간단합니다. 사용자가 필요로 하고, 사용자를 만족시킬 수 있는 부분에서 시작하고, 그 부분에서부터 코드를 살펴보면 됩니다.

*****

원문 : Building a better code review process

번역 : 김준호