ChatGPT를 사용해 번역한 일본어 문서와 한국어 문서를 같이 적도록 하겠습니다. 노션 페이지 좌측에 마우스를 가져다대시면 목차를 보실 수 있으며, 클릭을 통해 해당 탭으로 바로 넘어가실 수 있습니다. 팀원의 이름은 번역하지 않고 한국어 그대로 표기하겠습니다.

ChatGPTを使って翻訳した日本語文書と韓国語文書を一緒に記載いたします。 ノーションページの左側にマウスを移動すると目次が表示され、クリックすることで該当のタブに直接移動できます。 チームメンバーの名前は翻訳せず、韓国語のまま表記いたします。

배포 URL: https://dev.d1yiq9cn4wxboc.amplifyapp.com/

デプロイ URL: https://dev.d1yiq9cn4wxboc.amplifyapp.com/

光フロー

• ペルソナ（想定顧客）：自分で作ったアプリを配布することに慣れていない初心者開発者
  • 私たちのチームは、「デプロイを最も難しく、面倒で、楽しくないと感じる人は誰だろう？」と考えた結果、初心者開発者がその対象に当たると判断しました。
• サービスの特徴：ゲーミフィケーションを活用し、デプロイに慣れていない人でも楽しくデプロイを進められるようにする！

1. ユーザーがソースコードを zip ファイルとしてアップロードします。
   • zip ファイルは、Pre-Signed URL を利用して S3 にアップロードされます。
   • その zip ファイルを Bedrock に送信し、 を取得します。
2. ユーザーがデプロイに関するアンケートを実施します。
   • 個人プロジェクト用か、高可用性が必要かどうかを質問します。
   • 1つ目で得られた  と、今取得した <アンケート結果> を基に、AWS・GCP・Azure の Terraform ファイルを生成します。
   • 生成された Terraform ファイルをもとに、AWS・GCP・Azure の推定月額費用を算出します。
3. ユーザーは AWS、GCP、Azure の Terraform ファイルと推定月額費用を確認し、気に入ったクラウドを一つ選択します。
   • 選択したクラウドに対応する GitHub Actions ファイルが生成され、すぐに適用できる SDK CLI コマンド集が Markdown ファイルとして作成されます。
4. ユーザーはその情報を基に、残りのデプロイ作業を簡単に進めることができます。
   • クラウドコンソールへ直接移動できるボタンが生成され、その場ですぐに適用することができます。

• フロントエンドを迅速にデプロイするために、AWS Amplify を使用しました。
• Lambda を活用したサーバーレスアーキテクチャであるため、バックエンドサーバーが不要であり、CloudFront、AWS WAF、AWS Shield などの付加サービスとの連携も非常に容易です。

• 私たちのサービスは Event-driven アプリケーションであるため、すべての通信は API Gateway を通じて行われます。
• 上記のアーキテクチャには、API のパスも詳細に記載されています。

• Event-driven アプリケーションでサーバーレスアーキテクチャを実現するのに最適な Lambda を使用しました。
• サーバーを運用しないため、コスト効率が高いです。

• Amplify に含まれる WAF および AWS Shield を活用して、基本的なセキュリティを実装しました。

• CloudWatch を使用して、Lambda と Step Functions が正常にトリガーされているかを確認し、バグ修正を行いました。
• Step Functions のログを使用して、Step Functions の実行時に AI の応答を確認し、プロンプトエンジニアリングを行いました。

• 原本の会議記録も一緒に添付しますが、原本の会議記録は韓国語のみで作成されています。

2025-10-31

• チームメンバーとの初めての出会いの日でした。
• ハッカソンのテーマをどうするか、どのような方向性で進めるのが良いかについて、11月2日まで考える時間を取ることにしました。

2025-11-02

• それぞれがアイデアを考えてきて、チームメンバーと簡単に共有し、アイデアを一つにまとめる作業を行いました。

各自の事前調査内容

• 서호
  • AWS、Azure、GCP でデプロイを支援するサービスにはどのようなものがあり、どのように支援しているのかを調査しました。
  • デプロイの瞬間を不幸にする要因は何かを考え、それを解決したいと考えました。
  • 開発者の立場からは、「デプロイプロセス自体が存在しないことが一番楽である」という意見を提示しました。
  • 各種ログやコードベースを確認し、問題発生時にエラーの根本原因分析（root cause analysis）を行い、解決策まで提案する Observability AI エージェントのアイデアを提示しました。
• 동욱
  • デプロイプロセスにおいて、AWS・Azure・GCP のうちどのクラウドにデプロイするのが最も効率的かを判断してくれる仕組みを作ってはどうか、というアイデアを提案しました。
  • コア機能、フロントエンドおよびバックエンドで使用する技術やロジックについて詳細に説明しました。
