[Git] NAS에서 GitHub 조직 저장소로 push하기 — Deploy Key로 저장소별 분리

배경

다른 직원과 협업이 필요해져서 GitHub 조직(Organization) 저장소를 새로 만들었다. 지금 NAS에서 개발 중인 코드를 이 조직 저장소로 push하고 싶었는데, 지금 NAS에는 이미 SSH로 접속해 있는 상태라 "이 SSH 연결 그대로 GitHub 저장소에도 연결해서 push할 수 있나?" 하는 의문이 들었다.

SSH 접속과 GitHub 연결은 별개다

지금 SSH로 NAS에 접속해 있는 것과, 이 저장소를 GitHub 원격 저장소에 연결해서 push하는 것은 완전히 다른 이야기다. 방법은 두 가지가 있다.

방법 1: SSH 프로토콜로 GitHub 연결 (추천)

# NAS에서 SSH 키 생성 (이미 있으면 생략)
ssh-keygen -t ed25519 -C "이메일주소"
cat ~/.ssh/id_ed25519.pub

GitHub → Settings → SSH and GPG keys → New SSH key에 위 공개키를 등록한 뒤:

git remote add origin git@github.com:사용자명/저장소명.git
git push -u origin master

방법 2: HTTPS + Personal Access Token

git remote add origin https://github.com/사용자명/저장소명.git
git push -u origin master

push 시 비밀번호 대신 GitHub Personal Access Token(PAT)을 입력한다(Settings → Developer settings → Personal access tokens에서 발급).

기존 origin을 건드리면 안 되는 이유

지금 저장소의 origin은 이미 사내 NAS의 배포용 bare 저장소(sales-prod.git)를 가리키고 있었다. GitHub 조직 저장소는 여기에 새 리모트로 추가하는 게 안전하다 — origin을 덮어쓰면 기존 배포 파이프라인에 영향을 줄 수 있다.

git remote -v

origin  <nas-prod-repo-path>  (fetch)
origin  <nas-prod-repo-path>  (push)
prod    <nas-prod-live-dir>   (fetch)
prod    <nas-prod-live-dir>   (push)

GitHub SSH 연결 확인

NAS 계정에 GitHub으로 나가는 SSH 키가 있는지 먼저 확인해야 했다.

ls -la ~/.ssh/
ssh -T git@github.com -o BatchMode=yes -o ConnectTimeout=5

확인해보니 이 계정엔 authorized_keys(들어오는 연결용)만 있고, GitHub으로 나가는 키는 없었다. GitHub host key도 아직 신뢰 목록에 없어서 Host key verification failed가 떴다. 키를 새로 만들고 등록해야 하는 상황.

개인 계정 키 vs Deploy Key — 어느 쪽이 맞나

인증 방식을 고민하다가, 지금 SSH 연결을 폴더(프로젝트)별로 따로따로 하고 있다는 걸 감안해서 Deploy Key 방식을 선택했다.

왜 Deploy Key가 지금 구조에 맞는가:

• Deploy Key는 "저장소 1개당 키 1개"가 원칙이다
• 나중에 다른 프로젝트 저장소를 추가로 연결하더라도, 그 폴더에서 새 키 쌍을 만들어 그 저장소에만 등록하면 되고, 기존 폴더의 키와는 완전히 분리된다
• 개인 계정 키처럼 "이 키 하나로 조직 전체 접근 가능"한 구조가 아니라서, 폴더별 독립 관리라는 지금 습관과 자연스럽게 이어진다

저장소별로 다른 키를 쓰려면 SSH config에 Host 별칭 등록

GitHub SSH는 기본적으로 git@github.com으로 접속하면 어떤 키를 쓸지 자동으로 구분하지 못한다. 저장소마다 다른 키를 쓰려면 ~/.ssh/config에 저장소별 Host 별칭을 등록해야 한다.

Host github-<project>-dev
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_<project>_dev
    IdentitiesOnly yes

이렇게 등록하면 remote 주소는 git@github-<project>-dev:<조직명>/<저장소명>.git 형태로 쓴다. 나중에 다른 저장소를 추가할 때도 Host 별칭만 새로 하나 추가하면 된다.

진행 순서

1. 해당 프로젝트 전용 키 쌍 생성
2. 공개키를 GitHub 조직 저장소 → Settings → Deploy keys에 등록 (Write access 체크)
3. SSH config에 Host 별칭 추가, known_hosts에 github.com 등록
4. GitHub용 리모트 추가 후 push

단계별 상세 명령어

1단계: 이 프로젝트 전용 SSH 키 생성

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_<project>_dev -C "<project>-dev-deploy-key"

패스프레이즈는 비워도 된다 (자동 push 스크립트 등에 쓸 게 아니면 넣어도 무방). 완료되면 개인키(id_ed25519_<project>_dev)와 공개키(id_ed25519_<project>_dev.pub) 두 파일이 생성된다.

2단계: 공개키를 GitHub Deploy Key로 등록

cat ~/.ssh/id_ed25519_<project>_dev.pub

출력된 내용을 전체 복사한 뒤:

