맥 SSH config로 깃허브 계정 여러 개 전환하기 — 회사·개인 키 분리 설정법

회사 레포에 개인 계정 이름으로 커밋이 올라가 있고, 정작 개인 프로젝트를 푸시하려니 Permission denied가 뜬 적 있으신가요. 맥 한 대로 회사·개인 깃허브를 같이 쓰는 분이라면 한 번쯤 겪어봤을 겁니다. 저도 이것 때문에 새벽에 커밋 작성자를 통째로 다시 고쳐본 적이 있어요. 짜증나지만 원인을 알고 나면 10분이면 영구히 끝나는 문제입니다.

범인은 거의 항상 SSH 키 하나입니다. 깃허브는 "네가 누구냐"를 아이디·비밀번호가 아니라 어떤 SSH 키로 접속했는지로 판단합니다. 그런데 키가 하나뿐이면 회사 계정과 개인 계정을 구분할 방법이 없죠. 두 계정에 같은 공개키를 등록하는 것도 깃허브가 막아둔 터라, 결국 한쪽은 포기해야 하는 상황이 됩니다.

해법은 의외로 단순합니다. 계정마다 키를 따로 만들고, ~/.ssh/config에 별칭을 달아 "이 레포는 이 키로 붙어라"라고 못 박아 두면 됩니다. 아래 순서대로 따라 하면 그대로 끝납니다.

1. 계정별로 SSH 키를 따로 만든다

먼저 회사용·개인용 키를 각각 생성합니다. 요즘은 RSA 대신 ed25519가 표준입니다. 짧고 빠르고 안전하거든요. 파일 이름을 -f로 명확히 지정하는 게 핵심이에요. 기본 이름(id_ed25519)으로 두 번 만들면 뒤엣것이 앞엣것을 덮어씁니다.

ssh-keygen -t ed25519 -C "you@company.com" -f ~/.ssh/id_work
ssh-keygen -t ed25519 -C "you@personal.com" -f ~/.ssh/id_personal

-C는 그냥 메모용 주석이라 이메일을 넣어두면 나중에 공개키만 보고도 어느 계정 건지 알아보기 편합니다. passphrase는 묻는 대로 걸어두는 걸 권합니다. 뒤에서 맥 키체인에 저장할 거라 매번 입력할 일은 없어요.

2. ~/.ssh/config에 Host 별칭을 심는다

이 단계가 전부입니다. ~/.ssh/config 파일을 열어(없으면 새로 만들고) 아래처럼 적습니다.

# 공통 설정 (맥 전용)
Host *
  AddKeysToAgent yes
  UseKeychain yes

# 회사 계정
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_work
  IdentitiesOnly yes

# 개인 계정
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_personal
  IdentitiesOnly yes

여기서 github-work, github-personal은 내가 지은 가짜 호스트 이름(별칭)입니다. 실제 접속은 HostName github.com으로 가고, 별칭은 "어느 키를 쓸지" 구분하는 꼬리표일 뿐이에요. IdentitiesOnly yes가 진짜 중요한데, 이게 없으면 ssh가 agent에 올라간 다른 키들을 순서대로 들이밀다가 엉뚱한 계정으로 붙어버립니다. 맥이라면 UseKeychain yes로 passphrase를 키체인에 맡기고, AddKeysToAgent yes로 재부팅 후에도 키가 agent에 자동 등록되게 해둡니다.

3. 깃허브에 공개키를 등록한다

공개키(.pub)를 복사해 각 계정의 깃허브에 올립니다. 맥은 pbcopy로 클립보드에 바로 넣을 수 있어요.

pbcopy < ~/.ssh/id_work.pub

복사한 값을 깃허브 → Settings → SSH and GPG keys → New SSH key에 붙여넣습니다. 회사 계정은 회사 깃허브에, 개인 키는 개인 깃허브에. 당연하지만 이걸 반대로 올리는 실수가 은근히 잦습니다.

4. 리모트 URL을 별칭으로 바꾼다

