모든 강의를 무료로 볼 수 있어요. 회원가입 없이도 학습 가능합니다.

1강 / 전체 7강

버전 관리란

8분 읽기 조회 4

버전 관리가 왜 필요한지 역사적 맥락과 실전 문제로 이해하고, Git의 핵심 동작 원리, Git과 GitHub의 명확한 역할 차이, 이 시리즈에서 배울 전체 워크플로를 한눈에 파악합니다.

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

  • 버전 관리가 왜 필요한지 구체적인 문제 상황으로 설명할 수 있습니다.
  • Git이 파일을 어떤 방식으로 추적하는지 핵심 원리를 이해합니다.
  • Git(도구)과 GitHub(서비스)의 차이를 명확하게 구분할 수 있습니다.
  • 이 시리즈에서 배울 전체 워크플로의 큰 그림을 파악합니다.

💡 버전 관리가 없던 시절 — 공감할 수 있는 문제들

이 섹션에서는 버전 관리 도구 없이 작업할 때 누구나 경험하는 실제 문제들을 살펴보겠습니다.

버전 관리를 배우기 전에 왜 필요한지를 먼저 느끼는 것이 중요합니다. 다음 상황들이 낯설지 않다면 이미 버전 관리의 필요성을 몸으로 경험한 것입니다.

파일명 지옥: 중요한 보고서를 작성할 때 보통 어떻게 하나요? 처음엔 보고서.docx로 시작하지만, 수정이 쌓이면서 보고서_최종.docx, 보고서_최종2.docx, 보고서_진짜최종.docx, 보고서_진짜진짜최종_20240115.docx처럼 변해갑니다. 어느 버전이 실제로 최신인지 알기 어려워지고, 언제 무엇이 바뀌었는지 추적이 불가능해집니다.

실수 복구 불가: 코드나 문서를 수정했는데 그 수정이 오히려 더 나빴을 때, 이전 상태로 돌아가려면 어떻게 해야 할까요? 파일을 덮어썼다면 되돌릴 방법이 없습니다. Ctrl+Z(실행 취소)는 현재 세션 내에서만 가능하고, 파일을 닫고 다시 열면 그 이전 상태는 영원히 사라집니다.

협업의 혼란: 팀 프로젝트에서 두 사람이 같은 파일을 동시에 수정하면 어떻게 될까요? 나중에 저장하는 사람이 먼저 저장한 사람의 수정 내용을 덮어씁니다. 이메일로 파일을 주고받는 방식은 "어떤 버전이 최신인가"를 끊임없이 혼란스럽게 만듭니다. 심지어 서로 다른 사람이 같은 줄을 수정했을 때 어느 쪽을 선택해야 할지 판단하기 어렵습니다.

언제 왜 바뀌었는지 모름: 3개월 전 코드가 지금 코드와 다르다는 건 알겠는데, 누가 왜 바꿨는지 알 방법이 없습니다. 변경 이력이 없으면 버그가 어느 시점에 도입됐는지 찾기가 매우 어렵습니다.

이 모든 문제를 해결하기 위해 등장한 것이 버전 관리 시스템(VCS, Version Control System)입니다.

📚 버전 관리란 무엇인가 — 개념과 역사

이 섹션에서는 버전 관리 시스템의 정의와 발전 과정을 살펴보겠습니다.

버전 관리(Version Control)란 파일의 변경 내역을 시간 순으로 기록하고 관리하는 시스템입니다. 마치 문서 편집기의 "변경 이력 추적" 기능을 모든 종류의 파일에 대해, 팀 전체가, 영구적으로 사용할 수 있게 만든 것이라고 생각하면 됩니다.

버전 관리 시스템의 발전 역사를 간략히 살펴보면 Git이 왜 현재 표준이 됐는지 이해할 수 있습니다.

1세대 — 로컬 VCS (1970~1990년대): 개인 컴퓨터에서만 버전을 관리하는 방식입니다. SCCS, RCS 같은 도구가 있었습니다. 혼자 작업할 때는 편리했지만 협업이 불가능했습니다.

