AWS CodeCommit 소스 관리 완벽 가이드

AWS CodeCommit을 활용한 안전하고 효율적인 소스 코드 관리 방법을 배웁니다. Git 기본부터 브랜치 전략, 코드 리뷰까지 실무에 바로 적용할 수 있는 내용을 담았습니다.

---

목차

1. CodeCommit이란?
2. 레포지토리 생성
3. Git 자격 증명 설정
4. 코드 푸시하기
5. 브랜치 관리
6. PR과 코드 리뷰

---

1. CodeCommit이란?

김개발 씨는 신입 개발자로 입사한 첫 날, 팀장님으로부터 CodeCommit 저장소 주소를 받았습니다. GitHub는 들어봤지만 CodeCommit은 처음 듣는 이름입니다.

"이게 뭐지?" 궁금해진 김개발 씨는 박시니어 선배를 찾아갔습니다.

CodeCommit은 AWS에서 제공하는 완전 관리형 Git 저장소 서비스입니다. 마치 GitHub나 GitLab처럼 코드를 저장하고 관리할 수 있지만, AWS 인프라 안에서 동작합니다.

기업용 프로젝트에서 보안과 확장성이 중요할 때 자주 선택하는 서비스입니다.

다음 코드를 살펴봅시다.

# AWS CLI로 CodeCommit 저장소 목록 확인하기
import boto3

# CodeCommit 클라이언트 생성
client = boto3.client('codecommit', region_name='ap-northeast-2')

# 저장소 목록 가져오기
response = client.list_repositories()

# 저장소 정보 출력
for repo in response['repositories']:
    print(f"저장소 이름: {repo['repositoryName']}")
    print(f"저장소 ID: {repo['repositoryId']}")
    print("---")

박시니어 선배는 커피를 한 모금 마시고 설명을 시작했습니다. "CodeCommit은 쉽게 말하면 AWS가 운영하는 GitHub 같은 거예요.

우리 회사 코드를 AWS 안에 안전하게 보관하는 거죠." 김개발 씨는 고개를 끄덕이며 물었습니다. "그럼 GitHub랑 뭐가 다른가요?" 좋은 질문입니다.

이 차이를 이해하는 것이 CodeCommit을 선택하는 이유를 아는 첫걸음입니다. CodeCommit은 AWS의 다른 서비스들과 완벽하게 통합됩니다.

마치 같은 회사 제품들끼리는 서로 잘 맞는 것처럼, CodeCommit은 AWS의 IAM, CodeBuild, CodePipeline과 자연스럽게 연결됩니다. "우리 회사는 왜 CodeCommit을 쓰나요?" 김개발 씨가 다시 물었습니다.

박시니어 선배는 세 가지 이유를 손가락으로 꼽았습니다. "첫째, 보안이에요.

우리 회사 코드가 외부로 나가면 안 되거든요. CodeCommit은 AWS VPC 안에서만 접근하도록 설정할 수 있어요." "둘째는 비용입니다.

GitHub Enterprise는 사용자당 돈을 내야 하는데, CodeCommit은 사용량 기반이에요. 우리 팀은 5명뿐이라 더 저렴하죠." "셋째, CI/CD 파이프라인이 이미 AWS에 있어요.

CodeBuild, CodeDeploy를 쓰고 있으니까 CodeCommit을 쓰면 설정이 훨씬 간단합니다." 김개발 씨는 점점 이해가 되기 시작했습니다. 그런데 한 가지 더 궁금한 게 생겼습니다.

"그럼 Git 명령어는 똑같이 쓸 수 있나요?" "네, 그게 CodeCommit의 가장 큰 장점이에요." 박시니어 선배가 대답했습니다. "CodeCommit은 표준 Git 프로토콜을 사용해요.

git clone, git push, git pull 같은 명령어를 그대로 쓸 수 있습니다." 위의 코드는 Python의 boto3 라이브러리를 사용해서 CodeCommit 저장소 목록을 가져오는 예제입니다. AWS SDK를 통해 저장소를 프로그래밍 방식으로 관리할 수 있다는 것을 보여줍니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 금융회사에서 고객 데이터를 다루는 시스템을 개발한다고 생각해봅시다.

코드가 외부로 유출되면 큰 문제가 됩니다. 이럴 때 CodeCommit을 private VPC 안에 두고, 회사 네트워크에서만 접근하도록 설정합니다.

보안팀도 만족하고 개발팀도 편하게 작업할 수 있습니다. 또 다른 사례는 스타트업입니다.

처음에는 팀이 작아서 CodeCommit의 무료 티어만으로도 충분합니다. 나중에 팀이 커지면 자연스럽게 확장되고, 별도의 서버 관리 없이 AWS가 알아서 처리해줍니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 CodeCommit을 GitHub처럼 웹 UI로만 사용하려는 것입니다.

