우리 팀은 JavaScript를 사용하여 웹 서비스나 회사 내부의 도구를 만드는 팀이다. 회사에 JavaScript를 전문적으로 사용하는 조직이 처음 만들어진 것이라 과거의 유산을 받을 필요 없이 팀의 개발 방법을 처음부터 하나하나 만들 수 있었다. 이 글에서는 팀을 만들면서 우리가 만들었던 개발 방법을 간단하게 정리한다.
처음 팀이 만들어졌을 때 우리 앞에는 과거 2~3년간 같이 업무를 같이 했다는 경험과 Github이 있었다. 경험은 각자가 가진 생각의 이질감을 줄이는데 도움이 됐고 과거의 경험으로부터 가져올 것과 버릴 것을 결정할 때도 도움이 됐다. Github은 그 자체로써 멋진 도구라는 공감대를 갖고 있었고 이전 회사에서도 SVN 대신 Git으로 이전하기 위한 논의를 진행한 적이 있기에 이견 없이 Github을 사용하기로 결정했다.
그리고 나서 가장 처음 시작한 작업은 Coding Conventions를 정하는 일이었다. 이전 회사에서 사용하던 conventions도 머릿속에 있었고 손에도 익었지만 그만큼 단점도 알고 있었기에 새로운 우리만의 conventions을 만들기로 결정했다. Conventions을 만들 때는 Google의 JavaScript Style Guide 를 기본으로 삼았다. 다양한 내용이 잘 정리되어 있다는 점에 모두의 의견이 일치했기 때문이다. 하지만 우리의 경험이나 선호도에 비춰 생각했을 때 우리와 맞지 않다고 생각하는 요소는 적절히 수정했다. Conventions를 어느 정도 만든 후에는 Github에 팀 전용의 계정을 만들고 conventions를 저장할 독립적인 저장소를 만들었다. 그리고 conventions을 markdown 형식의 문서로 만들고 저장하여 해당 저장소에 접근하기만 하면 언제든 내용을 확인할 수 있도록 했다.
업무에 사용할 에디터를 결정하고 열심히 만든 conventions를 지킬 수 있는 보조 도구를 에디터에 추가하는 것도 잊지 않았다. JavaScript를 개발하기에 좋은 에디터는 상당히 많지만 팀에서 권장하는 에디터는 Sublime Text 에디터다. 가볍기도 하거니와 확장성이 좋으며 개인이 구매해도 기업에서 사용할 수 있는 유연한 라이선스 정책을 갖고 있기 때문이다. (반대의 경우는 불가능하다.) 그리고 단축키로 conventions를 한 번에 정리할 수 있도록 플러그인을 만들었다. 또한 Jslint를 사용하여 자동으로 lint의 결과가 에디터에 반영되도록 했다. JavaScript를 사용한 개발 과정에 컴파일과 같은 과정은 없지만 lint 과정을 추가함으로써 오류가 발생할 수 있는 가능성을 낮출 수 있도록 했다.
Github의 경우 업무에서 사용해본 경험은 없지만 모두들 개인적으로 사용해본 경험이 있기에 일반적인 사용법은 크게 문제되지 않았다. 브랜치의 사용을 장려하는 Git의 특성상 브랜치의 관리 방법에 대해 논의를 했는데 생각보다 쉽게 결론이 내려졌다. 바로 GitFlow에서 사용하는 방식을 적용하는 것이었다. - 구체적인 방법에 대해서는 A successful Git branching model를 참고하기 바란다. - 우리의 경우 develop 브랜치를 중심으로 구현해야 할 기능별로 브랜치를 따고 개발한 후 develop에 머지하고 develop 브랜치에서 master 브랜치로 옮긴 후 배포를 진행하는 것을 핵심적인 방법으로 결정했다. 이 과정에서 GitFlow를 직접 사용할지 여부는 개발자가 결정하도록 했다.
Github을 사용하는 방법을 고민할 때 가장 고민을 많이 했던 부분은 코드 리뷰를 업무 과정에 녹이는 방법이었다. 각 개발자가 업무나 강의를 통해서 코드 리뷰가 가지는 장점에 대해 너무 잘 이해하고 있었기에 코드 리뷰를 업무 과정 중에 자연스럽고도 강제적으로 진행되도록 업무 과정을 짜고 싶었다. 처음 고민했던 것은 팀 저장소를 각 개인의 저장소에 포크하여 개발한 뒤 팀 저장소로 Pull Request (이하 PR)을 보내는 방식이었다. 그리고 PR을 받은 리뷰어들이 코드를 리뷰한 후 모두 동의하면 코드를 머지하는 방법이었다. 그런데 이런 방법을 택할 경우 저장소간 소스의 이동이 매우 번거롭다는 문제에 부딛혔다. 또한 로컬 컴퓨터로 체크아웃 하는 과정 자체가 포크와 유사한데 개인 저장소가 중간에 끼게 된다면 불필요하게 저장소를 복제하는 과정이 추가된다는 점도 쉽게 받아들이지 못한 이유였다. 여러 테스트 끝에 서로 다른 브랜치 사이에서 PR를 보낼 수 있다는 사실을 발견했다. - 지금 생각하면 당연한 이야기지만 다들 Github을 개인적으로만 사용했고 여러명이 사용한 경험이 없었기에 한참 돌아갈 수 밖에 없었다. - 그리고 이 방법이 불필요한 저장소의 생성을 막고 자연스럽게 리뷰할 수 있는 좋은 방법이라는데 다들 동의했다. 특히 Github의 PR 기능은 코드 리뷰를 하고 의견을 주고 받기에 매우 편리했다. 브랜치의 이름을 따는 방법에 대해서도 많은 이야기를 했는데 최종적으로 기능을 개발할 때는 'feature/기능명' 정도로만 브랜치의 이름을 정하는 수준으로 정리했다.
이런 방법에 따라 업무를 진행하면 다음과 같은 순서가 된다.
- 서로가 개발해야 하는 기능을 나누고 develop 브랜치에서 각 기능별 브랜치를 만든다. 반드시 develop을 기본 브랜치로 삼아야 하는 것은 아니다.
- 기능을 구현한다.
- 기능 구현이 완료되면 소스 코드를 팀 저장소의 기능별 브랜치로 push하고 develop 브랜치로 PR을 날린다.
- 해당 기능을 구현하지 않은 사람이 코드를 리뷰하며 코멘트를 단다. 해당 기능을 구현한 사람은 코멘트에 따라 코드를 수정하거나 본인이 작성한 코드가 더 나은 코드임을 리뷰어에게 설명하고 설득한다. 이 과정에서 온라인으로 진행이 어렵다고 판단하거나 직접 설명하는 것이 효과적이라고 생각하는 경우 직접 이야기를 하기도 한다.
- 리뷰 과정에서 리뷰어 사이에 의견이 나뉠 경우 서로 설득한다. 옳고 그름의 문제가 아니라 호불호의 문제인 경우 다수결을 따르기도 한다.
- 코드의 리뷰를 완료한 리뷰어는 리뷰를 완료했다는 사실을 표시하고 마지막으로 코드의 리뷰를 완료한 사람이 코드를 머지하고 브랜치를 삭제한다. 이 때 사전 협의 없이는 PR을 날린 사람이 자신이 작성한 코드를 머지하지 않는다.
- 리뷰 과정에서 문제가 발생하거나 코드를 머지하기에 충분하지 않다고 판단하는 경우 PR을 닫고 수정 과정을 거친 후 다시 PR을 날린다.
- 리뷰 과정 중 머지를 해서는 안되는 경우에는 PR을 닫거나 라벨을 이용하여 머지하면 안되는 PR임을 표시한다.
리뷰를 업무 과정의 필수인 방식으로 업무를 진행하면서 발생한 문제점도 있다. 예를 들어 리뷰어가 짝수이면서 의견의 충돌이 발생했을 때 의견의 조율이 어려운 경우가 있다. 그리고 리뷰를 하는데 생각보다 많은 시간이 걸린다는 점이다.
리뷰어가 짝수여서 의견 조율이 어려운 문제는 리뷰어를 홀수로 바꾸면서 자연스럽게 해결했다. 물론 하나의 소스 코드를 다수의 리뷰어가 보면 그만큼 리뷰에 걸리는 총 시간이 늘어나므로 무조건 많은 리뷰어를 배정하는 것이 좋은 것은 아니다. 하나의 PR을 리뷰하는데 적당한 인원은 3명이라고 생각한다. 물론 이 숫자는 리뷰어의 숙련도 등 여러 조건에 의해 변경할 수 있을 것이다.
리뷰에 시간이 많이 걸리는 점은 특별한 해결법이 없다는 생각을 하고 있다. 경험상 하나의 PR을 리뷰할 때 걸리는 시간은 리뷰어당 코드 작성 시간의 30% 정도이다. 따라서 3명이 리뷰를 하게 되면 리뷰에 걸리는 총 시간은 코드 작성 시간과 맞먹는 셈이 된다. 이 시간은 코드의 리뷰 후 수정된 코드를 다시 리뷰하는 과정에 필요한 시간까지 포함된 시간으로 머지까지 소요되는 총 시간이라고 할 수 있다. 시간적인 여유가 있을 때는 별다른 문제가 되지 않으나 업무 막바지와 같이 시간에 쫓기는 상황에서는 상당한 부담으로 다가올 수 있다. 이 시간을 줄이기 위해 코드를 작성한 사람이 리뷰 받을 대상 파일을 직접 지정하는 방법으로 신규 파일이나 로직의 변경이 있는 파일을 지정하기도 했다. 그러나 이미 전체 파일을 리뷰하는데 익숙하다는 점과 리뷰어도 리뷰를 통해 리뷰에 걸리는 시간을 점점 줄이게 되는 이유로 자연스럽게 이 방법은 사용하지 않게 됐다.
리뷰 과정을 통해 각 구성원들이 짜는 코드의 형태가 유사해지면서 다른 사람이 작성한 코드를 볼 때도 이질감을 없앨 수 있었다. 그리고 좋은 코드를 서로 칭찬하고 자신의 코드에 반영함으로써 각자의 실력이 향상되는 결과를 얻을 수 있었다. 반대로 수정 요청을 하는 경우 초기에는 코드 작성자의 감정이 조금씩 상하는 일도 있었으나 한, 두달의 리뷰가 계속되면서 감정이 상하는 일은 사라지고 서로 토론하고 더 좋은 방법을 찾는 분위기가 정착된 상태이다.
그러나 이 방법은 처음 팀에 합류하는 사람에게는 매우 큰 스트레스가 된다. 첫째, 리뷰라는 익숙하지 않은 업무 습관에 익숙해져야 한다. 많은 개발자들이 코드 리뷰를 시도하지만 여러 이유로 실패하곤 한다. 따라서 코드 리뷰라는 익숙하지 않은 개발 방법과 리뷰로 인해 필요한 일정 문제로 많이 힘들어하고는 한다. 둘째, 리뷰하는 과정에서 코드와 자신을 분리하는데 시간이 필요하다. 초기에는 대체로 코드 리뷰를 통해 코드가 아닌 개발자를 공격하는 듯한 인상을 받는다. 특히 초기에 기존 코드에 익숙하지 않기 때문에 리뷰를 통해 다른 개발자들에 비해 상대적으로 많은 이야기를 듣게 되는데 이 과정을 지나는 일이 쉽지많은 않다. 셋째, Coding conventions과 프로그래밍 패턴에 익숙해지는 것이 쉽지 않다. 신입 개발자가 아닌 이상 기존에 본인이 사용하던 스타일이 있고 그 스타일에 익숙해져 있는 상태인데 리뷰를 통해 기존의 스타일이 부정당하는 경우가 많다. 이것을 극복하면서 팀의 패턴을 받아들이고 개선할 부분에 대해 의견을 개진하는 일은 항상 쉽지 않다.
초기에 팀이 소규모일 때 이런 방법을 만들고 팀이 성장하면서 일반적인 규모의 팀 내에서는 잘 동작하는 것을 확인할 수 있었다. 이렇게 일하는 방법을 주변에 이야기하면 대규모 팀 혹은 여러 팀으로 이루어진 조직에서는 잘 적용되기 어렵지 않느냐는 질문을 받는다. 냉정하게 이야기하면 적용해본 경험이 없으므로 무조건 잘 된다고도, 실패할 수 밖에 없다고도 이야기하기 어렵다. 쉽지는 않겠지만 일단 시도해보는 것이 중요하다고 생각하며, 편의에 따라 예외상황을 만들지 않고, 개발자들끼리 많은 이야기를 하는 것이 이 방법으로 대규모로 적용하는데 중요한 요소가 되리라 생각한다.
생각해보건데 지금의 팀을 처음 만들면서 다행이었던 점은 처음 팀이 일하는 방법을 만드는데 충분한 시간을 쓸 수 있었다는 것이다. 그리고 그 시간동안 서로가 생각하는 다양한 방법을 이야기하고 시도해볼 수 있었다. 아마 이런 경험은 과거에도 없었고 앞으로도 높은 확률로 얻기 힘든 경험이 아닐까 하는 생각을 해본다. 다른 개발자에게도 이 방법이 도움이 되면 좋겠다.
