협업

Git

처음부터 왓 스튜디오가 오픈소스 커뮤니티에 친화적이길 바랐다. 그래서 형상관리 도구로 Git을 사용하고 언어 커뮤니티의 컨벤션을 존중했다. 나도 그 전까지 Git으로 협업해 본 적은 없어서 이 기회에 Git에 통달하고자 했다.

내 이전 프로젝트에선 Subversion과 Mercurial을 썼었다. 프로그래머 1~3명짜리 작은 팀이다보니 복잡한 브랜치도 경험해보지 못 했다. 그래서인지 처음엔 Git을 거의 로컬 버퍼링만 하는 Subversion처럼 썼다. 이 시절에 머지한 브랜치들이 무지개 그래프를 이뤘다. 그래프가 너무 복잡해서 눈으로 쫓아갈 수 없었다. 딱히 보지도 않았다. 최신 저장소에서 문제라도 생기면 원인을 추적하는 데에 많은 시간을 쏟을 수밖에 없었다.

Git에 익숙한 김찬웅 님이 들어오고 나서야 이게 잘못된 상황이란 걸 인지했다. 따로 시간을 내서 rebase를 배웠다. "그래프의 base를 바꾸는 것이라서 rebase구나"라고 이해하니 개념이 어렵지 않았다. 비로소 커밋 그래프를 일렬로 펴고 눈으로 읽을 수 있게 됐다. 그동안 왜 Git에 커밋 그래프 조작 기능이 있는지 이해하지 못 했었는데 대규모 프로젝트에선 꼭 필요한 기능이라는 걸 깨달았다.

클라이언트는 용량이 큰 아트 리소스를 처리하기 위해, 그리고 미려한 GUI를 쓰기 위해 PlasticSCM을 썼다. 클라이언트와 서버는 서로 다른 프로젝트라서 굳이 같은 형상관리 도구를 쓸 필요가 없고, Git을 지원하는 수많은 DevOps 도구의 수혜를 포기할 수도 없어서, 서버에선 계속 Git을 쓰기로 결정했다.

하지만 Git의 개념과 사용법을 개발팀 모두에게 교육하는 게 정말 쉽지 않았다. 멘탈모델을 만드는 데에 시간이 꽤 걸리다보니 기꺼이 배우지 않으면 익히기 어렵다. 하지만 모두에게 꼭 배워야 할 책임이 부과되진 않기 때문인 것 같다.

GitLab

GitLab은 직접 설치해서 쓸 수 있는 GitHub 아류작이다. CE(community edition), EE(enterprise edition)로 나뉘며 CE는 공짜로 쓸 수 있다. 처음 도입했을 땐 운영하기 불편하고 버그도 많았지만 그동안 발전을 멈추지 않아 지금은 꽤 매력적인 모습이 되었다.

설치와 패치가 굉장히 쉽다. apt install gitlab-ee

자주 새 버전을 배포한다. 제보한 버그가 빠르게 해결된다.

CI가 내장되어있다. GitHub Enterprise엔 CI가 내장돼있지 않아서 CircleCI 나 Travis CI에 연동해야 한다.

포크-머지요청-코드리뷰 프로세스가 자연스럽다. 줄 단위 토론이 직관적이다. 개인적으로 GitHub의 코드리뷰보다 더 직관적인 것 같은데 그냥 익숙해서 그럴 수도 있다.

CI에서의 트러블슈팅은 난이도가 높다.

가능하면 로컬에서 재현하려고 노력한다. 정 안 되면↓

빌드/테스트 커맨드의 로그를 모두 출력하게 해본다.

CI에서 재빌드 속도를 높이기 위해 캐시를 쓰는데 이게 문제일 수 있다. 의심해본다.

임시 브랜치를 만들고 CI에서 문제가 되는 부분만 돌도록 스코프를 좁힌 다음 조금씩 고쳐서 자주 push해본다.

우리 GitLab CI Runner는 Docker로 돌아간다. 운이 좋으면 그 컨테이너가 부숴지기 전에 들어갈 수 있다: 우선 빌드 로그에서 컨테이너 아이디와 Docker 머신 이름을 확인한다. git.k에서 sudo su; docker-machine ls하면 Docker 머신의 EC2 인스턴스 주소를 확인할 수 있다. 해당 인스턴스에 SSH로 접속해서 docker exec ... /bin/bash하면 문제의 컨테이너에서 터미널을 띄울 수 있다.

