Git + Overleaf: LaTeX 프로젝트 버전관리·협업 워크플로

왜 Git과 Overleaf를 같이 쓰나

Overleaf는 브라우저에서 바로 편집·컴파일·리뷰가 가능해 공동저자(특히 개발 환경이 익숙하지 않은 구성원)와 협업하기 좋습니다. 반면 장기 보존, 변경 이력의 투명성, 태그 기반 릴리즈, 외부 도구(린터/CI/자동 빌드) 연동은 Git이 강합니다. 두 도구를 함께 쓰면 "작성은 Overleaf, 기록과 배포는 Git"처럼 역할을 분리해 운영할 수 있습니다.

오버리프 에디터 :

권장 운영 모델(단일 소스 오브 트루스 결정)

가장 먼저 "정본(source of truth)"을 정해야 충돌이 줄어듭니다. 보통은 Git을 정본으로 두고, Overleaf는 웹 편집과 빠른 리뷰를 위한 프론트엔드로 사용합니다. 즉, Git에서 브랜치/태그/릴리즈를 관리하고, Overleaf는 특정 브랜치(대개 main)와 동기화되도록 운용합니다.

반대로, 협업자가 대부분 Overleaf만 쓰고 Git 사용자가 소수라면 Overleaf를 정본으로 두고 Git은 백업·아카이빙·배포 자동화를 위한 미러로 둘 수도 있습니다. 이 경우에도 "누가, 언제, 어떤 방식으로 Git으로 내보내는지(Export/Sync 주기)"를 문서로 고정해 두는 것이 중요합니다.

프로젝트 초기 세팅(저장소 구조와 파일 규칙)

LaTeX 프로젝트는 텍스트 기반이라 Git 친화적이지만, 산출물(PDF, 로그)과 외부 바이너리(이미지)가 섞이기 쉽습니다. 저장소에는 소스만 남기고, 컴파일 산출물은 커밋하지 않는 규칙을 기본으로 둡니다. 그림 파일은 가능하면 벡터(PDF/SVG)나 원본(PNG)만 추적하고, 자동 생성되는 중간 산출물은 제외합니다.

여러 사람이 동시에 편집할 때 충돌을 줄이려면 메인 파일 한 개에 모든 내용을 몰아넣기보다 sections/, figures/, tables/처럼 파일을 쪼개는 편이 낫습니다. Overleaf에서도 input{}/include{} 기반 분할이 자연스럽게 동작하므로, "섹션 단위 소유권"을 정하기가 쉬워집니다.

Overleaf-Git 연결 방식(현실적인 동기화 흐름)

Overleaf는 프로젝트를 Git 저장소처럼 클론/푸시할 수 있는 방식(일명 Git bridge)으로 운영하는 것이 일반적입니다. 이때 권장 흐름은 "로컬에서 pull → 충돌 해결 → push → Overleaf에서 컴파일 확인" 순서로 단순화하는 것입니다. Overleaf 웹 편집을 병행한다면, 누가 언제 웹에서 대량 수정하는지(예: 초록/서론만 웹에서, 나머지는 PR로) 범위를 합의해 두면 충돌이 급감합니다.

동기화는 자주, 작게 하는 편이 안전합니다. Overleaf에서 대규모 리팩터링(파일 이동, 대량 rename)을 하고 곧바로 Git에서 별개로 수정이 들어가면 충돌 해결 비용이 크게 늘어납니다.

브랜치 전략(논문 작업에 맞춘 최소 규칙)

논문/보고서 작성은 "기능 개발"보다 "원고 흐름"이 중요하므로 복잡한 Git-flow보다 가벼운 규칙이 잘 맞습니다. 예를 들어 main은 항상 컴파일되는 상태로 유지하고, 각 저자는 sec-intro, rev-round1, fig-exp1처럼 작업 브랜치에서 수정한 뒤, main으로 합치는 방식을 씁니다.