CodeCommit의 웹 콘솔은 GitHub보다 기능이 제한적입니다. 따라서 대부분의 작업은 Git CLI나 IDE 통합을 통해 하는 것이 좋습니다.

김개발 씨는 이제 CodeCommit이 무엇인지 이해했습니다. "그럼 저도 이제 저장소를 만들어볼 수 있을까요?" 박시니어 선배가 웃으며 답했습니다.

"물론이죠. 다음 단계로 넘어가봅시다." CodeCommit을 선택하는 이유는 간단합니다.

AWS 환경에서 일한다면 가장 자연스러운 선택이고, 보안과 통합성 면에서 큰 이점을 제공합니다.

실전 팁

💡 - CodeCommit은 리전별로 저장소가 생성되므로, 프로젝트 위치를 고려해 적절한 리전을 선택하세요

• GitHub에서 마이그레이션할 때는 git mirror 옵션을 사용하면 모든 히스토리를 그대로 가져올 수 있습니다

---

2. 레포지토리 생성

이해는 했지만 직접 해보는 것이 중요하다고 생각한 김개발 씨는 자신만의 테스트 저장소를 만들어보기로 했습니다. AWS 콘솔에 접속했지만 메뉴가 너무 많아 어디서부터 시작해야 할지 막막합니다.

레포지토리 생성은 CodeCommit에서 코드를 저장할 공간을 만드는 첫 단계입니다. 마치 새 프로젝트를 시작할 때 폴더를 만드는 것처럼, CodeCommit에서도 저장소를 먼저 만들어야 합니다.

AWS 콘솔이나 CLI를 통해 간단하게 생성할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS CLI로 CodeCommit 저장소 생성하기
import boto3

# CodeCommit 클라이언트 생성
client = boto3.client('codecommit', region_name='ap-northeast-2')

# 저장소 생성
response = client.create_repository(
    repositoryName='my-first-project',
    repositoryDescription='나의 첫 CodeCommit 프로젝트',
    tags={
        'Team': 'Backend',
        'Environment': 'Development'
    }
)

# 생성된 저장소 정보 출력
print(f"저장소 이름: {response['repositoryMetadata']['repositoryName']}")
print(f"Clone URL (HTTPS): {response['repositoryMetadata']['cloneUrlHttp']}")
print(f"Clone URL (SSH): {response['repositoryMetadata']['cloneUrlSsh']}")

박시니어 선배가 김개발 씨의 화면을 함께 보며 설명했습니다. "저장소를 만드는 방법은 크게 두 가지예요.

콘솔에서 클릭으로 만들거나, CLI로 명령어를 입력하거나." 김개발 씨는 일단 눈으로 보는 게 편할 것 같아서 콘솔 방식을 선택했습니다. AWS Management Console에서 CodeCommit 서비스를 찾아 들어갔습니다.

"먼저 리전을 확인하세요." 박시니어 선배가 화면 오른쪽 위를 가리켰습니다. "서울 리전(ap-northeast-2)으로 되어 있나요?

저장소는 리전별로 생성되니까 팀이 사용하는 리전에 만들어야 해요." 리전을 확인한 김개발 씨는 "Create repository" 버튼을 클릭했습니다. 화면에 몇 가지 입력 필드가 나타났습니다.

Repository name은 가장 중요한 필드입니다. 마치 변수명을 짓는 것처럼, 명확하고 의미 있는 이름을 선택해야 합니다.

"my-app", "backend-api" 같은 식으로요. 김개발 씨는 "customer-management-api"라고 입력했습니다.

"좋은 이름이네요." 박시니어 선배가 칭찬했습니다. "나중에 저장소가 많아지면 이름만 보고도 뭘 하는 프로젝트인지 알 수 있어야 하거든요." 다음은 Description 필드입니다.

선택사항이지만 적어두는 게 좋습니다. "고객 정보 관리 REST API"라고 간단히 설명을 추가했습니다.

Tags는 어떻게 활용할까요? 실제 회사에서는 수십 개의 저장소가 있을 수 있습니다.

이때 태그를 사용하면 저장소를 쉽게 분류하고 찾을 수 있습니다. 예를 들어 "Team: Backend", "Environment: Production" 같은 태그를 달아두면 나중에 관리하기 편합니다.

김개발 씨가 "Create" 버튼을 클릭하자 몇 초 만에 저장소가 생성되었습니다. 화면에 Clone URL이 두 개 나타났습니다.

하나는 HTTPS, 하나는 SSH입니다. "이 URL들이 뭐예요?" 김개발 씨가 물었습니다.

박시니어 선배가 설명했습니다. "이게 Git으로 저장소를 복제할 때 쓰는 주소예요.

