AI로 개발하면 첫 화면이 나오는 속도는 정말 빠르다. 문제는 두 번째, 세 번째 기능을 붙일 때부터 시작된다. 처음에는 각각 독립적으로 보였던 기능이 로그인 상태, 데이터 구조, 공통 컴포넌트, 알림, 권한 같은 지점에서 서로 연결되기 때문이다.
기능 하나가 실제로는 여러 곳을 바꾼다
예를 들어 “홈에 최근 기록을 하나 더 보여줘”라는 요청은 화면 한 군데만 고치는 작업처럼 보인다. 하지만 실제로는 어떤 데이터를 최근 기록으로 볼지, 빈 상태는 어떻게 처리할지, 기존 정렬 규칙과 충돌하지 않는지, 모바일 레이아웃은 유지되는지까지 확인해야 한다.
coding agent는 요청받은 범위 안에서는 빠르게 코드를 만들 수 있다. 대신 프로젝트 전체의 과거 결정과 앞으로 유지해야 할 규칙을 항상 기억해주는 것은 아니다. 같은 기능을 다른 세션에서 다시 설명하다 보면 표현이 조금씩 달라지고, 그 차이가 코드의 중복이나 예외 처리의 불일치로 이어진다.
문제는 코드보다 컨텍스트에서 먼저 생긴다
프로젝트가 꼬였을 때 파일 구조부터 뜯어고치고 싶어지지만, 먼저 확인할 것은 “현재 무엇이 정답으로 취급되고 있는가”다.
- 이 기능의 원래 목적은 무엇인지
- 어떤 화면과 데이터를 함께 바꿔야 하는지
- 이미 재사용할 수 있는 로직이 있는지
- 이번 변경에서 건드리면 안 되는 영역은 어디인지
- 작업 완료를 무엇으로 판단할지
이 기준이 문서나 작업 단위로 남아 있지 않으면, 사람도 AI도 매번 현재 코드를 보고 의도를 추측하게 된다.
작은 변경일수록 먼저 영향 범위를 본다
실제로는 대규모 리팩터링보다 작은 기능 추가가 더 자주 프로젝트를 망가뜨린다. “이 정도는 바로 고쳐도 되겠지” 하고 시작한 변경이 공통 로직을 하나 더 만들고, 비슷한 상태값을 하나 더 만들고, 기존 예외 처리를 우회하기 쉽기 때문이다.
그래서 요즘은 구현 전에 아주 짧게라도 세 가지를 먼저 정리한다.
- 변경하려는 사용자 경험
- 영향을 받는 기존 기능과 데이터
- 작업이 끝났다고 판단할 수 있는 확인 방법
길고 완벽한 기획서를 만드는 것이 목적은 아니다. 코딩을 시작하기 전에 이번 변경의 경계를 만드는 것이 목적이다.
AI를 더 잘 쓰려면 AI에게 덜 추측하게 해야 한다
좋은 프롬프트를 만드는 것보다 더 중요한 것은 프로젝트의 사실을 안정적으로 전달하는 구조다. 어떤 agent를 쓰더라도 기능 정의, 변경 이유, 관련 파일, 확인 기준을 같은 형태로 넘길 수 있다면 도구를 바꿀 때마다 프로젝트 전체를 다시 설명할 필요가 줄어든다.
바이브코딩의 속도를 유지하면서 프로젝트를 오래 가져가려면 결국 “얼마나 빨리 코드를 생성하느냐”보다 “다음 변경에서도 같은 맥락을 이어갈 수 있느냐”가 중요해진다.