작년에 샌프랜시스코에 갔다 오고 나서 오픈 소스 활동을 더욱 열심히 해야겠다는 생각이 들었다. 평소에도 생각하던 일이지만 동기부여가 훨씬 강력히 되었다고나 할까... 물론 재작년에는 개인 프로젝트를 외부에 공개해서 주목도 받아보고 angular-summernote나 AngularJS-Atom처럼 작지만 내가 관리하고 사용하는 사람들이 있는 오픈 소스 프로젝트도 생겼지만 뭔가 좀 더 해야겠다는 생각이었다.

그러다가 생각난 것이 John Resig의 Write Code Every Day라는 글이다. 간단히 요약하자면 매일 코딩하는 습관(?)에 대해서 정리한 글로 그 이전에는 사이드 프로젝트를 할 때 주로 주말에 하거나 가끔은 주중 저녁에 코딩했는데 주말마다 시간이 난다는 보장도 없고 주말에 다 처리해야 하니까 스트레스도 많이 받았고 작업을 띄엄띄엄하다 보니 어떤 작업을 하던 중이었는지 잊는 경우도 많았다는 것이다. 그래서 몇 가지 규칙을 가지고 20주 정도를 매일 코드를 작성했고 그 결과를 정리한 글이다.

저 글 이후에도 John Resig은 511일째 매일 커밋을 하고 있다. 매일 같이 코드를 커밋한다는 것이 어떨지 잘 상상이 안 되었지만 오픈 소스를 더 많이 하고 규칙적으로 코드를 짜기 위한 목표로 괜찮은 방법이라고 생각했다.

일일 커밋

나는 이를 일일 커밋이라고 부르는데 작년 말 부터 해보자고 맘먹고 진행 중이다.

현재 106일째 진행하고 있고(사실 이 글도 100일이 지나면 쓰자고 생각하고 있었다.) 다음과 같은 프로젝트에 커밋을 했다.

• angular-summernote : 메인테이너로 참여하는 프로젝트
• AngularJS-Atom : Angular-UI 팀에서 메인테이너로 참여하는 Atom 패키지
• atom : Atom 에디터
• electron-starter : Electron(구 Atom Shell)
• iojs-ko : io.js 한국어 번역팀
• FRENDS : FRENDS 사이트
• involved : 개인 프로젝트
• ansible-prototype : 아는 사람들과 진행하는 사이드 프로젝트의 프로토타입
• Socket.IO Examples : 2년 동안 버려뒀던 개인 프로젝트
• Slack Invite Automation : Slack 초대를 자동화하는 개인 프로젝트
  
  

일일 커밋의 규칙

일일 커밋을 하려다 보니 어느 정도의 규칙이 필요했다. 사실 말 그대로 Github의 컨트리뷰션 그래프(위의 스크린샷에서 녹색으로 그려지는)을 그리기 위해서라면 코드를 한 줄도 안 짜도 매일 같이 커밋을 찍을 수 있다. 하지만 컨트리뷰션 그래프를 그리는 것이 목표는 아니므로 몇 가지 규칙을 정했다.

