（私が知っている）バイブコーディングのすべて

Haebom
「AIを活用して月千万ウォンは簡単に稼ぎました！」
「人工知能で数億ウォンの副収入を上げました」
スレッドやインスタグラム、カカオトークを開くたびに人工知能で収益を上げたという華麗な成功談があふれます。毎日のように上がる文を見て、正直羨ましさよりは疑問が先に聞きました。私の周りにはAIを研究したり、直接モデルを開発する人が多いのですが、実際の技術を開発したりサービスを構築する人よりも皮肉なことに人工知能講義をしている方が、より速くて大きな収益を上げているようです。長い間ITでご飯をやってきましたが、私が経験した現実はそんなにドラマティックではなかったんですよ。
そんな中、昨年から好奇心半分、楽しい半分で人工知能コーディングツールをあれこれ試してみました。最初は、単にメンテナンスや小さなスクリプトを書くほどに使ったツールが、ある瞬間からは予想外の収益をもたらし始めました。これをより体系的で目的的にすることは、まさにアンドレイ・カパシー（Andrej Karpathy）という名前ですか？ 「バイブコーディング」です。
ここ数ヶ月間、私はCursor 、 Replit 、 Trae 、 V0 、 Copilotなど、さまざまなAIコーディングツールを使って、最近はWindsurfやLovableのようなツールも書いています。直接使ってみるとツールごとに明らかな特性と違いがありましたね。コーディング経験が全くない人が素早くプロトタイプを作るときに有利な「コールドスタート」ツールと、すでにある程度コーディングをすることを知っている人が生産性を爆発的に引き上げるときに良い「ブースト」ツールに分けることができるという事実も知りました。
もちろん私の勝手に分けたので何の意味もありません！
ツール
分類
主な特長
一行平
コールドスタート
•
フロントエンド、デザイン、バックエンド統合の自動化
•
Supabase（データベース）と電子メールの統合
ITであり、考えが明確であるとき使い勝手よい。
コールドスタート/ブースト
•
ブラウザベースの開発環境
•
展開とオートスケーリング、ホスティング
•
モバイルアプリとして利用可能
非開発/非IT人が書く最高のツールだと思う。使いやすさ。 API Key 管理の容易さ。
コールドスタート
•
UIコンポーネントクイック作成
•
Figma統合
•
ShadCNスタイルデザイン
デザイナーやピグマを少​​し扱うとシナジー58,000％
ブースト
•
無制限の無料アクセス
•
VS Codeベース
•
マルチエージェントシステム
無料がいい方。
中国への先入観がない場合は使い勝手が良い。
ブースト
•
VS Codeベース
•
プロジェクトルールのカスタマイズ
開発知識があれば模擬条件。 VSコードを書いた？移さない理由はない。
ブースト
•
「エージェント」チャットモード
•
強力なコンテキスト認識
Flows というエージェント機能がぎこちない
ブースト
•
VS Codeエクステンションフォーム
•
Webでも書くことができ、Githubの最適化
一番長く購読中だが一番使わないことになる。
もちろん私の経験談はしばしばSNSに歩き回る「人工知能で数億稼ぐ」のようなドラマティックな話ではありません。しかし、現実的な限界と個人的な能力にもかかわらず、バイブコーディングのおかげで数ヶ月で$18,500という収益を上げることができた経験です。個人的にこれらの収益が続かないと思うに…面白い実験くらいだったと思います。 （確かに銀行に引き出したことを目安にします。）
この投稿では個人的な経験を扱い、このような使い方もあるんだという側面から見ていただければと思います。個人的に悟ったバイブコーディング、人工知能コーディング?の限界と内容について話をしてみたので、あまりに鋭い反応はしないでください。

1戒め。ルールを決める

🔖AIはなぜ明確なルールが必要なのでしょうか？

AIは人ではありません。感情や直観で文脈を把握できません。正確に指定してくれた指示に従うだけです。つまり、AIにコードを任せるには、「何をすべきか」、「何をすべきか」を明確に伝えなければなりません。
この明確なルールを事前に渡すことには、次の利点があります。
•
コードの一貫性を維持: チーム全体が同じ基準でコードを書くのを助けます。
•
エラーの低減：AIが不要な作業を実行したり、奇妙な構造を使用したりするのを防ぎます。
•
メンテナンスの容易さ：長期的にコードベースの構造がクリーンで明確に維持されます。

