Vibe 코딩으로 풀스택 앱 개발하기: 기술적 사용자와 비기술적 사용자 모두를 위한 통찰

https://youtu.be/VQMJm_lF-38?si=NA3zaqj4DO_tACxT

-- 데이터가 저장되고, 이미지가 업로드되며, 신용카드로 결제까지 이루어졌습니다 [1]. 이 모든 것을 직접 코드를 한 줄도 작성하지 않고 4시간도 채 안 되는 시간에 해냈습니다 [1]. 첫 시도에서는 원하는 것을 그냥 입력했습니다. 우리는 디지털 제품을 판매하는 마켓플레이스를 만들고 싶고, 이미 존재하는 제품을 보여주는 것부터 시작하고 프런트엔드를 먼저 다루고 싶다고 했습니다 [1]. 그러자 프로그램은 그 자체로 완전히 아름다운 사이트를 만들었지만, 때로는 작동하지 않는 많은 기능들과 제가 원하지 않는 기능들도 있었습니다. 예를 들어, 카테고리나 추천 기능은 원하지 않았고, 사람들이 달러가 아닌 토큰으로 지불하게 하고 싶었습니다 [1]. 그래서 저는 제가 원하는 것에 대해 좀 더 구체적으로 설명해야 했습니다 [1]. 프로그램은 다음에 무엇을 할지에 대해 좋은 아이디어를 제공했지만, 제가 정말로 원했던 것은 이 기능을 단순화하기 위해 원치 않는 기능을 먼저 제거하는 것이었습니다 [1]. 그래서 이 버전을 복원하자, 상단 내비게이션 바에서는 기능들이 제거되었지만, '추천' 버튼과 해당 페이지는 여전히 남아있었습니다. 제가 원했던 만큼 기능들을 잘 제거하지 못했습니다 [1]. 코드 변경 내용을 살펴보면, 변경 사항별로 차이점을 볼 수 있는데, 이는 예를 들어 클로드 프로젝트(Claude projects)에서는 얻을 수 없는 정말 멋진 기능입니다 [1]. 제품 유형에서 일부를 제거하고, 일부 사용법을 제거했으며, 카드를 변경했지만, 우리가 원했던 것처럼 전체 페이지를 제거하지 않고 단지 해당 페이지로의 링크만 제거했습니다 [1]. 사실 이것은 유형에서 제거되었고, 이로 인해 타입 오류가 발생했습니다. 빌드는 성공적이지 못했는데, 제거하지 않은 부분에서 여전히 이 유형들이 사용되었기 때문입니다 [1]. 그래서 오류가 발생했고, '수정 시도'라는 멋진 버튼이 있었고 실제로 수정되었습니다. 하지만 단지 유형을 다시 추가했을 뿐이라서 우리가 의도했던 바는 아니었습니다 [1]. 이 비디오를 통해, 그리고 직접 시도해 보면서 알게 될 한 가지는 바이브 코딩(Vibe coding)이 기술이며, 이미 기술 지식을 가지고 있다면 도움이 되지만, 완전히 필수적인 것은 아니라는 것입니다 [1]. 그래서 바이브 코딩의 첫 번째 교훈은 실제 코딩과 마찬가지로 작동하는 간단한 것부터 시작해야 한다는 것입니다 [1].

-- 그래서 우리는 새 프로젝트를 만들고 가장 간단한 것부터 시작하겠습니다 [2]. 저는 실제로 제가 원하는 것들을 미리 계획했고, 이는 제가 일반적인 프로젝트에 접근하는 방식과 같습니다. 즉, 단계별로 진행하는 것입니다 [2]. 이제 우리는 컴퓨터에게 이것을 어떻게 할지 알려주고 있습니다. 이전에도 컴퓨터에게 어떻게 할지 알려주고 있었지만, 이제는 자연스러운 영어로 훨씬 적은 단어를 타이핑하고 있습니다 [2].
-- 첫째, 제품 목록을 표시하고, 로컬 파일에서 가져오며, 아무런 기능이나 다른 것 없이 오직 제품 목록만 있으면 됩니다 [2].
-- 다음으로, 우리는 슈퍼베이스(Superbase)에서 제품을 가져올 것입니다. 슈퍼베이스는 백엔드와 작업하기 매우 쉬운 SaaS(서비스형 소프트웨어) 데이터베이스입니다 [2].
-- 그 다음에는 사용자로 로그인하고 로그아웃할 수 있어야 합니다. 이는 다음 단계에서 필요한데, 제품을 만들고 해당 제품을 해당 사용자가 생성한 것으로 할당하는 것입니다 [2]. 여기에 커버 이미지 업로드 기능도 포함하고 싶습니다 [2].
-- 그리고 사용자들에게 토큰을 사용하여 제품을 구매할 수 있도록 허용하고 싶습니다 [2].
-- 마지막으로, 신용카드를 사용하여 토큰을 구매하기 위해 스트라이프(Stripe)에 연결하고 싶습니다 [2].
-- 이 모든 것은 많은 작업이며, 직접 구축한다면 4시간 이상의 작업이 될 것입니다 [2]. 기술 사용자로서 저는 백엔드가 어떻게 생겼을지에 대한 작은 다이어그램도 만들었습니다 [2]. 사용자, 그리고 사용자가 만든 제품, 제품과 사용자를 모두 연결하는 제품 구매, 그리고 사용자를 위한 토큰 구매가 있습니다. 이는 스트라이프를 통해 실제 돈 구매를 기록하는 방법입니다 [2]. 이러한 프레임워크를 마음에 두고 있으면 바이브 코딩을 할 때 컴퓨터가 제대로 작동하도록 하는 데 정말 도움이 될 수 있습니다 [2]. 왜냐하면 세부 사항은 컴퓨터가 알아서 처리해 주지만, 첫 번째 예시에서 보았듯이 그냥 '아무거나 해'라고 말하면 세부 사항을 만들어내고 사용자가 반드시 동의하지 않는 제품 방향을 만들어낼 것이기 때문입니다 [2].
-- 참고로, 다시 시작하기 전에, 따라하고 싶다면 lovable.dev를 사용하고 있습니다. lovable.dev는 또 다른 AI 바이브 코딩 도구이며, 슈퍼베이스 백엔드 및 스트라이프와 연결할 수 있다는 것이 가장 큰 특징입니다. 예를 들어 클라우드 프로젝트에서처럼 자바스크립트 앱뿐만 아니라 실제 앱을 구축할 수 있습니다 [2]. 또한 Figma 파일을 가져올 수도 있으며, 제가 아직 탐색하지 않은 다른 기능들도 많이 있을 것이라고 확신합니다 [2].

-- 참고로, 이 비디오는 스폰서십을 받고 있지만, 제품에 대해 완전히 솔직하게 말할 수 있을 때만 스폰서십을 진행합니다 [3]. 나쁜 제품을 가진 회사들은 제가 그렇게 말한 후에 계속하지 않으므로 이는 좋은 점입니다. 그들은 '네, 원하시는 대로 말씀하세요'라고 했고, 제품에 대해 매우 자신 있어 했습니다. 그리고 솔직히 말해서, 보시다시피 꽤 좋습니다 [3].
-- 그래서 저는 프롬프트를 다시 작성했고, 이제는 매우 간단합니다. "사용자들이 디지털 제품을 판매하는 마켓플레이스를 만들고 있으며, 간단하게 만드세요"라고 되어 있습니다 [3]. 이는 이전과 똑같지만, 저는 "제품 유형은 이 네 가지 키와 값을 가질 것입니다"라고 추가했습니다 [3]. 그리고 "카테고리 필터링이나 추천 유형 화면은 만들지 마세요. 우리는 단지 인덱스만 원합니다"라고 말했습니다 [3]. 아마 그냥 "단지 인덱스만 원합니다"라고 말했어도 되었을 것입니다 [3]. 그러자 그렇게 했습니다 [3].
-- 이것을 확장해 보면, 인덱스가 있지만 아직 클릭할 수는 없습니다 [3]. '단지 인덱스만 원한다'는 말을 진지하게 받아들인 것 같습니다 [3]. 하지만 멋진 호버 기능이 있고, 이는 제가 했을 디자인보다 훨씬 낫습니다 [3]. 샘플 데이터에는 디지털 제품에 어울리는 이름들도 있습니다 [3]. 여기 코드를 보면, services/product service.ts 파일에 이 모든 제품들이 있습니다 [3].
-- 그래서 다음으로 할 일은 각 제품에 대한 개별 페이지를 만들라고 지시했는데, 이는 매우 쉬웠습니다. 그냥 그렇게 만들었습니다 [3]. 이 페이지들은 정보가 많지 않아서 환상적으로 보이지는 않지만, 지금 당장은 가장 중요한 부분이 아니므로 괜찮습니다 [3].
-- 참고로, 여기에서도 코드를 볼 수 있습니다. 코드를 보는 방법은 두 가지입니다. 'raw'에서는 그들이 생성한 모든 코드와 그들의 사고 과정을 볼 수 있고, 'diff'에서는 무엇이 추가되고 변경되었는지 볼 수 있습니다 [3]. 생성할 때, 'raw'에서는 전체를 다시 생성하므로 구성 요소가 커지면 느려집니다 [3]. 그러나 멋진 'diff'를 보여주는 것은 무엇을 하고 있는지 이해하는 데 정말 좋습니다 [3]. 물론, Lovable이 목표로 하는 완전한 비기술자라면 이 코드를 보는 것이 별 도움이 되지 않습니다 [3]. 그러나 개발 속도를 높이기 위해 이것을 사용하려는 기술자에게는 정말 유용합니다 [4].

