AI로 사이트 만들고 배포하기

앞서 AI로 정적 페이지 옮겨오기에서는 이미 만들어져 있던 정적 페이지를 WEEGLOO가 관리하는 콘텐츠 기반 서비스로 옮기는 과정을 살펴봤습니다. 이번에는 페이지를 처음부터 새로 만드는 단계까지 포함해, 더 넓은 흐름을 다룹니다.

이 도움말에서는 LLM 에이전트와 WEEGLOO MCP를 활용해, 백지 상태에서 시작해 다섯 가지 작업을 차례로 진행합니다. 먼저 AI 기반 디자인 도구로 페이지의 디자인과 구현을 마치고, 이어서 생성된 페이지를 분석해 Content Type을 자동으로 정의한 뒤, 페이지에 적혀 있던 데이터를 Content로 적재합니다. 그리고 페이지가 CDA로 데이터를 가져오도록 코드를 고친 다음, 마지막으로 WEEGLOO의 Web Hosting으로 페이지를 외부에 공개합니다.

이 과정을 거치면 디자인부터 콘텐츠 관리, 배포까지 전 과정을 별도의 인프라를 직접 구축하지 않고도 LLM 에이전트와 WEEGLOO만으로 완성할 수 있습니다.

사전 준비

작업을 시작하기 전에 세 가지가 준비돼 있어야 합니다.

첫째, WEEGLOO에 새 Space가 비어 있는 상태로 만들어져 있어야 합니다. 앞으로 만들 Content Type과 Content가 모두 이 Space 안에서 관리됩니다. Organization과 Space에 대한 자세한 내용은 접근과 권한에서 다룹니다.

둘째, LLM 에이전트가 WEEGLOO MCP에 연결돼 있어야 합니다. 이 도움말은 Cursor IDE를 기준으로 진행하지만, Claude Desktop처럼 MCP를 지원하는 환경이라면 같은 흐름으로 진행할 수 있습니다. 설치 방법은 MCP에서 다룹니다.

셋째, 페이지의 디자인과 구현을 자동으로 만들어 주는 AI 도구가 필요합니다. 이 도움말은 편의상 Vercel v0을 쓰지만, Lovable, Bolt.new처럼 자연어 요청만으로 디자인과 코드를 함께 만들어 주는 도구라면 무엇이든 됩니다. 직접 코드를 쓰는 환경이 더 익숙하다면, Cursor IDE 같은 평소 쓰는 LLM 에이전트에게 디자인과 구현을 함께 요청해도 됩니다.

페이지 디자인 및 구현

가장 먼저 할 일은 페이지의 디자인과 구현을 마치는 것입니다. 이 단계에서는 어떤 페이지를 만들고 싶은지를 자연어로 정리해 AI 도구에 그대로 전달합니다.

이 도움말에서는 가상의 분석 API 서비스를 위한 API 문서 페이지를 예제로 씁니다. 많은 개발팀이 API 문서를 운영하려고 별도의 문서 도구나 외부 템플릿을 도입하지만, 이런 방식은 문서의 형태와 콘텐츠가 강하게 묶여 있어 자유로운 구조 변경이나 팀 흐름에 맞춘 운영이 어려운 경우가 많습니다. 이번에는 디자인부터 콘텐츠 관리까지 전 과정을 직접 구성해, 필요에 맞춰 자유롭게 운영할 수 있는 형태로 만들어 봅니다.

페이지에는 API 자체에 대한 정보(이름, 태그라인, 짧은 소개)와 함께, 각 엔드포인트에 대한 정보(HTTP 메서드, 경로, 요약, 설명)가 들어갑니다. 페이지의 구체적인 형태나 다루는 엔드포인트 수는 운영하는 API에 맞춰 자유롭게 정할 수 있고, 운영하면서 얼마든지 넓혀 갈 수 있습니다. 이런 요구사항은 다음과 같이 자연어로 풀어 AI 도구에 전달합니다.

Hey, I want to build a docs site for an analytics API called Pulse.
Standard API reference layout — an overview area with the API's name,
tagline, and a short intro, plus an endpoint reference section showing
the HTTP method, path, summary, and description for each. Clean,
dev-friendly, not too colorful — think Stripe-style readable.