📌良いルールを書く方法：重要なヒント4つ

明確なプロジェクトルールを設定するときは、次の原則を守ってください。
1.
明確で簡潔に
あいまいなまたは抽象的な表現は避け、短く、明確に表現してください。
2.
具体的な例を含める
「コードをきれいに保つ」ではなく、「関数の1つの長さを30行以内に制限してください」のような具体的な例で表現してください。
3.
AIツールの機能活用
CursorやV0などのAIツールは、 /generate rulesコマンドを使用して既存のコードから自動的にルールを生成できます。既存のコードベースをAIで分析し、適切なルールを生成するようにしてください。
4.
定期的なアップデート
プロジェクトが進むにつれて、規則を定期的に更新し、AIに再配信します。これにより、最新のルールが常に反映されます。

✅良いプロジェクトルールの例

実際に効果的なプロジェクトルールは、次の形式で作成できます。
😉
重要なプロジェクトルール：
1.
コードを書く前に必ず@Architecture.mdを読んでください。このドキュメントには、プロジェクトの完全なデータベーススキーマが含まれています。
2.
新しいコンポーネントや機能を追加する前に、@Design-document.mdの内容を必ず参照してください。
3.
主な機能を追加するかマイルストーンを完了するたびに、すぐに@Architecture.mdと@design-document.mdを更新してください。
4.
すべてのコンポーネントは、Reactの関数型コンポーネントとTypeScriptで作成する必要があります。
5.
CSSスタイリングはTailwind CSSのみを使用し、カスタムCSSファイルを追加しないでください。
6.
API呼び出しはaxiosライブラリを使用し、APIキーまたは認証情報は別々の環境変数で管理する必要があります。
7.
すべての機能には単体テストが含まれており、Jestで書かれたテストファイルをコードと共に提供する必要があります。
8.
コードの重複を避け、共通ロジックは必ず/Utilsフォルダに別の関数に分割してください。
このような明確なルールがある場合、AIはそのルールを積極的に参照してコード生成を進めます。

🚩よく犯す間違いと解決策

ミス 1. あまりにも一般的なルールを書く
🔸間違った例：「コードを読みやすくしてください」
🔹正しい例：「変数と関数名は常に意味のある英文名で作成し、略語や略語は使用しないでください。」
ミス 2. 更新しないルール文書
🔸問題：プロジェクトが進化している間に最初に定められた規則はもはや適切ではないかもしれません。
🔹解決策：少なくとも月に一度ルール文書を確認して更新してください。定期的なミーティングでチームメイトと一緒にレビューする方が良いでしょう。
間違い 3. ルールを作りすぎる
🔸問題：ルールが多すぎると、AIは重要なルールを見逃す可能性があります。
🔹解決策：コアルール5 10個程度に制限し、重要でない部分は別のスタイルガイド文書に分けて管理してください。

🛠️実際のツールを使用するためのヒント： /Generate rules

CursorやV0などのツールは、コードベースの分析を通じてルールを自動生成する機能を提供します。次のコマンドで簡単にルールを作成できます。
/generate rules
このコマンドを使用すると、既存のコードベースを分析して適切なプロジェクトルールを自動的に生成します。

🚀このようにルールを設定すると、何が変わりますか？

ルールを明確に設定してAIに提供すると、プロジェクトのコード品質と生産性が大幅に向上します。

2戒め。

AIはすべての技術スタックやフレームワークを完全に理解していない可能性があります。新しい技術や慣れていない技術を使用する場合は、常に公式文書またはサンプル文書へのリンクを提供することをお勧めします。
プロンプトを作成すると、次の形式で文書リンクが提供されます。
⬛
Next.jsの新しいApp Routerを使ってページを作成してください。次の公式文書を参照してください： https://nextjs.org/docs/app-router
エラーが発生した場合は、AIに「行単位で文書の内容を参照してエラーを説明してください」と尋ねると、より詳細な分析と説明が得られます。個人的には、この機能はカーソルが最も圧倒的に楽でした。 [設定]で、Features> +Add new docを介して公式文書を追加したり、チャットウィンドウから@ /コマンドを介してDocsを追加したりすることもできました。
개인적으로 추가한 문서들. 자주 쓰는 문서들을 잘 먹여만 놔도 자잘한 실수를 안합니다.