-- 이제 슈퍼베이스에 연결하여 거기서 제품을 가져오라고 했습니다 [4]. 이를 위해 새 제품 마켓플레이스에 가서 '연결'을 눌러야 했습니다 [4]. 슈퍼베이스 대시보드로 이동할 수 있습니다. 저는 이 프로젝트를 위해 Lovable보다 슈퍼베이스에 더 많은 돈을 지불하고 있습니다. 이 데이터베이스를 위해 한 달에 약 10달러를 지불하고 있습니다 [4]. 여기에서 데이터베이스를 볼 수 있고, 스키마 시각화 도구도 볼 수 있습니다. 이는 우리가 지금 다루기에는 더 고급스러운 기능인데, 작업이 완료된 후에 필요합니다 [4]. 어떤 이유에서인지 이것이 사용자와 연결되지 않는데, 놀랍습니다 [4]. 어쨌든, 테이블을 볼 수 있고 특정 테이블로 이동하여 어떤 모습인지 볼 수 있으며, 실제 테이블 편집기를 보고 변경할 수도 있습니다 [4]. 물론, 프로덕션 환경에서 임의의 변경을 하고 싶지는 않겠지만, 데이터를 둘러보고 변경 사항을 저장할 수도 있습니다 [4].
-- 그래서 이것은 완전한 데이터베이스 솔루션입니다 [4]. 백엔드를 몰라도 이것을 할 수 있습니다 [4]. 데이터베이스 테이블이 어떻게 연결되는지에 대한 개념은 여전히 알아야 하지만, 설정에 관한 모든 세부적인 번거로운 작업은 모두 추상화되어 있습니다 [4]. 또한 인증 및 저장소도 처리합니다 [4]. 여기 저장소에서 제품 이미지가 있는 것을 볼 수 있습니다 [4]. 어쨌든, Lovable이 어떻게 하는지 잠시 후에 보여드리겠지만, 이것이 백엔드를 처리하는 마법이며, 이것이 클라우드 프로젝트나 다른 프런트엔드 전용 빌드보다 더 강력한 이유입니다 [4].
-- 자신만의 프로젝트를 설정할 때 슈퍼베이스를 설정하는 데 약간의 시간을 할애해야 할 것입니다 [4]. 인증 부분에 도달했을 때 나중에 설명할 함정이 있지만, 첫 부분은 꽤 쉬울 것입니다 [4]. 이 버전을 복원하면, 거의 똑같다는 것을 알 수 있을 것입니다. 유일한 차이점은 이제 슈퍼베이스에서 코드를 가져오고 있다는 것입니다 [4]. 그리고 슈퍼베이스에서 많은 유형을 가져옵니다. 걱정하지 마세요 [4].

-- 네, 이것은 슈퍼베이스에 연결되었고, 이제 실제로 제품 테이블을 만들고 메인 페이지에 모두 로드하라고 지시해야 했습니다 [5]. 사용하지 않을 많은 기능들(나중에 추가할 수 있는 필터링 등)을 받지 않기 위해 의도적으로 간단하게 유지했습니다 [5].
-- 슈퍼베이스와 작업할 때, 그것은 SQL을 보여주고 당신은 그것을 승인해야 합니다 [5]. 비기술자라면 데이터베이스가 어떻게 작동하는지 조금이라도 안다면 무서울 수도 있고, 순전히 바이브 코딩만 하고 데이터베이스가 뭔지 모른다면 충분히 무섭지 않을 수도 있습니다 [5]. 저는 그것에 대해 어떻게 생각해야 할지 모르겠습니다 [5]. 하지만 코더에게는 좋습니다. 기본적으로 그들의 코드를 검토할 수 있기 때문입니다 [5]. 이 모든 것은 정말 빨리 일하는 꽤 괜찮은 개발자와 함께하는 엔지니어링 매니저가 되는 것과 같습니다. 데본(Devon)보다 훨씬 낫습니다 [5].
-- 오류가 있었는데, UID 형식과 관련이 있었습니다 [5]. 자동적으로 수정했습니다 [5]. UID는 헥스(hex) 형식이며 숫자와 A부터 F까지만 사용해야 합니다 [5]. 첫 번째 시도에서 GH와 I 등 다른 알파벳 문자를 추가했고, 문제가 발생했으며, 수정했고, 성공했습니다 [5]. 스크립트를 실행하여 애플리케이션이 슈퍼베이스에서 슈퍼베이스 관련 데이터를 가져오도록 업데이트했습니다 [5].
-- 이것을 복원하면, 로딩 중이라는 메시지가 뜹니다 [5]. 아, 잠깐만요, 그 로딩은 이전 버전으로 복원하는 것이었습니다 [5]. 이걸 위해서는 이렇게 해야 할 것 같습니다. 네, 로드되지 않으면 여기 '페이지 새로고침'을 누르세요. 때로는 약간의 오류가 있거나 이상한 상태가 됩니다 [5]. 새로고침해야 합니다 [5]. 네, 이전처럼 잘 작동합니다 [5]. 코드를 보면, 'created_at'을 추가했습니다. 좋은 데이터베이스 테이블에는 그게 있죠 [5]. 그리고 이 모든 목업 데이터를 제거하고 대신 슈퍼베이스에 연결하고 있습니다 [5]. 이 내용을 이해할 필요도 없습니다. 단지 슈퍼베이스에 연결되어 있다는 것만 알면 됩니다 [5].
-- 제가 바이브 코딩을 할 때 생각하는 방식은 때로는 이런 것들이 라이브러리에 있을 것이라는 것입니다. 라이브러리 코드에 있는 모든 것을 이해하나요? 아니요 [5]. 하지만 이제 그 라이브러리 코드가 당신의 코드베이스에 있고 당신을 위해 작성되었습니다 [5]. 그래서 많은 경우 그렇게 생각해도 괜찮습니다 [6]. 다른 경우에는 보안 결함을 초래하거나 키를 노출할 수도 있습니다 [6]. 그러니 '바이브 코딩을 사용하면 사람들이 즉시 당신의 웹사이트를 해킹할 거야'라고 말하는 안티-하이프 사람들에게 속지 마세요 [6]. 하지만 코드도 조금 읽어보세요 [6]. 코드를 얼마나 잘 읽어야 하는지는 코드가 코드베이스의 어떤 부분에 있는지, 어떤 유형의 코드인지에 따라 결정됩니다. 어떤 코드는 이상한 버그나 보안 결함을 일으킬 가능성이 훨씬 높기 때문입니다 [6]. 그리고 프로그래머로서의 경험은 이를 이해하는 데 도움이 될 것입니다. 그래서 당신은 UI 위주인 임의의 리액트(React) 컴포넌트를 보느라 시간을 낭비하지 않고, 그냥 여기를 보고 '응, 괜찮아'라고 말할 수 있습니다 [6].

