[Git/DevOps] 여러 저장소의 소스를 안전하게 배포하는 서버 구축 방법 & 필수 Git 명령어 Cheat Sheet

안녕하세요, 플로거입니다.

MSA(마이크로서비스 아키텍처)나 멀티 레포지토리 환경에서 프로젝트를 운영하다 보면, 하나의 배포 서버가 여러 개의 Git 저장소(Repository)에서 소스를 땡겨와 배포해야 하는 상황을 자주 마주하게 됩니다.

이때 가장 간과하기 쉬운 부분이 바로 '보안(권한 분리)'과 '배포의 안정성'입니다. 만약 관리자 계정의 마스터 권한을 가진 SSH Key 하나를 모든 저장소에 공유해 두었다가 서버가 탈취된다면? 상상만 해도 끔찍한 일입니다.

오늘은 서버에서 여러 저장소의 소스를 안전하게 배포하는 아키텍처 가이드와 함께, 배포 전후로 유용하게 사용할 수 있는 필수 Git 명령어 치트시트를 공유합니다.

Part 1. 여러 저장소를 배포할 때의 안전한 Git 수행 전략 3가지

1️⃣ 저장소별 SSH Deploy Key 활용 (가장 추천)

하나의 SSH Key를 모든 저장소에 등록하는 것은 매우 위험합니다. Git 플랫폼(GitHub, GitLab 등)에서 제공하는 Deploy Key(배포 키)를 사용하면 권한을 엄격하게 분리할 수 있습니다.

• 특징: 특정 저장소에만 접근할 수 있는 SSH 키를 개별적으로 생성합니다.
• 보안 강화: 배포 키를 등록할 때 읽기 전용(Read-Only)으로 설정하여, 배포 서버가 원격 저장소의 소스코드를 변조하거나 무단으로 Push하는 것을 원천 차단합니다.

🛠️ 실무 적용: 서버의 Multi-SSH 설정 방법

여러 개의 Deploy Key를 한 서버에서 사용하려면 ~/.ssh/config 파일을 통해 호스트별로 키를 매핑해주어야 합니다.

Bash

 

# 1. 저장소 A와 B를 위한 SSH 키 개별 생성
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_repo_a
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_repo_b

# 2. ~/.ssh/config 파일 설정
Host repo-a.github.com
    HostName github.com
    IdentityFile ~/.ssh/id_ed25519_repo_a
    User git

Host repo-b.github.com
    HostName github.com
    IdentityFile ~/.ssh/id_ed25519_repo_b
    User git

이렇게 설정해두면 아래와 같이 호스트명을 분리하여 안전하게 Clone 및 Pull을 수행할 수 있습니다.

Bash

 

git clone git@repo-a.github.com:유저명/저장소A.git
git clone git@repo-b.github.com:유저명/저장소B.git

2️⃣ Git Submodule 또는 Subtree 활용

여러 저장소가 '메인 프로젝트'와 '하위 공통 라이브러리' 관계라면, 배포 스크립트에서 사방으로 흩어진 clone 명령을 날리는 것보다 Git 고유 기능을 쓰는 것이 관리상 안전합니다.

• Git Submodule: 메인 저장소가 하위 저장소의 특정 커밋 ID를 가리키도록 고정하므로, 배포 시점에 검증된 버젼의 소스만 동기화됩니다. (git submodule update --init --recursive)
• Git Subtree: 하위 저장소의 소스를 메인 저장소의 하위 디렉토리로 완전히 흡수합니다. 배포 서버 입장에서는 단 하나의 메인 저장소 권한만 관리하면 되므로 단순해집니다.

3️⃣ CI/CD 툴을 통한 Push 방식 전환

보안 관점에서 완벽을 기하려면 배포 서버가 Git 저장소에 직접 접근하는 권한 자체를 없애는 것입니다.

• 서버가 주도하는 'Pull' 방식 대신, GitHub Actions, Jenkins 등의 CI/CD 툴이 소스를 가져와 빌드한 뒤, 결과물만 서버로 밀어 넣는 'Push' 아키텍처로 전환하면 배포 서버 내에 어떠한 Git 인증 정보(SSH Key, PAT 토큰)도 저장할 필요가 없어 가장 안전합니다.

Part 2. 배포 전 상태 검증 및 조작 Git 명령어

여러 저장소를 다룰 때는 엉뚱한 저장소나 브랜치에 소스가 동기화되어 꼬이는 것을 막기 위해 배포 직전 검증 단계를 거쳐야 합니다. 아래 흐름대로 점검하는 것을 추천합니다.

🔍 1. 원격 저장소(Remote) 설정 및 URL 확인

현재 로컬 저장소가 어떤 원격지 주소와 연결되어 있는지 명확하게 확인합니다.

• 연결된 전체 원격 저장소 목록 및 URL 확인

git remote -v

• 특정 원격 저장소(origin)의 URL만 정밀 확인

git config --get remote.origin.url

🔁 2. 특정 원격 저장소의 URL 변경

서버 이전이나 주소 변경, 혹은 위에서 언급한 가상 SSH 호스트명 반영이 필요할 때 사용합니다.

git remote set-url origin <새로운_저장소_URL>

🌿 3. 브랜치(Branch) 확인 및 안전한 전환

원격지 주소가 맞다면, 작업 위치를 파악하고 배포 대상 브랜치로 이동합니다.

• 현재 위치한 브랜치 상태 확인

git branch

• 배포할 메인 브랜치로 전환

git checkout master

📥 4. 원격 최신 소스 동기화 (배포 수행)

검증이 끝났다면 원격 저장소의 최신 소스 코드를 안전하게 가져옵니다.

git pull origin master

💡 실무 운영자를 위한 깨알 팁

1. Personal Access Token(PAT) 자제: 개발자 개인 계정의 토큰을 서버에 심어두면 퇴사나 권한 변경 시 배포가 깨집니다. 무조건 Deploy Key나 시스템 권한을 사용하세요.
2. Shallow Clone 적용: 배포 서버는 과거 히스토리가 필요 없습니다. git clone --depth 1 옵션을 사용하면 네트워크 트래픽을 획기적으로 줄여 배포 속도가 빨라집니다.
3. 자동화 스크립트 짤 때의 팁: git checkout 후 pull을 받기 전, git status를 쉘 스크립트 내에서 체크하여 로컬에 예기치 않은 변경 사항(Conflict 요인)이 없는지 검증하는 로직을 한 줄 넣어두면 배포 사고를 원천 차단할 수 있습니다.

궁금한 점이나 본인만의 안전한 배포 노하우가 있다면 댓글로 공유해 주세요! 도움되셨다면 구독과 공감 부탁드립니다. 🙂