(비개발자를 위한) GitHub의 역사와 기능

9분

2022.09.01.

20.6K

GitHub(깃허브)는 개발자와 떼려야 뗄 수 없는 관계에 있는 서비스로, 개발자가 아닌 사람들조차 GitHub를 어렴풋이 들어본 적이 있을 정도로 유명합니다. 이 글은 ‘GitHub에 대해 듣기는 했지만, 무엇인지 정확히 모르는 사람들’과 ‘주변에서 많이 사용해서 일단 쓰고는 있는데, GitHub가 어떤 사이트인지 잘 모르는 사람들’을 위해 작성되었습니다. GitHub의 탄생부터 지금까지의 역사를 간단하게 살펴보고, 어떤 기능이 있는지 알아보겠습니다.

GitHub의 시작과 역사

Git이란?

GitHub에 대해 알아보기 전에, 우리는 Git이 무엇인지 먼저 알아야 합니다. GitHub는 이름에서부터 알 수 있듯이 Git과 Hub의 합성어로 Git들이 모여있는 곳(Hub)을 의미하기 때문입니다.

Git은 버전 컨트롤 시스템(Version Control System)의 일종으로 ‘레포지토리’라고 불리는 디렉터리 하위 파일들의 삭제와 생성, 수정을 추적하여 버전을 관리하는 소프트웨어입니다. 예를 들어 ‘GitHub 분석리포트’라는 이름의 파일을 관리하는 것을 생각해봅시다. 우리는 이 파일을 그대로 수정해서 리포트를 작성할 수도 있지만, 모종의 이유로 다른 버전이 필요할 수도 있습니다.

그러면 개발자는 이 파일을 필요에 따라 ‘GitHub 분석리포트_버전A’, ‘GitHub 분석리포트_버전 B’ 등 두 개로 구분해서 관리하게 됩니다. 더 나아가 버전A-1, A-2b 등으로 더 다양하고 세분화해서 나눌 수도 있습니다. Git은 이런 일련의 과정을 조금 더 체계적으로 관리할 수 있도록 도와줍니다.

위의 사례를 Git에서 쓰는 용어로 간단히 정리하면, GitHub 분석리포트를 A와 B, 두 개 버전으로 나눈 것을 ‘Branch(브랜치)를 나눈다’라고 합니다. 또한 이렇게 나눈 각각의 버전을 시간순으로 구분한 것을 ‘Commit(커밋)을 작성한다'라고 얘기합니다.

실제 프로젝트에서는 ‘Main 브랜치’를 정해 두고, 새로운 기능을 구현해야 할 때 먼저 해당 브랜치에서 새로운 브랜치를 분기합니다. 이후 분기한 브랜치에 커밋들을 작성하는 방식으로 버전을 관리합니다.

GitHub의 시작

이러한 Git은 오픈소스 운영체제로 유명한 Linux(리눅스)의 개발자 ‘리누스 토르발즈’가 개발했습니다. 리누스 토르발즈는 리눅스를 개발하면서 본래 BitKeeper라는 버전관리서비스를 이용하고 있었습니다. 하지만 오픈소스인 리눅스에 반해 BitKeeper는 상용 프로그램이었기 때문에 서로의 철학이 맞지 않았습니다. 결국 리눅스 개발 커뮤니티에서 ‘오픈소스 철학에 맞게 자체 버전관리서비스를 만들어 쓰겠다’라는 결론이 나왔고, Git이 탄생하게 되었습니다.

Git의 발명으로 개발 커뮤니티 개발자들은 원하는 오픈소스 프로젝트에 이전보다 훨씬 쉽게 기여할 수 있게 되었습니다. 말 그대로 ‘오픈소스의 르네상스’가 열렸다고 할 수 있었죠. 그러나 여기에는 여전히 두 가지 문제점이 존재했습니다.

첫째, ‘어떻게 해야 프로젝트에 합류할 수 있는가’는 여전한 문제였습니다. 아무리 많은 오픈소스가 세상에 존재한다고 한들, 이를 개발할 개발자와 연결되지 못하면 프로젝트가 성장하기는 어려웠습니다.