-- 이제 백엔드에 연결했고, 슈퍼베이스를 사용하여 인증 워크플로우를 만들고 싶습니다 [6]. '프로필' 테이블을 설정했습니다 [6]. 슈퍼베이스에서는 인증 테이블을 데이터베이스에서 볼 수 없습니다 [6]. 데이터베이스와 인증을 볼 수 있습니다. 'auth.users.ID'는 이 모든 테이블이 연결되는 곳이며, 인증은 여기서 처리됩니다 [6]. 이 모든 것을 설정할 수 있습니다. 잠시 후에 반드시 변경해야 할 설정을 보여드리겠지만, 데이터베이스에서는 인증 테이블을 볼 수 없다는 것만 알아두세요 [6].
-- 이렇게 설정되었습니다. 프로필을 만들기 위해 SQL을 실행하라고 요청합니다 [6]. 그리고 이것은 제가 알아낸 것인데, 아바타, 즉 프로필 사진을 자동으로 생성합니다 [6]. 이것은 기본적으로 당신의 이니셜을 넣어줍니다 [6]. 여기 보여드리겠습니다. 이것을 복원할 것입니다. 아, 사실 이것을 복원하면 안 됩니다. 빌드가 성공적이지 못했기 때문입니다 [6]. 아, 여기 있습니다. 제 성의 이니셜인 'bi'가 있습니다 [6]. 이것이 여기서 일어나는 일입니다. 제가 SQL 코드에서 잘 이해하지 못했고 찾아봐야 했던 부분이기 때문에 이것을 지적하는 것입니다 [6].
-- 그리고 다시 '수정 시도' 버튼을 누를 수 있는 것을 볼 수 있습니다 [6]. 오류를 복사해서 붙여넣을 필요가 없어서 좋습니다 [6]. 오류를 수정하지만 다른 문제가 있습니다 [6].
-- 자, 이것을 복원하고 문제가 무엇인지 보여드리겠습니다 [7]. 로그아웃한 다음 로그인 버튼을 누르면 멋진 로그인 및 등록 화면이 나타납니다 [7]. 예전에는 이런 화면 하나를 만드는 데 한 시간 반짜리 비디오 전체를 사용했는데, 이제는 그냥 만들어졌습니다. 정말 멋집니다 [7]. 등록 버튼을 누르고 이메일을 입력하면, 이메일을 확인하고 여기에서 확인을 눌러야 합니다 [7]. 그러나 기본적으로 Lovable은 `localhost:3000`으로 보내는데, 우리가 앱을 구축하는 곳이 아닙니다 [7].
-- 이 화면에 도달하는 방법은 인증 및 URL 구성으로 이동하여 Lovable 앱의 URL을 붙여넣거나, 지금은 이메일 인증을 끌 수 있습니다 [7]. 그러려면 '로그인 및 가입'으로 이동하여 '이메일' 섹션으로 내려가서 '이메일 확인'을 끄면 됩니다 [7]. 그러면 이메일을 확인할 필요가 없을 것입니다 [7].
-- 앱을 실제로 출시할 때는 이 기능을 다시 켜야겠지만, 테스트 중에는 필요 없습니다 [7]. 이 팁은 상당한 시간을 절약해 줄 것입니다 [7]. 왜냐하면 제가 이 작업을 할 때, 처음에는 로컬호스트를 사용하지 말라고 지시했고, 그것은 뭔가 리팩토링했다고 했지만, 보시다시피 별로 달라진 것이 없었습니다 [7]. 사용자 메타데이터를 추가했지만, 그것도 별 도움이 되지 않았고, 유사 이메일을 생성했습니다 [7]. 이것은 실제 문제를 해결하지 못했습니다 [7]. 그리고 저는 계속 질문했지만, 답을 주지 않았고, 이러한 변경 사항들은 실제로 유용하지 않았습니다 [7].
-- 그래서 저는 이 문제를 Lovable을 통해 실제로 해결하지 못했습니다. 여기와 여기 사이에서 제가 한 일은 슈퍼베이스 문서를 읽는 것이었고, 그렇게 문제를 해결했습니다 [7]. 이것이 Lovable의 약점입니다. 이런 일을 할 때, 필요한 외부 코드와 잘 통합되어 있지 않다는 점입니다 [7]. 연결은 되어 있지만, 슈퍼베이스에 들어가서 설정을 변경해야 한다는 것을 알아야 합니다 [7]. 자동으로 알려주지는 않습니다. 적어도 제가 다시 읽기 전까지는 그렇게 생각했습니다 [7].
-- 그래서 첫 번째 오류 직전에 이 한 문장이 있습니다. 이것을 실제로 읽어봐야 합니다 [8]. "슈퍼베이스 콘솔에서 이메일 인증을 비활성화하는 것이 좋을 것입니다"라고 말했습니다 [8]. 그러니 오류가 발생하기 직전에 알려주었던 것입니다 [8]. 저는 오류가 발생하면 '수정 시도'를 누르고 오류 이전의 모든 것을 무시하는 습관이 생겼는데, 이는 이상적이지 않습니다 [8]. 제가 불평했던 내용이 이것 때문이라는 것을 인식해 주었으면 좋았을 텐데, 어쨌든 알려주었습니다 [8].
-- 이제 다음 기능을 사용하기 위해 다시 로그인하겠습니다 [8]. 현재 진행 상황을 알려드리자면, 처음 세 가지는 완전히 완료했습니다 [8]. 이제 제품 생성, 토큰을 사용한 제품 구매, 그리고 스트라이프 연결을 통한 토큰 구매를 해야 합니다 [8]. 저희 차트를 보면 사용자(users)와 제품(products)은 있지만, 제품 구매(product purchases), 토큰 구매(token purchase) 또는 이러한 연결은 아직 없습니다 [8].
-- 비록 우리가 아주 조금밖에 하지 않은 것처럼 보이지만, 백엔드를 설정하고 모든 것을 인증에 연결하는 것은 사소한 일이 아니기 때문에 사실 가장 복잡한 작업 중 일부를 완료한 것입니다 [8]. 물론 바이브 코딩으로 했기 때문에 사소한 일처럼 느껴지기도 합니다 [8]. 그리고 우리가 그렇게 잘 바이브 코딩할 수 있었던 이유는 이러한 종류의 작업이 모든 앱에서 일어나야 하는 것들이기 때문입니다 [8]. 그래서 일반적인 앱에 가까울수록 바이브 코딩이 더 잘 작동합니다. 훈련 데이터가 훨씬 더 많고 강화 학습이 더 많이 작용했기 때문입니다 [8].
-- 제가 생각하는 방식은 이렇습니다. 모든 앱에는 이 빨간색으로 표시된 무작위적인 것들이 많이 있고, 핵심에는 여러분의 앱에만 있는 이 녹색으로 표시된 멋진 독특한 것이 있습니다 [8]. 그리고 앱을 사용 가능하게 만들려면 그 독특한 것 주위에 많은 것을 구축해야 합니다 [8]. 저는 바이브 코딩이 무엇을 하는지 이렇게 봅니다. 프레임워크는 보일러플레이트 코드의 양을 줄여주고, 바이브 코딩은 이 많은 부분을 자동으로 채워줍니다 [8]. 그래서 여러분은 매번 작성해야 하거나 80%의 앱에 있는 것에 시간을 훨씬 덜 쓰고, 여러분의 앱을 독특하게 만드는 것에 더 많은 시간을 쓸 수 있습니다 [9].

