사내 코드리뷰... 어떻게 하는게 맞는걸까요?

안녕하세요! 좋은 고민이네요 ㅎㅎ 저도 코드 리뷰를 자주하지만 상당히 어려운 것 같아요. 그래도 제가 하는 방식과 최근에 동료의 코드 리뷰 방식을 공유받은 내용을 알려드리면 도움이 될까 싶어 답변 남깁니다. 우선 저는 사내에 코드 컨벤션이 정리된 문서가 있습니다. 가령, 컴포넌트 구조는 어디에 어떻게 위치하며, 상태 관리는 어떤 식으로 하는지, 유틸성 함수들은 어떻게 관리하는지 등 대략적인 프로젝트 구조를 통일 시키기 위한 가이드라인이 존재해요. 그래서 이 컨벤션을 기준으로 리뷰를 많이 합니다. “컨벤션에 맞지 않는 코드 같은데 이렇게 개선하면 어떨까요?” 등의 코멘트를 주로 남겨요. 또 다른 기준은 리뷰하고 있는 코드에 크리티컬한 이슈가 될 만한 버그가 없는지 확인하는 것 같아요. 시간이 된다면 직접 코드 수정된 프로젝트를 로컬에서 구동해보고 로직을 따라가면서 제가 생각한 엣지 케이스 몇개를 대입해봅니다. 테스트 코드가 있다면 좋지만, 없는 경우도 많아서 이렇게 직접 테스트를 자주 하는 것 같아요. 그리고 크리티컬한 이슈가 발견되면 코멘트를 남겨요. 개인적인 기준도 분명 존재하지만 이건 권장사항 느낌인 것 같아요. 코드의 퀄리티를 높일 수 있는 방향이 있고 시간적 여유가 있다면, “이런 식으로 코드를 짜면 좀더 가독성/효율이 좋아질 것 같은데, 어떻게 생각하시나요?” 류의 코멘트를 자주 답니다. 물론, 배포를 바로 나가야되는 상황이라면 코드 퀄리티를 어느정도 포기하고 내보내기도 합니다. 저는 기준이라는게 각자 다르고, 개발자들도 사람이기에 코드도 다 다르다고 생각하는 입장을 가지고 있어요. 그래도 팀 차원에서 리소스를 아끼려면 코드가 어느정도 일관성이 있어야 하는데 이걸 정하기 위해 컨벤션 문서가 있다고 생각해요. 아직 사내에 컨벤션이 정해진게 없다면 동료분들과 정해보는 것도 좋을 것 같아요! 두번째 질문은 … 음 저도 아직 경험이 많지 않아서 잘 모르겠네요. 하지만, 연차와 상관없이 작업자가 고려하지 못한 부분을 코드 리뷰어가 (질문자님이) 충분히 찾을 수 있다고 생각해요. 그래서 그렇게 크게 주눅 들 필요가 없다고 생각합니다. 오히려 “내가 고려하지 못한 부분이 있는건가?” 싶으시면 그걸 그대로 코멘트 남겨주는것도 좋은 방법이라고 생각해요. 결론은 코드리뷰 힘든거 동의하구요. 그래서 기준이 있으면 좋긴합니다만, 그게 개인의 기준보다는 팀적으로 합의된 컨벤션 기준일 때 더 좋을 것 같다는 의견입니다. 추가적으로 리뷰를 남길때는 일관성있게 남기는 것도 중요한것 같습니다. 커리어리에도 코드리뷰 관련 좋은 글들이 있어서 몇개 첨부합니다. - https://careerly.co.kr/comments/79230 - https://careerly.co.kr/comments/79688 - https://careerly.co.kr/comments/81256 - https://careerly.co.kr/comments/80998 - https://careerly.co.kr/comments/78321 - https://careerly.co.kr/comments/73408 다른 분들은 어떻게 생각하시는지 저도 궁금하긴하네요 :)

