깃허브 프로필 링크 하나로 취업이 된다던데?

그렇다. 정말 깃허브 한 줄이면 된다. 하지만 지금 당신의 깃허브는 안녕한가? '소프트웨어 엔지니어'로서 전문성있는 깃허브 관리 방법에 대해 알아보자.

1. 매력적인 프로필 만들기

깃허브 프로필의 사진, 이름, 이메일 계정은 이력서와도 같다. 멋진 정장을 입고, 곱게 화장을 하고, 구두를 신고 면접을 보러가듯이 보는 이로 하여금 좋은 인상을 심어줘야 한다.

sujin-github

사진

프로필 사진은 사람들이 나를 보게 되는 최초의 창이다. 자연스럽고 밝은 분위기, 미소짓는 사진은 신뢰감을 주며 호감을 높인다. 반면 딱딱한 정자세의 취업용 증명 사진은 고리타분하며 트렌드에 뒤쳐진 사람으로 보여질 수 있다. 배경보다 얼굴이 클로즈 업된 사진이 좋다. 일러스트레이터, 연예인 사진, 동물 사진, 만화 캐릭터는 사용하지 말자. 500X500은 온전히 내 모습으로 채워야 한다.

유저네임

화려한 셀럽 개발자는 본명 대신 닉네임 또는 별칭으로 불리기도 한다. 하지만 이 글을 읽는 대부분은 나와 같이 평범한 개발자일 것이다. 우리는 다른 사람들이 나를 기억할 수 있게 내 이름을 더 많이 드러내고 알려야 한다.

'kiyomi'라는 깃허브 닉네임은 귀엽고 친근해 보이지만 전문가로 느껴지진 않을 것이다. 더군다나 여러 사람들과 공동 작업을 할 경우 'kiyomi'가 누군지를 기억하기 어렵다. 유저네임은 sujinlee와 같이 본명을 사용해 영어로 만든다. 유저네임에 sujinlee1212와 같이 숫자가 포함되어 있다면 지금 바로 숫자를 없애자. 깃허브 유저네임은 언제든지 바꿀 수 있으니 걱정하지 않아도 된다.

이메일 주소

이메일 주소가 너무 튀지는 않는지 확인하자. 영어자판에서 한글이름을 타이핑한 아이디(예:dltnwls), 의미가 너무 자극적이거나 부정적인 의미를 내포하는 아이디(예: myloveexo)는 피해야 한다. 아예 취업용 계정을 따로 만들어 사용하는 편이 좋다. 이메일 계정 역시 실명으로 만들어야 한다. 영문 이름이 Sujin Lee일 경우, sujin.lee, sujinlee, sujin 등으로 만들 수 있다. 만약 원하는 계정을 사용할 수 없다면, 아이디 끝에 dev, tech 등을 붙여 지원하는 직무와 어울리는 계정을 만든다. (예: sujin.tech 또는 sujin.dev) 개인 웹사이트 도메인이 있다면 별도 메일 호스팅을 사용해 contact@sujinlee.me와 같은 메일 주소를 만들어 사용하는 것도 좋다.

프로젝트

customize-repo

프로필 페이지 최상 단에 있는 pinned repositories를 클릭해 최소 3가지 이상 프로젝트를 고정시킨다. 기여한 오픈 소스 리퍼지토리가 있다면 반드시 메인 화면에 고정시킨다.

2. 1일 1커밋

year-of-code-git

풀이 듬성듬성난 마당보다 잘 가꿔진 푸른 잔디밭이 더 보기 좋다. 초록색으로 꽉 찬 커밋 히트맵(commit heatmap)은 당신의 열정과 성실함을 보여준다. 위 히트맵은 미국 샌프란시스코에서 일하고 있는 Jackie Luo의 깃허브이다. 그녀는 "깃헙 커밋의 해(A Year of committing to Github)"라는 프로젝트를 실시해 일년 간 하루도 빠짐없이 매일 커밋하기를 실천했다. 개발자는 매일마다 새로운 것을 배우고 성장해야 한다. 이제부터라도 매일 조금씩이라도 코딩하고 꾸준히 커밋하는 습관을 길러보자. "잔디(커밋)"를 하나 둘씩 심다보면 코딩에 대한 자신감은 물론 성장하는 나의 모습을 보며 큰 성취감을 느낄 수 있다.