-- 참고로, 이것이 리누스 토르발스(Linus Torvalds)와 같은 일부 사람들이 생성형 AI 및 바이브 코딩에 대해 그리 흥분하지 않는 이유이기도 합니다 [9]. 그들이 작업하는 분야에는 보일러플레이트가 많지 않기 때문에 그들에게는 그리 유용하지 않습니다 [9]. 네, 리액트 컴포넌트를 바이브 코딩하는 것은 매우 합리적입니다. 당신의 필요에 맞게 조금만 다르게 만들면 되는 리액트 컴포넌트가 수없이 많습니다 [9]. 리눅스 커널을 바이브 코딩하는 것을 상상할 수 있습니까? 아닙니다, 적어도 현재의 도구 세트로는 끔찍한 생각일 것입니다 [9].
-- 다시 앱으로 돌아가서, 다음으로 로그인한 사용자가 제품을 업로드할 수 있는 양식을 만들라고 요청했습니다 [9]. 그러자 승인해야 하는 SQL을 생성하고, 이미지 업로드를 허용하는 'product_images' 버킷을 생성합니다 [9]. 이것은 멋집니다. 이런 이미지를 업로드하려면 이미지를 제공하고 싶을 것이라는 것을 알고 있었기 때문입니다 [9]. 하지만 URL만 넣는 것이 아니라 직접 업로드할 수 있다는 점은 좋습니다 [9].
-- 가격을 추가했는데, 제가 원했던 것과는 달랐습니다. 그래서 아직 가격을 추가하지 말라고 말했습니다 [9]. 그러자 가격 열을 제거하고 업데이트했습니다. '확인'을 눌렀습니다 [9]. 참고로, 저는 매번 이것을 타이핑하지 않습니다. '확인' 버튼을 누르면 자동으로 타이핑됩니다 [9]. 오류가 발생하고, 수정됩니다 [9]. 새로운 것을 검토합니다. 이전 버전은 제가 충분히 잘 검토하지 못했지만, 이것이 바이브 코딩의 본질입니다 [9]. 만약 이것이 프로덕션 앱이었다면 아마 좀 더 신중했을 것입니다 [9].
-- 자, 성공했습니다. 로그인한 사용자를 위한 업로드 시스템이 생성되었습니다 [9]. 가서 어떻게 하는지 보겠습니다. 여기서 새로고침을 해야 합니다 [9]. '제품 추가'를 누르면, 이름, 설명, 제품 이미지를 입력할 수 있습니다 [9]. '회원 가입 확인'을 판매해 보겠습니다. '제품 생성'을 누르면, 나타나고 저장됩니다 [9]. 새로고침해도 여전히 있습니다. 보시다시피, 이것은 분명히 맞춤형입니다. 채널을 보셨다면 알아볼 것입니다 [10].

-- 이제 우리가 원했던 6가지 기능 중 4가지를 완료했습니다 [10]. 다음은 토큰을 사용하여 제품을 구매하는 것입니다. 아, 그리고 제품이 생성자에게 속하도록 하고 싶습니다 [10]. 그렇게 되었는지 다시 확인해 보겠습니다 [10]. 마이그레이션에서, 네, 업로드되고 있고, 'products' 테이블을 수정하여 'user_ID UUID'를 추가하고 있습니다 [10]. 괜찮습니다 [10].
-- 확인을 위해 슈퍼베이스에서 코드를 확인할 수도 있습니다. 실제 테이블 편집기로 가서 'products' 테이블로 이동하여 가장 최근에 추가된 것을 보겠습니다 [10]. 아, 이것으로는 정렬되지 않습니다. 어쨌든, 가장 최근에 추가된 것은 '회원 가입 확인'이고, 사용자 ID가 있습니다. 제가 이전에 만든 것과 동일하므로 사용자 ID를 연결하도록 올바르게 설정되었습니다 [10].
-- 그래서 5번, 토큰을 사용하여 제품을 구매하는 것으로 진행하겠습니다 [10]. 저는 이것을 그냥 말하면 아마 제가 원하는 대로 하지 않을 것이라는 것을 알기 때문에 좀 더 자세히 설명했습니다 [10]. 그래서 사용자 테이블에 사용자당 현재 토큰 수를 저장하고, 제품이 비용으로 지불해야 할 토큰 수를 가지도록 하고 싶다고 했습니다 [10]. 제 생각에는 제가 이렇게 하지 않았다면 아마 두 번째 부분만 했을 것 같습니다 [10].
-- 그것은 '프로필'과 '제품'에 모두 이것들을 추가합니다. 훌륭합니다 [10]. 그리고 그렇게 한 후, 제품 구매 기능을 구현합니다 [10]. 코드를 보면, 이것은 실제로 제가 원하는 것이 아닙니다 [10]. 제품을 구매하는 것이죠? 그리고 잠시 후에 보게 될 몇 가지 오류가 실제로 있을 것입니다 [10]. 네, 'purchaseProduct'라고 불리는데, 실제로는 이걸 하지 않습니다. 아, 괜찮습니다. 일부는 있지만, 단지 빼기만 하고 구매된 것을 실제로 보여주는 기록이 없습니다 [10]. 그리고 흥미롭게도 그렇게 하라는 권장 사항도 있습니다 [10]. 이것이 완전하지 않다는 것을 알았기 때문에 저는 이것을 이전에 읽지 않았지만, 만약 이것을 읽고 있었다면 제가 결국 했던 일을 할 아이디어를 얻었을 것입니다 [10].
-- 여기서 우리는 먼저 오류가 있다는 것을 알게 될 것입니다 [10]. 그래서 그냥 고칩니다 [10]. 그리고 여기서부터 정말 이상한 일들이 시작됩니다. 타입스크립트 오류가 발생하고, 저는 그것과 꽤 오랫동안 씨름했습니다 [10].
-- 이 오류를 살펴보겠습니다. 'product service'의 인수는 'string' 타입인데, 'never' 타입의 매개변수에 할당할 수 없다는 내용입니다 [11]. 여기서 저는 우리 코드를 이해하지 못했기 때문에 꽤 막혔습니다. 그래서 실제로 GitHub에서 '보기'를 클릭하고 코드를 이해하려고 노력했습니다 [11]. 거기서 기트 스냅샷(GS)을 볼 수 있고, 커밋을 볼 수 있고, 다른 브랜치를 볼 수 있습니다 [11]. 그리고 어떤 단계에서든 어떤 모습인지 볼 수 있습니다. 실제로 여기에 커서를 놓고 작업을 시작할 수도 있습니다. 그것은 우리가 할 수 있는 일입니다 [11]. 아, 흥미롭게도 이것은 메인 브랜치의 일부로 되돌려집니다. 프로덕션이라면 원하지 않을 것입니다 [11]. 다시 말하지만, 이것은 첫 부분을 생성하고 많은 보일러플레이트를 처리하는 데 더 좋습니다 [11]. 그들은 코드베이스를 가져오는 기능이 출시될 것이라고 말하지만, 아직 제 코드베이스에 있는 많은 것들을 신뢰하지는 않을 것입니다 [11].
-- 어쨌든, 코드를 봤는데 무엇이 잘못되었는지 이해할 수 없었습니다 [11]. 그리고 'product purchase RPC'에서 무슨 일이 일어나는지 추적하려고 여러 번 주고받았습니다 [11]. 결국, 우리는 그것을 원하지 않는다는 것을 깨달았습니다 [11]. 그래서 많은 노력 끝에 'purchaseProduct'를 제거했습니다 [11]. 네, 여기서 제거하는 것 같습니다. 아닙니다, 그들은 계속 타입스크립트 오류라고 생각하지만, 아니요, 오류는 이것이 작동하지 않는다는 것입니다 [11].
-- 다시 말하지만, 작동하도록 만들 수도 있습니다. 저는 슈퍼베이스 RPC 함수에 대해 충분히 알지 못합니다 [11]. 그래서 계속 주고받았습니다. 만약 LLM(대규모 언어 모델)과 작업해 본 적이 있다면 이런 종류의 루프를 인식할 것입니다 [11]. 인간도 때로는 이런 루프에 빠지지만, LLM을 그 루프에서 벗어나게 하는 것은 더 어렵습니다 [11]. 계속 진행하다가 결국 '야, 완전히 다른 걸 해보자'고 말했고, 이것이 작동한 것 같습니다 [11]. 네, RPC를 제거하고 직접 데이터베이스 트랜잭션을 수행했습니다 [11]. 그것이 결국 작동했습니다 [11].
-- 자, 이것을 복원하겠습니다. 좋습니다. 그리고 토큰이 이제 할당된 것을 볼 수 있습니다 [11]. 아, 이것은 토큰이 0개입니다. 편집 기능이 없으므로 변경할 수 없습니다 [11].

