기능 개발이 끝나면 프로덕션에 배포하기 전에 꼭 코드 리뷰를 진행해야 합니다. 코드 리뷰는 단순히 오류를 찾아 수정하는 과정이 아니라, 팀원들과 함께 배우고 성장할 수 있는 소중한 기회입니다. 작성자와 리뷰어는 서로의 코드를 통해 다양한 문제 해결 방법을 나누며, 새로운 기술과 접근 방식을 배울 수 있습니다. 이 과정에서 팀원 간 협업이 강화되고, 코드의 품질도 높아지며, 팀 전체의 코드 스타일이 일관되게 유지되는 데 큰 도움이 됩니다.

에브리타임의 안드로이드 앱을 개발할 때는 개발자가 혼자 작업을 했기 때문에, 일반적인 팀 코드 리뷰를 할 수 없었습니다. 하지만 이후에 팀원이 늘어나고 개발팀이 꾸려지면서, 코드 리뷰의 중요성을 점점 더 실감하게 되었습니다. 코드 리뷰를 통해 서로의 지식과 경험을 나누면서, 팀 전체의 기술적 역량이 확실히 향상되는 걸 느낄 수 있었기 때문입니다.

이번 글에서는 저희 개발팀이 코드 리뷰 문화를 정착시키는 과정에서 겪었던 고민과 느낀 점들을 함께 나눠보려 합니다.

건강한 코드 리뷰 문화를 만드는 레시피

1️⃣ 의도를 가지고 코드를 작성하자

코드 리뷰는 작성된 코드의 의도와 설계 철학을 함께 이야기하는 시간입니다. 작성자는 왜 그 방식을 선택했는지, 해결하려는 문제가 무엇인지, 그리고 다른 방법들과 비교했을 때 이 선택이 왜 최선이라고 생각하는지 면밀히 검토해야 하죠. 이런 논의는 리뷰어가 코드의 목적과 방향을 이해하는 데 도움을 줍니다.

리뷰 과정에서는 작성자가 자신의 코드에 대해 신념과 근거를 설명하고, 리뷰어는 단순한 오류를 지적하는 것을 넘어, 코드의 효율성과 유지보수성을 함께 고려한 피드백을 주어야 합니다. 예를 들어, 특정 알고리즘이나 패턴을 선택한 이유를 설명하면서 더 나은 해결책을 함께 찾아볼 수 있습니다.

코드 리뷰는 단순히 작은 실수나 오류를 잡는 데서 끝나지 않습니다. 코드의 설계와 구조에 대한 깊이 있는 논의가 필요합니다. 리뷰어가 코드의 전반적인 설계나 구조에 대해 질문을 던질 때, 작성자는 이를 통해 자신의 코드가 얼마나 견고하게 설계 되었는지 다시 한번 검토할 기회를 가질 수 있습니다.

2️⃣ 코드 리뷰에서 멍청한 질문은 없다

코드 리뷰 중 리뷰어는 코드 작성자가 당연하게 여길 수 있는 부분에 대해 의문을 가질 수 있습니다. 이러한 질문들은 때로는 사소하거나 바보같이 느껴질 수 있지만, 사실 코드 리뷰의 핵심입니다. 리뷰어는 자신의 궁금증을 솔직하게 표현해야 코드의 의도와 기능을 정확히 이해할 수 있고, 이를 통해 리뷰어도 코드에 대한 책임감을 가지고 이후 발생할 문제나 변경 사항에 능동적으로 대처할 수 있습니다.

특히, 새로 합류한 팀원이나 프로젝트에 참여하지 않은 팀원이 리뷰어로 참여하는 경우, 그들에게는 완전히 새로운 개념일 수 있습니다. 코드 작성자는 이러한 질문들을 통해 너무 익숙해져 간과했던 문제를 발견할 수도 있죠.

결국, 코드 리뷰에서 나오는 모든 질문과 피드백은 코드 품질을 높이는 데 기여합니다. 바보같은 질문은 없으며, 오히려 팀원 간의 지식 격차를 줄이고 코드베이스에 대한 공통의 이해를 형성하는 중요한 과정입니다.

3️⃣ 권위적인 리뷰 문화로 도플갱어를 만들지 말자

코드 리뷰 시 주의해야 할 점이 있습니다. 시니어 개발자가 피드백을 지나치게 권위적으로 전달하거나, 피드백 수용을 강요하면 주니어 개발자는 비판적인 사고 없이 리뷰어의 의견을 무조건적으로 따르게 됩니다. 이는 창의적인 문제 해결과 학습의 기회를 박탈하는 결과로 이어지죠. 결국 팀은 다양성과 창의성을 잃고, 하나의 틀에 갇힌 ‘도플갱어’들로 가득 차게 될 수 있습니다.