1. GitHub에서 해당 조직 저장소로 이동
2. Settings → Deploy keys → Add deploy key
3. Title: 예) NAS-<project>-dev
4. Key: 복사한 공개키 붙여넣기
5. "Allow write access" 체크 (push하려면 필수, 기본은 읽기 전용)
6. Add key

3단계: SSH config에 Host 별칭 등록

~/.ssh/config 파일 끝에 다음 내용을 추가한다(파일이 없으면 새로 생성됨).

Host github-<project>-dev
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_<project>_dev
    IdentitiesOnly yes

터미널에 nano가 없을 수도 있는데, 그럴 때는:

• vi 사용: vi ~/.ssh/config → i로 입력 모드 진입 → 내용 붙여넣기 → Esc → :wq 입력 후 저장/종료
• 에디터 없이 명령어로 바로 추가 (더 간단):

  cat >> ~/.ssh/config << 'EOF'Host github-<project>-dev    HostName github.com    User git    IdentityFile ~/.ssh/id_ed25519_<project>_dev    IdentitiesOnly yesEOF
  

내용이 잘 들어갔는지 cat ~/.ssh/config로 확인한 뒤, 권한을 맞춰준다.

chmod 600 ~/.ssh/config

참고: ~/.ssh/config는 VS Code 설정이 아니라 SSH 클라이언트 자체의 설정 파일이다. VS Code의 Remote-SSH 확장도 접속 대상 설정에 이 파일을 참조하기 때문에 혼동되기 쉬운데, 여기서 다루는 건 터미널에서 ssh/git이 GitHub에 접속할 때 어떤 키를 쓸지 정하는 설정으로 완전히 별개 용도다. 같은 파일을 공유할 뿐이다.

4단계: GitHub host key 신뢰 등록

별칭으로 접속하면서 처음 한 번 승인해야 한다.

ssh -T github-<project>-dev

The authenticity of host 'github.com ...' can't be established. Are you sure you want to continue connecting (yes/no)?

yes 입력. 정상이면 Hi <조직명>/<저장소명>! You've successfully authenticated, but GitHub does not provide shell access. 메시지가 뜬다. 이게 나오면 성공.

5단계: 이 저장소에 새 리모트 추가

git remote add github git@github-<project>-dev:<조직명>/<저장소명>.git
git remote -v

기존 origin(배포용), prod, 그리고 새로 추가된 github이 함께 보이면 정상이다.

6단계: Push

지금 작업 중인 변경사항이 커밋되지 않은 상태라면, 그건 이번 push에 포함되지 않는다 — 커밋된 이력까지만 올라간다.

git push -u github master

-u로 한 번 연결해두면 다음부터는 git push github master 또는 (필요시) git push만으로도 가능하다.

함정 — -u 옵션이 기본 push 대상을 바꿔버린다

6단계까지 진행하고 나서 문득 이런 의문이 들었다: "지금 터미널에서 git push하면 원래 push하던 NAS git 서버가 아니라 GitHub로 올라가는 거 아닌가?"

맞는 지적이었다. git push -u github master에서 -u 옵션이 로컬 master 브랜치의 upstream(추적 브랜치)을 github/master로 바꿔버린다. 즉 이전에는 인자 없이 git push만 치면 origin(NAS git 서버)으로 갔지만, -u를 쓴 이후로는 인자 없는 git push가 이제 GitHub로 올라가게 된다.

확인해보면:

git branch -vv

* master a6ffe87 [github/master] ...

[github/master]로 표시된 걸 보면, master 브랜치가 GitHub을 추적하도록 바뀐 상태였다. 이대로 두면 앞으로 git push만 입력했을 때 NAS(origin)가 아니라 GitHub로 올라간다 — 기존 배포 워크플로우를 그대로 유지하려면 위험한 상태다.

해결: 기존 배포 워크플로우(NAS origin으로 push)를 계속 기본으로 쓰고 싶다면, 추적 브랜치를 다시 origin으로 되돌리면 된다.

git branch --set-upstream-to=origin/master master
git branch -vv

branch 'master' set up to track 'origin/master'.
* master a6ffe87 [origin/master] ...

이제:

• git push (인자 없음) → **NAS origin**으로 감 (기존 방식 그대로)
• git push github master → GitHub으로 감 (명시적으로 지정할 때만)

앞으로 GitHub에 올릴 때는 항상 git push github master처럼 리모트 이름을 명시해서 쓰면 헷갈릴 일이 없다.

정리

• SSH로 서버에 접속해 있는 것과 그 저장소를 GitHub에 연결하는 것은 별개의 문제다
• 기존 배포용 리모트(origin)는 건드리지 않고 새 리모트를 추가하는 게 안전하다
• 여러 프로젝트를 폴더별로 독립 관리하는 습관이 있다면, 개인 계정 키보다 저장소별로 분리되는 Deploy Key가 구조적으로 더 잘 맞는다
• 저장소마다 다른 키를 쓰려면 ~/.ssh/config에 Host 별칭을 등록해서 구분해야 한다
• git push -u <리모트>는 편의를 위해 upstream(기본 push 대상)까지 바꿔버린다는 걸 잊기 쉽다 — 기존 배포 워크플로우가 있는 저장소에서는 처음 연결할 때 이 부분을 특히 조심해야 한다