-- AI 엔지니어링 로드맵을 구매하겠습니다. '구매'를 누르면, 118개에서 113개의 토큰이 남았습니다 [12]. 여기서 저는 '비기술자였다면 이것을 알아내지 못했을 거야'라고 정말로 생각했습니다 [12]. 이것이 바이브 코딩의 한계 중 하나입니다. 어떤 수준에서는 무슨 일이 일어나고 있는지 이해해야 합니다. 그렇지 않으면 막힐 것입니다 [12]. 그러면 너무나 답답합니다. 시속 60마일로 달리다가 갑자기 멈추고 오랫동안 막혀 있게 됩니다 [12]. 프로그래머라면 그런 것에 익숙하고 막히지 않는 요령을 개발하지만, 이전에 프로그래밍을 해본 적이 없다면 이것은 매우 답답할 것입니다 [12]. 특히 LLM이 '아, 해결했어'라고 말했는데 아무것도 변하지 않을 때 더욱 그렇습니다 [12]. 잠시 후에 보겠지만, 계속 해결했다고 말하지만, 댓글만 변경됩니다 [12].
-- 이제 'product_purchases' 테이블을 만들어 사용자가 구매한 모든 제품의 기록을 보관하고 싶습니다 [12]. 그래서 사용자 ID, 제품 ID, 구매 가격, 토큰 수를 알려주고, 구매가 이루어질 때 새 기록을 생성하도록 합니다 [12]. 그러면 이것이 모든 것을 처리해 줍니다 [12].
-- 오류가 발생했습니다 [12]. 흥미롭게도 우리는 오류를 처리하라고 지시하지 않고, 단지 '구매 내역 페이지를 만들어라'고 말합니다 [12]. 그리고 그렇게 만듭니다 [12]. 여전히 오류가 있습니다 [12]. 그리고 나서 오류를 수정합니다 [12]. 이 오류에는 재미있는 점이 있었습니다. 'database'라는 중복 식별자 오류가 있었고, 저는 그것을 고치기 위해 계속 방법을 찾으려 했지만, 계속 오류가 발생했습니다 [12]. 꽤 답답했습니다 [12]. 결국 저는 '음, 그래도 실행되잖아, 계속하자'라고 생각했습니다 [12].
-- 여전히 오류가 있지만 페이지는 여전히 실행됩니다 [12]. 여기서 복원을 눌러보세요 [12]. 아, 아마도 미리보기인가요? 아, 네, 그렇습니다. 코드를 종료해야 했습니다 [12]. 여기서 구매 내역으로 이동하여 구매 내역을 로드할 수 있고, 오류가 있는데도 작동합니다 [12]. 그래서 저는 계속 진행했고, 헤더 내비게이션 바에 링크를 추가하고, 네 가지 팩 크기로 토큰을 구매하는 작업을 시작했습니다 [12]. 그것은 잠시 후에 설명하겠습니다 [12]. 하지만 먼저, 이 오류가 계속 발생하다가 결국 사라진다는 것을 보여드리고 싶습니다. 왜 그런지는 확실하지 않습니다 [13].

-- 어쨌든, 그것이 경험의 일부입니다 [13]. 작동하는지 시연해 볼 수 있습니다. '회원 가입 확인'으로 이동하여 구매합니다. 토큰은 줄어들지 않지만, 구매 내역에 나타납니다 [13]. 여기서 보면, 다시 로드하면 제품 구매 내역에 나타날 것입니다 [13].
-- 마지막으로 추가할 것은 스트라이프에 연결하여 토큰을 구매하는 것입니다 [13]. 좋은 소프트웨어 개발자라면 누구나 그렇듯이, 우리는 이것을 나누어서 코더, 이 경우에는 LLM이 혼동하지 않도록 할 것입니다 [13]. 먼저 토큰 구매를 데이터베이스에 저장할 것입니다 [13]. 각 토큰 구매에는 사용자 ID가 있어야 합니다 [13]. 그래서 새 테이블을 만듭니다 [13]. 가격을 가져옵니다. 아, 사실 가격은 맞고, 'amount'는 정수입니다. 그래서 이것을 올바르게 처리합니다 [13].
-- 이것을 복원하면 '토큰 구매' 페이지가 나타날 것이고, 우리가 요청했던 대로 5개부터 100개까지 네 가지 티어가 있을 것입니다 [13]. 현재 113개의 토큰이 있습니다. 구매할 수 있습니다. 118개가 있지만 실제 돈을 지불한 것은 아닙니다 [13]. 이제 스트라이프를 사용하여 지불하고 싶다고 말합니다 [13]. 그리고 API 키를 요청합니다 [13]. 이 경우 테스트 프라이빗 키를 사용하고 있습니다 [13]. 물론 이 테스트 키는 백엔드에서 사용되므로 프런트엔드와 공유되지 않습니다 [13]. 하지만 이것은 프로덕션으로 배포하기 전에 잘 확인해야 하는 코드 유형입니다 [13].
-- 그렇게 합니다. 복원하겠습니다 [13]. '토큰 구매'로 가서 여기를 누르면 체크아웃을 시작하지 못했습니다 [13]. 제가 그것을 알려주자, '오류가 무엇인지 안다'고 말합니다 [13]. 그런데 여전히 작동하지 않습니다. 여전히 작동하지 않습니다 [13]. 오류 로깅은 많이 하지만 고치지는 않습니다 [13]. 계속 주고받습니다 [13]. 그리고 이것이 실제로 고쳐진 부분이라고 생각합니다 [13]. 여기를 누르면, 아, 체크아웃 URL이 반환되지 않았습니다 [14]. 이전 문제를 해결했고, 이제 체크아웃 페이지로 이동하기 위해 이것을 사용하라고 말합니다 [14]. 기술 지식을 사용해야 했습니다. 스트라이프 문서를 살펴보고, 그것이 우리에게 보내는 데이터를 확인했습니다 [14]. 인스펙터를 열었습니다 [14].

-- 그러다가 어느 시점에서 실제로 고쳐집니다 [14]. 그런데 이제 체크아웃 페이지가 제대로 표시되지 않습니다 [14]. 무슨 말인지 보여드리겠습니다 [14]. 여기로 가면 이렇게 보입니다 [14]. 이것을 디버깅하는 데 많은 시간을 보냈습니다 [14]. 그리고 일부를 보면, 단지 주석만 변경하고 있는 것을 알 수 있습니다 [14]. 작동하지 않는다고 말했지만, 그 코드 자체는 자신이 생각하기에 맞기 때문입니다 [14]. Raw로 가면 매번 완전히 새롭게 생성하지만, 차이점은 단지 주석과 공백뿐입니다 [14].
-- 마침내 제가 알아낸 것은 이 버튼을 클릭하여 새 탭에서 열어야 한다는 것입니다 [14]. 그러면 실제로 작동할 것입니다 [14]. iframe에 있는 것 때문에 작동하지 않았던 것 같습니다 [14]. 스트라이프 체크아웃 페이지를 만들 때는 여기서 테스트해야 합니다 [14]. 그래서 그렇습니다. 실제로 작동합니다 [14]. 그리고 이것은 테스트 키이므로, 실제로 지불하고 싶다면 사용할 수 있는 테스트 신용카드가 있습니다 [14]. 제가 작성했고, 카드 소지자 이름을 입력해야 합니다 [14]. 그리고 승인할 것이고, '처리 중'이라고 표시된 다음 새 잔액이 나타납니다. 훌륭합니다 [14].
-- 이것을 프로덕션에 푸시하고 실제 스트라이프 API 키를 입력하면 실제 신용카드를 받고 실제 결제를 처리할 수 있습니다 [14]. 이 모든 것이 바이브 코딩으로 이루어졌습니다 [14]. 물론 바이브 코딩된 결제 코드를 반드시 신뢰하지는 않을 것이므로, 직접 코드를 읽어보고 다른 LLM에 피드하여 문제가 있는지 물어볼 것입니다 [14]. 하지만 작동합니다. 이것은 작동합니다 [14]. 솔직히 바이브 코딩만으로 이 정도까지 할 수 있다는 것에 놀랐습니다 [14].
-- 끝내기 전에 몇 가지 한계를 언급하고 싶습니다. 우리가 이미 이야기했지만, 비기술자라면 처음에는 엄청나게 많은 일을 할 수 있게 되어 좋을 것이지만, 디버깅을 위해 기술 지식이 필요한 부분에 도달하면 벽에 부딪히는 것과 같을 것입니다 [14]. 이는 기반 모델이 개선되고 Lovable과 같은 팀이 그러한 격차를 극복하는 데 도움이 되는 더 많은 기능을 추가하면서 나아질 것입니다 [15].
-- 다른 한계는 코드베이스가 커질수록 제 경험상 LLM이 다루는 능력이 떨어졌다는 것입니다 [15]. 아마 내부적으로 뭔가 다른 것을 하고 있을 수도 있고, 사람들이 이것을 처리하는 기술을 개발하고 있을 수도 있지만, 제 경험상 작업해야 할 코드의 양이 많아질수록 품질이 떨어집니다 [15]. 그리고 이것이 완전히 바이브 코딩된 경우 더 빨리 문제가 될 수 있습니다 [15]. 보시다시피, 우리가 사용하지 않는 이 모든 UI 컴포넌트들을 그냥 넣어 놓았습니다 [15]. 그리고 LLM, 특히 클로드(Claud)와 같은 모델(클로드가 현재 최고의 코더입니다)은 코드를 출력하는 것을 정말 좋아하기 때문에 바이브 코딩을 하면 코드가 더 빨리 증가하는 경향이 있습니다 [15]. 그리고 보통 올바른 코드이지만, 인간이 작성하는 것보다 일반적으로 더 길게 만듭니다 [15].
-- 다음으로 제가 바이브 코딩하거나 다루었으면 하는 것이 무엇인지 댓글로 알려주세요 [15]. 좋아요를 누르고 구독해 주세요 [15]. 다음에 뵙겠습니다 [15].

