GitHub 브라우저에서 첫 저장소와 README 만들기

 

AI 서비스 소개

GitHub 초보 시작법: 브라우저에서 첫 저장소와 README 만들기

명령어를 외우기 전에, 내 프로젝트 설명 한 장을 수정 기록과 함께 남겨 본다. GitHub가 필요한지 판단하기에도 이 정도 실습이면 충분하다.

GitHub를 처음 열면 저장소, 커밋, 브랜치, 풀 리퀘스트가 한꺼번에 보인다. 아직 올릴 코드도 없는데 낯선 단어부터 배우라는 셈이다. 최근 초보자 커뮤니티 글에서도 명령어보다 이 단어들의 관계를 이해하는 데 오래 걸렸다는 이야기가 반복된다. 그래서 이 글은 Git 설치나 터미널부터 시작하지 않는다.

목표는 하나다. 브라우저에서 ai-tool-notes라는 저장소를 만들고, README.md를 한 번 고친 다음 수정 기록까지 확인한다. 끝나면 프로젝트를 설명하는 URL과 되돌아볼 수 있는 두 개의 기록이 남는다. 코딩 지식은 필요 없다.

GitHub를 클라우드 폴더로만 보면 금방 헷갈린다

저장소(repository)는 파일과 변경 이력을 함께 보관하는 프로젝트 공간이다. 커밋(commit)은 그 프로젝트의 특정 시점을 설명과 함께 남긴 기록이다. 브랜치(branch)는 원본을 바로 건드리지 않고 별도의 흐름에서 고칠 때 쓴다. Git은 이 기록을 다루는 도구이고, GitHub는 Git 저장소를 온라인에서 보관하고 함께 검토하는 서비스다.

처음부터 모든 기능을 써야 하는 것은 아니다. 혼자 메모 한 장을 만드는 동안에는 기본 브랜치인 main에 바로 커밋해도 된다. 다른 사람의 검토가 필요하거나, 실패할 수 있는 변경을 따로 시험할 때 브랜치와 풀 리퀘스트를 붙이면 된다.

이 글에서 쓰는 세 단어

저장소는 프로젝트 상자, README는 그 상자를 열었을 때 먼저 보이는 설명서, 커밋은 무엇을 왜 바꿨는지 남기는 저장 지점으로 이해하면 된다. 명령어는 이 관계를 이해한 뒤 배워도 늦지 않다.

첫 저장소는 무료 계정이면 충분하다

2026년 7월 18일 GitHub 공식 가격표 기준으로 Free는 월 0달러이며 공개·비공개 저장소를 제한 없이 만들 수 있다. 개인용 Pro는 월 4달러, 조직용 Team은 사용자당 월 4달러, Enterprise는 사용자당 월 21달러부터 표시된다. 세금, 환율, 계약 조건과 별도 사용량 과금은 계정에 따라 달라질 수 있으므로 결제 직전 가격표를 다시 확인해야 한다.

선택	맞는 경우	지금 확인할 것
Free	개인 학습, 포트폴리오, 작은 협업, 첫 저장소	공개 범위와 사용량 한도
Pro	개인이 비공개 저장소의 고급 검토·분석 기능을 써야 할 때	실제로 필요한 기능이 Free에 없는지
Team·Enterprise	조직 권한, 규칙, 감사, 보안·컴플라이언스가 필요한 팀	좌석 수, 저장소 정책, 추가 제품 비용

이번 실습은 Free 범위를 넘지 않는다. GitHub Actions, Codespaces, Packages, Copilot은 저장소와 별도의 기능이며 무료 할당량 또는 별도 요금이 있다. 첫날에는 켤 이유가 없다.

가입 전에 준비할 것은 계정과 공개 원칙 두 가지다

개인 계정을 만들고 이메일 인증을 마친다. GitHub는 코드 기여자 일부를 대상으로 2단계 인증 등록을 의무화하며, 선정된 계정에는 45일 등록 기간을 안내한다. 의무 대상이 아니더라도 TOTP 앱과 복구 수단을 먼저 설정하는 편이 안전하다. 회사나 학교에서 받은 계정은 관리자가 파일과 이용 정보를 다룰 수 있으므로 개인 프로젝트와 섞지 않는 것이 낫다.

