[Github]Pull Request(PR)로 협업 마스터하기 🚀

Github

[Github]Pull Request(PR)로 협업 마스터하기 🚀

다다면체 2025. 4. 25. 10:32

728x90

안녕하세요, 개발자 여러분! ✨ 지난 시간에는 Git 브랜치를 활용하여 독립적으로 기능을 개발하는 방법을 알아보았습니다. 오늘은 드디어! 동료들과 함께 코드를 나누고, 서로의 작업을 합치는 핵심 과정, 바로 **Pull Request(PR)**에 대해 깊이 알아보겠습니다.

PR은 단순히 코드를 병합하는 기술적인 행위를 넘어, 팀의 코드 품질을 높이고, 지식을 공유하며, 함께 성장하는 문화를 만드는 핵심적인 소통 도구입니다. 오늘 이 시간을 통해 PR을 자신있게 사용하고 협업의 효율을 극대화하는 방법을 마스터해 보세요! 😊

🤔 Pull Request(PR), 그것이 무엇인가요?

Pull Request (PR) 또는 Merge Request (MR) (GitLab 등 다른 플랫폼에서 사용하는 용어)는 내가 작업한 브랜치의 변경사항을 다른 브랜치(주로 main이나 develop 같은 핵심 브랜치)에 "병합(Merge)해 주세요" 라고 공식적으로 요청하고, 그 변경사항에 대해 동료들과 논의하는 과정을 의미합니다.

단순히 코드 변경 내역을 보내는 것을 넘어, 다음과 같은 중요한 목적을 가집니다.

코드 검토 (Code Review): 동료들이 내 코드 변경사항을 검토하며 잠재적인 버그, 개선점, 코드 스타일 일관성 등을 확인합니다.
논의 및 피드백: 코드에 대한 질문, 제안, 토론을 통해 더 나은 방향으로 코드를 개선합니다.
변경 이력 관리: 어떤 변경사항이 왜, 누구에 의해, 어떤 논의를 거쳐 병합되었는지 명확한 기록을 남깁니다.
CI/CD 연동: PR 생성 시 자동으로 테스트, 빌드 등을 실행하여 코드의 안정성을 검증할 수 있습니다. (CI/CD는 추후 다룰 예정입니다!)

🌊 GitHub에서 PR을 생성하는 표준 워크플로우

GitHub(및 유사 플랫폼)에서 PR을 통한 일반적인 협업 흐름은 다음과 같습니다.

기능 브랜치 생성: main 브랜치에서 최신 코드를 받아와 새로운 기능 개발을 위한 브랜치를 생성합니다. (예: feature/add-user-login)
```
git checkout main
git pull origin main # 최신 상태 유지
git checkout -b feature/add-user-login
```
코드 변경 및 커밋: 해당 브랜치에서 기능을 구현하거나 버그를 수정하고, 의미 있는 단위로 변경사항을 커밋(commit)합니다.
```
# (코드 수정 작업...)
git add .
git commit -m "Feat: 사용자 로그인 기능 기본 골격 추가"
# (추가 작업 및 커밋 반복...)
```
브랜치 푸시(Push): 로컬에서 작업한 브랜치를 원격 저장소(GitHub)에 푸시합니다.
```
git push origin feature/add-user-login
```
GitHub에서 PR 생성: GitHub 저장소 페이지로 이동하면 방금 푸시한 브랜치에 대해 PR을 생성하라는 안내가 나타납니다. 또는 'Pull requests' 탭에서 'New pull request' 버튼을 클릭합니다.
- Base Repository/Branch: 변경사항을 병합할 대상 저장소 및 브랜치 (예: YourRepo/main)
- Head Repository/Branch: 내가 작업한 변경사항이 있는 저장소 및 브랜치 (예: YourRepo/feature/add-user-login)
- 제목(Title): PR의 목적을 명확하게 나타내는 제목을 작성합니다. (예: Feat: 사용자 로그인 기능 구현)
- 설명(Description): 변경사항에 대한 상세 설명, 구현 배경, 테스트 방법, 관련 이슈 번호 등을 상세히 작성합니다. (PR 템플릿을 활용하면 좋습니다!)
- Reviewers: 코드 리뷰를 요청할 동료를 지정합니다.
- Assignees: 이 PR을 책임지고 마무리할 담당자를 지정합니다. (보통 PR 작성자 자신)
- Labels: PR의 종류(Bug, Feature, Chore 등), 상태 등을 표시하는 라벨을 붙입니다.
리뷰 및 논의: 지정된 리뷰어(Reviewer)들이 코드 변경 내용(Diff)을 확인하고 피드백을 남깁니다.
- Diff 확인: 변경된 파일과 코드 라인을 시각적으로 확인합니다.
- 댓글 달기: 특정 코드 라인이나 전체 PR에 대해 질문하거나 의견을 남깁니다.
- 개선 사항 제안 (Suggest Changes): 코드 변경을 직접 제안할 수 있습니다. (PR 작성자가 클릭 한 번으로 적용 가능)
- 변경 요청 (Request Changes): 병합 전에 반드시 수정해야 할 사항이 있을 때 사용합니다.
- 승인 (Approve): 코드 변경사항에 동의하고 병합해도 좋다고 판단될 때 사용합니다.
승인 및 병합 (Merge): 필요한 수의 리뷰어에게 승인(Approve)을 받고, 모든 논의가 완료되면 PR을 대상 브랜치에 병합합니다.

