깃허브

코드를 보관하고 함께 고치는 세계 최대 창고예요. 언제 무엇이 바뀌었는지 전부 남아서, 잘못되면 그 시점으로 정확히 돌아갈 수 있어요.

쉽게 말하면

날짜별로 전부 남는 장부예요. 가게 장부를 고칠 때마다 지우고 새로 쓰면 어제 무슨 일이 있었는지 사라지죠. 깃허브는 고칠 때마다 그 시점을 통째로 보관해요. "3일 전 저녁으로 돌려줘"가 되는 겁니다.

그리고 여러 사람이 같은 장부를 동시에 고칠 수 있어요. 누가 어디를 고쳤는지 표시되고, 두 사람이 같은 줄을 고치면 알려줍니다. 개발자들이 협업할 때 거의 예외 없이 이걸 쓰는 이유예요.

직접 쓰실 일은 많지 않아요. 그런데 두 가지 이유로 알아둘 가치가 있어요.

1내 코드가 여기 있으면 그건 내 것이에요. 외주 업체가 자기 컴퓨터에만 갖고 있으면, 헤어질 때 못 받는 일이 생겨요. 사장님 계정 창고에 있으면 그럴 일이 없습니다.
2개발자를 새로 구할 때 인수인계가 됩니다. 지금까지 무엇이 어떻게 바뀌었는지가 다 남아 있어서, 새 사람이 이어받기가 훨씬 쉬워요.
3사고가 나도 되돌아갈 수 있어요. 백업보다 정밀해요. 어제 상태가 아니라 "어제 오후 3시 그 상태"로 갈 수 있거든요.

계약할 때 한 줄 넣으세요

"코드는 사장님 명의 저장소에 보관한다." 이 한 줄이 나중에 업체와 헤어질 때 사장님을 지켜 줍니다. 만들 때 넣기는 쉽고, 헤어질 때 요구하기는 어려워요.

저장소를 만들 때 공개할지 말지를 고릅니다. 이 선택이 사고와 직결돼요.

공개 저장소

전 세계 누구나 내 코드를 볼 수 있어요

코드에 [[env-vars|비밀키]]가 섞여 있으면 몇 분 안에 발견됩니다. 요금 폭탄 사고의 절반이 여기서 나요.

비공개 저장소

내가 허락한 사람만 볼 수 있어요

장사에 쓰는 코드는 이쪽이에요. 지금은 무료 계정도 비공개를 쓸 수 있어요.

공개로 두면 나중에 비공개로 바꿔도 늦어요. 그 사이에 누가 복사해 갔을 수 있고, 이미 발견된 키는 이미 새어 나간 거예요. 비밀키가 들어 있었다면 저장소를 비공개로 바꾸는 것과 별개로 키를 폐기하고 새로 발급받아야 합니다.

장면 1 · 개발자가 저장소 초대를 보냈다

“깃허브 가입하고 초대 수락해 달라는데, 뭘 하는 건지 모르겠어요.”

사장님 계정으로 창고를 만들고 개발자를 손님으로 초대하는 것이 좋은 구조예요. 반대로 개발자 계정 창고에 사장님이 초대받는 구조면, 헤어질 때 창고가 개발자 것으로 남습니다. 어느 쪽인지 물어보세요.

장면 2 · 요금 폭탄을 맞았다

“AI 요금이 갑자기 몇백만 원 나왔어요. 개발자가 코드를 깃허브에 올렸다는데요.”

공개 저장소에 키가 같이 올라간 전형적인 사고예요. 즉시 그 키를 폐기하고, 저장소를 비공개로 돌리고, 발급처에 사고 신고를 하세요. 요금은 감면되는 경우가 많습니다. 순서는 폐기가 먼저예요.

Q. 깃허브를 꼭 써야 하나요?: 바이브캠퍼스만 쓰신다면 필수는 아니에요. 바이브캠퍼스 안에 이전 상태가 남고 코드도 내려받을 수 있으니까요. 개발자와 협업하거나 직접 관리하고 싶어질 때 필요해집니다.
Q. 돈이 드나요?: 개인이 쓰는 수준은 무료예요. 비공개 저장소도 무료로 만들 수 있어요.
Q. 코드 말고 다른 것도 올려도 되나요?: 사진이나 문서도 되지만 손님 명단 같은 개인정보는 절대 올리지 마세요. 비공개라도 위험합니다.
Q. 깃과 깃허브는 다른 건가요?: 깃은 변경 기록을 남기는 방식이고, 깃허브는 그걸 인터넷에서 쓰게 해 주는 서비스예요. 방식과 가게의 관계라고 보면 됩니다.
Q. 실수로 올린 걸 지우면 사라지나요?: 안 사라져요. 지운 것도 기록에 남는 게 이 도구의 성격이라서요. 그래서 비밀키를 올렸다면 지우는 것으로 끝내지 말고 반드시 키를 폐기해야 해요.

확인해 보세요

공개 저장소에 비밀키가 올라간 걸 발견했어요. 지우면 될까요?

하나 더

개발자와 협업할 때 저장소는 누구 계정에 두는 게 좋을까요?

직접 해보기

코드 내려받기부터 해 두세요

깃허브를 안 쓰더라도 내 작업물에서 코드를 내려받아 두면 그 자체가 완전한 사본이에요. 지금 한 번 해 두세요.

더 깊이 (안 읽어도 괜찮아요)

시점마다 이름을 붙인다 · 고칠 때마다 "무엇을 왜 고쳤는지" 한 줄을 함께 남겨요. 이 한 줄들이 쌓이면 사업의 역사가 됩니다. 좋은 팀은 이 한 줄을 정성껏 쓰는데, 나중에 문제를 찾을 때 이게 지도가 되기 때문이에요.

갈라졌다 합치기 · 새 기능을 시험할 때 본래 것을 건드리지 않고 옆길을 하나 내서 거기서 작업해요. 잘되면 합치고, 아니면 버립니다. 그래서 손님이 보는 화면은 계속 멀쩡한 채로 실험할 수 있어요.

창고가 자동으로 일도 해요 · 코드가 올라올 때마다 검사를 돌리거나 자동으로 게시하게 만들 수 있어요. 규모가 커지면 사람이 하던 반복 작업을 여기에 맡깁니다.

이것만 기억하세요