저는 지난 몇 달 동안 PostgreSQL, Sidekiq 및 여러 데이터 처리 모듈로 구축된 Bitcoin 분석 Rails 애플리케이션인 Tansa를 개발해 왔습니다.

이 애플리케이션은 상당 부분 AI의 도움을 받아 개발되었습니다. 저는 필요 사항, 아키텍처, 모듈 책임 및 유효성 검사 규칙을 정의합니다. AI는 제가 코드를 분석하고 생성하는 데 도움을 줍니다.

시간이 흐르면서 Git 저장소는 이해하기 어려워졌습니다. 많은 커밋, 여러 브랜치, 연속적인 수정 사항, 그리고 기록을 재구축하거나 정리하려는 다양한 개입들이 있었습니다.

그래서 저희는 저장소를 정리하는 작업을 시작했습니다.

기술적으로 볼 때, 이 작업은 통제되고 있는 것처럼 보였습니다. Git 참조가 식별되었고, 백업 브랜치가 생성되었으며, 기록은 더 깨끗해 보이는 것 같았습니다.

하지만 애플리케이션을 다시 실행했을 때 충격을 받았습니다. 저는 그 애플리케이션이 예전과 다르다는 것을 느꼈습니다.

제가 개발했다고 알고 있던 요소들이 기준 버전에는 존재하지 않았습니다. 애플리케이션의 일부 부분은 더 오래된 상태로 돌아간 것처럼 보였습니다. 저장소는 Git 관점에서는 깨끗해 보였지만, 제가 구축했던 애플리케이션을 제대로 나타내지 못했습니다.

이때 저는 본질적인 차이점을 깨달았습니다:

깨끗한 Git 저장소가 곧 올바른 버전의 애플리케이션을 가지고 있다는 것을 의미하지 않는다.

우리는 주로 브랜치, 커밋 및 기록이라는 측면에서만 생각했습니다. 우리는 훨씬 더 간단한 질문부터 시작할 필요가 있었습니다:

애플리케이션의 어떤 정확한 상태를 기능적 진실(functional truth)로 보존해야 하는가?

Git에 대한 중요한 작업을 수행하기 전에, 구체적인 목록을 작성하는 것이 필요했을 것입니다:

• 현재 어떤 기능들이 존재하는지;
• 어떤 페이지들이 존재해야 하는지;
• 어떤 마이그레이션(migrations)이 적용되었는지;
• 실제로 사용되는 서비스와 작업(jobs)은 무엇인지;
• 아직 제대로 기록되지 않은 수정된 파일들은 어떤 것들인지;
• 마지막으로 알려진 기능적 상태에 실제로 해당하는 커밋(commit)은 무엇인지;
• 작업 후 애플리케이션을 어떻게 검증할 수 있는지.

테스트는 필수적이지만, 항상 모든 이야기를 들려주는 것은 아닙니다. 테스트 스위트가 성공하더라도, 최근 추가된 기능, 인터페이스 또는 기대되는 작업의 일부가 메인 브랜치에서 사라졌을 수 있습니다.

복구 과정에서는 속도를 늦추고 저장소를 사방으로 계속 수정하지 않도록 주의해야 했습니다. 사용 가능한 다양한 상태들을 보존하고, 브랜치와 커밋들을 비교하며, 차이점을 검토한 다음, 어떤 것이 실제로 애플리케이션의 올바른 버전에 속하는지 점진적으로 식별해야 했습니다.

저는 이 경험을 통해 앞으로 적용할 몇 가지 규칙을 얻었습니다:

1. 모든 Git 정리 작업 전에 보호해야 할 기능적 상태를 명시적으로 식별합니다.
2. 중요한 작업을 수행하기 전에 백업 브랜치와 태그(tag)를 생성합니다.
3. 복구된 애플리케이션이 검증될 때까지는 어떤 참조(reference)도 삭제하지 않습니다.
4. 파일을 비교할 뿐만 아니라, 애플리케이션을 실행하고 주요 기능을 제어합니다.
5. AI가 개입할 때는 명시적인 인간의 검증 없이 파괴적인 Git 작업을 금지합니다.
6. 여러 에이전트(agents)가 프로젝트에서 작업할 경우, Git 작업에 대한 단일 책임자를 지정합니다.
7. 실행된 명령어와 각 결정의 이유를 기록으로 남깁니다.
8. '더 깨끗한 히스토리(history)'와 '제대로 보존된 애플리케이션'을 혼동하지 않습니다.

AI는 개발 속도를 엄청나게 높여주지만, 잘못 정의된 Git 결정도 매우 빠르게 실행할 수 있습니다. 시작 지침이 잘못되었다면, 그것은 나쁜 상태를 더 똑똑하게 파괴하는 것이 아니라, 단순히 더 빠르고 대규모로 수행합니다.

이 경험을 통해 저는 Git이 단지 코드를 기록하는 도구에 불과하지 않다는 것을 깨달았습니다. 중요한 애플리케이션에서 Git은 프로젝트의 기억(memory) 그 자체입니다. 그리고 잘못 이해된 기억은 기술적으로는 일관성이 있지만, 역사적으로는 틀린 버전을 만들어낼 수 있습니다.

저는 현재 여러 AI 에이전트가 도움을 주는 개발에 적합한 Git 방법을 공식화하는 작업을 진행하고 있습니다.

혹시 저장소(repository)가 깨끗해 보였지만, 메인 브랜치(main branch)가 실제 애플리케이션의 진정한 상태를 더 이상 나타내지 않았던 상황을 경험하신 적이 있나요? 클린업(cleanup), 리베이스(rebase) 또는 히스토리 재구축 전에 어떤 보호 장치를 사용하시나요?