[바이브 코딩 초보자를 위한 Git 기초 완벽 가이드] 폴더 관리부터 init, add, commit의 진짜 의미와 로그 확인법까지

바이브코딩을 시작하고 프로젝트를 진행하다 보면 필연적으로 만나게 되는 도구가 바로 Git입니다. 단순히 코드를 백업하는 용도를 넘어, 수많은 변경 이력을 추적하고 언제든 과거로 되돌릴 수 있게 해주는 강력한 '타임머신'이자 '버전 관리 시스템'입니다. 하지만 터미널 창에 낯선 명령어들을 입력하다 보면, 내가 지금 컴퓨터 전체를 건드리고 있는 것은 아닌지, 방금 입력한 명령어로 저장이 완벽하게 끝난 것인지 막막해지는 순간이 찾아옵니다.

이 글에서는 초보자들이 가장 헷갈려하는 Git의 폴더별 관리 원리부터, 시작을 알리는 git init, 저장의 핵심 파이프라인인 git add와 git commit의 차이, 그리고 저장된 내역을 정확히 확인하는 git log 해석법까지, 파편화된 개념들을 하나의 흐름으로 연결해 완벽하게 이해할 수 있도록 상세히 안내합니다.

1. Git은 컴퓨터 전체를 감시할까? (폴더별 독립 관리의 비밀)

버전 관리를 처음 시작할 때 가장 먼저 드는 의문은 "Git을 설치하면 내 컴퓨터 안의 모든 파일이 자동으로 감시 대상이 되는 걸까?"입니다. 결론부터 말씀드리면 전혀 그렇지 않습니다. Git은 컴퓨터 전체를 하나의 시스템으로 묶어서 관리하는 것이 아니라, 철저하게 사용자가 지정한 '폴더(디렉토리)' 단위로 독립적인 관리를 수행하도록 설계되어 있습니다.

완벽하게 독립된 평행우주, 로컬 저장소(Repository)

예를 들어 바탕화면에 A_Project 폴더와 B_Project 폴더가 있다고 가정해 보겠습니다. A_Project 폴더 안에서 Git을 활성화하면, 그 폴더는 다른 폴더들과 완전히 단절된 독립적인 '저장소(Repository)'가 됩니다. A_Project 안에서 파일을 수백 번 지우고 과거로 돌아가는 등 온갖 실험을 하더라도, 바로 옆에 있는 B_Project 폴더에는 0.1%의 영향도 미치지 않습니다.

하위 폴더는 자동으로 추적의 그물망에 들어온다

특정 최상위 폴더에서 버전 관리를 시작하면, 사용자가 일일이 지정하지 않아도 그 안에 속해 있는 수많은 하위 폴더(예: images, css, scripts 등)와 파일들은 하나의 거대한 프로젝트 단위로 묶여 자동으로 추적됩니다. 즉, 최상단에서 한 번만 관리망을 펼치면 그 아래의 모든 생태계가 안전하게 보호받는 구조입니다.

🚨 치명적인 시스템 오류를 부르는 절대 금지 행동 2가지

폴더 단위로 관리된다는 특성 때문에 반드시 피해야 할 두 가지 금기 사항이 있습니다.

1. 드라이브 최상단(C:\ 또는 D:)에서 시작하기: 만약 내 컴퓨터의 C드라이브 최상위 경로에서 Git을 시작해 버리면 어떻게 될까요? 윈도우 시스템 파일, 수만 개의 임시 파일, 개인 사진 등 컴퓨터 안의 모든 파일이 추적 대상이 되어버립니다. 이로 인해 컴퓨터가 심각하게 느려지거나 엉뚱한 파일이 업로드되는 대참사가 발생합니다. 반드시 구체적인 작업 폴더를 하나 만들고, 그 폴더 안으로 진입한 뒤에 시작해야 합니다.
2. 이중 관리(Nested Git) 만들기: 이미 Git으로 관리 중인 폴더 내부의 하위 폴더로 들어가서 또다시 Git 관리를 시작하는 행위입니다. 이렇게 되면 상위 폴더의 관리 시스템과 하위 폴더의 관리 시스템이 충돌을 일으켜, 파일의 변경 이력이 제대로 저장되지 않거나 통째로 유실되는 복잡한 문제가 발생합니다. "하나의 프로젝트 = 하나의 폴더 = 단 한 번의 시작"이라는 공식을 반드시 기억해야 합니다.

2. 모든 것의 시작, git init의 진짜 의미

작업할 폴더를 정했다면 시스템에 "이제부터 이 폴더의 버전 관리를 시작해 줘!"라고 선언해야 합니다. 이때 사용하는 첫 번째 명령어가 바로 git init(Initialize의 약자)입니다.

