폴더별 GitHub 계정 분리: SSH 별칭 + git includeIf 가이드

새로운 회사에 입사하셨거나, 사이드 프로젝트와 본업을 분리하고 싶으셨던 적이 있으실 겁니다. 한 머신에서 두 개 이상의 GitHub 계정을 쓰려고 하면 의외로 함정이 많습니다. 회사 코드를 push했는데 commit 작성자가 개인 계정으로 찍혀 있다거나, 권한이 분명히 있는데 Permission denied (publickey) 에러로 push가 막히는 경우가 그렇습니다.

이 글에서는 특정 폴더 안에서만 특정 GitHub 계정으로 자동 커밋·push 되도록 머신을 셋업하는 방법을 단계별로 다룹니다. SSH 호스트 별칭과 git includeIf를 조합한 표준 패턴이며, 한번 셋업하면 디렉토리만 잘 들어가면 다시는 신경 쓸 필요가 없습니다.

1. 문제 상황

다음과 같은 상황을 가정해 보겠습니다.

평소엔 개인 GitHub 계정 personal-account로 사이드 프로젝트를 관리하고 계십니다.
회사에서 새 GitHub 계정 company-account를 발급받았고, 회사 organization의 private repo를 clone해야 합니다.
모든 회사 작업은 ~/projects/company/ 폴더 아래에서 진행하려고 합니다.

이때 흔히 마주치는 문제는 다음과 같습니다.

