Show GN: 여러 AI 모델을 오가며 장기 프로젝트를 하기 위해 만든 협업 구조
(github.com/lim8603)AI 협업에서 기억은 채팅이 아니라 리포지토리에 있어야 합니다
최근 몇 달 동안 GPT-5 계열 모델, Claude, Copilot, Gemini 등 여러 AI 모델을 번갈아 사용하면서 개발 작업을 하는 일이 많아졌습니다. 예전에는 하나의 도구만 사용해도 충분했지만, 지금은 작업 종류에 따라 더 적합한 모델을 선택하는 것이 자연스러운 흐름이 되었습니다.
예를 들어 구조 설계는 GPT-5.4 같은 대형 모델이 안정적이고, 코드 작성은 Claude Sonnet / Opus 계열이 더 정확한 경우가 있으며, 프론트엔드 디자인이나 아이디어 탐색에는 다른 모델을 사용하는 편이 효율적일 때도 있습니다. 게다가 모델 업데이트 속도가 매우 빠르기 때문에 특정 도구에 고정하기보다는 상황에 따라 계속 선택을 바꾸게 됩니다.
문제는 여기서부터 시작됩니다.
모델을 바꿀 때마다, 세션이 바뀔 때마다 AI는 프로젝트를 전혀 기억하지 못합니다. 결국 매번 같은 설명을 반복하게 됩니다. 이 프로젝트가 무엇인지, 지금 어디까지 진행됐는지, 어떤 결정을 이미 했는지, 어떤 구조를 유지해야 하는지, 무엇을 하면 안 되는지 같은 기본적인 맥락을 계속 다시 전달해야 합니다.
처음에는 단순히 번거로운 정도였지만 프로젝트 규모가 커질수록 이 비용이 눈에 띄게 증가했습니다. 특히 여러 모델을 오가며 작업할 때는 실제 개발보다 컨텍스트를 다시 설명하는 데 더 많은 시간이 들어가는 느낌을 받았습니다. 그래서 자연스럽게 이런 질문을 하게 됐습니다.
"AI 협업에서 기억은 채팅에 있어야 하는 걸까, 아니면 프로젝트 자체가 기억을 가져야 하는 걸까?"
Prompt Engineering으로는 해결되지 않는 문제
AI를 잘 쓰기 위한 방법으로 Prompt Engineering 이야기는 많이 합니다. 하지만 장기 프로젝트를 진행해 보면 프롬프트보다 더 중요한 문제가 있습니다. 바로 컨텍스트가 유지되지 않는 문제입니다.
프롬프트는 한 번의 요청을 잘 만드는 방법이고, 프로젝트는 여러 번의 작업이 이어지는 과정입니다. 프로젝트를 안정적으로 진행하려면 최소한 다음 정보들이 계속 유지되어야 합니다.
- 현재 요구사항
- 지금까지의 결정 기록
- 작업 계획
- 완료된 작업
- 변경 이력
- 앞으로 할 일
이 정보들이 유지되지 않으면 모델이 아무리 좋아도 같은 실수를 반복하게 됩니다. 그래서 프롬프트를 더 잘 만드는 방향이 아니라, 컨텍스트 자체를 관리하는 방법을 만들기 시작했습니다. 이런 접근을 보통 Context Engineering이라고 부르는데, 저 역시 비슷한 문제를 겪으면서 이 개념을 프로젝트 단위 협업에 적용해 보기 시작했습니다.
채팅이 아니라 리포지토리가 기억을 가져야 한다
가장 먼저 바꾼 것은 컨텍스트를 저장하는 위치였습니다. 기존에는 모든 맥락이 채팅 안에 있었지만 채팅은 세션이 끝나면 사라집니다. 그래서 프로젝트 루트 안에 컨텍스트를 저장하는 구조를 만들었습니다.
.cowork/ 라는 폴더를 만들고 여기에 프로젝트 상태를 기록하도록 했습니다. 예를 들면 requirements, architecture decision record, task 목록, 테스트 기록, 릴리즈 기록, 세션 로그 같은 것들입니다.
세션을 시작할 때는 항상 현재 상태를 읽고, 계획을 세우고, 승인하고, 실행하고, 결과를 기록하는 흐름을 따릅니다. 대화는 휘발되지만 문서는 남습니다. 그래서 모델이 바뀌어도 프로젝트는 계속 이어집니다.
Plan → Approve → Execute 규칙
AI 협업을 하면서 가장 자주 겪은 문제 중 하나는 모델이 바로 코드를 수정해 버리는 상황이었습니다. 이전 결정을 무시하거나, 구조를 깨거나, 이미 합의된 방향과 다르게 변경하는 일이 반복됐습니다.
그래서 작업 규칙을 하나 만들었습니다. 항상 Plan → Approve → Execute 순서를 지키는 것입니다. 먼저 계획을 만들고, 사람이 확인하고, 그 다음에 실행합니다. 이 규칙 하나만으로도 장기 프로젝트에서 발생하는 오류가 크게 줄었습니다.
Artifact is Memory
이 프레임워크에서 가장 중요하게 생각하는 원칙은 'Artifact is Memory' 라는 문장으로 정리할 수 있습니다. 기억은 채팅에 있는 것이 아니라 프로젝트 산출물에 있어야 합니다.
그래야 모델이 바뀌어도, 세션이 바뀌어도, 도구가 바뀌어도, IDE가 바뀌어도 프로젝트 상태를 유지할 수 있습니다. 특히 여러 모델을 동시에 사용하는 환경에서는 이 원칙이 생각보다 훨씬 중요하게 작용합니다.
여기서 말하는 산출물은 처음부터 문서로 작성된 것만 뜻하지 않습니다. AI와 오가는 대화 속에서도 요구사항의 정제, 설계 결정, 작업 계획, 검토 결과처럼 프로젝트에 실제로 남겨야 할 정보가 계속 생깁니다. 문제는 이런 내용이 채팅 안에 머무는 한 일회성 맥락으로 소모되기 쉽다는 점입니다.
그래서 저는 AI와 나눈 대화 중 의미 있는 내용을 자동으로 분류해 기록하고, 그것을 다시 프로젝트 산출물로 사용하는 방식을 중요하게 보고 있습니다. 단순히 대화 로그를 쌓아두는 것이 아니라, 대화에서 나온 핵심 내용을 결정 기록, 요구사항 문서, 작업 계획, 세션 로그 같은 형태로 정리해 재사용 가능한 상태로 남기는 것입니다.
이렇게 하면 대화는 일회성 인터페이스에 머무르지 않고, 프로젝트를 계속 앞으로 밀어가는 작업 재료로 전환됩니다. 결국 기억해야 하는 것은 대화 그 자체가 아니라, 대화를 통해 추출된 구조화된 결과물이라고 생각합니다.
여러 모델을 오가면서 작업할 때 생기는 문제
요즘은 하나의 모델만 사용하는 경우가 거의 없습니다. 모델마다 강점이 다르기 때문에 작업 단계에 따라 다른 모델을 사용하게 되고, 설계, 코드 수정, 리뷰, 문맥 분석 같은 작업을 여러 세션과 여러 모델 사이에서 반복하게 됩니다.
이때 컨텍스트가 채팅 안에만 있으면 모델을 바꿀 때마다 프로젝트를 다시 설명해야 합니다. 그래서 컨텍스트를 채팅이 아니라 리포지토리 안에 두는 구조를 만들었습니다.
만든 것: cowork-context-framework
이 과정을 정리해서 하나의 프레임워크로 만들었습니다. 프로젝트 안에 컨텍스트를 저장하고, 세션을 복원하고, 결정을 기록하고, 작업을 추적하고, 모델이 바뀌어도 이어서 작업할 수 있도록 하는 구조입니다.
이전에는 템플릿 형태로 사용하면서 실제 프로젝트에 적용해 보며 어느 정도 검증을 거쳤고, 그 경험을 바탕으로 구조를 정리해 framework 형태로 승격한 상태입니다. AI와 장기 프로젝트를 할 때 필요한 최소한의 협업 구조는 이런 형태라고 생각하고 있습니다.
비슷한 시도를 해본 사람이 있는지 궁금합니다
- 여러 AI 모델을 같이 써본 경험이 있는 분
- 세션이 끊겨서 같은 설명을 반복해 본 적 있는 분
- agent / workflow / harness 같은 구조를 만들어 본 분
- 프로젝트 컨텍스트를 따로 관리해 본 분
비슷한 경험이 있다면 의견을 듣고 싶습니다.