이제 레포가 github.com이 아니라 방금 만든 별칭을 바라보게 합니다. 새로 클론할 때는 호스트 자리에 별칭을 넣습니다.

git clone git@github-work:my-company/backend.git

이미 클론해 둔 레포라면 리모트 주소만 갈아끼우면 됩니다.

git remote set-url origin git@github-personal:myname/side-project.git
git remote -v

git remote -v로 origin이 git@github-personal:...로 바뀐 걸 확인하세요. 이 한 글자 차이(github.com → github-personal)가 계정을 가르는 스위치입니다.

5. ssh-agent에 키를 올리고 연결을 확인한다

passphrase를 걸었다면 키체인에 저장해 둡니다. --apple-use-keychain 옵션이 맥 전용이에요.

ssh-add --apple-use-keychain ~/.ssh/id_work
ssh-add --apple-use-keychain ~/.ssh/id_personal
ssh-add -l

마지막으로 각 별칭이 제대로 인증되는지 테스트합니다.

ssh -T git@github-work
ssh -T git@github-personal

각각 Hi <회사계정>!, Hi <개인계정>!처럼 서로 다른 사용자 이름이 뜨면 성공입니다. 깃허브는 "shell access는 제공하지 않는다"는 메시지를 덧붙이는데, 이건 정상이니 놀라지 마세요.

자주 걸리는 실수들

세팅은 끝났는데 안 될 때, 열에 아홉은 아래 넷 중 하나입니다.

• IdentitiesOnly 누락: 가장 흔합니다. 이게 빠지면 ssh가 agent의 첫 번째 키로 먼저 붙어, 회사 레포인데 개인 계정으로 인증되는 식의 사고가 납니다. config 블록마다 꼭 넣으세요.
• 파일 권한: ssh는 권한이 느슨한 키 파일을 아예 무시합니다. 디렉터리는 700, 키와 config는 600이어야 해요.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_work ~/.ssh/id_personal ~/.ssh/config

• 커밋 작성자(user.email) 혼동: SSH는 "어디로 푸시할지"만 정합니다. 커밋에 박히는 이름·이메일은 별개로 git config가 정해요. 그래서 계정을 바꿔도 커밋 작성자는 그대로일 수 있습니다. 레포마다 아래를 따로 설정하면 안전합니다.

git config user.name "내 이름"
git config user.email "you@company.com"

• UseKeychain 에러: 오래된 맥이나 passphrase를 안 건 경우 UseKeychain에서 경고가 날 수 있습니다. 그땐 그 줄을 지워도 됩니다. 핵심은 IdentityFile + IdentitiesOnly니까요.

한 가지 더 귀띔하자면, 회사가 깃허브 Organization에 SSO(SAML)를 걸어둔 경우 키를 등록한 뒤 "Configure SSO → Authorize"까지 눌러야 접속이 뚫립니다. 이걸 몰라서 "분명 키는 맞는데 왜 안 되지" 하며 한참 헤매는 분을 여럿 봤어요. 국내 중견·대기업 깃허브 Enterprise 환경에서 특히 자주 걸리는 지점입니다. 레포가 많아 디렉터리별로 신원을 자동 전환하고 싶다면, git config의 includeIf "gitdir:~/work/" 조건부 설정으로 작업 폴더에 따라 user.email까지 자동으로 바꿔주는 방법도 있습니다. 개인적으론 Host 별칭을 github-회사이름처럼 구체적으로 지어두는 걸 추천합니다. 반년 뒤 config를 다시 열었을 때 github-work보다 훨씬 덜 헷갈리거든요.

정리하면, 멀티 계정의 본질은 "계정마다 키를 나누고, config로 레포와 키를 묶고, 리모트 URL을 별칭으로 바꾸는" 세 동작입니다. 한 번만 제대로 해두면 그 뒤로는 git push가 알아서 맞는 계정으로 붙어요. 여러분은 계정을 어떻게 나눠 쓰고 계신가요? includeIf까지 쓰시는 분들의 폴더 구조가 특히 궁금합니다.