# 첫 번째는, 코드 리뷰를 할 때 제 개인의 기준을 잣대로 활용해도 되는가? 입니다 저는 코드를 짤 때 저만의 기준이 존재합니다. 예를 들면, 코드를 읽다가 “이런 변수명은 지양해야지, 이렇게 함수 중첩이 되면 가독성이 떨어져, 이 함수는 하는 일이 너무 많은 것 같은데?” 라는 생각이 들면 코멘트를 작성하는 편입니다. 근데 문득 저만의 기준을 상대방에게 강요하고 있는 건가..? 하는 생각이 들었어요. 혹시 여러분들은 코드 리뷰를 할 때 기준이 있나요? 있다면 무엇을 기준으로 하시나요? 개인의 경험인가요? 모두가 코드 리뷰를 할 때 자신만의 기준은 있다고 생각해요. > “이런 변수명은 지양해야지, 이렇게 함수 중첩이 되면 가독성이 떨어져, 이 함수는 하는 일이 너무 많은 것 같은데?” 라는 생각이 들면 코멘트를 작성하는 편입니다. 라고 하셨어요. 제 생각에 글쓴이분의 리뷰하는 도구는 아무런 문제가 없다고 생각해요. 다만 우리가 리뷰를 왜 하는가?를 한번 생각해보면 좋을거 같아요. 제가 코드 리뷰를 할 때의 기준은 이래요. 1. 오류가 있는가? - 목적 : 서비스가 사용자에게 문제 없이 제공될 수 있는가 2. 유지보수하기에 좋은가? - 목적 : 서비스에 새로운 기능을 추가하거나 개선하는데에 좋은 구조 인가? 기본적으로 이 부분을 중점적으로 리뷰하는데요. 네이밍, 중복, 함수의 역할과 책임, 의존성, 가독성 등은 리뷰의 도구이지 목적은 아니라고 생각해요. 리뷰란 내가 가진 지식을 뽐내려고 하는 것이 아니고 동료의 코드를 지적하려고 하는 것도 아니라고 생각해요. 코드 리뷰의 최우선적인 가치는 프로덕트와 팀의 생산성이라고 생각해요. 개발 경력이 얼마이건 항상 이 부분을 놓치지 않는 것이 중요하다고 생각해요. 참고로 리뷰할 때의 글을 쓰면서 하나의 팁이 있다면 어떤 목적을 위해서 수정하는게 좋은지(오류 인지 구조 인지), 그리고 수정한다면 어떤 방식을 도입하는게 좋은지를 얘기하는 방식으로 하면 좋아요. # 두 번째는, 연차가 많으신 분의 코드를 리뷰 할 때 “내가? 해도 되는 건가?” 라는 생각이 들어요. 물론, 개발자라면 연차 상관없이 코드 그대로만 리뷰하는 게 맞지만, 리뷰를 하다 보면 “이게 맞는 건가? 내가 너무 시야가 좁은 것은 아닌가? 내가 고려하지 못한 다른 부분 때문에 코드를 이렇게 작성하신 게 아닐까?” 라는 생각이 자주 들어서 썼던 코멘트도 지우는 경우도 많거든요 ㅎㅎ 연차가 있으신 개발자 분들이 느끼기에 저연차 또는 갓 들어온 신입이 본인 코드에 리뷰를 달면 어떤 기분이신지도 궁금합니다. 물론, 현실적으로 연차가 많은 동료가 작성한 코드에 주니어 개발자가 리뷰를 할때에는 더 많이 고민하게 되는 것은 당연한 거 같아요. 1. 내가? 해도 되는 건가? - 위 첫번째 질문에 대한 제 생각의 기준에서는 해도 되는 가가 아니라 해야 된다 라고 생각해요. - 연차의 적고 많음이 아닌 바라보는 시각에 따라 오류가 발생할 수 있는 지점을 찾아낼수도 있고 더 나은 구조를 고안해낼 수도 있어요. 2. 이게 맞는 건가? 내가 너무 시야가 좁은 것은 아닌가? 내가 고려하지 못한 다른 부분 때문에 코드를 이렇게 작성하신 게 아닐까? - 이런 고민이 드는 코드를 만났다면 성장할 수 있는 기회에요. - 누가 봐도 이상한 코드라면 이런 고민을 하시지 않을거에요. - 즉, 명확한 답은 없지만 고민을 해볼 만한 코드를 만나면 이런 고민을 하게 되고 이때 더 다른 자료들도 찾아보고 스스로 생각도 해보고 하면서 성장할 수 있어요. - 또한, 첫 리뷰에서 바로 의미 있는 리뷰를 달 수 없다면 질문을 던지면서 서로 토론 하다보면 더 나은 구조가 나오기도 해요. 3. 연차가 있으신 개발자 분들이 느끼기에 저연차 또는 갓 들어온 신입이 본인 코드에 리뷰를 달면 어떤 기분이신지도 궁금합니다. - 이거 정말 중요해요. - 무슨 말이냐면 말이 아다르고 어다르다고 하죠. - 리뷰에 말투와 리뷰 대상등을 잘 고려해야해요. - 사람은 감정적인 동물이기에 감정적인 말투가 아닌 코드 그 자체만을 가지고 같이 코드를 개선해보자! 라는 느낌으로 리뷰를 하시는게 중요해요. - 리뷰 글을 쓰는 것도 스킬이에요. - 많이 해봐야 해요.