HTTPS는 사용자 이름과 비밀번호로 인증하고, SSH는 키 페어로 인증합니다." 위의 Python 코드를 보면 프로그래밍 방식으로도 저장소를 만들 수 있습니다. 특히 여러 프로젝트를 동시에 시작하거나, 자동화 스크립트를 만들 때 유용합니다.

코드의 세 번째 줄에서 리전을 지정하는 것을 볼 수 있습니다. 이 부분이 중요합니다.

잘못된 리전에 저장소를 만들면 나중에 옮기기 번거롭습니다. 일곱 번째 줄의 repositoryName은 고유해야 합니다.

같은 리전에 같은 이름의 저장소가 이미 있으면 에러가 발생합니다. 따라서 팀 내에서 네이밍 규칙을 정해두는 것이 좋습니다.

열한 번째 줄의 tags는 딕셔너리 형태로 전달합니다. 키-값 쌍으로 원하는 만큼 태그를 추가할 수 있습니다.

회사의 리소스 태깅 정책이 있다면 그것을 따라야 합니다. 실무에서는 어떻게 활용할까요?

대형 프로젝트에서는 마이크로서비스 아키텍처를 많이 사용합니다. 각 서비스마다 별도의 저장소를 만들어야 하는데, 일일이 콘솔에서 클릭하기는 번거롭습니다.

이럴 때 스크립트로 한 번에 여러 저장소를 생성합니다. 예를 들어 "user-service", "order-service", "payment-service" 세 개의 저장소를 만든다면, 반복문을 돌려서 한 번에 만들 수 있습니다.

하지만 주의할 점이 있습니다. 저장소 이름에는 특수문자를 사용할 수 없습니다.

영문자, 숫자, 하이픈(-), 언더스코어(_)만 가능합니다. "my-project-2024"는 되지만 "my_project@2024"는 안 됩니다.

또한 저장소 이름은 나중에 변경할 수 없습니다. 처음부터 신중하게 이름을 정해야 합니다.

만약 이름을 바꾸고 싶다면 새 저장소를 만들고 코드를 옮겨야 합니다. 김개발 씨는 이제 자신만의 저장소를 갖게 되었습니다.

"다음은 뭐 해야 하나요?" "이제 코드를 올려야죠." 박시니어 선배가 답했습니다. "하지만 그 전에 Git 자격 증명부터 설정해야 해요."

실전 팁

💡 - 저장소 이름은 프로젝트 구조를 반영하도록 짓세요 (예: backend-api, frontend-web, mobile-app)

• 개발 환경별로 저장소를 분리할지, 브랜치로 관리할지 미리 정책을 정하세요

---

3. Git 자격 증명 설정

김개발 씨는 로컬에서 git clone 명령어를 입력했지만 "Authentication failed"라는 에러만 계속 나타났습니다. GitHub에서는 그냥 로그인하면 됐는데 CodeCommit은 뭔가 다른 것 같습니다.

다시 박시니어 선배에게 도움을 청했습니다.

Git 자격 증명은 CodeCommit 저장소에 접근하기 위한 인증 정보입니다. 마치 집에 들어갈 때 열쇠가 필요한 것처럼, CodeCommit에 코드를 올리거나 내려받으려면 인증이 필요합니다.

AWS는 보안을 위해 여러 가지 인증 방식을 제공합니다.

다음 코드를 살펴봅시다.

# Git Credential Helper를 사용한 자격 증명 설정
# ~/.gitconfig 파일에 추가할 내용

[credential]
    helper = !aws codecommit credential-helper $@
    UseHttpPath = true

# 또는 특정 저장소에만 적용하려면
# 프로젝트 디렉토리의 .git/config에 추가

[credential "https://git-codecommit.ap-northeast-2.amazonaws.com"]
    helper = !aws codecommit credential-helper $@
    UseHttpPath = true

# AWS CLI 프로필을 사용하는 경우
[credential]
    helper = !aws --profile myprofile codecommit credential-helper $@
    UseHttpPath = true

박시니어 선배가 김개발 씨의 에러 메시지를 보고 고개를 끄덕였습니다. "예상했어요.

CodeCommit은 AWS 서비스니까 일반적인 Git 인증과는 다르게 동작해요." "그럼 어떻게 해야 하나요?" 김개발 씨가 물었습니다. "방법이 세 가지 있어요." 박시니어 선배가 설명하기 시작했습니다.

"첫 번째는 HTTPS Git 자격 증명, 두 번째는 SSH 키, 세 번째는 AWS CLI Credential Helper예요." 첫 번째 방법은 가장 간단합니다. IAM 콘솔에서 사용자를 선택하고, "Security credentials" 탭으로 들어갑니다.

거기서 "HTTPS Git credentials for AWS CodeCommit" 섹션을 찾아 "Generate credentials" 버튼을 클릭하면 됩니다. 그러면 사용자 이름과 비밀번호가 생성됩니다.

