저장소

코드를 여럿이 다루는 가장 원시적인 방법은 폴더를 압축해 주고받는 것입니다. 고친 사람이 넘기고 받은 사람이 풀어서 이어 작업합니다. 혼자 만들 때는 충분합니다.

사람이 둘을 넘으면 세 가지가 동시에 걸립니다. 페이지덱 초기에 서버 코드를 이 방식으로 주고받은 적이 있습니다. 파일 이름이 날짜와 사람 이름과 최종이라는 말이 겹쳐 붙은 모양이 됐고, 어느 것이 운영에 올라가 있는 코드인지 아무도 확실히 답하지 못했습니다.

두 번째는 이유가 남지 않는 것입니다. 한 달 전에 어떤 조건문이 추가돼 있었는데 왜 넣었는지 아는 사람이 없었습니다. 지우면 무언가 깨질 것 같아서 아무도 손대지 않은 채 반년이 지났습니다.

세 번째는 덮어쓰기입니다. 두 사람이 같은 주에 각자 고친 뒤 순서대로 넘기면 나중에 넘긴 쪽이 앞의 수정을 지웁니다. 사라진 코드는 다음 배포에서 기능이 없어진 형태로 드러납니다.

코드와 이력을 한 공간에 함께 담아 두고 그 공간을 유일한 기준으로 삼는 것이 이 개념입니다.

코드 파일과 그 파일들이 바뀌어 온 기록을 한 공간에 함께 담습니다. 안에 들어 있는 것은 넷입니다.

1. 지금 시점의 파일 전체.
2. 모든 커밋 기록. 변경을 한 덩어리로 묶은 지점이고, 무엇을 왜 바꿨는지 적은 메시지가 붙습니다.
3. 갈라져 나온 작업 줄기인 브랜치 목록. 지금 누가 어디에서 무엇을 만들고 있는지가 여기 보입니다.
4. 이 공간에만 적용되는 설정. 무엇을 이력에 담지 않을지, 합치기 전에 누구의 승인이 필요한지 같은 규칙입니다.

특징은 이 전체가 통째로 복사된다는 점입니다. 사실상 표준인 Git은 분산형이라서 각자의 컴퓨터에 파일뿐 아니라 전체 이력이 복사돼 있고, 네트워크가 끊긴 상태에서도 반년 전 기록을 뒤질 수 있습니다. 중앙에 둔 저장소가 기준인 것은 기술적 제약이 아니라 팀의 약속이고, 각자의 복사본과 중앙 저장소를 밀고 당겨 맞춥니다.

경계를 어디로 잡을지는 정해진 답이 없습니다. 보통 한 제품이나 한 서비스가 하나를 씁니다. 여러 프로젝트를 한 공간에 모아 두는 모노레포 방식도 있습니다. 가르는 기준은 둘입니다. 함께 배포되는지, 그리고 한 변경이 양쪽을 같이 고쳐야 하는지입니다. 웹 화면과 서버가 늘 함께 나가고 API 규격이 바뀔 때마다 둘을 동시에 고쳐야 한다면 나눠 둔 값이 크지 않습니다.

들어가면 안 되는 것도 있습니다. 접속 키와 비밀번호는 한 번 커밋되면 이력에 남아서, 다음 커밋에서 지워도 과거 기록을 열면 그대로 보입니다. 공개 저장소에서는 올린 지 몇 분 안에 자동 수집 도구에 잡힙니다. 그래서 이런 값은 코드 밖에 두고 실행할 때 넣어 주는 시크릿 관리 쪽으로 옮깁니다. 용량이 큰 파일도 이력에 쌓이므로 이미지나 데이터 묶음은 저장소 밖에 두는 편이 낫습니다.

가장 크게 쓰이는 자리는 협업의 단위입니다. 누가 읽을 수 있고 누가 합칠 수 있는지, 합치기 전에 몇 명의 승인이 필요한지가 이 공간 단위로 걸립니다. 규칙을 사람마다 지키기로 하는 대신 설정으로 막아 두면 승인 없이 본류에 들어가는 일이 없습니다.