브랜치 삭제: 병합이 완료된 기능 브랜치는 더 이상 필요 없으므로 삭제합니다. (GitHub PR 페이지에서 버튼 클릭으로 원격 브랜치 삭제 가능, 로컬 브랜치도 삭제)

# 로컬 브랜치 삭제
git checkout main # 다른 브랜치로 이동 후 삭제
git branch -d feature/add-user-login
# 원격 브랜치 삭제 (GitHub에서 삭제했다면 생략 가능)
# git push origin --delete feature/add-user-login

❤️ 코드 리뷰(Code Review)의 중요성 및 방법

코드 리뷰는 단순히 오류를 찾는 것을 넘어, 팀 전체의 코드 품질을 향상시키고 지식을 공유하는 핵심 문화입니다.

왜 중요할까요? 🤔

버그 조기 발견: 다른 시각에서 코드를 보며 논리적 오류나 엣지 케이스 누락 등을 찾아낼 수 있습니다.
코드 품질 향상: 더 효율적이고 읽기 좋은 코드 작성법, 디자인 패턴 적용 등에 대한 제안을 통해 코드 품질을 높입니다.
지식 공유 및 학습: 다른 사람의 코드를 보며 새로운 기술이나 접근 방식을 배우고, 내 코드에 대한 설명을 통해 이해도를 높입니다.
팀 표준 유지: 정해진 코드 스타일 가이드, 아키텍처 규칙 등을 일관성 있게 지키도록 돕습니다.
책임 공유: 혼자 모든 책임을 지는 것이 아니라, 팀 전체가 코드 품질에 대한 책임을 공유하게 됩니다.

어떻게 할까요? 📝

변경 내용(Diff) 꼼꼼히 확인: 'Files changed' 탭에서 어떤 파일이 어떻게 변경되었는지 라인별로 확인합니다.
전체적인 맥락 이해: PR 설명과 코드를 함께 보며 이 변경이 왜 필요했고, 어떤 문제를 해결하는지 이해하려 노력합니다.
긍정적이고 건설적인 피드백: 비판보다는 개선을 위한 제안 형태로 피드백을 남깁니다. ("이 부분은 이렇게 바꾸는 것이 더 명확해 보입니다.")
구체적인 의견 제시: 모호한 표현보다는 어떤 부분이 왜 개선되면 좋은지 명확하게 설명합니다. (예: "변수명이 모호해서 어떤 데이터인지 파악하기 어렵습니다. userData 대신 userProfileData는 어떨까요?")
GitHub 기능 활용:
- 특정 라인에 댓글: 궁금하거나 제안할 내용이 있는 코드 라인 옆 '+' 버튼 클릭.
- 변경 제안 (Suggest Changes): 댓글 창 상단의 아이콘(±) 클릭 후 수정 제안 작성.
- 리뷰 요약: 전체적인 의견과 함께 'Comment'(단순 의견), 'Approve'(승인), 'Request changes'(변경 요청) 중 하나를 선택하여 리뷰를 제출합니다.

💡 실무 팁: 코드 리뷰는 가능한 빠르게 피드백 주는 것이 좋습니다. PR이 너무 오래 방치되면 작업 흐름이 막히고 컨텍스트를 다시 파악하기 어려워집니다.