코드리뷰

코드리뷰가 건강한 개발 문화의 중심이라고 생각한다. 코드리뷰를 적게 하거나 아예 안 한다면 개발 문화가 건강하지 않다는 징후일 수 있을 것 같다.

우리 스튜디오에도 처음부터 코드리뷰가 있었던 건 아니고, 처음 도입했을 때부터 좋은 모습이었던 것도 아니다. 가령 초기에 나는 리뷰어 역할만 하고 리뷰이 역할을 하지 않았는데, 이 기간 동안 양쪽을 경험해야 알 수 있는 코드리뷰 매너를 배우지 못 했다. 또한 동료들 사이에서 부적절한 권위주의적 분위기를 야기하기도 했다. 다행히 이런 문제는 코드리뷰 문화를 이끌어 나가고 다방면의 조언을 수용하면서 차츰 사라졌다.

공통

한 사람이 리뷰어, 리뷰이 역할을 모두 수행해야 한다.

코드리뷰는 일상이다. 시간을 많이 들여야 한다. 귀찮아하지 말자.

여유가 없으면 대충하게 되니 몰아붙이지 말자.

코드리뷰의 목표는 머지가 아니다. 잘못된 코드가 배포되지 않게 하는 게 목표다.

리뷰어의 자세

줄 단위로 꼼꼼히 보는 게 굉장히 중요하다. 컨셉만 보고 넘기지 말아야 한다. 배포된 문제는 수습하기 정말 어렵고, 많은 인원의 스트레스가 동반하기 마련이다(본인 포함). 작업자나 다른 리뷰어가 놓친 문제를 발견하면서 두터운 신뢰도 쌓을 수 있다.

문제는 직설적으로 짚어야 하지만 어조가 공격적이어선 안 된다. 반대로 기분을 너무 신경써서 문제를 짚지 못하게 되는 것도 경계해야 한다. (난 공격적인 편이었다)

토론 내용이 코드리뷰 시스템에 남아야 한다. 의사소통 효율을 위해 구두로 협의하더라도 코드리뷰 시스템에 다시 한 번 요약하자.

머지요청 본문 템플릿을 주기적으로 보완한다.

리뷰이 입장에서 부당하다고 느낄 수 있으므로, 해당 머지요청에서 수정하지 않은 곳을 지적하지 않아야 한다. (난 잘 지키지 못 했다)

리뷰이의 자세

리뷰어가 쉽게 리뷰할 수 있도록 diff를 디자인해야 한다. 리뷰하기 어려운 diff는 충분히 검토되지 않는다. 이렇게 되면 프로젝트와 승인한 리뷰어, 재작업하게 될 리뷰이에게 모두 손해다.

Git은 탁월한 커밋 수정 기능을 제공한다. 머지요청을 만들기 전에 리뷰어의 관점에서 자신의 머지요청이 어떻게 보일지 검토하고 보완하는 시간을 갖는다.

한 머지요청엔 한 가지 의도만 담아야 한다. 버그픽스 모음집은 대표적인 안티패턴이니 피하자.

처음 코드리뷰 문화를 접하면 피곤할 수 있다. 하지만 피곤하게 여기면 더 나아지지 않을 것이다. 어떻게 하면 더 쉽게 합의를 끌어낼 수 있을지 고민하고 성장해야 한다.

SDC

서비스파트에 도입했던 자주 길게 하는 지식공유 회의. 6명 규모에서 주 2회 100분 정도 진행했었다.

자주 하는 이유는 비전 정렬을 빠르게 하기 위해서다. 각자 일을 맡고 1주일만에 확인해보니 서로 다른 방향으로 가고 있었다면 손실이 크기 때문이다. 서비스파트 5명 시절엔 서로 겹치는 분야가 별로 없었는데, 서로의 업무를 파악하려면 각 분야의 기술적 배경까지 자세히 공유해야만 했다. 그래서 시간이 길어졌다. 비전문가에게 설명하기 위해선 먼저 스스로 정리해야 하므로 지적만족감도 높았다.

처음엔 매일 진행하기도 했었는데, 하루 중에 작업에 집중할 수 있는 "덩어리 시간"이 확보되지 않는다는 문제가 지적되어 주 2회로 빈도를 줄였다. 다행히 1/n배 띄엄띄엄 모인다고 시간에 n배 늘지는 않았다.