• 의미 없는 커밋은 하지 않는다. 평소에도 할만한 커밋만을 작성한다. 나는 평소에도 커밋을 좀 잘게 쪼개서 하는 편이라서 이 규칙에 모호함이 있긴 하지만 스스로 양심에 맡기는 수밖에 없다. 존 레식의 글을 보면 실제 가치 있는 코드만 작성한다고 되어 있는데 어감상은 나보다는 좀 엄격한 느낌이 있긴 하다. 예를 들어 Readme에 의미 없는 줄 바꿈 등은 하지 않지만 필요한 수정을 커밋하거나 라이브러리 버전업이나 추가도 커밋을 한다.
• 치팅은 하지만 어뷰징은 하지 않는다. 이 규칙도 약간 애매한 구석이 있기는 하다. 예를 들어 package.json에 새로운 라이브러리를 추가하고 이를 커밋하는 경우가 많은데 작업하다 보니 나는 평소에도 이렇게 했나 아니면 일일 커밋을 하기 위해서 하나 하는 고민을 종종 하게 됐다.(평소에도 이런 커밋을 별도로 분리하기도 한다.) 약간 꼼수처럼 느껴지는 커밋을 하기도 하는데 여기선 이를 치팅이라고 얘기한 것이고 컴퓨터 시간을 어제로 바꿔서 커밋한다거나 하는 등의 어뷰징은 하지 않겠다는 의미이다.
• 사이드 프로젝트 외에도 오픈 소스에 대한 공헌을 늘려간다. 이는 일일 커밋을 하는 목표이기도 하므로 개인 프로젝트에만 몰두하지 않고 틈나는 대로 다른 오픈 소스 프로젝트의 공헌하는 기회도 늘려간다. 장기적으로 특정 오픈 소스 프로젝트에 지속해서 참여하는 것이 목표이기도 하다.
• 아무리 바빠도 일일 커밋을 최대한 한다. 바쁠 때는 안 하고 안 바쁠 때만 일일 커밋을 하게 되면 이전과 다를 바가 없으므로 바쁘고 안 바쁘고의 상관없이 진행한다.
• 공개 저장소에 커밋하는 내용을 기준으로 한다. 현재 회사에서도 Github을 사용하기는 하지만 공개저장소에 올리는 커밋만을 기준으로 한다. 즉, Github의 공개 컨트리뷰션 그래프에 그려지는 것을 기준으로 한다.
  
  

Github 컨트리뷰션 그래프의 기준

일일 커밋을 진행하면서 그동안은 자세히 몰랐던 컨트리뷰션 그래프에 그려지는 기준을 알게 되었다.

• 컨트리뷰션을 기준으로 그려지는데 푸시를 하면 커밋 개수만큼 그려진다. 하루에 3개의 커밋이 있으면 3으로 그려진다. (색은 상대적으로 많은 개수는 진해지고 적은 개수는 옅은 녹색이 된다.)
• 저장소에 메인 브랜치(보통은 master)에 올라오는 커밋만 그려진다.
• 다른 저장소를 포크한 브랜치에 올린 커밋은 컨트리뷰션 그래프에 그려지지 않는다.
• 포크한 프로젝트에서 풀 리퀘스트를 보내면 컨트리뷰션 그래프로 그래진다. 풀 리퀘스트는 머지되든 Reject이 되든 그려진다.
• 풀 리퀘스트가 머지되면 머지된 커밋도 별도의 컨트리뷰션으로 추가적으로 그려진다.(이 말은 작헙한 커밋과 풀 리퀘스트의 날짜가 다르면 2일의 컨트리뷰션 그래프를 그릴 수 있다는 의미이다.)
• 이슈도 그려지기는 하는데 정확한 규칙은 모르겠다.(이슈로 컨트리뷰션 그래프를 그리는 것은 의미가 없으므로 자세히 확인해 보지 않았다.)
  
  

일일 커밋의 진행

실제로 진행을 해보니 매일 커밋을 한다는 것이 예상했던 것보다 더 큰 일이었다. 연초부터 계속 바쁘기도 했지만 매일 코드를 작성하려니 하루에 낼 수 있는 시간이 그리 많지 않았다. 그래서 한 2, 3일 정도의 커밋을 준비하고 있어야, 즉, 내일은 A를 작업해서 커밋하고 모레는 B를 작업해서 커밋한다고 준비되어 있어야 좀 여유 있게 일일 커밋을 진행할 수 있다. 코드라는 것이 작성해야 지 하면 바로 작성하고 기능 구현이 끝나는 것이 아니라 하다 보면 잘 안되기도 하고 다른 문제로 디버깅에 시간을 쏟게도 되는데 이렇게 되면 그날의 일일 커밋은 실패한다. 그래서 확실한 내용이라서 바로 작성해서 커밋을 하거나 미리 어느 정도 작성을 해 놓고 마무리 작업만 해야 커밋을 할 수 있다.

