개발자 취업을 준비한 한 비전공자의 GitHub 저장소를 검토한 적이 있습니다. README에는 팀 프로젝트에서 회원가입과 게시판, 상품 주문 기능을 구현했다고 적혀 있었지만 커밋 기록은 프로젝트를 마친 날 한 번에 올라온 최종 프로젝트 하나였습니다. 팀원이 담당한 기능과 본인이 작성한 코드도 구분되어 있지 않았고, 오류를 수정하거나 테스트한 과정 역시 확인하기 어려웠습니다. Git과 GitHub의 차이를 물었을 때는 둘 다 코드를 저장하는 프로그램이라고 답했습니다. 프로젝트 폴더를 날짜별로 복사해 보관하다가 어떤 파일이 최신인지 혼동한 경험은 있었지만, Git을 이용해 변경 이력을 관리하거나 이전 상태로 돌아가 본 적은 없었습니다. GitHub도 취업할 때 코드를 올리는 사이트로만 이해하고 있었습니다.
이 사례에서 부족했던 것은 프로젝트의 규모가 아니었습니다. Git으로 코드의 변화를 기록하고 GitHub에서 작업 내용을 공유하는 과정을 경험하지 않아 개인 역할과 문제해결 방식이 남지 않은 것이 문제였습니다. Git은 내 컴퓨터에서 변경 이력을 관리하는 도구이고, GitHub는 저장소를 온라인에서 공유하며 협업할 수 있는 공간입니다. 두 개념을 구분하고 커밋과 브랜치, 코드 검토 과정을 제대로 활용해야 버전관리가 단순한 백업을 넘어 협업 경험과 포트폴리오의 근거로 바뀝니다.
Git 버전관리는 코드의 변화와 이유를 기록하는 과정입니다
- 프로젝트 폴더를 복사하는 것과 버전관리는 다릅니다
처음 개발을 공부하면 프로젝트 폴더를 프로젝트_최종, 프로젝트_최종수정, 프로젝트_진짜최종처럼 복사해 보관하기도 합니다. 파일을 잃지 않는 데는 도움이 될 수 있지만 어떤 기능이 언제 바뀌었고 왜 수정됐는지 확인하기는 어렵습니다. 여러 파일을 함께 변경했다면 이전 상태로 되돌릴 범위도 판단하기 어렵습니다.
Git은 프로젝트의 변경 이력을 기록하고 필요한 시점의 상태를 확인할 수 있게 해주는 분산 버전관리 도구입니다. 인터넷에 연결되지 않은 상태에서도 내 컴퓨터의 저장소에서 변경 내용을 기록하고 이전 상태와 비교할 수 있습니다. 변경 이력에는 누가 어떤 파일을 수정했는지뿐 아니라 커밋 메시지를 통해 수정 목적도 남길 수 있습니다.
- 커밋은 단순히 저장 버튼을 누르는 행위가 아닙니다. 하나의 기능 추가나 오류 수정처럼 의미 있는 변경 단위를 기록하고 다른 사람이 내용을 이해할 수 있도록 이유를 남기는 과정입니다.
- 변경 내용을 기록하기 전에는 어떤 파일이 수정됐는지 확인해야 합니다. 테스트용 값이나 불필요한 파일, 비밀번호와 인증 키가 함께 포함되지 않았는지도 점검해야 합니다.
- 이전 상태로 돌아가는 기능은 코드를 무조건 과거로 바꾸는 용도만이 아닙니다. 현재 코드와 이전 기록을 비교해 어느 변경 이후 문제가 생겼는지 추적하는 데도 활용할 수 있습니다.
- 입력 검증 코드가 사라진 프로젝트 사례
백엔드 개발을 준비한 지원자는 회원가입 기능에 이메일 형식과 비밀번호 길이를 확인하는 검증 로직을 추가했습니다. 이후 코드 구조를 정리하면서 여러 파일을 수정했는데 정상적으로 작동하던 입력 검증이 사라졌습니다. 별도의 폴더에 이전 프로젝트를 복사해 두었지만 어느 폴더의 코드에 검증 로직이 들어 있는지 기억하지 못했습니다.
처음에는 검증 기능을 처음부터 다시 작성하려고 했습니다. 그러나 Git 기록을 확인하면서 입력 검증을 추가한 시점과 코드 구조를 변경한 시점의 차이를 비교했습니다. 구조를 정리하는 과정에서 검증을 호출하던 부분이 빠졌다는 사실을 발견했습니다.
지원자는 이전 코드를 그대로 되돌리지 않고 누락된 호출 부분만 현재 구조에 맞게 다시 적용했습니다. 정상 회원가입과 잘못된 이메일, 짧은 비밀번호, 빈 입력을 각각 테스트했습니다. 이후 커밋도 회원가입 완성과 코드 정리처럼 넓게 작성하지 않고 입력 검증 추가, 검증 호출 누락 수정처럼 변경 목적이 드러나도록 남겼습니다.
- 결과 중심 설명: 회원가입 기능의 입력 검증 오류를 수정했습니다.
- 변경 과정이 보이는 설명: 입력 검증을 추가한 기록과 코드 구조를 변경한 기록을 비교해 누락된 부분을 찾았습니다.
- 문제해결이 담긴 설명: 구조를 정리한 뒤 이메일과 비밀번호 검증이 실행되지 않는 문제를 발견했습니다. 변경 이력을 비교해 검증 호출이 빠진 시점을 확인하고 현재 구조에 맞게 복원한 뒤 정상 입력과 예외 입력을 다시 테스트했습니다.
이 사례에서 Git은 코드를 저장한 도구가 아니라 문제의 발생 시점을 좁히고 수정 범위를 결정하는 근거로 활용됐습니다.
- 브랜치는 기능별 작업을 분리하는 데 활용합니다
브랜치는 현재 안정적인 코드에 바로 영향을 주지 않고 새로운 기능과 오류 수정을 별도의 흐름에서 진행할 수 있게 합니다. 회원가입과 결제, 검색 기능을 동시에 개발하는 팀이라면 각 작업을 분리하고 검토가 끝난 뒤 합칠 수 있습니다.
브랜치를 많이 만드는 것 자체가 협업 능력을 의미하지는 않습니다. 어떤 기준으로 나누고 언제 합칠 것인지 팀 안에서 정해야 합니다. 기능 개발과 긴급 오류 수정, 배포 준비처럼 목적에 따라 운영 방식이 달라질 수 있습니다.
- 새로운 기능을 작업할 때는 작업 목적이 드러나는 이름으로 분리합니다. 다른 팀원이 어떤 기능을 진행 중인지 이해할 수 있어야 합니다.
- 작업이 끝났다고 바로 합치지 말고 변경된 파일과 테스트 결과를 확인합니다. 관련 없는 수정이 함께 포함되지 않았는지도 살펴봐야 합니다.
- 충돌이 발생하면 한쪽 코드를 무조건 선택하지 않아야 합니다. 두 사람이 같은 부분을 왜 다르게 수정했는지 확인하고 최종 코드가 요구사항에 맞는지 다시 테스트해야 합니다.
- 커밋 개수보다 변경 단위와 메시지가 중요합니다
취업 준비생은 GitHub 활동을 많이 보이게 하려고 작은 수정도 지나치게 나누거나 의미 없는 커밋을 반복하기도 합니다. 반대로 프로젝트 전체를 완성한 뒤 최종본이라는 한 번의 기록으로 올리기도 합니다. 두 방식 모두 개발 과정을 이해하기 어렵게 만들 수 있습니다.
좋은 커밋은 변경 목적을 파악할 수 있는 범위로 구성됩니다. 회원가입 화면을 만들면서 입력 검증과 API 연동, 오류 안내를 모두 한 번에 처리했다면 작업 내용을 검토하기 어렵습니다. 기능을 구현한 순서와 테스트 가능한 단위에 맞춰 기록하는 편이 좋습니다.
메시지도 수정, 완료, 최종처럼 결과만 적지 않는 것이 좋습니다. 중복 요청 방지, 로그인 만료 처리, 잘못된 페이지 상태 초기화처럼 무엇이 달라졌는지를 나타내야 합니다. 세부 내용이 필요하다면 왜 변경했고 무엇을 확인했는지를 추가로 남길 수 있습니다.
Git 기록은 잔디를 채우기 위한 활동이 아니라 코드가 어떤 판단을 거쳐 현재 상태가 되었는지 보여주는 자료입니다.
GitHub 협업과 포트폴리오는 공유된 기록에서 차이가 납니다
- GitHub는 Git 저장소를 공유하는 온라인 공간입니다
GitHub는 Git으로 관리하는 저장소를 온라인에서 보관하고 다른 사람과 공유할 수 있는 서비스입니다. 로컬 저장소를 원격 저장소에 연결하면 여러 개발자가 각자의 변경 내용을 주고받을 수 있습니다. 이슈와 풀 리퀘스트, 코드 리뷰, 프로젝트 관리 기능도 활용할 수 있습니다.
Git이 없어도 GitHub 웹사이트에서 일부 파일을 올리고 수정할 수 있지만 변경 이력을 체계적으로 관리하며 협업하려면 두 역할을 함께 이해하는 것이 좋습니다. 반대로 Git은 GitHub 계정이나 인터넷 연결이 없어도 로컬에서 사용할 수 있습니다.
GitHub와 비슷한 원격 저장소 서비스도 존재합니다. 따라서 Git은 하나의 버전관리 기술이고 GitHub는 해당 저장소를 공유하고 협업하는 서비스 중 하나라고 구분하면 이해하기 쉽습니다.
- 메인 브랜치에 직접 올리면서 충돌한 팀 사례
팀 프로젝트에서 두 명의 개발자가 같은 게시글 수정 화면을 작업했습니다. 별도의 브랜치를 사용하지 않고 각자 메인 브랜치에 직접 변경 내용을 올렸기 때문에 한 사람이 수정한 입력 검증이 다른 사람의 화면 변경과 합쳐지는 과정에서 사라졌습니다.
처음에는 나중에 올린 코드가 최신이므로 그대로 사용하면 된다고 생각했습니다. 하지만 한 사람은 화면 배치를 수정했고 다른 사람은 저장 전 검증을 추가했기 때문에 어느 한쪽만 선택하면 필요한 기능이 빠졌습니다.
팀은 이후 기능별 브랜치에서 작업하고 변경 내용을 합치기 전에 풀 리퀘스트를 작성하기로 했습니다. 작업 목적과 주요 변경 파일, 테스트한 상황을 설명하고 다른 담당자가 코드를 검토했습니다. 충돌이 발생하면 두 변경의 의도를 확인하고 통합한 뒤 게시글 수정과 빈 입력, 서버 오류를 다시 테스트했습니다.
- 협업 사실만 담긴 설명: 팀원들과 GitHub를 이용해 프로젝트를 진행했습니다.
- 작업 방식이 보이는 설명: 기능별 브랜치를 사용하고 풀 리퀘스트에서 변경 내용과 테스트 결과를 공유했습니다.
- 협업 판단이 담긴 설명: 같은 화면을 수정하면서 입력 검증이 사라지는 충돌을 경험했습니다. 두 작업의 목적을 확인해 화면 변경과 검증 로직을 함께 반영하고, 이후에는 메인 브랜치에 직접 올리지 않고 코드 검토 후 합치는 기준을 마련했습니다.
GitHub를 사용했다는 사실보다 충돌이 발생했을 때 수정 의도를 조율하고 작업 방식을 개선한 경험이 협업 역량을 보여줍니다.
- 풀 리퀘스트는 코드만 합치는 요청이 아닙니다
풀 리퀘스트는 작업한 브랜치의 변경 내용을 다른 흐름에 반영해 달라고 요청하는 기능입니다. 어떤 문제를 해결했고 주요 변경 사항이 무엇인지, 검토할 부분과 테스트 결과가 무엇인지 설명할 수 있습니다.
팀원이 코드를 검토하면서 오류 가능성과 이해하기 어려운 부분, 더 단순한 구현 방법을 제안할 수 있습니다. 리뷰를 받은 사람은 무조건 의견을 적용하기보다 제안의 근거를 확인하고 반영 여부를 설명해야 합니다.
- 변경 목적에는 어떤 요구사항이나 오류를 해결했는지 적습니다. 구현 방법만 나열하지 말고 사용자와 서비스에 어떤 변화가 생기는지 보여주는 것이 좋습니다.
- 테스트 항목에는 정상 상황뿐 아니라 관련된 예외 상황을 포함합니다. 리뷰어가 같은 조건을 확인할 수 있도록 필요한 입력과 결과를 정리합니다.
- 검토가 끝난 뒤에는 합쳐진 코드가 정상적으로 실행되는지 다시 확인합니다. 각 브랜치에서는 작동했지만 함께 반영하면서 새로운 문제가 생길 수 있습니다.
- 커밋 기록이 한 번인 포트폴리오 사례
개인 프로젝트를 완성한 지원자는 취업 준비를 시작하면서 GitHub 저장소를 만들고 전체 코드를 한 번에 올렸습니다. README에는 프로젝트 기간이 두 달이라고 적혀 있었지만 변경 기록은 프로젝트 최종본이라는 한 건이었습니다.
면접 연습에서 가장 어려웠던 오류와 수정 과정을 질문받자 로그인 오류를 여러 번 해결했다고 답했지만 어떤 문제가 있었는지 기억하지 못했습니다. 프로젝트 진행 중에는 폴더를 복사해 보관했고 최종 결과만 원격 저장소에 올렸기 때문입니다.
이미 끝난 프로젝트의 기록을 실제 작업한 것처럼 새로 꾸미는 것은 적절하지 않습니다. 지원자는 기존 프로젝트를 다시 검토하면서 확인 가능한 오류와 개선점을 새 작업으로 진행했습니다. 로그인 만료 시 화면이 계속 유지되는 문제와 검색 조건이 바뀌어도 페이지 번호가 초기화되지 않는 문제를 각각 수정하고 테스트 결과를 기록했습니다.
- 기존 저장소는 완성된 코드만 보여주어 개발 과정과 개인의 판단을 확인하기 어려웠습니다.
- 보완 과정에서는 과거 작업을 허위로 재현하지 않고 현재 시점에서 발견한 문제와 수정 내용을 새로운 기록으로 남겼습니다.
- README에는 초기 결과물의 한계와 이후 개선한 기능, 테스트 범위를 구분했습니다. 면접에서도 언제 어떤 기준으로 보완했는지 솔직하게 설명할 수 있게 됐습니다.
포트폴리오에서 중요한 것은 커밋 수가 아니라 실제 작업 과정과 문제해결 기록의 신뢰성입니다.
- README와 저장소 구조가 포트폴리오의 입구가 됩니다
채용 담당자가 모든 코드를 처음부터 읽기는 어렵습니다. README에는 프로젝트의 목적과 핵심 기능, 개인 역할, 사용 기술의 적용 위치, 실행 방법, 대표 문제해결 경험을 정리해야 합니다.
팀 프로젝트라면 전체 서비스 소개와 자신의 담당 기능을 구분합니다. 기능별 화면만 보여주기보다 자신이 수정한 문제와 검증 결과를 연결해야 합니다. 저장소의 폴더 구조와 필요한 설정 방법도 다른 사람이 이해할 수 있도록 설명하는 것이 좋습니다.
- 프로젝트 소개에서는 어떤 사용자의 어떤 문제를 해결하려 했는지 간단히 설명합니다. 기능 이름만 나열하는 것보다 결과물의 목적을 먼저 보여주는 편이 좋습니다.
- 개인 역할에는 직접 구현한 기능과 협업한 범위를 구분합니다. 팀 전체 결과를 개인 성과처럼 표현하지 않아야 합니다.
- 기술스택에는 사용한 이유와 위치를 적습니다. 단순히 리액트와 스프링을 사용했다고 적기보다 상태관리와 인증, 데이터 처리 중 어디에 적용했는지 설명해야 합니다.
- 문제해결 사례에는 발생 조건과 원인 확인, 수정, 재검증을 포함합니다. 관련 커밋이나 풀 리퀘스트 기록과 연결되면 근거를 확인하기 쉽습니다.
Git은 도구이고 GitHub는 공유 공간이라는 차이를 활용해야 합니다
- 로컬과 원격 저장소의 역할을 구분해야 합니다
로컬 저장소는 내 컴퓨터에서 작업하고 변경 이력을 기록하는 공간입니다. 원격 저장소는 팀원과 코드를 공유하고 다른 환경에서도 가져올 수 있도록 온라인에 보관하는 공간입니다. 로컬에서 커밋했다고 자동으로 원격 저장소에 반영되는 것은 아닙니다.
반대로 원격 저장소에 다른 사람의 변경이 추가됐다고 내 컴퓨터의 코드가 자동으로 바뀌는 것도 아닙니다. 작업 전에 최신 변경을 확인하고 자신의 작업과 충돌하지 않는지 살펴봐야 합니다.
초보자는 코드가 GitHub에 올라갔으니 Git으로 저장했다거나 커밋했으니 팀원도 바로 볼 수 있다고 생각할 수 있습니다. 변경 기록을 만드는 단계와 원격으로 전송하는 단계를 구분하면 작업 흐름을 이해하기 쉬워집니다.
- 원격 저장소를 백업 공간으로만 사용하면 협업 기록이 약해집니다
GitHub는 코드가 사라지지 않게 보관하는 기능도 하지만 단순한 파일 저장소로만 사용하면 협업의 장점을 충분히 활용하기 어렵습니다. 작업 단위와 변경 목적, 검토 과정이 함께 남아야 팀원이 코드의 맥락을 이해할 수 있습니다.
파일을 웹사이트에 직접 끌어다 올리는 것만 반복하면 로컬의 변경 이력과 연결하기 어렵습니다. 여러 사람이 동시에 수정하는 프로젝트에서는 누가 어떤 목적의 변경을 올렸는지도 불분명해질 수 있습니다.
개인 프로젝트에서도 이슈를 이용해 다음 작업과 발견한 오류를 정리하고, 기능별 브랜치와 풀 리퀘스트로 스스로 변경 내용을 검토할 수 있습니다. 협업 인원이 없어도 문제를 계획하고 검증한 과정을 기록하는 연습이 됩니다.
- API 키가 저장소에 노출된 사례
날씨 정보를 보여주는 프로젝트를 만든 지원자는 외부 서비스의 API 키를 코드 파일에 직접 작성한 뒤 공개 저장소에 올렸습니다. 이후 해당 줄을 삭제하고 다시 올렸기 때문에 문제가 해결됐다고 생각했습니다.
하지만 최신 코드에서 삭제됐더라도 이전 커밋에는 값이 남아 있을 수 있습니다. 공개된 인증 정보는 다른 사람이 사용했을 가능성도 있기 때문에 파일만 지우는 것으로 끝내면 안 됩니다. 지원자는 기존 키를 즉시 폐기하고 새로운 키를 발급받았습니다.
새 키는 코드에 직접 작성하지 않고 실행 환경에서 불러오도록 변경했습니다. 비밀정보가 들어가는 설정 파일은 Git이 추적하지 않도록 제외하고, 저장소에는 필요한 항목의 이름만 담은 예시 설정 파일을 추가했습니다. 과거 기록에 남은 정보도 저장소 상태와 노출 범위를 확인해 정리했습니다.
- 삭제 중심 설명: 코드에 들어 있던 API 키를 발견해 파일에서 삭제했습니다.
- 위험 대응이 보이는 설명: 공개 저장소에 올라간 키는 과거 기록에 남을 수 있어 기존 키를 폐기하고 새로 발급했습니다.
- 재발 방지까지 담긴 설명: 비밀정보를 실행 환경에서 불러오도록 변경하고 설정 파일을 추적 대상에서 제외했습니다. 팀원이 필요한 항목을 알 수 있도록 값이 없는 예시 파일과 설정 방법을 README에 추가했습니다.
이 사례는 버전관리 기록이 편리한 만큼 잘못 올라간 정보도 기록에 남을 수 있다는 점을 보여줍니다.
- 취업에서는 도구 사용보다 작업 방식을 설명해야 합니다
면접에서 Git을 사용할 수 있는지 질문받았을 때 커밋과 푸시를 할 수 있다고만 답하면 실제 협업 경험을 판단하기 어렵습니다. 브랜치를 어떤 기준으로 나누었는지, 충돌이 발생했을 때 무엇을 확인했는지, 코드 검토에서 어떤 의견을 주고받았는지를 설명해야 합니다.
Git과 GitHub의 차이를 묻는 질문에는 Git이 로컬에서도 사용할 수 있는 버전관리 도구이고 GitHub는 저장소를 온라인에서 공유하고 협업할 수 있는 서비스라고 설명할 수 있습니다. 여기에 자신의 프로젝트에서 변경 이력을 이용해 오류 발생 시점을 찾거나 풀 리퀘스트로 작업 기준을 조정한 경험을 연결하면 좋습니다.
- 개념 중심 답변: Git은 버전관리 도구이고 GitHub는 Git 저장소를 공유하는 온라인 서비스입니다.
- 프로젝트 연결 답변: Git으로 기능별 변경 이력을 관리하고 GitHub의 브랜치와 풀 리퀘스트를 이용해 팀원의 코드를 검토했습니다.
- 경험까지 담긴 답변: 같은 화면을 수정하면서 입력 검증이 사라지는 충돌을 겪었습니다. 두 변경의 목적을 확인해 코드를 통합하고 이후에는 기능별 브랜치에서 작업한 뒤 테스트 결과를 공유하고 검토 후 합치는 기준을 마련했습니다.
도구의 기능을 나열하는 답변보다 실제로 어떤 문제를 해결하고 협업 방식을 개선했는지가 더 구체적인 근거가 됩니다.
- conclusion
Git과 GitHub는 함께 사용되지만 같은 역할을 하지 않습니다. Git은 내 컴퓨터에서 코드의 변경 이력을 기록하고 비교하며 필요한 시점으로 돌아갈 수 있게 하는 버전관리 도구입니다. GitHub는 Git 저장소를 온라인에서 공유하고 브랜치와 풀 리퀘스트, 코드 리뷰를 통해 협업할 수 있는 공간입니다.
현재 자신의 사용 방식은 다음 내용을 중심으로 점검할 수 있습니다.
- 커밋이 단순한 저장이나 최종본 기록에 머물지 않는지 확인해야 합니다. 기능 추가와 오류 수정처럼 의미 있는 단위로 나누고 무엇을 왜 변경했는지 이해할 수 있는 메시지를 남겨야 합니다.
- 팀 프로젝트에서는 메인 브랜치에 바로 변경을 올리기보다 기능별 작업과 검토 과정을 분리해야 합니다. 충돌이 생기면 한쪽 코드를 무조건 선택하지 말고 두 작업의 목적을 확인한 뒤 통합 결과를 다시 테스트해야 합니다.
- 공개 저장소에는 API 키와 비밀번호, 개인정보가 포함되지 않도록 점검해야 합니다. 이미 올라간 비밀정보는 파일만 삭제하지 말고 즉시 폐기한 뒤 새로운 값으로 교체하고 재발 방지 기준을 마련해야 합니다.
실제 포트폴리오를 검토하면 GitHub 링크는 있지만 커밋이 최종본 한 번 이거나 팀원이 만든 기능까지 자신의 역할처럼 보이는 경우가 있습니다. 커밋 수를 늘리는 것보다 기능 추가와 오류 수정, 검증 과정이 신뢰할 수 있는 기록으로 남아 있어야 합니다.
Git의 변경 이력은 문제 발생 시점을 추적하는 근거가 되고, GitHub의 풀 리퀘스트와 리뷰는 협업 방식을 보여주는 자료가 됩니다. README와 커밋, 이슈가 실제 프로젝트 경험과 연결되면 저장소는 단순한 코드 보관 공간에서 문제해결과 협업 역량을 확인할 수 있는 포트폴리오로 바뀝니다.
