7장. VSCode Source Control — 바로 그 소스 컨트롤 패널

VSCode는 코드 편집기이면서 동시에 Git 클라이언트입니다. 코드 작성과 커밋을 한 화면에서 끝낼 수 있습니다.

2026년 5월 28일 목요일 밤 10시, 김진관 선생님은 야간 자율학습 감독 중이었습니다. 핸드폰으로 class-2b를 열어 내일 1교시 수능 모의고사 분석 자료를 확인했는데 표 안의 점수대 하나가 잘못 들어가 있었습니다. 학생 서른두 명이 아침 9시에 이 자료로 수업을 합니다. 교사 업무용 노트북은 교무실 책상 위에 놓아두고 왔습니다. 핸드폰으로는 코드 수정이 불가능합니다. 야자 감독실 공용 컴퓨터를 깨웠더니 GitHub Desktop은 설치되어 있지 않고 VSCode만 있었습니다. 저장소 폴더를 열고 파일을 고친 뒤, 왼쪽 사이드바에서 가지가 두 갈래로 갈라진 세 번째 아이콘을 눌렀습니다. 방금 수정한 파일이 그대로 올라와 있었습니다. 김진관 선생님은 그 자리에서 커밋하고 푸시했습니다. 새벽 1시가 되기 전에 집에 들어갔습니다.

이 챕터를 마치면 다음을 할 수 있습니다.

• VSCode에서 Source Control 패널을 열어 변경 파일 목록을 확인할 수 있습니다.
• 인라인 Diff 뷰어로 어느 줄이 바뀌었는지 빨간색·초록색으로 구분할 수 있습니다.
• VSCode만으로 스테이징·커밋·푸시까지 한 화면에서 마칠 수 있습니다.

(1) Source Control 패널 열기 — 책상 밑 공구 서랍 찾기

책상 밑에 이미 달려 있는 공구 서랍을 찾는 일과 같습니다. VSCode 왼쪽 사이드바에는 파일 탐색기 아이콘, 검색 아이콘 다음으로 세 번째에 Source Control 아이콘이 놓여 있습니다. 가지가 두 갈래로 갈라진 모양이라 한 번 보면 기억에 남습니다. 이 아이콘을 클릭하거나 Ctrl+Shift+G(Mac은 Cmd+Shift+G)를 누르면 Source Control 패널이 열립니다.

패널이 열리면 Changes 섹션에 방금 수정했지만 아직 커밋하지 않은 파일 목록이 줄지어 뜹니다. 파일명 오른쪽에 M(Modified, 수정됨), U(Untracked, 추적되지 않음), D(Deleted, 삭제됨) 같은 한 글자 표시가 붙습니다. 이 표시만 봐도 지금 저장소가 어떤 상태인지 짐작할 수 있습니다. 매번 터미널을 켜고 git status를 치지 않아도 됩니다.

지금 바로 실습해 보겠습니다. VSCode로 class-2b 폴더를 엽니다. 아무 파일 하나를 열어 한 줄 수정하고 저장합니다. 왼쪽 세 번째 아이콘을 클릭합니다. Changes 아래에 방금 수정한 파일명이 떴다면 Quick Win 성공입니다. 김진관 선생님이 야자 감독실에서 찾아낸 바로 그 화면입니다.

잘 안 되면? Changes 섹션이 비어 있거나 Initialize Repository 버튼만 보인다면 이 폴더가 아직 Git 저장소가 아닙니다. 4장에서 만든 저장소 폴더가 맞는지 확인합니다. Publish Branch 버튼이 보인다면 원격 저장소에 연결만 되어 있지 않다는 뜻이니 한 번 눌러 GitHub에 올립니다. 파일을 수정해도 Changes에 뜨지 않는다면 저장(Ctrl+S)이 되었는지 먼저 확인합니다.

(2) 인라인 Diff 뷰어 — 교정지의 빨간 펜·파란 펜

원고를 고칠 때 빨간 펜으로 삭제한 부분, 파란 펜으로 추가한 부분을 표시하는 교정지와 같습니다. Diff(디프)는 어느 줄을 지우고 어느 줄을 새로 썼는지 색으로 구분해 보여주는 화면입니다. 이 장치 덕분에 내가 무엇을 바꿨는지 한눈에 훑을 수 있습니다.

Changes 섹션에서 파일명을 한 번 클릭하면 화면 중앙에 Diff 뷰어가 열립니다. 왼쪽에는 이전 버전, 오른쪽에는 지금 수정한 버전이 나란히 뜹니다. 삭제된 줄은 빨간색 배경, 추가된 줄은 초록색 배경으로 칠해집니다. 같은 화면에 두 시점이 겹쳐 있으므로 스크롤 한 번으로 전체 변경 내역이 드러납니다. 야자 감독실 컴퓨터에서 김진관 선생님은 Diff 뷰어로 빨간 줄과 초록 줄을 먼저 확인한 뒤에야 커밋 버튼을 눌렀습니다. 엉뚱한 곳을 건드리지 않았는지 검산하는 단계입니다.