이것을 저장해두고, git clone할 때 입력하면 됩니다. 마치 웹사이트에 로그인하는 것과 비슷합니다.

김개발 씨가 따라 해보니 정말 간단했습니다. "이거면 되는 거 아닌가요?" "맞아요.

하지만 매번 비밀번호를 입력하기 귀찮을 수 있어요." 박시니어 선배가 말했습니다. "그래서 두 번째 방법을 많이 써요." 두 번째 방법은 SSH 키를 사용하는 것입니다.

먼저 로컬에서 SSH 키 페어를 생성합니다. 터미널에서 "ssh-keygen -t rsa -b 4096"를 실행하면 공개키와 개인키가 만들어집니다.

공개키를 IAM 콘솔의 "SSH keys for AWS CodeCommit" 섹션에 등록합니다. 그러면 개인키로 자동으로 인증이 됩니다.

비밀번호를 입력할 필요가 없어서 편리합니다. 하지만 박시니어 선배는 세 번째 방법을 추천했습니다.

"우리 회사는 AWS CLI를 이미 쓰고 있잖아요? 그럼 Credential Helper가 가장 좋아요." 세 번째 방법인 AWS CLI Credential Helper는 AWS CLI의 인증 정보를 그대로 사용합니다.

위의 설정 코드를 보면 알 수 있듯이, Git 설정 파일에 몇 줄만 추가하면 됩니다. 이렇게 하면 AWS CLI로 인증된 상태라면 Git도 자동으로 인증됩니다.

별도의 비밀번호나 SSH 키를 관리할 필요가 없습니다. 김개발 씨는 홈 디렉토리의 .gitconfig 파일을 열어서 설정을 추가했습니다.

그리고 다시 git clone을 시도했습니다. "성공했어요!" 김개발 씨가 소리쳤습니다.

드디어 저장소가 로컬에 복제되었습니다. 실무에서는 어떤 방식을 선택할까요?

개인 개발자나 소규모 팀은 HTTPS Git 자격 증명을 많이 사용합니다. 설정이 간단하고 직관적이기 때문입니다.

비밀번호 관리자에 저장해두면 보안도 괜찮습니다. SSH 키는 보안에 민감한 환경에서 선호됩니다.

금융권이나 대기업에서는 SSH 키를 표준으로 정하는 경우가 많습니다. 키 교체 주기를 정책으로 관리할 수 있기 때문입니다.

AWS CLI Credential Helper는 AWS를 많이 사용하는 팀에게 최적입니다. 이미 IAM 역할이나 프로필로 권한을 관리하고 있다면, Git도 같은 방식으로 관리하는 것이 일관성이 있습니다.

주의할 점도 있습니다. HTTPS Git 자격 증명은 IAM 사용자당 최대 2개까지만 만들 수 있습니다.

여러 컴퓨터에서 작업한다면 같은 자격 증명을 공유하거나, 다른 방식을 사용해야 합니다. SSH 키는 분실하면 위험합니다.

개인키가 유출되면 누구든 그 키로 저장소에 접근할 수 있습니다. 따라서 키 파일의 권한을 600으로 설정하고, 암호를 걸어두는 것이 좋습니다.

AWS CLI Credential Helper는 AWS CLI가 설치되어 있고 설정되어 있어야 합니다. 새 팀원이 합류했을 때 이 부분을 놓치면 인증 오류가 발생할 수 있습니다.

김개발 씨는 이제 자유롭게 코드를 올리고 내려받을 수 있게 되었습니다. "드디어 진짜 개발을 시작할 수 있겠네요!" 박시니어 선배가 웃으며 답했습니다.

"맞아요. 이제 코드를 푸시해봅시다."

실전 팁

💡 - AWS CLI Credential Helper를 사용하면 MFA 인증도 자동으로 처리됩니다

• 팀 전체가 같은 인증 방식을 사용하도록 가이드 문서를 만들어두세요

---

4. 코드 푸시하기

드디어 김개발 씨는 자신이 작성한 코드를 CodeCommit에 올릴 준비가 되었습니다. 간단한 Python Flask 앱을 만들었고, 이제 팀원들과 공유하고 싶습니다.

git add, git commit까지는 했는데 git push를 하려니 긴장이 됩니다.

코드 푸시는 로컬에서 작성한 코드를 원격 저장소로 업로드하는 과정입니다. 마치 작성한 문서를 클라우드에 저장하는 것처럼, 코드를 CodeCommit에 올려서 팀원들이 볼 수 있게 만듭니다.

Git의 기본 명령어를 그대로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

# 로컬 저장소 초기화 및 코드 푸시하기

# Git 저장소 초기화
git init

# CodeCommit 원격 저장소 추가
git remote add origin https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/customer-management-api

