기초: 빌더가 생각하는 방식

건너뛴 계획은 나중에 디버깅해야 할 장애가 된다

소프트웨어 엔지니어링의 모든 방법론은 빠르게 움직이고, 일찍 출시하고, 실제 환경에서 반복하라고 말한다. AI가 생성하는 웹사이트에서는 이게 반대로 작동한다. 여기 빌더는 프롬프트에서 곧바로 코드를 스트리밍하는 것을 거부한다 — 멈추고, 계획을 작성하고, 사용자가 검토할 때까지 기다린다 — 그리고 이 거부야말로 이 파이프라인의 나머지 모든 것을 뒷받침하는 단 하나의 결정이다. 초반은 느리지만 그 이후 모든 게 저렴해진다. 나라면 매번 이 거래를 택하겠고, 반대 입장을 주장하는 대부분의 사람들은 잘못된 추측이 나중에 어떤 대가를 치르게 하는지 실제로 지켜본 적이 없을 것이다.

계획이 막으려는 실패 시나리오는 이런 것이다. "내 스튜디오용 예약 사이트"라고 입력하고 실행 버튼을 누른다. 시스템은 "예약"이 무엇을 의미하는지 추측해야 한다 — 캘린더 위젯인지, 서드파티 임베드인지, 충돌 검사가 포함된 진짜 예약 시스템인지 — 그리고 아무것도 작성하기 전에 그 추측을 해야 한다. 다른 순서로는 진행할 수 없기 때문이다. 계획 단계에서 잘못 추측하면 수정은 문장 하나, 5초, 끝이다. 생성된 코드 안에서 잘못 추측하면 더 이상 문장을 편집하는 게 아니라 이미 잘못된 가정에 의존하고 있는 파일 10개를 풀어내야 한다. 나는 두 경우를 모두 지켜봤다. 계획 단계 수정은 대화 한 번이면 끝난다. 생성 이후 동일한 모호함에 대한 방향 전환은 폐기하고 다시 만드는 일이 된다.

계획은 단순한 할 일 목록도 아니며, 사람들이 놓치는 부분이 바로 이거다. 계획은 일종의 계약이고, 시스템 스스로도 그 계약을 지킨다. 정합성 검사 검증자 — 빌드가 출시되기 전에 반드시 승인해야 하는 에이전트 중 하나 — 는 완성된 사이트를 승인받은 계획과 비교해 차이를 확인한다. 계획했던 모든 페이지가 만들어졌는가? 기능 목록이 실제 결과와 일치하는가? 여기서 "완료"는 느낌이 아니다 — 문서화된 약속에 대한 상대적 개념이며, 줄 단위로 확인할 수 있다. "코드가 실행된다"보다 훨씬 강력한 보장이며, 이는 대조할 문서가 있기 때문에 가능한 것이다. 계획을 없애면 이 기준자도 함께 사라진다.

실제로 효과를 보는 지점

빌드를 이끄는 당사자로서 당신이 가진 영향력은, 그것을 실제로 발휘하든 안 하든, 초반에 집중되어 있다. 정보 구조, 페이지 구성, 어떤 기능이 v1에 들어가고 v2로 미뤄질지에 신경 쓴다면 — 그 까다로움은 첫 생성 결과가 나온 후보다 계획 검토 단계에서 열 배는 더 값어치가 있다. 계획을 다시 읽는 데 4분을 더 쓰는 게, 이미 어긋난 빌드를 고치기 위해 왕복하는 것보다 낫다.

가장 명확한 예는 제품 유형이다 — 단순 정적 사이트, 설치형 앱, 프레임워크 빌드, 실제 데이터 저장 기능을 갖춘 서버 기반 앱. 겉보기엔 드롭다운 메뉴처럼 보이지만 그렇지 않다. 전체 과정에서 가장 구조적인 선택이며, 사이트의 겉모습과는 무관한 수십 가지 사항을 은연중에 결정한다.

그리고 나중에 가볍게 타입을 업그레이드할 수는 없습니다. 정적 사이트에서 서버 기반 앱으로 전환하는 것은 설정 하나 바꾸는 문제가 아니라, 거의 두 번째 빌드에 가깝습니다. 계획의 절반에 해당하는 전제들(페이지가 어떻게 로드되는지, 데이터가 어디에 저장되는지, "게시"가 무엇을 의미하는지)이 이미 예전 타입을 기준으로 만들어져 있기 때문입니다. 그러니 확신이 반쯤밖에 없더라도 계획 단계에서 미리 말해두세요: "계정 기능이 필요할 수도 있어요." 서버 기반 앱을 염두에 두고 계획했는데 정적 기능만 사용하게 되는 것은 아무런 비용이 들지 않습니다. 나중에서야 서버 기반이 필요했다는 걸 알게 되는 것은 재구축 비용이 듭니다.

비판자들의 말이 일리 있는 부분

이 모든 것이 공짜가 아니라는 점은 숨기지 않겠습니다. 실행마다 격리된 워크스페이스를 사용한다는 것은 지식 파일이 매번 새로 복사되어 들어가고 여러분의 컴퓨터로는 아무것도 다시 전달되지 않는다는 뜻입니다. 빌드 도중 노트북이 고장 나도 안전하다는 점에서는 좋지만, 지연 시간 면에서는 손해입니다. 워크스페이스를 프로비저닝하고, 프레임워크 빌드의 경우 컨테이너 경계 안에서 실제 의존성 설치를 실행하는 데 실제 시간이 소요되기 때문입니다. 이 컨테이너 경계가 존재하는 이유는 프레임워크 빌드가 `npm install`과 임의의 빌드 스크립트를 실행하기 때문입니다. 여러분이 작성하지 않은 코드가 빌드 타임 권한으로 실행되는 것이죠. 이를 격리 없이 공유 호스트에서 실행하면 의존성 혼동 공격 한 번으로 다른 테넌트의 데이터에 접근할 수 있습니다. 빠르지만 안전하지 않은 방식도 가능했습니다. 다만 감수할 가치가 없는 트레이드오프였을 뿐입니다.

검증 과정도 마찬가지입니다. 완성된 빌드는 생성이 멈췄을 때가 아니라, 여러 독립적인 검증자들이 더 이상 막을 만한 문제를 찾지 못했을 때 파이프라인을 떠납니다:

• 코드 리뷰
• 보안
• 링크 및 SEO
• 접근성
• 적합성(Conformance)
• 실제 브라우저에서의 실행

이건 단 한 번의 검사가 아니라, 아무도 더 할 말이 없어질 때까지 플래그-수정-재검토를 반복하는 과정입니다. 왜냐하면 한 번의 린트 검사만으로는 수정 자체가 만들어낸 회귀 문제를 놓칠 수 있기 때문입니다. 깨진 링크를 고치다가 같은 페이지의 제목 계층 구조를 실수로 망가뜨리는 것이 바로 한 번의 검사로는 놓치고 재검토로는 잡아내는 종류의 문제입니다. 이 루프의 정직한 비용은 특별한 이유 없이 마지막에 빌드가 몇 분 더 걸리는 것입니다. 사람들은 그 몇 분을 알아차립니다. 방금 사이트를 두고 논쟁을 마친 6개의 에이전트는 알아차리지 못하죠. 경험에 대한 정당한 불만이긴 하지만, 그 논쟁 자체가 아예 일어나지 않은 채로 출시하는 것에 대한 좋은 근거는 아니라고 생각합니다.