9장. 팀원에게 코드 공유하기 — Fork, PR, 충돌 해결

풀 리퀘스트는 "내 변경을 검토해 줘"라는 요청입니다. Fork는 원본을 건드리지 않고 내 복사본에서 작업하는 안전장치입니다.

2026년 6월 15일 월요일 방과 후, 박혜원 체육 선생님이 교무실 자리로 다가와 말을 걸었습니다. "진관 쌤, 저도 2학년 체육 수행평가 결과 페이지 만들고 싶은데요. class-2b에 같이 올려도 돼요?" 박혜원 선생님은 1학기 동안 김진관 선생님이 학급 웹사이트를 키워가는 걸 옆에서 지켜봐 왔습니다. 두 선생님은 그날 방과 후에 나란히 앉아 작업을 시작했습니다. 저녁이 되자 박혜원 선생님이 집에서도 이어서 하겠다며 파일을 카카오톡으로 받아갔습니다. 다음 날 아침 두 사람이 각자 수정한 버전을 합치려는데 VSCode 터미널에 CONFLICT라는 붉은 글자가 떴습니다. 같은 파일의 같은 줄을 두 사람이 다르게 고친 것이었습니다. 이날 두 선생님은 카카오톡으로 파일 덩어리를 주고받는 방식을 그만두기로 했습니다.

이 챕터를 마치면 다음을 할 수 있습니다.

• 저장소를 Fork해 내 계정에 복사본을 만들 수 있습니다.
• 풀 리퀘스트(PR)로 변경을 제안하고 검토·Merge 과정을 거칠 수 있습니다.
• 충돌(Conflict)이 생겼을 때 VSCode에서 해결할 수 있습니다.
• Issues로 할 일과 버그를 기록하고 PR과 연결할 수 있습니다.

(1) Fork — 수업 자료를 내 폴더로 복사해 오기

다른 선생님이 만든 수업 자료 파일을 공유 드라이브에서 그대로 고치지 않고, 내 폴더에 복사한 뒤 거기서 작업하는 것과 같습니다. Fork는 GitHub 저장소를 내 계정에 통째로 복사하는 기능입니다. 원본에는 손도 대지 않은 채 내 복사본에서 마음 놓고 실험할 수 있습니다.

박혜원 선생님의 화면으로 실습해 봅니다. GitHub에 로그인한 상태에서 github.com/jinkwan-kim/class-2b에 접속합니다. 오른쪽 위 Fork 버튼을 클릭합니다. 대상 계정을 hyewon-park로 선택하고 Create fork 버튼을 누릅니다. 5초 뒤 github.com/hyewon-park/class-2b에 복사본이 생깁니다. Quick Win 성공입니다. 원본 class-2b는 한 줄도 바뀌지 않았고, 박혜원 선생님 계정에 독립된 복사본이 생겼습니다.

복사본을 내 컴퓨터로 내려받는 과정은 4장에서 다룬 clone과 같습니다. GitHub Desktop의 Clone a repository에서 hyewon-park/class-2b를 선택하거나, VSCode에서 Clone Repository → 복사본 URL 입력으로 끝납니다.

잘 안 되면? Fork 버튼이 보이지 않는다면 GitHub 로그인이 풀린 상태입니다. 오른쪽 위 아바타를 눌러 로그인 상태를 확인합니다. 이미 같은 이름으로 Fork한 저장소가 있으면 새로 Fork할 수 없고 기존 복사본으로 이동합니다. 이 경우 기존 복사본을 삭제하거나 새 이름으로 진행합니다.

(2) 풀 리퀘스트 — 학습지를 부장님께 "이대로 인쇄해도 될까요?"

수정한 학습지를 인쇄소로 보내기 전에 학년 부장 선생님께 "이대로 인쇄해도 될까요?" 검토를 부탁하는 과정과 같습니다. 풀 리퀘스트(Pull Request, 줄여서 PR)는 내 Fork에서 한 작업을 원본 저장소에 "이 변경을 받아 주세요"라고 제안하는 요청서입니다. 받는 쪽은 내용을 읽고 질문하거나 수정을 요구하거나 Merge(병합) 버튼을 눌러 승인합니다.

박혜원 선생님이 복사본에서 체육 수행평가 페이지를 만들고 커밋까지 마쳤다고 가정합니다. hyewon-park/class-2b 저장소 페이지에 접속하면 상단에 노란 배너로 Compare & pull request 버튼이 뜹니다. 이 버튼을 누르면 PR 작성 화면이 열립니다. 제목에는 "체육 수행평가 결과 페이지 추가", 본문에는 "2학년 체육 수행평가 결과를 class-2b에 반영했습니다. 학생 이름은 이니셜 처리, 점수는 구간으로 공개했습니다."처럼 무엇을 왜 바꿨는지 적습니다. Create pull request 버튼을 누르면 김진관 선생님에게 검토 요청이 도착합니다.

김진관 선생님은 PR 페이지의 Files changed 탭에서 Diff를 확인합니다. 마음에 들면 Merge pull request 버튼을 눌러 원본에 반영합니다. 이 순간 박혜원 선생님의 체육 수행평가 페이지가 원본 class-2b의 공식 페이지로 합쳐집니다. 카카오톡으로 파일을 주고받을 필요가 없어집니다.

