논문 메모는 Obsidian에 있고 코드는 다른 폴더에 있다면, 몇 주 뒤에는 어떤 판단이 어느 구현으로 이어졌는지 찾기 어려워집니다. 저는 노트 앱과 코드 저장소를 따로 잘 쓰는 것보다 둘의 변경 시점을 함께 남기는 편이 더 중요하다고 판단했습니다. 그래서 Obsidian 보관함을 Git 저장소 안에 두되, 데이터와 모델 가중치는 제외하는 구조를 택했습니다. 이 글은 Git과 Obsidian을 처음 설치한 뒤 실제 로컬 워크스페이스까지 만드는 순서를 설명합니다.
Git과 Obsidian은 서로 다른 문제를 풉니다
Git은 파일의 변경 이력을 저장하는 버전 관리 도구입니다. “지금 파일”만 보관하는 백업과 달리, 언제 무엇이 바뀌었는지와 특정 시점으로 돌아갈 근거를 남깁니다. Obsidian은 Markdown 파일을 연결해 읽는 로컬 노트 앱이며, 보관함(vault)은 특별한 데이터베이스가 아니라 제 컴퓨터의 폴더입니다. 따라서 같은 Markdown을 Obsidian으로 읽고 Git으로 이력을 남길 수 있습니다.
workspace/ ├─ README.md ← 처음 읽는 안내 ├─ research-notes/ ← Obsidian 보관함 ├─ sim/ ← 시뮬레이션 코드 ├─ training/ ← 학습 코드 ├─ data/ ← Git에서 제외 ├─ models/ ← Git에서 제외 └─ .gitignore ← 추적하지 않을 경계
1. Git을 설치하고 이름을 설정했습니다
Windows에서는 Git for Windows 공식 설치 파일을 사용했습니다. 여러 선택지가 나오지만 처음에는 기본값을 유지하고, 설치 뒤 터미널에서 버전이 출력되는지를 확인했습니다. 설치 화면의 옵션을 외우는 것보다 실제 명령이 실행되는지를 먼저 보는 편이 오류를 줄였습니다. 작성자 이름과 이메일은 커밋 기록에 남으므로 공개 저장소에 사용할 정보인지 생각한 뒤 설정해야 합니다.
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"2. Obsidian은 기존 폴더를 보관함으로 열었습니다
Obsidian 공식 설치 안내에서 Windows 설치 파일을 내려받고 실행했습니다. 새 노트만 따로 만들기보다 연구 자료가 들어갈 research-notes 폴더를 먼저 만든 뒤, Obsidian의 “Open folder as vault”로 그 폴더를 열었습니다. 보관함이 평범한 폴더라는 구조를 유지하면 다른 편집기와 Git도 같은 파일을 읽을 수 있습니다. Obsidian 전용 설정은 .obsidian에 생기므로, 팀이나 두 PC에서 공유할 설정과 개인 화면 배치를 구분할 필요가 있었습니다.
3. 새 저장소를 만들거나 기존 저장소를 복제했습니다
처음부터 만드는 폴더라면 git init, 이미 원격 저장소가 있다면 git clone을 사용합니다. 두 방법을 동시에 쓸 이유는 없습니다. 저는 여러 컴퓨터에서 같은 구조를 이어 써야 했기 때문에 원격 저장소를 만들고 복제하는 방식을 골랐습니다. Git의 공식 설명도 새 저장소 초기화와 기존 저장소 복제를 별도 출발점으로 구분합니다.
아래의 <repository-url>은 자신이 접근할 수 있는 원격 저장소 주소로, <repository-folder>는 복제 후 만들어진 폴더 이름으로 바꿉니다. 꺾쇠괄호는 설명을 위한 표시이므로 실제 명령에는 포함하지 않습니다. 새 저장소 초기화와 기존 저장소 복제 중 자신의 상황에 맞는 한 경로를 선택하세요.
# 새 폴더에서 시작
mkdir workspace
cd workspace
git init
# 또는 기존 원격 저장소를 가져오기
git clone <repository-url>
cd <repository-folder>4. 무엇을 남기지 않을지 먼저 정했습니다
로봇 프로젝트의 데이터와 모델 가중치는 크고, API 키와 로컬 설정에는 민감한 정보가 들어갈 수 있습니다. 모든 것을 Git에 넣으면 저장소가 무거워질 뿐 아니라 공개하면 안 되는 파일까지 올라갈 수 있습니다. 그래서 코드와 Markdown 노트는 추적하되 대용량 산출물, 비밀번호 파일, 개인 UI 상태는 .gitignore로 제외했습니다. 비공개 저장소라도 비밀키를 커밋하지 않는 원칙은 바뀌지 않습니다.
# .gitignore 예시
data/
models/
.env
*.log
.obsidian/workspace.json5. 첫 커밋은 작은 구조만 담았습니다
처음부터 논문과 코드를 모두 옮기면 빠진 민감 파일을 확인하기 어렵습니다. 그래서 README, 빈 폴더를 설명하는 문서, .gitignore만 먼저 준비하고 상태를 확인했습니다. Git의 기본 흐름은 수정된 파일을 선택해 스테이징하고, 그 묶음에 설명을 붙여 커밋하는 과정입니다. modified → staged → committed라는 세 상태를 이해하면 “저장했는데 왜 Git에는 안 보이지?”라는 혼란이 줄어듭니다.
git status
git add README.md .gitignore research-notes
git diff --staged
git commit -m "Initialize local research workspace"
git pushgit add .는 편하지만 처음에는 무엇이 들어가는지 감추기 때문에 파일을 지정했습니다. 커밋 전 git diff --staged로 실제 업로드 후보를 읽고, 예상하지 못한 데이터와 계정 정보가 없는지 확인했습니다. 첫 커밋이 작으니 문제가 생겨도 원인을 찾기 쉬웠습니다. 이후에도 하나의 판단이나 기능이 설명 가능한 크기가 되었을 때 커밋하는 기준을 유지했습니다.
두 컴퓨터에서 이어 쓸 때의 규칙
Git은 자동 동기화 앱이 아니므로 한 컴퓨터에서 커밋만 하고 푸시하지 않으면 다른 컴퓨터에 나타나지 않습니다. 작업을 시작할 때 git pull, 끝낼 때 상태 확인·커밋·git push를 한 묶음으로 정했습니다. 동시에 같은 문단을 고치면 충돌이 생길 수 있으므로, 환경을 옮기기 전에는 다음에 할 일과 미완료 사항을 짧게 남겼습니다. 이 규칙 덕분에 노트북과 데스크톱이 서로 다른 기억을 가진 상태로 갈라지는 일을 줄일 수 있었습니다.
설정이 끝났다고 판단한 기준
- Obsidian에서
research-notes폴더의 Markdown을 읽고 수정할 수 있습니다. git status에서 수정한 노트가 보입니다.- 데이터·모델·비밀 파일은 추적 대상에 나타나지 않습니다.
- 다른 PC에서 clone 또는 pull한 뒤 같은 노트를 열 수 있습니다.
오늘의 결론은 Git과 Obsidian을 연결하는 특별한 플러그인이 핵심이 아니라는 점입니다. 같은 로컬 파일을 Obsidian은 지식으로 읽고 Git은 시간의 변화로 기록합니다. 도구별 역할과 “정본”을 더 자세히 나누고 싶다면 기존의 Obsidian, Git, Claude, Codex를 쓸 때 기록의 정본을 나누는 글을 함께 참고할 수 있습니다. 다음 글에서는 이 폴더를 Claude Code와 Codex가 같은 프로젝트로 읽게 만드는 방법을 다룹니다.