요청을 받은 AI 도구는 디자인 시안을 만들고, 그에 맞는 마크업과 스타일을 함께 작성합니다. 이 시점에는 아직 콘텐츠 관리 시스템이 연결돼 있지 않아, 페이지에 보이는 모든 데이터가 코드 안에 직접 적혀 있는 형태입니다.

이렇게 만든 페이지의 코드를 내려받아 Cursor IDE 같은 LLM 에이전트 환경으로 가져옵니다. 이후의 모든 작업은 이 코드를 기반으로 진행되며, AI로 정적 페이지 옮겨오기에서 본 흐름과 같은 단계를 거칩니다.

콘텐츠 모델링

이 단계에서는 앞서 생성된 페이지의 데이터 구조를 Content Type으로 정의합니다. Content Type은 데이터의 설계도와 같아서, 어떤 Field를 가지는 데이터를 WEEGLOO에서 관리할지 미리 정합니다.

페이지의 코드를 보면 API 자체에 대한 정보와 각 엔드포인트에 대한 정보가 함께 들어 있고, 두 종류의 데이터가 일대다 관계를 이룹니다. 그래서 이 페이지는 API 정보를 담는 Content Type과 엔드포인트 정보를 담는 Content Type, 두 가지로 자연스럽게 나뉩니다.

이 분석과 Content Type 생성은 LLM 에이전트에게 다음과 같이 요청하는 것만으로 자동으로 이루어집니다.

Hey, I just dropped the page from v0 into the project.
The data's all hardcoded for now (the API info up top, the endpoints down
below).
 
I want to migrate it over to Weegloo so the page can pull its content from
a CMS instead of having it all baked in. Let's take it step by step rather
than doing the whole thing in one go.
 
To kick things off, could you take a look and figure out
what content types would make sense for it, then go ahead and create them
in Weegloo? We'll deal with the actual content and the API wiring in the
following steps.

요청을 받은 LLM 에이전트는 코드의 구조를 살펴 데이터의 종류와 관계를 추론하고, 각 Field에 어울리는 타입을 정한 뒤, WEEGLOO MCP로 Content Type을 만듭니다.

작업이 끝난 뒤 WEEGLOO 콘텐츠 스튜디오의 Content Type 페이지를 보면, API를 나타내는 Content Type과 엔드포인트를 나타내는 Content Type 두 개가 새로 만들어진 것을 볼 수 있습니다. API Content Type에는 이름·태그라인·소개 같은 Field가, 엔드포인트 Content Type에는 HTTP 메서드·경로·요약·설명과 함께 어떤 API에 속하는지를 가리키는 참조(Reference) Field가 들어갑니다.

이렇게 Content Type이 정의되면 이 구조를 바탕으로 실제 데이터를 적재할 준비가 끝납니다. Content Type에 대한 자세한 내용은 Content 모델링에서 다룹니다.

콘텐츠 생성

Content Type은 데이터의 형식을 정의할 뿐, 그 자체에는 데이터가 들어 있지 않습니다. 이번 단계에서는 앞서 정의한 Content Type을 바탕으로, 페이지 코드에 적혀 있던 실제 데이터를 Content로 옮깁니다.

LLM 에이전트에게 다음과 같이 요청하면, 코드의 데이터를 분석해 Content Type에 맞는 Content를 만들고 발행까지 함께 처리합니다.

Alright, the content types look good. Now let's move on to actually loading
the data.
 
Could you go through project again, pull out the actual content
that's hardcoded in there, and create entries in Weegloo using the content
types we just made? Once everything's in, go ahead and publish them too
so they're ready to be served.

요청을 받은 LLM 에이전트는 코드를 다시 분석해 데이터를 항목별로 나눈 뒤, WEEGLOO MCP로 API 정보와 각 엔드포인트 정보를 차례로 등록합니다. 등록된 Content는 외부에서 조회할 수 있도록 함께 발행됩니다.

