![\"팀](\"/assets/etc.png\" "\\"팀")
코드 리뷰를 도입하겠다고 했을 때, 팀원들의 반응은 냉랭했다. “시간만 낭비하는 거 아니야?”, “내 코드를 지적받는 게 싫어”라는 반응이었다. 하지만 1년 후, 코드 리뷰는 우리 팀의 핵심 문화가 되었다. 이 글은 그 변화의 과정을 기록한 것이다.
\n2024년 초, 우리 팀은 코드 리뷰 없이 개발하고 있었다. 각자 코드를 작성하고, 바로 메인 브랜치에 머지했다. 버그가 자주 발생했고, 코드 품질도 일관되지 않았다.
\n“코드 리뷰를 도입하면 코드 품질이 향상되고, 버그도 줄어들 거야.” 이렇게 생각하며 코드 리뷰를 제안했다.
\n하지만 팀원들의 반응은 예상과 달랐다.
\n“코드 리뷰는 시간만 낭비해.”\n“내 코드를 지적받는 게 싫어.”\n“이미 바쁜데 리뷰까지 해야 해?”
\n특히 시니어 개발자 한 분이 강하게 반대했다. “내가 10년 넘게 개발했는데, 왜 리뷰를 받아야 해?”
\n주니어 개발자들도 부담스러워했다. “선배들 앞에서 코드를 보여주는 게 부끄러워.”
\n반대가 있었지만, 나는 코드 리뷰가 필수라고 생각했다. GitHub에서 Pull Request 없이는 머지할 수 없도록 설정했다.
\n# .github/branch-protection.yml\nrequired_pull_request_reviews:\n required_approving_review_count: 1이제 코드를 머지하려면 최소 1명의 승인이 필요했다.
\n하지만 이 결정이 갈등을 불러왔다.
\n갈등 1: 리뷰어 부족
\n갈등 2: 리뷰 품질 문제
\n갈등 3: 감정적 갈등
\n“내가 잘못 선택한 건가?”라는 생각이 들었다. 코드 리뷰가 팀을 나쁘게 만들고 있는 것 같았다. 하지만 포기하지 않았다. 방법을 바꿔야 했다.
\n강제만으로는 안 된다는 것을 깨달았다. 문화를 만들어야 했다. 코드 리뷰 가이드라인을 작성했다.
\n코드 리뷰 원칙:
\n리뷰어 행동 지침:
\n리뷰이 행동 지침:
\n좋은 리뷰와 나쁜 리뷰의 예시를 공유했다.
\n나쁜 리뷰:
\n\"이 코드는 잘못됐어요.\"\n\"왜 이렇게 했어요?\"좋은 리뷰:
\n\"이 부분은 좋은 접근이에요! 다만 성능을 고려하면 \n이렇게 수정하는 게 어떨까요? [코드 예시]\"\n\"이 로직이 복잡한데, 혹시 이렇게 리팩토링하면 \n더 읽기 쉬울 것 같아요.\"처음에는 작은 것부터 시작했다. 스타일, 네이밍, 주석 같은 것부터 리뷰했다. 복잡한 로직은 나중에 다루기로 했다.
\n리뷰에 너무 많은 시간을 쓰지 않도록 했다. 각 PR당 리뷰 시간을 30분으로 제한했다. 작은 변경사항은 빠르게 승인하고, 큰 변경사항만 집중적으로 리뷰했다.
\n의미 없는 리뷰를 줄이기 위해 자동화 도구를 활용했다.
\n이렇게 하면 사람은 로직과 아키텍처에 집중할 수 있었다.
\n3개월이 지나면서 변화가 보이기 시작했다. 한 주니어 개발자가 코드 리뷰를 통해 배운 점을 공유했다.
\n“리뷰를 받으면서 이렇게 하면 더 좋다는 걸 배웠어요.”\n“이전에는 몰랐던 패턴을 알게 됐어요.”
\n시니어 개발자도 변화했다. 처음에는 반대했지만, 코드 리뷰를 통해 주니어 개발자들을 가르칠 수 있다는 것을 깨달았다.
\n“코드 리뷰를 하면서 팀원들의 코드를 보고, 가르칠 수 있어서 좋아요.”\n“나도 리뷰를 받으면서 새로운 관점을 배워요.”
\n코드 품질이 눈에 띄게 개선되었다.
\n이전:
\n6개월 후:
\n1년이 지나면서 코드 리뷰가 자연스러워졌다. 이제는 강제하지 않아도 팀원들이 자발적으로 리뷰를 요청했다.
\n“이 부분 좀 리뷰해주세요.”\n“더 좋은 방법이 있을까요?”
\n코드 리뷰가 지식 공유의 장이 되었다. 새로운 패턴, 라이브러리, 기법을 코드 리뷰를 통해 공유했다.
\n코드 리뷰를 통해 팀워크도 향상되었다. 서로의 코드를 보면서 더 잘 알게 되었고, 협업이 원활해졌다.
\n처음에는 강제로 도입했지만, 이것만으로는 부족했다. 문화를 만들려면 팀원들의 이해와 동의가 필요하다.
\n처음부터 완벽한 코드 리뷰를 하려고 하지 말고, 작은 것부터 시작하라. 스타일, 네이밍 같은 것부터 시작해서 점진적으로 개선하라.
\n코드를 지적하는 것만으로는 부족하다. 좋은 점도 함께 언급하고, 건설적인 피드백을 제공해야 한다.
\n의미 없는 리뷰를 줄이기 위해 자동화 도구를 활용하라. 사람은 로직과 아키텍처에 집중할 수 있게 하라.
\n문화를 만드는 데는 시간이 필요하다. 하루아침에 바뀌지 않는다. 인내심을 가지고 꾸준히 노력해야 한다.
\n지금은 코드 리뷰가 일상이 되었다. PR을 올리면 자동으로 리뷰가 요청되고, 팀원들이 자발적으로 리뷰한다.
\n코드 품질이 크게 향상되었다. 버그가 줄었고, 코드 스타일이 일관되었고, 중복 코드가 감소했다.
\n코드 리뷰를 통해 지속적으로 학습하는 문화가 생겼다. 새로운 패턴과 기법을 공유하고, 함께 성장하고 있다.
\n코드 리뷰 문화를 만들려는 팀이 있다면, 다음을 고려해보길 바란다:
\n처음에는 저항이 있을 수 있다. 하지만 꾸준히 노력하면 문화가 정착된다. 우리의 경험이 다른 팀에게 도움이 되기를 바란다.
\n코드 리뷰 문화를 만드는 것은 쉽지 않았다. 저항과 갈등이 있었고, 실패도 있었다. 하지만 결국 성공했다.
\n지금은 코드 리뷰 없이는 개발할 수 없다. 코드 리뷰를 통해 코드 품질이 향상되었고, 팀워크가 좋아졌고, 지속적으로 학습하는 문화가 생겼다.
\n처음엔 싫어했지만, 지금은 없어서는 안 될 것이 되었다. 이것이 바로 문화의 힘이다.
","tableOfContents":"