2세대 — 중앙 집중식 VCS (1990~2000년대): 중앙 서버에 모든 버전을 저장하고 팀원이 네트워크로 접근하는 방식입니다. CVS, SVN(Subversion)이 대표적입니다. 협업이 가능해졌지만 서버가 다운되면 작업이 불가능하고, 인터넷 없이는 사용이 어려웠습니다.

3세대 — 분산형 VCS (2000년대~현재): 각 개발자가 전체 이력의 완전한 복사본을 로컬에 갖는 방식입니다. Git, Mercurial이 대표적입니다. 오프라인에서도 작업 가능하고, 서버 없이도 기본 작업이 가능합니다. Git은 2005년 리눅스 커널 개발팀(Linus Torvalds)이 만들었으며, 현재 전 세계 소프트웨어 개발의 사실상 표준이 됐습니다.

🔧 Git의 핵심 원리 — 스냅샷으로 이해하기

이 섹션에서는 Git이 파일 변경을 어떻게 추적하는지 핵심 동작 원리를 살펴보겠습니다.

Git을 이해하는 핵심 개념은 스냅샷(Snapshot)입니다. Git은 파일의 변경된 부분(차이)만 저장하는 것이 아니라, 특정 시점의 파일 상태 전체를 사진 찍듯 기록합니다. 이 스냅샷을 커밋(Commit)이라고 합니다.

커밋은 단순한 파일 저장이 아닙니다. 각 커밋에는 다음 정보가 포함됩니다.

  • 스냅샷: 해당 시점의 모든 파일 상태
  • 작성자 정보: 누가 커밋했는지 (이름, 이메일)
  • 타임스탬프: 언제 커밋했는지
  • 커밋 메시지: 무엇을 왜 변경했는지 설명
  • 부모 커밋 참조: 이전 커밋이 무엇인지 (히스토리 체인)

이 커밋들이 시간 순서대로 연결된 체인이 바로 프로젝트의 히스토리입니다. Git은 언제든지 이 히스토리를 따라 특정 시점의 상태로 되돌아갈 수 있습니다. "3주 전 이 파일이 어떤 상태였나?"라는 질문에 즉시 답할 수 있고, "이 버그가 처음 도입된 커밋이 어느 것인가?"도 찾을 수 있습니다.

Git의 또 다른 중요한 특성은 분산(Distributed)이라는 점입니다. 팀원 각자가 전체 프로젝트 히스토리를 로컬 컴퓨터에 완전히 보유합니다. 서버에 연결이 안 돼도 히스토리 확인, 커밋 생성, 브랜치 전환 등 대부분의 작업이 가능합니다. 서버와는 필요할 때만 동기화합니다.

🌐 Git과 GitHub — 도구와 서비스의 차이

이 섹션에서는 처음 배우는 분들이 가장 많이 혼동하는 Git과 GitHub의 차이를 명확하게 살펴보겠습니다.

Git과 GitHub는 이름이 비슷해서 혼동하기 쉽지만 전혀 다른 것입니다. 이 차이를 명확히 이해하는 것이 앞으로 배울 내용의 기초가 됩니다.

구분GitGitHub
정체 소프트웨어 도구 (프로그램) 웹 서비스 (플랫폼)
역할 로컬 버전 관리 (내 컴퓨터에서) 원격 저장소 호스팅 + 협업 기능
제작사 Linus Torvalds (오픈소스) GitHub Inc. (현재 Microsoft 소유)
인터넷 필요 불필요 (대부분의 작업) 필요
비용 무료 (오픈소스) 무료(기본) / 유료(팀·엔터프라이즈)
비유 카메라 (사진을 찍는 도구) 인스타그램 (사진을 올려 공유하는 서비스)

핵심을 한 문장으로 정리하면: Git은 내 컴퓨터에서 버전을 관리하는 도구이고, GitHub는 그 버전 히스토리를 인터넷에 올려 공유하고 협업하는 서비스입니다.

