Sanity check: LLM 보조 작업을 시간이 지나도 축적되게 만드는 git 활용법
Sanity check: using git to make LLM-assisted work accumulate over time
핵심 요약
LLM 작업 시 계획, 실행, 요약, 정제 과정을 git으로 관리해 지식을 축적하는 워크플로우 제안.
- 워크플로우 구조화 — 계획부터 정제까지의 단계를 git으로 관리해 LLM 작업의 맥락을 유지함.
- 지식 축적 — 일회성 작업이 아닌 재사용 가능한 지식으로 변환하여 프로젝트 메모리 시스템을 구축함.
- 도구 독립성 — 특정 프레임워크에 종속되지 않고 일반적인 git 저장소에서 버전 관리와 검토가 가능함.
- 의사결정 기록 — 코드 변경 사항뿐만 아니라 왜 그런 선택을 했는지에 대한 의도를 문서화하는 것이 중요함.
저는 여기서 무언가를 홍보하려는 게 아닙니다... 그저 LLM 보조 작업을 시간이 지나도 가치가 축적되게 만드는 제가 사용 중인 패턴에 대해 솔직한 피드백을 구하고 있을 뿐입니다.
이것은 메모 시스템이나 RAG 파이프라인, 혹은 에이전트 프레임워크가 아닙니다.
이것은 개별 작업을 재사용 가능한 지속적인 지식으로 바꾸기 위한 저장소 기반의 도구 독립적 워크플로우입니다.
핵심 루프
"작업 수행" -> "다음으로 이동" -> "맥락 상실" 대신 저는 다음과 같이 작업을 구조화하고 있습니다:
Plan (계획)
- 접근 방식, 제약 조건, 기대치 정의
- 계획을 저장소에 저장
Execute (실행) - LLM 보조, 지저분하고 탐색적인 작업
- 코드 변경 / 작업 아티팩트
Task closeout (작업 마무리, 작업 마무리 기술 사용) - 계획 대비 실제로 일어난 일
- 임시 세션 출력 저장
Distill (정제, 학습 정제 기술 사용) - 재사용 가능한 것만 추출
- 플레이북, 저장소 가이드, 교훈 업데이트
Commit (커밋) - 정리, 검사 및 수정
- 향후 작업은 더 나은 맥락에서 시작
저장소 기반 및 도구 독립적
이것은 특정 도구, 프레임워크 또는 에이전트 설정에 얽매이지 않습니다.
저는 다양한 코딩 어시스턴트, LLM 도구 및 환경 전반에서 이 동일한 루프를 사용해 왔습니다. 이 루프를 따를 때 저는 종종 계획, 실행 + 마무리, 정제 단계에서 도구를 혼합하여 사용합니다. 가치는 도구에 있는 것이 아니라 워크플로우의 구조와 그것이 생성하는 아티팩트에 있습니다.
모든 것은 일반 저장소에 존재합니다: 계획, 작업 아티팩트(gitignored), 그리고 정제된 지식. 그것은 저에게 버전 관리, PR 검토 및 diff 기능을 제공합니다. 따라서 숨겨진 채팅 기록이나 불투명한 메모 대신 모든 것을 검사하고 검토하며 되돌릴 수 있습니다.
실제 모습
저는 주로 코딩 프로젝트에 이것을 사용하고 있지만, 코딩에만 국한되지는 않습니다.
이것이 없으면 저(그리고 LLM)는 동일한 내용을 반복해서 다시 배우거나 너무 많은 맥락으로 프롬프트를 과부하시키게 됩니다. 이 루프를 사용하면: 계획을 작성하고, 작업을 수행하고, 마무리하고, 중요한 부분만 정제하여 재사용 가능한 지침으로 커밋합니다. 향후 작업은 차갑게 시작하는 대신 정제된 맥락에서 시작됩니다.
확신이 서지 않는 부분
여기서 반론을 제기해 주시면 정말 감사하겠습니다:
- 이것이 저장소에 좋은 메모와 예제를 유지하는 것과 실제로 다른가요?
- 다른 사람들도 이런 저장소 기반 워크플로우를 사용하고 있나요?
- 규모가 커지면 시간이 지남에 따라 맥락이 개선될까요, 아니면 결국 소음이 되는 또 다른 계층을 만들 뿐일까요?
결론적인 질문
이 '계획 -> 마무리 -> 정제' 루프가 의미 있는 패턴처럼 느껴지나요, 아니면 사람들이 이미 하고 있는 일의 더 구조화된 버전일 뿐인가요? 어디서 이 방식이 무너질 것으로 예상하시나요?
