코드 리뷰는 소프트웨어 개발의 필수 과정입니다. 잠재적 버그를 발견하고, 코드 품질을 높이려면 코드 리뷰가 필요합니다. 아울러 코드 리뷰는 코드 스타일의 일관성을 유지하고, 개발팀 전체가 코딩 습관을 개선하며, 개발 역량을 발전시키는 데 중요합니다. 팀에서 기술을 공유하며 기술 지식을 쌓는 데도 도움이 됩니다.
저는 인포그랩 개발팀 리더로서 일상적으로 코드 리뷰를 수행합니다. 리뷰어 관점에서 코드를 보면, ‘리뷰하기 좋은 코드’와 ‘그렇지 않은 코드’가 구분됩니다. 리뷰하기 좋은 코드는 가독성이 좋아 이해하기 쉽습니다. 이는 코드 리뷰 시간을 줄여 개발 생산성도 높입니다.
리뷰어는 코드의 ‘1차 독자’입니다. 1차 독자부터 코드를 신속하고 정확하게 이해시키지 못하면 2~3차 독자도 이 코드를 이해하기 어렵습니다. 코드는 다른 개발자에게 지속적으로 공유되기에 원활한 협업과 업무 효율화 측면에서 리뷰하기 좋은 코드를 작성하는 건 중요합니다. 이 글에서는 개발팀 리더 관점에서 코드 리뷰의 중요성과 리뷰하기 좋은 코드의 특징을 공유하겠습니다.
코드 리뷰의 중요성
코드 리뷰는 단순히 버그를 잡아내는 걸 넘어 코드 품질을 높이고 팀 전체의 성장을 돕는 강력한 도구입니다. 코드 리뷰로 발견한 개선 사항은 성능 최적화, 보안 강화, 유지 보수성 향상 등 다양한 측면에 긍정적 영향을 미칩니다.
- 버그, 문제 발견: 코드를 리뷰할 때, 리뷰어는 코드 작성자가 발견하지 못한 문제점을 찾아낼 수 있습니다. 이는 기능에 문제가 없어도 성능, 보안, 유지 보수 측면에서 코드 개선점을 파악하는 데 도움이 됩니다.
- 코드 품질 향상: 코드 리뷰를 토대로 코드에 더 나은 구조와 패턴을 적용할 수 있습니다. 이로써 읽기 쉽고 유지 보수하기 좋은 코드를 작성할 수 있습니다.
- 지식 공유와 팀 성장: 동료 리뷰를 진행하면, 팀원들이 서로 코드를 읽고 피드백하며 기술을 배우고 성장할 수 있습니다. 이는 팀의 코딩 스타일과 컨벤션을 통일하는 데도 기여합니다.
그러나 코드 리뷰에는 ‘시간’이라는 현실적 제약이 있습니다. 코드가 복잡해질수록 리뷰 시간은 길어집니다. 그 결과, 개발 속도가 지연되고, 리뷰어 부담도 커집니다. 이는 개발 생산성을 떨어뜨릴 우려가 있습니다. 원활하게 소통하며, 개발팀 협업을 효율화하고, 팀 전체 생산성을 높이려면 리뷰하기 쉬운 코드를 작성해야 합니다.
리뷰하기 좋은 코드는?
저는 팀에서 여러 사람이 작성한 코드를 경험하다 보니 업무 생산성, 협업 용이성 측면에서 ‘리뷰하기 좋은 코드는 어떤 것인지’ 자주 고민합니다. 제가 생각하는 리뷰하기 좋은 코드 요건과 해당 코드 작성법은 다음과 같습니다.
1. 간결하고 읽기 쉬운 코드 작성
리뷰어가 코드를 빠르게 이해하려면, 코드가 간결하고 명확해야 합니다. 코드가 복잡하면, 버그나 논리적 오류를 파악하는 데 시간이 오래 걸립니다.
- 하나의 함수, 하나의 역할: 함수나 메서드는 하나의 책임만 가져야 합니다. 여러 기능이 한 함수에 섞이면, 흐름을 파악하기 어렵습니다.
- 명확한 변수 이름: 의미 없는 변수 이름보다 의도를 드러내는 이름을 사용하세요. 예를 들어, temp 대신 userAge처럼 구체적인 이름이 좋습니다.
- 중복 코드 제거: DRY(Do Not Repeat Yourself) 원칙을 지켜 중복된 코드를 최소화하세요. 중복된 코드가 많으면 유지 보수하기 어렵고 디버깅도 복잡합니다.
2. 주석과 문서화
주석은 코드를 설명하는 중요한 도구지만, 과도한 주석은 방해가 될 수 있습니다. 코드 자체로 설명이 가능하도록 작성하는 게 이상적입니다. 그러나 복잡한 로직이나 외부 API와 연동된 부분에는 적절한 주석이 필요합니다.
- 의도 설명: 주석은 코드가 ‘무엇’을 하는지보다 ‘왜’ 그렇게 하는지 설명해야 합니다. 예를 들어, 특정 알고리즘이나 처리 방식을 선택한 이유는 주석으로 남기는 게 적절합니다.
3. 일관된 코드 스타일과 컨벤션 유지
팀에서 코드 스타일과 컨벤션을 일관되게 유지하면 코드 리뷰 시간이 절약됩니다. 코드 스타일이 일관되지 않으면, 리뷰어가 로직보다 스타일 문제에 더 많은 시간을 할애합니다.
- 자동화된 포맷터 사용: Prettier나 ESLint와 같은 포맷터와 린터 도구를 사용하면 코드 스타일 차이를 줄일 수 있습니다. 이는 불필요한 포맷팅 논쟁을 막고, 코드 스타일의 일관성을 유지하는 데 유리합니다.
- 컨벤션 문서화: 팀의 코드 스타일과 컨벤션을 문서화해 공유하면, 팀원들이 동일한 기준을 따르기에 코드 리뷰 시간이 줄어듭니다.
4. 태스크와 변경 사항 일치
하나의 태스크에 하나의 변경 사항만 포함해야 코드 리뷰를 효율적으로 진행할 수 있습니다. 여러 기능이나 수정 사항을 한꺼번에 추가하면, 리뷰어가 변경 목적을 파악하기 어렵습니다.
- 하나의 변경 사항: 하나의 Merge Request(MR)에는 하나의 기능 또는 버그 수정을 포함해야 합니다. 그래야 리뷰어가 각 변경 사항의 영향을 쉽게 이해할 수 있습니다.
- 작은 MR 선호: 여러 파일을 수정하거나 큰 기능을 한 번에 추가하기보다 작은 단위로 나눠서 MR을 작성하는 게 좋습니다. 작은 MR은 리뷰하기 쉽고, 오류를 발견하는 데 도움이 됩니다.
맺음말
“사연 없는 코드는 없다”라는 말이 있습니다. 저는 코드 리뷰할 때, 이 말이 자주 떠오릅니다. 코드에는 작성자의 의도와 목적이 있습니다. 따라서 코드를 단순한 결과물로 보기보다 ‘그 안에 담긴 맥락을 이해하는 게 중요하다’고 생각합니다.
코드 작성자는 자기 의도를 명확히 드러내도록 간결하고 일관된 코드를 작성해야 합니다. 아울러 필요시 주석과 문서화로 그 의도를 분명히 전달해야 합니다. 이러한 습관을 유지하면, 리뷰어를 비롯해 개발팀 안에서 소통이 원활해지고 코드 품질도 한층 더 높아질 것입니다.
DevOps와 GitLab을 효과적으로 도입하는 방법, 지금 인포그랩에 문의하세요.