잘 안 되면? Compare & pull request 버튼이 안 보인다면 복사본에 새 커밋이 없다는 뜻입니다. 커밋과 푸시를 먼저 끝냅니다. PR 생성 화면에서 base 저장소가 원본(jinkwan-kim/class-2b)으로, head 저장소가 내 복사본(hyewon-park/class-2b)으로 설정되어 있는지 확인합니다. 방향이 반대면 내 복사본에 원본이 들어오는 엉뚱한 PR이 생깁니다.

(3) 충돌 해결 — 같은 Word 문서를 두 사람이 다르게 고친 상황

두 선생님이 같은 Word 학습지 파일의 같은 문장을 각자 다르게 수정한 뒤 하나로 합치려는 상황과 같습니다. Git도 서로 다른 두 변경이 같은 줄을 건드렸을 때는 어느 쪽이 맞는지 스스로 결정하지 않습니다. 그 대신 파일 안에 <<<<<<<, =======, >>>>>>> 마커를 꽂아 두고 사람에게 "너희가 결정해" 하고 넘겨버립니다. 이 상태가 충돌(Conflict)입니다.

VSCode는 충돌을 친절하게 보여줍니다. 충돌이 난 파일을 열면 상단에 Accept Current Change, Accept Incoming Change, Accept Both Changes, Compare Changes 네 개의 작은 버튼이 뜹니다. Current는 내 변경, Incoming은 합치려는 상대 변경입니다. 박혜원 선생님의 PR에서 충돌이 났다면 김진관 선생님은 파일을 열어 네 버튼 중 하나를 누르거나, 필요하면 마커 사이의 내용을 직접 손으로 고쳐 <<<<<<<, =======, >>>>>>> 세 줄을 모두 지운 뒤 저장합니다.

해결이 끝나면 Source Control 패널로 돌아가 이 파일을 스테이징하고 커밋합니다. 커밋 메시지는 "체육 수행평가 페이지 충돌 해결"처럼 무슨 충돌을 어떻게 해결했는지 적습니다. 푸시하면 PR 페이지에 자동 반영되고 Merge 버튼이 다시 초록색으로 살아납니다.

잘 안 되면? 커밋하려는데 "unmerged paths"라는 메시지가 뜬다면 아직 해결하지 않은 충돌이 남아 있다는 뜻입니다. VSCode 상단 검색(Ctrl+Shift+F)에서 <<<<<<< 일곱 글자를 검색합니다. 하나라도 결과가 나오면 그 파일이 미완성입니다. 모두 제거해야 커밋이 통과합니다. 충돌 해결을 포기하고 처음부터 다시 하고 싶다면 터미널에서 git merge --abort를 실행해 충돌 시도 자체를 없던 일로 만듭니다.

(4) Issues — PR이 "완성된 제안"이라면 Issues는 "의논 중인 주제"

학년 회의에서 "이번 학기 체험학습 장소 어디로 할까요?"처럼 아직 결론이 나지 않은 안건을 공식 기록으로 남기는 것과 같습니다. Issues는 GitHub 저장소 탭 중 하나로 "메인 페이지 폰트가 너무 작다", "모바일에서 표가 깨진다" 같은 건의사항이나 버그 제보를 기록하는 공간입니다. 제목과 내용을 적고, 담당자(Assignees)와 라벨(bug, enhancement 등)을 지정합니다.

박혜원 선생님이 "체육 수행평가 페이지 색상이 학급 컬러랑 안 맞아요"라고 Issue를 열면, 김진관 선생님이 담당자로 지정되어 알림을 받습니다. 이 Issue를 해결한 PR을 만들 때 본문에 Closes #12처럼 Issue 번호를 적으면 PR이 Merge되는 순간 Issue가 자동으로 닫힙니다. 의논에서 실행까지 한 줄로 연결됩니다.

카카오톡 파일 전송의 마지막 날

방과 후 교무실에서 김진관 선생님은 박혜원 선생님이 보낸 PR의 Merge pull request 버튼을 눌렀습니다. 체육 수행평가 페이지가 class-2b에 공식으로 합쳐졌습니다. 카카오톡에 파일 덩어리를 붙여 보내던 방식은 그날로 끝났습니다. 두 선생님은 다음 주부터 Issues에 건의사항을 먼저 올리고, 각자 Fork한 복사본에서 작업한 뒤 PR로 검토를 요청하기로 했습니다.

핵심 3줄 요약

• Fork는 원본 저장소를 내 계정에 복사해 안전하게 실험할 공간을 만드는 기능입니다.
• 풀 리퀘스트는 내 복사본의 변경을 원본에 "받아 주세요" 제안하고 검토·Merge를 거치는 절차입니다.
• 충돌이 나면 VSCode의 Accept Current / Incoming / Both 버튼으로 해결하고 <<<<<<< 마커가 남아 있지 않은지 검색으로 확인합니다.

완료 체크리스트

• 나는 이제 저장소를 Fork해 내 계정에 복사본을 만들 수 있습니다.
• 나는 이제 풀 리퀘스트로 변경을 제안하고 Merge 과정을 이해합니다.
• 나는 이제 VSCode에서 충돌을 해결하고 커밋까지 마칠 수 있습니다.

다음 10장에서는 바이브 코딩의 가장 큰 위험 — API 키 노출과 그 예방법을 다룹니다. 8장에서 이름만 언급했던 .gitignore를 실제로 만들고, 이미 올라간 키를 어떻게 무효화하는지 손으로 익힙니다.