Vibe Coding을 사용하여 만든 Claude 아티팩트를 회사에 들고 가서, “이대로 출시할 수 없나요?” 혹은 “여기만 조금 수정해서 우리 홈페이지에 올려도 안 되나요?”라고 말했을 때 문제가 되는 이유입니다.
우선, Claude 디자인을 포함하여 Vibe Coding으로 만든 사이트는 빠른 검증을 위한 프로토타입으로는 매우 훌륭하지만,
실제 운영되는 애플리케이션 또는 웹 서비스로 옮기는 것은 완전히 다른 이야기입니다.
첫째, 실제 서비스에는 이미 백엔드(backend)와 프론트엔드(frontend) 아키텍처가 반영되어 있으며, 데이터 구조(data structures) 또한 존재합니다. 새로운 기능이나 페이지를 추가하는 것은 마치 방을 새로 짓는 것과 같습니다.
이는 기존의 코드(code), DB(데이터베이스), API(응용 프로그래밍 인터페이스), 인증 시스템(authentication system) 등과 맞춰서 개발해야 함을 의미합니다...
하지만 누군가 “아티팩트에 링크만 걸어서 보여줄 순 없나요?”라고 말한다면,
아티팩트 안의 것은 그저 화면이 그대로 실행되는 것일 뿐입니다—로그(logs)도 없고, 사용자 통합(user integration)도 없습니다. 그것은...
“저는 그런 건 필요 없어요. 그냥 연결할 수 있잖아요?”라고 할 수도 있습니다. 그렇게는 할 수 있습니다.
하지만 다시 말해 보면... 제 컴퓨터에서 잘 돌아가는 것이 수백 또는 수천 명의 사용자가 동시에 접속하는 것과는 완전히 다른 이야기입니다. 만약 제대로 된 서비스를 구축한다면, 우리는 트래픽을 처리할 수 있는 능력이 필요합니다.
특히 기존 홈페이지에 새로운 페이지를 추가하는 경우 문제는 더욱 복잡해집니다. 기존 프레임워크(framework), 코드 구조, DB, API, 그리고 디자인 시스템과 맞춰서 통합해야 하기 때문입니다.
기초가 전통 한옥인 집을 지을 수는 없습니다.
“모듈러 주택으로 하면 안 될까요?”라고 말할 수도 있지만, 220V용으로 만들어진 모듈러 주택을 110V용으로 지어진 집에 연결할 수는 없잖아요... “이 부분만 살짝 수정하면 안 될까요?”—사실 그 ‘부분’이라는 것은 처음부터 다시 작성(rewriting from scratch)해야 한다는 뜻입니다. 그래서요... ㅠㅠ...
서비스는 단순히 고객에게 보여주는 것으로 끝나지 않습니다. 버그에 대응하려면, 시스템이 잘 작동하는지 확인하기 위해 로그를 축적해야 하며, 이는 최소한의 성능 측정(performance measurement)을 가능하게 합니다. 또한 업데이트가 필요할 수도 있습니다. 이를 위해서는 버전 관리(version control), 배포(deployment) 등이 필수적입니다.