바이브 코딩으로 만든 앱이 쓸 만해지면 곧 이런 일이 생깁니다. «옆 팀 담당자도 같이 고치고 싶대요», «제가 다음 달에 부서를 옮기는데 이 앱은 누가 관리하죠?» 이 글은 GitHub를 «혼자 쓰는 창고»에서 «팀이 같이 쓰는 창고»로 바꾸는 네 가지를 다룹니다. 예시는 «실전 01»에서 웹 Claude Code가 실제로 남긴 브랜치와 PR(풀 리퀘스트)입니다 — AI도 사람 동료처럼 «제안하고, 검토받고, 합치는» 방식으로 일했습니다.
| 말 | 쉬운 뜻 | 왜 필요한가 |
|---|---|---|
| 협업자(Collaborator) | 비공개 창고에 들어올 수 있는 사람 | 비공개 저장소는 초대한 사람만 보고 고침 |
| 브랜치(branch) | 원본을 건드리지 않는 «내 사본» | 여럿이 동시에 고쳐도 원본이 안 망가짐 |
| PR(풀 리퀘스트) | «이 사본을 원본에 합쳐도 될까요?» 제안서 | 합치기 전에 사람이 보고 승인 |
| Merge(머지) | 제안을 원본에 합치기 | 합치면 Vercel·Cloudflare가 자동 배포 |
저장소 안에 열쇠(API 키)나 실제 개인정보가 없는지 먼저 점검하세요(«바이브 04»). 초대받은 사람은 지난 기록까지 전부 볼 수 있습니다. 외부 협력사라면 일이 끝난 뒤 초대를 해제하는 것까지가 한 세트입니다.
«실전 02»의 Codex는 혼자 쓰는 저장소라 main에 바로 올렸고, «실전 01»의 웹 Claude Code는 기본적으로 브랜치 + PR로 일했습니다. 팀으로 쓰는 앱이라면 AI에게도 «브랜치에서 고치고 PR로 올려줘»라고 시키는 것이 안전합니다.
| 비개발자 검토 체크 | 보는 곳 |
|---|---|
| 설명이 내가 시킨 일과 맞나 | PR 첫 글(요약·주요 내용) |
| 확인(테스트)을 했다고 적혀 있나 | «확인» 항목, Checks 탭 |
| 엉뚱한 파일이 바뀌지 않았나 | Files changed의 파일 목록 |
| 열쇠·개인정보가 섞이지 않았나 | AI에게 «이 PR에 비밀 값이 있는지 점검해줘» |
개인 GitHub·Vercel 계정에 둔 업무 앱은 담당자가 바뀌면 «주인 없는 앱»이 됩니다. 사내에서 계속 쓸 앱이라면 처음부터 회사 조직 계정에 두는 것을 권합니다.
이번 수정은 main에 바로 올리지 말고 새 브랜치에서 작업한 뒤 PR로 올려줘. PR 설명에는 무엇을 왜 바꿨는지, 어떻게 확인했는지, 사람이 확인해야 할 점을 쉬운 말로 적어줘. 내가 승인하기 전에는 합치지 마.
이 저장소의 열린 PR을 검토해줘. 개발자가 아닌 내가 판단할 수 있게 1) 무엇이 바뀌는지 3줄 요약 2) 위험해 보이는 변경 3) 비밀 값·개인정보가 섞였는지 4) 합쳐도 되는지 너의 의견을 알려줘.
이 앱을 다른 담당자에게 넘기려고 해. 저장소에 HANDOVER.md 를 만들어줘. - 이 앱이 하는 일, 쓰는 사람, 주소 - 연결된 서비스(GitHub·배포처·장부·AI)와 각각 어디서 관리하는지 - 환경 변수 이름 목록(값은 절대 적지 말 것)과 새로 발급하는 법 - 자주 생기는 문제와 해결법, 한 달 점검표 비개발자도 읽을 수 있게 써줘.
2026년 10월 8일 «실전 01·02»에서 AI가 실제로 남긴 GitHub 기록을 열어 찍었습니다. 동료 초대 화면은 GitHub 본인 확인 단계가 있어 경로만 안내했습니다.