AI가 코드를 작성한다면 세션도 커밋의 일부가 되어야 할까?

• git-memento는 AI가 생성한 코드 세션을 Git 커밋에 자동으로 기록하는 확장 도구로, 각 커밋에 대응하는 AI 대화 내역을 git notes로 저장함
• 커밋 시 AI 세션 ID를 지정하면, 요약본은 refs/notes/commits, 전체 대화는 refs/notes/memento-full-audit 에 분리 저장되어 추적성과 프라이버시를 동시에 확보함
• Codex와 Claude 등 다양한 AI 제공자를 지원하며, 요약 생성 시 사용자 정의 스킬을 적용해 커밋 노트의 품질을 제어할 수 있음
• GitHub Actions와 통합되어, 커밋 노트 자동 코멘트, CI 게이트 검증, 병합 시 노트 자동 이관(merge-carry) 기능을 제공함
• 윈도우/맥/리눅스 지원. AI 코드 생성의 투명성을 높이고, 협업 환경에서 AI 기여 내역의 감사(audit) 가능성을 확보하는 도구

---

git-memento 개요

• git-memento는 AI 코딩 세션을 커밋 단위로 기록하는 Git 확장 도구
  • 커밋 시 AI 세션의 대화 내용을 정리해 마크다운 노트로 저장
  • 각 커밋에 AI 세션의 출처와 대화 맥락을 남겨 코드 생성 과정을 추적 가능
• 기본적으로 Codex를 지원하며, Claude 등 다른 AI 모델도 설정 가능
• MIT 라이선스로 공개되어 있으며, NativeAOT 기반 단일 실행 파일로 배포

주요 명령어 및 기능

• git memento init으로 저장소별 설정을 초기화하고, AI 제공자 정보를 .git/config에 저장
• git memento commit 명령으로 커밋과 동시에 세션 노트를 추가
  • --summary-skill 옵션을 사용하면 요약본과 전체 세션을 분리 저장
  • 요약본은 refs/notes/commits, 전체 로그는 refs/notes/memento-full-audit에 기록
• git memento amend는 기존 커밋에 새로운 세션을 추가하거나 수정 가능
• git memento audit은 커밋 범위 내 노트 누락 여부와 메타데이터 유효성을 검사
• git memento doctor는 설정, 노트 참조, 원격 동기화 상태를 점검

노트 관리 및 동기화

• git memento share-notes로 원격 저장소(origin 등)에 노트를 푸시
• git memento notes-sync는 원격 노트를 안전하게 병합하고 백업 생성
  • refs/notes/commits와 refs/notes/memento-full-audit 모두 동기화
• git memento notes-carry는 리베이스나 스쿼시 후 새 커밋으로 노트를 이관
• git memento notes-rewrite-setup은 자동 노트 이관 설정을 활성화

GitHub Actions 통합

• 저장소에는 재사용 가능한 GitHub Action이 포함되어 있음
  • mode: comment — 커밋 노트를 읽어 자동 코멘트 작성
  • mode: gate — CI 단계에서 노트 누락 여부 검사, 실패 시 빌드 차단
  • mode: merge-carry — PR 병합 시 노트를 병합 커밋으로 이관
• 각 모드는 action.yml로 정의되어 있으며, 마켓플레이스 등록용 아티팩트(dist/note-comment-renderer.js) 포함
• ignore-notes 라벨이 붙은 PR은 게이트 검사를 건너뛰고 “Notes ignored” 코멘트를 남김

노트 포맷 및 버전 관리

• 노트는 git notes add -f -m "" 형식으로 저장
• 다중 세션 지원을 위해 버전 태그(``)와 구간 구분자 사용
• 사용자 메시지는 Git 사용자명, AI 응답은 제공자명으로 라벨링
• 기존 단일 세션 노트는 필요 시 자동 업그레이드되어 호환성 유지

[GN⁺]

Hacker News 의견들