• 재엽
  • 私たちのハッカソンの評価要素に基づいて、各評価要素に影響を与える可能性のあるサブ項目やクラウドサービスについて調査しました。
• 호정
  • デプロイ自動化プラットフォームのアイデアを持ち込み、それを実現するためのコア機能を作成しました。
  • 無停止デプロイ（ゼロダウンタイムデプロイ）を実現する際に発生し得る課題を調査し、「楽しいデプロイ」を実現する方法について考えました。

会議内容

• 「楽しさ」に焦点を当て、ゲーミフィケーション要素を取り入れようというアイデアが出ました。
  • 서호: デプロイプロセスを複数のステップに定義し、それぞれのステップをクリアしていくミニゲームのような感覚を提案しました。
• デプロイ自動化を支援するアプリは、他のチームも似たようなテーマを選ぶ可能性が高いため、Terraform ファイルを自動生成し、さらに推定コストまで出力する点を私たちのチームの差別化要素として取り入れようという話になりました。
• ユーザーがアプリを見せると、どのようにデプロイすべきかを提案してくれる 서호 のアイデアと、Terraform ファイルを自動生成し、さらに推定コストまで出力してくれる 동욱 のアイデアを組み合わせるのが良いという意見が出ました。
• 동욱: Terraform ファイルを自動生成するというアイデアは良いものですが、もしデプロイまでサービス側で代行する場合、セキュリティ上の問題が発生する可能性があるという意見が出ました。AI に多くの権限を与える必要があるため、エラーが発生した際には重大なトラブルにつながる恐れがあるためです。
  • 서호: それなら、デプロイ内容を簡単に適用できるように、クラウド CLI コマンド集を AI が代わりに作成してくれるのはどうか、という意見が出ました。
  • 他のチームメンバーもこの改善案に同意しました。
• 수인: GUI を積極的に活用し、ユーザーが数回のクリックだけでデプロイに必要なすべての要素を取得できるようなサービスを作ろうという意見が出ました。

2025-11-03

各自の事前調査内容

• 동욱
  • まずはダミーデータを利用して Web デモを実装し、その後で実際のロジックを構築しようという意見を出しました。
• 서호
  • ゲーミフィケーションを活用した Web をどのように構成するのが良いかを考え、ユーザーフローを作成し、それぞれのフローで必要な動作を定義しました。
  • このサービスを誰が使うかを考えたとき、初心者・中級者・上級者のすべてが利用できるサービスになると考えました。
• 재엽
  • Terraform ベースのマルチクラウド自動デプロイ、コスト予測 + AI 推薦システム、可視化 + ゲーミフィケーションをどのように実装すべきかについて記述しました。
• 호정
  • Web で使用する UI を一時的に実装しました。
  • 各機能に対して、どのクラウドサービスを利用できるかを調査しました。
• 수인
  • 私たちのサービスでどの技術を使用するかを検討しました。
  • Amazon Q を使ってサービスを実装することも可能だと思われますが、その実装方法についてはまだ十分に調査できていないと記述しました。

会議内容

• ユーザーが自分でクラウドアーキテクチャの図を描き、それを Web にアップロードすると、その画像を認識して Terraform ファイルを生成するという意見が出ました。
  • しかし、私たちのサービスはクラウドの専門家向けではなく、開発者のデプロイを支援するサービスであるため、開発者がクラウドアーキテクチャ図を描くことには慣れていないだろうという意見が出ました。
  • GitHub リポジトリにアクセスして直接コードファイルを読み取り、Terraform を生成しようという意見も出ました。
    • しかし、GitHub リポジトリへのアクセスにはログイン機能の実装とトークンの発行が必要であり、そのプロセスはかなり複雑で、ハッカソン期間内に実装するのは現実的ではないという意見が出ました。
  • そこで、開発者のコードを zip ファイルとして受け取り、それを解析するという案が出ました。
• 「私たちのサービスは“初回デプロイ”しか支援できないのではないか」という懸念がありました。
  • つまり、最初のデプロイ後のアップデートを支援せず、すでに存在するサービスに対してもサポートできないという問題です。
  • そこで、私たちのサービスで GitHub Actions のコードも生成しようという意見が出ました。
• 上記の議論内容を基に、会議で一次的に私たちのサービスのユーザーフローを決定しました。

1. 開発者が Zip ファイルを私たちのサービスにアップロードすることで開始します。
   • ログイン機能は実装しません。