# 파일 추가
git add .

# 커밋 생성
git commit -m "Initial commit: Flask API 기본 구조 추가"

# 원격 저장소에 푸시 (첫 번째 푸시는 -u 옵션 필요)
git push -u origin main

# 이후 푸시는 간단하게
git push

김개발 씨는 터미널에서 git push 명령어를 입력하기 직전에 박시니어 선배를 불렀습니다. "혹시 제가 뭔가 놓친 거 없을까요?" 박시니어 선배가 웃으며 답했습니다.

"걱정 마세요. CodeCommit도 일반 Git 저장소랑 똑같아요.

git push만 하면 됩니다." 김개발 씨는 용기를 내어 엔터 키를 눌렀습니다. 터미널에 여러 줄의 메시지가 출력되기 시작했습니다.

"Counting objects", "Compressing objects", "Writing objects"라는 메시지가 지나갔습니다. 그리고 마지막에 "Branch 'main' set up to track remote branch 'main' from 'origin'"이라는 메시지가 나타났습니다.

성공입니다. 첫 번째 푸시는 조금 특별합니다.

위의 코드에서 볼 수 있듯이 "-u origin main"이라는 옵션을 붙여야 합니다. 이것은 로컬 브랜치와 원격 브랜치를 연결하는 작업입니다.

마치 휴대폰과 블루투스 기기를 처음 연결할 때 페어링하는 것과 비슷합니다. 한 번 연결해두면 다음부터는 자동으로 연결됩니다.

"-u"는 "--set-upstream"의 줄임말입니다. 이것을 실행하면 Git이 "아, main 브랜치는 origin의 main 브랜치로 푸시하면 되는구나"라고 기억합니다.

두 번째 푸시부터는 "git push"만 입력하면 됩니다. 브랜치 이름을 적을 필요도 없습니다.

Git이 알아서 연결된 원격 브랜치로 푸시합니다. 김개발 씨가 AWS 콘솔에서 CodeCommit 저장소를 새로고침했습니다.

"파일이 올라왔어요!" "맞아요. 이제 팀원 누구나 이 코드를 받아볼 수 있어요." 박시니어 선배가 설명했습니다.

실무에서는 푸시하기 전에 몇 가지를 확인해야 합니다. 먼저 .gitignore 파일을 제대로 설정했는지 확인합니다.

node_modules나 .env 같은 파일은 저장소에 올리면 안 됩니다. 특히 .env 파일에는 데이터베이스 비밀번호나 API 키가 들어있을 수 있습니다.

김개발 씨도 처음에는 .env 파일을 커밋하려다가 박시니어 선배가 막았습니다. "이거 올리면 큰일 나요.

비밀번호가 다 공개되는 거예요." 다행히 아직 푸시 전이었습니다. "git reset HEAD .env"로 스테이징에서 제거하고, .gitignore에 .env를 추가했습니다.

커밋 메시지도 중요합니다. "fix", "update" 같은 모호한 메시지는 나중에 보면 무슨 변경인지 알 수 없습니다.

"Initial commit: Flask API 기본 구조 추가"처럼 구체적으로 작성해야 합니다. 많은 회사에서 커밋 메시지 컨벤션을 정해놓습니다.

예를 들어 "feat: 로그인 기능 추가", "fix: 비밀번호 검증 버그 수정" 같은 형식입니다. 푸시할 때 충돌이 발생할 수도 있습니다.

다른 팀원이 같은 브랜치에 먼저 푸시했다면, "Updates were rejected because the remote contains work that you do not have locally"라는 에러가 나타납니다. 이럴 때는 먼저 "git pull"로 원격 변경사항을 받아온 다음, 충돌을 해결하고 다시 푸시해야 합니다.

김개발 씨는 첫 푸시를 성공했지만, 궁금한 게 생겼습니다. "만약 실수로 잘못된 코드를 푸시하면 어떻게 하나요?" "좋은 질문이에요." 박시니어 선배가 답했습니다.

"일단 푸시하면 팀원들이 볼 수 있으니까 조심해야 해요. 하지만 Git은 모든 히스토리를 저장하니까 되돌릴 수는 있어요." "git revert"나 "git reset"으로 변경을 취소할 수 있지만, 이미 다른 사람이 그 코드를 받아갔다면 복잡해집니다.

따라서 푸시 전에 "git log"로 커밋을 확인하고, "git diff"로 변경사항을 검토하는 습관이 중요합니다. 코드를 푸시하는 것은 개발자의 일상입니다.

하루에도 여러 번 푸시할 수 있습니다. 작은 단위로 자주 커밋하고 푸시하는 것이 협업에 유리합니다.

김개발 씨는 이제 자신있게 코드를 푸시할 수 있게 되었습니다. "다음은 뭐 배워야 하나요?" "브랜치 관리예요." 박시니어 선배가 답했습니다.