• 나는 AI와 코드를 작성할 때 project.md 파일로 시작함
  거기에 내가 원하는 결과를 설명하고, AI에게 그 내용을 기반으로 plan.md를 작성하게 함
  이후 plan.md를 여러 번 수정하며 원하는 계획이 완성되면, 세부 todo 리스트를 생성해 plan.md 끝에 붙임
  완전히 만족하면 AI에게 todo를 실행하라고 지시하고, 더 이상 묻지 말고 끝까지 수행하게 함
  마지막으로 project.md와 plan.md, 그리고 코드 전체를 커밋함
  이렇게 하면 plan.md가 일종의 재현 가능한 아티팩트가 되어, 나중에 더 발전한 모델이 이를 기반으로 수정하거나 오류를 찾을 수 있음

  • 나도 비슷하게 하지만 세 가지 문서로 나눔 — design, plan, debug
    design은 기능 단위로 작성하며, 미해결 질문을 명시함
    plan은 plan/[feature]/phase-N-[description].md 구조로 관리하고, 빌드나 실행 한계에 부딪히면 중단함
    debug 단계에서는 가능한 원인 가설을 세우고, 로깅/트레이싱으로 검증한 뒤 수정함
    이 방식으로 신규 프로젝트와 레거시 모두에서 거의 100% 성공률을 보였음
    단점은 너무 많은 markdown 파일이 쌓인다는 점이지만, 과거 기록이 미래 변경에 유용해 아직 자동화하지 않았음
  • 이건 spec 기반 접근법처럼 들림
    GitHub spec-kit을 참고해볼 만함
  • obra/superpowers의 “brainstorming” 기능이 거의 동일한 워크플로우임. 써보면 정말 훌륭함
  • 예전에 Beads를 이렇게 썼는데, 이후 GuardRails를 만들었음
    모델에게 시장조사와 제안 검토를 시키며 반복하다 보면, 모델이 스스로 이해할 수 있는 언어로 프롬프트 설계를 하게 됨
    최근 XML이 Claude의 동작에 영향을 준다는 걸 알고 GuardRails의 구조를 다시 고민 중임
    소개 글 링크
  • 나도 비슷한 구조를 쓰지만, “context” 파일을 따로 둠
    plan이 완성되면 “context.md”를 만들어, 나중에 잘못된 계획을 되돌릴 때 참고함
    아직 실제로 쓸 일은 없었지만, 개념적으로는 유용함
    다만 이런 파일들을 어디에 둘지 애매해서 아직 레포에는 포함하지 않음
    혹시 이런 작업별 md 파일을 어디에 저장하는지 궁금함

• 내 생각엔 이건 “모든 줄을 커밋해야 하나?”와 같은 문제임
  결국 누구를 위한 기록인가가 핵심임
  대부분의 세션은 잡음이 많고, 잘못된 시도나 불필요한 정보가 많음
  중요한 건 세션의 산출물이지, 그 과정 자체는 아님
  다만 초기 spec이나 첫 프롬프트는 가치가 있음. 그것을 요약해 커밋 메시지나 markdown 파일로 남기는 게 좋음

  • 인간에게는 복잡하고 시끄럽지만, 이런 세션 정보는 미래의 AI에게 유용할 수 있음
    과거 세션을 학습 맥락으로 삼아 현재 작업을 이어가게 할 수 있음
    특히 모델의 한계를 이해하고, 코드가 사용자 의도에서 벗어난 지점을 찾는 데 도움이 될 수 있음
    결국 모든 인간 입력을 기록하는 것이 오픈소스 모델 발전에 중요하다고 생각함
  • “모든 줄을 커밋하느냐”보다 “모든 메모와 실패한 시도를 남길 것이냐”가 더 적절한 비유 같음
  • 과학 연구에서도 이런 문제를 이미 겪고 있음 — 재현성 위기
    초기 조건과 잡음을 포함해도 같은 결과가 나와야 함
    그렇지 않으면 미래의 코드 유지보수는 의도 추측 게임이 되어버림
    관련 기사
  • 투명성이 중요한 조직이라면 감사용으로 가치가 있을 수 있지만, 현실적으로 누가 그 긴 로그를 읽겠음
  • 모든 세션을 저장할 필요는 없지만, 세부 수정 과정에서 요구사항이 구체화되는 순간은 가치가 있음