2. AI がコードを分析し、必要な適正規模を推薦します。
   • この段階では Terraform を生成せず、コスト計算も行いません。
   • この段階はデプロイサーバーの規模を推定するフェーズです。
     • 「あなたのコードを見る限り、この程度のスペックで十分だと思います」といった内容です。
     • ユーザーが自分の判断でスペックを決める権限を持つと考えました。
     • ユーザーが推奨スペックを不足と感じる場合は上位スペックを、過剰と感じる場合はダウングレードを、または AI 推奨通りのスペックを選択できます。
   • 開発者が提供した Zip ファイル（コードベース）とプロンプト（例：トラフィック集中時間帯、予算など）を入力として受け取ります。
     • これらの情報をもとに AI がスペックを推薦します。
3. Terraform ファイルと推定月額費用を提案する段階です。
   • ユーザーが選択した内容に基づき、3 大クラウド（AWS・GCP・Azure）すべての Terraform ファイルを生成します。
   • 生成された Terraform ファイルをもとに、それぞれのクラウドのコストを算出します。
   • ユーザーがどのクラウドを利用するかを選択します。
4. ユーザーが選択したクラウドに基づき、ファイルをダウンロードする段階です。
   • Terraform ファイル + GitHub Actions の YAML ファイル + クラウド CLI コマンドガイドが記載された md ファイル
5. 完了。

2025-11-04

各自の事前調査内容

• 동욱
  • すべてのクラウド技術を実装するには時間がかかると予想されるため、ハッカソンではまずダミーデータを活用したデモに集中するのが良いのではないかという意見が出ました。
  • 11月3日に決定したユーザーフローを基に、どのように実装するのが最適かを検討してきました。
• 재엽
  • ユーザーから zip ファイルを受け取る際、環境変数などの機密情報が一緒に送信される可能性があると考えました。
  • AI が規模を推奨したり、コストを予測したり、Terraform コードを生成したりする際には、その根拠となる情報や判断基準を明確にする必要があると考えました。
• 서호
  • 11月3日に決定したユーザーフローを基に、どのように実装するのが良いかを検討しました。
  • ハッカソン期間中の残り時間が多くないため、まず実装すべき部分と、今後の発展項目として後回しにすべき部分を区別しました。
  • Step Functions と Lambda を活用したサーバーレスアーキテクチャを構築した経験があり、この構成にはそれほど時間がかからないため、ハッカソン期間中にダミーデータではなく実際のインフラを構築しようと提案・説得しました。
• 호정
  • コア機能を中心に、UI をどのように構成すべきか、各機能に必要な API や送受信するデータなどをまとめた API 仕様書を作成しました。
  • データベースが必要になる可能性があると考え、DB スキーマとバックエンドのフローチャートを作成しました。

会議内容

• 서호
  • クラウドサービスに詳しくないチームメンバーのために、API Gateway、Lambda、S3 の動作原理を説明しながら会議を進めました。
• 동욱
  • 私たちのサービスが支援できる開発者の特徴（ペルソナ）を定義しようという意見を出しました。
    • チームメンバーとの議論を通じて、デプロイの経験がほとんどなく、デプロイプロセスに対する理解が浅い初心者開発者をペルソナとして設定しました。
• 議論内容
  • AI が Terraform ファイルを生成するものの、コード自体は Terraform 作成にあまり直接的な助けにならないため、ユーザーが入力するプロンプトが重要だという意見が出ました。
  • しかし、私たちのサービスの想定ユーザーを初心者開発者としているため、詳細で正確なプロンプトを記述しない可能性が高いと考えました。
  • そのため、Terraform ファイル生成に役立つ客観式アンケートを通じて、私たちがプロンプトのテンプレートを自動的に構築する方針を決めました。
• 開発要件整理
  • フロントエンドは AWS Amplify を利用し、迅速なデプロイを目標としました。
  • S3 は Pre-signed URL を用いて zip ファイルを効率的に保存できるようにしました。
  • 必要な API Gateway と Lambda の種類、およびその名称を決定しました。
• 役割分担
  • 호정, 동욱
    • フロントエンドとクラウドのパートを担当することになりました。
  • 재엽, 수인
    • バックエンド（Lambda）とクラウドのパートを担当することになりました。
  • 서호
    • プロジェクトマネージャーやフロントエンド／バックエンドのメンバーと協力し、問題が発生した際には一緒に検討し解決することにしました。

2025-11-05

会議内容

• これまでに進めてきた内容をお互いに共有し、問題があれば一緒に検討する時間を持ちました。
• 서호
  • フロントエンドとバックエンドで、先に実装すべき機能の優先順位を提案しました。
  • 「初心者開発者」というペルソナを前提にすると、環境変数ファイルを zip に含めてしまうミスを十分に起こし得ると考え、環境変数ファイルをサービス側で除外し、AI に分析を任せるべきだという意見を出しました。

2025-11-06

会議内容

