안녕하세요! 토스터 iOS팀 개발자 코딩하는 체대생, 민군입니다.
TOASTER 어플을 앱스토어에 릴리즈한지 어언 2개월이 지나고 있는 지금 시점에서, 저희 iOS 팀의 첫 번째 팀블로그를 작성하고자 힘겹게 노트북을 펼치게 되었습니다.
첫 글인만큼, 이번 글에서는 iOS와 관련된 기술적인 구현과정보다는 저희 iOS 팀의 프로젝트 협업 방식, 특히 코드 리뷰 문화에 대해 먼저 소개를 하고자 합니다!
코드 리뷰의 중요성이나 그 효과에 대해 작성한 글 중에서는 코드 리뷰 in 뱅크샐러드 개발 문화 글이 가장 유명한 것으로 많이들 알고 계실텐데요.
저희 팀도 위 사례를 바탕으로 코드 리뷰 문화를 정착시키고자 노력했습니다!
다만, 현 상황(프로덕트의 크기나 개인별 개발 실력 차이, 그리고 수익을 창출하는 기업이 아니라 대학생들끼리 모여서 만드는 프로젝트라는 점)에 맞춰서 적용가능한 부분만을 우선적으로 받아드리고자 했다는 점! 감안하시고 글을 읽어주시면 감사할 것 같습니다 ^__^
🍎 기능 구현에 급급한 앱잼은 지양하고 싶다!
저희 <TOASTER 토스터> 서비스는 솝트 SOPT라는 대학생 연합 IT 벤처 창업 동아리 내에서 구현한 프로젝트입니다.
하나의 프로덕트를 위해 기획, 디자인, 서버, 안드로이드, iOS까지 여러 팀원들이 함께 노력을 하고 있으며, 그 중 저희 iOS 팀은 저 포함 네 명의 개발자분들이 함께 협업해서 개발을 진행하고 있습니다.
자랑을 먼저 하고 넘어가자면,
저희 팀은 iOS 파트의 피드백을 담당해주셨던 멘토님에게도 아래와 같은 칭찬을 받았을만큼 코드 스타일과 구성 자체에 있어 좋은 퀄리티를 가진 프로덕트를 만들었다고 평가를 받았습니다!
프로덕트 크기가 얼마나 된다고, 코드 스타일이랑 구성을 깔끔하게 하는게 뭐 그리 자랑이야?
위와 같은 지적이 있을 수 있어, 배경설명 먼저 하고 넘어가보려 해요!
솝트 동아리에서 진행되는 장기 해커톤 행사, 앱잼(APP-JAM)의 기간은 5주이고, 이 짧은 5주간 완성도 높은 서비스 하나를 완성하기 위해서는 아무래도 코드의 quality를 높이기 위한 노력보다는 feature 개발에 급급하게 되는 것이 그동안의 현실이었습니다.
그러다 보니, 앱잼 기간이 끝나고 프로젝트를 계속 유지보수하기 어렵고, 각 팀원별 코딩 스타일이 달라 다른 팀원의 코드를 파악하기 어렵다는 문제, 다음 스프린트에서는 다른 기능 구현을 우선으로 하다 보니 Code Quality를 개선하는 것은 계속 후순위로만 밀리게 되는 문제...등이 계속 반복될 수 밖에 없었죠.
*아마 이 문제는 솝트 동아리가 아니더라도, 기업이 아닌 대학생들끼리 모여서 진행하는 프로젝트에서는 한번쯤 겪어볼 수 있는 만성적(?)인 문제라고 생각해요!
아무튼 그래서, 이번 앱잼 프로젝트에서는 위와 같은 악순환을 끊어내고자 기능 구현에 급급한 앱잼은 지양하고자 했습니다!
첫 iOS 킥오프 회의 때, iOS 팀원 전원이 이번 앱잼에서는 기능 구현에 급급하기보다 코드 Quality도 신경쓰는 프로젝트를 목표로 하는데 동의했고, 그 일환으로 "Code Review를 통한 Convention 확인 및 모르는 것은 질문하는 문화"를 팀 문화로 채택, 적극적으로 수행하고자 노력했습니다.
🍎 꼼꼼한 PR 규칙
코드 리뷰(Code Review)는 다른 개발자가 작성한 코드를 확인해서 피드백을 주는 행위입니다.
혼자서는 확인할 수 없었던 문제를 다른 개발자들이 중복 검토하며 발견할 수도 있고,
피드백을 통해 더 좋은 코드나 방법을 함께 고민하거나 공부할 수 있는 창구가 되기도 하죠!
하지만, 무엇보다 코드 리뷰를 통해 다른 팀원이 짠 코드에 대해 이해되지 않는 부분을 질문할 수 있다는 점이 코드 리뷰의 가장 큰 효과라고 생각해요.
결국은 내가 짠 코드가 아닌 이상, 네이밍이 직관적이거나 의존성이 바로 눈에 보이도록 코드를 구성했다하더라도 처음부터 모든 코드를 이해하기는 쉽지 않은 일이니까요..
그래서 저희 팀은 이 부분을 코드 리뷰에서 직접 물어보기보다 처음 PR을 올릴 때 신경을 쓰기로 했습니다!
작업 내용 설명과 기기대응
보통 Git Issue Template를 사용해서 본인이 수행할 작업에 대해 공유하고 개발을 시작하지만, 작업을 마치고 PR을 올릴 때에도 Git Pull Request Template으로 수행한 작업에 대해 공유하고 있습니다.
Issue에서 작업할 내용을 작성했지만 PR에서도 작업한 내용을 자세하게 작성하고,
만약 뷰와 관련된 작업인 경우에는 작동 화면 (스크린샷, 혹은 gif)을 함께 첨부하도록 합니다.
이때 구현은 SE, 13 mini, 15 pro 세 개의 기기의 화면을 기준으로, 기기 대응이 정확하게 이루어졌는지 리뷰어들이 확인할 수 있도록 PR에 담게 하였습니다.
코드설명과 체크리스트
특정한 디자인 패턴을 사용했거나, 재사용 가능성이 있는 코드에 대해서는 추가로 코드 구성이나 사용법을 설명합니다.
재사용 가능하도록 만든 Toast Message와 Bottom Sheet Components 같은 경우는 어떻게 가져다가 사용할 수 있는지를 설명한 예시가 아래 이미지입니다.
이 과정을 통해 팀 내 반복되는 불필요한 코드를 줄일 수도 있으며,
사용한 코드에 대해 다른 팀원들에게 "왜 이렇게 코드를 짰는지"에 대한 정당성을 설득하는 역할이 되기도 합니다.
추가로 마지막 PR을 올리기 전 체크리스트를 통해,
테스트 시 사용했던 주석이나, print문의 제거 여부, 그리고 Coding Convention (Lint Error 발생여부)을 잘 준수했는지를 마지막으로 확인하도록 했습니다!
🍎 뱅크샐러드 문화 재해석 : 코드 리뷰의 우선순위(P1~P3) 부여하기
뱅크샐러드 조직은 코드 리뷰 코멘트에 P1부터 P5까지 나누어져 있는 Pn 룰을 통해 "강조하고 싶은 정도"를 표현, 이를 통해 커뮤니케이션 비용을 줄이기 위해 노력한다고 표현했습니다.
저희 토스터 iOS 팀도 이 문화를 빌려, 코드 리뷰의 우선순위를 부여해 PR 담당자가 코드 리뷰 반영 정도를 쉽게 파악할 수 있도록 했습니다!
다만, 서비스 프로덕트 볼륨의 차이와 코드리뷰 반영의 용이성을 고려해 저희 팀에서는 3단계로 조금 간소화해서 코드리뷰의 우선순위를 부여하기로 합니다.
P1: 꼭 반영해주세요. 수정이 필요해 보입니다. (Request changes)
검토 과정에서 중요한 오류 (런타임 에러, 레이아웃, 잘못된 연산 혹은 데이터 처리 등) 발생되었거나, 오류를 발생시킬 가능성이 있어 보이는 경우 리뷰어는 P1으로 코드의 수정이 필요하다는 것을 알려줍니다.
P2: 반영하면 좋을 것 같습니다. (Comment)
검토 과정에서 발견한 Warning이나 개선할 가능성이 있어 보이는 기존 코드에 대해 리뷰어는 P2와 함께 다른 대안을 제시할 수 있습니다.
만약, 리뷰 요청자가 해당 커멘트를 수용할 수 없는 경우에는 리뷰어가 해당 의견을 받아들일 수 있도록 적절한 근거를 들어 설명해야 합니다.
P3: 단순 의견 제시 혹은 질문사항이 있습니다. 무시해도 좋습니다. (Approve)
P3로 명시된 코드리뷰에 대해서는 리뷰 요청자가 무시하고 넘어갈 수 있습니다.
단, 학습 목적으로 질문하는 커멘트도 P3로 표현되기에, 이 리뷰에 대해서 리뷰 요청자가 아닌 다른 팀원이 답을 남기는 경우도 존재할 수 있습니다.
추가로, Coding Convention에 맞지 않는 코드(개행, 들여쓰기, 네이밍 등)들도 해당 우선순위로 리뷰 요청자에게 알려줍니다.
🍎 P1 사례 : 중복 검토해서 발생하는 에러를 줄이기
PR을 올리기 전, 아무리 리뷰 요청자가 꼼꼼히 검토한다고 하더라도 스스로 짠 코드에서 발생하는 에러를 모두 찾기는 쉽지 않은 일입니다.
코드 리뷰의 가장 핵심 기능이라 할 수 있는 중복 검토를 통해 iOS 팀은 Merge 전 리뷰 요청자가 발견하지 못했던 에러나 잠재적 에러 상황을 확인하고, 이를 수정 반영할 수 있도록 노력했습니다. 
특히, 해당 우선순위에서 기능적인 에러(동작 불가, 앱 강제 종료 등)와 더불어 레이아웃 대응이나 데이터 처리을 모두 확인하면서
QA에서 발견될 수 있는 문제들을 자체 팀 수준에서 많이 발견할 수 있었습니다 ^__^
🍎 P2 사례 : 더 좋은 코드를 구현하기 위한 iOS팀의 노력
"절대적으로 좋은 코드는 없다"라는 같은 가치관 아래,
단순히 기능 구현에 그치지 않고 더 좋은 코드를 작성하기 위한 iOS 팀의 노력은 P2 우선순위로 나타나게 되었습니다.
한 기능 아래 구현가능한 다른 방법을 함께 고민해보거나,
함수 분리, 객체 분리, 가독성 좋은 코드가 무엇인지와 같은 사소한 내용들도 해당 우선순위에서 함께 고민하며 리뷰어와 리뷰 요청자가 함께 토론할 수 있는 문화를 지향하고 있습니다.
이 과정을 통해 저희팀은 "그저 코드를 작성하는 행위"에만 집중하기보다,
"더 좋은 방법, 더 좋은 코드를 위해 끊임없이 고민"하는 이상적인 Software Developer로서 성장하기 위해 노력중인 것을 확인하실 수 있을 것입니다 :)
🍎 P3 사례 : 이해가 어려운 것은 적극적으로 물어보는 문화
P3 우선순위의 대부분은 일관된 코딩 스타일을 체크하는 용도로 활용됩니다.
"이 부분 1줄 개행 해주세요!" "이 부분 줄바꿈이 필요할 것 같습니다"와 같은 커멘트가 대부분이죠.
뭐 이런 것까지 확인하냐라고 할 수도 있지만, 결국 이런 사소한 Convention 하나하나가 쌓이고 쌓여 가독성 있는 코드를 만들게 되는 것이자 일관된 팀 문화를 유지하는 데 도움을 준다고 말할 수 있을 것 같습니다.
P3지만, 결코 무시할 수 없고, 그만큼 엄격하게 체크하는 부분이 Coding Style과 관련된 리뷰입니다.
이 내용 외에도 저희 팀 P3 리뷰에는 질문의 가치를 중요하게 생각하는 부분을 확인하실 수 있습니다.
저희 팀은 Coding Convention 확인 외에도, P3 우선순위에서는 적극적으로 질문하는 문화를 지향하고 있습니다.
위와 같이 즉각적인 수정과 관련되지 않은 코드 실행에 대한 의문 ("만약, 이 부분이 이런 상황이라면 어떻게 처리가 되는 것이죠?" "이 부분에 대한 수정은 이루어지지 않나요?" 등의 질문들)을 해당 커멘트에서 제시할 수 있으며,
아래와 같이 iOS 개발 지식 ("해당 키워드는 무엇을 의미하죠?" "이 코드를 사용할 수 있는 또 다른 예시는 없을까요?" 등의 질문들)과 같은 사소하다고 볼 수 있는 질문을 통해 스터디 형식으로 공부를 할 수도 있습니다.
특히 후자의 경우에는 아무래도 그저 공부를 위한 공부가 아니라, 실제 구현 부분에서 사용되는 예제를 바로 확인할 수 있다는 점에서 더 와닿는 공부를 할 수 있다는 것이 큰 장점이 되는 것 같았습니다.
🍎 글을 마무리하며
위와 같은 문화를 가지고 개발한 토스터 <TOASTER 토스터> 서비스를 직접 경험해보시는 것은 어떨까요?
토스터는 앱스토어와 플레이스토어에서 지금 바로 다운로드 받으실 수 있습니다.
❤️ 토스터 iOS 앱스토어 다운받으러 가기
💚 토스터 안드로이드 구글 플레이스토어 다운받으러 가기
🍞 더 좋은 토스터 서비스를 위해 의견 전달하러 가기