show-more-commit

일부 커밋 그래프가 보이지 않는다면 Contribution settings 버튼을 클릭해 Public and private contributions을 선택했는지 확인한다. 자세한 내용은 '내 프로필에 커밋 그래프 기록이 보이지 않아요'를 참고한다.

3. 올바르게 커밋하기

커밋 이력은 내가 개발자로서 일하는 모습과 태도를 보여주는 객관적인 지표이다. 논리적이고 체계적으로 일하며, 꾸준하게 발전하고 있다는 모습을 보여줘야 한다.

커밋 단위

커밋은 최종 목표를 달성하기 위한 이정표와 같다. 초보자가 가장 많이 하는 잘못된 습관 중 하나는 한꺼번에 모든 파일과 코드를 커밋하는 것이다. 작은 단계로 커밋하여 코드 개발 과정을 가시적으로 보여줘야 한다.

메서드 리팩터링이나 새로운 메서드 또는 클래스를 추가할 때마다 커밋한다. 실험이나 성능 튜닝을 할 때도 각 단계별로 커밋한다. 소스 코드 변경 내역이 없을 때는 커밋하지 않는다.

커밋 메시지 작성법

자신만의 커밋 메시지 작성 원칙을 정하고 일관성있게 커밋해야 한다. 이미 많은 커밋 작성 가이드가 있다. 이 중 유다시티의 커밋 메시지 작성 가이드를 소개한다.

커밋 메시지는 제목, 본문(선택), 꼬리말(선택) 세 부분으로 작성한다.

Type: 제목(Title)

본문(Body)

꼬리말(Footer)

제목

커밋 메시지 제목은 docs: Edit README.md to include New Features Use-Cases 와 같이 작성한다.

제목은 타입 라벨을 맨 앞에 붙어 타입(Type): 제목 형식으로 작성한다. 각 타입 라벨은 아래와 같다.

feat: 새로운 기능을 추가할 경우
fix: 버그를 고친 경우
docs: 문서 수정한 경우
style: 코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
refactor: 프로덕션 코드 리팩터링
test: 테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음)
chore: 빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)

제목의 처음은 동사 원형으로 시작하고 첫 글자는 대문자로 작성한다. "Fixed", "Added", "Changed" 등 과거 시제가 아닌 "Fix", "Add", "Change"로 명령어로 시작한다. 총 글자 수는 50자 이내며 마지막에 마침표(.)를 붙이지 않는다.

본문 (선택)

본문은 커밋의 상세 내용을 작성한다. 제목과 본문 사이에 한 줄 비운다. 본문은 한 줄에 72자 이내로 작성한다. 한 줄을 띄워 문단으로 나누거나 불렛을 사용해 내용을 구분한다.

꼬리말 (선택)

꼬리말에는 이슈 트래커 ID를 추가한다.

Resolves: #123
See also: #456, #789

샘플

지금까지 잘못된 방법으로 커밋했다면 커밋 히스토리를 수정하거나 히스토리 전체를 삭제하는 방법이 있다.

4. 프로젝트 소개 글 작성하기

프로젝트 문서는 음식 레시피와 같다. 레시피를 보는 대부분은 처음 음식을 만들거나 요리에 익숙하지 않는 이들이다. 조리법은 물론 재료, 준비물 등이 자세하고 완벽하게 설명되어 있어야 초보자들도 제대로 된 음식을 만들 수 있다. readme.md 역시 처음 보는 이들을 위해 프로젝트 모든 것을 적어놓은 레시피와 같다.

하루에도 수만 개의 오픈 소스 프로젝트가 쏟아지고 있다. 오픈 소스 생태계는 드넓은 바다와 같다. 누군가 내 프로젝트에 관심을 가져주는 것은 매우 고마운 일이다. readme.md 만으로도 얼마든지 다른 개발자들을 끌여들여 내 프로젝트에 참여시킬 수 있다.

