개발을 하다 보면 흔하게 접하는 단어 코드 리뷰. 자주 접하다 보니 코드 리뷰 문화에 관심이 생겼는데, 현재 제가 다니는 회사에서는 코드 리뷰를 따로 진행하고 있지 않아서 백명석 님의 코드 리뷰 강의를 듣게 되었습니다. 짧은 강의였지만 코드 리뷰를 하는 이유와 하는 방법들에 대해 자세히 배워 볼 수 있는 시간이었습니다.
비록 지금 당장 사내에서 코드 리뷰를 진행할 수 있는 짬밥(?)이 안되지만, 시간이 흘러 제가 좋은 리뷰를 해줄 수 있는 리뷰어의 실력을 갖췄을 때 꼭 진행해야겠다는 생각이 들었습니다. 그럼 코드 리뷰가 뭔지 알아볼까요?
코드 리뷰란?
한 명 또는 여러 명의 개발자가 본인이 만든 코드나, 다른 팀원이 만든 코드를 서로 점검해주고 피드백을 해주는 과정을 일컫습니다. 피드백이란 품질 문제, 아키텍처 속성 개선, 개발 표준 등에 대한 의견이 될 수도 있고, 좋은 코드에 대한 긍정적인 피드백이 될 수도 있습니다.
코드 리뷰의 핵심은 단순히 사내에서 코딩 스타일을 일관되게 하는 것에 그치지 않고, 코드 리뷰에 참여한 모두가 다 같이 성장하는 것에 초점을 둬야 합니다.
코드 리뷰를 해야 하는 이유🤗
소프트웨어의 비용의 80%는 유지보수 비용이라고 합니다. 사실상 저도 실무에 투입되었을 때, 기존 코드가 있어서 그걸 분석하는 것보다는 새로 만드는 게 편할 것 같다는 생각을 종종 하곤 했습니다. 기존에 코드가 있다면, 그걸 만든 개발자가 무슨 의도로 코드를 작성했는지에 대한 의문점도 해결해야 하기 때문입니다.
사람마다 코드를 짜는 스타일이 너무나도 다르기 때문에, 사내 혹은 같은 팀원끼리는 어느 정도 코드를 표준화시킬 필요가 있습니다. 예를 들어 들여 쓰기의 크기, 파일과 변수의 명명규칙 등이 있습니다.
하지만, 너무 세부적으로 표준을 정하는 것은 역설적인 효과를 낳을 수도 있기에 조심해야 합니다.
만약 코드 리뷰가 문화로 잡혀있다면, 팀원들의 코드를 자주 볼 수 있게 됩니다. 자연스럽게 코드가 표준화되는 현상을 겪게 될 것 같습니다. 코드 리뷰를 해야 하는 또 다른 이유 중 하나는 SW의 규칙을 예로 들 수 있을 것 같습니다.
SW의 2가지 규칙
1. 현재 SW가 현재 사용자의 현재 요구사항을 만족시키는가?
2. 지속적으로 변화하는 요구사항을 수용할 수 있나?
극단적인 예시로 현재 동작하지만 고칠 수 없는 SW와 고칠 수 있지만 동작하지 않는 SW가 있을 때 독자분들은 무엇을 선택할 건가요? 저는 당연히 후자를 선택할 것 같습니다. 지금 당장은 동작하는 SW가 좋겠지만, 추후 발전 가능성을 보았을 때는 후자이기 때문입니다.
혼자만 자기 코드를 알고 있다면, 지금 당장 소프트웨어가 돌아가더라도 잠재적인 문제가 있어서 추후 장애가 날 확률이 높습니다. 혹여 잘못된 방식으로 계속해서 코드를 짜게 된다면 나중에는 돌이킬 수 없게 될지도 모릅니다.
만약 코드 리뷰를 진행했다면 모든 사람이 리뷰어가 되어 코드를 보게 되고 이러한 과정을 거치게 되면 조기에 버그를 발견할 가능성이 훨씬 높아지게 됩니다. 이밖에도 코드 리뷰가 가져다주는 장점은 많습니다. 어떤 것이 있을까요?
코드 리뷰의 주목적👩👩👦
- 앞서 언급한 바와 같이 버그와 장애 같은 품질 문제를 조기에 발견할 수 있습니다.
- 아키텍처 속성 개선을 위한 코드 개선이 가능합니다.
- 코드 리뷰에 참여한 모든 사람들에게 코드, 해결책 등과 관련된 지식 공유에 기여할 수 있습니다.
- 버그를 발견했을 때, 코드를 짠 사람의 잘못만이 아닙니다. 코드 리뷰를 진행 시에 같이 발견 못한 팀원들도 잘못이 있다고 인지하게 되므로 팀원 모두가 책임감을 가지게 됩니다. 지속적으로 진행하다 보면 팀에서 일어나는 모든 일을 공유하게 되어 결과론적으로 팀워크가 향상됩니다.
- 동일한 역할을 수행하는 중복 코드를 빨리 발견하고 이미 만들어진 코드를 재사용할 수 있습니다.
※ 코드 리뷰는 단순히 버그를 사전에 발견하거나 문제점을 찾는 목적을 넘어서 전체적인 조직의 역량을 강화하는 중요한 역할을 합니다.
코드 리뷰가 어려운 이유😞
코드 리뷰가 가져다주는 장점이 정말 많지만 아직 많은 회사에서 진행하고 있지는 않다고 합니다. SI 회사에서나 초기 스타트업 등 빠르게 프로젝트를 쳐내야 하는 기업에서는 아무래도 상황적인 측면에서 힘든 것 같습니다.
이 밖에도, 코드 리뷰를 요청한 저자가 본인 생각에 멋지다고 생각하는 PR을 보내지만 리뷰어들은 왜 멋지지 않은가에 초점을 맞춰 장황한 이유를 작성할 수도 있습니다. 코드에 대한 비판을 자신에 대한 비판으로 이해할 가능성이 있어서 조심해야 할 부분입니다.
저도 처음에는 코드 리뷰 자체가 선배 개발자분들한테 제가 만든 코드를 검사(?) 맡는 느낌이라고 생각했었습니다. 대부분의 피드백이 잘못된 부분에만 집중할 거라는 생각이었던 것 같습니다. 강의에서도 이 부분에 대해 조심해야 할 부분이라며 강조했습니다. 피드백은 잘못된 부분에만 집중하는 것이 아닌, 진심 어린 칭찬을 적절하게 섞는 것도 중요합니다.
진정한 칭찬은 리뷰어가 감시자가 아닌, 도와주려는 팀 동료라는 것으로 보여서 모든 팀원들은 긴장감을 낮추게 되고 코드 리뷰에 적극 참여할 수 있게 됩니다.
또한, 온라인으로 코드 리뷰를 진행하는 상황이라면 모든 의견을 글로 작성하는데 어려움이 있고, 시간적인 측면에서도 비효율적일 수 있습니다. 각 상황에 맞게 적절한 방법을 채택해 진행해야 할 것 같습니다.
코드 리뷰 효율적인 방법👍
첫 번째로, 리뷰어들을 위한 설명을 주석으로 코멘트로 남겨서 리뷰어들의 시간을 절약하게 해야 합니다. 대부분의 코드 리뷰는 깃허브 같은 도구들을 이용해서 진행을 합니다. 이해가 되지 않는 부분들을 직접 찾아가서 물어보기에는 많은 시간이 소모되기 때문에, 리뷰를 요청한 저자는 적절한 코멘트로 리뷰어들의 이해력을 높여주면 좋습니다.
두 번째로, 리뷰어에 팀원 모두를 포함시키면 좋습니다. 당연한 이야기지만 많은 사람들이 볼 수록 버그를 더 잘 찾아낼 수 있는 건 물론이거니와 많은 사람이 보기 때문에 저자는 대게 더 잘하려는 마음이 들어 조금 더 신경 써서 작성하게 됩니다.
세 번째로, 코드 리뷰를 일처리에 있어 높은 우선순위에 두어야 합니다. 저자는 리뷰가 종료될 때까지 대기하고 다음 일처리를 진행하지 못하는 상황일 수 있기 때문입니다.
네 번째로, 저자는 작고 범위가 좋은 PR을 올려야 합니다. 복잡도가 높은 PR은 리뷰어들에게 많은 부담이 되므로 세분화시켜서 작성하는 것이 좋습니다.
마지막으로, 리뷰의 범위를 PR의 범위를 넘어가는 건 좋지 않습니다. 잘 알려주고 싶은 마음에 PR의 범위를 벗어난 코드까지 지적한다면 저자는 어쩌면 리뷰어의 생각보다 더 많은 곳을 수정해야 한다는 압박감을 가질 수도 있습니다.
피드백 방법🔨
- 절대 '너'라는 단어를 사용하지 않습니다. 저자의 방어 유발을 일으킬 가능성이 높습니다.
- 건설적인 피드백을 해야 합니다. 코드 리뷰는 누가 잘하고 못하고를 판가름하는 것이 아니라, 개발자들이 그들의 실수에서 배우고 역량을 증대하도록 동기 부여하는 것입니다.
- 리뷰의 핵심은 '무엇이 코드를 나아지게 하는가'이지, '누가 그런 아이디어(잘못)를 냈는가'가 아닙니다.
- 피드백을 조심스럽게 표현하는 것이 제일 중요하고 명령이 아닌 요청으로 표현해야 합니다 - Nit 태그 사용(고치면 좋지만 아니어도 그만)
- 피드백은 의견이 아니라 원칙에 기반해야 합니다. 제안하는 변경과 변경의 이유를 모두 설명해줘야 합니다.
체크리스트📜
- 버그/장애 : 멀티쓰레드 환경에 적합한 데이터 구조체를 사용했는지? 경합 발생 가능성이 있는지? 등 장애가 날 확률이 있는지에 대한 체크가 필요합니다.
- 기능성 : 코드가 실제로 기대되는 일을 하는지와 선택한 해결책이 요구사항을 충족시키는지에 대한 확인이 필요합니다.
- 가독성/유지보수 용이성 : 특히 변수 이름이 실제로 나타내야 하는 것을 반영하는지에 대한 체크가 필요합니다.
- 테스트 : 테스트가 예외 경우를 모두 다루고 있는지에 대한 체크도 필요합니다. 대게 테스트를 성공한 사례만 기재했을 가능성이 있습니다.
- 자료구조 : 너무 많은 탐색, 잦은 정렬 등 필요 없는 코드에 대한 리뷰도 필요합니다.
- 성능 : 변경 사항이 성능 저하를 유발하지 않는지? 리소스를 효율적으로 사용했는지?
- 보안 : 암호화해야 할 데이터가 있는가? 등에 대한 보안적인 문제에 대한 체크가 필요합니다.
- 설계 : 객체지향의 원칙들을 준수하였는지? 기능 확장을 코드 수정 없이 할 수 있는지(OCP) 등에 대한 확인도 필요합니다.
간단 예시👀
👨👩👦👦 오픈채팅방 운영
취업을 준비하는 예비 개발자분들을 위한 질문&답변할 수 있는 공간을 만들었습니다. 취업과 이직을 하기 위해서 어떤 걸 중점적으로 준비해야 하는지부터 포트폴리오&이력서 작성법 등 다양한 질문들을 받고 답변을 드립니다. 참여하셔서 다양한 정보 얻고 가시면 좋을 것 같네요😁
참여코드 : 456456
https://open.kakao.com/o/gVHZP8dg
비전공 개발자 취업 준비방(질문&답변)
#비전공 #개발자 #취업 #멘토링 #부트캠프 #국비지원 #백엔드 #프론트엔드 #중소기업 #중견기업 #자바 #Java #sql
open.kakao.com
👨💻 전자책 출간
아울러 제가 🌟비전공자에서 2년만에 보안 전문 중견기업으로 이직 한 방법들을 정리한 전자책을 출간 하게 되었습니다. 어떤 걸 공부해야 하는지, 이직을 위해서 무엇을 준비해야 하는지, 제가 받았던 기술 면접 리스트 등 다양한 목차로 구성되어 있습니다. 또한, 구매 시 1:1 채팅을 이용하여 포트폴리오 첨삭을 도와드리고 있습니다. 🐕전자책으로 얻은 모든 수익은 유기견 센터 '팅*벨 입양센터'에 후원될 예정입니다. 관심 있으신 분들은 아래 링크를 참고해주세요😁
비전공개발자 2년만에 중견기업 들어간 방법 | 14000원부터 시작 가능한 총 평점 0점의 전자책, 취
0개 총 작업 개수 완료한 총 평점 0점인 Binco의 전자책, 취업·이직 전자책 서비스를 0개의 리뷰와 함께 확인해 보세요. 전자책, 취업·이직 전자책 제공 등 14000원부터 시작 가능한 서비스
kmong.com
마치며
지금까지 코드 리뷰에 대해 알아보았습니다. 제 블로그 소개글을 보시면 아시겠지만, 제가 블로그를 시작한 이유도 개발 선배님들이 만든 공유하는 개발 문화를 이어나가고 싶은 마음이 컸습니다. 블로그를 통해 기술과 정보를 공유하는 것도 좋지만, 이번 포스팅을 하면서 한편으로는 사내에서도 많은 커뮤니케이션을 해야겠다는 다짐도 들었네요. 이번 내용에 대해 조금 더 궁금하시다면 클릭 하셔서 강의를 수강해보시는 것도 좋을 것 같습니다.