git init은 정확히 어떤 작업을 수행할까?

터미널(명령 프롬프트)에서 해당 폴더로 이동한 뒤 git init을 입력하는 순간, 겉으로는 아무런 변화가 없어 보이지만 폴더 내부에는 .git이라는 이름의 '숨김 폴더'가 조용히 생성됩니다.

버전을 기억하는 블랙박스, .git 폴더

이 .git 폴더는 단순한 폴더가 아니라 Git 시스템의 심장이자 뇌 역할을 하는 핵심 데이터베이스입니다. 우리가 코드를 수정하고 저장할 때마다 발생하는 모든 변경 내역, 과거로 돌아가기 위한 스냅샷, 분기점(Branch) 정보 등이 모두 이 숨겨진 공간 안에 압축되어 암호화된 상태로 차곡차곡 보관됩니다. 만약 실수로 이 .git 폴더를 삭제해버리면, 파일의 현재 원본은 남아있더라도 과거의 모든 버전 기록은 영구히 날아가게 되므로 절대 건드려서는 안 됩니다.

프로젝트를 통틀어 단 한 번만 실행하세요

초보자들이 자주 헷갈리는 부분 중 하나는 컴퓨터를 껐다 켜거나 며칠 뒤에 작업을 다시 시작할 때마다 git init을 쳐야 하는지 묻는 것입니다. 정답은 '아니오'입니다. 한 번 .git 폴더가 생성되어 관리가 시작된 폴더는 그 사실을 영구적으로 기억합니다. 따라서 git init은 특정 프로젝트 폴더를 처음 만들었을 때 일생에 단 한 번만 실행하는 명령어입니다.

3. git add .를 하면 저장이 끝난 걸까? (장바구니와 사진기 비유)

파일을 열심히 수정한 뒤 터미널에 git add .를 입력하고 안도하는 경우가 많습니다. 하지만 이는 반쪽짜리 저장이며, 컴퓨터 전원이 꺼지면 작업 내역을 잃어버릴 수 있습니다. 완벽한 하나의 버전을 만들기 위해서는 add와 commit이라는 두 단계의 파이프라인을 정확히 이해해야 합니다.

1단계: 촬영 준비 완료, git add . (Staging Area)

파일의 코드를 수정했다고 해서 Git이 그것을 무작정 버전에 포함시키지는 않습니다. 에러가 난 코드나 아직 작업 중인 미완성 코드가 무분별하게 기록되는 것을 막기 위해서입니다.

git add . 명령어는 현재 폴더 내에서 변경되거나 새로 만들어진 모든 파일(.)을 긁어모아 '스테이징 에어리어(Staging Area)'라는 임시 대기열에 올리는 작업입니다. 일상생활에 비유하자면 다음과 같습니다.

• 장바구니 비유: 마트에서 물건을 골라 계산대에 올리기 전, 카트(장바구니)에 담아두는 행위입니다. 아직 결제가 끝난 것은 아닙니다.
• 사진기 비유: 단체 사진을 찍기 위해 흩어져 있던 사람들을 카메라 앵글(프레임) 안으로 모아 세우는 준비 과정입니다. 아직 셔터를 누르지는 않았습니다.

2단계: 영구 보관용 스냅샷 찰칵! git commit

장바구니에 파일들을 예쁘게 담아두었다면, 이제 결제를 하고 확정 지어야 합니다. 이때 사용하는 명령어가 바로 git commit -m "작업 내용 메모"입니다.

이 명령어를 실행하는 순간, 임시 대기열에 올라가 있던 파일들의 현재 상태가 마치 카메라 셔터가 터지듯 찰칵! 하고 사진(스냅샷)으로 찍힙니다. 그리고 -m 뒤에 남긴 메시지표와 함께 고유한 인식 번호를 부여받아 .git 폴더 깊숙한 곳에 영구적인 하나의 '버전'으로 굳어지게 됩니다. 결론적으로 git add는 저장할 녀석들을 '선택'하는 과정이고, git commit이 비로소 그것들을 '영구 저장'하는 핵심 마무리가 됩니다. 두 명령어는 언제나 바늘과 실처럼 세트로 움직여야 합니다.

4. 성공적으로 저장되었는지 확인하는 완벽한 검증법

저장을 마쳤다면 내가 작업한 내용이 꼬임 없이 깔끔하게 반영되었는지 눈으로 확인하는 습관을 들여야 합니다. 이때 두 가지 확인 명령어를 순서대로 사용합니다.

첫 번째 점검: 작업 공간의 청결도 확인 (git status)