• 일주일 전에 비슷한 아이디어를 제안했음 (링크)
  하지만 반대 의견도 많았음 — AI 프로젝트는 단일 입력으로 생성되지 않고, 대화형 과정이라 소스코드처럼 아티팩트화하기 어렵다는 점임
  그래도 Show HN에 올라오는 생성 프로젝트들이 너무 많아 노이즈가 심각한 상황임
  완전히 배제할 수는 없지만, 지금 상태로는 흥미가 떨어짐
  커뮤니티가 이 문제를 어떻게 다뤄야 할지 고민 중임

  • 나는 Boris Tane의 Claude 코드 작성법을 참고함
    research.md와 plan.md를 커밋해, 아키텍처와 기능의 살아있는 사전으로 사용함
    기능 이름을 파일명에 접두사로 붙여, Claude가 관련 설계를 빠르게 불러올 수 있게 함
    참고 블로그
  • 문제는 맥락 부족이 아니라, 노력의 기준이 낮아진 것임
    예전엔 흥미로웠던 프로젝트가 이제는 너무 쉽게 만들어짐
    긴 세션 로그를 읽게 만드는 건 해결책이 아님. 요약력과 기획력이 더 중요해짐
  • Codex가 세션 전체를 markdown으로 내보낼 수 있다면 좋겠음
    vibe coding의 진짜 가치는 시도와 실패의 과정을 보는 데 있음
  • 나도 두 개의 프로젝트를 Show HN에 올릴까 고민 중임
    단순히 결과물만 올리는 것보다 제작 과정과 해설이 있을 때 더 흥미로움
    그래서 [Show HN]과 별도로 [Creations] 같은 카테고리가 있으면 좋겠음
    예: 단순 체스 엔진은 [Creations], 1k로 만든 체스 엔진은 [Show HN]
    PerfBoard와 Lerc가 그 예시임

• 세션은 중간 산출물일 뿐, 최종 결과물에 포함할 필요는 없음
  코드 변경의 이유가 중요하다면, 커밋 메시지나 문서로 정리하는 게 맞음

  • 이건 결국 요약의 문제임
    커밋 시점에는 미래 독자가 어떤 질문을 할지 알 수 없음
    그래서 나는 세션을 저장해두고, 나중에 질문으로 요약을 생성하는 방식을 선호함
    Git AI는 이런 접근을 사용함
    요즘 엔지니어들이 너무 빠르게 작업해서, 일주일만 지나도 왜 그렇게 했는지 기억 못하는 경우가 많음
  • 최소한 세션의 요약본은 필요함
    연구형 프롬프트는 요약하고, 코드 생성형 프롬프트는 그대로 저장하는 게 좋음
    그래야 재현성과 리뷰 가능성이 확보됨
  • 나도 예전엔 LLM에게 커밋 메시지만 쓰게 했지만, 지금은 plan 파일 버전 관리가 더 낫다고 느낌
    계획이 에러 수정 과정까지 반영되어, 다음 반복에 유용한 문서가 됨
  • 내 경우엔 레포 자체가 에이전트의 기억 저장소임
    각 레포가 서로 메시지를 주고받으며 기능 요청을 관리함
    원본 대화와 의미 압축된 기억을 함께 저장해, 사양과 요구사항을 재정렬함
  • 세션 저장은 버그 원인 추적이나 사후 분석에도 유용함

