메리 크리스마스! 오늘은 즐거운 크리스마스입니다. 이 글을 작성하는 때가 크리스마스이기에 첫 문구를 크리스마스로 시작하게 되었답니다? 저는 연인이 없는지라 집에서 나 홀로 집에나 보고 코딩이나 해야겠습니다. 어제 퇴근하다가 불현듯 떠올라서 hELLO 티스토리 스킨의 크리스마스 테마를 구상해보려고 했는데, 역시 디자인 능력이 꽝인 저로서는 디자인은 몸에 맞지 않는 옷이더군요. 이제는 친절한 디자이너 분의 기여를 기다릴 수밖에 없겠습니다.
이번에 이야기해볼 사항은 깃허브에 대한 이야기다. 깃허브 포트폴리오라고 하면 대부분 깃허브 페이지(Github Pages)를 포트폴리오로 작성하는 방법을 이야기하는 글이 많은데, 이 글에는 깃허브 페이지가 아니라 깃허브 그 자체를 이야기해본다.
개발자로 취직할 때 중요한 것은 코딩 테스트, 그리고 포트폴리오가 있다. 오카방에 있다 보면 다양한 사람들의 깃허브를 볼 기회가 종종 있는데, 어떤 깃허브는 정말 괜찮다 싶은 것도 있는 반면, 또 어떤 것은 너무 아니다 싶은 것이 있다. 나도 경험이 부족하기에 어떤 깃허브가 '좋은' 것인지 명확히 답을 내리는 것은 불가능하지만, 그 반대로 '나쁜' 것에 대해서는 이야기할 수 있을 것 같다. 내가 개발자를 채용하는 입장이 되었을 때, 뒤도 안 돌아보고 컷(Cut)할 깃허브에 대해서.
요즘에는 포트폴리오의 일부로써 깃허브 주소를 요구하는 기업들이 많아졌다. 개발자에게 깃허브는 생각보다 중요하다. 오픈소스 생태계는 이제 없어서는 안 될 존재가 되었다. 그리고 그 오픈소스의 허브에는 깃허브가 존재한다. 같은 개발자가 보았을 때, 깃허브만으로도 이 개발자가 어떤 것에 관심 있는지, 어떤 언어를 주로 쓰는지, 오픈소스에 대한 기여는 어느 정도 했는지, 조금 더 나가가면 프로젝트에 작성된 코드의 스타일을 파악할 수 있는 수단이 될 수 있다. 나는 깃허브를 정말 중요시 여기며 어떤 개발자인지를 판단할 때 주요 지표가 되어야 한다고 여긴다.
깃허브를 포트폴리오로써 제출하고 싶다면, 깃허브를 관리함에 있어서 주요 요소가 될 수 있는 것들에 대해 살펴보고 이에 대해 고민해보자.
1일 1커밋은 정말 유용할까?
깃허브에는 많은 것들을 표현할 수 있는데, 가장 먼저 많은 사람들 입에서 오르락 내리는 잔디에 대해 이야기해보자. 잔디는 깃허브에 커밋을 하면 자동으로 채워지며 얼마나 활동을 했는지를 보여주는 지표다. 그래서 TIL(Today I Learned)과 같은 프로젝트를 진행함으로써 1일 1커밋을 지향하는 개발자들도 많다. 물론 나는 잔디는 그다지 신경 쓰지 않는다. 코딩을 대부분 매일같이 하니까 연연하지 않기 때문이다.
개인적인 의견으로, 1일 1커밋이 필요한 사람은 잔디라는 동기가 없으면 에디터를 잘 켜지 않는 사람들이다. 아직은 스스로에게 개발이 일상화되지 않았기에 동기가 필요하다면 1일 1커밋은 충분히 유효하며. 처음으로 깃허브를 관리해보고자 한다면 괜찮은 수단이 되리라 생각한다.
여기서 문제가 될 수 있다고 생각되는 점은 매일 잔디를 채워야한다는 강박을 가져서 개발 자체보다 잔디에만 집착하게 될 수 있다는 점이다. 영양가 없는 커밋을 욱여넣음으로 인해 잔디를 채우려고 하는 것과 그로 인해 받아야 하는 강압감은 오히려 개발에 대한 흥미를 떨어뜨리고 마치 숙제를 하는 기분이 들게 한다. 가뜩이나 요즘 모바일 게임도 숙제 게임이 되어버려 하기 싫어지는 마당에 개발까지 숙제하는 기분으로 한다면 얼마나 우울한 일을 하고 있는 것인지 생각하기도 싫다.
텅―
아무것도 없는 비어있는 잔디보다 나쁜 경우가 있다면(물론, 비어있는 잔디도 조금은...), 취직 이후에는 잔디가 귀신같이 끊기는 경우다. 취직을 위해 1일 1커밋으로 잔디를 작업해놨는데, 취직을 한 이후부터는 잔디가 하나도 안 채워지는 그런 상황. 이것은 누가 봐도 개발에 대한 업(業) 보다 취직을 위해 개발한다는 뉘앙스를 풍긴다고 볼 수 있어서 직업적인 열의가 느껴지지 않는다고 여긴다.
잔디가 때로는 성실함의 척도로 사용될 여지가 있기는 하지만, 개발자 개인에게 있어서는 여러모로 무게감을 느낄 수도 있으며, 자칫 잘못하다는 나쁜 방향으로 보일 수 있다. 1일 1커밋에 집착하기보다는 적어도 작년보다는 더 많은 커밋을 함으로 인해 개발자의 주요 가치라고 여겨지는 성장을 보여주는 것이 더 좋다고 생각한다. 1일 1커밋을 그 자체에 집착하기보다는 왜 우리가 1일 1커밋을 하려 하는지 그 본질적인 이유를 되돌아볼 필요가 있다. 그저 비어있는 잔디를 심으려하는 건지, 아니면 이렇게 해서라도 에디터를 켜게 하려고 스스로에게 하는 약속인 것인지.
반짝반짝 작은 별
깃허브의 또 한가지 기능은 별(Star)이다. 내가 다른 개발자로부터 별을 받거나 아니면 다른 프로젝트에 별을 누를 수 있다. 개발을 많이 하고 오픈소스를 찾아볼수록 접한 라이브러리와 프레임워크가 늘어날 것이고 관심분야에 따라 주력으로 쓰이는 것도 많이 알 수 있을 것이다. 나는 백엔드(PHP/Laravel)와 비트코인, 이더리움(go-ethereum) 등 블록체인 플랫폼에 관심이 있고, 취미로는 프론트엔드(Javascript/Vue)도 조금씩 하고 있는데, 그에 따라 별이 찍혀있다.
내 프로젝트는 이 만큼의 가치가 있어요
2019년, SKT 에서는 오픈소스 생태계에서 차지하는 깃허브 별의 가치를 알고 이를 이용하고자 자신들이 개발한 빅데이터 분석 솔루션인 메타트론(Metatron)에 대해 어느 한 이벤트를 기획하기에 이른다. 그 이벤트란 일반인을 대상으로 깃허브에 회원가입하고 프로젝트에 별을 누르면 "무려" 스타벅스 기프티콘을 준다는 이야기였다.
해당 이벤트가 어느정도 성공하면서 메타트론의 깃허브 별은 빠르게 쌓이기 시작했는데, 어느 날 프로젝트에 어떤 이슈가 등록된다.
https://github.com/metatron-app/metatron-discovery/issues/2405
Stop abuse Github Star
이슈가 달리고 나서 해당 이벤트에 대해 개발자들 사이에 좋지 않은 소문이 퍼지고, 언론에 기사도 나기 시작한다. 이상을 감지한 메타트론의 주요 개발자는 다음과 같은 발언을 하기에 이른다.
"이건 저희가 살기위한 몸부림으로 이해해주셨으면 합니다."
...
"그리고 사실 저희가 개발하는 제품에 대해 한번 더 들여다볼 수 있는 기회가 된다면,
전 개인적으로 개발 외 적으로도 저는 어떠한 짓도 마다하지 않을 준비가 되어있습니다."
https://github.com/metatron-app/metatron-discovery/issues/2405#issuecomment-516196067
이 발언을 계기로 문제가 퍼지면서 최종적으로 메타트론의 깃허브 별은 결국 초기화를 하기에 이르렀으며 현재는 360개 정도를 가지고 있다. 해당 이벤트가 한창 진행 중이었을 때는 2K 이상이었던 것으로 기억이 나는데, 아무튼 지금과 생각하면 상당한 격차가 있다.
해당 이슈에도 나와있듯이 깃허브의 별은 인스타그램, 페이스북의 SNS 의 좋아요와는 그 무게감이 다르며, 기술자인 개발자들 또는 그 도구를 사용하는 사람이 판단하기에, 이 프로젝트가 유용하고 가치 있기에 추천한다는 의미가 내포되어 있다. 내 경험상 별을 받는 것은 생각보다 쉬운 일이 아니다. 프로젝트를 홍보해야 함은 물론, 그들에게 어떤 가치가 주어지는지를 명확하게 이야기할 수 있어야 한다.
"Star를 받기 위해 전 세계의 수많은 개발자들과 꿈나무들이 얼마나 노력하는지 단 한 번이라도 생각해 보셨다면 이런 식으로 변명을 하실 순 없습니다."
https://github.com/metatron-app/metatron-discovery/issues/2405#issuecomment-516202272
SKT 의 이벤트가 문제가 되었던 것은 대기업의 자본력을 사용하여 깃허브의 별을 매수하여 오픈소스 생태계 가치를 훼손하고 프로젝트를 부풀림으로 인해 어뷰징 했다는 점이다. 자신들이 살기 위해 몸부림친다는 것을 핑계 삼아 다수의 개발자가 사용하는 오픈소스 생태계를 어지럽히려 드는 행위는 옳은 행위라고 판단할 수 없다. 어뷰징으로 신고가 되어 프로젝트 자체가 닫히는 수모는 겪지 않았으나 한국기업이 가지고 있는 깃허브 별에 대한 인식에 있어서는 나쁜 선례를 남기게 되었다.
다른 개발자에게 별을 받는다는 것은 그만큼 가치 있는 일이기 때문에 이 또한 깃허브를 포트폴리오로 활용할 때 주요 지표로 사용되기에 충분하다고 판단한다. 나는 내가 개발을 함에 있어서 느끼고, 깨닫고, 진행한 프로젝트에 대해 외주 프로젝트가 아닌 이상은 대부분 퍼블릭으로 공개되어 있다. 오픈소스에 기여하고 인정받는 일은 회사에서 치고받고 싸우는 것보다 개인적으로 직업적인 만족감에 있어서는 더 즐거운 일이다.
이 분야에 관심 있어요
깃허브에서는 다른 사람이 내가 어느 프로젝트에 별을 눌렀는지 다 알 수 있게 되어있다. 이는 곧 내가 어느 분야에 관심이 있는지를 보여주는 수단이 된다. 만약 인공지능에 관심이 있는데 그 유명한 텐서플로우나 파이토치에 별도 하나 안 찍혀있다면 진정성이 있다고 보일 수 있을까? 이 사람이 개발을 하면서 얼마나 많은 라이브러리와 프레임워크를 탐방해오고 눈여겨봤는지를 보여주는 지표로 별을 사용하는 것은 약간은 타당하다고 생각한다.
왜 "약간" 이냐면, 아무리 깃허브 별이 가지는 의미가 추천 어쩌니 가치가 저쩌니 해도 결국에는 별을 누르는 행위는 클릭한 번으로 끝나기 때문에 이를 악용하여 무지성으로 관련없는 프로젝트에 별을 던질 수 있도 있기 때문이다. 실제로 별을 누르는 행위는 단순하기 때문에 결국 페이스북의 좋아요나 다름 없다는 의견을 던지는 사람도 있다.
"깃헙스타는 페이스북 좋아요, 트위터 리트윗이랑 비슷한거 맞아요. 본인은 엄청 진중하게 생각하는지 모르겠지만 이미 이슈 링크 올라간 외국사이트 댓글반응 보면 동의하지도 않고 의미 부여하지 않는 댓글도 많아요. 한국인들이 발광하죠. 그냥 페이스북 좋아요 유도 프로모션쯤으로 보는건데."
https://github.com/metatron-app/metatron-discovery/issues/2405#issuecomment-516293310
한 방에 모든 것을 맡긴다
깃허브에는 프로젝트를 진행하면서 발생하는 각종 수정사항들에 대해 커밋이라는 것을 할 수 있다. 프로젝트를 공개 프로젝트로 올려놓는 것까지는 좋다. 그런데 커밋 기록을 보면 놀랍게도 단 한 개인 경우가 있다. 깃을 기반으로 진행하지 않아서 그런지는 몰라도 한 개의 커밋만으로 프로젝트의 모든 것을 설명하고 있는 것이다.
커밋 기록에는 내가 이 프로젝트를 진행하면서 겪었던 온갖 고민, 어떻게 하면 이 기능을 구현하고, 더 나은 코드를 만들 수 있을까, 버그가 발생했는데 이를 어떤 방식으로 수정할까에 대한 고뇌가 담겨있다. 그런데 커밋이 단 한 개라면 이러한 고민을 표현할 수 있는 수단이 없다. 개발은 도깨비방망이로 뚝딱한다고 나오는 것이 아니고 시간이 지날수록 버그는 발생하기 때문에 지속적인 수정이 요구되기 마련이다. 깃과 같은 VCS(Version Control System)이 가지는 큰 힘은 과거 기록을 전부 살펴볼 수 있다는 점인데, 커밋이 한 개라면 쓰나 마나 한 무용지물이 된다.
브랜치
깃 브랜치에 대한 이야기도 할 수 있다. 프로젝트를 하면서 브랜치를 나눠서 작업하고 병합하고 하는 일을 하면 더욱 좋을 수 있다. 특히 혼자 하는 개인 프로젝트가 아니라 팀 프로젝트를 하면 더욱 중요할 수 있다. 나도 아직 그 습관을 들이지는 못해서 여전히 master 브랜치 하나에서만 작업하는 경우가 많다만, 실무에 가면 Git Flow 와 같은 전략을 사용하여 프로젝트를 진행하는 경우도 많기 때문에 브랜치를 나눠서 작업하고 병합하는 일을 버릇을 들이는 것이 여러모로 좋다고 생각한다.
Git Flow 개념 이해하기
Git으로 협업을 하는 것이 매우 좋다라고는 알고 있으나 실제로 서로 다른 그 사람들이 어떻게 각자 작성한 코드를 합치고 배포하는지가 궁금해 졌습니다. Git-flow 이해하기 Git-flow는 Git이 새롭게
ux.stories.pe.kr
처음으로 깃허브를 관리해보고 싶다면
깃허브를 포트폴리오로 사용하고 싶은데 아직 깃허브를 관리해본 적이 없다면 추천하고 싶은 프로젝트는 대략 두 가지가 있다. 하나는 TIL(Today I Learned)이며 또 한 가지는 깃허브 페이지다. 사실 둘 다 글과 기록을 남긴다는 차원에서는 똑같지만 용도가 다르기 때문에 나눠서 해보기를 바란다. 팀 프로젝트와 개인 프로젝트도 당연히 깃허브에 올릴 수 있는 대상이기는 한데, 이는 너무나도 당연한 것이라 생략.
TIL 과 깃허브 블로그는 깃허브 위에서 돌아갈 것이기 때문에 모두 커밋 기록이 남는다. 그래서 잔디로 자연스럽게 만들어줄 수 있다는 장점이 있다.
TIL
개인적으로 1일 1커밋을 중시하지 않는다고는 했지만, 그것이 모두에게 일반적으로 적용될 수 있는 사항이라고 생각되지 않는다. TIL 은 자신이 매일 배운, 간단하지만 유용한 내용들을 남기는 메모와 같다. 블로그와는 다르게 간단하게 짧은 내용들을 남기며 주로 문제를 해결하기 위한 이슈나 개념들을 남긴다. 개발을 업으로 삼다보면 문제는 늘 발생하기 때문에 미리 TIL 을 통해 기록해두는 습관을 가지면 좋을 수 있다. TIL 의 모범 사례로는 milooy/TIL 프로젝트가 있다.
깃허브 페이지
블로그 플랫폼은 워낙 여러 가지라 꼭 깃허브 페이지를 사용하지 않아도 되지만, 티스토리를 사용하지 않는다면 깃허브 페이지도 괜찮은 선택지라고 볼 수 있다. hexo 를 사용하면 다양한 테마도 사용할 수 있다, 하지만 깃허브 페이지는 블로그라고 하기에는 여러모로 사용자 편의성은 떨어져서 개인적으로 선호하는 편은 아니다. 애초에 "블로그로 사용할 수 있다" 정도이지 깃허브 페이지를 블로그 플랫폼이라고 하면 그건 잘못된 것이다. 그냥 정적 페이지 호스팅이니까. 아무튼 가장 개발자의 블로그스러운 냄새를 풍기는 것이 깃허브 페이지다.
블로그에는 어떤 글을 적을까?
개발자 블로그에는 TIL 과는 다르게 내용이 다소 길고 그 내용이 다수에게 보일만한 유용한 정보를 적어내는 것이 좋다. 일상과 취미생활을 섞는 것은 개인의 자유이지만, 개발에 대한 이야기를 할 때에는 가급적 글을 일목요연하게 정리하고 카테고리를 분류하는 것이 좋다.
개발자 블로거가 가장 많이 적는 글은 프로그래밍 언어, 그리고 개발에 대한 철학, 기술에 대해 설명 및 요약, 개인 및 팀 프로젝트에 대한 상세 내용 등이 블로그에 적기 적당한 내용이고, 실험이나 연구를 하여 그 결과를 정리하는 글도 써볼 수 있다. 만약 팀 프로젝트를 했다면 단지 깃허브 주소만을 던져주지 말고 내용을 정리한 글이 있다면 더욱 좋게 평가될 가능성이 크다.
마치며
개발자에게 깃허브를 관리하는 일이 필수적인 것은 아니다. 깃허브를 관리하지 않더라도 충분히 멋진 기업에 가는 사람들도 있기 때문이다. 깃허브는 강요되는 것이 아니라 그저 포트폴리오 중 하나로 제출될 수 있을 뿐이다. 다만 블로그와 함께 깃허브는 개발자가 자신의 능력을 드러낼 수 있는 중요한 수단 중 하나이기 때문에 관리하는 것을 추천하는 것이고, 만약 깃허브를 포트폴리오의 한 요소로서 제출하고자 한다면 위에 적은 내용들에 대해서는 고민해보는 것이 좋다. 일부 기업들은 오픈소스 기여 경험이 있는 개발자에게 가산점을 주는 경우도 있다.
구름에서 나와 가장 닮은 개발언어는? 이라는 것이 있길래 한 번 해봤습니다.