awesome-readme에서 우수한 readme를 큐레이션했다. 이 중 몇 가지 모범 예제를 참고해 스스로 목차를 만들어보자.

readme.md 파일은 마크다운 문법으로 작성한다. 문법이 어렵지 않고 학습 시간도 많이 걸리지 않는다.

readme.md 파일에는 기본적으로 프로젝트명, 프로젝트 소개, 설치 방법, 사용 예제, 개발 환경 설정 방법, 기여 방법, 변경 로그, 라이센스 및 작성자 정보를 포함해야 한다.

아래 readme.md 템플릿을 참고해 멋진 프로젝트 소개 글을 작성해보자. 좀더 간결한 템플릿(국문)도 있다.

프로젝트 제목

프로젝트 제목은 매우 중요하다. 초보 개발자라면 제목만으로도 어떤 기술을 사용하여 무슨 프로젝트를 만들었는지 상대방이 이해할 수 있게 직관적으로 작성한다.
프로젝트 소개 웹 사이트도 잊지 말고 추가한다. heroku, surge.sh, gh-pages 등 무료 호스팅 서비스가 많으니 이를 적극적으로 활용한다. 특히 gh-pages는 마크다운으로 정적페이지를 만들어주니 꼭 사용해보자.

프로젝트에 사용한 기술, 분야, 주제 등 태그도 추가해 프로젝트 메인 페이지를 풍성하게 만든다.
intro-github-tag

프로젝트 내용

짧은 소개 문구와 한 문단 분량의 프로젝트 내용을 적는다. 프로젝트의 목적과 동기, 주요 기능이 잘 드러나있어야 한다.

직접 개발 환경을 로컬 컴퓨터에 구축하는 사용자는 많지 않다. 무엇보다 사용자에게 프로젝트 실제 데모를 보여주는 것이 중요하다. 배포를 하거나 설치가 필요한 프로그램이라면 반드시 데모를 추가하자. 스크린 캡쳐 프로그램으로 스크린 녹화를 하고 gif 파일로 변환한다. 영상이 필요하면 유투브에 올리고 링크를 건다.

(옵션) shields.io에서 뱃지를 선택해 패키지, 배포, 소셜 네트워크, 코드 커버리지, 다운로드 수, 버전 등을 명시해 좀더 시각적으로 표현할 수 있다.

설치 방법

실력과 관계없이 누구나 개발 환경을 설치할 수 있어야 한다. 사용자가 설치 과정 중 좌절하지 않게 최대한 자세하고 친절하게 작성한다. 운영 체제 별(OS X/Linux/Windows 등) 설치 방법도 작성한다. 가능한 사용자가 간단한 명령어로 설치를 끝내도록 설치 과정을 간결하게 만드는 것이 좋다.

코드 예제

설치 이후 실제 사용 방법 가이드를 작성한다. 코드 예제와 실제 적용 사례를 보여준다.

개발 환경 설정 방법

잠재적인 컨트리뷰터가 당신의 프로젝트에 기여할 수 있도록 명확한 가이드를 제시한다. 개발 의존성 설치와 자동 테스트 슈트를 실행해 사용자가 개발 환경을 올바르게 설정했는지 확인할 수 있게 한다. 또한 신규 버전 소프트웨어를 빌드하고 릴리스하는 방법도 작성한다.

기여 방법

깃허브 리퍼지토리 대부분은 오픈 소스다. 누구나 소스 코드를 다운받아 개발 환경을 구축할 수 있고 개선시킬 수 있다. 당신의 프로젝트에 관심을 가진 누군가 직접 기여할 수 있다. 따라서 개발 프로세스와 기여 방법에 관한 명확한 지침을 제공해야 한다.

로그 변경

사용자는 마지막 버전과 비교하여 어떤 변경 사항이 있었는지 확인할 수 있어야 한다. 기능 개선과 수정 내역을 함축적으로 정리하여 로그 변경 히스토리를 관리한다.