🔀 PR 병합(Merge) 옵션: 어떤 것을 선택해야 할까?

GitHub에서 PR을 병합할 때 주로 3가지 옵션을 제공합니다. 각 방식은 Git 히스토리를 다르게 관리하므로, 팀의 전략에 맞게 선택하는 것이 중요합니다.

Create a merge commit (기본값):
- 동작: 기능 브랜치의 모든 커밋 내역을 그대로 유지하면서, 대상 브랜치(예: main)와 병합하는 새로운 'Merge commit'을 생성합니다.
- 장점: 모든 개별 커밋 히스토리가 보존되어 작업 과정을 상세히 추적할 수 있습니다. 어떤 브랜치에서 작업했는지 명확하게 보입니다.
- 단점: 기능 개발 중 발생한 자잘한 커밋들(오타 수정, 임시 저장 등)까지 모두 main 히스토리에 남아 복잡해 보일 수 있습니다. 브랜치 그래프가 비선형적으로 복잡해집니다.
- 언제 사용할까? 기능 브랜치의 상세한 개발 과정을 모두 남기고 싶을 때, 브랜치 기반 워크플로우(Gitflow 등)에서 주로 사용됩니다.
Squash and merge:
- 동작: 기능 브랜치의 모든 커밋들을 하나의 커밋으로 합친(Squash) 후, 대상 브랜치에 병합합니다. PR 제목과 설명을 기반으로 커밋 메시지를 편집할 수 있습니다.
- 장점: main 브랜치의 히스토리가 기능 단위로 깔끔하게 유지됩니다. 자잘한 커밋들이 하나로 합쳐져 히스토리 가독성이 높아집니다.
- 단점: 기능 개발 과정의 상세한 커밋 내역이 사라집니다. (어떤 순서로 개발했는지 추적하기 어려움)
- 언제 사용할까? main 히스토리를 깔끔하게 유지하고 싶을 때, 각 PR이 독립적인 기능이나 수정 사항을 나타낼 때 유용합니다. 많은 팀에서 선호하는 방식입니다.
Rebase and merge:
- 동작: 기능 브랜치의 커밋들을 대상 브랜치의 최신 커밋 뒤에 차례대로 이어 붙입니다(Rebase). 그 후 대상 브랜치가 단순히 앞으로 이동(Fast-forward)하여 병합됩니다.
- 장점: main 브랜치의 히스토리가 **완전히 선형(Linear)**으로 유지되어 매우 깔끔하고 이해하기 쉽습니다. Merge commit이 남지 않습니다.
- 단점: 커밋들의 해시(ID)가 변경되어 히스토리가 **재작성(Rewrite)**됩니다. 이미 여러 사람이 공유하고 있는 브랜치에 Rebase를 사용하면 큰 혼란을 야기할 수 있습니다. (Force push 필요) Merge commit 방식보다 충돌 해결이 더 복잡할 수 있습니다.
- 언제 사용할까? 매우 깔끔한 선형 히스토리를 선호하는 팀에서 사용합니다. Rebase의 동작 방식과 잠재적 위험성을 팀원 모두가 잘 이해하고 있을 때 적합합니다.

📊 어떤 옵션을 선택해야 할까요? 정답은 없습니다! 팀의 규모, 프로젝트 복잡성, 히스토리 관리 정책에 따라 다릅니다. 일반적으로 Squash and merge가 히스토리의 깔끔함과 추적 용이성 사이에서 좋은 균형을 제공하여 많이 사용됩니다. 중요한 것은 팀 내에서 합의된 방식을 일관성 있게 사용하는 것입니다.

🍴 (선택 사항) Forking 워크플로우: 오픈소스 기여의 첫걸음

만약 여러분이 다른 사람이나 조직의 공개 저장소(Repository)에 기여하고 싶다면? 보통 해당 저장소에 직접 코드를 푸시할 권한(Write access)이 없습니다. 이럴 때 사용하는 것이 Forking 워크플로우입니다.