커밋에 개인 이메일이 노출되는 것도 놓치기 쉽다. 프로필 사진 → Settings → Emails에서 Keep my email addresses private를 켜면 웹에서 만든 커밋에는 GitHub의 noreply 주소가 쓰인다. 나중에 PC에서 Git을 사용할 때는 로컬 Git 이메일도 별도로 맞춰야 한다.

10분 실습: AI 도구 기록용 README를 만든다

GitHub 공식 Hello World도 브라우저만으로 저장소와 README를 만들 수 있다고 안내한다. 메뉴 이름은 바뀔 수 있으니 위치를 외우기보다, 새 저장소를 만들고 → 설명 파일을 고치고 → 커밋 기록을 확인한다는 흐름을 기억하자.

1. 비공개 저장소부터 연다

1. github.com/new로 이동한다.
2. Owner는 개인 계정, Repository name은 ai-tool-notes로 둔다.
3. Description에는 “AI 서비스 테스트 조건과 결과를 기록하는 노트”라고 적는다.
4. 공개 여부를 아직 결정하지 못했다면 Private를 고른다. 나중에 바꿀 수 있지만, 공개 저장소는 인터넷 누구나 볼 수 있고 포크할 수 있다.
5. Add a README file을 켠다. .gitignore는 None, License도 None으로 둔다.
6. Create repository를 누른다.

License를 비워 두는 이유는 “라이선스가 필요 없다”는 뜻이 아니다. 지금 만든 것은 비공개 연습 노트이고, 공개 배포 조건을 아직 정하지 않았기 때문이다. 오픈소스로 공개할 때는 프로젝트 목적과 포함한 코드의 권리를 확인한 뒤 LICENSE 파일을 추가한다.

2. README를 한 번 고친다

저장소 첫 화면에서 README.md를 열고 연필 모양의 편집 버튼을 누른다. 기존 내용을 다음처럼 바꾼다.

# AI 도구 실험 노트 테스트한 AI 서비스의 조건과 결과를 기록합니다. ## 기록할 항목 - 서비스명과 테스트 날짜 - 해결하려던 문제 - 입력한 자료의 종류 - 얻은 결과와 다시 확인할 점

미리보기에서 제목과 목록이 제대로 보이는지 확인한다. Commit changes를 누르고 메시지는 “첫 실험 노트 구조 추가”로 적는다. 두 번째 입력란에는 “서비스별 테스트 조건을 빠뜨리지 않기 위해 항목을 정함”처럼 이유를 덧붙일 수 있다. 혼자 쓰는 연습 저장소이므로 Commit directly to the main branch를 선택해도 된다.

3. 파일이 아니라 결과를 확인한다

저장소 첫 화면으로 돌아오면 README가 본문처럼 펼쳐져야 한다. 파일 목록 위의 커밋 기록을 열었을 때 저장소 생성 때의 첫 기록과 방금 남긴 “첫 실험 노트 구조 추가”가 보이면 완료다. 각 커밋을 열어 어떤 줄이 추가됐는지 확인해 본다.

완료 기준

저장소 URL이 열리고, README의 제목과 네 항목이 보이며, 수정 전후 커밋 두 시점을 구분할 수 있으면 된다. 별 개수, 방문자 수, 코드 줄 수는 첫 결과물의 품질과 관계없다.

공개 버튼을 누르기 전에 라이선스와 데이터부터 본다

Public은 무료 홍보 옵션이 아니라 공개 결정이다. 공식 문서상 공개 저장소는 인터넷 누구나 볼 수 있고, GitHub 안에서 포크할 수 있다. 비공개에서 공개로 바꾸면 코드뿐 아니라 Actions 기록과 로그도 보일 수 있다. API 키, 고객 데이터, 내부 문서, 계약상 외부 반출이 금지된 파일은 저장소에 올리지 않는 것이 먼저다.

GitHub의 사용자용 push protection은 지원하는 비밀 키 패턴을 공개 저장소에 올리려 할 때 기본적으로 막아 준다. 하지만 모든 비밀번호와 사내 형식을 알아내는 장치는 아니다. 키가 이미 커밋됐다면 파일을 지우는 것으로 끝나지 않는다. 공식 지침대로 키를 먼저 폐기하거나 교체하고, 필요하면 기록에서도 제거해야 한다.

