12강. 프로젝트 공유와 협업 구조
0. 학습 목표
→ 프로젝트가 다른 컴퓨터에서 실행되기까지의 전체 흐름과 GitHub 중심 협업 구조를 정리합니다.
이번 글은 개념 중심 강의입니다.
11강에서 requirements.txt를 cp 명령으로 옆 폴더에 전달했습니다.
하지만 실제 협업에서 소스 코드와 requirements.txt는 GitHub 클라우드 저장소를 통해 오갑니다.
이번 강의는 직접 명령어를 입력하는 실습이 아니라, 그 전체 그림을 정리하는 이론 학습입니다.
지금까지 배운 조각들 — 가상환경, 패키지 설치, requirements.txt — 이 협업 구조 안에서 각각 어느 자리에 들어가는지 확인합니다.
여기서 정리하는 흐름은 다음 강의(13강)에서 실제로 한 번 통과하게 되므로,
이번 강의는 13강의 설계도라고 생각하면 됩니다.
| 구분 | 내용 |
| 이해할 것 | 프로젝트를 받아서 실행하기까지의 5단계 표준 흐름 |
| 정리할 것 | GitHub 클라우드 저장소가 협업의 기준점 역할을 하는 구조 |
| 확인할 것 | GitHub에 올라간 최신 작업물이 각 개발자 컴퓨터에 자동 반영되지 않는다는 사실 |
1. 프로젝트를 받아서 실행하기까지 — 표준 5단계
→ 다른 사람의 Python 프로젝트를 내 컴퓨터에서 실행하는 일반적인 흐름을 정리합니다.
Python 프로젝트를 공유받아 실행하는 가장 일반적인 흐름은 다음 5단계입니다. GitHub(온라인)에서 프로젝트를 내 PC(오프라인)로 가져온 뒤, Python 버전에 맞춰 가상환경을 만들고, requirements.txt 기준으로 패키지를 설치하고, 실행합니다.
[GitHub 저장소]
│
▼ 1. git clone <저장소_주소> (프로젝트 가져오기)
[내 컴퓨터: 프로젝트 폴더]
│
▼ 2. python3.13 -m venv .venv (가상환경 새로 생성)
[독립된 가상환경]
│
▼ 3. source .venv/bin/activate (가상환경 활성화)
[가상환경 활성화 완료]
│
▼ 4. python -m pip install -r requirements.txt (패키지 복원)
[패키지 설치 완료]
│
▼ 5. python main.py (실행)
[프로젝트 실행] ← 이 흐름 전체가 13강의 실습
새로운 것은 1단계의 git clone뿐입니다.
GitHub 저장소의 내용을 내 컴퓨터로 통째로 내려받는 명령으로,
11강의 cp가 하던 "전달" 역할을 인터넷 너머로 확장한 것이라고 이해하면 됩니다.
2~5단계는 11강에서 Project_New를 만들며 이미 직접 해본 절차 그대로입니다.
이 흐름에서 중요한 점은 순서입니다. 프로젝트를 받은 뒤 바로 python main.py를 실행하는 것이 아니라, 먼저 가상환경을 새로 만들고 패키지를 복원한 다음 실행합니다.
왜 이 순서여야 하는지는 이미 배웠습니다 — 10강에서 본 대로 저장소에는 .venv가 없기 때문입니다.
가상환경 폴더는 공유 대상이 아니므로, 받는 쪽이 자기 컴퓨터에서 새로 만드는 것입니다.
| 단계 | 하는 일 | 배운 강의 |
| 1. clone | 저장소를 내 컴퓨터로 가져오기 | 이번 강의 (실습은 13강) |
| 2. venv 생성 | 프로젝트 전용 가상환경 만들기 | 4강 (기본) · 6강 (버전 지정) |
| 3. 활성화 | 터미널을 가상환경 모드로 전환 | 4강 |
| 4. 패키지 복원 | requirements.txt 기준 일괄 설치 | 10강 (원리) · 11강 (실습) |
| 5. 실행 | 프로그램 실행 | — |
표에서 보이듯 5단계 중 4단계는 이미 손에 익은 절차입니다. 시리즈 전체가 사실 이 표준 흐름을 한 단계씩 준비해 온 과정이었던 것입니다.
2. GitHub를 기준점으로 하는 협업 구조
→ 여러 개발자가 클라우드 저장소를 사이에 두고 작업물을 주고받는 구조를 이해합니다.
2.1 왜 중간에 저장소를 두는가
S/W 프로젝트는 보통 여러 개발자가 함께 작업합니다.
이때 각자의 컴퓨터에 있는 작업물을 서로 직접 주고받으면 — A가 B에게 보내고, B가 C에게 보내고, 그 사이 A가 또 수정하면 — 누구의 것이 최신인지 금방 알 수 없게 됩니다.
그래서 중간에 GitHub 클라우드 저장소를 두고, 모든 작업물은 저장소를 거쳐 오가게 합니다.
전체 구조는 크게 다음 세 부분으로 나누어 이해할 수 있습니다.
A 개발자 작업
A 개발자 컴퓨터의 작업물
GitHub 클라우드
공동 작업물을 보관하는 저장소
(소스 코드 + requirements.txt)
B 개발자 작업
B 개발자 컴퓨터의 작업물
여기서 10강의 공유 기준이 그대로 적용됩니다.
저장소에 올라가는 것은 소스 코드와 requirements.txt이고, .venv는 각 개발자가 자기 컴퓨터에서 만듭니다.
A는 Ubuntu, B는 Windows를 쓰더라도 문제없는 이유가 바로 이것입니다 — 각자 자기 OS에 맞는 가상환경을 새로 만들고, 같은 requirements.txt로 같은 조합을 복원하기 때문입니다.
2.2 시간 흐름으로 보는 주고받기
저장소를 사이에 둔 하루의 작업 흐름을 시간순으로 따라가 보겠습니다.
올리는 방향(개발자 → GitHub)과 가져오는 방향(GitHub → 개발자)이 계속 교차합니다.
| 09:00 | A 개발자 → GitHub → B 개발자 | A 개발자가 자신의 작업물을 GitHub 클라우드에 올립니다. |
| 10:00 | A 개발자 → GitHub → B 개발자 | B 개발자가 GitHub 클라우드에서 작업물을 가져옵니다. |
| 11:00 | A 개발자 → GitHub → B 개발자 | A 개발자가 수정한 작업물을 다시 GitHub 클라우드에 올립니다. |
| 12:00 | A 개발자 → GitHub ↔ B 개발자 | B 개발자는 자신의 작업물을 갱신 전 GitHub의 최신 변경사항을 확인합니다. |
예를 들어, 11:00에 A 개발자가 수정한 작업물을 GitHub에 올리면 GitHub 클라우드는 최신 상태가 됩니다.
하지만 B 개발자의 컴퓨터는 아직 이전 상태일 수 있습니다.
그래서 12:00 B 개발자는 자신의 작업물을 올리기 전에 먼저 GitHub에 새로운 변경사항이 있는지 확인해야 합니다.
- 프로젝트 실행의 표준 흐름: clone → venv 생성 → 활성화 → 패키지 복원 → 실행
- 협업은 개발자끼리 직접 주고받지 않고 GitHub 저장소를 기준점으로 오간다
- 저장소에는 소스 코드 + requirements.txt만 — .venv는 각자 자기 컴퓨터에서 생성
- 저장소가 갱신되어도 내 컴퓨터는 자동으로 바뀌지 않는다 — 올리기 전에 먼저 가져온다→ 다음 강의 (13강): 이번 강의에서 정리한 표준 5단계를 실제로 통과합니다.
11강에서 만든 Project를 "공유받은 프로젝트"로 삼아, clone(또는 폴더 이동 시뮬레이션)
→ venv 생성
→ 패키지 복원
→ python main.py 실행까지 — 0강에서 약속한 시리즈 전체의 성공 기준을 직접 확인하며 마무리합니다.