AI coding agent를 쓰면 첫 기능을 만드는 속도는 놀라울 정도로 빨라진다.
아이디어를 설명하고 화면 하나를 만들고, 다음 기능을 추가하는 과정까지는 정말 편하다. 문제는 프로젝트가 조금 커진 뒤부터였다.
기능을 하나 더 추가할 때마다 기존 화면, 데이터, 공통 로직, 권한, 테스트에 어떤 영향을 주는지 사람이 다시 확인해야 했다. 대화가 길어지면 agent도 이전 결정을 모두 유지하기 어려웠고, 새로운 세션에서는 같은 프로젝트를 다시 설명해야 했다.
이 경험이 DevWeave의 출발점이었다.
문제는 “코드를 못 짠다”가 아니었다
coding agent가 잘못된 코드를 만들어서만 프로젝트가 꼬이는 것은 아니었다.
오히려 각 요청만 보면 코드가 맞는 경우가 많았다.
문제는 기능 A를 만들 때 했던 결정과 기능 B를 만들 때 한 결정이 조금씩 달라지는 데 있었다. 비슷한 로직이 두 번 생기고, 같은 개념을 서로 다른 이름으로 저장하고, 기존 기능을 재사용할 수 있는데 새로 만드는 일이 반복됐다.
한 번의 코드 생성 품질보다 여러 번의 변경 사이에서 맥락을 유지하는 것이 더 어려웠다.
코딩 전에 프로젝트의 구조를 볼 수 있어야 했다
그래서 DevWeave는 코드를 대신 작성하는 서비스로 시작하지 않았다.
아이디어나 기존 프로젝트를 받아서 다음 내용을 먼저 구조화하는 쪽에 초점을 맞췄다.
- 어떤 기능이 있는지
- 어떤 화면과 연결되는지
- 어떤 데이터가 필요한지
- 기능 사이에 어떤 의존관계가 있는지
- 변경하면 어디까지 영향을 받는지
- 이미 있는 기능을 재사용할 수 있는지
이 구조를 먼저 알면 coding agent에게 “이 기능 만들어줘”라고 넘길 때도 변경 범위를 더 구체적으로 줄 수 있다.
특정 AI에 종속되고 싶지 않았다
프로젝트를 진행하면서 Codex, Claude Code, Cursor, OpenCode처럼 여러 도구를 바꿔 쓸 수 있다.
어떤 도구가 가장 좋은지는 시기와 작업에 따라 달라질 수 있다. 그래서 DevWeave 자체가 특정 agent의 전용 프런트엔드가 되는 방향은 피하고 싶었다.
대신 어떤 coding agent를 사용하더라도 같은 프로젝트 구조와 작업 정보를 넘길 수 있도록 만드는 것을 목표로 했다.
GitHub 저장소를 마지막 handoff 지점으로 잡았다
AI 도구의 대화 기록이나 내부 메모리에만 프로젝트 맥락을 두면 도구를 바꾸는 순간 다시 시작해야 한다.
반면 사용자가 소유한 GitHub 저장소에 작업 문서와 코드가 함께 남아 있으면 agent가 바뀌어도 기준점을 유지할 수 있다.
그래서 DevWeave에서 중요한 것은 “우리 서비스 안에 모든 것을 가둔다”가 아니라, 정리한 결과를 사용자의 저장소에 durable handoff 형태로 남기는 것이다.
DevWeave가 해결하려는 순간
DevWeave가 필요한 사람은 처음 코딩을 시작하는 사람만은 아니다.
오히려 이런 순간을 자주 떠올렸다.
기능은 꽤 많이 만들었는데, 이제 뭘 건드리면 어디가 깨질지 무서워서 더 이상 손대기 어려운 프로젝트.
AI 덕분에 만들기 시작하는 장벽은 낮아졌다. DevWeave는 그 다음 단계인 계속 고치고 이어갈 수 있는 프로젝트 구조를 만드는 데 초점을 맞추고 있다.