크레딧

오픈 소스 프로젝트를 사용해 만들었거나, 누군가로부터 큰 도움을 받았거나, 크게 기여한 사람이 있다면 잊지 않고 꼭 언급하자.

라이센스

라이센스를 명시하고 디렉터리에 LICENSE.txt를 포함시키자.  오픈 소스 라이센스(영문), 오픈소스 SW 라이센스 종합시스템(국문) 라이센스 목록을 확인할 수 있다. 가장 많이 쓰는 라이센스는 MIT 라이센스, Apache 2.0 라이센스, ISC 라이센스, BSD 라이센스다.

연락처

연락처는 프로젝트 신뢰성을 뒷받침해준다. 프로젝트 담당자 또는 팀원들의 깃허브 프로필 링크, 트위터, 이메일 등 연락처 정보를 기입한다. 별도로 전문적이고 공식적인 트위터를 만들고 프로젝트 진행 상황과 업데이트 소식을 알리며 적극적으로 내 프로젝트를 홍보하자.

5. 프로젝트 관리하기

코드 이외에도 깃허브는 개발자의 프로젝트 운영과 관리 능력을 보여준다. 프로젝트 관리란 실제 어떻게 내가 프로그램을 만들지 계획을 세우고 그 계획을 실행하는 기술이다. 개발자라면 모든 개발 진행 상황을 트래킹하고, 관리하고, 문제를 해결하고, 예측하지 못했던 문제를 해결해야 한다.

프로젝트 보드 사용

깃허브에는 트렐로와 유사한 프로젝트 보드 기능이 있다. 화이트보드에 포스트잇으로 이슈를 관리하는 모습을 그대로 웹 상으로 옮긴 것으로 개발 현황을 한 눈에 파악하기 쉽다.

프로젝트 보드로 사용해 프로젝트 작업을 구성하고 우선 순위를 지정할 수 있다. 보편적인 기능부터 특정 기능 작업, 로드맵을 작성하고배포 체크 리스트을 관리할 수 있다. 제일 큰 장점은 깃허브에 있는 이슈, 풀리퀘스트 테스크를 끌어올 수 있다는 것이다.

이슈 관리하기

기본적으로 깃허브 내 리퍼지토리는 오픈소스이다. 누구나 내 프로그램을 설치하고 실행해 볼 수 있다. 내가 만든 프로젝트에 많은 사람들이 관심을 가지기 시작한다면 자연스레 버그와 이슈 트래커가 쌓이게 될 것이다. 이 때 사람들이 작성한 이슈 내용과 작성 양식이 서로 다르고 이를 분류하고 내용을 파악하는데 큰 어려움이 따른다. 이를 위해 깃허브에서는 최근 이슈 템플릿 기능을 만들었다. 작성자가 새로운 이슈를 작성 시, 먼저 유형을 선택하고 제시된 양식에 맞춰 작성할 수 있다.

이슈 템플릿 생성 방법은 다음 링크에서 확인할 수 있다. 바벨(Babel.js)에서는 아래와 같은 템플릿을 사용한다.

6. 오픈 소스 기여하기