제출 직전에는 submission/<venue>-<date> 같은 브랜치를 따서 포맷 고정(클래스 파일, 템플릿, 참고문헌 스타일)을 안정화하고, 카메라레디까지는 그 브랜치에서만 수정하는 방식이 흔히 안정적입니다. 최종 제출본은 Git 태그로 남겨 재현성과 추적성을 확보합니다.

충돌이 자주 나는 지점과 줄이는 방법

가장 흔한 충돌은 .bib 파일과 하나의 큰 .tex 파일에서 발생합니다. 참고문헌은 가능하면 "추가만" 하는 방향으로 운영하고, 정렬/정리(키 변경, 대량 포맷 변경)는 한 사람이 전담해 한 번에 처리하는 편이 좋습니다. 본문은 섹션 파일로 분리하고, 표/그림 캡션도 각 파일에 붙여두면 같은 줄을 동시에 건드릴 확률이 줄어듭니다.

Overleaf의 자동 포맷팅/자동 줄바꿈이 로컬 편집기 설정과 다르면 diff가 커질 수 있습니다. 팀 차원에서 줄바꿈 정책(예: 문장 단위 줄바꿈, 혹은 자동 줄바꿈 최소화)을 합의하고, 에디터 설정도 가능하면 맞춥니다.

리뷰와 변경 추적(Overleaf 코멘트 + Git PR의 역할 분담)

Overleaf의 강점은 PDF를 보면서 코멘트/리뷰를 남기기 쉽다는 점입니다. 반면 "어떤 변경이 왜 들어갔는지"를 논리적으로 묶어 기록하기엔 Git 커밋/PR이 유리합니다. 그래서 문장 다듬기나 공동저자 피드백 반영은 Overleaf 코멘트로 진행하고, 구조 변경(섹션 재배치, 수식 정의 변경, 파일 분할, 참고문헌 정리)처럼 영향 범위가 큰 작업은 Git PR로 리뷰하는 식으로 역할을 나누면 운영이 깔끔해집니다.

재현성과 장기 보존(논문 프로젝트에서 특히 중요한 부분)

웹 편집기는 편하지만, 수년 뒤에도 같은 결과물을 다시 빌드해야 하는 요구가 종종 생깁니다. Git에는 소스뿐 아니라 빌드 환경의 단서를 남겨두는 것이 좋습니다. 예를 들어 사용한 TeX 배포판/패키지(TeX Live 버전), 빌드 방법, 필요 폰트 등을 README에 적어두면 "왜 내 컴퓨터에서만 깨지나" 같은 문제가 크게 줄어듭니다.

민감한 초안/아이디어가 포함되는 경우, 클라우드 협업 도구 사용 정책(접근 권한, 링크 공유 금지, 내보내기 권한)을 팀 규정으로 명시해 두는 편이 안전합니다. Git에서도 비공개 저장소, 접근 권한 최소화, 외부 협업자 초대 절차를 미리 정해두면 운영 리스크가 낮아집니다.

자동화(선택): Git 기반 빌드/배포 파이프라인

원고가 길어질수록 "main은 항상 컴파일 가능"을 사람 손으로 지키기 어렵습니다. 여유가 있다면 Git에서 커밋/PR 시 LaTeX를 자동 컴파일하고 PDF 아티팩트를 생성하는 CI를 붙이면, 깨진 상태가 오래 방치되지 않습니다. 제출본 생성(압축 파일 구조 맞추기, supplementary 포함)도 스크립트화해 두면 마감 직전 실수를 줄일 수 있습니다.

팀에 바로 적용하는 최소 합의안

운영을 단단하게 만들려면 복잡한 규칙보다 "정본은 어디인가", "main은 항상 컴파일되는가", "제출본은 태그로 남기는가", ".bib/포맷 정리는 누가 전담하는가" 정도만 먼저 합의해도 효과가 큽니다. 그 위에 Overleaf의 즉시성(웹 편집/코멘트)과 Git의 추적성(커밋/브랜치/태그)을 겹치지 않게 배치하는 것이 핵심입니다.