저도 처음 입사했을 때 정해진 컨벤션이 없어 많은 고민을 했었던 것 같습니다. 코드리뷰를 시작하면서 시니어 개발자분들께 많이 도움을 받았는데요. 먼저 답변을 드리자면, 1. 앞서 답변하신 분과 같이 컨벤션 같은 기준이 있다면 해당 문서가 기준이 되는 것이 좋습니다. 다만 개인적으로는 코드리뷰를 통해 컨벤션을 만들어간다고 생각하는데요. 코드리뷰라는 것이 단순히 코드를 평가하는 것이 아니라, 코드에 대해 논의하고 설명하는 과정속에서 구성원들의 코드 스타일을 맞추어간다고 생각해요. 그런것들이 컨벤션들이 만들어지기도 하고요. 저희 회사에서도 코드리뷰에서 나왔던 많은 피드백들이 컨벤션으로 자리잡은 것들이 많습니다 😀 2. 코드 리뷰할때 시니어 개발자들에게는 주로 질문성 코드리뷰가 많은 편인데요. 왜 이렇게 했는지 함수 구성이 어떻게 되는지, 단순히 구성원의 코드가 잘못했다가 아니라 질문하고 답변하는 과정속에서 구성원의 서비스 이해도가 좋아지는 것 같아요. 물론 시니어분들도 사람이시기에 실수가 있는 부분도 종종있어서 잡아드리면 다들 좋아하십니다 😄

일단 코드리뷰는 지적 혹은 가르침이 아닌 의견공유리는 측면으로 접근하는 것이 가장 올바른 형태가 될거같이요! 결국 최종 가치는 의견공유를 통해 시야를 넓히고 내가 생각지 못한 아이디어를 얻어 내는 등의 브레인 스토밍에 가깝다고 생각하거든요 ㅎ 1. 이 경우에는 기본적인 룰은 코딩 컨벤션, 린트 등으로 정의 해둔 내용을 기반으로 이런 부분에 있어서는 리뷰할 것들이 줄어듭니다. 의견공유 측면이라면 당연히 각자의 기준이 맞춘 시야를 공유 해주시는 것이 중요하기에 본인이 가진 기준대로 공유 해주시면 좋을 것 같아요! 단 본인의 기준을 계속 업데이트 해나가시면 동료 분들에게 도움이 될 수 있으면 더더욱 좋을 것 같습니다! 2. 말씀 드린데로 가르침이 아니라 의견공유측면으로 가는게 제일 좋습니다. 그렇기 때문에 올바른 코드리뷰 문화가 정착하려면 수평적으로 자유로운 의사소통이 가능한 문화일수록 좋습니다. 개발자가 폭팔적으로 성장하는 시기는 아무래도 새로운 것들을 익히고 막 배워갈 때 이기에 시니어분들은 주니어 분들을 통해서 새로운 형태의 시야를 넓혀가고 주니어 분들은 시니어 분들을 통해 노하우외 아키텍쳐로써 역량을 쌓아간다면, 더 좋은 코드리뷰가 될 것 같습니다 ㅎㅎ 사실 이상적이고 원론적인 이야기지만 도움되었으면 좋겠습니다!

