Part 1. Git, 인터넷과 만나다 - 원격 리포지토리
원격이 뭐길래?
원격 저장소는 한마디로 "클라우드에 있는 내 Git 폴더"입니다.
구글 드라이브 아시죠? 원격 저장소는 그것의 Git 버전이에요. 다만 파일만 올라가는 게 아니라 모든 커밋 히스토리, 브랜치, 타임라인까지 통째로 올라갑니다.
여러 사람이 함께 일할 때는 원격 저장소가 필수입니다. 각자 컴퓨터에서 작업한 걸 한 곳에 모아야 하거든요. 원격이 있으면 "누가 언제 뭘 바꿨는지" 전부 기록되고, 모두가 최신 코드를 받아볼 수 있습니다.
GitHub, GitLab, Bitbucket 같은 서비스들이 이런 원격 저장소를 제공합니다. 대부분 무료로 시작할 수 있고, GitHub는 특히 개인 프로젝트는 무제한 무료예요.
바이브코더에게도 원격 저장소는 필수입니다
- 어디서든 AI와 작업 가능 집에서 작업하던걸 회사 컴퓨터에서 이어서 할 수 있으려면 원격 저장소가 필요합니다. git push로 원격에 올리고, git pull로 받으면 돼요. 낮에는 회사 데스크톱에서 Claude와 작업한 코드를 저녁엔 집 노트북에서 이어서 GPT와 계속 작업할 수 있어요. 그게 정말 좋은건지(?)는 본인 판단입니다 🤣
- 자동 백업 + 맘껏 실험하기 뭔가 크게 망가뜨렸어도 걱정 없어요. 원격에서 깨끗한 버전을 다시 받으면 됩니다. git clone이라는 명령어 하나면 프로젝트 전체를 새로 받을 수 있죠. 컴퓨터가 고장 나도 상관없습니다. 새 컴퓨터에서 GitHub 로그인하고 clone 하면 모든 작업 내역이 그대로 돌아옵니다.
- 바로바로 미리보기 Vercel이나 Netlify 같은 배포 플랫폼을 이용하면, "이렇게 보일 거예요~" 하고 웹사이트를 자동으로 만들어줍니다. 수정할 때마다 바로바로 결과를 볼 수 있어요. 특히 브랜치별로 다른 URL을 만들어주는 게 정말 편해요. feature/claude-design 브랜치는 xxxxxxxx.vercel.app으로, feature/gpt-design 브랜치는 yyyyyyyy.vercel.app으로 각각 배포되니까 사이트를 여러개 열어놓고 비교하기 쉽죠. 이건 5편에서 또한번 설명드릴게요~!
(*배포라는 개념이 지금은 잘 안와닿을 수 있어요. 다음주 뉴스레터는 '배포'에 대해 설명합니다. 배포란게 뭔지, 배포를 할때 코드는 어떻게 동작하고 어떤 과정을 거쳐 우리눈에 보이는지. 이런것들이요. 기대해주세요 👀)
- 내 성장 기록이 쌓이는 곳 원격 저장소는 단순한 백업이 아니라 포트폴리오예요. 6개월 전 커밋과 지금을 비교하면 "와, 내가 이만큼 성장했구나" 느낄 수 있습니다. 취업이나 이직할 때도 GitHub 프로필 링크 하나면 "이 사람이 어떻게 일하는구나"를 보여줄 수 있어요. 꾸준히 커밋하고, 브랜치 관리 잘하고, AI 도구들과 협업하는 모습이 다 기록으로 남으니까요.
Part 2. 병합과 충돌 - 두 갈래 길이 만날 때
병합이 뭐길래?
병합(Merge)은 두 개의 브랜치를 하나로 합치는 것입니다.
Claude용 브랜치, GPT용 브랜치를 만들어서 각각 작업했다면, 결국엔 가장 좋은 걸 골라서 main 브랜치에 합쳐야 해요. 이게 병합입니다.
대부분은 Git이 알아서 합쳐줍니다. 예를 들어 Claude는 헤더를 수정했고, GPT는 푸터를 수정했다면? 충돌 없이 자동으로 합쳐져요. 둘 다 반영됩니다.
문제는 같은 부분을 다르게 수정했을 때입니다. Claude도 버튼 색을 바꿨고, GPT도 같은 버튼 색을 바꿨다면? Git은 "어... 뭘 선택해야 할지 모르겠어요!"라고 손을 듭니다. 이게 충돌(Conflict)입니다.
충돌은 언제 생기나요?
주로 협업을 할때나 브랜치를 병합할 때 생깁니다. 앞서 말했듯 같은 코드를 양쪽에서 수정했을때요.
코딩할 때 한번에 한파일 안에서만 작업하는 경우는 드뭅니다.
하나의 기능을 추가하더라도 다수의 파일에 들어가서 코드를 조금씩(또는 대거) 수정해야 하기 때문에, 두명이상 또는 두 브랜치 이상이 함께 작업해 나가게 되면 십중팔구 작업이 겹치는 파일이 생기고 충돌은 불가피하게 발생합니다.
혼자 작업해도 충돌이 생깁니다!
아침에 데스크탑에서 하던 작업을 점심에 이어서하려고 스타벅스에 노트북을 들고 왔는데..
아차, 데스크탑에서 push하는걸 깜빡했어요. 결국 노트북으로 처음부터 작업을 다시 하고 일단 잊지않고 원격에 push를 했습니다.
그리고 다시 집에 돌아와서 데스크탑에서 pull을 하려고 하면? 아침에 작업하던것(push를 깜빡했던)과 노트북에서 push한 부분이 겹쳐, "어? 충돌이네?"라는 메시지가 뜹니다.
집 컴퓨터의 변경사항과 노트북의 변경사항이 부딪친 거죠.
충돌이 생기면 어떻게 하나요?
바이브코더의 방법을 알려드릴게요. (*일반적인 방법은 하단 부록 참고)
충돌은 나쁜 게 아니에요
충돌을 버그라고 생각하기 쉬운데, 사실은 "이 부분 한 번 더 생각해봐"라는 Git의 친절한 알림입니다.
두 명의 AI가 같은 부분을 다르게 개선했다는 건, 그 부분이 중요하다는 뜻일지도 몰라요. 충돌을 해결하면서 "아, 이렇게 하는 게 더 낫겠네!"하는 인사이트를 얻을 때도 있습니다.
충돌은 구글 문서에서 동시 편집하다가 "어? 같은 문장을 둘이 고쳤네?"할 때와 비슷합니다. 다만 Git은 더 체계적으로 "여기 봐주세요"라고 정확히 알려주고, 모든 과정이 기록으로 남는다는 점이 다르죠.
마무리: 원격, 병합, 충돌. 두려워하지 마세요.
원격 저장소는 프로젝트에 날개를 달아줍니다. 나 혼자가 아닌 여러사람과 함께 작업해서 결과를 빨리 달성할 수도 있고, 답답한 한공간에서 벗어나 디지털 노마드처럼 원하는 공간에서 원하는 디바이스로 작업할 수도 있게 해주죠.
병합과 충돌은 더 나은 코드를 만드는 기회입니다. 처음엔 충돌 메시지가 무서워 보일 수 있지만, 몇 번 해결해보면 "아, 이거구나!" 싶을 거예요. 이를 자연스러운 협업의 과정으로 여기고 받아들이게 되면, 개발 과정의 안정성과 더불어 다양한 의견이 모여 시너지가 일어나는 인사이트풀한 경험 도모해볼 수 있습니다!
다음 편 예고: 전 세계 개발자들이 모여드는 개발자들의 놀이터 GitHub. 다음편에서는 GitHub를 소개하고 "그래서 우리가 뭘 하고 놀 수 있는데?"를 알아보겠습니다 🚀
그럼, 목요일날 뵙겠습니다!
(*아래 내용은 부록입니다)
실습을 위한 샘플 시나리오: 시간대가 다른 팀원의 충돌
상황을 가정해봅시다. 한국에 있는 개발자 철수와 미국에 있는 개발자 Anna가 같은 프로젝트를 진행 중입니다. 철수는 낮 시간대에 피처 X를 개발하고 있었고, Anna는 철수가 자는 동안(미국 낮 시간)에 우연히 같은 파일의 일부를 수정했습니다.
- 철수는 오전에 자신의 작업 브랜치를 main에 푸시하지 않은 채 작업을 계속했고, Anna는 그 사이 main 브랜치를 최신 상태로 받아 다른 수정을 한 후 main에 푸시했습니다.
- 다음 날 철수가 본인 코드를 main에 푸시하려고 git push를 했더니, “failed to push” 오류가 나면서 푸시가 거부됩니다. 이는 remote(main)이 이미 본인 로컬보다 더 앞으로 나아갔기 때문입니다. 철수는 먼저 git pull로 원격 변경사항(Anna의 커밋)을 가져옵니다.
- git pull 결과 Git은 철수의 변경과 Anna의 변경이 같은 파일의 같은 부분을 수정했음을 감지합니다. 자동으로 merge 시도를 했으나 충돌이 발생했다는 메시지가 뜹니다:
Auto-merging filename.txt
CONFLICT (content): Merge conflict in filename.txt
Automatic merge failed; fix conflicts and commit the result.Git은 충돌이 난 파일(filename.txt) 안에 특수한 충돌 표시를 삽입합니다. 파일을 열어보면 다음과 같은 마커를 볼 수 있습니다:
<<<<<<< HEAD
(철수의 변경 내용)
=======
(Anna의 변경 내용)
>>>>>>> origin/mainHEAD쪽(위쪽)은 내 변경, 그 아래 =======부터 >>>>>> 사이는 원격(main, 즉 Anna)의 변경입니다.
- 철수와 Anna는 이 충돌 지점을 함께 논의합니다. 두 사람의 수정 내용을 비교해보니, 일부는 철수의 구현이 더 적절했고, 다른 부분은 Anna의 개선이 유효했습니다. 협의 결과: 철수의 기능 코드와 Anna가 고친 버그 수정 코드를 모두 살리는 방향으로 합치기로 했습니다.
- 철수는 에디터에서 충돌 표시 구간을 직접 편집합니다. 불필요한 표시(<<<<<<, ======, >>>>>>)를 모두 지우고, 필요한 코드만 남겨 새로운 최종 내용을 만듭니다. 파일 저장 후 git add filename.txt로 수정된 파일을 스테이지하고 git commit을 실행하면, Git은 merge commit을 만들면서 “Merge conflict resolved” 등의 기본 메시지를 기록합니다.
- 이제 git push를 하면 철수와 Anna의 작업이 모두 반영된 최신 main이 원격에 올라갑니다. 모두가 같은 상태를 보게 되었고 충돌은 해결되었습니다.
이 시나리오에서 핵심은 동일 파일을 동시에 수정하면 충돌이 발생할 수밖에 없고, Git이 이를 막거나 자동해결해주진 않는다는 것입니다. 대신 Git은 충돌 지점을 명확히 보여주므로, 협업자들이 머리를 맞대고 어느 쪽 변경을 살릴지, 혹은 합쳐서 새 결과물을 만들지 대화와 합의를 해야 합니다. 이는 협업의 본질적인 부분이며, Git은 그 과정을 투명하게 도와주는 도구입니다.
충돌을 줄이기 위한 협업 습관
항상 충돌이 나고 나서 해결하기보다는, 애초에 충돌 가능성을 줄이는 협업 방식을 취하는 것이 좋습니다. 경험 많은 리뷰어나 팀 리드는 아래와 같은 규칙을 제안하곤 합니다:
- 작은 단위 기능별 브랜치와 PR: 한 번에 너무 많은 파일을 수정하거나 여러 기능을 한꺼번에 개발하지 않습니다. 작업을 가능한 잘게 나누고, 각 작업마다 별도의 브랜치에서 진행한 후 Pull Request로 merge합니다. 이렇게 하면 다른 사람이 동시에 같은 부분을 건드릴 확률이 줄고, 충돌이 나더라도 영향 범위가 작습니다.
- 명확한 커밋 메시지와 PR 설명: 커밋 메시지나 PR 본문에 “무엇을, 왜” 변경했는지 기록합니다. 예를 들어 “Fix signup form validation bug (#101)”처럼 이슈 번호를 언급하거나, “리팩터: 함수 validateInput을 모듈화하여 재사용성 개선” 등 상세히 적습니다. 이렇게 해두면 나중에 충돌 상황에서 어느 커밋이 어떤 의도로 이루어졌는지 파악하기 쉬워집니다. (GitHub PR 본문에 템플릿을 두어 변경 요약, 체크리스트 등을 작성하게 하는 프로젝트도 많습니다.)
- 코드 리뷰와 소통: PR을 올리면 다른 팀원이 리뷰를 하고 승인을 받는 문화를 지닙니다. 리뷰 과정에서 “이 부분은 내가 곧 작업할 예정인데, 네 변경과 겹칠 수 있으니 조정하자” 같은 사전 조율이 가능합니다. 사람이 직접 대화하는 과정에서 잠재 충돌을 발견하고, 미리 한쪽 작업 순서를 조정하거나, 아예 협력하여 한 PR로 합치는 전략도 세울 수 있습니다.
- 일관된 코딩 규칙과 코드 스타일: 사소하지만 줄바꿈이나 포맷 때문에 충돌이 나는 경우도 있습니다. 팀별로 코드 스타일 가이드나 자동 포매터(Prettier, ESLint 등)를 활용해 스타일을 통일하면, 같은 내용의 수정이라도 충돌 없이 적용되는 경우가 많습니다.
의견을 남겨주세요