• これまでに進めてきた内容を互いに共有する時間を持ちました。
• UI をどのように構成するか、またバックエンドのコードをどのように GitHub にアップロードするかについて議論しました。

2025-11-07

会議内容

• これまでに進めてきた内容を共有し、問題があれば一緒に検討する時間を持ちました。
• 서호
  • UI の構成について議論しました。
  • バックエンド側で Bedrock 呼び出しに関するエラーが発生し、その原因と解決方法について記録しました。
• 複数のユーザーが同時にサービスを利用する場合、ユーザーを区別する必要があることが分かりました。
  • しかし、ログイン機能を実装していないため、Lambda 側で UUID を発行し、一時的にユーザーを識別する方式を採用することに決定しました。
• ユーザーフローを改めて整理する中で、既存のフローに比べて API Gateway をより細かく分割・調整する必要があると判断し、翌日に対面で集まり確実に修正することにしました。

最終的にアーキテクチャを修正し、API パスおよび必要な Lambda 関数の種類も併せて整理しました。

API 仕様書を作成することで、フロントエンドとバックエンドが効果的に協力できるようにしました。

• 最終発表前に、設計ドキュメントにこれまで検討してきた内容がしっかり反映されているかを確認しました。
• デプロイを完了させ、エラーが発生していないか全体的に検証しました。

現在、私たちのアプリはワンクリックデプロイではありません。ユーザーが自分でダウンロードしたファイルを基にデプロイを実行する必要があります。

• Terraform ファイルを基に、AI（LLM）がユーザーのクラウドに直接アクセスし、CLI コマンドを入力して自動的にデプロイを行うことも可能です。
• しかし、この方法はセキュリティ上のリスクが非常に高いと考えました。ユーザーのクラウド環境で LLM の予期しないエラーが発生すれば、重大な被害をもたらす可能性があるためです。
• そのため、「AI が勝手にデプロイを行う」のではなく、「ユーザーが簡単にデプロイを行えるよう支援する」サービスを作る方針にしました。
• また、AI がクラウドプラットフォームにアクセスしてリソースを生成するには、Access Key の発行や IAM 構成などが必要になる場合があります。
  • 初心者開発者にとって、AI が自分のクラウドにアクセスできるようこれらの設定を行うのは難しいだろうと考えました。

• プロンプトをより精緻に設計し、十分なデータが蓄積されれば、AI にデプロイを任せられるようになると考えています。

• 現在はデータ不足のため、単一モデルの呼び出しにとどまっています。
• しかし、データが蓄積されれば、それを活用して Bedrock Agent を通じ、私たちのサービス専用の AI を構築できるようになります。

• 現在の AI の構造は「【ユーザーリクエスト】→【ファイル生成】→【保存】」というフローになっています。
  • そのため、エラーが発生しやすいです。
• より正確で精緻な動作を実現するためには、「【ユーザーリクエスト】→【計画立案】→【ファイル生成】→【最終確認】→【保存】」というフローに構成することができます。
• しかし、この方法はハッカソン期間中に実装するには時間がかかりすぎるうえ、AI 呼び出しコストも急増するため、今回は見送ることにしました。

• 既にデプロイされたサービスに対して CI/CD を支援する機能は、現時点で私たちのサービスには存在しません。
• デプロイにある程度慣れた開発者も、私たちのサービスを通じてさらなる支援を受けられるようにしたいと考えています。

HikariFlow

• 페르소나(예상 고객): 자신이 만든 앱을 배포하는 것에 익숙하지 않은 초보 개발자
  • 우리 팀은 배포를 가장 힘들어하고 어려워하고 재미없어할 사람이 누구일까를 생각해보았는데, 초보 개발자가 여기에 해당된다고 생각했습니다.
• 서비스 특징: Gamification을 활용하여 배포에 익숙하지 않은 사람도 즐겁게 배포를 진행할 수 있도록!

1. 사용자가 소스코드를 zip파일로 업로드합니다.
   • zip파일을 S3에 Pre-Signed URL을 활용해서 업로드합니다.
   • 해당 zip파일을 Bedrock에게 전송해 를 얻어냅니다.
2. 사용자가 배포와 관련된 설문조사를 진행합니다.
   • 개인 프로젝트 용도인지, 고가용성이 필요한지 여부를 물어봅니다.
   • 1번에서 얻은 와 지금 얻어낸 <설문조사 결과>를 바탕으로 AWS, GCP, Azure의 Terraform 파일을 생성합니다.
   • 생성한 테라폼 파일을 바탕으로 AWS, GCP, Azure의 예상 월 비용을 계산합니다.