Fork: 기여하고 싶은 원본 저장소를 내 GitHub 계정으로 **복제(Fork)**합니다. 내 계정 아래에 동일한 이름의 저장소가 생성됩니다.
Clone: 내 계정으로 Fork 해온 저장소를 로컬 컴퓨터로 클론(Clone)합니다.
Branch & Code: 로컬 저장소에서 새로운 브랜치를 만들고 코드를 수정/추가합니다.
Push: 작업한 브랜치를 내 Fork된 저장소로 푸시합니다.
Create PR: 내 Fork된 저장소에서 원본 저장소를 대상으로 PR을 생성합니다. (Base: 원본 저장소의 main, Head: 내 저장소의 feature-branch)
Review & Merge: 원본 저장소의 관리자들이 코드를 리뷰하고, 문제가 없으면 PR을 병합합니다.

이 방식은 오픈소스 프로젝트에 기여하는 표준적인 방법이며, 원본 저장소의 안전성을 유지하면서 외부의 기여를 받을 수 있게 해줍니다.

💥 [문제 해결] 병합 충돌(Merge Conflict)과 해결 방법

협업하다 보면 피할 수 없는 상황 중 하나가 바로 **병합 충돌(Merge Conflict)**입니다. 너무 당황하지 마세요! 원리를 이해하면 충분히 해결할 수 있습니다.

왜 발생하나요? 🤔

병합 충돌은 서로 다른 브랜치에서 같은 파일의 같은 부분을 동시에 수정했을 때 발생합니다. Git이 어떤 변경사항을 최종본으로 선택해야 할지 자동으로 판단할 수 없기 때문에 사용자에게 직접 해결을 요청하는 것입니다.

어떻게 해결하나요? 🛠️

1. GitHub 웹사이트에서 간단한 충돌 해결:

PR 페이지에 충돌이 발생했다는 메시지가 표시됩니다. ('Conflicts' 버튼 활성화)
'Resolve conflicts' 버튼을 클릭하면 충돌이 발생한 파일을 웹 편집기에서 보여줍니다.

충돌 부분은 다음과 같은 마커로 표시됩니다.

<<<<<<< HEAD (또는 대상 브랜치 이름)
// 현재 브랜치(대상 브랜치)의 코드 내용
=======
// 병합하려는 브랜치(내 작업 브랜치)의 코드 내용
>>>>>>> [branch-name] (내 작업 브랜치 이름)

마커(<<<<<<<, =======, >>>>>>>)를 모두 제거하고, 두 버전의 코드를 비교하여 원하는 최종 코드로 직접 수정합니다.
수정이 완료되면 'Mark as resolved' 버튼을 클릭합니다.
모든 충돌을 해결한 후 'Commit merge' 버튼을 클릭하여 충돌 해결 커밋을 생성합니다.

2. 로컬 개발 환경에서 충돌 해결 (권장):

더 복잡한 충돌이나, 로컬에서 테스트하며 해결하고 싶을 때 사용하는 방법입니다.

충돌 발생 확인: git merge [branch-name] 또는 git pull 명령 실행 시 충돌이 발생하면 터미널에 메시지가 출력됩니다. git status 명령으로 어떤 파일에서 충돌이 났는지 확인할 수 있습니다.

# 예시: main 브랜치에 feature 브랜치를 병합하려다 충돌 발생
git checkout main
git merge feature/add-user-login
# Auto-merging README.md
# CONFLICT (content): Merge conflict in README.md
# Automatic merge failed; fix conflicts and then commit the result.

git status
# On branch main
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#   (use "git merge --abort" to abort the merge)
#
# Unmerged paths:
#   (use "git add <file>..." to mark resolution)
#         both modified:   README.md
#

충돌 파일 열기: IDE나 텍스트 에디터에서 충돌이 발생한 파일(예: README.md)을 엽니다.
충돌 마커 확인 및 수정: GitHub 웹 편집기에서 본 것과 동일한 충돌 마커(<<<<<<< HEAD, =======, >>>>>>> [branch-name])가 보입니다.
- <<<<<<< HEAD: 현재 체크아웃된 브랜치(main 등)의 변경 내용입니다.
- =======: 두 변경 내용을 구분하는 구분선입니다.
- >>>>>>> [branch-name]: 병합하려는 브랜치(feature/add-user-login 등)의 변경 내용입니다.
- 이 마커들을 포함하여 불필요한 코드는 지우고, 최종적으로 남기고 싶은 코드만 남도록 직접 수정합니다. 두 브랜치의 내용을 조합해야 할 수도 있습니다.
수정된 파일 스테이징(Staging): 충돌을 해결하고 파일을 저장한 후, Git에게 충돌을 해결했음을 알려주기 위해 해당 파일을 git add 합니다.
```
git add README.md
```
커밋 또는 병합 계속:
- 만약 git merge 중에 충돌이 발생했다면, git commit 명령을 실행하여 충돌 해결 커밋을 생성합니다. Git이 기본 커밋 메시지를 제안해 줄 것입니다.
  git commit # 편집기에서 커밋 메시지 확인/수정 후 저장