3戒め。コードが間違っている場合は自分で書く

AIが生成したコードが引き続き問題になる場合は、長い説明や繰り返しの指示ではなく、直接修正したコードを提供することが最も効果的です。 AIは、説明よりも実際のコード例ではるかに速く学習します。ここで「直接作成」という言葉にあまりにも恐れないでください。正確には正しい例を示すという意味です。

🛠️自分で書く必要がある場合はいつですか？

AIが繰り返し次の問題を引き起こす場合は、直接コードを書いて表示することをお勧めします。
•
同じミスを繰り返し行う場合
•
パフォーマンスが非効率なコードを作成し続ける場合
•
特定のロジックを正しく理解できない場合
この場合は長く説明するのではなく、あなたが望むことを明確に示す「例コード」を提供する方がはるかに効果的です。
// AI가 생성한 잘못된 코드 users.forEach(user => { if (user.active === true) { activeUsers.push(user); } }); // 수정된 효율적인 코드 const activeUsers = users.filter(user => user.active);
もちろん、何が間違ったコードなのかわからない場合や、何が効率的なコードなのかわからない場合があります。開発の背景 知識がない場合や初めて見る言語や環境で開発をしなければならない場合がそうでしょう。その時は ChatGPT 件、 Claude 件、 Grok に尋ねてみてください。人工知能の最も魅力的な部分は、ずっと聞いてみても、絶対にひどく見たり無視しないという点です。

4戒め。チャット履歴を活用する

AIとコラボレーションするときに同じことを繰り返し行う必要がある場合がよくあります。このとき、毎回プロンプトを最初から書き直すのは時間の無駄です。チャット履歴を活用して、繰り返し作業をより効率的に実行できます。

📌チャット履歴を活用する方法

チャット履歴を活用する良い方法は次のとおりです。
•
以前に正常に実行された操作プロンプトを再度呼び出す
•
以前に変更したコードやフィードバックをコピーして再リクエストする
•
過去のジョブの内容に基づいて新しいジョブをリクエストする
例：
「以前に作成したログインフォームコードに基づいて会員登録フォームを作成してください。技術スタックとスタイルは同じです。」
これにより、時間が節約され、プロジェクト全体にわたってコードスタイルと品質も一貫して維持されます。これを一戒で述べたルールと併用すると、よりパワフルに使用できます。まさに@Architecture.mdのようなガイドファイルを作っておくのです。 Cursor ベースで .cursor/ フォルダサブに指示となるマークダウンを作成すればよい。マークダウンはおおよその文書形式を言いますが、NotionやChatGPTなどで作成したものを貼り付ければそれがマークダウン文法です。個人的に幼い時、エンハウィキ編集しながら知り合いになってずっと気軽に書いています。
.Cursor/
├── architecture.md
├── design-document.md
└── todo-checklist.md

5戒め。具体的なプロンプトを作成する

AIで作業するとき、あなたが提供するプロンプトは、結果の品質を決定する最も強力なツールです。具体的なプロンプトは正確な結果を生み出し、あいまいなプロンプトは時間の無駄につながります。

🔍なぜプロンプトが重要ですか？

AIは明示的に提供された情報に基づいてコードを生成します。人間開発者のように直観や推論で理解できません。 AIに正確な指示を出すほど、所望の結果が得られる可能性が高くなります。
これはまるで食べ物を注文するとき、「おいしい食べ物をください」ということと、「スパイシーで香ばしいクリームパスタにエビを加えてください」と注文することの違いと似ています。後者の注文が好きな料理を得る可能性ははるかに大きいでしょうか？

🎯良いプロンプトの前提条件4つ

1.
技術スタックの指定：React、TypeScript、Tailwind CSS、React Contextなどの使用技術とライブラリを明確に指定します。
2.
具体的な機能と要件：画面に何が表示されるべきか、どのデータを扱うべきかを正確に少なくします。
3.
明確な制約：どのようなスキルや方法を使用してはいけないのかを正確に伝えます。
4.
例外状況または例外処理方法：エラー状況または特殊なケースを事前に考慮して、AIが適切なコードを生成するように誘導します。