3. 사용자는 AWS, GCP, Azure의 Terraform 파일과 예상 월 비용을 보고 마음에 드는 클라우드를 하나 선택합니다.
   • 선택한 클라우드에 맞춘 Github Actions 파일이 생성되고, 바로 적용할 수 있는 SDK cli 명령어 모음집을 markdown 파일로 생성합니다.
   • 사용자는 최종적으로 Terraform 파일, Github Actions 파일, SDK 명령어 모음집 파일을 다운로드 받게됩니다.
4. 사용자는 해당 정보를 바탕으로 마저 배포를 쉽게 진행할 수 있습니다.
   • 클라우드 콘솔로 바로 이동할 수 있는 버튼이 생성되어 즉시 적용할 수 있습니다.

• 프론트엔드를 빠르게 배포하기 위해 AWS Amplify를 사용했습니다.
• 람다를 활용하는 Serverless Architecture이기 때문에 백엔드 서버가 필요없고 CloudFront, AWS WAF, AWS Shield와 같은 부가 서비스와의 연결도 매우 편하기 때문입니다.

• 저희 서비스는 Event-driven Application이기 때문에 API Gateway로 모든 통신이 이루어집니다.
• 위의 Architecture에 api 경로도 자세하게 적혀있습니다.

• Event-driven Application에서 Serverless Architecture를 구현하기에 적합한 Lambda를 사용했습니다.
• 서버를 운영하지 않기 때문에 비용효율적입니다.

• Amplify에 포함된 WAF, AWS Shield를 활용하여 기본적인 보안을 구현했습니다.

• CloudWatch를 사용해 Lambda와 Step Functions이 정상적으로 trigger 되고있는지 확인하고, 버그픽스를 진행했습니다.
• Step Functions Log를 사용해 Step Functions가 동작할 때 AI응답을 확인하고, 프롬프트 엔지니어링을 진행했습니다.

• 원본 회의록도 같이 첨부해두겠으나, 원본 회의록은 한국어로만 작성되어 있습니다.

2025-10-31

• 팀원들과의 첫 만남이 이루어진 날이었습니다.
• 해커톤 주제를 어떻게 해야할지, 어떤 방향성으로 가져가는게 좋을지 11월 2일까지 생각해보는 시간을 갖기로 했습니다.

2025-11-02

• 각자 아이디어를 생각해와서 팀원들과 간단히 공유하고, 아이디어를 하나로 모으는 작업을 진행했습니다.

각자의 사전조사 내용

• 서호
  • AWS, Azure, GCP에서 배포를 도와주는 서비스에는 어떤 것들이 있는지, 어떻게 도와주는지 조사했습니다.
  • 배포하는 순간을 불행하게 만드는 순간에는 어떤 것이 있는지 생각해보고, 그 부분을 해결해주고자 했습니다.
  • 개발자 입장에서는 배포 과정 자체가 없는 것이 제일 편하다는 의견을 제시했습니다.
  • 각종 로그와 코드베이스를 보고 문제가 발생했을 때 에러의 root cause analysis를 진행해서 해결방안까지 추천해주는 Observability AI agent 아이디어를 제시했습니다.
• 동욱
  • 배포 과정에서 AWS, Azure, GCP 중 어느 클라우드에 배포하는 것이 가장 효율적인지를 해결해주는 것이 어떻겠냐는 아이디어를 제시했습니다.
  • 핵심 기능, 프론트와 백엔드에서 사용할 기술과 로직에 대해 자세히 서술했습니다.
• 재엽
  • 우리 해커톤의 평가요소를 바탕으로, 각 평가요소에 영향을 줄 수 있는 하위 항목이나 클라우드 서비스에 대해 조사했습니다.
• 호정
  • 배포 자동화 플랫폼 아이디어를 가져오고, 이를 실현할 수 있는 핵심 기능을 작성했습니다.
  • 무중단 배포를 구현하고자 할 때 발생할 수 있는 어려움을 조사했으며, 재미있는 배포를 고민했습니다.

회의 내용

• ‘재미’에 집중하여 Gamification 요소를 집어넣자는 아이디어가 나왔습니다.
  • 서호: 배포 과정을 여러 개의 단계로 정의하고, 각 단계를 클리어하는 미니게임 느낌을 제안했습니다.
