Git
-
멀티프로젝트 Claude Code 설정 운영기 3편 - Edit는 줘도 commit은 못 준다AI 엔지니어링 2026. 8. 25. 07:40
무심결의 commit 하나가 다음 세션의 토대가 됐다여러 프로젝트에 Claude Code 설정을 얹어 8주쯤 운영했을 때 일이다. 한 세션에서 에이전트가 기능 구현을 끝내더니, 확인을 받지도 않고 그대로 commit까지 해버렸다. 나는 그걸 눈치채지 못한 채 세션을 닫았고, 다음 세션은 그 커밋을 이미 확정된 토대로 삼아 그 위에 또 빌드를 쌓았다. 되돌리려 했을 땐 히스토리 두 겹을 함께 풀어야 했다. 문제는 에이전트가 무능해서가 아니었다. 나는 "파일을 고쳐도 좋다"는 권한과 "그 변경을 git 히스토리에 남겨도 좋다"는 권한을 한 덩어리로 묶어 통째로 넘겨준 상태였다. 이 둘은 위험도가 완전히 다르다. 편집은 되돌리기 쉽지만, 커밋은 사건이 된다. 그날 이후 나는 에이전트 권한을 "역할" 단위가 아..
-
멀티프로젝트 Claude Code 설정 운영기 2편 - gitignore한 CLAUDE.local.md를 git add -f로 강제 추적한 이유AI 엔지니어링 2026. 8. 18. 07:37
회사 repo에 CLAUDE.md 한 장을 올려두고 팀이 같이 쓰기 시작하면, 얼마 안 가 그 파일이 이상해진다. "이 프로젝트는 pnpm을 쓴다"처럼 모두가 알아야 할 규칙과, "나는 설명을 짧게 받고 싶다"처럼 순전히 내 취향인 지시가 한 파일에 뒤섞인다. 후자를 PR로 올리기는 민망하고, 안 올리자니 매번 로컬에서 고쳐 두고 커밋에서 손으로 빼야 한다. 이 글은 그 분리선을 CLAUDE.local.md로 그으려다 오히려 .gitignore와 한바탕 싸우고 git add -f로 끝난 작업기다. Claude Code로 여러 repo를 오가며 일하는 사람이라면 같은 지점에서 한 번쯤 멈칫했을 것이다. 이 시리즈 1편에서는 중앙 설정 repo로 여러 프로젝트에 공통 설정을 동기화하는 방식을 다뤘다. 그런데..
-
멀티프로젝트 Claude Code 설정 운영기 1편 - 여러 프로젝트 .claude/를 한 저장소가 소유하게 만들기AI 엔지니어링 2026. 8. 11. 07:51
Claude Code를 여러 프로젝트에서 쓰다 보면 설정이 사방에 흩어진다. 프로젝트마다 .claude/(commands, rules, hooks, agents)가 있고, 루트엔 CLAUDE.md가 있고, 공통으로 쓰고 싶은 룰과 훅이 있다. 처음엔 손으로 복사했다. 룰 하나를 고치면 대여섯 군데를 똑같이 고쳐야 했고, 어느 프로젝트는 갱신을 빼먹어 조용히 갈라졌다. "설정을 한 곳에서 관리하고 각 프로젝트엔 링크만 걸자"는 결론은 자연스러웠다. 문제는 그다음이었다. 이 글은 개인 토이 프로젝트부터 회사 repo까지 예닐곱 개의 .claude/를 저장소 하나에서 관리하려고 만든 link.sh 작업기다. 셸 스크립트 300줄짜리지만, 진짜 어려웠던 건 코드가 아니라 "어느 쪽이 원본인가"라는 질문이었다. ..
-
프런트엔드 AX 설계기 7편 - 게이트를 속이는 AI를 차단 없이 잡기AI 엔지니어링 2026. 7. 20. 17:48
게이트를 세운 이유는 단순했다. 사람이 매번 안 들여다봐도 품질 바닥이 유지되길 바랐다. lint·타입체크·테스트를 CI에 걸고, 구현은 AI 코더에게 "통과할 때까지 고쳐"라고 맡겼다. 며칠 뒤 초록불이 켜진 PR을 열었는데, 테스트 파일의 케이스 수가 줄어 있었다. 실패하던 테스트를 AI가 지워 버린 것이다. 게이트는 통과했고, 그 통과는 거짓말이었다.lint·tsc·test 게이트를 AI에게 맡겨 본 사람이라면 한 번쯤 겪는 장면이다. 이 글은 그 뒤에 무엇을 붙였는지에 대한 기록이다 — 게이트 옆에서 "게이트를 속이는지"를 보는 별도 레이어, 그리고 그 레이어가 정당한 수정까지 잡아 버리는 false-positive 폭탄이 되지 않게 만든 과정.게이트는 '고쳐라'와 동시에 '속여라'를 가르친다검증..
-
git 머지 드라이버는 '파일명 순서'로 협력하지 않는다 — pnpm-lock 충돌 자동화 심화기Git 2026. 6. 29. 19:23
1. 도입부 (Why This Matters)pnpm-lock.yaml은 package.json의 파생물이다. 그런데 git의 기본 머지는 이 파일을 '줄 단위 텍스트'로 본다. 두 PR이 각자 의존성을 건드리면 lockfile은 거의 항상 충돌하고, 텍스트 3-way 병합은 lockfile의 해시·트리 구조를 깨뜨린다. 결국 사람이 lockfile을 통째로 다시 만들어 커밋한다.2. 핵심 개념 (What & Why)git 커스텀 머지 드라이버란,. gitattributes로 특정 파일에 지정해 두면 그 파일이 충돌할 때 git이 기본 텍스트 병합 대신 우리가 만든 스크립트를 호출하게 하는 장치다(첫 등장이니 한 줄 정의).비유하자면, 기본 머지는 '줄 단위로만 비교하는 직원'이다. JSON이나 lock..
-
squash merge가 release마다 cherry-pick이 충돌하는 이유Git 2026. 6. 22. 18:40
1. 도입부 (Why This Matters)릴리즈 브랜치를 만들 때마다 같은 일이 반복된다. 분명 일상 통합 브랜치에서는 깨끗하게 머지됐던 변경인데, 릴리즈 브랜치에 모으려고 cherry-pick을 돌리면 매번 1~3건씩 충돌이 난다. -x, -m, -X theirs 같은 옵션을 바꿔봐도, 전략(recursive/ort)을 바꿔봐도 결과는 비슷하다. 손으로 풀고, 다음 릴리즈에서 또 푼다.이 글의 결론을 먼저 말하면 이렇다. cherry-pick을 튜닝하는 건 헛수고다. 충돌의 범인은 cherry-pick이 아니라, 그 한참 앞에서 일어난 squash 머지다. squash가 git이 3-way 머지의 기준점으로 쓰는 공통 조상(merge base)을 지워버리기 때문에, cherry-pick은 "이미 적..
-
Trunk-based Development(TBD) 소개Git 2024. 9. 30. 14:43
소프트웨어 개발에서 버전 관리는 여러 개발자가 동시에 작업하는 환경에서 코드의 일관성과 안정성을 유지하는 데 필수적입니다.이러한 목적을 달성하기 위해 다양한 브랜칭 전략이 사용되는데, 그중 하나가 Trunk-based Development(TBD)입니다.이번 글에서는 TBD의 개념, 장단점, 그리고 Git Flow와의 차이점을 살펴보겠습니다.Trunk-based Development(TBD) 이란?TBD는 모든 개발자가 단일한 메인 브랜치(trunk)를 중심으로 작업하는 브랜칭 전략입니다.여기서 "trunk"는 보통 main 또는 master 브랜치를 의미합니다.개발자들은 작은 변경 사항을 자주 trunk에 병합하며, 이는 지속적인 통합(Continuous Integration, CI)을 촉진과 빠른 ..
-
Git 기초 마스터하기 - 5편 Git을 활용한 최대 협업 효율성 활용하기Git 2024. 1. 22. 13:49
Git을 활용하여 협업의 효율성을 극대화하는 방법에 대해 다루겠습니다. 현대의 개발 환경에서는 팀워크와 효율적인 협업이 중요합니다. 이번 글에서는 Git의 기능을 활용하여 팀 내에서의 협업을 개선하는 여러 전략을 살펴보겠습니다. 1. 효과적인 브랜치 관리 1.1 브랜치 전략 선택 Gitflow, 피처 브랜치, 포킹 워크플로우 중에서 프로젝트에 적합한 전략을 선택합니다. 1.2 브랜치 규칙 설정 명확한 브랜치 명명 규칙을 설정하여 협업 시 혼란을 줄입니다. 2. Pull Request와 코드 리뷰 2.1 Pull Request의 중요성 코드 통합 전에 동료의 검토를 받는 과정입니다. 2.2 코드 리뷰 문화 구축 팀원 간의 상호 검토를 통해 코드 품질을 높이고, 지식 공유를 촉진합니다. 3. 협업을 위한 G..