📌良いプロンプト対悪いプロンプト：具体的なケースの比較

🔸あいまいなプロンプトの例：
「ユーザープロフィールを画面に表示してください。」
🔹具体的なプロンプトの例：
「ReactとTypeScriptを使用してユーザープロファイルコンポーネントを作成してください。このコンポーネントはユーザー名、プロファイル写真、購読日を表示する必要があります。プロファイルイメージを読み込めない場合はデフォルトのアバターイメージを表示します。スタイリングはTailwind CSSに進み、ステータス管理にReduceではなくReact Contextを使用してください。」

🚩プロンプトを書くときによくある間違いと改善法

ミス1.技術スタックを明確にしない
•
悪い例：「ログインフォームを作成してください」
•
良い例： "Next.jsとTypeScript、Tailwind CSSを使用してログインフォームを作成します。入力値の検証にはreact-hook-formを使用し、ログイン失敗時に警告メッセージを表示する必要があります。
ミス 2. 制約の欠落
•
悪い例：「ページをスタイリングしてください」
•
良い例：「ページスタイリングにはTailwind CSSのみを使用し、外部スタイルシートは追加しないでください。」
間違い3.例外処理を指定しない
•
悪い例：「画像を表示するコンポーネントを作成してください」
•
良い例：「画像を表示するコンポーネントを作成してください。画像URLが空の場合、またはロードに失敗した場合は、「no-image.svg」というデフォルトの画像を表示してください。」

🚀プロンプト構造化テンプレート

効果的なプロンプトを作成するためのテンプレートです。
👉🏻
[コンポーネント/機能名]開発
📌技術スタック：
•
[使用する技術/ライブラリ一覧]
🎯機能要件：
•
【実装すべき詳細機能一覧】
🚨 制約事項:
•
[避けるべきスキル/方式のリスト]
🧪例外処理：
•
[考慮すべき例外状況の一覧]
これらの構造化されたプロンプトを使用すると、AIはより正確に意図を特定し、目的の成果物を生成する可能性が大幅に高くなります。

6戒め。繰り返しフィードバックによる結果の改善

AIとコラボレーションは、ワンタイムコマンドで完璧な結果を得るプロセスではなく、繰り返しのコミュニケーションと改善のプロセスです。最初の成果物が完璧ではなくても、徐々にフィードバックすることで目的の方向に導くことができます。

反復フィードバックの重要性

完璧な結果は、通常、数回のフィードバックと修正を経て誕生します。 AIに一度にすべてを完璧にするように求めるよりも、徐々に改善していくアプローチがより効果的です。

効果的なフィードバックサイクル

1.
最初の成果物の作成：第5章で説明した具体的なプロンプトで最初の成果物を作成します。
2.
結果の評価：生成されたコードが要件をどの程度満たすかを確認します。
3.
具体的なフィードバックの提供：「この部分はうまく機能しますが、機能がYTの状況でエラーが発生します。
4.
改善要求: 修正が必要な部分に焦点を当てた簡潔な指示を出します。
5.
繰返し: 満足のいく結果が出るまで、手順3～4を繰り返します。

効果的なフィードバックを提供する方法

1.具体的かつ客観的に
•
悪い例：「このコードは気に入らない」
•
良い例：「ログインボタンをクリックするとフォームの検証が機能しません」
2. 優先順位を決めて
•
複数の問題がある場合は、重要度順にフィードバックを提供します。
•
「最も緊急の問題はXです。次にYとZを修正してください。」
3. 希望する結果を明確に
•
悪い例：「この部分をより良くしてください」
•
良い例：「この関数がユーザー入力を処理するときは、スペースを削除して小文字に変換する必要があります。」

💡簡潔な改善命令を活用する

繰り返し操作時にプロンプ​​ト全体を書き換える必要がなく、簡潔なコマンドで特定の部分だけを改善するように要求できます。
👉🏻
次の部分を修正してください：
1.
ログインフォームにメール検証を追加する
2.
パスワードフィールドに少なくとも8文字の要件を表示する
3.
ログインに失敗したときにエラーメッセージをより顕著に表示する
このような簡潔なフィードバックは、AIが集中すべき部分を明確にし、不要な作業を減らし、より効率的なコラボレーションを可能にします。

