"깃허브로 협업?...풀리퀘스트 주목해야"

"코드리뷰, 필요한 건 알지만 쉽지 않다. 테스트도 못하고 배포해 버릴 때도 있다. 코드질이 안정적이지 못하니 버그가 생기고 야근과 주말 근무에 시달린다. 옆 부서에서 뭘 만들고 있는지 몰라 똑 같은 일을 반복해서 또 하기도 한다.” 개발자라면 한번 쯤 경험해 봤을 법한 '안 좋은 개발과정'의 예다.

이런 문제들은 왜 발생할까? 여러가지 요인이 있겠지만 개발 조직내 협업이 안되기 때문인 경우가 많다. 조직 멤버들이 모든 코드와 정보에 쉽게 접근할 수 있는 환경이 마련되면 코드리뷰가 활발해 지고 누구나 더 깔끔하고 좋은 코드를 제안할 수 있게 된다.

요즘 개발자들에게 가장 있기 있는 소스코드 저장소이자 버전관리시스템 '깃허브(Github)’는 이런 협업 정신을 개발 플로우(flow) 안에서 잘 지원하고 있다. 최근 SK플래닛이 주최한 컨퍼런스 테크플래닛에 연사로 선 깃허브 이케다 타카후미 (Ikeda Takafumi) 세일즈 엔지니어는 “협업은 깃허브의 본질”이라고 강조했다. 한국에도 출간된 "성공으로 이끄는 팀 개발 실천 기술"의 저자이기도한 그가 소개한 깃허브 활용법을 소개한다.

깃허브는 풀리퀘스트(Pull Request)라는 기능을 중심으로 개발 플로우가 짜여 있다. 풀리퀘스트는 다른 사람이 만든 코드에 수정을 제안하는 기능이다.

먼저 다른 사람의 코드를 변경해보고 싶다면 그의 브랜치(Master branch)에서 포크해 독자적인 브랜치를 만들어야 한다. 여기서 중요한 포인트는 브랜치를 작은 단위로 만드는데 있다. 브랜치를 길게 유지하게 되면 마스터 브렌치와 차이가 커져 나중에 코드를 합치기 쉽지 않다. 이케다 타카후미 개발자는 “변경 단위를 짧게 하면서 세밀하게 만들어 풀리퀘스트하는 게 중요하다”고 조언했다.

이렇게 자신의 브랜치를 만들면 여기서는 다른 사람의 작업을 방해는 일 없이 무엇이든 뜯어보고 고쳐볼 수 있다. 가벼운 마음으로 한번 실험해보고 잘못 됐으면 그냥 풀리퀘스트를 하지 않으면 된다.

변경한 코드가 좀 괜찮은 것 같다면 이제 풀리퀘스트를 보낼 수 있다. 마스터 브랜치에 자신이 수정한 내용을 제안하는 것이다. 이것을 가지고 다 같이 코드 리뷰를 하거나 설계 방식이 맞는지 토론을 할 수 있다. 리뷰과정에서 지적 사항이 나오면 수정하기를 반복한다.

이케다 타카후미 개발자는 "이 때까지 마스터 브랜치에 변경 사항이 들어가지 않기 때문에 다른 사람의 브랜치를 방해하거나 멋대로 배포되는 일을 걱정할 필요가 없고, 또 동시다발적으로 여러 사람이 변경하면서 개발할 수 있다는 점이 깃허브의 가장 큰 장점”이라고 설명했다.

코드리뷰는 상대의 코드에 대해 비평하는 것이기 때문에 자칫 잘못하면 상대의 감정을 상하게 할 수도 있다. 그래서 그는 깃허브에서 제공하는 이모티콘을 적극 활용해서 딱딱한 텍스트로 전달할 수 없는 감정을 전달하고 오해를 줄이는 것이 하나의 팁이라고 전했다.

코드리뷰가 끝나고 오케이가 나면, 그때 마스터 브랜치에 합쳐(merge)지는데 머지 전에 테스트는 필수적이다. 이케다 타카후미 개발자는 '지속적인 통합 (CI: Continuous Integration)’을 강조하며 “테스트는 계속해야한다. 머지하기 전에 테스트를 해서 품질을 보장해야한다”말했다.

풀리퀘스트의 또 다른 장점 중 하나는 잘못된 변경 사항을 쉽게 되돌릴 수(리버트 Revert) 있다는 점이다. 꼼꼼한 코드리뷰와 테스트를 거졌는데도 미쳐 체크하지 못한 문제가 있을 수 있다. 이 때 사용할 수 있는게 리버트다. 풀리퀘스트를 잘 활용해서 개발했다면, 특히 리버트가 용이하다. 커밋이 풀리퀘스트 단위로 묶여 있어 리버트도 풀리퀘스트 단위로 할 수 있다는 설명이다.