- 만약 git rebase 중에 충돌이 발생했다면, git rebase --continue 명령을 실행하여 리베이스 과정을 계속 진행합니다.

💡 실무 팁: 충돌 해결 후에는 반드시 애플리케이션이 정상적으로 동작하는지 테스트하는 것이 매우 중요합니다! 코드를 잘못 수정하여 새로운 버그를 만들 수 있기 때문입니다.

🔄 [문제 해결] PR 리뷰 피드백 반영 및 업데이트

리뷰어로부터 코드 수정 요청을 받았다면 어떻게 해야 할까요? 간단합니다!

로컬 브랜치 확인: 피드백을 받은 PR의 로컬 브랜치(예: feature/add-user-login)로 이동합니다.
```
git checkout feature/add-user-login
```

코드 수정 및 커밋: 피드백에 따라 코드를 수정하고, 변경사항을 커밋합니다.

# (코드 수정 작업...)
git add .
git commit -m "Refactor: 리뷰 피드백 반영 - 로그인 로직 개선"

다시 푸시: 수정된 내용을 동일한 이름의 원격 브랜치에 다시 푸시합니다.
```
git push origin feature/add-user-login
```

✨ 마법 같은 순간: 이렇게 기존 PR 브랜치에 새로운 커밋을 푸시하면, GitHub의 해당 PR 페이지가 자동으로 업데이트됩니다! 리뷰어는 새로운 변경사항을 확인하고 다시 리뷰를 진행할 수 있습니다. 별도로 PR을 다시 만들 필요가 없습니다.

🚀 예제를 통해 직접 경험해보기

자, 이론을 배웠으니 이제 직접 해볼 차례입니다! (3편에서 feature/add-user-login 브랜치를 만들었다고 가정합니다.)

PR 생성:

feature/add-user-login 브랜치에서 작업한 내용을 커밋하고 origin에 푸시합니다. (git push origin feature/add-user-login)
GitHub 저장소로 이동하여 main 브랜치를 대상으로 feature/add-user-login 브랜치에 대한 새 PR을 생성합니다.
제목: Feat: 사용자 로그인 기능 추가

설명:

## 📝 변경 내용
- 사용자 아이디/비밀번호 입력 폼 추가
- 로그인 버튼 클릭 시 서버로 요청 전송 (기본 로직)
- (아직 실제 인증 로직은 구현되지 않음)

## ✅ 테스트 방법
1. 애플리케이션 실행
2. 로그인 페이지로 이동
3. 아이디/비밀번호 입력 후 로그인 버튼 클릭 (콘솔 로그 확인)

## 关联 이슈
- Closes #12  (만약 관련된 이슈가 있다면)

(선택 사항) 동료 개발자나 자신의 다른 계정을 Reviewer로 지정합니다.