선생님께서 코멘트를 공격적이게 작성하시는게 아니라면 충분히 좋은 방향이라 생각합니다! 다른 사우분들도 본인의 단점을 발견하거나 새로운 관점, 시각을 갖게 될 수도 있고 반대로 선생님께 잘못된, 또는 몰랐던 방법 같은 것들에 대해서 알려줄 수도 있게 될 수 있고 추후 내부에서든 새로 입사하신 분이든 다른분께서 프로젝트에 참여하게 되어 코드를 보게 될 때도 그분에게도 도움이 될 수 있고 여러모로 서로 긍정적인 것 같아요. 라고 썼지만 아직 저는 넘나 신생아이고 저희 사내에선 리뷰문화가 없읍니당..ㅎ

안녕하세요! 고민 상황에 대해 이야기해주셔서 감사합니다. 코드 리뷰는 개발 과정에서 중요한 부분이기 때문에 이에 대해 고민하는 것은 당연한 일이죠. 제가 생각하는 두 가지 문제에 대한 의견을 말씀드리겠습니다. 개인 기준을 코드 리뷰에 활용해도 되는가? 개인적인 기준을 가지고 코드 리뷰를 하는 것은 문제가 되지 않습니다. 실제로 코드 리뷰의 목적 중 하나는 다양한 관점에서의 피드백을 통해 코드의 품질을 높이는 것이기 때문입니다. 하지만 그 기준이 합리적이고 일관성이 있어야 하며, 팀원들과 공유된 규칙과 원칙에 따라야 합니다. 예를 들어, 팀에서 이미 정해진 코딩 스타일이 있다면 그 스타일에 맞추는 것이 좋겠죠. 개인적인 경험과 노하우를 활용할 때는 상대방에게 강요하기보다는 조언이나 제안의 형태로 리뷰를 작성하는 것이 좋습니다. 연차가 많은 사람의 코드를 리뷰해도 되는가? 연차와 상관없이 코드 리뷰는 가능하며, 오히려 다양한 시각에서의 피드백이 도움이 될 수 있습니다. 연차가 많은 개발자라도 실수를 할 수 있고, 새로운 관점에서 본 인사이트를 제공할 수 있는 리뷰어가 있으면 좋습니다. 리뷰를 작성할 때 겸손한 자세로, "이 부분을 이렇게 변경하면 어떨까요?" 혹은 "제가 이해한 것이 맞다면, 이 부분을 개선할 수 있는 방법이 있을 것 같아요."와 같이 제안의 형태로 작성하는 것이 좋습니다. 결론적으로, 코드 리뷰 시 기준은 팀원들과의 협업을 통해 정해진 규칙과 원칙에 기반해야 하며, 겸손한 자세로 피드백을 제공하는 것이 중요합니다. 팀원들과 원활한 소통을 통해 피드백을 주고받으며, 서로의 코드를 개선해나가는 것이 좋겠습니다. 이런 과정을 통해 개발자로서 더 성장할 수 있을 거에 ----- ✅ Chat GPT의 답변을 평가해 주세요! - 답변 내용이 올바른지, 틀린 내용은 없는지 댓글로 작성해 주세요.