작업이 끝난 뒤 WEEGLOO 콘텐츠 스튜디오의 Content 목록을 보면, API 정보와 엔드포인트 정보가 모두 발행된 상태로 등록돼 있습니다. 이때부터는 페이지의 코드를 직접 고치지 않아도, 콘텐츠 스튜디오나 LLM 에이전트로 데이터를 자유롭게 바꿀 수 있습니다.

Content의 작성과 발행에 대한 자세한 내용은 Content 작성과 발행에서 다룹니다.

CDA 연동

데이터까지 준비됐다면, 이번에는 페이지가 코드에 직접 적힌 데이터가 아니라 WEEGLOO의 CDA로 데이터를 가져오도록 코드를 고칩니다. CDA는 발행된 Content를 외부 서비스에서 조회하도록 제공되는 읽기 전용 API로, 웹 페이지나 모바일 앱이 WEEGLOO의 데이터를 직접 가져와 쓸 수 있게 해 줍니다.

이 작업도 LLM 에이전트에게 다음과 같이 요청하면 자동으로 이루어집니다.

Okay, almost there. The content's all in Weegloo and published, so now
let's hook the page up to actually use it.
 
Could you update project so that instead of having all that data
hardcoded in the markup, it fetches from Weegloo's CDA on load and
renders the page from the response? Basically the same page as before,
just pulling from the API now.

요청을 받은 LLM 에이전트는 코드에 박혀 있던 정적 데이터를 걷어 내고, 그 자리에 CDA 호출과 응답 데이터를 화면에 반영하는 코드를 채워 넣습니다. 엔드포인트 정보가 있던 자리에는 엔드포인트 Content 목록을 조회하는 CDA 호출이, API 정보가 있던 자리에는 API Content를 단건으로 조회하는 호출이 들어갑니다.

고친 페이지를 로컬에서 실행한 뒤 브라우저 개발자 도구의 Network 탭을 보면, 페이지가 로딩될 때 WEEGLOO의 CDA로 실제 요청이 보내지고 응답이 도착하는 것을 확인할 수 있습니다. CDA에 대한 자세한 내용은 Content Delivery API에서 다룹니다.

웹 호스팅

마지막 단계는 지금까지 만든 페이지를 외부에 공개하는 것입니다. WEEGLOO는 페이지를 직접 호스팅할 수 있도록 Web Hosting 기능을 제공합니다. 이를 통해 별도의 호스팅 인프라를 직접 구성하지 않고도 완성된 페이지를 누구나 접근할 수 있는 상태로 공개할 수 있습니다.

LLM 에이전트에게 다음과 같이 요청합니다.

Last thing — let's get this live.
 
Could you set up a WebHosting in Weegloo for this project and deploy the
page to it?

요청을 받은 LLM 에이전트는 페이지의 빌드 결과물을 Web Hosting에 올리고, 자동으로 발급되는 서브도메인을 통해 외부에서 접근할 수 있도록 페이지를 배포합니다.

배포가 끝나면 발급된 서브도메인 주소로 어디서든 페이지에 접근할 수 있습니다. 이때부터는 WEEGLOO 콘텐츠 스튜디오에서 Content를 고치기만 하면, 따로 빌드하거나 다시 배포하지 않아도 바뀐 내용이 곧바로 라이브 사이트에 반영됩니다. 새 엔드포인트가 추가되거나 기존 엔드포인트의 설명이 바뀌는 등 API 문서 운영에서 자주 일어나는 작업도 코드 수정 없이 처리할 수 있습니다.

나중에 운영 단계에서 자체 도메인을 쓰고 싶다면, WEEGLOO 콘텐츠 스튜디오에서 Custom Domain을 연결할 수 있습니다. Web Hosting과 Custom Domain에 대한 자세한 내용은 웹사이트 배포에서 다룹니다.

지금까지 백지 상태에서 시작해 디자인과 구현, 콘텐츠 관리, 배포까지 전 과정을 LLM 에이전트와 WEEGLOO만으로 완성해 봤습니다. 같은 흐름은 더 복잡한 사이트에도 그대로 적용할 수 있고, 운영하면서 새 Content Type을 추가하거나 Content의 양을 늘려 가는 작업도 같은 방식으로 자연스럽게 이어 갈 수 있습니다.