# 회사 repo를 clone 시도했는데
$ git clone [email protected]:your-org/internal-api.git
[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

또는 운 좋게 clone은 됐는데 commit author가 잘못 찍히는 경우도 있습니다.

$ git log -1 --format='%an <%ae>'
personal-account <[email protected]>   # ← 회사 commit인데 개인 이름으로 찍힘

이 두 증상은 사실 같은 뿌리에서 나오는 다른 가지입니다.

2. 원인 분석 — Identity와 Auth는 다른 축

Git에서 "이 commit은 누가 만들었는가" 는 두 가지 완전히 다른 메커니즘으로 결정됩니다.

축	결정하는 것	어떻게 결정되는가
Identity	commit author / committer 정보 (이름·이메일)	`git config user.name` / `user.email`
Auth	push·pull 권한	SSH 키 또는 HTTPS 토큰

이 두 축은 서로 모르는 사이입니다. 즉:

SSH 키가 회사 계정에 등록돼 있어도, user.email이 개인 이메일이면 commit은 개인 이름으로 찍힙니다.
반대로 user.email을 회사 이메일로 박아도, SSH 키가 개인 계정 것이면 push가 거부됩니다.

따라서 회사 작업을 깔끔히 분리하려면 두 축을 동시에 분리해야 합니다.

┌─────────────────────────────────────────┐
│ Identity (누가 commit?)                 │
│   → git config user.name/user.email     │
└─────────────────────────────────────────┘
              ⊥ (서로 모름)
┌─────────────────────────────────────────┐
│ Auth (누가 push 권한?)                  │
│   → SSH 키 또는 HTTPS 토큰              │
└─────────────────────────────────────────┘

이 글의 해결책은 두 축을 각각 다른 메커니즘으로 분리합니다.

Identity 분리 → git includeIf로 디렉토리에 따라 다른 user.email 자동 적용
Auth 분리 → SSH 호스트 별칭으로 같은 github.com에 다른 키로 접속

3. 해결 방법 — 4단계 셋업

3-1. 회사 계정용 SSH 키 새로 만들기

기존 개인 키 (~/.ssh/id_ed25519)는 그대로 두고, 회사용 키를 별도 파일로 생성합니다.

ssh-keygen -t ed25519 \
  -C "[email protected]" \
  -f ~/.ssh/id_ed25519_company \
  -N ""

옵션 의미는 다음과 같습니다.

-t ed25519 — RSA보다 짧고 빠른 최신 키 알고리즘. GitHub 공식 권장.
-C "..." — 키에 라벨로 박히는 코멘트. 어떤 계정 키인지 식별용.
-f ~/.ssh/id_ed25519_company — 별도 파일명. 기존 id_ed25519를 덮어쓰지 않습니다.
-N "" — 패스프레이즈 없음. 보안이 걱정되면 패스프레이즈를 넣고 macOS 키체인에 저장하는 방법도 뒤에서 다룹니다.

생성 후 public key는 클립보드로 복사합니다.

pbcopy < ~/.ssh/id_ed25519_company.pub

GitHub company-account 계정에 로그인 후 Settings → SSH and GPG keys → New SSH key 메뉴에서 붙여넣으면 끝입니다. Title은 머신을 식별할 수 있게 MacBook (~/projects/company) 같이 적어 두시면 좋습니다.

3-2. SSH 호스트 별칭 등록

이제 ~/.ssh/config에 별칭을 추가합니다. 별칭이란 같은 서버 (github.com)에 다른 이름 (github-company)으로 접속하면서 다른 키를 쓰게 만드는 트릭입니다.

~/.ssh/config에 다음 블록을 추가합니다.

# 기존 블록 - 개인 계정용 (수정)
Host github.com
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes        # ← 핵심 변경점

# 신규 블록 - 회사 계정용
Host github-company
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519_company
  IdentitiesOnly yes        # ← 핵심 변경점

각 옵션의 역할은 다음과 같습니다.

옵션	역할
`Host github-company`	별칭 이름. clone URL에서 `git@github-company:...` 형태로 사용
`HostName github.com`	실제 접속할 서버
`User git`	GitHub은 항상 `git` 사용자로 접속
`IdentityFile`	이 호스트로 갈 때 사용할 SSH 비밀키
`IdentitiesOnly yes`	명시된 키만 시도. 다른 키를 시도하지 않음
`AddKeysToAgent yes`	첫 사용 시 ssh-agent에 키 자동 추가
`UseKeychain yes`	macOS 키체인에 패스프레이즈 저장 (있을 때)

IdentitiesOnly yes가 가장 중요한 옵션입니다. 이 옵션이 없으면 SSH는 기본적으로 ssh-agent에 로드된 모든 키를 순서대로 시도합니다. 그러면 github-company에 갔을 때 우연히 개인 키가 먼저 인증되어, 회사 권한 인증이 끝나버리는 사고가 생깁니다. GitHub은 인증된 키의 주인 계정으로 모든 권한을 처리하므로, 이건 곧 회사 push가 개인 계정으로 처리되는 사고입니다.

설정이 잘 됐는지 테스트합니다.

ssh -T git@github-company
# → Hi company-account! You've successfully authenticated, but GitHub does not provide shell access.

Hi company-account!가 떠야 정상입니다. exit code가 1로 나오는데 이건 GitHub이 인증 후 셸을 막아서 그런 것이라 정상입니다.

3-3. 디렉토리별 Identity 자동 전환 — `git includeIf`

이제 회사 폴더 안에서만 자동으로 회사 이메일이 적용되게 만듭니다. ~/.gitconfig-company 파일을 새로 만듭니다.

# ~/.gitconfig-company
[user]
	name = company-account
	email = [email protected]

email 형식이 좀 특이합니다. 이건 GitHub의 noreply 이메일인데, 형식은 <숫자ID>+<유저네임>@users.noreply.github.com 입니다. 숫자 ID는 본인 GitHub 계정의 내부 ID이며, Settings → Emails 페이지 하단에 정확한 형식이 표시돼 있습니다.

💡 Tip: noreply 이메일을 쓰면 개인 메일 주소가 commit 로그에 노출되지 않습니다. 또한 GitHub이 "이 commit은 어느 계정의 것인가"를 판별할 때, noreply 이메일에 박힌 숫자 ID로 자동 매칭합니다.

만약 <유저네임>@users.noreply.github.com처럼 숫자 ID 없는 형태로 넣으면 commit이 GitHub 계정에 연결되지 않고 회색 텍스트로만 표시됩니다 (아바타·프로필 링크 없음).

다음으로 ~/.gitconfig에 조건부 포함 블록을 추가합니다.

git config --global \
  includeIf.gitdir:~/projects/company/.path \
  ~/.gitconfig-company

이렇게 하면 ~/.gitconfig 끝부분에 자동으로 다음 블록이 추가됩니다.

[includeIf "gitdir:~/projects/company/"]
	path = ~/.gitconfig-company

이 블록의 의미는 명료합니다.

현재 작업 디렉토리가 ~/projects/company/ 안에 있다면, ~/.gitconfig-company의 모든 설정을 추가로 읽어들여서 적용한다.

~/.gitconfig-company의 [user] 블록은 글로벌 [user] 블록을 덮어쓰기 때문에, 결과적으로 회사 폴더 안에서는 자동으로 company-account identity가 적용됩니다.

⚠️ 주의: gitdir 경로 끝의 슬래시(/)는 필수입니다. 슬래시가 없으면 ~/projects/company-old처럼 비슷한 이름의 다른 디렉토리도 매칭됩니다. 슬래시를 붙이면 정확히 그 폴더의 직계·하위 경로만 매칭됩니다.

3-4. Repo clone — 별칭 URL 사용

마지막으로 회사 repo를 clone할 때는 일반 github.com 대신 별칭 github-company를 사용합니다.

cd ~/projects/company
git clone git@github-company:your-org/your-repo.git

이렇게 clone하면 origin remote URL이 git@github-company:your-org/your-repo.git로 박혀서, 앞으로의 모든 push/pull도 자동으로 회사 SSH 키를 씁니다.

Before / After 비교:

# Before (잘못된 방식 — 개인 키로 시도되어 권한 거부될 수 있음)
git clone [email protected]:your-org/your-repo.git

# After (별칭 사용 — 회사 키만 시도)
git clone git@github-company:your-org/your-repo.git

이미 잘못된 URL로 clone해 버린 repo가 있다면 remote URL만 갈아 끼우면 됩니다.

cd your-repo
git remote set-url origin git@github-company:your-org/your-repo.git

4. 검증 — 진짜로 분리됐는지 확인하기

셋업이 끝났으면 실제로 분리가 되는지 확인합니다.

4-1. Identity 검증

# 회사 폴더 안에서
cd ~/projects/company/your-repo
git config user.name      # → company-account
git config user.email     # → [email protected]

# 회사 폴더 바깥에서 (예: 홈 디렉토리)
cd ~
git config user.name      # → personal-account
git config user.email     # → [email protected]

폴더에 따라 값이 자동으로 바뀌면 성공입니다.

4-2. Push 검증 — Sandbox repo로 실전 테스트

이론만으로는 부족하니 실제로 commit·push까지 한 번 해 봅니다. GitHub에서 회사 계정에 빈 repo your-org/sandbox를 만들어 두고:

cd ~/projects/company
git clone git@github-company:your-org/sandbox.git
cd sandbox

echo "# sandbox" > README.md
git add README.md
git commit -m "chore: initial commit to verify identity setup"

# 작성자가 회사 계정으로 찍혔는지 즉시 확인
git log -1 --format='%an <%ae>'
# → company-account <[email protected]>

git push -u origin main

push가 성공하고, GitHub 웹의 commit 페이지에서 commit author 옆에 회사 계정 아바타와 프로필 링크가 자동으로 붙으면 완벽히 분리된 것입니다.

5. 핵심 개념 정리

개념	한 줄 요약	사용 위치
Identity vs Auth	commit 작성자(`user.email`)와 push 권한(SSH 키)은 별개	항상
SSH host alias	같은 서버에 다른 이름·다른 키로 접속하는 트릭	`~/.ssh/config`
`IdentitiesOnly yes`	명시한 키만 시도, 엉뚱한 키 인증 사고 방지	`~/.ssh/config`
`git includeIf`	디렉토리에 따라 다른 git config 자동 적용	`~/.gitconfig`
noreply email	`<숫자ID>+<유저네임>@users.noreply.github.com` 형식만 계정에 연결됨	`[user] email`
`core.sshCommand`	git이 호출하는 ssh 바이너리 경로 강제 지정	글로벌 또는 로컬 git config

6. 베스트 프랙티스 체크리스트

[ ] 두 호스트 모두 IdentitiesOnly yes — 한쪽만 적용하면 의미 없습니다
[ ] noreply email은 숫자 ID 형식 — 안 그러면 commit이 계정에 연결되지 않습니다
[ ] includeIf 경로 끝에 슬래시 — 슬래시 빠지면 비슷한 이름 폴더도 매칭됩니다
[ ] clone URL에 호스트 별칭 사용 — github.com이 아니라 github-company
[ ] ssh -T git@github-company로 사전 검증 — Hi <username>! 메시지 확인
[ ] 첫 commit 후 git log -1로 author 즉시 확인 — push 전에 잘못 찍혔으면 amend 가능
[ ] 별칭 URL은 본인 머신에서만 동작 — 동료에게 공유할 땐 github.com으로 다시 변환

7. 자주 마주치는 함정 (FAQ)

Q1. ssh: command not found: _kaku_wrapped_ssh 같은 에러가 떠요

zsh 환경에 kaku 같은 SSH 래퍼가 설치돼 있고 비대화형 쉘에서 함수 정의가 로드되지 않으면 발생합니다. git이 호출할 ssh 바이너리 경로를 직접 박아주세요.

git config --global core.sshCommand /usr/bin/ssh

이 설정 한 줄이면 모든 git push/pull/fetch가 시스템 ssh를 직접 호출합니다.

Q2. push했는데 commit author가 여전히 잘못 찍혀요

이미 잘못된 author로 commit이 만들어졌기 때문입니다. 마지막 commit이라면 amend로 고칠 수 있습니다.

# 회사 폴더 안에 있는지 확인
pwd

# config가 정상인지 재확인
git config user.email

# author 다시 박기
git commit --amend --reset-author --no-edit

이미 push해 버렸다면 force-push가 필요한데, 이건 협업 중인 브랜치라면 위험합니다. 본인 feature 브랜치에서만 시도하세요.

Q3. 별칭 URL을 동료에게 그대로 공유해도 되나요?

안 됩니다. github-company는 본인 ~/.ssh/config에만 정의된 이름이라 다른 사람 머신에선 의미가 없습니다. README나 PR 본문에 clone 명령어를 적을 때는 항상 정식 github.com URL을 써야 합니다.

# 외부 공유용 (정식 URL)
git clone [email protected]:your-org/your-repo.git

# 본인 머신용 (별칭)
git clone git@github-company:your-org/your-repo.git

Q4. GitHub CLI (`gh`)는 어떻게 분리하나요?

gh는 SSH가 아니라 HTTPS 토큰 기반이라 별칭 트릭이 안 먹힙니다. 대신 gh auth login을 회사 계정으로 한 번 더 실행해 두 계정을 등록한 뒤, gh auth switch로 토글하면 됩니다.

gh auth login           # 회사 계정 추가
gh auth status          # 두 계정 모두 보이는지 확인
gh auth switch          # 활성 계정 전환

다만 gh는 "현재 활성 계정"으로 모든 명령을 처리하므로 gh pr create 전에 활성 계정이 맞는지 항상 확인하셔야 합니다. 이게 귀찮으면 회사 폴더에서는 gh를 안 쓰고 git CLI만 쓰는 것도 깔끔한 방법입니다.

Q5. `includeIf`가 적용되지 않는 것 같아요

대부분 다음 셋 중 하나입니다.

경로 끝 슬래시 누락 — gitdir:~/projects/company ❌ → gitdir:~/projects/company/ ✅
상대 경로 오해 — gitdir:projects/company/처럼 쓰면 의미가 달라집니다. ~/로 시작하는 절대 경로를 쓰세요
git config --show-origin user.email로 확인 — 이 명령어는 어느 파일에서 값이 왔는지 보여줍니다. 회사 폴더 안에서 실행했을 때 ~/.gitconfig-company에서 왔다고 떠야 정상입니다

Q6. 패스프레이즈를 넣고 싶은데 매번 입력하긴 싫어요

macOS라면 ssh-add --apple-use-keychain으로 키체인에 패스프레이즈를 한 번 저장하면 됩니다.

ssh-add --apple-use-keychain ~/.ssh/id_ed25519_company

~/.ssh/config의 UseKeychain yes 옵션과 함께라면 키체인에서 자동으로 패스프레이즈를 가져와 풀어줍니다. 보안과 편의 둘 다 챙기는 표준 방법입니다.

8. 참고 자료

9. 다음 단계

이 셋업이 완료되면 회사 폴더 안에서는 git/SSH가 알아서 회사 계정으로 처리됩니다. 더 안전하게 운영하려면 다음 단계도 고려해 보세요.

commit signing 설정: GPG 또는 SSH 서명 키를 추가해 commit에 Verified 뱃지를 붙입니다
pre-commit hook으로 identity guard: 회사 폴더 안에서 개인 이메일로 commit하려 하면 자동 차단하는 hook을 설치합니다
gh CLI 멀티 계정 토글 자동화: 폴더 진입 시 gh auth switch까지 자동 실행하는 zsh 함수를 만들어 둡니다