Claude로 바이브 코딩을 하는 경우 이 화면은 더 중요합니다. 한 번의 프롬프트로 파일 열 개가 한꺼번에 바뀌는 상황이 흔하기 때문입니다. 파일을 하나씩 클릭하며 초록 줄만 빠르게 스캔하면 AI가 추가한 문장이 모두 드러납니다. 붉은 줄에 중요한 내용이 섞여 있다면 그 커밋은 보류하면 됩니다. Diff 뷰어는 내 안전망입니다.

(3) VSCode에서 커밋하기 — 한 화면에서 네 단계로 끝내기

다시 Source Control 패널로 돌아갑니다. 커밋 절차는 (1) 스테이징 (2) 메시지 작성 (3) 커밋 (4) 푸시 네 단계입니다.

(1) 스테이징: Changes 섹션에서 파일 오른쪽 끝에 마우스를 올리면 작은 + 아이콘이 나타납니다. 이 +를 누르면 해당 파일이 위쪽 Staged Changes 섹션으로 이동합니다. 이번 커밋에 포함할 파일만 골라 담는 과정입니다. 모든 변경을 한꺼번에 올리고 싶다면 Changes 글자 옆의 +를 누릅니다.

(2) 메시지 작성: 패널 상단 입력창에 커밋 메시지를 적습니다. "모의고사 점수대 표 오류 수정"처럼 구체적으로 씁니다. "update"나 "fix" 같은 한 단어 메시지는 석 달 뒤의 내가 해독하지 못합니다.

(3) 커밋: 입력창 위의 체크(✓) 아이콘을 누르거나 Ctrl+Enter를 누릅니다. 커밋이 완료되면 Staged Changes 목록이 비워집니다.

(4) 푸시: 패널 하단에 Sync Changes 버튼이 나타납니다. 이 버튼을 누르면 로컬 커밋이 GitHub에 업로드됩니다. 구름 모양 아이콘 옆에 숫자가 떠 있다면 그만큼 아직 원격에 보내지 않은 커밋이 남아 있다는 뜻입니다. 김진관 선생님이 야자 감독실에서 마지막으로 누른 버튼이 바로 이 Sync Changes였습니다.

잘 안 되면? Sync Changes를 눌렀는데 "Please make sure you have the correct access rights" 메시지가 뜬다면 GitHub 로그인이 풀린 상태입니다. VSCode 왼쪽 아래 사람 모양 아이콘을 클릭해 GitHub 계정으로 다시 로그인합니다. 커밋은 되었는데 푸시가 안 된다면 네트워크를 먼저 확인합니다. 공용 컴퓨터에서는 회사·학교 와이파이가 GitHub 접속을 차단하는 경우도 있습니다.

(4) GitHub Desktop과 VSCode — 경쟁이 아니라 역할 분담

두 도구는 어느 하나를 버려야 하는 관계가 아닙니다. GitHub Desktop은 저장소 전체 흐름을 시각적으로 조망할 때, 여러 저장소를 오가며 상태를 점검할 때 빠릅니다. VSCode는 코드를 쓰면서 커밋까지 같은 창에서 해결하고 싶을 때 유리합니다. 김진관 선생님처럼 평소엔 GitHub Desktop을 쓰다가 야자 감독실 같은 비상 상황에는 VSCode 한 창으로 끝내는 방식이 현실적입니다. 공구 상자에 공구가 두 개 들어 있으면 좋지 하나만 있어야 할 이유는 없습니다.

핵심 3줄 요약

• VSCode 왼쪽 세 번째 아이콘 또는 Ctrl+Shift+G로 Source Control 패널을 엽니다.
• Diff 뷰어의 빨간 줄·초록 줄로 변경 내용을 한눈에 확인합니다.
• + → 메시지 입력 → ✓ → Sync Changes 네 단계로 커밋과 푸시가 끝납니다.

완료 체크리스트

• 나는 이제 VSCode에서 Source Control 패널을 열 수 있습니다.
• 나는 이제 Diff 뷰어로 변경된 줄을 구분할 수 있습니다.
• 나는 이제 VSCode만으로 커밋과 푸시를 마칠 수 있습니다.

다음 8장에서는 AI가 커밋 메시지까지 대신 써주는 방법과, 언제 커밋해야 하는지 세 가지 타이밍 원칙을 다룹니다.