Git — 의사가 코드를 관리하는 법
한줄 요약
Git은 코드의 의무기록이다 — 누가, 언제, 무엇을, 왜 수정했는지 모두 남고, 언제든 이전으로 되돌릴 수 있다.
의사가 공감할 문제: “최종_최종2.docx”
연구실에 이런 파일이 없는 의사는 드물다.
당뇨분석_코드.py
당뇨분석_코드_수정.py
당뇨분석_코드_수정2.py
당뇨분석_코드_진짜최종.py
당뇨분석_코드_진짜최종_이게맞음.py코드가 갑자기 작동하지 않는다. 어제까지 됐는데. 어떤 파일이 “진짜” 최신인지, 무엇을 바꿨는지, 어디로 돌아가야 하는지 알 수 없다.
이 문제를 해결하는 것이 Git이다.
Git = 코드의 의무기록
의무기록 시스템과 Git을 비교하면 직관적으로 이해된다.
| 의무기록 | Git |
|---|---|
| 차트(환자 기록부) | Repository(저장소) |
| 진료 기록 한 건 | Commit(커밋) |
| 임시 처방 계획 | Branch(브랜치) |
| 최종 처방 확정 | Merge(병합) |
| 기록 날짜·서명 | Commit message + 작성자 정보 |
| 이전 기록 열람 | git log + git checkout |
의무기록이 환자의 상태 변화를 날짜순으로 추적하듯, Git은 코드의 변화를 날짜순으로 추적한다. 언제든 과거 시점의 상태로 돌아갈 수 있다.
핵심 개념 4가지
1. Repository (저장소)
프로젝트 전체를 담는 폴더다. Git이 초기화된 폴더는 모든 변경 이력을 내부의 .git 디렉터리에 저장한다. 환자 한 명의 “전체 차트”에 해당한다.
2. Commit (커밋)
“지금 이 상태를 기록한다”는 명령이다. 의무기록의 날짜·서명된 기록 한 건에 해당한다. 각 커밋에는 고유한 ID, 작성자, 날짜, 메시지가 함께 저장된다.
3. Branch (브랜치)
메인 코드를 건드리지 않고 실험적 변경을 시도하는 별도 공간이다. 주치의 처방은 그대로 두고, 주니어가 새로운 치료 계획을 별도로 작성하는 것과 같다. 실험이 성공하면 메인에 합친다.
4. Merge (병합)
브랜치에서 작업한 내용을 메인 코드에 통합하는 것이다. 임시 처방 계획이 최종 승인되어 공식 처방이 되는 과정이다.
기본 명령어 실습
처음 시작하는 의사라면 이 5개 명령어만 알아도 충분하다.
# 1. 새 프로젝트 시작 (차트 개설)
git init
# 2. 오늘 변경한 파일을 기록 준비 (진료 기록 작성)
git add 당뇨분석.py
# 3. 현재 상태를 저장하고 메시지 남기기 (서명·날인)
git commit -m "HbA1c 기준 분류 함수 추가"
# 4. GitHub(원격 저장소)에 백업 (병원 서버 저장)
git push origin main
# 5. 변경 이력 확인 (과거 기록 열람)
git log --oneline좋은 커밋 메시지 작성 원칙:
- 나쁜 예:
git commit -m "수정"— 무엇을 수정했는지 모름 - 좋은 예:
git commit -m "eGFR 30 미만 환자 신독성 약물 경고 로직 추가"
3개월 후 자신이, 또는 동료가 이 기록을 봤을 때 무슨 변경인지 바로 알 수 있어야 한다.
GitHub 계정 및 Private 저장소 설정
- github.com에서 계정 생성
- “New repository” 클릭
- 반드시 Private으로 설정 — 연구 데이터, 분석 코드는 공개하면 안 된다
- 로컬 폴더와 연결:
git remote add origin https://github.com/사용자명/프로젝트명.git
git push -u origin main이후 모든 커밋은 GitHub에 자동 백업된다. 컴퓨터가 망가져도 코드는 안전하다.
.gitignore: 절대 올려서는 안 되는 것들
.gitignore 파일에 나열된 파일과 폴더는 Git이 추적하지 않는다. 다음은 의사 연구자가 반드시 제외해야 할 항목들이다.
# API 키 — 절대 업로드 금지
.env
secrets.py
config.json
# 환자 데이터 — 개인정보보호법 위반 가능
data/
*.csv
patient_*.xlsx
# 대용량 파일
*.pkl
models/
# IDE 설정 파일
.vscode/
__pycache__/
*.pyc.env 파일에 OpenAI API 키를 저장해두고 실수로 GitHub에 업로드하면, 수 시간 내에 봇이 키를 탈취해 수백만 원의 과금이 발생할 수 있다. 이것은 실제로 흔히 발생하는 사고다.
실수 되돌리기
마지막 커밋을 취소하고 싶을 때
# 커밋은 취소하되 파일 변경은 유지
git reset --soft HEAD~1특정 파일을 이전 버전으로 되돌리고 싶을 때
# 해당 파일을 직전 커밋 상태로 복원
git checkout HEAD -- 당뇨분석.py잘못된 변경을 새 커밋으로 취소하고 싶을 때 (기록 유지)
# 이전 커밋의 반대 작업을 새 커밋으로 생성
git revert HEAD의무기록에서 “이전 기록 삭제”가 허용되지 않듯, Git에서도 공유된 이력을 강제로 삭제하는 것은 원칙적으로 피해야 한다. git revert는 삭제 없이 “정정 기록”을 남기는 방식이라 더 안전하다.
협업: 동료와 코드 공유
동료와 같은 저장소에서 작업할 때:
# 동료의 최신 변경 가져오기
git pull
# 내 변경 브랜치에서 작업 후 병합 요청 (Pull Request)
git checkout -b feature/혈압-분류-추가
git add .
git commit -m "수축기 혈압 3단계 분류 함수 추가"
git push origin feature/혈압-분류-추가이후 GitHub에서 Pull Request를 열면 동료가 코드를 리뷰하고 승인할 수 있다. 논문 공동저자가 초안을 검토하는 것과 같다.
왜 의사 연구자에게 Git이 필수인가: 재현 가능한 연구
재현 가능성(Reproducibility)은 과학의 근본 원칙이다. 다른 연구자가 같은 데이터와 코드로 같은 결과를 낼 수 있어야 논문이 신뢰받는다.
Git을 사용하면 논문 제출 시점의 정확한 코드 상태를 태그로 보존할 수 있다.
git tag -a v1.0 -m "NEJM 논문 제출 버전"심사자나 독자가 “이 결과를 어떻게 재현하나요?”라고 묻는다면, GitHub 링크 하나로 답할 수 있다.
핵심 정리
- Git은 코드의 의무기록으로, 모든 변경 이력을 날짜·작성자와 함께 추적한다
- “최종_최종2.py” 문제를 근본적으로 해결하며, 언제든 이전 상태로 복원할 수 있다
.gitignore로 API 키와 환자 데이터는 반드시 저장소에서 제외해야 한다- GitHub Private 저장소는 무료이며, 연구 코드의 기본 백업 수단으로 적극 활용해야 한다
- 재현 가능한 연구를 위해 논문 제출 버전을 Git 태그로 보존하는 습관이 중요하다