역사와 학술적 배경
레이먼드(Raymond, 1999)의 '성당과 시장'은 공개 협업 개발의 문화를 설명했고, 러너·티롤(Lerner & Tirole, 2002)은 개발자가 오픈소스에 기여하는 이유로 '경력 신호' 동기를 제시했어요. 폰 히펠·폰 크로그(von Hippel & von Krogh, 2003)는 이를 사적-집단 혁신 모델로 정리했어요. 다비시 외(Dabbish et al., 2012)는 깃허브의 투명한 활동 기록이 협업과 평가에 쓰인다는 '소셜 코딩' 연구를, 말로 외(Marlow et al., 2013)는 사람들이 활동 흔적으로 개발자 인상을 형성한다는 점을 보였어요. 칼리암바카우 외(Kalliamvakou et al., 2014)는 깃허브 데이터만으로 판단할 때의 함정을 지적했어요.
핵심 내용
일반적으로 대표 저장소 몇 개를 고정하고, README에 목적·기술 스택·실행 방법·주요 기능·트러블슈팅을 정리해요. 커밋 메시지와 이슈·PR 기록이 협업 방식을 보여준다고 알려져 있어요. ※ 법령·제도·비자 요건과 채용 관행은 바뀔 수 있으니 고용노동부·관계 기관 공지, 현행 법령, 실제 공고를 확인하세요.
실무와 체크포인트
잔디(기여 그래프)의 양보다 설명 가능한 코드 품질이 더 중요하다는 조언이 많아요. 비밀번호·API 키 같은 민감 정보가 저장소에 올라가지 않았는지 꼭 확인하세요. 포트폴리오와 이력서에 링크를 걸고, 부트캠프 팀 프로젝트는 본인 기여를 명시하세요.
자주 묻는 질문
- 잔디가 비어 있으면 불리한가요?
- 기업마다 달라요. 꾸준함보다 프로젝트 설명력이 중요하다는 의견이 많아요.
- 포크한 저장소도 넣나요?
- 본인 기여가 분명할 때만 의미가 있어요.
출처 검토일: 2026-10-26
캠퍼스다운 취업정보: 2026 깃허브 잔디, 개발자 취업에 도움 될까? 기여 그래프 집계 기준과 프로필 README 정리법
참고문헌
- Raymond, E. S. (1999). The Cathedral and the Bazaar. O'Reilly.
- Lerner, J., & Tirole, J. (2002). Some simple economics of open source. Journal of Industrial Economics, 50(2), 197–234.
- von Hippel, E., & von Krogh, G. (2003). Open source software and the "private-collective" innovation model. Organization Science, 14(2), 209–223.
- Dabbish, L., Stuart, C., Tsay, J., & Herbsleb, J. (2012). Social coding in GitHub: Transparency and collaboration in an open software repository. Proceedings of CSCW 2012, 1277–1286.
- Marlow, J., Dabbish, L., & Herbsleb, J. (2013). Impression formation in online peer production: Activity traces and personal profiles in GitHub. Proceedings of CSCW 2013, 117–128.
- Kalliamvakou, E., Gousios, G., Blincoe, K., Singer, L., German, D. M., & Damian, D. (2014). The promises and perils of mining GitHub. Proceedings of MSR 2014, 92–101.
- 고용24(고용노동부). https://www.work24.go.kr
- 국가법령정보센터. https://www.law.go.kr