그렇다면 건설적이고 건강한 코드 리뷰 문화를 만들기 위해서는 어떻게 해야 할까요? 먼저 시니어 개발자는 자신의 경험을 바탕으로 피드백을 제공하되, 주니어 개발자가 스스로 생각하고 결정할 수 있도록 격려해야 합니다. 이를 통해 주니어 개발자는 주체적이고 자신감 있는 엔지니어로 성장할 수 있으며, 궁극적으로 팀 전체의 역량이 강화되는 계기가 될 것입니다.

즉, 코드 리뷰는 일방적인 지시가 아닌, 다양한 선택지와 그에 따른 장단점을 제시하며 함께 고민하는 건설적인 대화의 장이 되어야 합니다.

4️⃣ 반복되는 리뷰를 줄이자

리뷰를 할 때 반복적으로 지적되는 문제가 있습니다. 바로 줄 정렬과 간격과 같은 사소한 코드 스타일입니다. 이런 피드백은 코드의 가독성을 높이는 데 도움을 주지만, 지나치게 자주 언급되면 정작 중요한 비즈니스 로직이나 복잡한 알고리즘에 대한 검토가 소홀해질 수 있습니다. 따라서 팀의 코드 리뷰 시간을 보다 효율적으로 활용할 필요가 있습니다.

이를 위해 저희 개발팀은 코드 스타일 규칙을 자동화 도구로 관리하고 있습니다. Ktlint를 도입해 줄 정렬, 간격 등 스타일 규칙을 자동으로 검토하고 수정하며, 코드 작성 중에도 포맷팅을 자동으로 적용하도록 설정했습니다.

또한, Gitlab CI와 Ktlint를 연동해, 스타일 문제를 해결하지 않으면 코드 머지가 불가능하도록 설정했습니다. 이 자동화 프로세스 덕분에 리뷰어는 코드 스타일 대신 비즈니스 로직과 기능적 측면에 집중할 수 있었고, 코드 리뷰에 걸리는 시간도 크게 줄었습니다.

결과적으로 코드 리뷰는 코드 품질 향상이라는 본래의 목적에 더욱 충실해졌고, 팀의 생산성과 효율성도 크게 개선되었습니다. 자동화 도구는 코드 스타일의 일관성을 유지할 뿐만 아니라, 개발자들이 창의적인 문제 해결과 코드 설계에 더 많은 에너지를 쏟을 수 있도록 돕는 중요한 역할을 하고 있습니다.

    override fun onResume() {
        super.onResume()
        if (intent.hasExtra(EXTRA_NAVIGATOR)){

    override fun onResume() {
        super.onResume()
        if (intent.hasExtra(EXTRA_NAVIGATOR)) {

이러한 공백 하나까지 자동으로 인식해주기 때문에, 리뷰로 인한 피로도가 크게 감소합니다.

5️⃣ 코드 스타일을 개인의 취향에 맞추지 말자

개발자마다 개발 환경과 취향이 다르기 때문에 코드 스타일에 차이가 발생할 수 있습니다. Ktlint와 같은 자동화 도구를 통해 코드 스타일을 통일할 수 있지만, 여전히 개인의 코딩 스타일이나 접근 방식은 다를 수 있죠.

    private val _userFlow = MutableStateFlow(user)
    val userFlow = _userFlow.asStateFlow()

    private val _userFlow = MutableStateFlow(user)
    val userFlow: StateFlow<User?> = _userFlow

예를 들어 보겠습니다. 위와 같이 코딩 컨벤션(Coding Convention)에는 벗어나지 않지만, 내가 사용하는 코드 스타일과 다를 때 어떻게 코드 리뷰를 해야 할까요?

저희 팀은 이를 해결하기 위해 그라운드룰을 정했습니다. 그라운드룰에 명시되지 않은 내용은 리뷰하지 않고, 개인 취향에 맡기기로 했죠. 만약 더 효율적인 방법이 있거나, 여러가지 접근 방식이 가독성을 해지게 된다면, 모든 팀원들이 모여 회의를 통해 그라운드룰을 수정하고 문서화합니다.

그라운드룰은 코드 리뷰의 기준이 되며, 새로 입사한 개발자의 온보딩에도 큰 도움을 주기 때문에 문서화하는 것이 중요합니다.

코드 리뷰를 할 때 주의해야 할 점도 있습니다. 글에는 표정이나 어투가 담기지 않기 때문에 다르게 해석되어 오해가 생길 수 있습니다. 이를 방지하려면, 팀원 모두가 코드 리뷰의 목적을 명확히 이해하고, 상호 존중과 공감을 바탕으로 리뷰를 진행하는 것이 중요합니다.

지금까지 건설적인 코드 리뷰 문화를 만드는 방법에 대해 살펴보았습니다. 코드 리뷰는 팀의 기술적 성장을 촉진하고, 더 나은 협업 문화를 구축하는 중요한 도구입니다. 저희 개발팀도 이러한 과정을 통해 배우고 성장하며, 더 나아가 팀의 역량을 높여 비누팀의 기술력에 기여할 것입니다.

Written by 현명준