---
-- 감사합니다.

---

**Vibe 코딩으로 풀스택 앱 개발하기: 기술적 사용자와 비기술적 사용자 모두를 위한 통찰**

최근에 4시간도 채 안 되는 시간 안에 코드 한 줄도 직접 작성하지 않고 데이터 저장, 이미지 업로드, 심지어 신용카드를 통한 구매 기능까지 갖춘 풀스택 애플리케이션을 Vibe 코딩으로 개발하는 과정을 시연했습니다. 이 경험은 **Vibe 코딩이 단순한 도구가 아니라 기술이라는 점**을 분명히 보여주며, 기술적 지식이 있다면 훨씬 더 큰 이점을 얻을 수 있지만, 그것이 필수는 아니라는 것을 강조합니다 (영상 전반부에서 설명된 바와 같이).

**Vibe 코딩의 첫 번째 교훈:** 실제 코딩과 마찬가지로, **작동하는 간단한 것부터 시작하는 것이 중요합니다** (영상의 첫 번째 부분과 두 번째 부분에서 강조된 바와 같이). 처음에는 원하는 바를 입력했지만, 의도치 않게 카테고리나 추천 제품 기능 등 불필요한 기능들이 생성되었습니다. 심지어 페이지가 제대로 제거되지 않거나, 제거된 내용이 의존하는 다른 부분에서 타입 오류를 유발하는 문제도 발생했습니다. 이는 단순히 링크만 제거하고 실제 코드는 남겨두어 빌드 실패로 이어지기도 했습니다 (초반부 영상 내용에서 상세히 설명됨). '수정 시도(try to fix it)' 버튼이 있어 오류를 해결하려 했지만, 원래 목표와는 달리 불필요한 타입을 다시 추가하는 방식으로 해결되는 경우도 있었습니다 (영상의 첫 번째 섹션에서 언급됨).

**구조화된 접근 방식과 개발 도구**

이러한 시행착오 끝에, 저는 **단계별 접근 방식**을 채택했습니다. 이는 마치 일반적인 프로젝트를 계획하는 것처럼, 컴퓨터에 자연어로 지시하는 방식입니다 (영상의 두 번째 부분에서 설명된 바와 같이). 저는 다음과 같은 목표를 설정했습니다:
*   제품 목록을 로컬 파일에서 가져와 간단하게 표시 (영상의 두 번째 섹션에서 언급됨).
*   Superbase라는 SaaS 데이터베이스에서 제품을 가져오기 (영상의 두 번째 섹션에서 언급됨).
*   사용자 로그인 및 로그아웃 기능 구현 (영상의 두 번째 섹션에서 언급됨).
*   사용자가 제품을 생성하고, 커버 이미지를 업로드하며, 해당 제품을 생성한 사용자와 연결 (영상의 두 번째 섹션에서 언급됨).
*   토큰을 사용하여 제품 구매 기능 구현 (영상의 두 번째 섹션에서 언급됨).
*   Stripe를 통해 신용카드로 토큰 구매 기능 연결 (영상의 두 번째 섹션에서 언급됨).

이 모든 작업을 수동으로 한다면 4시간 이상 걸릴 복잡한 작업입니다 (영상의 두 번째 섹션에서 언급됨). 기술적 사용자로서, 저는 사용자, 제품, 제품 구매, 토큰 구매 간의 관계를 나타내는 **백엔드 다이어그램**을 미리 구상했습니다. 이러한 **프레임워크를 마음에 두고 있으면 Vibe 코딩 시 컴퓨터가 엉뚱한 방향으로 가지 않도록 돕는 데 큰 도움**이 됩니다. Vibe 코딩은 세부 사항을 처리해주지만, 명확한 지시가 없으면 의도하지 않은 세부 사항이나 제품 방향을 만들어낼 수 있기 때문입니다 (영상의 두 번째 섹션에서 강조됨).

이번 프로젝트에는 **Lovable.dev**라는 AI Vibe 코딩 도구를 사용했습니다 (영상의 두 번째 섹션에서 언급됨). 이 도구는 Superbase 백엔드 및 Stripe와 연동되어 실제로 작동하는 앱을 만들 수 있다는 점이 특징입니다. 이는 클로드 프로젝트(Claude projects)처럼 자바스크립트 기반의 프론트엔드 앱만 만들 수 있는 도구와 차별화되는 점입니다 (영상의 두 번째 섹션에서 설명됨). Figma 파일 가져오기 등 다른 기능도 있지만, 아직 다 탐색하지는 못했습니다 (영상의 두 번째 섹션에서 언급됨). Lovable은 이 영상의 스폰서였지만, 저는 항상 제품에 대해 솔직하게 이야기할 수 있는 조건에서만 스폰서십을 수락합니다. Lovable 팀은 제품에 대한 자신감이 매우 높았고, 실제로도 꽤 좋았습니다 (영상의 세 번째 섹션에서 밝힘).

**간단하게 시작하고 점진적으로 구축하기**

새로운 프롬프트는 "디지털 제품을 판매하는 마켓플레이스를 구축하고 있으며, **간단하게 만들고 싶다**"고 명시했습니다. 또한 제품 타입에 네 가지 키(key)와 그 값만 포함하고, 카테고리 필터링이나 추천 화면은 원하지 않으며, **오직 인덱스(index)만 원한다**고 구체적으로 지시했습니다 (영상의 세 번째 섹션에서 설명됨). 이 지시를 통해 깔끔한 인덱스 페이지가 생성되었고, 샘플 데이터도 디지털 제품에 적합하게 잘 채워졌습니다 (영상의 세 번째 섹션에서 언급됨). 코드 레벨에서는 `Services/productService.ts` 파일에 모든 제품 정보가 포함되어 있었습니다 (영상의 세 번째 섹션에서 언급됨).

다음으로 각 제품에 대한 개별 페이지를 생성하도록 지시했는데, 이는 매우 쉽게 구현되었습니다 (영상의 세 번째 섹션에서 설명됨). 생성된 코드는 **원시(Raw) 코드 전체 보기**와 **변경 사항만 볼 수 있는 Diff 보기** 두 가지 방식으로 확인할 수 있습니다 (영상의 세 번째 섹션에서 설명됨). Diff 보기는 어떤 부분이 추가되거나 변경되었는지 이해하는 데 매우 유용합니다 (영상의 세 번째 섹션에서 강조됨). Lovable의 주요 타겟 고객은 비기술적 사용자이기 때문에 코드를 직접 보는 것이 큰 도움이 되지 않을 수 있지만, 개발 속도를 높이려는 기술적 사용자에게는 매우 유용합니다 (영상의 네 번째 섹션에서 설명됨).

**백엔드 연결: Superbase의 활용**