🚀フィードバック効率を最大化する

1. フィードバック履歴を活用する
•
前の会話を参照して、「以前に述べたX問題がまだ存在します」のような文脈を維持します。
2. コードの変更を強調表示する
•
変更された部分を明確に表示することで、どの部分が変更されたかを簡単に把握できます。
3.成功した改善のための肯定的なフィードバックを提供する
•
「この部分はまさに私が望んでいた方法で改善されました。次に…」のように肯定的な強化によってAIが正しい方向を認識するのを助けます。
反復的なフィードバックプロセスにより、AIはより多くの作業スタイルと好みを理解し、時間が経つにつれて少ない修正で目的の結果を得ることができます。

7戒め。ファイル単位で作業する

「このアプリを作ってください！」同じ大きなリクエストをAIに渡すと、生成されたコードはしばしば管理が難しく、バグを見つけて修正するのにもはるかに時間がかかります。この問題を解決する最も効果的な方法は、「ファイル単位」で作業することです。

🗂️なぜファイル単位の作業ですか？

私が使ってきた生成型人工知能開発ツールはすべてサポートされていました。通常@または＃を介して特定のファイルまたはフォルダを指定できますが、これを行うと、次のような利点があります。
•
クイックフィードバックサイクル：小さな単位ですぐにAIが生成したコードの品質を確認し、フィードバックを与えることができます。
•
簡単なエラーの検出と修正：小さなユニットのコードでエラーが発生した場合は、原因を簡単に見つけることができます。
•
高いコード品質を維持: コードをひとつひとつ集中的に管理するので、一貫性と読みやすさが向上します。

🛠️ファイル単位の作業プロセス

この記事を読んでいる人が先の戒めを読んで正しく適用した場合、おそらく変数名、ファイル名は非常に直感的に書かれているでしょう。本当に文字通り読んでもどんな機能を担当しているのか分かるでしょう。これにより、ファイル単位で作業を効率的に実行できるようになります。
1.
明確な作業単位を定義する
まず、機能全体を実装するときにどのファイルが必要かを具体的に定義します。たとえば、ログイン機能を開発すると、次のようなファイル単位の作業に分けることができます。
•
/Components/LoginForm.tsx
•
/Hooks/useLogin.ts
•
/Contexts/AuthContext.tsx
2.
各ファイルの独立したプロンプトの作成
各ファイルを作成するときは、そのファイルが実行する役割だけを明確に説明するプロンプトを作成します。
🔹良い例：
「LoginForm.tsxファイルをReact、TypeScript、Tailwind CSSで作成してください。ユーザーの電子メールとパスワードを入力し、送信ボタンをクリックしたときに渡された関数を呼び出します。エラーメッセージの表示領域を含めてください。」
🔸悪い例：
「ログインページを作成してください。」
3.
AI生成コードをすぐにテストする
ファイルが生成されたらすぐに実行して動作するかどうかを確認し、異常がある場合はすぐにフィードバックを提供します。問題がある場合は、AIがそれを修正できるように修正されたコード例を提供することをお勧めします。
4.
1つのファイルが完成したら、次のファイルに移動する
1つのファイルが十分に完成したら、次のファイルに進みます。これにより、各コードの完成度を高め、将来のデバッグの負担を最小限に抑えることができます。

8戒め。ぎこちないでください。

実際、バイブコーディングでもLLMでも人工知能ツールが出てきて考えが面倒なこともあります。もうやってほしいと言えばオガンなことはすべてやってみると、実は詳しいことは越えたいと思うのが人間の本性…あるいは私だけの怠惰な特性かもしれませんが、むしろ人工知能で作業しながら最も重要なのがこんなディテールのようです。土さん一つ言わなかったり逃したらそれを何とか詰め込んでみるとそれがうまく合えば幸いなのにその一つが間違っていて全体が壊れることもあります

バイブコーディング時、よくあるミスと改善法