"main 브랜치에 직접 푸시하는 건 위험하거든요."

실전 팁

💡 - 푸시 전에 항상 git status로 어떤 파일이 커밋되는지 확인하세요

• 큰 파일(100MB 이상)은 Git LFS를 사용하거나 S3에 별도로 저장하세요

---

5. 브랜치 관리

어느 날 김개발 씨는 새로운 기능을 개발하다가 main 브랜치를 망가뜨렸습니다. 팀원들이 "빌드가 안 돼요"라고 슬랙 메시지를 보내기 시작했습니다.

당황한 김개발 씨는 박시니어 선배에게 급히 연락했습니다.

브랜치 관리는 여러 개발자가 동시에 작업할 수 있도록 코드를 분기하는 전략입니다. 마치 철도의 선로가 여러 갈래로 나뉘듯이, 코드도 main 브랜치에서 feature 브랜치로 나누어 작업합니다.

안전하고 효율적인 협업의 핵심입니다.

다음 코드를 살펴봅시다.

# 브랜치 생성 및 관리하기

# 새로운 feature 브랜치 생성
git checkout -b feature/user-authentication

# 브랜치 목록 확인
git branch

# 작업하고 커밋
git add .
git commit -m "feat: JWT 기반 인증 로직 추가"

# feature 브랜치를 원격에 푸시
git push -u origin feature/user-authentication

# main 브랜치로 돌아가기
git checkout main

# 원격의 최신 변경사항 받기
git pull origin main

# 브랜치 삭제 (작업 완료 후)
git branch -d feature/user-authentication

박시니어 선배는 심각한 표정으로 화면을 봤습니다. "김 개발님, 앞으로는 main 브랜치에 직접 푸시하면 안 돼요." 김개발 씨는 잘못을 깨달았습니다.

"그럼 어떻게 해야 하나요?" "브랜치를 만들어서 작업해야 해요." 박시니어 선배가 설명하기 시작했습니다. 브랜치는 코드의 독립적인 작업 공간입니다.

마치 워드 문서의 "다른 이름으로 저장"과 비슷하지만, 훨씬 강력합니다. 원본은 그대로 두고 복사본에서 마음껏 실험할 수 있습니다.

"우리 팀은 Git Flow 전략을 써요." 박시니어 선배가 화이트보드에 그림을 그리기 시작했습니다. main 브랜치는 항상 배포 가능한 상태를 유지합니다.

고객이 실제로 사용하는 코드가 여기 있습니다. 절대 깨지면 안 됩니다.

develop 브랜치는 다음 배포를 준비하는 브랜치입니다. 개발자들이 완성한 기능이 모이는 곳입니다.

feature 브랜치는 개별 기능을 개발하는 브랜치입니다. "feature/user-login", "feature/payment-api" 같은 이름을 붙입니다.

김개발 씨가 앞으로 작업할 곳이 바로 여기입니다. 위의 코드를 보면 "git checkout -b"로 브랜치를 만들고 동시에 이동합니다.

"-b" 옵션이 없으면 기존 브랜치로 이동만 합니다. 김개발 씨가 따라 해봤습니다.

"git checkout -b feature/email-notification"을 입력하자 "Switched to a new branch 'feature/email-notification'"이라는 메시지가 나타났습니다. "이제 이 브랜치에서 마음껏 작업하세요." 박시니어 선배가 말했습니다.

"여기서 뭘 하든 main 브랜치는 안전해요." 김개발 씨는 안심하고 코드를 작성했습니다. 이메일 발송 기능을 추가하고, 테스트 코드도 작성했습니다.

그리고 커밋했습니다. "이제 이 브랜치를 원격에 푸시하세요." 박시니어 선배가 지시했습니다.

"git push -u origin feature/email-notification"을 입력하자 브랜치가 CodeCommit에 올라갔습니다. 실무에서는 브랜치 전략이 팀마다 다릅니다.

스타트업에서는 간단하게 main과 feature 브랜치만 사용하기도 합니다. 빠른 개발이 중요하니까 프로세스를 최소화합니다.

대기업에서는 Git Flow나 GitHub Flow 같은 표준화된 전략을 따릅니다. 브랜치 이름에도 규칙이 있습니다.

"feature/JIRA-1234-user-login" 같은 형식으로 티켓 번호를 포함시킵니다. 김개발 씨가 작업을 완료하고 main 브랜치로 돌아가려고 했습니다.

"git checkout main"을 입력했습니다. 그런데 "error: Your local changes to the following files would be overwritten"라는 에러가 나타났습니다.

아직 커밋하지 않은 변경사항이 있다는 뜻입니다. "이럴 때는 두 가지 선택지가 있어요." 박시니어 선배가 설명했습니다.