공개 저장소에 LICENSE가 없으면 기본 저작권법이 적용된다. 다른 사람이 화면을 보고 포크할 수 있다는 GitHub 이용 권한과, 코드를 수정·배포해도 된다는 오픈소스 라이선스는 같은 말이 아니다. 재사용을 허용하려면 MIT, Apache-2.0, GPL 같은 라이선스의 의무를 비교하고 명시해야 한다. 반대로 다른 저장소의 파일을 가져왔다면 그 파일의 라이선스를 먼저 따라야 한다.

2026년 4월 27일 효력의 GitHub 이용약관에는 게시자가 콘텐츠 소유권을 유지하는 한편, 서비스 제공과 개발, AI·머신러닝 기술 개선 등을 위해 GitHub와 계열사에 일정한 이용 권한을 부여한다는 내용이 있다. 같은 약관의 비공개 저장소 조항은 비공개 콘텐츠를 기밀로 취급하며, AI 기능의 입력으로 제공한 경우 등을 제외하면 서비스 개선에 쓰지 않는다고 설명한다. 회사 소스나 민감 자료라면 단순히 Private를 선택하는 데서 끝내지 말고 조직 계약, AI 기능 설정, 반출 정책을 함께 확인해야 한다.

대용량 파일 보관함으로 쓰면 첫날부터 막힌다

웹 브라우저에서 올리는 파일은 하나당 25MiB 이하여야 한다. 일반 Git 저장소는 50MiB가 넘는 파일에 경고를 내고 100MiB를 넘으면 차단한다. GitHub는 저장소를 가능하면 1GB 미만으로 유지하고, 5GB 미만을 강하게 권장한다. 이 한도는 영상, 학습 데이터, 모델 가중치를 프로젝트 폴더째 올리려는 순간 금방 닿는다.

큰 파일은 Git LFS, Releases, 데이터 전용 스토리지 가운데 목적에 맞는 곳으로 분리한다. 특히 AI 모델과 데이터셋을 공개·협업하려는 목적이라면 대용량 ML 파일에 맞춘 Hugging Face Hub가 더 자연스러울 수 있다. GitHub에는 코드, 설정 예시, 재현 방법과 작은 샘플만 두는 편이 기록을 읽고 내려받기도 쉽다.

초보자가 자주 막히는 지점은 오류보다 작업 순서다

2026년에 공개된 한 초보자 글은 repository, commit, push, origin, branch가 한꺼번에 등장하고 많은 입문 자료가 명령어부터 던지는 점을 불편으로 꼽았다. 또 GitHub Community의 New to GitHub 게시판에는 README를 어디에 두고 무엇을 써야 하는지 묻는 질문이 올라왔다. 이는 제품 결함을 증명하는 자료가 아니라 사용자 의견이다. 다만 첫 설명을 ‘기능 목록’이 아니라 ‘프로젝트 설명과 변경 기록’에서 시작해야 하는 이유는 잘 보여 준다.

막힌 장면	뜻	먼저 할 일
README가 첫 화면에 안 보임	파일명이나 위치가 다를 수 있음	저장소 최상위에 README.md가 있는지 확인
업로드가 거부됨	브라우저 파일 한도를 넘겼을 수 있음	파일 크기 확인 후 LFS·Releases·외부 저장소 검토
수정했는데 기록이 없음	편집만 하고 커밋하지 않았을 수 있음	Commit changes 완료와 현재 브랜치 확인
브랜치를 꼭 만들어야 할지 고민됨	검토·실험 흐름이 필요한지의 문제	혼자 쓰는 첫 메모는 main, 위험한 변경이나 협업부터 branch

README는 저장소 최상위에 두면 첫 화면에 렌더링된다. 커뮤니티 답변은 프로젝트 목적, 설치, 사용법, 설정, 라이선스 등을 권하지만 모든 항목을 빈칸으로 채울 필요는 없다. 첫 저장소라면 “무엇을 기록하는 곳인지”와 “어떤 기준으로 기록할지”가 분명한 지금의 네 항목이 더 낫다. 실제 코드가 들어온 뒤 설치법과 실행 예시를 보태면 된다.

GitHub를 추천하지 않는 경우도 분명하다

문서를 여러 사람이 동시에 편집하는 것이 전부라면 Google Drive나 Notion 같은 문서 도구가 더 단순하다. 파일 변경점, 브랜치, 코드 검토가 필요하지 않은데 Git 개념까지 끌어오면 관리할 것만 늘어난다. 대용량 원본 영상과 백업 파일을 쌓아 두는 용도에도 맞지 않는다.

