AI와 개발할수록 프로젝트 정보가 코드 밖에도 많이 생긴다.
기능을 왜 이렇게 만들었는지, 다음 작업에서 무엇을 건드리면 안 되는지, 아직 해결하지 못한 결정은 무엇인지 같은 정보가 채팅에 쌓인다.
문제는 그 채팅이 특정 도구에 묶여 있다는 점이다.
DevWeave에서 상태를 한곳에 몰아넣지 않은 이유
V1 구조를 잡으면서 “모든 데이터를 DevWeave 서버에 저장하면 편하지 않을까?”도 생각했다. 하지만 그렇게 하면 서비스가 프로젝트의 새로운 종속성이 된다.
그래서 역할을 나눴다.
- Working — IndexedDB: 브라우저에서 빠르게 작업하는 현재 상태
- Durable —
devweave/sync: 세션을 넘어 유지할 프로젝트 맥락 - Backup —
.aipbZIP: 서비스와 분리해 보관할 수 있는 백업 - Handoff —
devweave/...작업 브랜치 + PR: coding agent와 사람에게 넘길 변경 제안
이 구조에서 가장 중요한 원칙은 사용자 저장소가 마지막 기준점이라는 것이다. DevWeave가 없어져도 코드와 handoff 결과를 읽을 수 있어야 한다.
coding agent를 바꾸면 맥락이 끊겼다
한 도구에서 오래 개발한 뒤 다른 coding agent를 열면 저장소 코드는 그대로 있지만 이전 대화의 이유와 결정은 따라오지 않는다.
결국 새 agent에게 프로젝트 설명을 다시 한다.
사람이 다시 요약하는 과정에서 빠지는 내용도 있고, 이미 폐기한 아이디어가 다시 들어가기도 한다.
이 문제를 해결하려면 AI 서비스의 메모리보다 더 오래 남는 기준점이 필요했다.
사용자가 소유한 저장소가 가장 자연스러웠다
GitHub 저장소에는 이미 실제 코드가 있고 변경 이력이 남는다.
여기에 큰 작업의 task 문서, 프로젝트 구조, 결정사항과 테스트 기준까지 함께 두면 코드와 의도를 같은 장소에서 확인할 수 있다.
중요한 점은 DevWeave가 사용자의 프로젝트를 독점적으로 보관하지 않는다는 것이다.
DevWeave가 없어도 사용자는 자기 저장소에서 결과를 읽을 수 있어야 하고, 다른 agent도 같은 파일을 사용할 수 있어야 한다.
기존 프로젝트도 같은 방식으로 연결하려 한다
DevWeave는 새 프로젝트만 만드는 도구로 범위를 잡지 않았다. 이미 개발 중인 GitHub 저장소를 연결했을 때도 현재 코드와 문서를 읽고 기능·화면·데이터·의존관계를 구조화한 뒤 같은 handoff 흐름으로 이어가는 것이 V1의 중요한 사용 사례다.
이때 저장소에 바로 쓰는 권한을 크게 열기보다 필요한 범위만 읽고, 변경이 필요할 때는 작업 브랜치와 PR을 제안하는 흐름을 우선한다. 자동 merge보다 사용자의 최종 승인을 경계로 두는 이유다.
GitHub write 범위를 어떻게 제한할지는 DevWeave의 GitHub write를 사용자 승인 뒤에만 열기로 한 이유와 이어진다.
handoff는 전체 대화를 복사하는 일이 아니다
처음에는 지금까지 나눈 대화를 요약해서 새 agent에게 넘기면 된다고 생각하기 쉽다.
하지만 긴 대화에는 폐기된 선택지와 중간 실수가 섞여 있다.
handoff에는 현재 작업에 필요한 사실만 있어야 한다.
- 현재 프로젝트 상태
- 이번 변경의 목적
- 관련된 기능과 파일
- 변경 제약
- 확인해야 할 테스트
- 아직 결정되지 않은 부분
과거 대화는 참고자료일 수 있지만 source of truth가 되어서는 안 된다.
저장소가 있으면 사람과 AI 모두 같은 기준을 볼 수 있다
DevWeave가 구조화한 내용이 GitHub에 남으면 다음 작업자는 사람이든 AI든 같은 파일을 읽을 수 있다.
이것이 durable handoff라는 표현을 쓰는 이유다.
세션이 끝나거나 모델이 바뀌어도 사라지지 않고, 코드의 변화와 함께 버전 관리된다.
DevWeave의 역할은 저장소를 대체하는 것이 아니다
DevWeave 안에서 보기 편하게 기능 관계와 변경 영향을 보여줄 수는 있다.
하지만 프로젝트의 최종 소유권과 장기 기록은 사용자의 GitHub 저장소에 남도록 하는 것이 원칙이다.
AI 개발 도구는 계속 바뀔 수 있다. 반면 프로젝트는 몇 달, 몇 년 이어질 수 있다.
그래서 DevWeave에서는 도구보다 오래 살아남을 수 있는 곳에 프로젝트의 맥락을 남기는 것을 제품 구조의 핵심으로 두고 있다.