• 배포 자동화를 도와주는 앱은 다른 팀들도 모두 비슷하게 선택할 주제이기 때문에, 테라폼 파일을 대신 작성해주는 것과 예상 비용까지 출력해주는 것을 우리 팀의 차별점으로 가져가자는 이야기가 나왔습니다.
• 사용자가 앱을 보여주면 어떻게 배포하는지 추천해주는 서호의 아이디어와, 테라폼 파일을 대신 작성해주는 것과 예상 비용까지 출력해주는 동욱의 아이디어를 합치는 것이 좋겠다는 이야기가 나왔습니다.
• 동욱: Terraform 파일을 대신 작성해준다는 아이디어는 좋지만, 배포까지 우리 서비스가 대신해줄 경우 보안상의 문제가 있을 수 있다는 이야기가 나왔습니다. AI에게 많은 권한을 줘야하기 때문에 에러가 발생할 경우 큰 문제가 발생할 수 있기 때문입니다.
  • 서호: 그렇다면 배포 내용을 쉽게 적용할 수 있는 cloud cli 명령어 모음집을 AI가 대신 작성해주는건 어떻냐는 의견을 제시했습니다.
  • 다른 팀원들도 이 개선안에 동의했습니다.
• 수인: GUI를 적극적으로 활용하여 사용자가 몇 번의 클릭만으로도 배포에 필요한 요소들을 모두 획득할 수 있도록 서비스를 만들자는 의견을 제시했습니다.

2025-11-03

각자의 사전조사 내용

• 동욱
  • 일단은 더미 데이터를 활용해 웹 데모를 구현하고, 그 다음 실제 로직을 구현하는 의견을 제시했습니다.
• 서호
  • Gamification을 활용한 웹이 어떻게 구성되는게 좋을지에 대해 User Flow를 작성하며, 각각의 flow에 어떤 동작이 필요한지 정의했습니다.
  • 이 서비스를 어떤 사람들이 사용하게될지 생각해봤을 때, 초보/중수/고수 모두 이 서비스를 사용할 수 있다는 생각을 했습니다.
• 재엽
  • Terraform 기반 멀티클라우드 배포 자동화, 비용 예측 + AI 추천 시스템, 시각화 + Gamification이 어떤 방식으로 구현되어야 할지에 대해 작성했습니다.
• 호정
  • 웹에 사용할 ui를 임시로 구현했습니다.
  • 각각의 기능에 대해 어떤 클라우드 서비스를 사용할 수 있는지 조사해왔습니다.
• 수인
  • 우리 서비스에 어떤 기술을 사용할지 생각해봤습니다.
  • Amazon Q를 사용해 서비스를 구현하는 것도 가능할 것 같은데, 그 구현 방식에 대한 조사가 아직 불충분하다는 내용을 작성했습니다.

회의 내용

• 클라우드 아키텍처 사진을 사용자가 직접 그려서 우리 웹에 업로드하면, 해당 사진을 인식하여 Terraform 파일로 만들어주자는 의견이 나왔습니다.
  • 그러나 우리 서비스는 클라우드 전문가가 아니라 개발자들의 배포를 도와주는 서비스이므로, 개발자들이 클라우드 아키텍처를 그리는 것에 익숙하지 않을 것이라는 의견이 나왔습니다.
  • 우리가 github repository에 접근해서 직접 코드 파일을 읽고 테라폼을 만들어주자는 의견이 나왔습니다.
    • 그러나 github repository 접근을 위해 로그인 기능을 구현하고, 토큰을 발급받는 과정이 꽤나 복잡할 것이라 생각해 해커톤 기간에 구현하기엔 부적절하다는 의견이 나왔습니다.
  • 개발자의 코드를 zip파일로 받아서 이를 분석하자는 의견이 나왔습니다.
• 우리가 ‘서비스의 첫 배포’만 도와준다는 걱정이 있었습니다.
  • 즉, 첫 배포를 진행하고 나서 그 다음 업데이트를 도와주지 않으며, 이미 있는 서비스에 대한 도움도 주지 못한다는 것이었습니다.
  • 우리 서비스에서 Github Action 코드까지 같이 만들어주자는 의견이 나왔습니다.
• 위 논의 내용을 바탕으로, 회의에서 1차적으로 우리 서비스의 User Flow를 정했습니다.
  1. 개발자가 Zip파일을 우리 서비스에 업로드하면서 시작합니다.
     • 로그인기능 구현X
  2. AI가 코드 분석 → 필요한 적정 규모를 추천해줍니다.
     • 해당 단계에서는 Terraform을 생성하지 않고, 비용 또한 계산해주지 않습니다.
     • 해당 단계에서는 배포 서버 규모를 측정해주는 단계입니다.
       • ‘너의 코드를 보면 이 정도 스펙을 쓰면 충분할 것같다’ 라는 내용입니다.
       • 사용자 입장에서 본인이 의사결정 권한을 갖고 스펙을 결정해야 한다고 생각했습니다.
       • 본인이 이 스펙으로 부족하다고 생각하면 더 좋은 스펙으로 변경 요청할 수 있고, 너무 과하면 다운 그레이드 요청하거나, AI가 추천한 사항을 바로 사용하겠다고 결정할 수 있습니다
     • 개발자가 제공한 Zip파일(코드베이스)과 프롬프트 (ex. 트래픽이 몰리는 시간대, 예산 등)를 입력으로 받습니다
       • 위 정보를 취합해서 AI가 스펙을 추천해주는 로직입니다.
  3. Terraform파일과 예상 월 비용을 제안하는 단계입니다.
     • 사용자가 선택한 내용 바탕으로 Terraform 파일을 클라우드 3사 모두 생성합니다.
     • 해당 Terraform 파일 바탕으로 클라우드 3사 각각의 비용을 측정합니다.
     • 사용자가 클라우드 3사 중 어떤 클라우드를 사용할 것인지 결정합니다.
  4. 사용자가 선택한 클라우드를 바탕으로 파일을 다운로드받는 단계입니다.
     • Terraform 파일 + Github Action yaml파일 + 클라우드 명령어 가이드가 적힌 md파일
  5. 끝