GitHub와 비슷한 서비스로 GitLab, Bitbucket이 있습니다. 이들 모두 Git을 기반으로 하지만 제공하는 부가 기능과 가격 정책이 다릅니다. 이 강의에서는 가장 많이 사용되는 GitHub를 기준으로 배웁니다. Git을 배우면 다른 서비스도 쉽게 활용할 수 있습니다.

🗺️ 이 시리즈에서 배울 워크플로 전체 그림

이 섹션에서는 앞으로 18강에 걸쳐 배울 Git·GitHub 워크플로의 전체 지도를 살펴보겠습니다.

처음에는 개별 명령어가 낯설겠지만, 전체 그림을 이해하면 각 단계가 어떤 맥락에서 필요한지 알 수 있습니다. 이 강의 시리즈에서 배울 워크플로는 다음 흐름으로 이어집니다.

단계무엇을 하는가배우는 강
1. 설치와 설정Git을 내 컴퓨터에 설치하고 기본 설정2강
2. 저장소 생성프로젝트 폴더를 Git이 추적할 수 있게 초기화3강
3. 변경 기록파일 추가(add)와 커밋(commit)으로 스냅샷 저장4강
4. 이력 확인변경된 내용과 히스토리 조회5강
5. 파일 제외.gitignore로 추적하지 않을 파일 설정6강
6. 브랜치 활용독립적인 작업 공간 생성과 전환7강
7. 병합두 브랜치의 작업을 합치기8강
8. 충돌 해결같은 파일을 동시 수정했을 때 처리 방법9강
9. GitHub 연동원격 저장소 생성과 로컬-원격 연결10강
10. 동기화push(올리기)와 pull(받기)11강
11. PR 협업Pull Request로 코드 리뷰와 병합 요청12강
12. 팀 협업여러 사람이 함께 쓰는 협업 워크플로13강
13. 이슈 관리이슈와 프로젝트 보드로 작업 추적14강
14. 되돌리기실수를 되돌리는 다양한 전략15강
15. 문서화README와 GitHub 마크다운 작성16강
16. 자동화GitHub Pages와 GitHub Actions 맛보기17강
17. 정리전체 복습과 다음 학습 방향18강

이 흐름에서 기억할 핵심 구조가 있습니다. Git 작업의 기본 사이클은 수정 → add → commit → push입니다. 파일을 수정하고, 변경된 파일을 스테이지에 올리고(add), 스냅샷으로 저장하고(commit), 원격 저장소에 올립니다(push). 이 사이클이 Git 사용의 90%를 차지합니다.

📝 핵심 요약

1강에서 배운 내용을 정리해 보겠습니다.

개념핵심 설명
버전 관리파일 변경 이력을 시간 순으로 기록·관리하는 시스템
커밋(Commit)특정 시점의 파일 상태 스냅샷 + 작성자·시간·메시지
Git로컬 버전 관리 소프트웨어 도구 (무료, 오픈소스)
GitHubGit 저장소 호스팅 + 협업 기능을 제공하는 웹 서비스
분산 VCS팀원 각자가 전체 히스토리 보유 → 오프라인 작업 가능

다음 강인 2강 — 설치와 초기 설정에서는 Git을 실제로 컴퓨터에 설치하고 사용자 이름·이메일 설정, 에디터 연결까지 완료합니다. 2강을 마치면 처음으로 Git 명령어를 직접 실행해볼 수 있습니다!

관련 주제

  • 버전 관리 개념
  • Git 동작 원리
  • Git과 GitHub 차이
  • 파일명 지옥
  • 실수 복구
  • 협업 워크플로 개요
  • 개발·프로그래밍
  • 개발·프로그래밍 강의
  • 깃허브 사용법 18강 — Git & GitHub 협업
  • 무료강의
  • 무료 온라인 강의
  • NUGUNA
  • 누구나

📚 시리즈 전체 공유

깃허브 사용법 18강 — Git & GitHub 협업

이 강의가 속한 시리즈는 총 7강, 모두 무료입니다. 처음부터 배우려는 동료에게 시리즈 전체를 알려 주세요.

댓글

0/1000

불러오는 중...