# AI가 코드를 작성한다면 세션도 커밋의 일부가 되어야 할까? > Clean Markdown view of GeekNews topic #27153. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27153](https://news.hada.io/topic?id=27153) - GeekNews Markdown: [https://news.hada.io/topic/27153.md](https://news.hada.io/topic/27153.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-03T09:54:41+09:00 - Updated: 2026-03-03T09:54:41+09:00 - Original source: [github.com/mandel-macaque](https://github.com/mandel-macaque/memento) - Points: 26 - Comments: 4 ## Summary AI 코드 생성의 **출처와 맥락을 커밋 단위로 기록**하는 `git‑memento`는 개발 흐름 속에서 AI의 기여를 명시적으로 남길 수 있게 합니다. 커밋 시점의 대화 요약과 전체 세션을 각각 `git notes`에 분리 저장해 **추적성과 프라이버시**를 함께 확보하며, GitHub Actions와 연동해 자동 코멘트·검증·병합 이관까지 지원합니다. AI가 작성한 코드의 투명성을 관리 가능한 형태로 통합하려는 시도라는 점에서, 협업 환경의 새로운 감사를 위한 기반을 제시합니다. ## Topic Body - **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 응답은 제공자명으로 라벨링 - 기존 단일 세션 노트는 필요 시 자동 업그레이드되어 호환성 유지 ## Comments ### Comment 52303 - Author: wedding - Created: 2026-03-03T22:42:59+09:00 - Points: 1 프라이빗 프로젝트는 세션을 익스포트 해서 커밋하고, 퍼블릭은 요약파일이 꼭 필요한 경우라고 판단하면 커밋합니다. 아무래도 개인정보도 있고.. 툴마다 다르지만 세션당 10메가는 가볍게 넘어서.. 막 올리긴 좀 그렇더라구요 ### Comment 54040 - Author: roxie - Created: 2026-03-28T18:21:15+09:00 - Points: 1 - Parent comment: 52303 - Depth: 1 하지만 우리는 디스크가 그 어느때보다 싼 시대를 살고 있는걸요! ### Comment 52225 - Author: neo - Created: 2026-03-03T09:54:41+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47212355) - 나는 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](https://github.com/github/spec-kit)을 참고해볼 만함 - [obra/superpowers](https://github.com/obra/superpowers)의 “brainstorming” 기능이 거의 동일한 워크플로우임. 써보면 정말 훌륭함 - 예전에 Beads를 이렇게 썼는데, 이후 **GuardRails**를 만들었음 모델에게 시장조사와 제안 검토를 시키며 반복하다 보면, 모델이 스스로 이해할 수 있는 언어로 **프롬프트 설계**를 하게 됨 최근 **XML이 Claude의 동작에 영향을 준다**는 걸 알고 GuardRails의 구조를 다시 고민 중임 [소개 글 링크](https://giancarlostoro.com/introducing-guardrails-a-new-coding-agent-task-companion) - 나도 비슷한 구조를 쓰지만, “context” 파일을 따로 둠 plan이 완성되면 “context.md”를 만들어, 나중에 잘못된 계획을 되돌릴 때 참고함 아직 실제로 쓸 일은 없었지만, 개념적으로는 유용함 다만 이런 파일들을 어디에 둘지 애매해서 아직 레포에는 포함하지 않음 혹시 이런 **작업별 md 파일을 어디에 저장**하는지 궁금함 - 내 생각엔 이건 “모든 줄을 커밋해야 하나?”와 같은 문제임 결국 **누구를 위한 기록인가**가 핵심임 대부분의 세션은 잡음이 많고, 잘못된 시도나 불필요한 정보가 많음 중요한 건 세션의 산출물이지, 그 과정 자체는 아님 다만 초기 **spec**이나 첫 프롬프트는 가치가 있음. 그것을 요약해 커밋 메시지나 markdown 파일로 남기는 게 좋음 - 인간에게는 복잡하고 시끄럽지만, 이런 세션 정보는 **미래의 AI**에게 유용할 수 있음 과거 세션을 학습 맥락으로 삼아 현재 작업을 이어가게 할 수 있음 특히 모델의 한계를 이해하고, 코드가 사용자 의도에서 벗어난 지점을 찾는 데 도움이 될 수 있음 결국 모든 **인간 입력을 기록**하는 것이 오픈소스 모델 발전에 중요하다고 생각함 - “모든 줄을 커밋하느냐”보다 “모든 **메모와 실패한 시도**를 남길 것이냐”가 더 적절한 비유 같음 - 과학 연구에서도 이런 문제를 이미 겪고 있음 — **재현성 위기** 초기 조건과 잡음을 포함해도 같은 결과가 나와야 함 그렇지 않으면 미래의 코드 유지보수는 **의도 추측 게임**이 되어버림 [관련 기사](https://www.ipr.northwestern.edu/news/2024/an-existential-crisis-for-science.html) - 투명성이 중요한 조직이라면 감사용으로 가치가 있을 수 있지만, 현실적으로 누가 그 긴 로그를 읽겠음 - 모든 세션을 저장할 필요는 없지만, 세부 수정 과정에서 **요구사항이 구체화되는 순간**은 가치가 있음 - 일주일 전에 비슷한 아이디어를 제안했음 ([링크](https://news.ycombinator.com/item?id=47096202)) 하지만 반대 의견도 많았음 — AI 프로젝트는 단일 입력으로 생성되지 않고, 대화형 과정이라 **소스코드처럼 아티팩트화하기 어렵다**는 점임 그래도 Show HN에 올라오는 생성 프로젝트들이 너무 많아 **노이즈가 심각**한 상황임 완전히 배제할 수는 없지만, 지금 상태로는 흥미가 떨어짐 커뮤니티가 이 문제를 어떻게 다뤄야 할지 고민 중임 - 나는 **Boris Tane의 Claude 코드 작성법**을 참고함 research.md와 plan.md를 커밋해, 아키텍처와 기능의 **살아있는 사전**으로 사용함 기능 이름을 파일명에 접두사로 붙여, Claude가 관련 설계를 빠르게 불러올 수 있게 함 [참고 블로그](https://boristane.com/blog/how-i-use-claude-code/) - 문제는 맥락 부족이 아니라, **노력의 기준이 낮아진 것**임 예전엔 흥미로웠던 프로젝트가 이제는 너무 쉽게 만들어짐 긴 세션 로그를 읽게 만드는 건 해결책이 아님. **요약력과 기획력**이 더 중요해짐 - Codex가 세션 전체를 markdown으로 내보낼 수 있다면 좋겠음 vibe coding의 진짜 가치는 **시도와 실패의 과정**을 보는 데 있음 - 나도 두 개의 프로젝트를 Show HN에 올릴까 고민 중임 단순히 결과물만 올리는 것보다 **제작 과정과 해설**이 있을 때 더 흥미로움 그래서 [Show HN]과 별도로 [Creations] 같은 카테고리가 있으면 좋겠음 예: 단순 체스 엔진은 [Creations], 1k로 만든 체스 엔진은 [Show HN] [PerfBoard](https://fingswotidun.com/PerfBoard/)와 [Lerc](https://lerc.neocities.org/)가 그 예시임 - 세션은 **중간 산출물**일 뿐, 최종 결과물에 포함할 필요는 없음 코드 변경의 이유가 중요하다면, **커밋 메시지나 문서**로 정리하는 게 맞음 - 이건 결국 **요약의 문제**임 커밋 시점에는 미래 독자가 어떤 질문을 할지 알 수 없음 그래서 나는 세션을 저장해두고, 나중에 **질문으로 요약을 생성**하는 방식을 선호함 [Git AI](https://github.com/git-ai-project/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 가운데 정렬”을 몇 번 검색했는지 알고 싶지 않음 마찬가지로, 모델이 사소한 문제로 헤맨 로그는 불필요함 - 게다가 모든 검색이 커밋과 관련 있는 것도 아님. **민감한 정보**가 포함될 수도 있음 ### Comment 54041 - Author: roxie - Created: 2026-03-28T18:21:29+09:00 - Points: 1 - Parent comment: 52225 - Depth: 1 > “구글 검색 기록을 커밋에 포함해야 하나?”라는 질문과 같음 — 당연히 아니라고 생각함 이 댓글이 좋네요