• 세션 로그는 대부분 잡음임
  잘못된 시도와 되돌리기의 연속이라, 커밋 옆에 두는 건 브라우저 히스토리를 저장하는 것과 같음
  중요한 건 의도와 제약 조건을 담은 커밋 메시지임
  AI가 코드를 썼다면, 핵심은 대화가 아니라 왜 그렇게 요청했는가임
  결국 문제는 세션 저장이 아니라, 커밋 메시지를 소홀히 하는 습관일 수 있음

• 나는 AI를 쓰더라도 전통적인 설계 절차를 유지함
  요구사항 → 유스케이스 → 클래스 설계 → 제약조건 정의 → AI 실행
  이렇게 하면 인간의 아키텍처 판단력을 유지하면서, AI는 반복 구현을 가속함
  세션 로그 대신 이런 UML/제약 문서를 커밋에 포함하면, 의도와 맥락을 명확히 남길 수 있음
  2026년의 개발자는 이렇게 품격 있는 협업 구조를 지켜야 한다고 생각함

• 이건 커밋을 squash할지 말지의 문제와 유사함
  squash를 선호하면 결과만 중요하고, 과정을 남기지 않음
  반대라면 여정 자체를 기록함
  AI 세션도 마찬가지로, 사고 과정 디버깅에는 유용하지만, 깔끔한 히스토리를 선호하는 사람은 굳이 보지 않음
  세션은 레포 외부에서 별도로 관리하는 게 현실적임

  • 나도 squash파지만, 내부 이력을 펼쳐볼 수 있는 시스템이라면 세션도 함께 보고 싶음
    Mercurial이나 Fossil은 이런 기능이 더 잘 되어 있다고 들었음
  • 이 비유가 가장 적절하다고 생각함
    vibe-coding에서는 코드 자체보다 프롬프트가 사고의 흔적을 보여줌
    git에 넣을지 여부는 별개지만, 접근 가능하게 두는 건 가치 있음
  • 사람이 주도하는 개발이라면 AI 사용은 단순한 도구에 불과함
    그런 경우엔 실시간 과정을 볼 필요가 없음
    하지만 완전히 AI가 작성한 코드라면, 프롬프트 공개가 필요함

• 나도 세션을 추출해봤음
  일부 정보 손실 위험은 있지만, 가독성과 접근성이 훨씬 좋아짐

• 최소한 세션의 요약된 프롬프트는 저장해야 한다고 생각함
  AI 코드 리뷰는 인간보다 덜 엄격하고, 의도는 프롬프트에만 담겨 있음
  그렇지 않으면 같은 실수를 반복하게 됨
  코드 리뷰의 가치는 학습과 개선인데, AI는 학습하지 않으므로 프롬프트 기록이 그 역할을 대신해야 함
  또한 프롬프트 실력 평가나 주니어 교육에도 필요함

  • 하지만 이게 “당연하다”는 건 동의하지 않음
    우리는 키 입력, 메뉴 클릭, 디버깅 시도 같은 걸 커밋에 포함하지 않음
    모든 대화를 저장하면 노이즈가 너무 많음
    대신 의도와 가정이 담긴 문서 정도만 남기는 게 현실적임
  • 참고로, 세션 크기가 어느 정도라고 생각하는지도 궁금함

• “구글 검색 기록을 커밋에 포함해야 하나?”라는 질문과 같음 — 당연히 아니라고 생각함

  • 완벽한 비유임. 생각의 모든 조각을 기록하는 건 신호 대비 잡음 비율이 너무 나쁨
    대신 이유, 가정, 대안 요약만 남기는 게 좋음
  • 하지만 세션을 보관하면 AI가 수행한 검색 쿼리와 결과도 함께 저장되어, 프로젝트 맥락에 유용할 수 있음
  • 아무도 “div 가운데 정렬”을 몇 번 검색했는지 알고 싶지 않음
    마찬가지로, 모델이 사소한 문제로 헤맨 로그는 불필요함
  • 게다가 모든 검색이 커밋과 관련 있는 것도 아님. 민감한 정보가 포함될 수도 있음