깃허브란 무엇인가? 초보자를 위한 사용법과 게임·블로그 활용 가이드
깃허브의 역할부터 저장소, 커밋, 브랜치 뜻까지 쉽게 알아봅니다.
AI로 만든 게임과 계산기를 저장하고 GitHub Pages로 공개하는 방법도 소개합니다.
깃허브란 무엇인가? 내 작품을 저장하고 세상과 나누는 첫걸음
깃허브(GitHub)를 처음 접하면 영어 메뉴와 낯선 용어 때문에 어렵게 느껴집니다.
“개발자들만 사용하는 곳 아닌가?”라는 생각도 들지요.
하지만 AI로 계산기나 게임을 만드는 시대에는 일반인에게도 유용한 공간입니다.
AI가 만들어 준 프로그램을 보관하고, 수정한 내용을 기록하고, 다른 사람이 사용할 수 있도록 공개할 때 깃허브가 도움을 줍니다.
오늘은 코딩을 모르는 초보자의 눈높이에서 깃허브의 역할과 활용법을 살펴보겠습니다.
1. 깃허브란? 프로그램을 만드는 온라인 작업 공간
깃허브는 프로그램의 소스코드를 저장하고 관리하며, 다른 사람과 함께 작업할 수 있는 플랫폼입니다.
소스코드는 컴퓨터에 “이렇게 움직여라”라고 알려 주는 명령문입니다.
게임의 이동 방식이나 계산기의 계산 규칙도 코드로 작성됩니다.
쉽게 말하면 깃허브는 ‘프로그램 재료를 보관하는 창고이자 작업 기록장’입니다.
파일을 올려 두는 기능에 더해, 무엇을 어떻게 바꾸었는지 기록하고 수정 내용을 검토할 수 있습니다.
요리로 비유하면 완성된 음식은 실행 중인 프로그램, 조리법은 소스코드입니다. 깃허브에는 그 조리법과 필요한 재료를 모아 두고, 조리법을 개선한 과정도 남기는 셈입니다.
2. 구글 드라이브와는 무엇이 다를까?
구글 드라이브에서도 파일을 보관하고 공유할 수 있습니다. 깃허브는 특히 프로그램을 계속 수정하고 함께 만드는 작업에 초점이 맞춰져 있습니다.
예를 들어 게임을 만들었다고 가정해 보겠습니다.
• 첫 번째 작업: 기본 게임 완성
• 두 번째 작업: 모바일 조작 버튼 추가
• 세 번째 작업: 점수 계산 오류 수정
이때 깃허브에서는 각각의 변경 내용을 기록하고 비교할 수 있습니다.
문제가 생겼다면 기록을 살펴보고 이전 상태로 되돌리는 작업에도 활용할 수 있습니다.
‘게임최종’, ‘게임진짜최종’, ‘게임최종수정’처럼 파일 이름을 계속 늘리는 대신, 하나의 프로젝트 안에서 변화 과정을 관리하는 것입니다. 수정이 잦아질수록 이런 기록의 가치가 커집니다.
3. 깃과 깃허브는 같은 것일까?
이름이 비슷하지만 역할이 다릅니다.
3.1. 깃(Git)은 변경 이력을 관리하는 도구
깃은 파일이 바뀐 내용을 기록하는 버전 관리 도구입니다. 내 컴퓨터에서도 사용할 수 있으며, 프로젝트의 여러 작업 흐름을 관리하는 데 쓰입니다.
3.2. 깃허브(GitHub)는 온라인에서 공유하는 플랫폼
깃허브는 깃으로 관리하는 프로젝트를 인터넷에 보관하고, 협업과 검토 기능을 제공하는 서비스입니다.
사진 촬영 도구와 온라인 사진 공유 서비스를 구분하듯 이해하면 쉽습니다. 깃이 변경 기록을 다루는 도구라면, 깃허브는 그 프로젝트를 온라인에서 함께 관리하는 공간입니다.
처음부터 깃 명령어를 외울 필요는 없습니다. 깃허브 공식 입문 실습도 코딩 지식이나 깃 설치 없이 웹브라우저에서 진행할 수 있습니다.
4. 깃허브 초보자가 알아야 할 기본 용어
화면에 자주 등장하는 용어부터 생활 속 표현으로 이해해 보겠습니다.
4.1. 저장소: 프로젝트를 담는 폴더
저장소(Repository)는 하나의 프로젝트에 필요한 파일과 기록을 모아 두는 공간입니다. 줄여서 ‘리포’라고도 부릅니다.
계산기는 calculator, 테트리스는 tetris-game처럼 이름을 붙일 수 있습니다. 초보자는 작품마다 저장소를 하나씩 만들면 관리하기 편합니다. 저장소 안에는 코드뿐 아니라 이미지와 설명 문서도 들어갑니다.
4.2. 커밋: 설명을 붙인 변경 기록
커밋(Commit)은 변경한 내용을 기록하는 단위입니다. “모바일 버튼 크기 확대”처럼 메시지를 남기면, 나중에 무엇을 고쳤는지 알기 쉽습니다.
게임의 세이브 지점에 가깝지만, 편집할 때마다 저절로 만들어지는 것은 아닙니다. 변경 사항을 커밋해야 기록으로 남습니다.
4.3. 브랜치: 따로 시험하는 작업 갈래
브랜치(Branch)는 기존 작업에서 갈라져 새로운 수정을 진행하는 흐름입니다. 보통 main이라는 기본 브랜치를 사용합니다.
실행 중인 게임에 새 기능을 추가하고 싶다면 별도 브랜치에서 시험한 뒤 반영할 수 있습니다. 초보자는 우선 기본 브랜치로 시작하고, 수정 규모가 커질 때 익혀도 됩니다.
4.4. 풀 리퀘스트와 머지: 검토하고 합치기
풀 리퀘스트(Pull Request)는 “이 변경 내용을 검토하고 반영해 주세요”라는 제안입니다.
머지(Merge)는 검토한 변경 내용을 대상 브랜치에 합치는 작업입니다.
여러 사람이 함께 일할 때 유용하며, 혼자 작업할 때도 수정 전후를 확인하는 데 사용할 수 있습니다.
5. README는 내 작품의 안내문
저장소를 방문했을 때 보이는 설명 글은 대개 README 파일에 작성되어 있습니다. 프로그램의 이름표이자 사용 설명서라고 생각하면 됩니다.
게임이라면 다음 내용을 적으면 좋습니다.
• 어떤 게임인지
• 어디에서 실행하는지
• 키보드와 모바일 조작 방법
• 현재 사용할 수 있는 기능
• 알려진 문제나 앞으로 개선할 내용
코드를 읽지 못하는 사람도 README를 보면 작품을 이해할 수 있습니다.
특히 실행 주소를 눈에 잘 띄게 적어 두면 방문자가 게임을 찾기 편합니다. README는 입문 단계부터 만들어 볼 수 있는 기본 문서입니다.
6. 깃허브는 무료로 사용할 수 있을까?
처음 시작하는 개인 사용자라면 GitHub Free로 기본적인 저장소 관리부터 경험할 수 있습니다. 유료 기능이 필요한지는 프로젝트가 커진 뒤 판단해도 됩니다.
GitHub Pages는 무료 플랜에서도 공개 저장소를 이용해 사용할 수 있습니다. 비공개 저장소에서 Pages를 사용하는 기능은 지원되는 유료 플랜 등에 따라 달라집니다.
공개(Public) 저장소는 다른 사람이 내용을 볼 수 있고, 비공개(Private) 저장소는 접근을 허용받은 사람이 볼 수 있습니다. 따라서 저장소를 만들 때는 무엇을 공개하려는지 먼저 생각해야 합니다.
연습용 게임 코드는 공개할 수 있지만 비밀번호, 인증키, 개인 기록을 함께 올려서는 안 됩니다. ‘프로그램 공개’와 ‘내 정보 공개’는 구분해서 관리해야 합니다.
7. 깃허브에 올리면 바로 게임이 실행될까?
여기서 가장 많이 헷갈립니다. 코드가 보이는 저장소 주소와 실제 프로그램을 실행하는 웹사이트 주소는 역할이 다릅니다.
저장소는 제작 파일을 확인하는 공간입니다. 방문자가 브라우저에서 게임을 실행하게 하려면 웹사이트로 공개하는 과정이 필요합니다. 이를 흔히 ‘배포’라고 부릅니다.
깃허브에서 간단한 웹사이트를 공개할 때 사용하는 기능이 GitHub Pages입니다. HTML, CSS, JavaScript 파일을 바탕으로 웹사이트를 제공합니다. 기본 프로젝트 주소는 ‘계정명.github.io/저장소명’ 형태입니다.
블로그에서 “게임 시작하기” 링크를 걸 때는 코드 저장소 주소보다 실제 실행 주소를 연결해야 독자가 바로 이용할 수 있습니다.
8. GitHub Pages로 만들 수 있는 것과 한계
HTML은 화면의 뼈대, CSS는 모양과 색상, JavaScript는 움직임과 계산을 담당한다고 생각하면 쉽습니다.
이 파일들로 브라우저에서 작동하는 프로그램을 만들 수 있습니다.
예를 들어 다음과 같은 작품이 가능합니다.
• 간단한 퍼즐이나 레트로 게임
• 계산기와 단위 변환 도구
• 스톱워치와 타이머
• 자기소개와 작품 소개 페이지
이런 프로그램은 서버에서 복잡한 처리를 하지 않아도 작동하도록 만들 수 있습니다.
반면 회원가입, 사용자별 기록의 중앙 저장, 결제 처리처럼 서버가 필요한 기능은 별도 서비스나 서버를 연결해야 합니다. GitHub Pages 자체에서는 PHP나 Python 같은 서버 측 프로그램을 실행하지 않습니다.
9. 초보자의 첫 저장소 만들기
처음에는 거창한 프로그램보다 작은 연습 저장소를 만들어 보는 것이 좋습니다.
• 깃허브에 가입하고 로그인합니다.
• New repository를 선택합니다.
• my-first-project처럼 이름을 입력합니다.
• 공개 또는 비공개 여부를 선택합니다.
• README 추가 옵션을 켭니다.
• Create repository를 눌러 생성합니다.
이후 README에 “이곳은 나의 첫 깃허브 연습 공간입니다”라고 작성하고 변경 내용을 저장해 보세요. 이것만으로도 저장소와 커밋의 의미를 직접 경험할 수 있습니다.
공식 Hello World 안내에서는 저장소 생성부터 브랜치, 커밋, 풀 리퀘스트와 머지까지 순서대로 연습할 수 있습니다.
10. 간단한 웹게임을 공개하는 순서
별도 빌드 과정이 필요 없는 웹게임을 기준으로 보면 흐름은 다음과 같습니다.
• 게임용 저장소를 만듭니다.
• index.html과 필요한 파일을 올립니다.
• 저장소의 Settings에서 Pages로 들어갑니다.
• Source에서 Deploy from a branch를 선택합니다.
• 게시할 브랜치와 폴더를 선택하고 Save를 누릅니다.
파일을 main 브랜치의 최상위에 올렸다면 main과 /(root)를 선택하는 방식입니다. 파일 위치에 따라 설정도 달라집니다.
배포 후에는 Pages에 표시된 주소로 접속해 확인합니다. 수정 내용이 웹사이트에 반영되기까지 시간이 걸릴 수 있으며, 공식 문서는 최대 10분이 걸릴 수 있다고 안내합니다.
11. AI로 만든 프로그램을 블로그에 활용하기
AI로 작은 도구를 만드는 사람에게 깃허브는 결과물을 쌓아 가는 공간이 됩니다.
먼저 AI에 필요한 기능을 설명하고 프로그램을 만듭니다. 실행해 오류를 고친 뒤 깃허브에 저장하고, 웹사이트로 공개합니다. 마지막으로 블로그에 사용 방법과 실행 링크를 소개하면 됩니다.
예를 들어 시험용 타이머를 만들었다면, 블로그 글에는 시간 설정법과 실제 활용 예시를 담을 수 있습니다. 단순히 코드만 보여 주는 것보다 독자가 바로 써 볼 수 있는 도구가 있어 이해를 돕습니다.
다만 AI가 코드를 작성했다고 완성된 것은 아닙니다. 휴대폰에서 버튼을 누를 수 있는지, 화면이 잘리는지, 계산 결과가 맞는지는 직접 확인해야 합니다. 작은 불편을 고치는 과정도 작품의 중요한 일부입니다.
12. 다른 사람의 코드도 마음대로 써도 될까?
깃허브에는 참고할 만한 공개 프로젝트가 많습니다. 그렇다고 공개된 코드를 모두 자유롭게 복사하고 배포할 수 있는 것은 아닙니다.
다른 사람의 작품을 활용하려면 LICENSE 파일 등에서 사용 조건을 확인해야 합니다. 라이선스는 코드를 사용하거나 수정하고 배포할 때 지켜야 하는 조건을 알려 줍니다. 공개 저장소라는 이유만으로 모든 이용 권한이 주어지지는 않습니다.
게임에 포함된 그림, 음악, 글꼴도 사용 조건을 확인하는 습관이 필요합니다. 처음에는 직접 만든 자료나 사용 조건이 명확한 자료로 작은 작품을 완성해 보세요.
깃허브 입문의 첫 목표는 모든 메뉴를 배우는 것이 아닙니다. 저장소 하나를 만들고, 파일 하나를 수정하고, 내가 만든 작은 작품을 공개해 보는 것입니다. 그 경험이 쌓이면 낯설었던 영어 메뉴도 실제 작업과 연결되어 이해되기 시작합니다.