둘째, Git이 버전관리 문제는 해결했지만 여전히 파일 전송 등은 이메일을 통하고 있었습니다. 심지어 지금도 Git 자체 레포지토리는 GitHub가 아닌 이메일을 통해 파일을 주고받을 정도로 접근성이 끔찍하게 낮습니다. 메일링 리스트에 가입하고, 메일에 패치 파일을 첨부하여 관리자에게 보내고, 관리자가 패치파일을 열어보고 적용여부를 결정하고, 다시 패치 파일을 모든 사용자에게 전송해주는 상황은 전혀 편하지도 않고 멋지지도 않았습니다.

GitHub는 이런 문제들을 해결하기 위한 커뮤니티 및 협업 도구로서의 목적을 가지고 2008년 공개되었습니다. GitHub는 모든 코드 베이스를 업로드할 수 있는 호스팅 서버를 제공했고, 오픈소스 프로젝트의 모든 소스는 GitHub에 업로드되었습니다. 덕분에 모든 코드 기여자(개발자)들은 거의 실시간으로 협업이 가능해지게 되었습니다. 프로젝트들이 인터넷에 업로드됨에 따라 자신이 기여하고 싶은 프로젝트를 쉽게 찾을 수 있게 된 건 덤이었죠.

GitHub의 발전 및 성장

IT 프로젝트에서 가장 중요한 것은 소스코드이고, 대부분의 의사소통은 소스코드를 중심으로 이루어집니다. GitHub는 레포지토리 사용자들(회사에서는 소속 개발자, 오픈소스 프로젝트에서는 기여자)이 소스코드를 중심으로 소통할 수 있도록 ‘Trello(트렐로)나 ‘Jira(지라) 등과 같은 업무 협업 툴의 요소를 계속해서 받아들였습니다. 또한 소스코드의 보안이 중요한 회사에서는 자체 서버에 GitHub와 비슷한 기능을 이용할 수 있도록 ‘GutHub Enterprise’를 출시하는 등 끊임없이 사용자들을 끌어들였습니다. 그 결과 GitHub은 투자 한 푼 받지 않고, 세계 최대의 코드저장소가 되었습니다.

특히 GitHub의 성장은 세계 최대의 코드 저장소 그 이상의 의미를 가졌습니다. GitHub 탄생의 배경이 되었던 2000년대 초중반의 오픈소스 르네상스 상징인 ‘공개 소프트웨어’ 정신이 소프트웨어 시장을 장악한 것과 다름없었기 때문입니다. 마이크로소프트, 오라클, 썬시스템즈와 같은 IT 대기업은 물론, 미국 백악관 같은 정부 기관까지 GitHub을 사용하는 것은 자본주의의 정점을 달리는 IT 산업 속에서 선의로 이루어진 '나눔과 공유 정신’이 꽃을 피웠다는 걸 의미했습니다.

GitHub의 변화

그러던 중 2018년, 마이크로소프트(Microsoft)가 GitHub 인수를 발표했습니다. 개발자들, 특히 공개 소프트웨어의 가치에 깊이 공감하던 많은 개발자가 크게 반발했습니다. 과거부터 상업 소프트웨어 그 자체를 상징한 마이크로소프트가 자유 소프트웨어를 상징하는 GitHub을 인수하는 건 ‘자유 소프트웨어에 관한 도전이자 그 의지를 꺾어버린다’는 의미로 받아들여졌기 때문입니다.

그러나 마이크로소프트는 ‘사티아 나델라’가 새로운 CEO가 되면서 오픈소스에 대한 입장을 바꾸고, 자유 소프트웨어 진영에 속하고자 많은 노력을 기울였습니다. 특히 GitHub 인수를 발표할 당시에는 사이트 내에서 Top 10위 안에 들어가는 오픈소스 기여 집단이었습니다. 따라서 개발자들의 거센 반발에도 불구하고 긍정적인 분위기가 형성되면서 인수가 진행되었습니다.

GitHub는 마이크로소프트에 인수된 이후 유료로 서비스하던 비공개 레포지토리를 무료로 전환하는 등 개인이나 교육, 비영리 프로젝트에 대한 지원을 늘렸습니다. 또 마이크로소프트의 ‘Visual Studio Code’ 코드 편집기를 GitHub와 연동하는 등 프로그래머들의 편의를 위한 기능도 계속 추가했습니다. 덕분에 인수 초반 개발자들이 가지고 있던 우려가 조금씩 해소되고 있습니다.

GitHub의 특이한 기능