그래서 좀 큰 작업은 며칠에 걸쳐서 진행하면서 다른 커밋 거리를 찾아서 일일 커밋을 유지해야 했다. 그러다 보니 사이드 프로젝트가 있어야 좀 좋고 나 같은 경우도 이번에 100일을 진행하면서 과거에 귀찮아서 방치했거나 해야지 하다가 놔두었던 것을 모두 꺼내서 리팩토링하고 구현했다. 전에는 귀찮았지만, 이제는 하나하나가 소중하다. 특히 주말이나 시간 여유가 있을 때는 일일 커밋을 해놓고도 다음 커밋을 미리 준비해 놓는다. 작성한 코드를 굳이 커밋 안하고 대기해 놓는 게 의미 있나 싶기도 했지만 일일 커밋을 하면 아무리 준비해놔도 금세 다 소진되므로 나중에는 크게 신경 안 썼다.

그러다 보니 밤부터 새벽까지 작업하는 경우가 많았다. 예를 들어 퇴근하고 밤늦게 커밋하고는 이어서 작업하다가 12시 넘어서 커밋을 하면 2일간의 일일 커밋을 해결할 수 있다. 존 레식은 12시 이전에 커밋하는 것을 규칙으로 정했던데 나는 좀 야행성이라 이 부분은 엄격하게 지키지 않았다. 그리고 저녁에 약속이 있는 날은 새벽에 잠들기 전에 일일커밋을 해놓고 나가야 맘 편히 약속에 갈 수 있다. 최근에는 매우 바빠서 일일 커밋을 하는데 상당히 허덕이면서 좀 의미없을 수도 있는 커밋도 많이 나가기는 했는데 --amend를 활용하는 꼼수도 좀 이용했다.(앞에서 말한 치팅의 범주다.) Git 커밋에는 author 일시와 commit 일시가 따로 있는데 최초 커밋을 하면 author가 찍히고 이후 rebase나 --amend를 해도 바뀌지 않고 컨트리뷰션 그래프에는 author 일시를 기준으로 그려진다. 그래서 정말 시간이 없는 경우에는 일단 커밋을 대충 해놓고 --amend로 다시 내용을 채운다.(꼼수이지만 꽤 유용하다. ㅡㅡ;;)

시간이 좀 날 때는 다른 관심 프로젝트를 돌아다니면서 이슈를 처리할 게 있나 보다가 발견하면 디버깅해서 바로 풀 리퀘스트를 보내기도 하고 오픈 소스를 사용하다가 어떤 문제를 발견하면 바로 수정해서 풀 리퀘스트를 보냈다. 최근에 바빠서 시간을 별로 못 쓰긴 했지만 오픈 소스에서 해결할 이슈를 찾기도 은근히 쉽지 않다.

lqez이 Dive into OpenSource 발표에서 얘기하셨듯이(위 그림은 lqez님의 발표자료에서 발췌했다.) 열정의 선순환이 되는 느낌이다. 회사 코딩만 하면서 좀 답답할 때 오픈 소스나 사이드 프로젝트에 코드를 작성하면서 기분전환을 하고 적당히 작성하고 나면 다시 업무에 몰입해서 일할 수 있다.

그리고 위에서도 얘기했듯이 하루에 일일 커밋에 쏟을 수 있는 시간이 많지 않은데 코드는 보통 작성하는 시간도 시간이지만 어떻게 작성할지를 고민하는 시간이 보통은 더 많다. 그래서 자리에 앉아서 고민하기 시작하면 일일 커밋을 할 수 없으므로 어떻게 작성할지는 미리 생각해 두고 대충의 코드도 머릿속에 그려놨다가 코드는 바로 작성해야 한다. 그러다 보니 평소에 어떻게 작성할지를 생각하는 경우가 많아져서 취미처럼 삶의 한구석에 자리를 잡은 기분이고 업무 코딩과도 균형이 잘 맞게 되는 느낌이다.

이런저런 꼼수도 있고 고민도 있긴 했지만, 결과적으로 보면 예전보다 코딩양 자체는 엄청나게 늘어났다. 코드를 개수나 라인으로 따질 수 있는 것은 아니지만 느껴지는 작성 양이나 고민의 양은 비교도 안 되게 늘어났다. 한 번도 끊지 않고 계속 이어갈 수 있을지는 모르겠지만, 일단은 계속 진행할 생각이다.