코드 리뷰 및 댓글:
- 리뷰어 계정으로 GitHub에 로그인하여 해당 PR 페이지로 이동합니다.
- 'Files changed' 탭에서 변경된 코드를 확인합니다.
- 특정 코드 라인(예: 변수명) 옆 '+' 버튼을 클릭하여 질문 댓글을 남깁니다. "이 변수명이 조금 모호한 것 같은데, 어떤 데이터를 의미하는지 좀 더 명확하게 알 수 있을까요? 🤔"
피드백 반영 및 PR 업데이트:
- PR 작성자 계정으로 돌아옵니다. 리뷰 댓글을 확인합니다.
- 로컬 feature/add-user-login 브랜치에서 해당 변수명을 더 명확하게 수정하고 커밋합니다. (git commit -m "Refactor: 로그인 관련 변수명 명확하게 수정 (피드백 반영)")
- 다시 푸시합니다. (git push origin feature/add-user-login)
- GitHub PR 페이지에 새로운 커밋이 반영된 것을 확인합니다. 리뷰 댓글에 답변을 남깁니다. "피드백 감사합니다! 변수명 수정해서 다시 푸시했습니다. 확인 부탁드려요! 🙏"
리뷰 승인:
- 리뷰어 계정으로 변경사항을 다시 확인합니다. 만족스럽다면 'Review changes' 버튼을 클릭하고 'Approve'를 선택하여 리뷰를 제출합니다. 👍
PR 병합:
- PR 작성자 계정(또는 병합 권한이 있는 계정)으로 돌아옵니다. 승인된 것을 확인하고, 'Merge pull request' 버튼을 클릭합니다.
- (옵션 선택) 여기서는 'Create a merge commit' 기본 방식을 선택하고 'Confirm merge' 버튼을 클릭합니다. ✅
브랜치 삭제:
- 병합 후 나타나는 'Delete branch' 버튼을 클릭하여 GitHub에서 원격 브랜치를 삭제합니다.
- 로컬에서도 해당 브랜치를 삭제합니다.
  git checkout main git pull origin main # main을 최신 상태로 업데이트 git branch -d feature/add-user-login
병합 충돌 만들기 및 해결 (연습):
- 상황 만들기:
  - main 브랜치에서 README.md 파일의 첫 번째 줄을 수정하고 커밋, 푸시합니다. (git checkout main, README.md 수정, git commit -am "Docs: README 첫 줄 수정 (main)", git push origin main)
  - 새로운 브랜치(feature/update-readme)를 생성하고, 동일하게 README.md 파일의 첫 번째 줄을 다른 내용으로 수정하고 커밋, 푸시합니다. (git checkout -b feature/update-readme, README.md 수정, git commit -am "Docs: README 첫 줄 수정 (feature)", git push origin feature/update-readme)
  - 이제 feature/update-readme 브랜치에서 main 브랜치로 PR을 생성하면 충돌이 발생할 것입니다! 💥
- 로컬에서 충돌 해결:
  - 로컬 feature/update-readme 브랜치에서 최신 main 브랜치의 변경사항을 가져와 병합(또는 리베이스) 시도합니다.
    git checkout feature/update-readme # 방법 1: main 브랜치를 현재 브랜치로 병합 시도 git fetch origin # 원격 저장소 최신 정보 가져오기 git merge origin/main # 또는 방법 2: 현재 브랜치를 main 브랜치 위로 리베이스 시도 (히스토리 재작성) # git pull --rebase origin main
  - 터미널에 충돌 메시지가 나타나면 git status로 충돌 파일을 확인합니다 (README.md).
  - VS Code 등 에디터에서 README.md 파일을 엽니다.
  - <<<<<<< HEAD, =======, >>>>>>> origin/main (또는 유사한) 마커를 확인합니다.
  - 두 버전의 내용을 보고 원하는 최종 내용만 남기고, 마커들은 모두 삭제합니다.
  - 파일을 저장합니다.
  - 터미널에서 git add README.md 명령으로 충돌 해결을 알립니다.
  - 병합(merge) 중이었다면 git commit을, 리베이스(rebase) 중이었다면 git rebase --continue를 실행합니다.
  - 마지막으로 git push origin feature/update-readme (리베이스 했다면 git push --force-with-lease origin feature/update-readme 필요할 수 있음) 하여 충돌이 해결된 내용을 원격 저장소 및 PR에 반영합니다.

✨ 함께 성장하는 협업을 위한 마무리

Pull Request는 단순히 코드를 합치는 기술이 아니라, 소통하고, 배우고, 함께 더 나은 결과물을 만들어가는 과정입니다. 처음에는 조금 복잡하게 느껴질 수 있지만, 몇 번 직접 해보면 금방 익숙해질 거예요.

명확한 PR 설명은 리뷰어의 시간을 절약해주고,
건설적인 코드 리뷰는 동료와 나 자신의 성장을 돕고,
체계적인 병합 전략은 프로젝트 히스토리를 건강하게 유지합니다.

오늘 배운 내용을 바탕으로 동료들과 적극적으로 PR을 주고받으며 즐겁게 협업하시길 바랍니다! 🎉 다음 시간에는 더 흥미로운 Git의 세계로 함께 떠나보겠습니다.

728x90

저작자표시 비영리 변경금지 (새창열림)