間違い1：あまりにも多くのファイルを一度に生成しようとする
•
問題：同時に複数のファイルを作成すると、エラーが発生したときにどこで問題が発生したかを見つけるのは困難です。
•
解決策：1つのファイルの作成後にテストとレビューが完了したら、次のファイルを生成します。
ミス2：ファイルの役割を明確にしない
•
問題：役割が不明なファイルは、重複した機能や非効率的なコードにつながる可能性があります。
•
解決策：各ファイルの役割と責任を明確にプロンプ​​トに書き込んでAIに渡します。
ミス3：問題を明確に指摘しないで修正してもらう
•
問題：特定の機能が機能しない場合、または機能しない場合は、修正するように広範囲に言うと問題をむしろ広げます。
•
解決策：エラーコードを直接挿入するか、正確にどの部分で動作しないかを話します。

追加のヒント

•
明確なネーミングルールを使用する：ファイルとコンポーネントの名前を直感的かつ明確に設定すると、メンテナンスとコラボレーションが簡単になります。大体ファイル名をつけて、あるいは勝手に作るのは楽ですが後で管理できるはずです。
•
独立したファイル構造を維持する：1つのファイルが依存しすぎないように注意し、独立性を最大化すると、AIはより簡単に良いコードを生成できます。
•
小さな作業単位で頻繁にコミットする：ファイル単位の作業後にコードがうまく機能したらすぐにコミットし、次の手順に進みます。これにより、コード管理と将来のロールバックが容易になります。

9戒め。テスト優先アプローチの適用

AIを活用したコーディングでよく遭遇する問題の1つは、「表面的にはうまく動作するコード」が時間が経つにつれて複雑なバグやロジックエラーになることです。これを防ぐ最も効果的な方法は、テスト優先アプローチ（TDD、Test Driven Development）を使用することです。昔はこれに関連した本もありましたが覚えていませんね。 IT業界ではドリップでDDDで略語いたずらをたくさん打ったが…これは雑説のようで…

テスト優先アプローチとは何ですか？

テスト優先アプローチ（TDD）は、実装コードを作成する前にまずテストを作成し、テストが失敗するように設定した後、コードを作成してすべてのテストに合格する開発方法論ですが、この方法論はAIにとっても非常に効果的です。テストケースは、AIが実装すべき目標を非常に明確に定義しているため、AIが正確に何をすべきかを混乱させることなく正確に理解するのに役立ちます。
最近はReplitでこれを自動化してくれて簡単なQAなどを行ってくれました。例えばログイン検証、特定ボタン押してポップアップ開いてつながるシナリオチェックのようなことをしてくれたら楽なのにいざというと言ったのに配布してはいけない言葉がない場合もあるので無条件に信じることができず、先に述べたように分割作業するのが最も基本的なようです。

TDDの適用方法

1.
テストケースを最初に書く
実装する機能を明確に定義し、その機能を検証できるテストケースを作成します。
たとえば、ユーザーログイン機能の場合：
test('올바른 이메일과 비밀번호 입력 시 로그인 성공', () => { const result = login('user@example.com', 'correct-password'); expect(result).toBe(true); }); test('잘못된 비밀번호 입력 시 로그인 실패', () => { const result = login('user@example.com', 'wrong-password'); expect(result).toBe(false); });
2.
テスト失敗の状態を確認する
最初は実装コードがないので、すべてのテストは失敗します。これは通常のプロセスであり、AIに実装の目標を明確に伝える信号になります。
3.
AIにテストパスを要求する
AIにはっきりと尋ねます：
「次のテストケースを通過させるログイン機能コードをTypeScriptで作成してください。」
AIは、これらのテストケースに基づいて正確に動作する実装コードを生成します。
4.
すべてのテストに合格し繰り返し
テストを実行し、すべてのテストが合格したことを確認します。失敗したテストがある場合は、AIにそのテストに合格するように追加の要求を行います。
結局のところ、これも繰り返しです。割るほど修理しやすい皮肉ができますが、まるで機械工学のようです。部品をたくさん作っておくと組み立てる時は面倒なことがあっても後で故障したり、問題が生じたら着替えやすくメンテナンスが良いように…

10戒め。アイデアを絞る+ビジネス化する