"커밋하거나, stash로 임시 저장하거나." "git stash"는 변경사항을 임시로 보관합니다. 마치 책갈피를 끼워두고 다른 책을 읽는 것과 같습니다.

나중에 "git stash pop"으로 다시 꺼낼 수 있습니다. 브랜치 삭제는 언제 할까요?

작업이 완료되고 main에 병합된 브랜치는 더 이상 필요 없습니다. "git branch -d feature/email-notification"으로 로컬 브랜치를 삭제합니다.

원격 브랜치는 "git push origin --delete feature/email-notification"으로 삭제합니다. 주의할 점이 있습니다.

브랜치를 너무 오래 유지하면 안 됩니다. main 브랜치와 점점 멀어지면 나중에 병합할 때 충돌이 많이 발생합니다.

가능하면 작은 단위로 자주 병합하는 것이 좋습니다. 또한 브랜치 이름은 명확해야 합니다.

"test", "temp", "my-branch" 같은 이름은 나중에 무슨 작업인지 알 수 없습니다. 김개발 씨는 이제 브랜치 관리의 중요성을 깨달았습니다.

"앞으로는 항상 feature 브랜치를 만들어서 작업할게요." "좋아요." 박시니어 선배가 칭찬했습니다. "그럼 이제 마지막 단계, Pull Request와 코드 리뷰를 배워봅시다."

실전 팁

💡 - 브랜치 이름에 자신의 이름을 넣지 마세요. 기능이나 목적을 명확히 표현하세요

• 브랜치를 전환하기 전에 항상 git status로 작업 중인 변경사항이 있는지 확인하세요

---

6. PR과 코드 리뷰

김개발 씨는 feature 브랜치에서 이메일 발송 기능을 완성했습니다. 이제 main 브랜치에 합치고 싶은데, 박시니어 선배가 "직접 merge하지 말고 Pull Request를 만들어요"라고 말했습니다.

PR이 뭘까요?

Pull Request는 자신이 작성한 코드를 main 브랜치에 병합하기 전에 팀원들에게 검토를 요청하는 과정입니다. 마치 논문을 제출하기 전에 동료 심사를 받는 것처럼, 코드도 리뷰를 거쳐야 합니다.

코드 품질을 높이고 지식을 공유하는 핵심 프로세스입니다.

다음 코드를 살펴봅시다.

# AWS CLI로 Pull Request 생성하기
import boto3

client = boto3.client('codecommit', region_name='ap-northeast-2')

# Pull Request 생성
response = client.create_pull_request(
    title='feat: 이메일 알림 기능 추가',
    description='''
## 변경 사항
- SMTP 연동으로 이메일 발송 기능 구현
- 템플릿 엔진으로 HTML 이메일 지원
- 발송 실패 시 재시도 로직 추가

## 테스트
- 단위 테스트 10개 추가
- 통합 테스트 3개 추가
    ''',
    targets=[{
        'repositoryName': 'customer-management-api',
        'sourceReference': 'feature/email-notification',
        'destinationReference': 'main'
    }]
)

print(f"PR 생성됨: {response['pullRequest']['pullRequestId']}")

박시니어 선배는 CodeCommit 콘솔을 열어서 보여주기 시작했습니다. "Pull Request는 줄여서 PR이라고 불러요.

GitHub에서는 많이 봤을 텐데, CodeCommit도 똑같아요." 김개발 씨는 GitHub에서 오픈소스 프로젝트의 PR을 본 적이 있었습니다. "아, 그거요!

코드를 올리면 다른 사람이 댓글을 달고 승인하는 거요." "정확해요." 박시니어 선배가 말했습니다. "우리 팀도 모든 코드는 최소 한 명 이상의 리뷰를 받아야 main에 병합할 수 있어요." PR을 만드는 방법은 간단합니다.

CodeCommit 콘솔에서 "Pull requests" 메뉴로 들어가서 "Create pull request" 버튼을 클릭합니다. 소스 브랜치와 대상 브랜치를 선택합니다.

김개발 씨의 경우 "feature/email-notification"에서 "main"으로 병합하려고 합니다. 제목과 설명을 작성하는 것이 중요합니다.

제목은 "feat: 이메일 알림 기능 추가"처럼 명확하게 작성합니다. 설명에는 무엇을 변경했는지, 왜 변경했는지, 어떻게 테스트했는지를 적습니다.

위의 코드는 프로그래밍 방식으로 PR을 생성하는 예제입니다. CI/CD 파이프라인에서 자동으로 PR을 만들 때 유용합니다.

description 필드를 보면 마크다운 형식으로 구조화되어 있습니다. "변경 사항", "테스트" 같은 섹션으로 나누어서 리뷰어가 쉽게 이해할 수 있도록 합니다.