이어서 Superbase에 연결하여 제품을 가져오도록 했습니다 (영상의 네 번째 섹션에서 언급됨). Superbase는 월 10달러 정도의 비용이 드는 풀스택 데이터베이스 솔루션으로, 백엔드 지식이 없어도 사용할 수 있습니다. 물론 **데이터베이스 테이블이 어떻게 연결되는지에 대한 개념은 이해하고 있는 것이 좋습니다**. Superbase는 데이터베이스 설정과 관련된 번거로운 작업들을 모두 추상화해 줍니다. 또한 인증(Auth) 및 스토리지(Storage) 기능도 제공하여 제품 이미지 등을 저장할 수 있습니다 (영상의 네 번째 섹션에서 설명됨). Superbase는 **클로드 프로젝트나 다른 프론트엔드 전용 빌더보다 강력한 이유**이기도 합니다 (영상의 네 번째 섹션에서 언급됨).

처음에는 Superbase에 연결하기만 했지만, 실제로 제품 테이블을 생성하고 데이터를 로드하도록 추가 지시를 내렸습니다. 이때도 불필요한 필터링 기능 등을 피하기 위해 의도적으로 간단하게 유지했습니다 (영상의 다섯 번째 섹션에서 설명됨). Superbase 작업 시, Vibe 코딩 도구는 **SQL 스크립트**를 보여주고 승인을 요청합니다. 기술적 지식이 있는 사용자에게는 코드를 검토하는 좋은 기회이지만, 비기술적 사용자에게는 무섭거나 반대로 너무 무관심할 수 있는 부분입니다 (영상의 다섯 번째 섹션에서 언급됨). 저의 경우, 처음에 UUID 형식 오류가 발생했지만, 시스템이 이를 자동으로 감지하고 수정하여 성공적으로 해결했습니다 (영상의 다섯 번째 섹션에서 설명됨). Vibe 코딩은 마치 **빠르게 일하는 유능한 개발자와 함께 일하는 엔지니어링 매니저**가 되는 것과 같다고 비유할 수 있습니다 (영상의 다섯 번째 섹션에서 언급됨). 데이터베이스에 연결되면서 기존의 목업 데이터는 제거되고 Superbase에서 데이터를 가져오도록 코드가 업데이트되었습니다. 저는 이를 **마치 라이브러리 코드가 내 코드베이스에 맞춤형으로 작성된 것**처럼 생각합니다 (영상의 다섯 번째와 여섯 번째 섹션에서 설명됨). 물론 모든 라이브러리 코드를 이해할 필요는 없지만, **보안 취약점이나 버그를 유발할 수 있는 부분은 코드를 검토하는 것이 중요**합니다 (영상의 여섯 번째 섹션에서 강조됨).

**인증 기능 구현의 도전과 통찰**

백엔드 연결 후, Superbase를 이용한 인증 워크플로를 구축했습니다. 여기에는 프로필 테이블 설정이 포함됩니다 (영상의 여섯 번째 섹션에서 언급됨). Superbase의 인증 기능은 데이터베이스 테이블에 직접 보이지 않고 별도로 처리됩니다 (영상의 여섯 번째 섹션에서 설명됨). 회원가입 및 로그인 화면은 자동으로 멋지게 생성되었습니다. 과거에는 이러한 기능을 구현하기 위해 한 시간 반짜리 비디오를 만들어야 했지만, 이제는 Vibe 코딩으로 쉽게 해결되었습니다 (영상의 일곱 번째 섹션에서 언급됨).

가장 큰 난관 중 하나는 **이메일 인증 문제**였습니다. 기본적으로 Superbase는 확인 이메일을 `localhost:3000`으로 보내는데, 이는 실제 개발 환경과 다릅니다. 이 문제를 해결하기 위해 Superbase 콘솔의 'Authentication' 섹션에 있는 'URL Configuration'에서 앱의 URL을 붙여넣거나, **테스트 중에는 'Sign in methods'의 'Email' 섹션에서 'Confirm email' 옵션을 꺼두는 것이 유용합니다** (영상의 일곱 번째 섹션에서 상세히 설명됨). Lovable은 이 문제를 직접 해결해주지 못했습니다. 여러 번 시도했지만, 코드 변경은 사용자 메타데이터를 추가하거나 가상 이메일을 생성하는 등 실제 문제를 해결하지 못했습니다. 결국 저는 Superbase 문서를 직접 읽고 문제를 해결해야 했습니다 (영상의 일곱 번째 섹션에서 설명됨).

흥미롭게도, Vibe 코딩 도구는 처음 오류가 발생하기 전에 "Superbase 콘솔에서 이메일 인증을 비활성화하는 것이 좋을 수 있습니다"라고 **미리 경고**했습니다. 하지만 저는 오류가 발생하면 '수정 시도' 버튼만 누르고 앞선 모든 메시지를 무시하는 습관이 있었기에 이 중요한 조언을 놓쳤습니다 (영상의 여덟 번째 섹션에서 밝힘). 이는 **AI 도구를 사용할 때도 전체적인 맥락과 메시지를 주의 깊게 읽는 것이 중요함**을 시사합니다.

**Vibe 코딩의 핵심 가치: 반복적인 작업 자동화**

현재까지 사용자 및 제품 관련 핵심 기능이 구현되었습니다. 저는 이러한 부분들이 **모든 앱에 필요한 기능이기에 Vibe 코딩으로 구현하기 쉬웠다**고 생각합니다. 이는 훈련 데이터에 해당 내용이 풍부하고 강화 학습이 잘 되어 있기 때문입니다 (영상의 여덟 번째 섹션에서 설명됨).

Vibe 코딩은 마치 **프레임워크가 보일러플레이트(반복적인 상용구 코드)를 줄여주는 것처럼, 더 나아가 그 보일러플레이트를 직접 채워주는 역할**을 합니다 (영상의 여덟 번째 섹션에서 비유적으로 설명됨). 이를 통해 개발자는 **앱을 독특하게 만드는 핵심 기능(녹색 영역)에 더 많은 시간을 할애**할 수 있고, 매번 작성해야 하는 또는 대부분의 앱에 공통적으로 포함되는 부분(빨간색 영역)에 대한 시간을 줄일 수 있습니다 (영상의 여덟 번째와 아홉 번째 섹션에서 시각적으로 설명됨). 예를 들어, React 컴포넌트를 Vibe 코딩하는 것은 매우 합리적입니다. 하지만 리눅스 커널과 같이 보일러플레이트가 거의 없는 복잡한 시스템을 Vibe 코딩하는 것은 현재 도구로는 적합하지 않습니다 (영상의 아홉 번째 섹션에서 언급됨).

**제품 생성 및 구매 기능 구현**

다음으로 로그인한 사용자가 제품을 업로드할 수 있는 폼을 만들도록 요청했습니다 (영상의 아홉 번째 섹션에서 언급됨). Vibe 코딩 도구는 제품 이미지를 업로드할 수 있는 스토리지 버킷인 `product_images`를 생성하는 SQL까지 제안하며, 이는 매우 유용했습니다 (영상의 아홉 번째 섹션에서 설명됨). 또한, 제가 원하지 않았던 '가격' 필드를 추가하려 했을 때, **'아직 가격을 추가하지 마라'고 지시하여 즉시 수정**할 수 있었습니다 (영상의 아홉 번째 섹션에서 설명됨). 때때로 오류가 발생했지만, 시스템이 이를 수정해주었고, 저는 새로운 변경 사항을 검토했습니다. 프로덕션 앱이었다면 더 신중했겠지만, Vibe 코딩의 특성상 빠르게 시도하고 수정하는 것이 가능했습니다 (영상의 아홉 번째 섹션에서 언급됨). 성공적으로 제품 업로드 시스템이 구축되었고, 사용자는 이름, 설명, 이미지와 함께 제품을 생성하고 저장할 수 있게 되었습니다 (영상의 아홉 번째와 열 번째 섹션에서 시연됨).

제품이 생성자에게 귀속되도록 하는 기능도 중요했습니다. 제품 테이블에 `user_id`를 추가하여 사용자 ID와 연결하도록 마이그레이션이 올바르게 이루어졌음을 Superbase의 실제 테이블 편집기에서 확인했습니다 (영상의 열 번째 섹션에서 설명됨).