個人的にこれが全部のようです。きっと上にある戒めなどは、人工知能の発展と道具の発展で十分に解決されそうだが、何を作るのか？どのように人々に購入をもたらすかを考え出すことが最も重要でした。個人的にこのように何かを作ることが比較的容易になれば、明らかなサービスやアプリはすぐに出てくるだろうし、結局有意な差別もしくは機能を持つか、他人が容易に越えられない堀を作ったり、厄介なマーケティングもしくはBMがなければならないと思います。
前述の収益化のために私が作ったサービスは合計17でした。その中でお金を稼いでくれたのはわずか3つでした。そして収益の半分以上が1つのサービスから出てきました。これはまさにピカソの法則だから、なんとかして多作をすれば成功して... まあ、このような話をしようとするのではなく、むしろアイデアやマーケティング戦略、BMをよく組むことが重要だということを骨折に感じました。
たとえば、私がしたことの中で最も多くのユーザーを獲得したのは、以下の方法でした。
1.
ユーザが時間（１０〜３０分）をかけて心理テスト／基質テストなどを行う。
2.
ユーザーが行ったテストによって異なるが、少なくても70問、多くは600問まである。
3.
ユーザーはテストを終えた後、明らかに自分が時間を投資したので、何とか報酬を得たいと思うでしょう。
4.
アンケートの概要は、会員登録時に無料で提供されます。
（当然ながら、アンケート結果の分析はClaudeを介してユーザーの応答に基づいて生成されます。）
5.
詳細で綿密な分析レポートを見たい場合は、ユーザーは3つのうちの1つを選択する必要があります。
a.
48時間待つ *ボタンを押した瞬間からカウント
b.
3人の友達を招待する*参照リンクフォーム
c.
費用を支払う
すでにユーザーは時間を費やしており、簡単な要約レポートだけを受けた状態で、損を見た気がし、A案、b案、c案の中から選択をするしかありません。 a を押してもリテンションが確保され、このサイトには合計 11 個のテストがあるので、実際に違うことを言ってもいいです。 1つのテスト結果を待つと、別のテストを進めることができません。
そしてB案を選択すれば新規ユーザー（顧客）を確保できるので良いし、c案を選択してもお金を稼ぐのだからむしろ良いです。私はいつも人間は煩わしさを一番嫌い、待つことができず、不快感に怒る存在だと思うのにこの部分に触れてみました。
😇
上記の投稿を参考にしてみることも？方法です。とにかく…重要なのは、このようなアイデアと構造を組む能力のようだというのが要点です。
今まで関連戒めをずっと書いてみましたが、あまりにも長くなった感じもあってなんだろうか…結局わかるけど失敗がもっと多かったです。何を自慢しようとしたものでもなく、おそらく膨大な事例がより多く出てくるでしょう。 Cal.aiは100万ドル稼いだというのですが何...国内でももっと面白い事例が出てくることを期待します。本当にアイデアの戦いのように、星の星のサービスが出ています。まるで2010年初めにモバイルアプリケーションがあふれるようです。人工知能がすべてを解決してくれません。当然アイデアとどのように収益化するかは結局使う人の力量のようで、むしろマーケティングが重要になる時期ではないかと思います。以前に書いた文が思い出されます。
バイブコーディングをあまりに賞賛するだけで一言付けると、これは単にアイデアを実装するプロセスが以前よりはるかに速くなっただけです。個人的には、バイブコーディング時代に開発者の能力が危険だというよりもむしろ開発者の需要がより多くなりそうです。みんな故障した製品を作って修復する方法を知らないようです。したがって、単に開発者が終わったようなことを言いたくありません。
今回の連休に、ある方がDMで「アイデアはたくさんあるが、実装する実力がなくてあきらめた」と以前に私が書いた文を見てバイブコーディングを通じてサイドプロジェクトを再挑戦してみると言いました。最近メールでご連絡いただいた方の中でも「初めにはただチュートリアルに従い、いつの間にか収益が出るからもっと頑張ることになった」という方が多かったです。そんな話聞くとブログ書く満足感が生まれます。やはり人でも応援とお金で動くようだという考えを最後にして…この文を終えます。
死族。
🍡
そういえばコーチングを進行した人の首都いつのまにか100人を超えてこれも後期を書かなければならないのにずっと遅れていますね。むしろ人工知能ができてブログ文をすぐに書こうとしましたが、あまり書いていないようで曖昧ですね。先日知っている方々とこの事例を分けてみると講義を作ろうと、本を書くなどの話をしましたが、そんな勤勉さと在住はなくてできないようで…こんなブログ文を残すことで仕上げます…（たくさん読んで広げればそれだけで満足です。
Subscribe to 'haebom'
📚 Haebomのアーカイブへようこそ。
---
IT💻、経済💰、人文科学🎭に関連する記事を投稿します。
私の考えや視点や興味が気になったら購読してください。
haebom@kakao.com
Subscribe
22
H
Hyunseok Jeong
감사히 읽었습니다.
긱뉴스에서 말씀하신대로 이 글도 i18n을 생각해서 영어로 퍼블리싱하는 것도 좋아보입니다. :-)
❤️
3
Haebom
말씀 감사합니다. 현재 국제화를 어느 정도 해놓은 상태 입니다.
영어판의 경우, 기존 URL 뒤에 &tl=en를 붙이면 접근 가능하십니다. :)
👍👍🏻
3
👏👏🏻
2
Peter
최근 관심이 가는 분야라서 아주 인상깊게 읽었습니다. 고맙습니다!
Haebom
부족한 글 읽어주셔서 감사합니다.
가
가을 청록 목소리
너무 잘 읽었습니다.
Haebom
감사합니다.
B
Bonnie_Ryu
안녕하세요, 감사히 잘 읽었습니다.
수입은 앱 출시로 창출하신걸까요?
Haebom
Stripe로 연결해 개별 카드결제를 받았습니다.
👍👍🏻
3
DX컨설팅
안녕하세요. 글 너무 잘 읽었습니다. 제가 개발자는 아니다 보니 100% 이해할 수는 없었지만 그래도 개발이 예전 보다는 쉬워지겠구나를 느꼈습니다. 저도 여러 개발을 했는데(기획자나 PM), 항상 결제가 문제였습니다. stripe는 한국에서 지원이 안되는 것으로 알고 있습니다. polar.sh 등으로 우회한다고 했는데, 혹시 직접 stripe.com 을 연동하셨나요? 하셨다면 어떻게 하셨는지 궁금합니다.
이
이름 없는 황갈 서리
글 잘 읽었습니다! 만드신 심리검사 해보고 싶은데 어디서 해볼 수 있을까요?
Haebom
공개적으로 링크 노출은 안하고 있습니다 ㅎㅎ 조만간 개발기도 공유할게요!
쓴
쓴 보라 개구리
잘 봤는데 사이트가 너무 느려요. 다른글들도 읽어보고 싶은데 쉽지않네요.
Haebom
헉 슬래시페이지 팀에게 전달해 놓을게요
W
Wandering salmon thunder
안녕하세요! Stripe 연동은 해외 법인을 설립하신걸까요~? 한국에서 결제 연동이 가능한지 궁금합니다
Haebom
Stripe atlas 사용하시면 한국에서도 법인 설립과 계좌 생성 가능하세요!
꽃
꽃무늬의 주황 공명
너무 재밌게 잘읽었습니다.
평소 바이브 코딩을 하면서 불편한 부분들에 대해서 본문에 있던 팁들 중 일부를 스스로 체득하고 있었는데
체득하지 못했던 부분들 까지도 이렇게 정리된걸 보니 간지러웠던 부분을 기원하게 긁어주는 느낌입니다.
개인적으로도 이런저런 프로젝트를 해보면서 수익화를 해보고 싶은데 아직 막연하네요 ㅎㅎ 대단하십니다!
Haebom
요즘 이 글 덕분에 많은 분들과 교류하고 있는데 되게 재밌습니다. 모임이나 스터디를 한 번 해볼까해요.
고
고독한 비취 물
너무 좋습니다~ 참여 의사 100% 에요 ^^
리
리플리
관심은 많은데 모르는 게 너무 많아서 어디서 부터 접근할지 몰라 이것저것 막 해보는 단계 입니다. 수익화를 하신 분들 보면 부러울 따름입니다^^ 잘 읽었습니다. 감사합니다~
Haebom
도움이 필요하시면 언제든 말씀 주세요!
신
신성한 자두 나무
프론트엔드 개발 1년하고 한계를 느껴 떠났는데, 다시 해볼 용기가 생기네요. 좋은 글 공유해주셔서 감사합니다.
P
Park_David
해봄님 너무 대단하십니다!
See latest comments