두 번째는 자동화의 출발점입니다. 코드 변경을 자동으로 검증하고 배포까지 잇는 CI/CD는 이 공간에 새 기록이 들어오는 것을 신호로 삼아 돕니다. 검사와 배포의 대상이 사람이 고른 파일 묶음이 아니라 특정 시점의 저장소 상태입니다. 무엇을 배포했는지 나중에 물었을 때 커밋 하나를 가리켜 답할 수 있습니다.

세 번째는 문서의 자리입니다. 이 코드를 어떻게 돌리는지 적은 안내문과 왜 이렇게 설계했는지 남긴 결정 기록을 코드 옆에 둡니다. 문서 도구에 따로 두면 코드를 고칠 때 문서가 같이 고쳐지지 않지만, 같은 공간에 있으면 한 번의 변경에 둘이 함께 담깁니다.

네 번째는 공개할 때입니다. 저장소를 열어 두는 것만으로는 다른 사람이 그 코드를 어떻게 써도 되는지 정해지지 않습니다. 쓸 때 지켜야 할 조건을 정하는 오픈소스 라이선스를 함께 넣어야 조건이 섭니다. 이 파일이 없는 공개 저장소는 법적으로는 아무 권리도 주지 않은 상태입니다.

다섯 번째는 새로 들어온 사람입니다. 지금 코드만 보면 왜 이렇게 생겼는지 알 수 없는 부분이 많은데, 그 줄이 들어온 커밋의 메시지를 읽으면 대개 이유가 적혀 있습니다.

"그 코드 어느 저장소에 있어요?"

어느 공간에서 이력을 찾아야 하는지 묻는 말입니다.

"저장소를 나눌지 합칠지 정하죠. 지금은 API 고칠 때마다 두 곳을 같이 배포합니다."

경계가 배포 단위와 어긋나 있다는 지적입니다.

"키가 커밋에 들어갔습니다. 이력에서 지워야 하고 키도 새로 발급해야 해요."

지웠다고 끝나지 않는다는 뜻입니다.

페이지덱에서는 서비스별로 저장소를 나눠 두고, 함께 배포되는 웹 화면과 서버는 한 공간에 둡니다. 태오가 새 저장소를 만들 때는 순서가 정해져 있습니다. 안내문을 쓰고, 이력에 담지 않을 것을 적고, 본류에 바로 넣지 못하게 막고 승인 한 명을 요구하도록 설정합니다. 이 넷을 처음에 해 두지 않으면 나중에 되돌리기 어렵습니다.

저장소를 파일 백업 공간으로 여기는 경우가 많습니다. 코드를 올려 두면 잃지 않는다는 점이 먼저 눈에 들어오니 그렇게 읽힙니다. 하지만 파일을 보관하는 일은 클라우드 폴더도 합니다. 이 공간이 하는 일은 모든 변경에 누가 왜라는 설명을 붙여 순서대로 쌓아 두고, 언제든 그중 한 지점으로 되돌아갈 수 있게 만드는 것입니다. 백업으로만 쓰는 팀은 커밋 메시지를 수정이라고만 적게 되고, 그러면 이력이 남아 있어도 읽을 수 없어 되돌릴 지점을 고르지 못합니다.

경계를 나누는 문제에서 한쪽 극단으로 가는 것도 흔합니다. 전부 한 공간에 넣으면 관리가 쉬워 보이고, 잘게 쪼개면 각자 독립돼 보입니다. 기준은 취향이 아니라 배포입니다. 늘 함께 나가는 것을 나눠 두면 한 기능을 위해 두 곳을 같은 순서로 배포해야 하고, 따로 나가는 것을 한곳에 두면 한쪽 변경이 다른 쪽의 검사를 매번 다시 돌게 만듭니다.