김개발 씨가 PR을 생성하자, 팀 슬랙 채널에 알림이 떴습니다. "김개발님이 PR을 생성했습니다.

리뷰 부탁드립니다." 박시니어 선배가 PR을 열어봤습니다. 변경된 파일 목록이 보이고, 추가된 줄은 초록색, 삭제된 줄은 빨간색으로 표시됩니다.

"코드를 한 줄씩 보면서 댓글을 달 수 있어요." 박시니어 선배가 특정 줄을 클릭했습니다. "여기 이 부분, 에러 핸들링이 없는데 추가하면 어떨까요?" 댓글이 달리자 김개발 씨에게 알림이 갔습니다.

김개발 씨는 박시니어 선배의 의견이 맞다고 생각해서 코드를 수정했습니다. 수정한 코드를 같은 브랜치에 커밋하고 푸시하면, 자동으로 PR에 반영됩니다.

별도로 PR을 새로 만들 필요가 없습니다. 코드 리뷰는 단순히 버그를 찾는 것이 아닙니다.

더 나은 설계를 논의하고, 팀의 코딩 스타일을 맞추고, 지식을 공유하는 시간입니다. 실무에서는 리뷰 가이드라인을 정해놓습니다.

예를 들어 "24시간 이내에 리뷰하기", "nitpick은 명시하기", "칭찬도 적극적으로 하기" 같은 규칙입니다. "nitpick"은 아주 사소한 의견을 말합니다.

"이 변수 이름을 userName으로 바꾸면 더 명확할 것 같아요 (nitpick)"처럼 표시하면, 작성자가 선택적으로 반영할 수 있습니다. 반면 "이 부분은 SQL Injection 취약점이 있습니다.

반드시 수정해야 합니다"처럼 중요한 지적은 명확히 해야 합니다. 김개발 씨는 모든 댓글에 답변하고 코드를 수정했습니다.

박시니어 선배와 다른 팀원 두 명이 "Approve"를 눌렀습니다. "이제 병합해도 돼요." 박시니어 선배가 말했습니다.

병합 전략에는 세 가지가 있습니다. Fast-forward merge는 히스토리가 일직선으로 유지됩니다.

간단하지만 어떤 커밋이 같은 PR인지 구분하기 어렵습니다. Squash merge는 feature 브랜치의 모든 커밋을 하나로 합쳐서 병합합니다.

히스토리가 깔끔해지지만 세부 커밋 정보는 사라집니다. 3-way merge는 병합 커밋을 만듭니다.

히스토리가 복잡해지지만 모든 정보가 보존됩니다. "우리 팀은 Squash merge를 써요." 박시니어 선배가 설명했습니다.

"main 브랜치 히스토리를 깔끔하게 유지하려고요." 김개발 씨는 "Merge" 버튼을 클릭했습니다. 몇 초 후 "Merged successfully"라는 메시지가 나타났습니다.

드디어 자신의 코드가 main 브랜치에 들어갔습니다. 주의할 점도 있습니다.

PR이 너무 크면 리뷰하기 어렵습니다. 500줄 이상의 변경은 여러 PR로 나누는 것이 좋습니다.

"이 PR은 리뷰하기 힘드네요"라는 댓글이 달리기 전에 미리 작게 만들어야 합니다. 또한 PR을 오래 열어두면 안 됩니다.

main 브랜치가 계속 변하니까 충돌이 발생할 확률이 높아집니다. 가능하면 하루 안에 리뷰받고 병합하는 것이 이상적입니다.

김개발 씨는 처음으로 PR 프로세스를 완료했습니다. "생각보다 어렵지 않네요.

그리고 리뷰를 받으니까 제 코드가 더 좋아진 것 같아요." "맞아요." 박시니어 선배가 웃으며 답했습니다. "코드 리뷰는 개발자가 성장하는 가장 빠른 방법 중 하나예요." 이제 김개발 씨는 CodeCommit을 자유롭게 사용할 수 있게 되었습니다.

저장소 생성부터 브랜치 관리, 코드 리뷰까지 전체 워크플로우를 이해했습니다. "오늘 배운 걸 정리해볼까요?" 박시니어 선배가 말했습니다.

"네, CodeCommit은 AWS의 Git 서비스고, 보안과 통합성이 장점이에요. 저장소를 만들고, Git 자격 증명을 설정하고, 브랜치를 만들어서 작업하고, PR로 코드 리뷰를 받아서 병합하면 돼요." "완벽해요." 박시니어 선배가 엄지를 치켜세웠습니다.

"이제 실전에서 써보세요."

실전 팁

💡 - PR 설명에 스크린샷을 추가하면 리뷰어가 UI 변경사항을 쉽게 이해할 수 있습니다

• CodeCommit의 Approval Rules을 설정하면 최소 리뷰어 수를 강제할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!