매끄러운 '코드 리뷰'를 돕는 10가지 방법

'코드 리뷰'란 말 그대로 코드를 검토해주는 과정을 뜻한다. 보통 누군가가 작성한 소스코드에 예상치 못한 오류나 개선돼야 할 방향이 없는지 코드 작성에 참여하지 않는 개발자가 살펴봐준다. 하지만 코드 리뷰를 시작하는 것은 쉽지 않다. 과연 한국 사회에서 자신보다 직급이 높은 사람에게 무언가를 지적할 수 있을까? 경력이 많은 개발자가 지적한 내용에 신입 개발자가 반박할 수 있을까. 팀 페터슨 아틀라시안 개발자 프로바커터는 “몇 가지 원칙이 있고 문화가 형성되면 가능하다”라고 말했다.

“그건 한국만 있는 문화가 아니에요. 제가 일했던 호주나 미국에서도 주니어 개발자가 시니어 개발자에게 무엇인가 제안하는 건 쉽지 않았어요. 그래서 코드 리뷰가 진행되기 위해서는 원칙과 문화를 먼저 만들어야 합니다. 중요한 건, 누구든 ‘이 코드가 잘못됐다’라는 식으로 말해선 안 됩니다. 상대방을 존중해야 해요. ‘이렇게 해보는 게 어떨까’, ‘이런 가능성도 있지 않을까?’라는 식으로 말을 주고받아야 해요. 그런 과정이 반복되면 코드 리뷰에 대한 문화가 생길 수 있죠."

코드 리뷰를 하다보면 같은 코드를 여러 사람이 함께 본다. 그래서 코드 리뷰로 왠지 할일이 늘어날 것 같고, 코드 작성에 들어갈 시간이 줄어들 것 같다. 이러한 과정이 혹시 제품 출시 시점을 늦추진 않을까. 팀 페터슨 개발자 프로바커터는 오히려 "코드 리뷰 때문에 배포 속도가 더 빨라진다"라며 "코드 리뷰를 통해 코드에 대한 자신감도 높아질 수 있다"라고 말했다. 특히 시간이 지날수록 배포 속도는 더욱 빨라질 수 있다고 밝혔다.

팀 페터슨 개발자 프로바커터는 9월14일 '데뷰 2015' 발표에서 코드 리뷰를 좀 더 효율적으로 적용할 수 있는 10가지 팁을 알려줬다. 여기서 말한 개념은 '깃'같은 버전 관리도구를 이용할 때 더욱 잘 활용할 수 있다.

1. 한 번에 하나씩 리뷰하고 고치자. 리뷰를 하다가 갑자기 다른 버그가 보일 수 있고, 스타일이나 포맷을 고치고 싶은 마음이 들 수 있다.  일단 그것은 제쳐두고 원래 고치려고 했던 내용 하나만을 보고 리뷰하고 고치는 게 더 효율적이다.

2. 코드를 리뷰하는 사람(검토자)은 이슈 1개당 최소 2명을 두자.

3. 코드 리뷰를 해야 할 항목(이슈)에 대비해 1.5~2.5배 정도의 검토자를 두자. 버전 관리도구에 이제 막 수정된 2가지 코드 내용이 올라왔다고 치자. 검토자는 이를 살펴보고 최종 프로그램에 합칠지 승인한다. 이때 검토자는 3명(2×1.5=3) 혹은 5명(2×2.5=5)을 두는 게 바람직하다. 모든 검토자가 이상이 없는지 확인하는 건 아니다. 만약 검토자가 3명이라면, 3명 중 한 사람이 승인하면 수정된 코드가 실제 프로그램에 적용된다. 따라서 검토자 중 한 사람이 바쁘거나 휴가를 내도 수정된 코드는 금세 프로그램에 반영될 수 있다. 보통 아틀라시안 내부 팀에서는 2가지 이슈를 승인하기 위해서 3~5명 정도의 검토자를 할당하고 있다고 한다. 개발 속도를 더 빠르게 하기 위해서는 더 많은 검토자를 배정하고 있다.