방금까지 장바구니에 담아두었던 파일들이 성공적으로 영구 저장소로 넘어갔는지, 혹시 빼먹고 저장하지 않은 파일은 없는지 확인하는 가장 기본적인 명령어입니다. 터미널에 git status를 입력했을 때 다음과 같은 메시지가 나타나야 정상입니다.

nothing to commit, working tree clean

이 메시지는 "더 이상 새로 저장할 것이 없으며, 현재 당신의 작업 폴더는 아주 깨끗하게 잘 정돈되어 있습니다"라는 뜻입니다. 만약 붉은색이나 초록색 파일 이름이 남아있다면, 아직 add나 commit을 마무리하지 않은 파일이 있다는 신호이므로 추가 조치가 필요합니다.

두 번째 점검: 영구 사진첩 뒤적이기 (git log)

status로 깨끗한 상태를 확인했다면, 이제 실제로 앨범에 사진이 잘 꽂혔는지 과거 기록들을 조회해 볼 차례입니다. git log --oneline 명령어를 입력하면 과거부터 지금까지 저장해 온 모든 커밋(버전)들의 목록이 한 줄씩 깔끔하게 나타납니다.

5. 로그(Log)의 비밀: 화면에 출력된 목록은 항상 최신일까?

git log를 쳤을 때 터미널 창에 여러 줄의 기록이 나타나면, 초보자들은 어느 것이 가장 최신 버전인지 헷갈리곤 합니다. Git의 로그 출력 방식에는 명확한 규칙이 존재합니다.

최신순(역순) 정렬의 법칙

화면에 출력된 목록 중 가장 맨 위에 있는 줄이 무조건 가장 최근에 방금 저장한 '최신 버전'입니다. Git은 시간의 흐름을 역순으로 보여줍니다. 블로그 최신 글이 맨 위에 올라오는 것과 똑같은 이치입니다. 맨 윗줄부터 아래로 내려갈수록 과거로 거슬러 올라가는 형태입니다.

• 6c8cfcd (HEAD -> main) 유튜브 재생목록 기능 추가 (가장 방금 한 작업)
• 7b84e40 오타 수정 및 배경색 변경 (과거 작업)
• 9a1f2de 프로젝트 초기 세팅 (가장 오래된 최초 작업)

괄호 (...) 속 내비게이션 정보 해독하기

로그의 맨 윗줄을 자세히 보면 고유한 해시코드(예: 6c8cfcd) 바로 옆에 (HEAD -> main) 또는 (HEAD -> Agent0-update, tag: Agent0)와 같은 괄호 정보가 붙어있는 것을 볼 수 있습니다. 이것은 현재 나의 위치를 알려주는 매우 중요한 표지판입니다.

• HEAD: 현재 내 컴퓨터의 작업 디렉토리가 어느 버전을 바라보고 있는지를 나타내는 '현재 위치 포인터'입니다. HEAD ->가 가리키고 있는 곳이 곧 내가 지금 서 있는 시점입니다.
• 브랜치 이름 (예: main, Agent0-update): 현재 작업이 어느 평행우주(브랜치) 위에서 이루어지고 있는지를 보여줍니다.
• tag: 특정 커밋에 찾아보기 쉽도록 사용자가 직접 달아놓은 견출지(이름표)입니다.

즉, (HEAD -> main)이 맨 위 최신 기록에 붙어있다면 "당신은 현재 main 브랜치의 가장 최신 완성본 위에서 안전하게 작업하고 있습니다"라는 것을 시스템이 보증해 주는 것입니다.

결론: Git의 흐름을 지배하는 자가 코드를 지배한다

Git은 처음 접할 때는 외워야 할 명령어도 많고 그 철학을 이해하기 어려워 진입 장벽이 높은 것이 사실입니다. 하지만 이 글에서 다룬 핵심 흐름만 머릿속에 그릴 수 있다면 두려워할 것이 전혀 없습니다.

1. 독립된 폴더를 만들고 그 안으로 들어간다.
2. 일생에 단 한 번, git init으로 감시 카메라(블랙박스)를 설치한다.
3. 코드를 열심히 수정한 뒤, git add .로 변경된 파일들을 장바구니에 모은다.
4. git commit -m "메모"로 셔터를 눌러 영구적인 하나의 버전으로 확정 짓는다.
5. git status로 남은 것이 없는지 확인하고, git log의 맨 윗줄을 보며 안전하게 기록되었는지 확인한다.

이 짧은 파이프라인의 반복이 바로 전 세계 수백만 명의 개발자들이 매일같이 수행하는 버전 관리의 전부입니다. 명령어 이면에 숨겨진 원리와 의미를 정확히 이해하셨다면, 이제 어떤 복잡한 프로젝트라도 데이터를 잃어버릴 걱정 없이 안전하고 대담하게 코드를 작성해 나가실 수 있을 것입니다.