코드 저장부터 이슈, CI/CD, 배포까지 한 제품에서 강하게 묶고 자체 운영 가능성도 보고 있다면 GitLab을 함께 비교할 만하다. 모델·데이터셋·데모 앱을 공개하고 대용량 AI 파일을 다루는 일이 중심이라면 Hugging Face Hub가 더 직접적이다. 반면 공개 프로젝트를 찾고, 익숙한 Git 흐름으로 코드와 문서를 함께 검토하며, 다양한 외부 도구와 연결하려는 사람에게 GitHub는 여전히 무난한 출발점이다.

선택 기준은 서비스의 기능 개수가 아니다. 무엇을 기록할지, 누가 볼지, 파일이 얼마나 큰지, 변경을 누가 승인할지 네 가지다. 이번 실습으로 만든 저장소가 그 질문에 답하지 못한다면 억지로 계속 쓸 이유도 없다.

함께 읽으면 좋은 글

첫 저장소를 만든 뒤 팀의 풀 리퀘스트 검토 흐름까지 확장하려면 GitHub Copilot PR 코드 리뷰 자동화 만들기를 이어서 볼 수 있다. 자동 코멘트와 사람 승인을 분리하는 방법을 다룬 글이라, 브랜치와 풀 리퀘스트가 필요한 단계에서만 읽는 편이 좋다.

GitHub를 배웠다는 말은 모든 메뉴를 안다는 뜻이 아니다. 설명 파일 하나를 만들고, 왜 바꿨는지 커밋에 남기고, 공개해도 되는 자료인지 판단할 수 있으면 이미 핵심을 시작한 셈이다. 다음 단계는 새 기능을 켜는 것이 아니라 이 저장소에 실제 AI 서비스 테스트 기록 한 건을 추가하는 일이다.

출처·참고 자료

가격과 정책은 2026년 7월 18일 확인했다. 사용자 게시물은 기능을 확정하는 근거가 아니라 초보자가 막히는 지점을 찾는 참고 자료로만 사용했다.

• GitHub Docs, Hello World
• GitHub 공식 가격표 · GitHub 요금제 설명
• GitHub 필수 2단계 인증 안내 · 커밋 이메일 설정
• 저장소 공개 범위 변경 · 저장소 라이선스
• GitHub 대용량 파일 제한
• GitHub push protection · 민감 정보 제거
• GitHub Terms of Service, 2026-04-27 · GitHub General Privacy Statement
• GitLab Docs, 프로젝트 시작 · Hugging Face Hub 저장소 문서
• Reddit 초보자 Git·GitHub 학습 글, 2026 (사용자 의견)
• GitHub Community, README 위치와 구성 질문, 2025-10 (사용자 의견)

실제 입력 → 실제 출력 → 검증 결과

실제 입력

GitHub 웹에서 새 저장소 이름을 ai-tool-notes-adsense-evidence로 지정하고 공개 범위를 비공개로 설정했습니다. README에는 브라우저 기반 비공개 저장소 생성과 커밋 흐름을 검증한다는 목적, 합성 텍스트만 사용했다는 데이터 조건, 한 번의 흐름만 확인했다는 제한을 영어로 입력했습니다.

실제 출력

• 저장소 화면에서 비공개 상태를 확인했습니다.
• README가 기본 브랜치에 표시되는 것을 확인했습니다.
• 웹 커밋 결과의 짧은 식별자는 d066a51입니다.

검증 결과

확인 항목	실제 결과	판정
저장소 공개 범위	비공개 표시 확인	통과
README 입력	개인정보 없는 실험 노트 표시 확인	통과
웹 저장 결과	기본 브랜치 커밋과 짧은 식별자 확인	통과

제한 사항: 이번 기록은 한 계정에서 한 번 수행한 브라우저 기반 비공개 저장소 생성과 README 커밋 흐름만 검증합니다. 계정명, 이메일, 저장소 목록은 기록하지 않았고 식별 정보를 안전하게 분리하기 어려워 확인 화면은 공개하지 않았습니다. 테스트 저장소는 삭제 권한이 별도로 주어지지 않아 비공개 상태로 유지했습니다.