앞서 언급했듯 GitHub의 개발자 문화는 ‘자유 소프트웨어’와 크게 맞닿아 있습니다. 자유 소프트웨어주의는 '모든 사람은 소프트웨어에 자유롭게 접근 및 사용할 권리가 있다’라는 사상을 바탕으로 이루어진 운동입니다. 실제로 우리가 사용하는 많은 제품은 소프트웨어에 대한 사용권을 지불해야 하지만, 그보다 훨씬 더 많은 다수 제품은 아무런 비용도 지불하지 않고 자유롭게 소프트웨어를 사용할 수 있습니다. 즉, 이러한 선의에 의해 더 나은 세상을 만들어 갈 수 있다고 믿는 사람들이 GitHub에 많이 분포하고 있으며, 이를 바탕으로 ‘나눔과 공유 문화’가 발전했습니다.

GitHub 별(Star)

GitHub는 단순히 소스코드를 모아 놓은 것이 아니라 커뮤니티 성격 또한 띄고 있기 때문에 페이스북이나 인스타그램처럼 '인기'의 척도를 나타내는 수치가 존재합니다. 바로 ‘별(GitHub Star)’라고 불리는 수치입니다. GitHub에서는 자신이 마음에 드는 레포지토리에 별을 눌러서 해당 프로젝트에 관한 자신의 관심을 표시할 수 있습니다.

해당 별에 대하여 별다른 관심을 갖지 않는 개발자도 있지만, 대부분 해당 개발 분야에서 많이 사용되거나 도움이 되는 프로젝트는 많은 별을 받습니다. 그 때문에 별이 많은 레포지토리는 그만큼 개발자와 관계자의 많은 관심을 받고 있다는 방증입니다.

다만 많은 개발자가 이러한 별을 부당한 방법으로 얻는 것에 대해 부정적으로 보고 있습니다. 그래서 이를 잘 모르는 마케터나 개발자가 회사 혹은 개인의 프로젝트 홍보를 위해 유료 마케팅을 진행하다가 ‘어뷰징’으로 경고를 받거나 심하면 해당 레포지토리가 삭제당하는 페널티를 받는 경우도 종종 있습니다.

GitHub 이슈트래커

이슈트래커는 GitHub의 대표적인 기능 중 하나로 현재 해야 할 일과 진행 중인 일, 끝난 일 등을 구분하여 관리할 수 있습니다. 덕분에 업무 태스크를 관리하기에 매우 효율적입니다. 이런 기능을 극단적으로 이용한 예시가 ‘집안일 레포지토리’입니다.

README 파일을 읽어보면 ‘My house has no source code, so I only use the issue tracker. (내 집에는 소스코드가 없다. 그렇지만 이슈트래커만 쓸 거야)’라고 적혀 있는데, 문장 그대로 GitHub 소스코드 관리기능은 전혀 사용하지 않은 채 이슈트래커만 사용하는 방법을 설명하고 있습니다.

Awesome 레포지토리

Awesome 레포지토리는 의미를 가진 것보다는 해당 주제에 대한 관련 링크를 모아두는 북마크 역할을 하는 레포지토리라고 생각하면 됩니다. 일반적으로는 개발과 관련된 주제에 대해 레포지토리를 개설하지만, ‘국내 스시 오마카세 맛집 리스트 및 관련 자료가 담긴 레포지토리’가 존재할 정도로 주제에 제한이 없습니다.

이런 레포지토리는 개인이 리스트 업데이트를 하는 경우도 있지만, ‘Pull Request’라는 GitHub의 협업 기능을 사용하여 리스트 업데이트를 제안할 수 있습니다. 주제는 다르지만, GitHub의 기능을 효율적으로 사용한 예시라고 할 수 있습니다.

정리

지금까지 간단히 GitHub의 역사와 문화를 알아보고, 어떤 특이한 기능이 있는지 알아봤습니다. GitHub는 개발자 면접에서 일종의 포트폴리오 역할을 할 정도로 유명해 졌지만, 아직도 많은 개발자가 단순히 소스코드 저장용으로 쓰고 있습니다. 이번 글을 통해 단순히 ‘남들이 쓰니까 나도 써 봐야지’라고 생각하기보다 어떤 의도로 사이트가 만들어졌고, 무슨 기능이 있는지 알 수 있는 계기가 되었으면 좋겠습니다. 또한 개발자와 일하는 비개발자들이 GitHub에 관한 이해를 가지고, 소통할 수 있도록 도움이 되었기를 기대합니다.

로그인하고 자유롭게 의견을 남겨주세요.