코딩을 처음 배우기 시작할 때 가장 먼저 벽에 부딪히는 순간이 언제일까? 아마 내 컴퓨터에서 완벽하게 잘 돌아가던 코드가 다른 컴퓨터로 옮기기만 하면 이상하게 에러를 뿜어낼 때, 혹은 어제까지 멀쩡하던 코드를 수정하다가 어디를 고쳤는지 기억조차 나지 않아 밤을 새우게 될 때가 아닐까 싶다. 😅
개발을 업으로 삼든 취미로 하든 소스코드를 관리하는 일은 피할 수 없는 숙명이다. 특히 혼자서 코드를 짜는 게 아니라 여러 사람과 협업을 하거나, 집과 카페, 연구실을 오가며 여러 대의 기기로 작업을 이어가야 하는 상황이라면 이 Git과 GitHub라는 도구는 선택이 아니라 생존의 문제가 된다.
소스 코드 관리의 시작점, Git과 GitHub의 개념
소스 스토커라 불리는 Git의 역할과 로컬 저장소
<파란색줄>프로그램을 개발하다 보면 코드와 설명 문서, 설정 파일 등 실행에 필요한 소스들이 끊임없이 업데이트된다.파란색줄> 이 과정에서 어떤 코드가 추가되고 변경되고 삭제되었는지 그 변화들을 끈질기게 추적하고 기록해 주는 시스템이 바로 Git이다. 보통 "코드의 버전을 관리한다"고 표현하는데, 내 컴퓨터 내부의 특정 공간인 로컬 저장소(Local Repository, 줄여서 repo)를 지키며 소스의 변화를 감시한다는 의미에서 흔히 '소스 스토커'로 비유되기도 한다. 컴퓨터 내부에 존재하면서 나의 개발 소스들이 담긴 저장소를 지속적으로 바라보고 그 변화들의 버전을 차곡차곡 쌓아주는 프로그램이다. 이 로컬 저장소를 내 컴퓨터에서 본격적으로 활성화하는 명령어가 바로 git init이다. 터미널에 이 명령어를 치면 "Initialized empty Git repository"라는 메시지가 출력되며 해당 폴더가 깃에 의해 추적되는 상태가 된다. 정상적으로 초기화되면 폴더 내부에 `.git`이라는 숨김 폴더가 생성되는데, 이것이 바로 로컬 저장소의 모든 변화를 순차적으로 기록하는 핵심 이력 관리 창고다. 내가 무엇을 고쳤는지 이 폴더가 다 알고 있다는 뜻이다. 그런데 개발 역사를 조금 들여다보면 Git과 종종 비교되는 오래된 시스템이 하나 존재한다. 바로 SVN(Subversion)이다. SVN은 중앙집중형 버전 관리 시스템으로 모든 데이터가 중앙 서버에 저장되고 파일 경로 기반으로 변경 이력을 관리한다. 사용법이 비교적 단순하고 중앙 관리가 편하다는 장점이 있지만, 네트워크 연결이 끊기면 작업을 못 하고 브랜치와 병합 작업이 무겁고 까다롭다는 치명적인 단점이 있다. 반면 Git은 분산형 구조를 취해 로컬에서 모든 히스토리를 가지고 놀 수 있으니, 대규모 프로젝트와 협업 환경에서 Git이 대세가 된 것은 어쩌면 너무나 당연한 수순이라는 생각이 든다. 👀온라인 허브 GitHub와 나만의 코드 관리 필요성
컴퓨터 내부에만 머물러 있는 코드와 설정들을 온라인 상에서 자유롭게 쓸 수 있도록 지원해 주는 플랫폼이 바로 GitHub다. Git이라는 버전 관리 시스템이 온라인 허브 위로 올라갔다고 이해하면 아주 쉽다. GitHub는 다른 사람들과의 코드 공유와 협업을 원활하게 만들어줄 뿐만 아니라, 꼭 여럿이 쓰는 목적이 아니더라도 혼자서 개발하는 이들에게 강력한 무기가 되어준다. 집에서 연구실에서 카페에서 여러 작업환경을 오가며 일해야 하는 현대 개발자들에게 코드가 온라인에 저장되어 있다는 사실은 그 활용도를 몇 배로 키워준다. 하지만 이 편리한 도구를 쓰기 전에 반드시 짚고 넘어가야 할 보안의 실상이 있다. 최근 오픈소스 생태계는 수많은 의존성 패키지와 라이브러리 위에 지어올린 거대한 성과 같다. 문제는 내가 가져다 쓴 오픈소스 패키지에 알려진 보안 취약점(CVE)이 숨어있을 때 발생한다. NVD, OSV.dev, GitHub Advisory 같은 취약점 데이터베이스를 통합 조회하는 스캐너 도구들이 연구되는 이유도 여기에 있다. 내 코드만 잘 짜면 끝나는 게 아니라, 내가 가져다 쓴 외부 패키지의 버전까지 실시간으로 추적하고 관리해야 하는 시대인 것이다.🔥 오픈소스 세상의 무서운 이면, 취약점 관리를 외면하는 개발 문화
우리는 누구나 남이 만들어 둔 코드를 가져다 쓰며 개발 속도를 높인다. 하지만 그 의존성 파일 속에 어떤 시한폭탄이 숨어 있는지 들여다보려는 이는 드물다.
GitHub Advisory나 Dependabot 같은 경고 시스템이 존재함에도 불구하고 이를 꺼두거나 무시하는 관행은 결국 서비스 전체를 치명적인 보안 위협에 노출시키는 주범이다. 코드를 올리고 잔디를 심는 것만큼이나 내가 쓰는 라이브러리의 안전을 점검하는 일이 필수가 되어야 한다.
로컬 저장소 설정과 꼼꼼한 신원 확인의 기술
git config를 통한 user.name과 user.email 설정
원격 저장소를 만들고 로컬 환경에 Git을 설치했다면, 본격적으로 코드를 담을 그릇을 다듬어야 한다. 터미널에 `git config` 명령어를 치는 것은 단순한 초기 설정이 아니라 "내가 이 코드를 수정한 당사자요" 하고 세상에 증명하는 신원 확인 절차다. "같은 이름으로 해야 이후에 헷갈리지 않더라고요"라는 말처럼, 깃허브 프로필 이름과 로컬 설정 이름을 동일하게 맞춰주는 것이 정신 건강에 이롭다. 여기서 가장 주의 깊게 보아야 할 옵션이 바로 `--global`이다. "글로벌 옵션은 컴퓨터 안에 존재하는 모든 깃허브 리포지토리에 영향을 미치는 옵션입니다." 그렇기 때문에 여러 개의 깃허브 계정을 번갈아 쓰거나 여러 사람이 함께 사용하는 공용 서버 환경에서는 이 글로벌 설정을 무턱대고 건드렸다가는 끔찍한 혼란을 초래할 수 있다. 어찌 보면 굉장히 위험할 수 있는 상황을 이 옵션 하나가 만들어낼 수 있는 것이다. 다행히 Git은 로컬 설정의 우선순위를 더 높게 쳐준다. 특정 리포지토리에서 `--global` 없이 `git config`를 설정하면, 그 폴더 내부에서만 유효한 설정이 적용되어 글로벌 설정보다 우선시된다. 프로젝트별로 다른 계정을 써야 하는 현실적인 필요를 이 섬세한 우선순위 구조가 지탱해 주는 셈이다. `git config --list` 명령어로 현재 적용된 정보를 확인하고 `q`를 눌러 빠져나오는 습관은 실수를 줄여주는 소소하지만 확실한 팁이다.토큰 인증의 번거로움과 원격 저장소 연동의 실제
로컬에서 작성한 코드를 깃허브 서버로 밀어 올릴 때, 처음 터미널을 마주한 초보자들을 당황하게 만드는 복병이 있다. 바로 패스워드 입력란이다. 여기서 절대 헷갈리면 안 되는 점이 있는데, 이 비밀번호는 여러분의 깃허브 로그인 패스워드가 아니라는 사실이다. 깃허브 계정 세팅 속 디벨로퍼 세팅(Developer settings)으로 들어가 퍼스널 액세스 토큰(Personal Access Tokens, 클래식)을 발급받아야 한다. 토큰을 만들 때 만료일을 30일, 60일, 혹은 무기한으로 설정할 수 있는데 개인 프로젝트용이라면 유출되지 않는다는 전제하에 만료일 없이 쓰는 것도 편의상 나쁘지 않다. 다만 이 토큰 번호는 생성한 그 순간을 지나면 다시는 화면에 표시되지 않기 때문에 잊어버리면 재발급을 받는 귀찮음을 겪어야 한다. 나 같은 경우는 카카오톡 '나에게 보내기'나 별도의 메모장에 이 토큰을 안전하게 복사해 두고 쓴다.📊 보안과 편의 사이, 퍼스널 토큰 관리의 실상
비밀번호 대신 토큰을 요구하는 깃허브의 정책은 계정 탈취를 막기 위한 최소한의 안전장치다. 하지만 개발자 개인이 토큰을 카톡이나 메모장에 평문으로 저장해 두는 순간 보안의 성벽은 무너진다.
편리함 뒤에 숨은 보안 리스크를 직시하고, 환경 변수나 안전한 자격 증명 관리자를 사용하는 습관으로 나아가야 진정한 의미의 코드 관리가 완성된다.
add, commit, push로 이어지는 소스 동기화의 철학
구두 판매 회사의 비유로 이해하는 3단계 프로세스
코드를 깃허브로 보내는 과정을 머릿속에 쏙쏙 박히게 이해하려면 현실의 비유를 가져오는 것만큼 좋은 게 없다. 구두를 팔고 있는 회사가 새 시즌을 맞아 수많은 디자인 중 판매할 제품을 엄선하는 상황을 상상해 보자. 수많은 구두 샘플 중에서 이번에 확실히 매장에 선보일 제품들을 골라내는 작업이 필요하다. 제품이 골라졌다면 그 구두가 얼마인지, 어떤 소재로 만들어졌고 세탁은 어떻게 해야 하는지 상세한 설명서를 작성해 붙여야 한다. 그리고 준비가 끝난 상품을 전국 모든 매장에 동일하게 진열하여 동기화를 마친다. 이 일련의 흐름이 바로 Git의 핵심인 add, commit, push와 정확히 일치한다. 먼저 개발자가 수많은 코드 수정 사항 중 이번에 원격으로 보낼 가치가 있는 파일만 콕 집어 선택하는 과정이 git add [파일명]이다. 이 단계를 거쳐야 코드가 스테이징 영역이라는 대기실로 올라간다. 그 다음, 선택된 파일에 왜 이 수정을 가했는지 설명 문구를 붙여 확정 짓는 작업이 git commit -m "[메시지]"다. 마지막으로 로컬에서 단단히 여문 코드를 깃허브 원격 서버로 통째로 밀어 넣어 모든 환경을 일치시키는 대미가 바로 git push다. 이 세 단계의 논리적 흐름을 몸에 익히는 것이 Git 마스터가 되는 유일한 지름길이다.미래의 나를 살리는 Commit 메시지 작성법
커밋 메시지를 대충 적는 행위는 미래의 나에게 폭탄을 던지는 것과 같다. 당장은 내가 혼자 짜는 코드고 내가 볼 내용이니까 "수정", "11", "아오" 같은 성의 없는 메시지를 남기기 쉽다. 하지만 일주일만 지나도 내가 왜 이 코드를 이렇게 더럽게 짰는지 기억이 나지 않아 밤을 새우며 땅을 치고 후회하게 된다. 미래에 이 코드를 열어볼 불쌍한 나를 구원하기 위해 커밋 메시지는 구체적이고 명확해야 한다. 굳이 거창한 영어 규칙을 따를 필요는 없다. 조직의 룰이 없다면 나름대로의 일관된 말머리를 만들어 쓰는 연습부터 시작하면 된다. 새로운 기능이나 변수를 추가했을 때는 Add: [무엇을 왜 추가했는지], 기존 코드를 뜯어고쳤을 때는 Modify: [어떤 부분을 바꿨는지], 에러를 잡았을 때는 Fix: [어떤 문제를 해결했는지] 형태로 구조화하는 식이다.💭 기록이라는 행위가 주는 개발자의 자존감
코딩은 결국 글쓰기와 닮아 있다. 내가 무슨 생각을 하며 이 로직을 짰는지 코드는 말해주지 못하지만, 커밋 메시지는 그 당시의 치열했던 고민을 고스란히 담아낸다.
대충 적어 넘긴 메시지 속에서 길을 잃고 헤매던 수많은 밤들을 떠올려보면, 성실하게 남긴 기록 하나가 얼마나 값진 자산인지 깨닫게 된다. 내 손으로 쌓아 올린 커밋 히스토리는 단순한 잔디 파밍용이 아니라, 내가 걸어온 개발자의 발자취 그 자체다.
VS Code라는 날개를 달고 GUI로 Git 다루기
커맨드 라인의 벽을 허무는 VS Code의 실시간 시각화
"기본적으로 깃이라고 하는 게 커맨드 라인 상에서 작성을 하는 건데, 이게 사용자 친화적이지가 않아요." 처음에 터미널 창을 열고 시커먼 화면에 하얀 글씨로 명령어를 타이핑해야 하는 진입 장벽은 수많은 비전공자와 초보 코서들을 좌절시켜 왔다. 점 하나, 띄어쓰기 하나만 틀려도 빨간색 에러 폭탄이 떨어지니 겁을 먹는 게 당연하다. 다행히 우리에게는 만인의 연인인 VS Code(Visual Studio Code)가 있다. VS Code 내부에서 Git을 연동해 사용하면, 터미널의 공포에서 벗어나 직관적인 GUI(그래픽 사용자 인터페이스) 환경에서 모든 것을 처리할 수 있다. 파일의 수정, 추가, 삭제 상태가 색상과 기호로 실시간 시각화되어 눈앞에 펼쳐진다. 원격 서버에 이미 올라가 있는 파일을 수정하면 코드 줄 옆에 초록색 바가 생기고 파일 이름 옆에는 'M(Modify)' 마크가 뜬다. 반대로 새로운 파일을 만들고 내용을 채워 넣으면 파일명 자체가 초록색으로 변하며 'U(Untracked)' 마크가 반긴다. 이 직관적인 시각적 피드백 덕분에 내가 지금 어떤 파일을 건드렸고 어떤 상태로 방치하고 있는지 한눈에 파악할 수 있다. 세상을 다 가진 듯 편안해지는 순간이다. 😎버튼 클릭 몇 번으로 끝내는 Add, Commit, Push와 실무 팁
VS Code의 '소스 제어' 탭을 열어보면 터미널에서 길게 치던 명령어들이 아이콘과 버튼으로 탈바꿈해 있다. 변경된 파일 옆의 '+' 버튼을 누르면 그게 바로 add(스테이징)가 된다. 실수로 올렸다면 '-' 버튼을 눌러 가볍게 취소할 수도 있다. 메시지 입력창에 변경 이유를 꾹꾹 눌러 담고 '커밋' 버튼을 누르면 커밋이 완료되고, 상단 점 세 개(...) 메뉴를 눌러 '푸시'를 누르면 깃허브로 코드가 날아간다. 하지만 이 편리한 도구를 쓸 때도 뼈아픈 실수를 유발하는 함정이 하나 도사리고 있다. 바로 작업 경로 내 한글 사용 금지 원칙이다. 프로젝트 폴더 경로에 한글 이름이 포함되어 있으면 VS Code 내에서 Git 기능이 꼬이거나 아예 작동하지 않는 먹통 사태가 벌어지곤 한다. 이 지경이 되면 결국 다시 시커먼 터미널을 열고 수동으로 경로를 찾아 헤매야 하는 불상사가 생긴다.🔥 개발자의 영원한 적, 폴더 이름의 한글화
내 컴퓨터의 사용자 이름이나 프로젝트 폴더를 한글로 지어두고 편하게 쓰던 버릇은 개발 세계에 들어오는 순간 가장 먼저 고쳐야 할 악습이다. 윈도우 환경에서 경로에 섞인 한글은 Git과 VS Code 사이의 인코딩 충돌을 일으키며 원인 모를 에러를 유발한다.
편의를 위해 만든 한글 폴더가 결국 나를 괴롭히는 부메랑으로 돌아오는 셈이다.
📚 이 글이랑 같이 보면 좋은 글
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
기술은 결국 사람을 편하게 만들기 위해 존재하고, 버전 관리 역시 코드가 날아가는 공포에서 우리를 구원하기 위해 태어났다. 오늘 다룬 Git과 GitHub의 기초 체력을 단단히 다져둔다면, 내일 마주할 에러와 협업의 바다에서도 길을 잃지 않고 당당히 전진할 수 있을 것이다.
#Git #GitHub #개발공부 #코딩입문 #버전관리 #소스코드관리 #VSCode #프로그래밍 #개발자 #협업툴 #기초코딩 #깃허브사용법 #깃사용법 #개발꿀팁 #독학코딩 #입문개발자 #개발환경 #코드관리 #개발자도구 #깃공부 #IT지식 #프로그래밍학습 #개발기초 #커밋 #푸시 #저장소 #원격저장소 #GUI #생산성 #개발일기
0 댓글