GitHub 를 뭘 하는지도 모른 채 쓰고 계신가요?
모르고 쓰면 결국 깨집니다.
GitHub 에는 초록색 버튼이 딱 3 개뿐입니다.
누르기 전에 봐야 할 곳도 딱 한 곳입니다.
이 글에서는 GitHub 화면에서 어디를 보고 어디를 눌러야 하는지, 빨간 박스로 표시해 전부 보여드립니다.
연결하고, 제출하고, diff 를 확인하고, 병합하고, 되돌리기.
실제 스크린샷 10 장으로 이 전체 사이클을 함께 돌아봅니다.
타이핑은 AI 가 합니다.
여러분은 보고 누르기만 하면 됩니다.
어려운 용어가 나오면 그때그때 쉽게 풀어서 설명하겠습니다.
※ 이 글의 GitHub 화면과 사양은 2026 년 10 월 기준으로 확인했습니다. 화면은 변경될 수 있습니다.
1 장: GitHub 연결하기 | 저장소 만들고 로컬 기록 올리기
GitHub 인터페이스는 영어입니다.
하지만 눌러야 할 곳은 정해져 있습니다.
화면의 빨간 박스가 어디를 보고 어디를 눌러야 하는지 알려줍니다.
이번 장에서 눌러야 할 초록색 버튼은 단 하나입니다.
먼저 저장소를 하나 만듭니다.
저장소는 Git 기록을 온라인에 보관하는 사물함 같은 것입니다.
사물함 안에 무엇이 들어가는지와 핵심 용어 4 개는 이전 글에서 다뤘습니다.
【그림 해설】중학생도 이해하는 Git 설명
https://x.com/dan_pro_man/status/2107224533099069671?s=20
이 글을 안 읽었더라도, 이번 글만으로도 전체 사이클을 끝낼 수 있습니다.
GitHub 에 로그인한 뒤 오른쪽 위 "+" 아이콘에서 "New repository" 를 선택하세요.
https://github.com/new 를 열아도 같은 화면으로 이동합니다.
입력해야 할 것은 이름뿐입니다.
"Repository name" 에 영문과 숫자로 된 이름을 입력하세요.
"git-practice" 정도면 충분합니다.
"Choose visibility" 에서 "Private" 을 선택합니다.
비공개로 두겠다는 뜻입니다.
"Add README" 스위치는 일단 꺼두세요.
이미 로컬에 기록이 있다면, 빈 저장소를 만든 뒤 연결하는 편이 훨씬 쉽습니다.
맨 아래 초록색 "Create repository" 버튼을 누릅니다.
누른 직후 나오는 화면이 이번 장에서 가장 중요합니다.
아래쪽을 보면 "…or push an existing repository from the command line" 이라는 제목이 있습니다.
그 아래 세 줄이 오늘 우리가 쓸 명령어입니다.
위쪽 일곱 줄은 아직 로컬 기록이 없는 사람을 위한 것이니 건너뛰어도 됩니다.
세 줄의 의미는 다음과 같습니다.
1 번째 줄: 로컬 기록에게 이 사물함의 주소를 알려준다.
2 번째 줄: 메인 브랜치 이름을 "main" 으로 맞춘다.
3 번째 줄: main 브랜치를 사물함에 넣는다.
이 화면에서 주소(빨간 박스)를 복사해 한 줄로 AI 에게 보내세요.
1이 폴더의 기록을 https://github.com/account-name/git-practice 에 업로드해 줘
그러면 Claude Code 가 알아서 세 줄을 타이핑합니다.
Claude Code 는 지시를 받으면 내 컴퓨터에서 작업을 수행하는 AI 입니다.
저는 지시서에 push 하기 전 반드시 확인을 거치도록 적어둡니다.
Push 란 로컬 기록을 사물함에 넣는 작업입니다.
그래서 여기서 한 번 멈춥니다.
"Yes" 라고 답한 뒤 브라우저 화면을 새로고침하세요.
명령어 세 줄이 있던 자리에 이제 로컬 파일들이 나란히 보입니다. 그 옆에는 커밋 메시지가 있습니다.
이것이 바로 "연결되었다"는 증거입니다.
여기서 꼭 짚고 넘어가고 싶은 게 하나 있습니다.
파일 목록 위에 있는 "main" 이라는 글자입니다.
사물함 안에서 지금 어떤 책갈피를 보고 있는지 알려줍니다.
책갈피가 곧 브랜치입니다.
어떤 칸에 기록을 쌓고 있는지 표시하는 역할입니다.
앞으로는 이 "main" 을 직접 건드리지 마세요.
저도 처음엔 별생각 없이 넘겼습니다.
main 에서 바로 작업하다가, 원래대로 돌아가느라 시간을 허비했죠.
연결이 실패할 때는 대부분 주소 문제입니다.
끝에 ".git" 이 빠져 있거나,
계정 이름 철자가 틀렸거나요.
"not found" 가 뜨면 이미지 ② 에서 주소를 다시 복사하세요.
이제 로컬 기록이 GitHub 와 연결되었습니다. 다음은 Pull Request 로 병합하는 일상적인 사이클입니다.
**
2 장: Pull Request 로 병합하기 | AI 작업 제출하고 diff 확인 후 누르기
여기서부터가 매일 반복되는 사이클입니다.
Pull Request 는 "이거 병합해 주세요"라고 요청하는 제출 행위입니다.
이번 장에서는 초록색 버튼을 3 번 누릅니다.
타이핑은 AI 가 합니다.
여러분의 일은 보고 누르는 것뿐입니다.
먼저 AI 에게 한 줄을 보냅니다.
1새 브랜치를 만들고, README 에 사용법 3 줄을 추가한 뒤 커밋해서 GitHub 에 올려줘
README 는 저장소 설명을 적는 첫 번째 파일입니다.
Claude Code 가 브랜치를 만듭니다.
파일을 수정하고 커밋합니다.
마지막으로 push 직전에 멈춰서 물어봅니다.
"Yes" 라고 답한 뒤 브라우저로 사물함을 열어보세요.
상단에 노란색 배너가 뜹니다.
"방금 이 브랜치를 저장했어요"라고 알려주는 겁니다.
오른쪽 초록색 버튼 "Compare & pull request" 를 누르세요.
이것이 '제출'입니다.
선생님께 연습장을 내미는 것과 같습니다.
제출만 한다고 최종본에 내용이 복사되지는 않습니다.
복사는 검토를 거친 뒤에 일어납니다.
제출 화면에서 봐야 할 곳은 세 군데입니다.
첫째: 맨 위의 화살표.
"base: main" 과 "compare: work-branch"
어디서 어디로 병합할지를 보여줍니다.
왼쪽이 main 인지 정도만 확인하면 됩니다.
둘째: "Add a title" 의 제목.
AI 가 생성했다면 변경 요약이 포함됩니다.
직접 제출한다면 커밋 메시지가 미리 채워져 있습니다.
직접 제출할 때는 "무엇을 했는지" 한 줄로 적으세요.
셋째: 초록색 "Create pull request" 버튼.
누르면 제출이 접수됩니다.
제출 후에는 사람의 손길이 필요합니다.
화면 상단에 탭 4 개가 나타납니다.
맨 오른쪽 탭인 "Files changed" 만 보세요.
변경된 파일이라는 뜻입니다.
초록색 줄은 추가된 줄입니다.
빨간색 줄은 삭제된 줄입니다.
이것이 diff 입니다.
요청했던 3 줄이 초록색으로 잘 들어갔다면 통과입니다.
예시 화면에서는 제목과 빈 줄까지 추가되어 초록색이 6 줄이 되었습니다.
요청하지 않은 빨간색 줄이 있다면 병합하지 마세요.
예시 화면에는 빨간색 줄이 1 개 있습니다.
"Items placed" 에서 메모 한 줄이 사라졌습니다.
이걸 시킨 적이 없다면 여기서 멈추세요.
AI 에게 이렇게 물어보세요. "왜 이 빨간 줄을 지웠어?"
AI 에게 일을 맡길 때 가장 중요한 30 초가 바로 이때입니다.
리뷰 알림만 떠도 속이 쓰리던 시절, 저도 확인 없이 그냥 눌렀습니다.
지금은 무조건 빨간 줄부터 셉니다.
요청하지 않은 빨간 줄이 단 하나라도 있으면 멈춥니다.
diff 에 문제가 없다면 "Conversation" 으로 돌아갑니다.
아래쪽에 초록색 "Merge pull request" 버튼이 있습니다.
그 위에 "No conflicts with base branch" 가 떠 있다면 바로 병합해도 됩니다.
누르면 "Confirm merge" 로 바뀝니다.
한 번 더 누르세요.
이제 작업 브랜치의 기록이 main 으로 병합됩니다.
색이 보라색으로 바뀌며 "Merged" 가 표시됩니다.
아래에 "Pull request successfully merged and closed" 라는 상자가 뜹니다.
그 오른쪽에 "Delete branch" 가 있습니다.
편하게 누르셔도 됩니다.
사물함 안에 있던 작업 브랜치라는 '책갈피'만 사라질 뿐입니다.
기록은 이미 main 에 병합되었으니 잃어버리는 건 없습니다.
마지막으로 로컬 환경을 업데이트합니다.
AI 에게 "main 으로 전환하고 GitHub 에서 최신 내용을 받아와" 라고 보내세요.
이렇게 한 사이클이 끝납니다.
다음 작업은 항상 새 브랜치에서 시작하세요.
main 에서 바로 작업하면 안 됩니다.
여기까지 제출하고, diff 를 확인하고, 병합하는 사이클을 마쳤습니다. 다음은 병합 후 실수를 되돌리는 Revert 버튼 이야기입니다.
**
3 장: Revert 하기 | 병합 후 실수, 버튼 하나로 되돌리기
병합하고 나서야 실수를 발견할 때가 있습니다.
Git 은 저장된 기록을 지우지 않고 "되돌립니다".
GitHub 화면에도 이를 위한 버튼이 있습니다.
바로 "Revert" 입니다.
방금 병합한 Pull Request 를 다시 열어보세요.
"merged commit … into main" 이라는 문구가 있습니다.
그 줄 맨 오른쪽에 "Revert" 가 있습니다.
누르면 어떻게 될까요?
기록이 삭제되지 않습니다.
반대되는 변경 사항을 담은 새로운 Pull Request 가 만들어집니다.
공식 문서에 따르면, 이 새 Pull Request 를 병합해야 되돌리기가 완료됩니다.
즉, Revert 도 2 장과 똑같은 사이클을 따릅니다.
diff 를 확인하고 초록색 버튼을 누릅니다.
삭제하는 대신 "되돌렸다"는 기록이 추가됩니다.
AI 에게 시킬 때는 "방금 병합한 Pull Request 되돌려 줘" 라고 말하세요.
Claude Code 는 git revert 로 똑같이 처리합니다.
한 가지 더 마주칠 수 있는 화면이 있습니다.
"This branch has conflicts that must be resolved".
충돌(conflict)입니다.
main 과 작업 브랜치에서 같은 줄을 서로 다르게 수정했을 때 발생합니다.
초록색 버튼이 회색으로 변해 누를 수 없습니다.
화면에서 직접 고치지 말고, AI 에게 한 줄을 보내세요.
1main 을 받아와서 충돌 난 부분의 두 버전을 모두 보여줘
어떤 걸 살릴지는 여러분이 결정합니다.
AI 가 수정해서 다시 올리면 초록색 버튼이 돌아옵니다.
충돌은 실패가 아닙니다.
같은 줄이 두 번 편집되었다는 사실을 알려줄 뿐입니다.
마지막으로, 화면에는 보이지 않는 이야기입니다.
키(key)입니다.
비밀번호나 API 키가 담긴 파일은 절대 GitHub 에 올려서는 안 됩니다.
Revert 를 하더라도, 키가 올라간 순간 유출로 간주하여 새로 발급받아야 합니다.
업로드 전에 AI 에게 ".env 는 기록에서 제외해 줘" 라고 보내세요.
저도 실제 업무에서 AWS 설정을 텍스트 파일로 작성하며 이 사이클을 그대로 따릅니다.
diff 확인 없이 병합된 설정은 운영 환경에서 바로 실행됩니다.
그래서 버튼을 누르기 전 그 결정적인 30 초만큼은 AI 에게 맡기지 않습니다.
화면의 모든 버튼은 사람이 누릅니다.
AI 가 처리하는 범위를 넓혀가도 이 원칙은 변하지 않습니다.
이로써 연결, 제출, 병합, 되돌리기의 전체 사이클이 끝났습니다.
마지막으로, 바로 쓸 수 있는 자료를 드립니다.
GitHub 화면에서 한 사이클을 완성하는 절차를 정리했습니다.
이 글에 나온 화면과 프롬프트를 바로 쓸 수 있는 형태로 묶었습니다.
- GitHub 화면 번역 포스터 (화면 9 개, 용어 69 개)
- AI 가 망쳤을 때 복구 맵 (시나리오 6 개)
- 한 사이클 완성을 위한 프롬프트 7 개
- 병합 전 체크리스트 (8 개 항목)
총 15 쪽 PDF 소책자로 함께 전달합니다.
이것만 있으면 오늘 당장 사이클을 돌릴 수 있습니다.
받으려면 아래 오픈 채팅방에 참여하기만 하면 됩니다.
참여 후 안내에 따라 "Submit" 이라고 보내주시면 자동으로 도착합니다.
https://line.me/ti/g2/pEpZQdEyn1BM5Zi2wqLBT2rZYpC0ZaOncIWTag
요약: 오늘 딱 한 사이클만 완성하세요
AI 작업 결과를 바로 main 에 넣지 마세요.
작업 브랜치에서 제출하고, diff 를 확인한 뒤 초록색 버튼을 누르세요.
한 사이클에 눌러야 할 초록색 버튼은 3 개였습니다.
처음으로 직접 Revert 를 눌러본 날, 기록은 삭제되지 않는다는 걸 깨달았습니다.
그 뒤로는 무언가를 건드리는 게 두렵지 않았습니다.
한번에 다 할 필요는 없습니다.
오늘 해야 할 일은 딱 하나입니다.
1 장에서 만든 저장소를 열고 AI 에게 한 줄을 보내세요.
새 브랜치를 만들고, README 에 1 줄을 추가한 뒤 GitHub 에 올려줘
노란색 배너가 뜨면 초록색 버튼을 누르고 "Files changed" 를 열어보세요.
초록색 줄이 딱 1 개라면 통과입니다.
병합하기 전에 그 한 줄을 자기 눈으로 직접 확인하세요.
그것이 AI 에게 맡길 수 있는 영역을 넓히는 첫걸음입니다.
30 대 이상의 엔지니어에게 승부는 작업량이 아니라 설계에서 갈립니다.
도구가 업데이트될 때마다 다시 배우기보다, 어디서 멈출지 정하는 편이 훨씬 빠릅니다.
AWS 와 AI 는 빠르게 진화합니다.
혼자 쫓아가려 애쓰기보다, 실무에서 테스트하는 사람들의 로그를 보는 게 빠릅니다.
저는 AI × 엔지니어링 실천 과정에서 성공한 기록뿐만 아니라, 깨지고 제외된 기록도 함께 남깁니다.
앞으로의 인사이트를 놓치지 않으려면 팔로우해 주세요! @dan_pro_man
