DevWeave를 기획하면서 가장 먼저 잘라낸 기능 중 하나가 “우리 안에서 모든 코드를 생성하자”는 방향이었다.
AI 코딩 도구는 이미 많고, 각 도구의 모델과 실행 환경은 빠르게 바뀐다. 여기에 또 하나의 코드 생성 화면을 만드는 것보다 내가 실제 개발에서 반복해서 필요했던 빈틈을 해결하는 편이 낫다고 봤다.
그 빈틈은 코딩을 시작하기 전과 변경하기 전의 구조화였다.
아이디어를 곧바로 코드로 보내면 빠르지만 경계가 없다
새 프로젝트 초반에는 “로그인, 홈, 기록 기능 만들어줘”처럼 바로 agent에게 요청해도 결과가 나온다.
하지만 기능이 늘어나면 질문이 달라진다.
- 이 기능은 기존 어느 화면을 재사용할 수 있는가
- 새 테이블이 정말 필요한가
- 같은 데이터를 두 군데서 관리하게 되지 않는가
- 이 변경으로 깨질 수 있는 기능은 무엇인가
- 기존 API 계약을 바꿔도 되는가
이 질문은 코드 생성 전에 답하는 편이 싸다.
DevWeave는 디자인 툴도 아니다
화면 구조를 다룬다고 해서 Figma처럼 픽셀 단위 디자인을 만드는 서비스로 범위를 넓히지는 않기로 했다.
DevWeave에서 화면 정보가 필요한 이유는 예쁜 UI를 만들기 위해서가 아니라 기능과 데이터가 어디에서 만나고 있는지를 이해하기 위해서다.
버튼 색상보다 이 버튼이 어떤 상태를 바꾸고, 어떤 다음 화면으로 이동하며, 어떤 API를 호출하는지가 더 중요하다.
결과물은 coding agent가 실행할 수 있어야 한다
구조화가 잘 되어 있어도 사람이 읽는 기획서로 끝나면 다시 agent에게 번역해야 한다.
그래서 최종 handoff에는 구현에 필요한 범위와 제약이 포함되어야 한다.
- 작업 목적
- 관련 기능과 화면
- 영향받는 데이터
- 재사용할 기존 구성
- 수정 예상 범위
- 완료 조건
- 테스트 기준
이 정보가 있으면 Codex든 Claude Code든 다른 도구든 같은 출발점에서 작업을 시작할 수 있다.
coding-agent agnostic을 유지하는 이유
특정 agent 하나에 깊게 통합하면 당장은 더 편한 기능을 만들 수 있다.
하지만 사용자가 도구를 바꾸면 프로젝트 구조도 다시 옮겨야 한다면 DevWeave가 해결하려던 문제가 반복된다.
그래서 agent는 교체 가능한 실행자이고, 프로젝트 구조와 결정은 사용자 소유 자산으로 남는 방향을 택했다.
DevWeave가 하려는 일은 코드를 가장 빨리 생성하는 것이 아니다.
어떤 AI에게 코딩을 맡겨도 프로젝트의 맥락과 변경 경계가 사라지지 않게 만드는 것.
그 범위를 지키는 것이 오히려 제품을 더 분명하게 만든다고 생각했다.