왜 다른 사람의 레포를 훔쳐봐야 할까요?

개발을 배울 때 가장 자주 듣는 조언은 "좋은 코드를 많이 읽어 보세요"예요. 그런데 막상 유명한 레포에 들어가 보면 폴더는 수십 개고 파일은 수백 개라서, 어디서부터 읽어야 할지 몰라 조용히 탭을 닫게 돼요.

이 글에서는 조금 다른 이야기를 해 보려고 해요. 레포에서 정말 훔쳐볼 만한 것은 완성된 코드가 아니라, 그 코드가 만들어진 과정이라는 이야기예요.

완성된 코드는 결과만 보여줘요

지금 보이는 코드는 수많은 결정이 끝난 뒤의 모습이에요. 왜 이 구조가 됐는지, 처음에는 어떻게 짰다가 무엇 때문에 바꿨는지, 누가 어떤 부분을 맡았는지는 파일만 읽어서는 알 수 없어요.

반대로 레포의 기록에는 이런 것들이 고스란히 남아 있어요.

튜토리얼은 정답만 알려 주지만, 레포의 기록은 정답에 이르는 길을 보여줘요. 그래서 잘 굴러간 프로젝트 하나를 제대로 들여다보는 일이 강의 여러 개를 듣는 것보다 오래 남아요.

처음 일주일 동안 무엇을 만들었는지 보면 그 팀이 무엇을 가장 중요하게 여겼는지 알 수 있어요. 로그인부터 만든 팀이 있고, 핵심 화면 하나를 먼저 완성한 팀이 있어요. 배포를 첫날에 끝낸 팀도 있고, 마지막 날에야 붙인 팀도 있어요.

내 프로젝트가 늘 중간에 엎어진다면, 끝까지 간 프로젝트가 초반에 무엇을 먼저 했는지를 보는 것만으로도 힌트를 얻을 수 있어요.

커밋 하나에 파일이 몇 개나 바뀌는지, 하루에 커밋이 몇 번 올라오는지를 보세요. 잘 굴러가는 팀은 대체로 작업 단위가 작아요. 작게 쪼개야 되돌리기 쉽고, 다른 사람이 읽기 쉽고, 충돌이 덜 나기 때문이에요.

커밋 메시지 앞에 feat, fix 같은 말머리를 붙이는지, 브랜치 이름에 이슈 번호를 넣는지, PR을 올릴 때 어떤 항목을 적는지 같은 것들이에요. 이런 약속은 문서로 정리되어 있지 않은 경우가 많아서, 실제 기록에서 읽어 내야 해요.

혼자 만든 것처럼 보이는 프로젝트도 들여다보면 역할이 나뉘어 있어요. 한 사람이 화면을 도맡고 다른 사람이 서버를 맡았는지, 모두가 조금씩 다 건드렸는지에 따라 팀의 모양이 완전히 달라요. 내가 다음 프로젝트에서 어떤 자리를 맡고 싶은지 그려 보는 데 도움이 돼요.

처음부터 코드를 열지 않는 것이 요령이에요. 아래 순서를 추천해요.

이 순서로 보면 코드를 열었을 때 이미 맥락을 알고 있어서 훨씬 잘 읽혀요.

문제는 이 과정이 손이 많이 간다는 점이에요. 커밋 수백 개를 하나씩 열어 보고, 누가 얼마나 작업했는지 세고, 커밋 메시지에서 규칙을 찾아내려면 한두 시간은 금방 지나가요.

WhoIsLoafing은 이 번거로운 부분을 대신해 줘요. 공개 레포 링크 하나만 넣으면 아래 내용을 대화로 풀어서 알려드려요.

로그인도 필요 없어요. 평소에 궁금했던 레포가 있다면 링크부터 넣어 보세요.

마지막으로 두 가지만 기억해 주세요.

첫째, 훔쳐보는 대상은 방식이지 코드가 아니에요. 다른 사람의 코드를 그대로 가져다 쓰려면 그 레포의 라이선스를 꼭 확인해야 해요. 일하는 방식을 참고하는 데에는 그런 제약이 없어요.

둘째, 숫자는 사람을 평가하는 도구가 아니에요. 커밋 수가 적다고 기여가 적은 것이 아니고, 기록에 남지 않는 일도 많아요. 레포를 들여다보는 목적은 누군가를 깎아내리는 것이 아니라 더 나은 방식을 배우는 것이라는 점을 잊지 말아 주세요.

궁금한 레포가 떠올랐나요?

공개 레포 링크만 넣으면 로그인 없이 바로 분석해 드려요.

내가 하는 협업 방식에 갇혀있지 마세요!