잡지식 정리 정돈
GitHub 속 git 저장소 Clone 방법 정리 _ 전송 경로와 자격증명
본문 사진 4장 · 총 279.36 KB
github에 저장소 하나 만들어놓고 초록색 Code 버튼을 눌렀더니 탭이 셋 나옵니다. 저게 뭐길래 3가지나 있으며, 그 중 무엇을 골라야 하는지 막막할 수도 있습니다. 이번 글에서는 git이 뭔지부터 시작해서, 저 3가지 옵션들 이름의 유래와 주소가 저 모양이 된 이유를 순서대로 뜯어봅니다.
1. 깃허브 저장소 상단의 Code 버튼을 누르면 창이 하나 열리고, 그 안의 Local 탭 아래에 Clone 방식 탭이 세 개 나옴. HTTPS, SSH, GitHub CLI 순임.
2. 각 탭이 내주는 것은 아래 셋임.
HTTPS — https://github.com/tsusaikang/winutil.git
SSH — git@github.com:tsusaikang/winutil.git
GitHub CLI — gh repo clone tsusaikang/winutil
3. 이걸 처음 본 사람이 대개 던지는 질문은 "셋 중에 뭐가 제일 좋냐"임.
4. 그런데 이 셋은 같은 층위(?)에 놓인 세 개의 선택지가 아님. 앞의 둘은 데이터를 실어 나르는 길(load)이고, 셋째는 깃허브가 따로 만든 프로그램인데 앞의 두 길 중 하나를 대신 골라주는 도구 같은 것임. 두 개의 길과 도구 하나, 합쳐서 셋.
5. 그래서 이 글은 "몇 가지냐"를 따지기에 앞서 축을 두 가지로 나눔. 첫째 축은 전송 경로, 곧 "저장소의 데이터가 실제로 어느 길로 오는가"임. 둘째 축은 자격증명, 곧 "그 길에서 내가 누구인지를 어떤 식으로 증명하는가"임.
6. 왜 그런지 보려면 git부터 알아야 함. git은 파일이 바뀌어온 내력을 통째로 기록해두는 프로그램임. 리눅스를 만든 리누스 토르발스가 2005년에 리눅스 커널 개발에 쓰려고 직접 만들었음.
7. 흔히 "버전 관리 도구"라고 부르는데, 한마디로 "언제 누가 무엇을 왜 바꿨는지를 파일 옆에 같이 쌓아두는 것"임. 보고서_최종.docx, 보고서_최종_진짜최종.docx 하는 식으로 이름을 바꿔가며 사본을 늘려놓던 짓을 프로그램이 대신 해준다고 보면 됨. 다른 점은 사본을 늘리지 않고 바뀐 부분만 기록하며, 아무 시점으로나 되돌아갈 수 있다는 것임.
8. 그렇게 쌓인 기록 뭉치를 저장소(repository)라고 부름. 작업 폴더 안에 .git이라는 숨은 폴더가 생기는데, 그 안에 모든게 기록되어 있음.
9. 여기까지는 전부 내 컴퓨터 안에서만 일어나는 일이고 인터넷이 필요 없음. git은 중앙 서버를 전제하지 않는 분산형이라, 참여자 각자가 이력 전체의 사본을 들고 있음.
10. 이름이 비슷해서 git과 깃허브(GitHub)를 하나로 뭉뚱그려 부르는 일이 많은데, 둘은 다른 것임. 깃허브는 그 사본 하나를 남들이 접근할 수 있는 자리(인터넷)에 얹어두고 웹 화면과 부가 기능을 붙여 파는 회사의 서비스임. git은 깃허브 없이도 그대로 돌아감.
11. 그 얹혀 있는 사본을 내 컴퓨터로 가져오는 명령이 git clone임. 최신 파일만 받는 게 아니라 첫 기록부터 지금까지의 이력을 통째로 복제함.
12. 그러려면 두 가지가 필요함. 어느 컴퓨터의 어느 저장소인지(주소), 그리고 그 컴퓨터와 어떤 방식으로 대화할지(전송 경로)임. Clone 탭이 알려주는 문자열은 이 두 가지를 한 줄에 적어놓은 것임.
13. 여기서부터 첫째 축임. git이 원래 지원하는 전송 경로는 네 가지임. 같은 컴퓨터 안의 경로(local), SSH, HTTP(S), 그리고 git://으로 시작하는 전용 프로토콜임.
14. 이 중 git://은 깃허브에서 2022년 3월 15일부로 완전히 차단됐음. 암호화도 인증도 없어서 중간에서 내용을 바꿔치기해도 받는 쪽이 알 방법이 없는 방식이었음. 깃허브처럼 저장소 사본을 얹어두고 남이 받아갈 수 있도록 열어주는 컴퓨터(서버)를 직접 구동할 수도 있는데(이것을 git 서버라 부름), 그런 곳에는 아직 사용중일 수 있지만 깃허브에서는 더 이상 사용 안하는 방식.
※ 출처: GitHub Changelog, "Removed unencrypted Git protocol and certain SSH keys" (2022.03.15)
15. 13번의 넷 중 같은 컴퓨터 안의 경로도 깃허브 화면에는 안 나옴. 같은 디스크나 마운트한 NAS의 폴더를 그대로 clone 하는 길이라 인터넷 연결을 전제로 서비스되는 깃허브가 내줄 것이 없기 때문임. 이 넷 말고 git bundle이라는 것도 있는데, 저장소를 파일 하나로 말아서 USB로 옮긴 뒤 그 파일을 clone 하는 방식임. 인터넷이 끊긴 망에서 쓰는 길이라 역시 화면에는 없음.
16. 그래서 깃허브 화면에 남은 길이 둘임. HTTPS와 SSH. 첫째 축은 사실상 이 둘 중 하나를 고르는 것임.
17. 먼저 HTTPS임. HyperText Transfer Protocol Secure의 약자로, 브라우저가 웹페이지를 받아올 때 쓰는 바로 그 프로토콜임. 뒤의 S는 통신 내용을 암호로 감싼다는 뜻임.
18. 소스코드를 받는데 왜 웹페이지용 프로토콜을 쓰냐는 의문이 들 수 있음. 답은 포트임. 포트는 한 컴퓨터가 바깥과 통신할 때 쓰는 번호 붙은 통로인데, 회사망이나 학교망은 대개 포트를 몇 개만 열어둠. 그런데 웹이 쓰는 443번 포트는 사실상 어디서나 열려 있음. 웹을 막아버리면 업무가 안 되기 때문임. 그러니 웹 포트에 실어 보내면 거의 모든 환경에서 통함.
19. 주소를 쪼개보면 https://(어떻게) + github.com(어느 컴퓨터) + /tsusaikang/winutil.git(그 안의 어디) 세 토막임. 브라우저 주소창에 넣는 주소와 사실상 같은 모양이고, 깃허브가 이 탭에 "Clone using the web URL"이라고 써놓은 게 그 뜻임.
20. 그러면 같은 주소인데 브라우저는 웹페이지를 받고 git은 저장소를 받는 게 이상해 보일 것임. 실제로는 요청이 다름. git은 저 주소 뒤에 /info/refs?service=git-upload-pack 같은 꼬리를 붙여 요청함. 서버는 그 꼬리를 보고 웹페이지가 아니라 저장소 데이터를 내줌. 이 방식을 Smart HTTP라고 부름.
21. 끝의 .git은 서버에 저장소 디렉터리를 만들 때 붙이는 오래된 관례임. 작업 파일 없이 이력 데이터만 담아둔 저장소를 bare repository라고 하는데, 여기에 프로젝트명.git이라는 이름을 붙여왔음. 8번에서 말한 숨은 .git 폴더의 내용물만 따로 떼어놓은 것이 이것임. 깃허브는 .git을 떼고 요청해도 받아주지만, 그 주소가 웹페이지가 아니라 저장소를 가리킨다는 표시라 붙여서 내줌.
22. 다음은 SSH임. Secure SHell의 약자이고, 원래 용도는 파일 전송이 아니라 원격 컴퓨터에 로그인해서 명령을 내리고 원격 컴퓨터를 사용하는 것임. 옛날에 쓰던 telnet이 통신 내용을 그대로 흘려보내서, 그걸 암호로 감싼 대체품으로 나온 것임.
23. 그런데 SSH 탭이 내주는 git@github.com:tsusaikang/winutil.git에는 ://이 없음. 19번의 https:// 주소처럼 "방식://컴퓨터/경로" 꼴로 적는 것을 URL이라 부르는데, 저 줄은 그 꼴이 아니라서 URL이 아님.
24. 이 모양은 scp 문법임. 원격 컴퓨터로 파일을 복사하는 명령이 "scp 파일 사용자@호스트:경로" 형태인데, 저 주소는 그 뒷부분을 그대로 가져온 것임. SSH로 원격 접속하던 사람들이 수십 년간 써온 표기라 git이 따로 만들지 않고 그대로 받아 씀. : 뒤의 tsusaikang/winutil.git이 슬래시로 시작하지 않는 것도 같은 문법을 따른 결과이고, 서버가 자기 저장소 보관 위치를 기준으로 알아서 해석해줌.
25. 앞의 git@은 github.com이라는 컴퓨터에 실제로 존재하는 계정 이름임. 전 세계 사용자가 전부 git이라는 계정 하나로 로그인함. 그러면 누가 접속했는지 어떻게 구분하느냐는 문제가 남는데, 키로 구분함. 이 이야기는 두 번째 축에서 이어감.
26. 로그인은 되지만 SSH의 원래 목적인 '원격 컴퓨터에 명령 내리기'를 위해 필요한 창구(셸)는 안 열림. git 계정은 git 명령만 실행하도록 묶여 있어서, 접속을 시험해보면 이런 답이 옴.
"Hi tsusaikang! You've successfully authenticated, but GitHub does not provide shell access."
27. SSH가 쓰는 22번 포트는 443번만큼 널리 열려 있지 않음. 막힌 망에서는 ssh.github.com의 443번 포트로 우회하는 경로를 깃허브가 따로 제공함.
28. 여기까지가 첫째 축, 길 이야기임. 길을 골랐으면 그 길에서 내가 누구인지를 증명해야 하고, 그것이 둘째 축 자격증명임. 자격증명은 "서버에 내가 누구인지 증명할 때 내미는 것"이고, 어느 길을 골랐느냐에 따라 쓸 수 있는 것이 다름.
29. 먼저, HTTPS의 자격증명부터 보면, 공개 저장소를 받기만 할 때는 아무것도 필요 없음. 브라우저로 웹페이지 보는 것과 같음. 쓰기(push)를 하거나 비공개 저장소를 받을 때 무엇인가를 제출해야 함.
30. 그 무엇인가는 예전에는 계정 비밀번호였는데, 깃허브는 2021년 8월 13일부로 계정 비밀번호를 더 이상 받지 않음. 대신 개인용 액세스 토큰(PAT)을 씀. 토큰은 "계정 비밀번호 대신 발급받는, 용도가 정해진 긴 문자열"임.
※ 출처: GitHub Changelog, "Git password authentication is shutting down" (2021.08.12)
31. 토큰이 비밀번호보다 나은 지점은 세 개임. 권한 범위를 좁게 잘라 발급할 수 있고, 만료일을 걸 수 있고, 하나가 새면 그것만 폐기하면 됨. 계정 비밀번호는 이 셋 중 아무것도 안 됨.
32. 토큰은 두 종류임. 오래된 쪽이 classic PAT인데 범위가 계정 단위임. 저장소 읽기 권한을 주면 내 계정이 닿는 모든 저장소가 읽힘. 나중에 나온 fine-grained PAT는 저장소 단위로 좁힐 수 있음. 2025년 3월 18일에 정식 출시됐음.
※ 출처: GitHub Changelog, "Fine-grained PATs are now generally available" (2025.03.18)
33. 그 밖에, 사람이 아니라 프로그램이 접속할 때 쓰는 GitHub App 설치 토큰은 1시간이면 만료되고, 깃허브가 저장소 안에서 대신 돌려주는 자동 실행 기능(GitHub Actions)이 실행 한 번마다 자동으로 주는 GITHUB_TOKEN은 그 실행이 끝나면 없어짐. 개인이 손으로 clone 하면서 만날 일은 거의 없으니 이런 것도 있다는 정도로 넘어감.
34. HTTPS에는 문제가 하나 더 있음. 문제는 그 토큰을 어디에 두느냐임. 매번 손으로 치는 게 아니라면 어딘가에 저장해야 하는데, 그 자리가 안전을 좌우함.
35. 가장 쉽고 가장 안 좋은 자리는 저장소 주소 안임. clone 한 뒤에는 어디서 받아왔는지가 .git 폴더 안의 config 파일에 적히는데(이 원본 쪽을 git은 리모트라 부름), https://토큰@github.com/tsusaikang/winutil.git 처럼 주소에 박아두면 그 config 파일에 토큰이 평문으로 남음. 작업 폴더를 통째로 복사하거나 백업하면 토큰이 같이 감.
36. 맥에서 흔히 쓰는 자리는 키체인임. git이 처음 토큰을 받을 때 맥 키체인에 넣어두고, 다음부터는 거기서 꺼내 씀. 맥에서 git을 쓰면서 토큰을 한 번 넣은 뒤로 물어보지 않는다면 대개 HTTPS 방식에는 PAT를 사용하고, 그 PAT를 키체인에 둔 경우임. 윈도우는 Git Credential Manager가 같은 역할을 하고, 리눅스는 libsecret 같은 것이 그 자리임.
37. 36번의 키체인, Git Credential Manager, libsecret 같은 보관함이 없는 환경에서는 git이 평문 파일에 적어두거나(store), 메모리에 잠깐만 들고 있다가 버리거나(cache) 함. 1번의 셋째 탭 GitHub CLI가 곧 gh라는 프로그램인데, 거기에 로그인해두고 git이 gh에게 토큰을 물어보게 하는 방법도 있음.
38. 다음으로, SSH의 자격증명임. 25번에서 미뤄둔 키 이야기임. SSH 접속에서는 내가 만든 키 한 쌍 중 공개키를 미리 깃허브 계정에 올려두고, 접속할 때 짝이 맞는 개인키를 가졌는지 증명함. 깃허브는 그때 쓰인 키가 누구 계정에 등록된 키인지를 보고 사람을 알아냄. 계정 이름이 주소에 들어갈 자리가 없는 이유가 이것임.
39. 이 탭에 "Use a password-protected SSH key"라고 적혀 있는 데는 이유가 있음. 개인키 파일은 그 자체가 나를 증명하는 것이라, 파일이 새어나가면 가져간 사람이 곧 나임. 비밀번호와 달리 다시 입력할 일이 없어 새어나간 것을 눈치채기도 어려움. 그래서 키 파일 자체에 암호를 걸어두라는 것임. 새어나간 것을 알았을 때는 깃허브에 등록한 그 공개키를 지우면 됨.
40. 키도 종류가 있음. 38번처럼 내 계정에 등록해서 그 계정이 닿는 모든 저장소에 쓰는 계정 키가 기본이고, 저장소 하나에만 등록하는 배포키(deploy key)가 따로 있음. 배포키는 "건물 마스터키가 아니라 그 집 현관문 하나만 여는 열쇠"임. 사람이 아니라 33번에서 말한 것처럼 프로그램이 스스로 접속할 때, 그 프로그램에게 저장소 하나만 열어줄 때 씀. 그 밖에 개인키가 기기 밖으로 나오지 않는 하드웨어 키, 키 파일을 디스크에 두지 않고 에이전트 프로그램이 대신 들고 있는 방식도 있음.
41. 여기까지 축 둘을 다 세웠으니 GitHub CLI 차례임. 이 탭만 내용물이 주소가 아니라 명령어 한 줄임. ://도 없고, github.com도 없고, .git도 없음. gh는 git이 아니라 깃허브가 따로 만들어 배포하는 별도 프로그램임. 설치하지 않은 컴퓨터에서 저 줄을 붙여넣으면 명령을 못 찾겠다는 답만 옴.
42. github.com이 빠진 이유는 gh가 깃허브 전용 도구라서임. 갈 곳이 하나뿐이면 주소에 적을 이유가 없음. .git이 빠진 이유는 저 뒷부분이 주소가 아니라 소유자/저장소 형태의 식별자이기 때문임. 파일 경로가 아니니 디렉터리 이름 관례를 따를 까닭도 없음.
43. 그리고 gh가 내부에서 실제로 하는 일은, 37번에서 말한 gh 로그인 때 저장해둔 설정을 보고 HTTPS와 SSH 중 하나를 골라 git clone을 대신 실행하는 것임. 첫째 축에서 길을 대신 고르고, HTTPS를 골랐을 때는 둘째 축의 토큰도 37번 방식으로 대신 내주는 것임.
44. 그러니 GitHub CLI는 앞의 둘과 나란한 세 번째 길이 아니라, 두 축 위에 얹혀서 고르는 일을 대신 해주는 층임. 소스트리, GitHub Desktop, VS Code, JetBrains 같은 프로그램도 전부 같은 층에 있음. 화면 뒤에서 하는 일은 두 축의 조합 하나를 골라 git을 실행하는 것임.
45. 3번("셋 중에 뭐가 제일 좋냐?")의 질문이 틀린 질문인 이유가 여기임.
46. 세 탭에 붙은 설명 문구가 서로 결이 다른 것도 이 구조를 그대로 보여줌. 앞의 둘은 "웹 주소로 복제한다", "암호 걸린 키를 써라"처럼 길과 자격증명을 설명하는데, 셋째만 "우리 공식 CLI로 빠르게 작업하세요"라는 도구 소개임.
47. 축을 둘로 나누면 조합은 여럿 나오지만, 러프하게 보면 개인이 마주치는 것은 대개 셋임. 토큰은 34번의 두는 자리까지 같이 적음.
HTTPS + PAT, 보관은 맥 키체인 / 맥에서 토큰을 한 번 넣고 잊고 쓰는 경우. 본인이 뭘 쓰는지 모르는 경우가 제일 많은 조합임
HTTPS + PAT, 보관함 없이 store나 cache / 회사망이나 서버처럼 22번 포트가 막혔거나 키체인 같은 보관함이 없는 곳임
SSH + 계정 키 / 키 한 번 등록해두고 그 뒤로 조용히 쓰는 경우임
48. 지금 내가 어느 조합인지는 저장소 폴더에서 git remote -v를 쳐보면 나옴. 주소가 https://로 시작하면 HTTPS이고 git@로 시작하면 SSH임. HTTPS이면 git config credential.helper를 쳐서 osxkeychain이 나오면 키체인, store가 나오면 평문 파일에 토큰을 두고 있는 것임.
49. 나머지 조합은 특수한 자리에 들어감. 배포키는 프로그램에게 저장소 하나만 열어줄 때, bundle은 인터넷이 끊긴 망에서, App 토큰과 GITHUB_TOKEN은 프로그램이 프로그램에게 접속할 때임. 처음 보는 방식도 "길이 뭐고 자격증명이 뭐냐"로 자리가 정해짐.
한줄 코멘트. git은 파일 이력을 기록하는 프로그램이고 깃허브는 그 기록 사본을 남에게 열어주는 서비스인데, github 속 Clone 탭 세 개는 그 사본을 내 컴퓨터로 복사해올 때 어떤 길로 끌어올지를 고르는 자리임. 그런데 셋이 나란한 세 개의 길이 아니라, 길 둘과 그 둘을 대신 골라주는 도구 하나임. 길을 고르고 나면 그 길에서 나를 증명할 자격증명을 따로 골라야 하고, HTTPS는 토큰을 어디 둘지가, SSH는 키 파일을 어떻게 지킬지가 중요. 세 번째 탭은 어느 길에 어느 자격증명을 내는지 몰라도 되게 덮어주는 도구라 편하기는 하지만, 토큰이 새면 토큰을 폐기하고 키가 새면 공개키를 지워야 하는 것은 그대로임. 지금 어느 길에 무엇을 내고 접속하는지는 알고 써야 함.