개발 일지 & 회고록 / 開発日誌 & レトロスペクティブ#

먼저.. / まずは..#

이번 글은 Unity 프로젝트에서 Git Hooks를 도입하며 공부한 내용과 회고를 정리한 개발 일지입니다.
今回は UnityプロジェクトにGit Hooksを導入し、学習・適用した内容をまとめた開発日誌です。

개발을 진행하면서

“왜 이 문제는 항상 커밋 이후에 발견될까?”
라는 고민이 계속 쌓이던 시점에 해당 글을 접하게 되었습니다.

특히 Unity 특성상

• 메타 파일 누락
• 코드 스타일 불일치
• 자동 포맷 미적용
• 커밋 이후에 터지는 에러

이런 문제들이 반복되었고,
사람의 주의력에 의존하는 방식의 한계를 느끼게 되었습니다.

도입 배경 / 導入背景#

• 팀원마다 다른 개발 습관
  チームメンバーごとに異なる開発習慣
• 커밋 이후 발견되는 포맷/규칙 오류
  コミット後に発覚するフォーマット・ルールエラー
• Unity 프로젝트 특성상 실수 비용이 큼
  Unityプロジェクト特有のミスコストの大きさ

결론적으로

“문제는 사람을 믿지 말고, 도구로 막자”
라는 판단에 도달했습니다.

Git Hooks란? / Git Hooksとは？#

• Git에서 특정 이벤트 시 자동 실행되는 스크립트
  Gitの特定イベント時に自動実行されるスクリプト
• 대표적으로 pre-commit, pre-push 등이 존재
  代表的に pre-commit, pre-push などが存在
• 커밋 이전에 강제 검증 가능
  コミット前に強制的な検証が可能

즉,

커밋 자체를 품질 게이트로 만드는 구조
コミット自体を品質ゲートにする仕組み

Unity + Git Hooks 적용 / Unity × Git Hooks 適用#

EditorConfig 연동 / EditorConfig 連携#

• 코드 스타일을 룰로 고정
  コードスタイルをルール化
• 개인 취향 배제
  個人の好みを排除
• 리뷰 비용 감소
  レビューコスト削減

특히 Unity C# 코드에서

• 줄바꿈
• 공백
• 네이밍

같은 사소하지만 누적되는 문제를
커밋 단계에서 차단할 수 있다는 점이 가장 컸습니다.

회고 / 回顧#

이번 Git Hooks 도입을 통해 느낀 가장 큰 점은

“팀 개발에서 자유는 방치가 아니라, 규칙 위에서의 자유다”

라는 사실이었습니다.

특히 Unity처럼

• 에디터 의존도가 높고
• 파일 구조가 민감한 환경에서는

사람보다 시스템을 먼저 믿는 구조가
장기적으로 팀을 살린다고 느꼈습니다.