4. '깃 블레임'이라는 깃 명령어를 활용하라. 이 명령어를 이용하면 각 코드마다 마지막으로 수정한 사람이 누구인지, 최종 커밋 시간은 언제였는지 확인할 수 있다. 팀 페터슨 개발자 프로바커터가 직접 만든 오픈소스 '깃 길트'를 이용해도 된다. 깃 길트는 깃 블레임 내용을 요약하고 정리해주는 무료 커맨드라인 도구다.

5. 코드 리뷰를 하다보면 의견 차이가 생길 수 있다. 당사자끼리 화를 내거나 온라인에 감정적인 논쟁이 길어질 때도 있다. 이런 논쟁이 발생했다면 바로 상사, 아키텍트, 다른 개발자들 등이 나서서 중재해야 한다. 특히 온라인에서 의견을 교환하는 것을 중단하고 당사자들끼리 얼굴을 맞대고 해결할 수 있도록 도와줘야 한다.

6. 코드 리뷰 도구를 이용하다보면 리뷰해야 할 코드가 무엇인지 모아 볼 수 있다. 그런데 시간이 지나면서 해야 할 코드 리뷰가 산더미처럼 쌓일 때가 있다. 따라서 '특정 요일에는 코드 리뷰할 과제를 모두 해결하자'는 식의 규칙을 만들면 좋다. 예를 들어 '매주 화요일에는 코드리뷰함에 있는 항목들을 다 해결하자'라는 내부 팀 규칙을 만드는 것이다.

7. 코드 리뷰 도구나 프로젝트 추적기에서는 코드 내부에 메모나 글을 적을 수 있다. 이러한 기능을 활용해 특정 전문가나 관련자에게 코드에 대한 질문을 작성해 코드 리뷰를 해보자.

8. 개발자들은 소스코드를  작성하면서 "// TODO fix this later"같은 주석을 달곤한다. 나중에 다시 고치기 위해 일단 메모하는 것이다. 개발자는 가끔씩 이 주석을 잊고 수정을 안 한 채 코드를 제출하기도 한다. 만약 코드 검토자가 이러한 주석을 발견했다면 개발자에게 다시 알려주거나 구체적으로 이슈 주소를 만들어 주석에 추가하는게 좋다. 나중에 좀 더 쉽게 추적하기 위해서다.

9. 코드검토자는 코드 내용이 잘 이해 못 할 수도 있다. 이럴 때 검토자는 코드를 작성한 사람에게 찾아가 코드에 대한 설명을 듣는다. 코드 검토자는 이 내용을 말로만 듣지 말고 코드에 기록하면 좋다. 특히 코드작성자에게 들을 내용을 주석 형태로 코드에 아예 삽입해 놓으면, 향후 유지보수를 하는 개발자에게 큰 도움이 된다. 코드를 작성한 사람이 이에 대한 설명을 스스로 코드 주석으로 적는 것도 좋다.

10. 코드 리뷰에 대한 정책을 팀 단위로 정해놓자. 풀 리퀘스트(Pull Request)를 언제 적용할지 팀이 회의해서 규칙을 만들어놔야 한다.

http://www.slideshare.net/deview/123-quality-without-qa

팀 페터슨 아틀라시안 개발자 프로바커터

팀 페터슨은 올해 두 번째로 한국을 방문했다. 지난해엔 '깃'과 관련된 발표를 하기 위해 한국을 찾았다. 올해는 이보다 좀 더 다양한 발표에 참여했다. 깃, 스태시, 코드 리뷰 등 여러 주제로 한국 개발자를 만났다. 팀 페터슨 개발자 프로바커터는 "이번 방문에서 특히 깃을 어떻게 사용하는지에 대한 질문을 많이 받았다"라며 "한국 개발자들이 깃을 더 많이 도입하려는 것처럼 보였다"라고 말했다.

팀 페터슨 개발자 프로바커터는 이미 많은 세계 많은 기업에서 깃을 도입하고 있다고 설명했다. 점점 버전 관리도구, 이슈 및 프로젝트 추적기에 대한 관심이 높아지고 있는 것이다. 개발자 협업도구를 만드는 아틀라시안도 이러한 상황에 발빠르게 대처하고 있다. 아틀라시안은 대표 제품 '지라' 외에 다양한 제품을 개발하는 데 투자하고 있다.