오픈 소스(open source)란 단순히 소스 코드를 마음대로 사용할 수 있다는 뜻이 아니다. OSI(Open Source Initiative)에서 정의하는 오픈 소프트웨어 조건을 준수해야 한다. 자유 배포(Free Redistribution), 소스 코드 공개(Source Code Open), 2차적 저작물(Derived Works), 소스 코드 수정제한(Integrity of The Author's Source Code), 개인이나 단체에 대한 차별 금지(No Discrimination Against Persons or Groups), 사용분야에 대한 제한 금지(No Discrimination Against Fields of Endeavor) 등 10개 항목이 있다. 누구나 오픈 소스 프로젝트에 참여할 수 있으며 이를 재가공하거나 활용하여 창의적이고 흥미로운 프로젝트를 만들 수 있다.

오픈 소스 활동을 통해 관심있는 분야와 기술을 수련할 수 있고 디버거, 버전 제어 시스템, 이슈 트래커 등을 통해 실제 소프트웨어 개발 과정을 경험할 수 있다. 또한 프로젝트에 새 기능을 추가하거나 개선을 하며 문제 해결 능력을 크게 향상시킬 수 있다.

많은 기업에서 오픈 소스 프로젝트 경험이 있는 개발자를 환영하고 있다. 이력서 내 오픈 소스 프로젝트 경험을 강조해서 작성하는 것이 좋다.

오픈 소스가 생소하다면 먼저 내가 사용 중인 라이브러리, 프레임워크의 깃허브 리퍼지토리를 찾아보는 것부터 시작해보자. 리퍼지토리에 별(star)을 달아주고 오픈 소스 메인테이너, 컨트리뷰터가 누구인지 찾아보고 팔로우해보자. https://github.com/explore 에서도 인기있는 오픈 소스 프로젝트를 탐험할 수 있다. 리퍼지토리 첫 페이지 상단 위에 [watch > watching] 버튼을 클릭하면 알림을 받을 수 있으니 오픈 소스 프로젝트가 어떻게 진화하고 발전하는지 눈여겨보자.

watching-github

오픈 소스 활동은 코드를 기여하는 것 이외에도 다양한 활동을 할 수 있다.

  • 이슈 고치기 - 풀리퀘스트 보내기 : 일반적인 오픈 소스 기여 방법이다. 이슈 리스트(예: react 이슈리스트 )를 확인하고 직접 고쳐 풀리퀘스트를 보내보자.

  • 오탈자 고치기 : 코드로 기여하기 어렵다면 문서나 내 오타를 고치는 것부터 시작하자. 아주 사소한 세미콜론, 따옴표, 맞춤법도 괜찮다.

  • 이슈 제기하기 : 버그, 기능 개선 요청, 문서 수정 요청 등 이슈를 제기하거나, 해결 방법을 댓글로 알려주는 것도 오픈 소스에 기여하는 것이다.

  • 번역하기 : 공식 문서와 도움말을 한국어 번역해보자. 페이스북 또는 깃허브에서 한국어 사용자 그룹 커뮤니티를 찾아보고 번역 프로젝트에 동참하자.

그 외에도 공식 문서 또는 도움말 작성하기, 예제 제작하기, 이슈 관리하기 등 다양한 활동을 통해 오픈 소스에 기여할 수 있다.

이력서 제출 전, 깃허브 체크리스트를 통해 깃허브가 잘 관리되어 있는지 스스로 자가진단 해보자. 모든 준비가 끝났다면, 분명 좋은 소식이 곧 찾아올 것이다.

체크리스트

깃허브 활동 이력

[ ] 완성된 프로젝트 리퍼지토리가 3개 이상 있다.
[ ] 최근 2주 동안 이상 커밋 했다.
[ ] 최소 1개 이상 기여한 오픈소스 프로젝트가 있다.

프로필

[ ] 유저네임은 본명을 사용했다.
[ ] 프로필 사진은 웃고 있으며, 밝고 긍정적인 느낌을 준다.
[ ] 현재 소속/직장/단체, 거주 지역, 이메일 주소, 홈페이지 정보를 기입했다. (소속된 기업의 깃허브 기관 계정이 있다면 '@' 로 태그했다.)

프로젝트

[ ] 커밋 메시지 작성 규칙에 따라 올바르고 일관성있게 작성했다.
[ ] 다른 사람의 리퍼지토리를 포크하여 기여한 이력이 있다.
[ ] 프로젝트 이름과 상세 설명을 전문성있게 작성했다.
[ ] 가장 최근 완성한 프로젝트 모두 README.md 파일에 상세 설명을 작성했다.
[ ] 관심있는 리퍼지토리에 별(star)을 달았다.

photo credit : github store
refs:

  1. Udacity - Github Review Rubrics https://review.udacity.com/#!/rubrics/52/view
  2. Udacity - LinkedIn and GitHub Profiles
    https://career-resource-center.udacity.com/linkedin-github-profiles