그다음은 **토큰을 사용하여 제품을 구매하는 기능**입니다. 저는 사용자 테이블에 현재 토큰 수를 저장하고, 제품에 토큰 비용을 지정하도록 구체적으로 지시했습니다. 만약 이러한 세부 지시가 없었다면, 아마도 제품 가격만 설정했을 것이라고 예상했습니다 (영상의 열 번째 섹션에서 설명됨). 시스템은 프로필(사용자) 테이블과 제품 테이블 모두에 필요한 필드를 추가했으며, 제품 구매 기능을 구현했습니다 (영상의 열 번째 섹션에서 언급됨).

초기 구매 기능 구현에서는 오류가 발생했습니다. 코드 자체는 `purchaseProduct`라는 함수를 가지고 있었지만, 실제로 구매 내역을 기록하는 부분은 없었습니다. Vibe 코딩 도구는 이 문제를 인식하고 **구매 내역 기록을 위한 권장 사항을 스스로 제시**하기도 했습니다 (영상의 열 번째 섹션에서 설명됨).

여기서 **가장 큰 난관 중 하나**가 발생했습니다. 타입스크립트(TypeScript) 오류가 계속 발생했는데, `argument of type string is not assignable to parameter of type never`라는 메시지였습니다. 저는 이 문제를 해결하기 위해 **GitHub에서 코드를 직접 확인하고 이해하려 노력**했습니다. Vibe 코딩 도구는 커밋 이력과 브랜치를 볼 수 있는 기능을 제공하여 특정 단계의 코드를 검토할 수 있게 합니다 (영상의 열한 번째 섹션에서 설명됨).

하지만 코드 자체를 이해하기 어려웠고, Vibe 코딩 도구와 **여러 차례 질문-답변 루프(loop)에 갇혔습니다**. 도구는 계속 타입스크립트 오류라고 주장하며 주석만 변경하는 등 실제 문제 해결에는 도움이 되지 않았습니다. 결국 저는 Superbase의 원격 프로시저 호출(RPC) 대신 **직접 데이터베이스 트랜잭션을 수행하도록 완전히 다른 접근 방식**을 시도하라고 지시했습니다. 그리고 **이 방식이 비로소 작동했습니다** (영상의 열한 번째 섹션에서 상세히 설명됨). 이 부분이 **비기술적 사용자라면 정말 막혔을 것이라고 생각되는 지점**이었습니다. Vibe 코딩은 60마일의 속도로 달리게 해주지만, 막히는 지점에 도달하면 마치 벽에 부딪힌 듯 멈춰 서게 됩니다. 프로그래머는 이러한 난관을 극복하는 방법을 알고 있지만, 비프로그래머에게는 엄청난 좌절감을 줄 수 있습니다 (영상의 열두 번째 섹션에서 강조됨).

구매 기능이 작동한 후, 사용자의 모든 제품 구매를 기록하는 **`product_purchases` 테이블**을 만들도록 했습니다. 여기에는 사용자 ID, 제품 ID, 구매 가격, 토큰 수 등이 포함됩니다. 구매가 이루어질 때마다 새로운 기록이 생성되도록 했습니다 (영상의 열두 번째 섹션에서 설명됨). 오류가 발생하기도 했지만, 페이지 자체는 여전히 잘 작동했습니다. 저는 오류를 무시하고 진행했고, 결국 해당 오류는 스스로 사라졌습니다 (영상의 열두 번째와 열세 번째 섹션에서 언급됨). 구매 내역 페이지를 만들고 헤더 내비게이션 바에 링크를 추가하는 작업도 진행했습니다 (영상의 열두 번째 섹션에서 언급됨).

**Stripe를 통한 토큰 구매 및 최종 디버깅**

마지막으로 **Stripe에 연결하여 토큰을 구매하는 기능**을 추가했습니다. 좋은 소프트웨어 개발자처럼, 이 작업을 작은 단위로 쪼개어 AI 모델이 혼동하지 않도록 했습니다. 먼저, 토큰 구매 내역을 데이터베이스에 저장하도록 했습니다. 새로운 테이블이 생성되었고, 가격과 금액(정수)이 올바르게 처리되었습니다 (영상의 열세 번째 섹션에서 설명됨). 이 기능을 통해 토큰 구매 페이지가 생성되었고, 5개부터 100개까지 네 가지 토큰 묶음이 제공되었습니다 (영상의 열세 번째 섹션에서 언급됨).

Stripe 결제 기능을 테스트하기 위해 테스트용 비공개 API 키를 사용했습니다 (영상의 열세 번째 섹션에서 언급됨). 결제 초기화에 실패하는 오류가 발생했고, 시스템은 오류 로깅만 할 뿐 실제 수정은 하지 못하는 상황이 반복되었습니다 (영상의 열세 번째 섹션에서 설명됨). 저는 **Stripe 문서와 네트워크 인스펙터를 통해 데이터 흐름을 확인하며 기술적 지식을 활용**해야 했습니다. 결국 결제 URL을 얻는 문제는 해결되었지만, 이번에는 **결제 페이지가 제대로 표시되지 않는 문제**가 발생했습니다 (영상의 열네 번째 섹션에서 설명됨).

이 디버깅 과정에서 Vibe 코딩 도구는 **오류를 해결하지 못하고 주석만 변경하거나 공백을 조정하는 등 의미 없는 코드 변경**을 반복했습니다. 이는 제가 '작동하지 않는다'고 말했지만, 도구의 관점에서는 코드가 이미 자신이 생각하는 대로 작동하고 있었기 때문입니다 (영상의 열네 번째 섹션에서 상세히 설명됨). 결국 제가 직접 발견한 해결책은 **결제 페이지를 새 탭에서 열어야만 정상적으로 작동한다**는 것이었습니다. iframe 내에서 제대로 작동하지 않았던 것 같습니다 (영상의 열네 번째 섹션에서 강조됨). 새 탭에서 테스트용 신용카드 정보로 결제를 시도한 결과, **성공적으로 결제가 처리되고 토큰 잔액이 업데이트되는 것을 확인**할 수 있었습니다 (영상의 열네 번째 섹션에서 시연됨).

물론, 프로덕션 환경에 배포하기 전에 Vibe 코딩된 결제 코드를 그대로 신뢰하지는 않을 것입니다. 직접 코드를 검토하거나 다른 LLM에 보안 문제를 검토해달라고 요청하는 것이 현명할 것입니다 (영상의 열네 번째 섹션에서 강조됨). 하지만 **Vibe 코딩만으로 이 정도 수준의 앱을 만들 수 있다는 사실에 놀랐습니다** (영상의 열네 번째 섹션에서 언급됨).

**Vibe 코딩의 한계점**

이러한 놀라운 경험에도 불구하고, Vibe 코딩에는 몇 가지 한계점이 있습니다 (영상의 열네 번째 섹션에서 언급됨):
*   **기술적 지식의 필요성:** 비기술적 사용자에게 Vibe 코딩은 처음에는 엄청난 생산성을 제공하지만, 디버깅이 필요한 시점에 도달하면 **기술적 지식이 부족하여 '벽에 부딪히는' 경험**을 할 수 있습니다 (영상의 열네 번째 섹션에서 강조됨). 이러한 격차는 기반 모델이 발전하고 Lovable과 같은 팀이 더 많은 지원 기능을 추가하면서 개선될 것입니다 (영상의 열네 번째와 열다섯 번째 섹션에서 언급됨).
*   **코드베이스 규모에 따른 성능 저하:** 제 경험상 코드베이스가 커질수록 LLM의 처리 능력이 떨어지는 경향이 있습니다 (영상의 열다섯 번째 섹션에서 언급됨). Vibe 코딩된 코드베이스는 LLM, 특히 현재 최고의 코딩 성능을 보이는 Claude와 같은 모델이 **코드를 더 길게 생성하는 경향**이 있어, 사용하지 않는 UI 컴포넌트 등 **불필요한 코드가 많아져 코드 규모가 더 빠르게 커질 수 있습니다** (영상의 열다섯 번째 섹션에서 설명됨).

종합적으로 볼 때, Vibe 코딩은 개발 속도를 획기적으로 높이고, 특히 반복적이고 상용구적인 작업에서 큰 이점을 제공하는 강력한 도구입니다. 하지만 최적의 결과를 얻고 복잡한 문제를 해결하기 위해서는 여전히 개발자의 기술적 이해와 판단력이 중요합니다.