2025-11-04

각자의 사전조사 내용

• 동욱
  • 클라우드 기술을 모두 구현하는게 시간이 오래 걸릴 것으로 예상되기 때문에, 해커톤에서는 일단 더미데이터를 활용한 데모에 집중하는 것이 어떻겠냐는 의견입니다.
  • 11월 3일에 정했던 User flow를 바탕으로 어떻게 구현하는게 좋을지 생각해왔습니다.
• 재엽
  • 사용자로부터 zip파일을 받을 때, 환경변수와 같은 민감한 정보가 같이 넘어올 수 있다고 생각했습니다.
  • AI가 규모를 추천해주거나, 비용을 예상하거나, Terraform 코드를 생성할 때 활용할 수 있는 정보나 그 근거가 명확해야 한다고 생각했습니다.
• 서호
  • 11월 3일에 정했던 User flow를 바탕으로 어떻게 구현하는게 좋을지 생각해왔습니다.
  • 우리가 해커톤 기간동안 남은 시간이 많지 않기때문에, 우선 구현해야 할 부분과 추후에 발전사항으로 두어야 할 부분을 구분했습니다.
  • Step Functions와 Lambda를 활용한 Serverelss Architecture를 구성해본 경험이 있고, 이를 구성하는 것이 시간이 오래 걸리지 않기 때문에, 해커톤 기간동안 더미 데이터가 아니라 직접 인프라를 구성하자고 설득했습니다.
• 호정
  • 핵심 기능을 중심으로 UI가 어떻게 구성되어야 할지, 각 기능에 대해 필요한 api와 주고받을 데이터와 같은 api 명세서를 작성해왔습니다.
  • DB가 필요할수도 있겠다고 생각해 DB schema와 백엔드 흐름도 작성해왔습니다.

회의 내용

• 서호
  • 클라우드 서비스에 대해 잘 모르는 팀원을 위해 API Gateway, Lambda, S3의 동작 방식을 설명하고 회의를 진행했습니다.
• 동욱
  • 우리 서비스가 도와줄 수 있는 개발자의 특징 (페르소나)를 정하자는 의견을 제시했습니다.
    • 팀원들과의 회의를 통해 배포를 해본 적이 거의 없는, 배포 과정에 대한 이해가 부족한 초보 개발자를 페르소나로 설정했습니다.
• 논의 내용
  • AI가 terraform 파일을 작성해주는데, 코드 자체는 terraform 파일을 작성하는데 크게 도움이 되지 않아 사용자가 입력하는 프롬프트가 중요하다는 의견이 나왔습니다.
  • 그러나 우리 서비스의 예상 사용자를 초보 개발자로 설정했기 때문에, 프롬프트를 구체적으로 작성하지 않을 가능성이 큽니다.
  • 따라서 terraform파일을 만드는 데 도움이 되는 객관식의 설문조사를 통해 우리가 직접 프롬프트 양식을 구성하기로 했습니다.
• 개발 요구사항 정리
  • 프론트엔드는 AWS Amplify를 통해 빠르게 배포하는 것을 목표로 설정했습니다.
  • S3는 Pre-signed URL을 통해 zip파일을 빠르게 저장할 수 있도록 했습니다
  • 필요한 API Gateway, Lambda의 종류와 그 이름을 정했습니다.
• 역할 분담
  • 호정, 동욱
    • 프론트엔드와 클라우드 파트를 맡기로 했습니다.
  • 재엽, 수인
    • 백엔드(Lambda)와 클라우드 파트를 맡기로 했습니다.
  • 서호
    • Project Manager와 프론트엔드/백엔드에서 문제가 발생했을 때 같이 고민하고 해결해주기로 했습니다.

2025-11-05

회의 내용

