DevWeave에 새 프로젝트만 넣는 것이 아니라 이미 개발 중인 GitHub 저장소를 연결해 이어서 작업하는 흐름을 넣으면서 가장 먼저 고민한 것은 쓰기 권한이었다.
저장소를 읽기만 하는 단계에서는 프로젝트 구조와 기능 관계를 분석하면 된다. 하지만 실제 코드를 바꾸기 시작하면 제품이 사용자의 작업 공간에 영향을 준다.
그래서 “연결했으니 main에 바로 써도 된다”는 구조는 피하기로 했다.
기존 프로젝트는 현재 상태 자체가 중요한 자산이다
새 프로젝트는 아직 깨질 것이 적다. 반면 기존 저장소에는 운영 코드, 미완료 작업, 다른 사람의 브랜치, CI 규칙이 이미 존재할 수 있다.
DevWeave가 해야 할 일은 이 상태를 자기 방식으로 덮어쓰는 것이 아니라 먼저 읽고 구조화하는 것이다.
- 현재 기능과 화면
- 데이터와 API 관계
- 수정할 때 영향을 받는 영역
- 기존 재사용 가능 요소
- 테스트와 배포 규칙
이 정보를 정리한 뒤 실제 변경 범위를 제안한다.
쓰기가 필요하면 작업 브랜치를 만든다
V1에서는 durable handoff의 기본 단위를 GitHub 작업 브랜치와 PR로 잡았다.
예를 들면 devweave/... 형태의 별도 브랜치에서 변경을 만들고, 사용자가 diff와 설명을 확인할 수 있는 PR을 제안한다.
이 방식의 장점은 명확하다.
- main을 직접 덮어쓰지 않는다
- 변경 내역이 Git 기록으로 남는다
- CI와 코드 리뷰 흐름을 그대로 사용할 수 있다
- 마음에 들지 않으면 merge하지 않으면 된다
- DevWeave를 떠나도 결과가 사용자 저장소에 남는다
연결 권한과 실행 권한은 같은 것이 아니다
GitHub를 연결했다고 해서 모든 write를 영구 허용할 필요는 없다.
프로젝트 분석에는 읽기만 필요할 수 있고, 브랜치 생성이나 PR 작성은 사용자가 실제 작업을 시작할 때만 필요하다. 운영 배포나 외부 저장소 변경처럼 더 큰 영향이 있는 작업은 별도의 경계가 있어야 한다.
DevWeave가 agent-agnostic을 지키려면 권한도 특정 agent의 편의에 맞춰 넓게 열기보다 작업에 필요한 최소 범위로 나누는 편이 맞다.
목표는 자동 merge가 아니라 안전한 handoff다
AI 개발 도구는 점점 더 많은 것을 자동으로 할 수 있다. 하지만 DevWeave에서 자동화의 목표는 사용자의 최종 판단을 없애는 것이 아니다.
프로젝트의 현재 구조를 이해하고, 변경 영향을 정리하고, 실행 가능한 작업 단위로 만든 뒤, 사용자가 검토할 수 있는 형태로 GitHub에 넘기는 것이 먼저다.
그래서 GitHub 쓰기 권한은 기능 하나가 아니라 제품의 신뢰 경계로 보고 있다.
읽기는 넓게 이해하기 위해, 쓰기는 승인된 작업을 남기기 위해.
기존 프로젝트를 안전하게 이어가는 제품이라면 이 차이를 제품 구조에서부터 보여줘야 한다고 생각했다.