아틀라시안은 깃과 이슈 추적기 기능을 통합한 '스태쉬'를 지원하고 있다. 코드 리뷰를 쉽게 할 수 있는 '스태시 리뷰어 서제스터'라는 무료 플로그인도 공개했다. 깃을 좀 더 쉽게 이용할 수 있도록 도와주는 '소스트리'도 내놓았다. 팀 페터슨 개발자 프로바커터는 "소스트리는 무료로 이용할 수 있다"라며 "깃은 초급자에게 조금 어려운 도구인데, 소스트리로 좀 더 시각화해서 쉽게 이해할 수 있다"라고 설명했다. 소스트리 실 사용자는 현재 70만명을 넘었다. 깃허브와 비슷한 '비트버킷'도 인기가 치솟고 있다. 현재 비트버킷 가입자는 300만명이다. 비트버킷은 5명까지는 무료로 이용할 수 있다.

팀 페터슨 개발자 프로바커터는 아틀라시안에서 9년여 동안 일했다. 초창기에는 '지라'를 개발하기도 했고, 피시아이, 크루시블, 스태시 개발 작업에도 참여했다. 최근에는 '개발자 프로바커터(Developer Provocateur)'라는 직함으로 활동하고 있다. 많은 개발자들에게 아틀라시안 제품과 철학을 소개하는 역할이다. '에반젤리스트'(전도사)와 비슷한 직업인데, 프로바커터라는 단어가 좀 더 '통찰력'을 준다는 의미가 있어서 선택했다고 한다.

[rel]아틀라시안은 2002년 설립됐으며, 호주의 시드니에 둥지 틀고 있다. 소프트웨어 개발자들을 주요 고객으로 삼고 있다. 아틀라시안 제품의 경쟁자는 주로 오픈소스 기술이다. 아틀라시안은 기업에서 이용할만큼 안정적인 도구를 제공하면서 경쟁력을 쌓고 있다. 현재 전세계 3만5천곳이 넘는 고객을 두고 있으며, 스타트업에서부터 대기업까지 다양하다. 페이스북, 이베이, 어도비, 링크드인 등이 아틀라시안 고객이며, 한국에도 주요 대기업과 인터넷 기업들이 아틀라시안 제품을 사용하고 있다.

아틀라시안에 직원은 1800여명이 넘으며 그 중 800여명이 개발자다. 그만큼 내부 개발자 문화가 발달돼 있다. 구글의 '20/80 프로젝트'와 비슷하게 아틀라시안 개발자들도 업무 시간 중 20%는 자신이 하고 싶은 일에 투자할 수 있다. 또한 3개월에 한 번씩 '십잇데이(ShipItDay)'라는 사내 해커톤이 열린다. 스태시 관련 기능도 십잇데이 해커톤을 통해 탄생했다. 팀 페터슨 개발자 프로바커터는 "아틀라시안은 개발자가 다양한 경험을 할 수 있도록 도와준다"라고 설명했다. 팀 페터슨 자신도 여러가지 제품을 만들면서 부서를 자주 바꿨는데, 이는 스스로 다양한 개발을 하고 싶어서 자발적으로 결정한 일이라고 한다. 개발자가 경험을 넓히기 위해 마케팅 담당자로 이직을 하거나 제품 관리 매니저로 직무를 바꾸는 일도 종종 있다고 한다.

"과거처럼 폭포수 모형을 적용해 프로그램을 개발하려면, 아주 많은 설계 문서들이 필요합니다. 기능을 수정하고 보안하는 데 시간이 많이 걸리죠. 앞으로 미래에는 개발이 어디까지 진행됐는지, 누가 어떤 기능을 개발하는지 자세히 아는 것이 결국 좋은 제품을 만들 수 있는 핵심 요소가 될 것입니다. 팀 단위로 일할 땐 더더욱 그렇죠. 그런 의미에서 앞으로 더 많은 개발팀들이 이슈 및 프로젝트 추적 프로그램이나 깃같은 프로그램을 사용할 것이라고 봅니다. 아틀라시안은 이러한 개발도구에 전문성을 불어넣는 데 힘을 쏟고 있는 것이고요."