• 서로가 이때까지 진행한 내용을 공유하고, 문제가 있다면 같이 고민해보는 시간을 가졌습니다.
• 서호
  • 프론트엔드와 백엔드에서 먼저 구현할 기능에 대한 우선순위를 제안했습니다
  • ‘초보 개발자’라는 페르소나를 바탕으로 하면 환경변수를 zip파일에 첨부하는 실수를 충분히 저지를 수 있다고 생각해서, 환경변수 파일을 우리 서비스에서 제외하고 AI에게 분석을 맡겨야 할 것 같다는 의견을 제시했습니다

2025-11-06

회의 내용

• 서로가 이때까지 진행한 내용을 공유하는 시간을 가졌습니다.
• ui 를 어떻게 구성할지에 대한 논의와 백엔드 코드를 어떻게 github에 업로드할 것인지에 대해 논의했습니다.

2025-11-07

회의 내용

• 서로가 이때까지 진행한 내용을 공유하고, 문제가 있다면 같이 고민해보는 시간을 가졌습니다.
• 서호
  • ui를 어떻게 구성할지에 대해 논의했습니다.
  • 백엔드 측에서 bedrock 호출과 관련한 에러가 발생하여, 해당 에러의 원인과 그 해결방안에 대해 서술해두었습니다.
• 여러 사용자가 동시에 우리 서비스를 이용하고 있을 때, 유저를 구분할 필요가 생겼습니다.
  • 그런데 우리는 로그인 기능을 구현하지 않았으므로, 람다 측에서 uuid를 발급하여 임시로 유저를 구분하기로 결정했습니다.
• User Flow를 다시한번 정리하면서, 기존의 user flow 대비 API Gateway를 더 세분화하고 조절해야 할 필요성이 있어 다음날 대면으로 만나서 확실히 수정하기로 했습니다.

최종적으로 아키텍처를 수정하고, api 경로와 필요한 lambda의 함수 종류도 같이 정리했습니다.

API 명세서를 작성하며 프론트엔드와 백엔드가 효과적으로 협업할 수 있도록 했습니다.

• 최종발표 전 설계 문서에 우리가 고민했던 부분이 잘 담겼는지 한번 확인했습니다.
• 배포를 마무리하고, 에러가 발생하진 않는지 전반적으로 검토했습니다.

현재 우리 앱은 원클릭 배포는 아닙니다. 사용자가 직접 받은 파일을 바탕으로 배포를 진행해야 합니다.

• Terraform 파일을 바탕으로 직접 사용자의 클라우드에 접근하여 LLM이 cli 명령어 입력을 통해 대신 배포를 해줄 수도 있습니다.
• 그러나 해당 방법은 보안상의 이슈가 굉장히 크다고 생각했습니다. 사용자의 클라우드에서 LLM의 예기치 못한 에러가 발생하면 막심한 피해를 입을수도 있기 때문입니다.
• 그래서 배포를 알아서 해주는게 아니라, 사용자가 배포를 손쉽게 할 수 있게 도와주는 서비스를 만들었습니다.
• 또한, AI가 클라우드 플랫폼에 접근해서 리소스를 생성하기 위해선 Access Key를 생성하거나, IAM을 구성해야 하는 경우가 있습니다.
  • 초보 개발자 입장에서 AI가 자신의 클라우드 플랫폼에 접근할 수 있도록 위 설정을 진행하는게 어려울 수 있겠다는 생각도 들었습니다.

• 프롬프트를 정교하게 작성하고, 충분한 데이터가 쌓이면 AI에게 배포를 맡겨도 될 것 같다는 생각입니다.

• 현재는 데이터의 부족으로 인해 단일 모델을 호출하는 것에서 그치고 있습니다.
• 그러나 데이터가 쌓인다면 해당 데이터를 활용해 Bedrock Agent를 통해 우리 서비스만의 AI를 만들어낼 수 있습니다.

• 현재 AI의 구조는 [사용자 요청] → [파일 생성] → [저장] 의 Flow를 가지고 있습니다.
  • 그렇기 때문에 에러가 발생하기 쉽습니다.
• 더욱 정확하고 정교한 동작을 위해서는 [사용자 요청] → [계획 수립] → [파일 생성] → [최종 검토] → [저장]의 Flow로 구성할 수 있습니다.
• 그러나 해당 방법은 해커톤 기간에 구현하기에는 너무 시간이 오래걸리며, AI 호출비용이 급증하기 때문에 우선은 보류했습니다.

• 이미 배포한 서비스에 대해 CI/CD를 도와주는 기능이 우리 서비스에는 존재하지 않습니다.
• 배포에 어느정도 익숙해진 개발자들도 우리 서비스를 통해 도움받을 수 있는 서비스를 만들고 싶습니다.