System, Method, and for Website Construction Using a Generative Model

Abstract

The present invention relates to a website construction system, construction method, and construction program using a generative model. More specifically, the present invention relates to a website construction system, construction method, and construction program that sequentially generates a sitemap (structure), content (content), layout (design), and images (resources) based on user intent analyzed by a natural language processing model. The present invention comprises a sitemap management unit that constructs, modifies, or manages a sitemap by linking with a sitemap generation model based on input basic information; A content management unit that, based on input prompts, links with a content generation model to place, modify, or manage content generated in accordance with the sitemap in the sitemap; A layout management unit that, based on input prompts, links with a layout generation model to place, modify, or manage layouts generated to match sitemaps or content within the content; A website building system is provided that includes a layout management unit that places images generated according to a sitemap, content, or layout into a layout by linking with an image generation model based on input prompts. It is characterized by further including a database that stores at least one of prompt or prompt template data or sitemap data or content data or layout data.

Description

Technology Field

[0001] The present invention relates to a website construction system and method using a generative model. More specifically, the present invention relates to a website construction system and method that sequentially generates a sitemap (structure), content (content), layout (design), and images (resources) based on user intent analyzed by a natural language processing model. Background Technology

[0002] As the importance of websites grows day by day due to the proliferation of internet businesses, the demand for automation tools that allow even users without professional coding knowledge to easily create websites is surging. In particular, technologies that incorporate artificial intelligence (AI) to analyze user requirements and generate websites based on this analysis are currently being researched.

[0003] A related prior art is Korean Registered Patent No. 10-2766873, "Method and System for Automatically Generating an AI-Based Website" (hereinafter referred to as "Prior Art 1"). Prior Art 1 discloses a technology that analyzes a user's online presence to extract preferences, generates components including text, images, and layouts using a multimodal AI model, and then combines them to generate multiple website candidates. Furthermore, it includes a technology that selects the optimal website by comparing and evaluating user responses or performance indicators for the generated multiple candidates, and explains the generation process through Explainable AI (XAI).

[0004] However, since these prior art technologies focused on methods of generating and comparing various candidates, they had certain limitations in fundamentally resolving issues such as system resource efficiency, design consistency between generated pages, and loading speed problems caused by the generation of large-capacity images.

[0005] Conventional AI-based website generation technologies, including prior art 1, have the following problems.

[0006] First, there are issues regarding the waste of system resources and the degradation of generation speed. The prior art adopts a method of generating 'multiple website candidates' randomly or probabilistically to obtain optimal results, followed by retrospective comparative evaluation. This consumes unnecessary computational resources to produce a multitude of unconfirmed results and results in inefficiency, as it takes a significant amount of time to present the final result to the user.

[0007] Second, there are issues regarding website loading delays and degraded user experience (UX). Conventional technologies tend to generate text, layouts, and images integrally or process them simultaneously through multimodal AI. In particular, generating high-resolution images takes significantly longer than generating text or code; if this is processed simultaneously with layout generation, users must view a blank screen until the images are fully created.

[0008] Third, there is the issue of a lack of design consistency. Since the prior art generates designs individually for each page or candidate, it is difficult to maintain a consistent design identity that runs through the entire site. There is a risk that fonts, margins, and color tones may vary slightly from page to page. Prior art literature

[0009] Korean Patent Publication No. 10-2766873 (Published February 13, 2025) The problem to be solved

[0010] The present invention aims to resolve the waste of system resources and computational inefficiency caused by conventional multiple candidate generation methods, and to improve the problems of initial loading delay and degraded user experience resulting from the simultaneous processing of text and high-capacity images.

[0011] Furthermore, we aim to rapidly build a high-quality website by preventing the lack of design consistency across the entire website caused by individual page generation, and by blocking structural errors resulting from AI illusions through prompt template-based control. means of solving the problem

[0012] The present invention for achieving these objectives comprises a sitemap management unit that constructs, modifies, or manages a sitemap by linking with a sitemap generation model based on input basic information;

[0013] A content management unit that, based on input prompts, links with a content generation model to place, modify, or manage content generated in accordance with the sitemap in the sitemap;

[0014] A layout management unit that, based on input prompts, links with a layout generation model to place, modify, or manage layouts generated to match sitemaps or content within the content;

[0015] A website building system is provided that includes a layout management unit that places images generated according to a sitemap, content, or layout into a layout by linking with an image generation model based on input prompts.

[0016] It is characterized by further including a database that stores at least one of prompt or prompt template data or sitemap data or content data or layout data.

[0017] It is characterized by including an additional storage server for storing images.

[0018] It includes a prompt template lookup unit that, when a prompt is entered, looks up a prompt template corresponding to the entered prompt in the database,

[0019] The prompt template includes role definitions regarding the contextual background of the prompt or compliance requirements for duties to be performed when processing the prompt, and a list of input data for the prompt, and

[0020] It is characterized by including rules for prompt processing and constraints for prompt processing.

[0021] The prompt template is characterized by including a content creation prompt template; a layout creation prompt template; a sitemap creation prompt template; and a global style prompt template.

[0022] It further includes a data replacement unit that replaces prompt data based on the response received from a query request in a prompt query unit,

[0023] The prompt template includes categorized general word items, and

[0024] The data replacement unit is characterized by recognizing the site's basic information, sitemap, content, or global style content, and replacing general words in the prompt template received as a response to a query request with specific words entered.

[0025] The present invention further includes a header / footer management unit that manages a header and footer generated based on input basic information, wherein the header is placed in a first area on the homepage and the footer is placed in a second area different from the first area on the homepage, wherein the header and footer are managed separately from the generated content, layout, or images, and are implemented so as not to affect the header and footer when the content, layout, or images are changed or modified during homepage screen transformation.

[0026] The sitemap generation model is characterized by the fact that when a sitemap generation request is received from the sitemap management department along with a sitemap generation prompt, it analyzes the user's request-response history and reflects the request, reviews and creates or modifies the title, reviews and modifies the homepage ID, reviews and applies data processing rules based on the sitemap's hierarchy (Depth) to create or modify the sitemap, and sends it to the sitemap management department after performing final JSON generation and validation.

[0027] In the content creation model, when a content creation request is delivered from the content management unit along with a content creation prompt,

[0028] It is characterized by determining the input analysis and target page, analyzing the user's request-response history and / or checking the immediate content for the page name, identifying prohibited modifications in the basic sitemap structure / values, writing HTML tags for the main section (the hero section of the page) and additional sections representing supplementary information to the main section, reviewing and applying data processing rules based on the hierarchy (Depth) of the content to create or modify content, and outputting the final JSON string of the sitemap with added content attributes and sending it to the content management department.

[0029] The layout generation model is characterized by the fact that when a layout generation request is received from the layout management unit along with a content generation prompt, it first generates global styles and secondarily generates page-specific layouts and sends them back to the layout management unit.

[0030] When generating global styles in the layout generation model, if the layout generation model receives a basic global style and a global style generation prompt from the layout management unit, it analyzes the basic style / request and identifies the creation / modification target; if it is a color-gray token or a style related to the main section, it checks the content prohibiting modification; if it is possible to modify / create, it applies a color priority value to implement the color of the global style, writes the final HTML tag, and sends the final global style back to the layout management unit.

[0031] When generating page-specific layouts secondarily from the layout generation model

[0032] The layout generation model is characterized by analyzing existing responses, styles, and content, preparing main tags, processing the main section which is the hero section, adding images and applying image tag attribute rules when processing the main section, processing the general section below the main section, combining visual elements, visual implementation through text processing or block pattern combination, creating style tags by applying tag rules to assemble the final HTML, and outputting the final HTML code to the layout generation model.

[0033] When it is necessary to generate images for a layout, the image management unit queries the database for the layout HTML to receive a response, analyzes the layout HTML to list the images to be generated, and when the generation model receives a layout generation request from the layout management unit along with a content generation prompt, it generates the images, converts the generated images into binary or URL formats, and transmits them to the image management unit. The image management unit saves the binary data as an image and / or generates a URL, and updates the attribute values ​​of image tags within the HTML code with the generated URL.

[0034] The system further includes a user requirements management unit that manages user requirements, wherein the user requirements management unit is linked with a keyword extraction model, and when requirements are input to the keyword extraction model through the user requirements management unit, the keyword extraction model performs input text preprocessing and analysis, infers the model to pass it through an encoder and generates an embedding vector, generates logits for each label, applies a Sigmoid function to assign probability scores for each label, selects only the labels that exceed a threshold to create a result object, and returns the final keyword extraction result to the user requirements management unit.

[0035] In addition, the present invention relates to a method for constructing a website using a website construction system utilizing a generative model, comprising the step of: a sitemap management unit of the system receiving basic site information entered by a user; querying a sitemap generation prompt template from a database to replace the basic site information; and transmitting it to a sitemap generation model to generate sitemap structure data.

[0036] A step in which the content management unit of the above system calls a content creation prompt template based on the generated sitemap structure data, replaces user requirements and sitemap data, and transmits them to a content creation model to generate text content and HTML section structures corresponding to each page;

[0037] A step in which the layout management unit of the above system calls a layout generation prompt template based on the generated content and sitemap, replaces related data, and transmits it to a layout generation model to generate style and layout HTML code of a webpage; and

[0038] A method for constructing a homepage is provided, characterized in that an image management unit of the above-described system analyzes the generated layout HTML code to identify the location where image generation is required, and includes the step of reflecting the path (URL) of the image generated through an image generation model within the layout HTML code.

[0039] The step of generating the above sitemap structure data is,

[0040] The above sitemap generation model analyzes the prompt received from the sitemap management unit to reflect the user's Nth-level request, applies home menu rules depending on whether the top-level hierarchy (Depth 1) of the sitemap is 'Home', and identifies the number of lower-level hierarchy (Depth 2),

[0041] It is characterized by applying a rule to forcibly remove the lower hierarchy when there is one or modify the URL of the upper hierarchy when there are two or more, and finally verifying the total number of menus and whether constraints are satisfied for the generated sitemap data and outputting it in JSON format.

[0042] The step of generating the above text content and HTML section structure involves the content generation model identifying the first section of the page as the hero section,

[0043] The process includes generating a tag with a Hero Section class for the relevant section and validating title constraints; and for additional sections, reviewing the hierarchical use and validity of HTML tags and applying rules prohibiting external links, and

[0044] It is characterized by adding the generated content data as a 'content' attribute to the corresponding page object within the sitemap structure data and outputting the final JSON string.

[0045] The step of generating the above style and layout HTML code is,

[0046] A step of primarily requesting the creation of a global style to define and save a global style token value including a main color; and

[0047] It is characterized by including the step of secondarily requesting the creation of a layout for a specific page, applying the stored global style rules, combining visual elements, adding a grid or flex wrapper, and processing text to assemble the final HTML code.

[0048] The step of reflecting the path (URL) of the above image within the layout HTML code comprises the process of analyzing the layout HTML code generated by the layout management unit and listing image tags (img tags);

[0049] A process of requesting image generation from the image generation model for the number of images listed above;

[0050] The process of saving the generated image to a storage server and generating an accessible URL; and

[0051] It is characterized by including a process of updating the final webpage by updating the source (src) attribute value of an image tag within the above-mentioned layout HTML code to the above-mentioned generated URL.

[0052] In addition, the present invention provides a computer program stored on a computer-readable non-transient recording medium to execute the above method in combination with hardware.

[0053] In addition, the present invention comprises a data management unit that links with a data generation model based on input information or prompts to place, modify, or manage generated data on a screen;

[0054] It includes a database that stores at least one of a prompt, prompt template data, or generated data, and

[0055] It includes a prompt template lookup unit that queries a database for a prompt template corresponding to the entered prompt when a prompt is entered, and

[0056] It further includes a data replacement unit that replaces prompt data based on the response received from a query request in a prompt query unit,

[0057] The prompt template includes categorized general word items, and

[0058] A website construction system is provided characterized by a data replacement unit that replaces general words in a prompt template received as a response to a query request with specific words entered, inputs the replaced content into a data generation model, and receives the generated data.

[0059] It is characterized by further including a database that stores at least one of prompt or prompt template data or sitemap data or content data or layout data.

[0060] The management department includes a sitemap management department that builds, modifies, or manages sitemaps by linking with a sitemap generation model based on input basic information;

[0061] A content management unit that, based on input prompts, links with a content generation model to place, modify, or manage content generated in accordance with the sitemap in the sitemap;

[0062] A layout management unit that, based on input prompts, links with a layout generation model to place, modify, or manage layouts generated to match sitemaps or content within the content;

[0063] It is characterized by including a layout management unit that places images generated according to a sitemap, content, or layout into a layout by linking with an image generation model based on an input prompt.

[0064] The prompt template is;

[0065] Role definitions regarding the contextual background of the prompt or compliance requirements for duties to be performed when processing the prompt, and,

[0066] List of input data for the prompt and

[0067] Prompt processing rules and

[0068] It is characterized by including constraints on prompt processing.

[0069] Manage the header and footer generated based on the input basic information, but

[0070] Place the header in the first area of ​​the homepage, and

[0071] The header / footer management unit further includes a second area on the homepage that is different from the first area, characterized by placing the footer in the second area.

[0072] Headers and footers are managed separately from generated content, layouts, or images, and

[0073] It is characterized by being implemented so that the header and footer are not affected when content, layout, or images are changed or modified during homepage screen transformation. Effects of the invention

[0074] According to the invention, each step of generating sitemaps, content, layouts, and images is performed sequentially in an organic and logical order, thereby ensuring the systematic nature of website construction and maintaining consistency among data. This fundamentally resolves structural errors or content inconsistencies that frequently occurred in conventional integrated generation methods, and maximizes the technical completeness of the final output by providing a process that allows for verification and correction at each stage.

[0075] Furthermore, by separating the global style generation step and the individual page layout generation step, the present invention effectively ensures perfect design consistency throughout the entire website. Through this, design rules such as fonts, colors, and margins are consistently maintained even as the number of pages increases, enabling non-design professionals to implement a high-level brand identity comparable to that produced by a professional designer, even when using the system.

[0076] In particular, the present invention has the effect of significantly improving the initial loading speed by adopting a method in which image paths are pre-processed as temporary values ​​during layout generation, and the actual generation of high-capacity images is performed asynchronously in the background and injected subsequently. Users can immediately check the text and layout structure without having to wait for image generation to be completed, thereby preventing user abandonment due to system response delays and providing a pleasant and fast web surfing experience.

[0077] The present invention has the effect of suppressing hallucinations characteristic of AI models and producing accurate results that match the user's intentions by utilizing sophisticated prompt templates stored in a database to finely control the operation of generative AI.

[0078] Since even simple requirements entered by the user are converted and processed internally by the system into professional prompts containing specific role definitions, rules, and constraints, general users can obtain high-quality results without prompt engineering knowledge.

[0079] Furthermore, the present invention strictly applies data processing rules based on the depth structure when generating a sitemap, thereby clarifying dependencies between menus and preventing duplication of URLs and IDs. This logical structuring not only optimizes website navigation to enhance visitor convenience but also automatically generates a website with a structure advantageous for Search Engine Optimization (SEO), thereby increasing marketing efficiency.

[0080] The present invention provides a dynamic layout design technology that automatically applies a grid or flex wrapper by analyzing the amount and density of content in real time, thereby having the effect of implementing a visually balanced web page regardless of the amount of text or images.

[0081] By avoiding simple text listings and strategically placing various visual block patterns, such as card UIs and list UIs, it breaks away from monotony and provides an aesthetically pleasing user interface.

[0082] Furthermore, the present invention has the effect of generating semantic markup code that complies with web standards through the hierarchical use of HTML tags and validity review logic. It ensures code integrity by systematically blocking the duplicate generation of tags that require separate management, such as headers, footers, and navigation, thereby guaranteeing compatibility across various devices and browser environments and significantly improving the ease of future maintenance.

[0083] This invention has the effect of transforming abstract requirements into concrete design elements by accurately extracting and reflecting key keywords and latent intentions from users' unstructured natural language input through a user requirements analysis model. Even if users are unfamiliar with specific design terminology, the AI ​​analyzes the input context to suggest optimal styles and content suited to the industry and atmosphere, thereby maximizing user satisfaction and reducing communication costs.

[0084] Furthermore, the present invention adopts a dual storage method in which generated large-capacity image files are stored on a separate storage server and only metadata is managed in the database, thereby minimizing the load on the database and enhancing the operational efficiency of the system. This architecture enables the provision of stable services even in environments with high-volume traffic and improves overall system performance by optimizing the loading speed of web resources.

[0085] Finally, by automating the entire process of website construction—from planning and design to publishing and resource creation—based on AI, this invention provides overwhelming time savings and cost reductions compared to existing methods. This offers small business owners and individual users, who find it difficult to hire professional developers or outsource, the opportunity to own high-quality websites, thereby lowering the barrier to entry for web technology and accelerating digital transformation. Brief explanation of the drawing

[0086] FIG. 1 is a control block diagram of the present invention. Figure 2 is a flowchart for storing basic site information. Figures 3 to 5 are flowcharts for sitemap generation. Figures 6 through 8 are flowcharts of content creation. Figures 9 through 13 are layout creation flowcharts. Figures 14 and 15 are image generation flowcharts. Figure 16 is a flowchart of user requirements analysis. Fig. 17 is a screen for entering basic information on the front end. Figure 18 is a screen for entering a prompt for sitemap generation. Figure 19 is a screen showing the sitemap generated. Fig. 20 is a screen for entering a prompt for content creation. Figure 21 is a screen showing the result (HTML) of content generation. Figure 22 is a screen for entering prompts for layout creation. FIG. 23 is a screen showing the response to layout creation (main page creation output - no image). FIG. 24 is the response screen for layout generation (main page generation output - image loading). Fig. 25 is a screen for entering a modification prompt for the layout. FIGS. 26 and FIGS. 27 are screens where the layout changes according to the modification prompt. Fig. 28 is a screen for entering different modification prompts for the layout. FIGS. 29 to 32 are screens showing the results of re-editing the layout. Fig. 33 is a screen showing the saved result. Fig. 34 is a screen of the completed homepage. Specific details for implementing the invention

[0087] The present invention is capable of various modifications and may have various embodiments, and specific embodiments are illustrated and described in the drawings.

[0088] However, this is not intended to limit the invention to specific embodiments, and it should be understood that it includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the invention.

[0089] Terms including ordinal numbers, such as first, second, etc., may be used to describe various components, but said components are not limited by said terms.

[0090] The above terms are used solely for the purpose of distinguishing one component from another.

[0091] For example, without departing from the scope of the present invention, the second component may be named the first component, and similarly, the first component may be named the second component.

[0092] The term "and / or" includes a combination of multiple related listed items or any of the multiple related listed items.

[0093] When it is stated that one component is "connected" or "joined" to another component, it should be understood that while it may be directly connected or joined to that other component, there may also be other components in between.

[0094] On the other hand, when it is stated that one component is "directly connected" or "directly coupled" to another component, it should be understood that there are no other components in between.

[0095] The terms used in this application are used merely to describe specific embodiments and are not intended to limit the invention.

[0096] A singular expression includes a plural expression unless the context clearly indicates otherwise.

[0097] In this application, terms such as "comprising" or "having" are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0098] Hereinafter, embodiments will be described in detail with reference to the attached drawings, provided that identical or corresponding components are given the same reference number regardless of the drawing symbols, and redundant descriptions thereof will be omitted.

[0099] In the following description, each "module" or "part" may be any one of a PC (personal computer), smartphone, tablet PC, mobile internet device (MID), internet tablet, IoT (internet of things) device, IoE (internet of everything) device, desktop computer, laptop computer, workstation computer, Wibro (Wireless Broadband Internet) terminal, and PDA (Personal Digital Assistant), but is not limited thereto, and may be implemented as a server capable of hosting an online network and network addressing, and capable of accessing a separate database and writing or reading data.

[0100] The definitions of terms used below are as follows.

[0101] Sitemap: Refers to the menus that make up a website.

[0102] Content: Refers to the text that makes up each page of a website

[0103] Layout: In a narrow sense, it refers to the structure or form of a website; however, in this document, it refers to the overall output of each page of a website, including images, text, programming code, and design.

[0104] Header: The top menu and title section used commonly on all pages of a website.

[0105] Footer: The footer area, such as the privacy policy, used commonly on all pages of the website.

[0106] Content area: The area between the header and the footer

[0107] Global Styles: Style elements that are used commonly across all pages, such as color and font size.

[0108] A brief overview of the present invention is as follows. The present invention is an AI solution that configures a sitemap and content based on requirements entered by a user, and generates a layout based thereon. The process involves the steps of generating a sitemap in the first stage, content in the second stage, and a layout (programming code, images, etc.) in the third stage. This is explained in detail below.

[0109] Hereinafter, the configuration of a homepage construction system using a generation model according to an embodiment of the present invention will be described in detail with reference to the attached FIG. 1. FIG. 1 is a block diagram illustrating the overall data flow and control relationships of a system according to the present invention.

[0110] The website building system according to the present invention is largely composed of a front end (100) responsible for interaction with a user, a back end (200) that performs actual business logic and data processing, a plurality of generation models (300, 400, 500, 600, 900) that generate specialized results according to a request from the back end, and a database (700) and a storage server (800) that store data.

[0111] While each of these components may be physically implemented within a single server, it is desirable to physically distribute them in a cloud environment and functionally connect them via a network for load balancing and processing efficiency.

[0112] The front end (100) is a component that provides an interface (UI / UX) between the user and the system. Through this, the user inputs basic information (e.g., site name, industry, main color, etc.) and specific requirements (e.g., "Please create a cafe introduction page with a modern feel") for the homepage to be built. Additionally, it performs the role of an input / output terminal that visually checks the results (sitemap, content, layout, etc.) generated by the back end (200) and issues modification commands.

[0113] The backend (200) is the core brain of the system and mediates and controls between the frontend (100) and each generative model (AI Model). The backend (200) includes multiple functionally subdivided management units (Managers), which are organically combined to perform a step-by-step homepage construction process. The specific components of the backend are described below.

[0114] The communication unit (201) serves as a channel for transmitting and receiving data to and from the front end (100) and external generation model APIs, databases (700), etc.

[0115] The control unit (202) controls the operation timing of each management unit and manages the process flow of the entire system.

[0116] In particular, the backend (200) includes specialized components such as the following to efficiently utilize generative AI.

[0117] The user requirements management unit (213) and the user requirements analysis model (900) are modules that analyze unstructured natural language requirements entered by the user. The text entered by the user is transmitted to the user requirements analysis model (900) (e.g., a classification model based on KOBERT) and converted into key keywords or intents that the system can understand. This serves as a compass to help the subsequent generation model produce accurate results.

[0118] The prompt template lookup unit (204) and the data replacement unit (205) are one of the core technical features of the present invention. It is a step of generating a sophisticated instruction (prompt) containing expert know-how, rather than simply commanding the generative model (AI) to "make a homepage."

[0119] The prompt template lookup unit (204) retrieves a predefined optimal 'prompt template' from the database (700) to match the task to be performed (such as generating a sitemap or writing content). This template specifies the role, constraints, and output format (e.g., JSON format) that the AI ​​must adhere to.

[0120] The data replacement unit (205) creates a completed prompt by inserting specific information (site name, industry, etc.) entered by the user into the blank space (variable area) of the retrieved template. Through this, a general-purpose AI model is transformed into a customized expert unique to that user.

[0121] The sitemap management unit (208) and the sitemap generation model (300) play the role of establishing the 'structure,' which is the first step in building a homepage. The completed prompt is transmitted to the sitemap generation model (300) (LLM, etc.) to generate hierarchical data (e.g., JSON tree structure) that defines the menu structure (Depth 1, Depth 2, etc.) of the homepage.

[0122] The content management unit (208) and the content creation model (400) are configured to apply 'content (Flesh)' to the 'structure' framework generated by the sitemap management unit. By linking with the content creation model (400), text, phrases, and basic HTML section structures to be entered into each menu page are generated. Since sitemap information is referenced at this time, consistent content generation that fits the overall context is possible.

[0123] Layout management unit (209) and layout generation model (500): This is a configuration for applying 'designs (Clothes)' to content. It is linked with the layout generation model (500) to visually arrange content composed of text in an aesthetically pleasing way.

[0124] HTML / CSS code is generated to determine the color scheme, spacing, font style, etc., of a webpage. In particular, the present invention maintains design consistency by processing global styles and individual page styles separately.

[0125] The image management unit (210) and the image generation model (600) are components that provide visual image data as the final step of construction. When a "space requiring an image" is identified within the code generated by the layout management unit (209), an image suitable for that location is generated through the image generation model (600) (e.g., Stability AI model), stored in the storage server (800), and then the image path (URL) within the webpage code is updated (replaced) with the actual generated image address.

[0126] The header / footer management unit (211) is one of the distinguishing features of the present invention, and separately manages the top (header) and bottom (footer) areas that are common to all pages of the homepage. This reduces system load and increases maintenance convenience by allowing them to be applied to all pages with a single creation without the need for repeated creation for each page.

[0127] The site ID generation management unit (203) assigns and manages a unique identifier (ID) to each generated homepage project so that data is not mixed even when multiple users use the system simultaneously.

[0128] Explain the generative model (300, 400, 500, 600, 900).

[0129] These are AI engines that perform actual intelligent tasks upon receiving requests from the backend (200). In the present invention, instead of a single large model doing everything, models optimized for each role—such as sitemap generation, content generation, layout generation, and image generation—are separated and used (or the same model can use different parameters or prompts), thereby maximizing the quality and expertise of the results for each stage.

[0130] The database (700) stores structured data such as user basic information, generated sitemap data (JSON), text content, and prompt templates.

[0131] The storage server (800) stores large volumes of unstructured data, such as generated image files, and provides a URL accessible on the web.

[0133] < Site Basic Information Storage Flow >

[0134] Figure 2 shows the basic storage flow of the site.

[0135] FIG. 2 is a sequence diagram illustrating a series of flows in a homepage building system according to an embodiment of the present invention, in which a user inputs basic information of a website to be built, registers it in the system, and receives a unique project ID.

[0136] This process establishes a reference point for data to ensure that the subsequent 'sitemap generation,' 'content creation,' and 'layout generation' steps are organically connected; the specific operation process is as follows.

[0138] A. User Input and Request Steps:

[0139] First, the user inputs the 'basic site information' of the website to be built through the user interface (UI) provided by the front end (100). Here, 'basic site information' refers to the most basic metadata required for a generative AI model to infer the nature and direction of the site. For example, the site's name (Title), main industry (Category), target audience, preferred atmosphere (Tone & Manner), main color (Theme Color), etc., may be included.

[0140] This information serves as the core material to be substituted into the 'variables' section of the prompt template, which will be explained later. Once the information input is complete, the user clicks the "Save Site" button to request saving.

[0141] At this time, the front end (100) first validates the input value within the user's browser (e.g., checks whether required items are missing) and then calls the 'temporary site creation API' to the back end (200) server.

[0142] This process is performed asynchronously through a communication network, and the input site basic information is converted into a structured data format such as JSON and transmitted to the backend (200).

[0144] B. Backend Identifier Generation and Temporary Data Processing Steps:

[0145] When the control unit (202) and the site ID generation management unit (203) of the backend (200) receive an API request from the frontend (100), they generate a 'Site ID' that can uniquely identify the project within the system. This 'Site ID' has significant technical meaning within the system of the present invention. In this system, sitemaps, content, layouts, and images are each generated sequentially or in parallel by different AI models, and a common link is required for these fragmented results to be assembled into a single homepage. The site ID serves as that link.

[0146] After generating an ID, the backend (200) combines the generated site ID with the basic information entered by the user and sends a request to save to the database (700). At this point, it is important to note that the status of the site data is set to "Temporary" and saved.

[0147] This indicates to the system that it is in an 'initialization phase' where specific pages or content have not yet been created, serving as a safety mechanism for data management that allows the user to resume work from a 'temporarily saved list' even if they leave the task midway.

[0148] C. Database Storage and Response Steps:

[0149] The database (700) provides persistence by recording the basic information, status value, and generated ID received from the backend (200) into a table. When the saving is successfully completed, the database (700) returns the site ID to the backend (200) to indicate that the transaction was successful.

[0150] Next, the backend (200) transmits the processing result to the frontend (100) in the form of an HTTP response, including the generated site ID. Through this, the frontend (100) recognizes what project the user is currently working on, and communicates with the server by including this ID in all subsequent AI generation requests (such as sitemap generation).

[0151] D. Screen transitions and subsequent process linkages:

[0152] The front end (100) that receives the site ID in response routes the user's screen to the 'sitemap generation page'. This means that the process of FIG. 2 does not end with simply storing information, but serves as an entry point that naturally guides the user to the next step, the 'structure design (sitemap generation)' step.

[0153] As a result, users are provided with a continuous user experience (UX) where they feel, "After entering and saving basic information, I am ready for the next step: creating a sitemap."

[0154] To summarize, the process of Fig. 2 can be described as an essential preprocessing step that materializes intangible user requirements into 'data objects' manageable by the system through an organic flow of [user input] -> [API request] -> [generate unique ID] -> [save temporary state] -> [return ID and maintain session] -> [enter next step].

[0156] Sitemap Creation and Structuring Process

[0157] FIGS. 3 to 5 are sequence diagrams illustrating the process of generating a sitemap corresponding to the skeleton of a website in a homepage building system according to an embodiment of the present invention, divided chronologically.

[0158] Figure 3 shows the request and initial analysis steps, Figure 4 shows the logical processing and rule application steps within the generation model, and Figure 5 shows the storage of the final result and user response steps.

[0159] Below, each step is explained in detail by organically connecting them.

[0161] a. Sitemap Generation Request and Prompt Engineering Steps (See Fig. 3):

[0162] Creating a sitemap, the first step in building a website, begins with the process of converting the user's intent into a language that AI can understand.

[0163] User requirements are entered and transmitted. The user enters specific 'sitemap requirements,' such as the desired menu configuration or purpose of the site, on the 'sitemap generation page' of the front end (100) and requests generation. The front end (100) combines the unique 'site ID' issued in the process of FIG. 2 above with the 'requirements' entered by the user and calls the API to the back end (200).

[0164] Prompt template lookup and data merging are performed. The backend (200) uses the received site ID as a key to look up the 'site basic information' already stored in the database (700), and at the same time calls the 'sitemap generation prompt template' specialized for sitemap generation tasks.

[0165] Here, the sitemap generation prompt template refers to detailed sitemap generation prompt engineering guidelines that include role definitions regarding the context background of the prompt or compliance requirements for handling the prompt, a list of input data for the prompt, rules for handling the prompt, data output format, and constraints for handling the prompt.

[0166] At this time, the data replacement unit (205, see FIG. 1) inside the backend (200) dynamically maps and replaces the 'site basic information', 'user requirements', and 'previous response history' into the variable area (Slot) within the retrieved prompt template. Through this process, a 'complete prompt' with context injected is generated so that a general-purpose LLM model can function like a 'dedicated consultant' specialized for the project.

[0167] The creation model is called and history analysis is performed. The backend (200) sends the completed prompt to the sitemap creation model (300). The model (300) does not stop at simply creating new data, but analyzes 'RequestResponseHistory'. This is to ensure that the context of the previous conversation is not interrupted and maintains continuity by reflecting modification instructions (e.g., "Please remove the company introduction menu") or additional requests (Nth request) previously given by the user. At this stage, the addition, deletion, or modification of the menu is decided.

[0168] Data sanitization can be performed. The sitemap generation model (300) performs a primary verification of the title and ID of the menu to be generated. Since the title is text to be displayed in the UI, readability is reviewed, and since the ID may be used as a URL path later, it is sanitized and modified to comply with system rules (e.g., use of lowercase English letters, removal of spaces, etc.).

[0170] B. Hierarchy Determination and Rule Application Steps (See Fig. 4)

[0171] FIG. 4 shows in detail the logical control logic (Logic Flow) performed within the sitemap generation model (300). Since generative AI generates text probabilistically, the present invention enforces strict 'structural rules' for the stability of the system.

[0172] Top level (Depth 1) processing rule: The model (300) analyzes the depth (Depth) of the generated menu item. In the case of the 'Home' menu: If Depth 1 is identified as 'Home', it is the entry point of the site, so it is forced not to have a sub-menu (Depth 2) and applies a 'Home menu rule' that fixes the URL path to the root (' / ').

[0173] If the menu is not 'Home', it is classified as a general menu that can have a lower hierarchy (Depth 2) and separate logic is performed.

[0174] Depth 2 Dependency Processing Rule: The present invention includes dynamic processing logic based on the number of submenus to optimize the user experience (UX).

[0175] When the number of Depth 2s is 1, a structure in which only one submenu (Depth 2) exists under the top menu (Depth 1) is inefficient for navigation. Therefore, this system performs a 'Depth 2 forced removal logic' to eliminate the submenu and flatten the structure so that the top menu (Depth 1) directly performs the corresponding function.

[0176] At this time, URL and ID rules are also readjusted accordingly.

[0177] If there are 2 or more Depth 2 items, it is recognized as a normal dropdown or sub-menu structure, and the URL of the parent menu (Depth 1) is modified so that it does not conflict with the sub-menus.

[0178] Final verification and JSON generation are performed. Once all rule applications are complete, the model (300) performs a final check to determine whether the 'constraints are satisfied,' such as whether the total number of menus does not exceed the range allowed by the system and whether there are any duplicate URLs. Data that passes the verification is converted into a JSON (JavaScript Object Notation) format optimized for inter-system communication and is ready for output.

[0180] C. Result Saving and Visualization Step (See Fig. 5)

[0181] Figure 5 is a final step of permanently storing the computational results of the generation model (300) in the system and providing feedback to the user.

[0182] Return and save result: The sitemap generation model (300) returns the validated 'generated sitemap (JSON)' to the backend (200). The backend (200) saves this data by mapping it to the corresponding 'site ID' record in the database (700) without evaporating it. This saving process is essential because the sitemap structure must be retrieved again during the 'content generation' and 'layout generation' stages to be performed later.

[0183] User Response and UI Display: When saving is complete, the backend (200) sends the sitemap data to the frontend (100). The frontend (100) parses the received JSON data and converts it into a visual UI (User Interface) in the form of a tree structure or a navigation bar, and displays it to the user.

[0184] This allows users to visually verify the result of their input text requirements being converted into an actual website 'menu structure diagram'.

[0186] <Content Creation and Page Refinement Process>

[0187] FIGS. 6 to 8 are sequence diagrams illustrating the process of generating specific content (text, section structure, etc.) to be entered into each page defined in a sitemap in a homepage building system according to an embodiment of the present invention. FIG. 6 shows the content generation request and initialization step, FIG. 7 shows the content generation logic for each section, and FIG. 8 shows the final verification and saving step.

[0189] a. Content creation request and context injection steps (see Fig. 6)

[0190] Content creation begins when a user wishes to fill in the content of a specific page. This process is not merely simple writing, but rather a 'customized writing activity' that takes into account the role of the page and the context of the entire site.

[0191] User request and API call: The user enters 'content requirements' for a specific page (e.g., 'About Us' page) through the front end (100) and requests creation. The front end (100) calls the API to the back end (200), including the 'site ID' and 'content requirements'.

[0192] Prompt template loading and data replacement: The backend (200) retrieves 'site basic information' and 'content creation prompt template' from the database (700).

[0193] Here, the content creation prompt template refers to a detailed content creation prompt engineering guideline that includes role definitions for the context background of the prompt or compliance requirements for performing duties when processing the prompt, a list of input data for the prompt, rules for processing the prompt, and constraints for processing the prompt.

[0194] An important point here is that the backend (200) also references the 'previously generated sitemap data' and injects it into the prompt. This is to prevent the creation of incorrect content by allowing the content generation model (400) to determine the position (hierarchy) of the content currently being generated within the overall site structure. The data replacement unit (205) replaces all this information (basic information, sitemap, user requirements, history) into the template to generate a completed prompt.

[0195] Determination of work target and analysis of history: The content generation model (400) analyzes the received prompt to clearly determine the 'work target page'. In addition, by analyzing 'RequestResponseHistory' to identify the context related to the modifications or page name made by the user immediately prior to the request, it prepares for consistent content generation.

[0197] B. Logic for generating and structuring content by section (see Fig. 7)

[0198] FIG. 7 shows the generation logic of a 'Section' unit that constitutes a page within a content generation model (400). A web page is typically composed of a 'Hero Section' which serves as the main section at the top and 'General Sections' below it, and the present invention systematically generates these by distinguishing them.

[0199] Checking structural constraints: Before generating content, the model (400) checks the 'absolutely no modification to basic sitemap structure / values' rule. This is a safety measure to prevent accidentally breaking the menu structure (sitemap) while generating content.

[0200] Hero Section Processing: Creates the 'Hero Section,' the top area that determines the first impression of the page. <section>Create a tag, but assign the class='hero-section' attribute to leave an identifier so that a special design can be applied later during the layout stage.

[0201] Create the 'Hero Title' and 'Description' for the corresponding section. At this stage, verify that the title meets constraints, such as not being too long.

[0202] Creating Additional Sections: Create additional sections following the hero section to enrich the content. Write appropriate content for each section, while adhering to semantic markup rules.

[0203] Tag Validation: Checks if the generated HTML code is syntactically correct.

[0204] Apply link rules: Links within the body ( If tags are included, apply a rule that 'allows only sitemap URLs' and 'prohibits external links' to ensure time spent on the site and prevent users from leaving for external sites.

[0206] C. Final verification and data merging step (see Fig. 8)

[0207] Figure 8 is the final step of combining the generated content with sitemap data to create the final output.

[0208] Content Data Merging: The model (400) combines the HTML strings of each generated section into an array to create a 'final HTML string'. Then, this string is added as a 'content' attribute to the corresponding page object within the sitemap data structure.

[0209] If Depth 2 does not exist, add the 'content' property directly to the Depth 1 page object.

[0210] If there is a Depth 2, add the 'content' property to the corresponding Depth 2 page object.

[0211] Constraint Compliance Verification and Output Validation: Before final output, verify once again whether systemically prohibited elements are included.

[0212] Check prohibited tags: Since headers and footers are handled by a separate management department, within the content <header> , <footer>Tags or <nav>Checks whether tags, etc., have been created in duplicate.

[0213] Metadata Exclusion: Lightweight transmission data is achieved by removing unnecessary metadata and retaining only the pure sitemap JSON structure and content data.

[0214] Response and Storage: The validated 'sitemap JSON with added content attribute' is returned to the backend (200). The backend (200) passes this to the frontend (100), and the frontend (100) displays a 'content UI' on the screen that reflects the text and HTML structure.

[0215] Through this process, users can view a more complete web page, with actual reading material (text) and sections filled into the sitemap that previously consisted only of a framework.

[0218] <Layout Creation and Visual Structuring Deepening Process> (See Figs. 9 through 13)

[0219] The layout generation model (500) of the present invention generates executable HTML / CSS code by combining the aesthetic requirements of the user and the structural characteristics of the content. This process is strictly divided into a global style generation phase (Phase 1) and a page-by-page layout generation phase (Phase 2) and proceeds sequentially to distribute the load of the system and ensure the quality of the result.

[0220] A. Step 1: Creation of Global Style and Establishment of Design Rules (Refer to Figs. 9 and 10)

[0221] In website construction, the most important factor is the consistency of the 'Design Identity' that permeates the whole, rather than the flashiness of individual pages. To achieve this, the system first defines immutable style rules that apply to the entire site.

[0222] Request for global style creation and context merging (see FIG. 9): When a user executes the 'Create Layout' function on the front end (100), global style creation is primarily triggered. At this time, the back end (200) does not simply request style information.

[0223] At the same time as querying the 'basic global style' template from the database (700), all information regarding the 'basic information (industry, target, etc.)', 'sitemap (structure)', and 'content (content)' of the site currently being built is collected. The data replacement unit (205) of the backend (200) replaces and maps this vast amount of information to the 'global style generation prompt template'.

[0224] Here, the global style generation prompt template refers to detailed global style generation prompt engineering guidelines that include role definitions for the context background of the prompt or compliance requirements for performing duties when processing the prompt, a list of input data for the prompt, rules for processing the prompt, and constraints for processing the prompt.

[0228] Through this, the layout generation model (500) obtains sufficient context to infer not just a "simply pretty style," but a "style optimized for the content and industry."

[0229] Style Token Analysis and Intelligent Computation Logic (see FIG. 10): Based on the received prompt, the layout generation model (500) analyzes and generates 'Tokens,' which are the smallest units that constitute CSS styles. In this process, advanced computation logic is applied rather than simple generation.

[0230] Identification of Locking Areas: Color-gray tokens, which are essential for maintaining the system's UI framework, and styles related to Hero-sections, which are responsible for the site's first impression, are locked down to prevent the AI ​​from arbitrarily altering them. This serves as a technical safeguard to prevent layout collapse caused by the generative AI's hallucinations.

[0231] Intelligent Color Mixing Calculation (Auto-Calculation): When a user specifies only one main color or the AI ​​recommends it (Color Primary 01), the model (500) does not randomly select auxiliary colors (Color Primary 02~05) that match it. Instead, to ensure visual visibility and aesthetics, it mathematically calculates the Brightness Ratio and automatically applies it. Through this, even if a non-expert selects colors, a harmonious color palette similar to one created by a professional designer is generated.

[0232] Reflection of Nth Request and Verification of Code Integrity: When there is a repeated modification request (Nth request) from the user, the model (500) modifies the existing token value, maintains the !important declaration to ensure CSS priority, and checks whether the style is defined within the host selector so that it is not limited to a specific component. Finally generated <style> HTML 문자열은 추가 / 삭제 금지 확인을 거쳐 백엔드(200)로 출력된다.

[0234] 나. 제2단계: 전역 규칙의 저장 및 페이지별 상세 구현 (도 11, 도 12 참조)

[0235] 1차 단계에서 생성된 '디자인 헌법(Constitution)'인 전역 스타일을 기반으로, 이제 각 '주(State)'에 해당하는 개별 페이지들을 구체적으로 건설한다.

[0236] 전역 스타일의 영속화 및 규칙 전파 (도 11 참조): 생성된 전역 스타일은 데이터베이스(700)에 저장되어 영속성을 갖는다.

[0237] 이후 진행되는 '2차 요청: 페이지별 레이아웃 생성' 단계에서, 백엔드(200)는 이 저장된 '전역 스타일 규칙'을 다시 조회하여 레이아웃 생성 프롬프트에 포함시킨다. 이는 모든 페이지가 동일한 폰트, 동일한 컬러 시스템, 동일한 여백 규칙을 따르도록 강제하여 사이트 전체의 통일성을 기술적으로 보장하는 과정이다.

[0238] 페이지 컨테이너 및 히어로 섹션 구조화 (도 12 참조): 레이아웃 생성 모델(500)은 특정 페이지(예: 소개 페이지)의 레이아웃 생성 요청을 받으면 다음과 같은 구조화 작업을 수행한다.

[0239] 스코프 격리(Scope Isolation): 해당 페이지의 레이아웃이 다른 페이지와 충돌하지 않도록, <main> 태그를 생성하고 ID 속성에 고유한 pageName을 적용하여 스타일 범위를 격리한다.

[0240] 히어로 섹션(Hero-section)의 강제적 표준화: 페이지 상단의 히어로 섹션은 사용자 이탈률을 막는 가장 중요한 영역이다. 따라서 모델(500)은 이 영역의 HTML 구조 및 속성 변경을 원천적으로 금지한다. 대신, 시각적 임팩트를 위해 대표 태그 1개를 필수로 추가하도록 강제하며, 이때 이미지의 규격(Width / Height)과 접근성 속성(Alt) 규칙을 엄격히 적용한다. 또한, 이 영역의 스타일링은 오직 '전역 스타일'만 허용하여, 페이지마다 제각각인 헤더 디자인이 나오는 것을 방지한다.

[0242] 다. 제3단계: 콘텐츠 최적화 레이아웃 설계 및 최종 조립 (도 13 참조)

[0243] 히어로 섹션 하단의 일반 섹션(General Section)에서는 콘텐츠의 양과 성격에 따라 유연하고 창의적인 레이아웃이 적용된다.

[0244] 동적 레이아웃 결정 알고리즘 (도 13 참조): 모델(500)은 콘텐츠 텍스트의 양(밀도)을 분석하여 최적의 배치 방식을 결정한다.

[0245] Grid / Flex Wrapper 자동 적용: 많은 정보가 나열되는 경우 그리드(Grid) 시스템을, 순차적인 흐름이 중요한 경우 플렉스(Flex) 래퍼를 <section> 하위에 자동으로 추가한다.

[0246] 시각적 패턴 적용: 텍스트만 나열될 경우의 지루함을 없애기 위해, 텍스트를 가공하거나 카드(Card) UI, 리스트(List) UI 등 블록 패턴을 조합하여 시각적 변화를 준다. 이 과정에서 단조로운 레이아웃을 지양하고 창의적인 설계를 유도하는 로직이 작동한다.

[0247] 태그 및 스크립트 유효성 제어 (도 13 참조): 생성되는 코드의 품질을 위해 세밀한 제어가 수행된다.

[0248] 링크 및 이미지 규칙: 태그는 오직 href 속성만 사용하되 사이트맵에 정의된 내부 URL만 허용하며, 태그는 필수 속성(alt, width, height)을 준수해야 한다.

[0249] 인터랙션 및 스타일 격리: 페이지 전용 인터랙션이 필요한 경우 자바스크립트(JS) 코드를 작성하고, 페이지 전용 CSS는 @container 쿼리를 사용하여 반응형을 지원하되 전역 스타일을 침범하지 않도록 한다.

[0250] 구조적 제약사항 검증: 최종적으로 <main> 태그 내부에 <header>, <nav>, <footer> 등 전체 레이아웃을 깨뜨릴 수 있는 태그가 포함되었는지 검사하여 모든 제약사항을 충족하는지 확인한다.

[0251] 이미지 처리의 이원화 및 최종 출력 (도 13 하단 참조): 본 발명의 속도 최적화를 위한 핵심 기술이다.

[0252] 이미지 소스 경로 치환(Source Replacement): 모델(500)이 최종 HTML 코드를 출력하면, 백엔드(200)는 즉시 이를 파싱(Parsing)하여 코드 내에 포함된 모든 태그의 src 속성 경로를 "noimg"라는 임시 경로(Placeholder)로 일괄 치환한다. 이는 상대적으로 시간이 오래 걸리는 '이미지 생성(Image Generation)' 프로세스와 '레이아웃 생성(Layout Generation)' 프로세스를 분리(Decoupling)하기 위함이다. 이를 통해 사용자는 이미지가 생성되기를 기다릴 필요 없이, 즉시 레이아웃 구조를 화면에서 확인할 수 있어 응답 속도가 획기적으로 개선된다.

[0253] 경로가 치환된 수정된 레이아웃 데이터는 데이터베이스(700)에 저장되고, 프론트 엔드(100)로 전송되어 사용자에게 시각적으로 표시된다.

[0254] 이와 같이 본 발명의 레이아웃 생성 과정은 전역과 지역(페이지)의 조화, 구조적 안정성과 디자인적 유연성의 균형, 그리고 시스템 처리 속도까지 고려하여 설계된 정교한 프로세스이다.

[0256] <미지 생성 및 비동기적 리소스 주입 프로세스>

[0257] 이 단계는 앞선 레이아웃 생성 단계에서 구조적으로 확보된 '빈 공간(Placeholder)'에 '생성형 AI가 만든 시각적 결과물(Image Resource)'을 채워 넣는 공정이다. 본 발명은 이 과정을 레이아웃 생성과 분리하여 '후행적 비동기 처리(Post-Asynchronous Processing)' 방식을 채택함으로써, 전체 시스템의 응답 지연(Latency)을 최소화하고 사용자 경험(UX)을 극대화하는 기술적 특징을 가진다.

[0259] 본 발명의 이미지 생성 시스템은 텍스트와 레이아웃 구조가 확정된 이후, 후행적으로 고해상도 이미지를 생성하여 주입하는 '지연 로딩 및 주입(Lazy Generation & Injection)' 아키텍처를 따른다.

[0260] 도 14 및 도 15는 이러한 일련의 과정을 기술적 데이터 흐름에 따라 도시한 것이다.

[0262] 가. 제1단계: 비동기 트리거 및 HTML DOM 분석 (도 14 상단 참조)

[0263] 본 프로세스는 레이아웃 생성 모델(500)이 작업을 마치고 사용자에게 1차적인 웹 페이지(텍스트+구조)를 보여준 직후, 백그라운드에서 시작된다.

[0264] 비동기적 API 호출을 통한 프로세스 분리: 프론트 엔드(100)는 레이아웃 데이터를 수신하여 화면에 렌더링함과 동시에, 별도의 스레드(Thread) 또는 비동기 호출을 통해 백엔드(200)로 '페이지 레이아웃 이미지 생성 API'를 요청한다. 이때 전달되는 파라미터는 '사이트 ID'와 '현재 페이지 정보'이다. 이러한 비동기적 설계는 이미지 생성이라는 고연산(High-Computation) 작업이 UI 스레드를 차단(Block)하여 사용자의 브라우저가 멈추는 현상을 원천적으로 방지한다.

[0265] 레이아웃 HTML 조회 및 서버 사이드 파싱(Server-side Parsing): 요청을 수신한 백엔드(200)는 데이터베이스(700)에 저장된 해당 페이지의 '레이아웃 HTML 원본'을 로딩한다. 백엔드(200)의 이미지 관리부(210)는 로딩된 HTML 문자열을 DOM(Document Object Model) 트리 구조로 파싱하거나 정규식(Regular Expression)을 사용하여 분석한다.

[0266] 이 분석의 목적은 앞선 레이아웃 생성 단계에서 src="noimg"라는 특정 플래그(Flag) 값으로 마킹(Marking)된 태그를 전수 조사(Full Scan)하는 것이다.

[0267] 생성 타겟 리스트업(List-up) 및 컨텍스트 추출: 분석 과정에서 백엔드(200)는 단순히 이미지 개수만 세는 것이 아니라, 각 태그에 할당된 속성 정보(Attribute)를 추출하여 '생성해야 할 이미지 리스트'를 객체화한다.

[0268] alt 속성: 이미지 생성 프롬프트의 핵심 재료가 된다 (예: "modern office interior").

[0269] width / height 속성: 생성할 이미지의 종횡비(Aspect Ratio)를 결정한다. 이 과정을 통해 시스템은 "어떤 크기의, 어떤 내용을 담은 이미지를, 몇 개 생성해야 하는지"에 대한 정확한 명세서를 확보하게 된다.

[0271] 나. 제2단계: 프롬프트 엔지니어링 및 생성 루프 실행 (도 14 중단 참조)

[0272] 확정된 리스트를 바탕으로, 시스템은 반복문(Loop)을 통해 각 슬롯에 들어갈 이미지를 개별적으로 생성한다.

[0273] 동적 프롬프트 구성 (Prompt Composition): 백엔드(200)는 리스트의 각 항목에 대해 이미지 생성 모델(600)에 보낼 프롬프트를 동적으로 구성한다. 이때, 단순히 alt 텍스트만 보내는 것이 아니라, '사이트 기본 정보(예: 카페, IT기업)'와 '전역 스타일(예: 따뜻한 색감, 미니멀리즘)' 정보를 프롬프트에 결합(Merge)한다. 이는 생성된 이미지가 개별적으로는 훌륭하더라도 전체 사이트 분위기와 이질감이 생기는 것을 방지하기 위한 '톤 앤 매너(Tone & Manner) 일치' 기술이다.

[0274] 모델 호출 및 생성 수행 (Generation Execution): 구성된 프롬프트는 이미지 생성 모델(600)(Stability AI, Midjourney API 등)로 전송된다. 모델(600)은 확산 모델(Diffusion Model) 등의 알고리즘을 수행하여 텍스트 묘사에 부합하는 고화질 이미지를 생성한다.

[0275] 바이너리 데이터 수신 및 URL 변환: 모델(600)이 생성한 결과물은 일반적으로 바이너리 스트림(Binary Stream) 또는 인코딩 문자열 형태로 백엔드(200)에 반환된다.

[0276] 백엔드(200)는 이 데이터를 수신하여 메모리 버퍼에 담고, 파일 시스템이나 스토리지에 저장하기 위한 준비를 수행한다. 이 단계에서 이미지 파일의 포맷(WebP, PNG, JPG 등) 변환이나 압축(Optimization) 과정이 추가로 수행될 수 있다.

[0278] 다. 제3단계: HTML 코드 내 리소스 주입(Injection) 및 핫 스왑 (도 14 하단 참조)

[0279] 생성된 이미지를 HTML 코드와 결합하는 과정으로, 본 발명의 핵심적인 데이터 처리 기술이다.

[0280] 인메모리(In-Memory) 태그 치환: 백엔드(200)는 메모리에 로드되어 있는 레이아웃 HTML 코드에 대해 문자열 치환 또는 DOM 조작을 수행한다. 구체적으로는, 리스트업 단계에서 식별된 태그의 src="noimg" 속성값을, 방금 생성하여 확보한 실제 이미지의 URL(또는 저장될 예상 경로)로 교체한다. 이 과정은 모든 이미지가 생성될 때까지 반복되며, 결과적으로 HTML 코드 내의 모든 '빈 껍데기'가 '실제 콘텐츠'로 채워지게 된다.

[0281] 데이터 무결성 검증: 치환이 완료된 HTML 코드가 문법적으로 오류가 없는지, 이미지 경로가 유효한지 최종 검증을 수행한다.

[0283] 라. 제4단계: 리소스의 영속적 저장 및 배포 (도 15 참조)

[0284] 생성된 데이터는 휘발되지 않도록 저장소에 안전하게 기록되어야 한다. 본 발명은 데이터의 성격에 따라 저장소를 이원화하여 효율성을 극대화한다.

[0285] 스토리지 서버 오프로딩(Off-loading): 이미지 파일(바이너리)은 용량이 크기 때문에 데이터베이스에 직접 저장하지 않고, 스토리지 서버(800)(AWS S3, Google Cloud Storage 등)로 전송하여 저장한다. 이를 통해 웹 서버의 부하를 줄이고, 추후 CDN(Content Delivery Network) 등을 통한 빠른 전송이 가능해진다.

[0286] 데이터베이스 메타데이터 갱신: 이미지 파일이 스토리지에 저장되면, 그 접근 경로(URL)와 메타데이터(파일 크기, 생성일 등)는 데이터베이스(700)에 기록된다. 무엇보다 중요한 것은, 이미지 경로가 모두 업데이트된 '최종 완성형 레이아웃 HTML'을 데이터베이스(700)에 다시 저장(Update)한다는 점이다. 이로써 추후 사용자가 페이지를 다시 방문했을 때는 이미지 생성 과정을 거치지 않고 완성된 페이지를 즉시 로딩할 수 있게 된다.

[0288] 마. 제5단계: 클라이언트 동기화 및 UI 갱신 (도 15 하단 참조)

[0289] 서버 측의 모든 작업이 완료되면, 이를 사용자 화면에 반영하는 마지막 단계가 수행된다.

[0290] 완료 신호 전송: 백엔드(200)는 프론트 엔드(100)에게 '이미지 생성 완료 응답'을 전송한다. 이 응답에는 갱신된 HTML 데이터 전체가 포함되거나, 혹은 단순히 '완료되었다'는 시그널만 포함될 수도 있다.

[0291] 사이트 UI 갱신 (Re-rendering): 프론트 엔드(100)는 완료 신호를 수신하는 즉시, 사용자 브라우저의 화면을 갱신한다. 이때 전체 페이지를 새로고침(Refresh)할 수도 있으나, 사용자 경험을 위해 AJAX 등을 활용하여 이미지 영역만 부분적으로 업데이트하거나, 플레이스홀더(Skeleton UI)가 있던 자리에 이미지를 부드럽게 페이드-인(Fade-in) 시키는 방식으로 UI를 갱신하는 것이 바람직하다.

[0292] 결론적으로, 도 14 및 도 15의 프로세스는 AI 생성 모델의 속도 한계를 '비동기 아키텍처'와 '코드 레벨의 동적 주입 기술'로 극복하여, 사용자에게 쾌적하고 끊김 없는 웹사이트 구축 경험을 제공하는 고도화된 시스템 동작 원리를 보여준다.

[0294] <사용자 요구 사항 분석 모델>

[0295] 이 구성은 본 발명의 홈페이지 구축 시스템에서 필수적인 구성요소는 아니나, 시스템의 지능과 결과물의 정확도를 획기적으로 높여주는 구성에 해당한다.

[0296] 사용자의 모호하고 비정형적인 자연어 입력을 시스템이 이해 가능한 '정형 데이터(Structured Data)'로 변환하는 '자연어 처리(NLP) 전처리 프로세스'로서의 중요한 기술적 가치를 가진다

[0298] 도 16은 본 발명의 일 실시예에 따른 홈페이지 구축 시스템에 부가적으로 포함될 수 있는 '사용자 요구사항 분석 모델(900)'의 내부 데이터 처리 흐름을 도시한 것이다. 앞서 설명한 사이트맵, 콘텐츠, 레이아웃 생성 단계에서 사용자가 입력한 요구사항(Prompt)이 단순한 텍스트일지라도, 이를 그대로 생성 모델(LLM)에 전달하기보다는 '키워드 추출 모델(Keyword Extraction Model)'을 통해 사용자의 핵심 의도를 파악하고, 이를 구조화된 데이터로 변환하여 주입함으로써 생성 결과의 품질을 고도화할 수 있다.

[0300] 가. 프로세스의 개시: 비정형 데이터의 입력

[0301] 홈페이지 구축 과정에서 사용자는 "세련된 느낌의 카페 사이트를 만들어줘, 메뉴는 많지 않아도 돼"와 같이 구어체나 비정형 자연어로 요구사항을 입력하게 된다. 백엔드(200)는 이러한 원본 텍스트(Raw Text)를 그대로 사용하지 않고, 키워드 추출 모델(900)로 전송하여 분석을 요청한다. 이때 모델(900)은 딥러닝 기반의 자연어 이해(NLU) 모델, 예를 들어 KoBERT 등을 파인튜닝(Fine-tuning)하여 구현될 수 있다.

[0303] 나. 제1단계: 입력 텍스트 전처리 및 분석 준비

[0304] 사용자 요구 사항 분석 모델(900)은 입력된 텍스트를 기계가 처리하기 용이한 형태로 변환하는 전처리 과정을 수행한다.

[0305] 텍스트 검증 및 정제: 입력된 문자열에서 분석에 불필요한 노이즈를 제거한다. 예를 들어, 무의미한 특수문자, 중복된 공백, HTML 태그 등을 제거하거나 정규화(Normalization)하여 텍스트의 품질을 높인다.

[0306] 토크나이징 (Tokenizing): 정제된 문장을 모델이 이해할 수 있는 최소 의미 단위인 '토큰(Token)'으로 분해한다. 이때 사용되는 토크나이저(Tokenizer)는 한국어의 형태소적 특성을 반영한 것(예: SentencePiece, WordPiece 등)이 바람직하며, 각 토큰은 모델의 단어 사전(Vocabulary)에 매핑된 고유한 정수 인덱스(Input IDs)로 변환된다.

[0308] 다. 제2단계: 모델 추론 단계

[0309] 전처리된 데이터는 인공지능 모델의 내부 연산 과정을 거쳐 고차원의 의미 정보로 변환된다.

[0310] 인코더 통과 (Encoder Processing): 토큰화된 데이터는 BERT 등의 트랜스포머(Transformer) 기반 엔코더(Encoder)에 입력된다. 엔코더는 문장 내 단어들 간의 양방향 문맥(Context)과 상관관계를 분석하여, 문장의 심층적인 의미를 포착한다.

[0311] 임베딩 벡터 생성 (Embedding Vector Generation): 엔코더를 통과한 결과물은 다차원 공간상의 좌표값인 '임베딩 벡터'로 변환된다. 이 벡터는 입력 텍스트의 의미론적 특징(Semantic Features)을 함축하고 있는 숫자들의 집합이다. 예를 들어, '카페'라는 단어와 '커피', '분위기' 등의 단어는 벡터 공간상에서 가깝게 위치하게 된다.

[0312] 로짓 생성 (Logits Generation): 생성된 벡터는 분류 레이어(Classification Layer)를 통과하며 각 분류 카테고리(레이블)에 대한 로짓(Logits) 값을 생성한다. 로짓은 모델이 예측한 각 키워드(예: '모던함', '심플함', '식당', 'IT기업' 등)에 대한 정규화되지 않은 점수(Raw Score)를 의미한다.

[0314] 라. 제3단계: 후처리 및 결과 생성 (Post-processing)

[0315] 추론된 로짓 값은 사람이 이해할 수 있고 시스템에 적용 가능한 형태의 데이터로 가공된다.

[0316] 시그모이드 함수 적용 (Sigmoid Activation): 본 모델은 하나의 문장에서 여러 개의 키워드를 동시에 추출해야 하는 '다중 레이블 분류(Multi-label Classification)' 과제를 수행한다. 따라서 로짓 값을 확률값으로 변환하기 위해 시그모이드(Sigmoid) 함수를 적용한다. 이를 통해 각 레이블(키워드)에 대해 0.0에서 1.0 사이의 독립적인 확률 점수가 부여된다.

[0317] 임계값 필터링 (Threshold Filtering): 모든 예측 결과를 사용하는 것이 아니라, 확실한 정보만을 추출하기 위해 임계값(Threshold) 필터링을 수행한다. 도면에서는 기본값으로 0.5를 제시하고 있다. 즉, 모델이 해당 키워드일 확률이 50% 이상이라고 판단한(확률 >= threshold) 레이블만 유효한 결과로 선택하고, 그 미만의 불확실한 추론 결과는 버린다.

[0318] 결과 객체 생성: 선택된 레이블들을 바탕으로 최종 결과 객체를 생성한다. 이 객체는 추출된 '키워드 리스트(Keyword List)'와 각 키워드의 신뢰도를 나타내는 '스코어 딕셔너리(Score Dictionary)'를 포함한다.

[0320] 마. 최종 결과 반환 및 시스템 활용

[0321] 모델(900)은 최종적으로 분석된 (텍스트 원본, 추출된 키워드, 신뢰도 스코어) 데이터를 백엔드(200)로 반환한다.

[0323] 이를 통해서 백엔드(200)는 이렇게 반환된 '키워드' 정보를, 앞서 설명한 사이트맵 / 콘텐츠 / 레이아웃 생성 프롬프트 템플릿의 '변수 영역'에 더욱 정교하게 매핑할 수 있다. 예를 들어, 사용자가 "그냥 깔끔하게 해줘"라고만 입력했더라도, 분석 모델이 ['Minimalism', 'White_Theme', 'Modern']이라는 키워드를 추출해 줌으로써, 레이아웃 생성 모델(500)은 더욱 명확한 디자인 지침을 가지고 고품질의 결과를 생성할 수 있게 된다.

[0324] 이와 같이 도 16의 프로세스는 단순한 입력 값 전달을 넘어, 사용자의 '잠재된 의도(Intention)'를 데이터화하여 전체 시스템의 지능 수준을 한 단계 격상시키는 역할을 수행한다.

[0325] 이하에서는 실제 사용자가 프롬프트를 입력하여 홈페이지를 구축하되, 사이트맵 생성 및 수정, 콘텐츠 생성 및 수정, 레이아웃 생성 및 수정을 하는 것을 실제 화면으로 도시한 것을 설명한다.

[0326] 도17은 프론트 엔드에서 기본 정보를 입력하는 화면이다.

[0327] 도17에서는 사업자 등록번호, 주소, 대표 이메일과 같은 기본 정보를 입력하도록 되어 있고, 맨 아래에는 1 사이트맵 생성 > 2 콘텐츠 생성 > 3 레이이웃 생성의 상태 표시부가 마련되어, 현재 상태가 어느 상태인지 알 수 있도록 현재 상태에 해당되는 문구가 밝게 활성화 된다.

[0328] 도18은 사이트맵생성에 대한 프롬프트를 입력하는 화면이다

[0329] 여기서 화면 왼쪽 상부 코너에는 프롬프트 입력창이 마련되고, 그 아래에는 프롬프트 입력과 관련된 안내창이 표시된다. 그리고 오른쪽에는 생성 결과가 표시되는 생성 결과 표시창이 마련된다.

[0330] 여기서 예를 들어 특허법률 사무소에 대한 사이트맵을 구축하기 위하여 프롬프트 입력창에 "특허사무소이고, 주로 소프트웨어 특허를 많이 진행하는 회사야 간단하게 회사 소개 할꺼야" 라는 문구를 입력하면 도19와 같이 오른쪽에 사이트 맵이 트리 구조로 표시된다.

[0331] 한편, 프롬프트 입력과 관련된 안내창의 아래에는 "반영된 요구사항"이 표시되어 그전에 입력했던 프롬프트가 히스토리 형태로 누적된다.

[0332] 도20은 콘텐츠 생성에 대한 프롬프트를 입력하는 화면이다.

[0333] 생성된 사이트 맵에 넣을 컨텐츠를 생성하기 위해서 프롬프트 입력창에 "신뢰가 가도록 인물 이미지 사진을 많이 활용해주고 내용도 가상으로 풍부하게 작성해줘, 특허 관련 일반적인 내용으로 채워줘. 특히 디딤돌 같은 정부 지원 사업도 많이 하니깐 이 내용도 넣어주면 좋겠어"라는 콘텐츠 프롬프트를 입력한다.

[0334] 도21은 콘텐츠 생성에 대한 결과물(HTML)이 나타난 화면으로서, 생성된 콘텐츠와 관련된 텍스트가 HTML코드로 표시된다.

[0335] 본 발명의 장점은 컨텐츠와 HTML을 동시에 생성하는 방식이며, 특히 생성 모델이 특정 텍스트를 생성할때 바로 사용할 수 있는 HTML태그를 같이 생성하도록 함으로써 레이아웃 생성의 편의를 도모한다.

[0336] 도22는 레이아웃 생성에 대한 프롬프트 입력하는 화면이다.

[0337] 콘텐츠가 완성되면, 이에 맞는 레이아웃을 생성하기 위해서 프롬프트 입력창에 "인물 사진 많이 써주고 아이콘같은 것도 만들어주고 사이트가 풍부하게 보일 수 있도록 해줘"라는 프롬프트를 입력한다.

[0338] 이때, 오른쪽 결과 표시창에는 상부에는 헤더(회사소개, 서비스, 전문분야, 문의)가 표시되고, 하부에는 푸터(기업명, 대표이사, 주소, 사업자 등록번호)가 표시되며, 헤더와 푸터 사이는 아직 비어 있다.

[0339] 헤더와 푸터는 사이트맵을 기준으로 미리 본 출원인(운영자)이 제작한 레이아웃을 알고리즘으로 생성하고, 생성 모델은 헤더와 푸터 사이의 컨텐츠 영역을 생성하도록 두 데이터를 조합하여 페이지를 완성한다.

[0340] 도23은 레이아웃 생성에 대한 응답(메인페이지 생성 출력-이미지 없음) 화면이다. 입력된 레이아웃 생성 프롬프트에 따라서 레이아웃이 형성되는데, 이때 헤더 바로 아래의 히어로 섹션(예, 올바른 특허사무소: 귀하의 혁신을 위한 든든한 파트너)에는 문구만 표시되고 이미지 로딩 시간 동안에는 일시적으로 이미지는 표시되지 않으며, 히어로 섹션 아래에는 설명을 위한 일반 섹션이 표시된다.

[0341] 여기서 전역 스타일과 일반 페이지를 분리 관리 하고, 추후 조합하는데, 사용자의 요구 사항을 전역 스타일 모델과 페이지 레이아웃 생성 모델 각각에 전달하며, 각 데이터를 수집하고 이를 조합하여 페이지를 만든다.

[0342] 그리고, 웹사이트 페이지를 만들 때, 생성 모델이 생성한 레이아웃 데이터를 분석하여 이미지가 필요한 부분을 추출하고, 이를 바로 이미지 생성 모델에게 전달하여, 최종 이미지가 포함된 페이지를 사용자에게 전달하는 방식을

[0343] 도24는 레이아웃 생성에 대한 응답(메인페이지 생성 출력-이미지 불러옴) 화면으로서,이미지가 로딩되어 히어로 섹션에 표시된 것을 나타낸 것이다.

[0344] 생성 모델이 레이아웃을 생성할때 이미지 영역과 사이즈, 들어가야 할 이미지에 대한 설명을 생성하도록 하고, 이 부분만을 추출하여 별개의 이미지 생성모델에 전달하고, 이를 조합하여 페이지를 만드는 방식이 활용된다.

[0345] 도25는 레이아웃에 대한 수정 프롬프트를 입력하는 화면이다. 여기서는 "메인 페이지 레이아웃 다시 잘 가다듬어줘"라는 프롬프트를 입력한다. 그러면 도26과 도27과 같이 수정 프롬프트에 따라서 레이아웃이 바뀐다.

[0346] 도28과 같이 레이아웃에 대한 다른 수정 프롬프트를 입력(레이아웃을 풍부하게 해주고, 아이콘이나 사진 써줘. 그리고 사진은 그림같은거 말고 인물 사진같은 것으로 해줘)한다. 그러면 도29 내지 도32과 같이 레이아웃에 대한 재수정 결과를 출력한 화면이 표시된다.

[0347] 여기서 URL창에 표시된 URL 자체가 사이트 ID가 되며, URL를 새로운 URL창에 기입하거나 복사하여 붙여넣기를 하면 구현된 사이트가 보일 수 있다. 여기에 도메인을 연결하여 사용할 수 있다.

[0348] 도33은 저장 결과물이 보이는 화면으로 작업한 결과물, 회사 이름, 작업자, 생성일이 표시될 수 있다.

[0349] 도34는 위 과정을 거쳐 최종적으로 완성된 홈페이지의 화면으로서, 사이트맵, 컨텐츠, 레이아웃, 이미지가 완전하게 구현된 것을 나타낸 것이다.

[0350] 실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 한 것일 수도 있다.

[0351] 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체 (magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

[0352] 소프트웨어는 컴퓨터 프로그램(computer program), 코드(code)명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다.

[0353] 소프트웨어 및 / 또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호파(signal wave)에 영구적으로,또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

[0354] 이상과 같이 본 발명을 도면에 도시한 실시예를 참고하여 설명하였으나, 이는 발명을 설명하기 위한 것일 뿐이며, 본 발명이 속하는 기술 분야의 통상의 지식을 가진 자라면 발명의 상세한 설명으로부터 다양한 변형 또는 균등한 실시예가 가능하다는 것을 이해할 수 있을 것이다.

[0355] 따라서 본 발명의 진정한 권리범위는 특허청구범위의 기술적 사상에 의해 결정되어야 한다.부호의 설명

[0356] 100: 프론트 엔드 200: 백엔드 201: 통신부 202: 제어부203: 사이트 ID 생성 관리부 204: 프롬프트 탬플릿 조회부 205: 데이터 치환부 206: 생성 요청부 208: 사이트맵 관리부 208: 콘텐츠 관리부 209: 레이아웃 관리부 210: 이미지 관리부 211: 헤더 / 푸터 관리부 212: HTML 코드 관리부 213: 사용자 요구사항 관리부 300: 사이트맵 생성모델 400: 콘텐츠 생성모델 500: 레이아웃 생성모델 600: 이미지 생성모델 700: 데이터 베이스 800: 스토리지 서버 900: 사용자 요구사항 분석 모델< / style> < / nav> < / footer> < / header> < / section>

Claims

Claim 1 A website building system comprising: a sitemap management unit that builds, modifies, or manages a sitemap by linking with a sitemap generation model based on input basic information; a content management unit that places, modifies, or manages content generated to fit the sitemap by linking with a content generation model based on input prompts; a layout management unit that places, modifies, or manages layouts generated to fit the sitemap or content by linking with a layout generation model based on input prompts; and an image management unit that places images generated to fit the sitemap, content, or layout into a layout by linking with an image generation model based on input prompts; wherein, when a sitemap generation model receives a sitemap generation request along with a sitemap generation prompt from the sitemap management unit, the sitemap generation model analyzes the user's request-response history and reflects the request, reviews and creates or modifies the title, reviews and modifies the website ID, reviews and applies data processing rules based on the sitemap's depth to create or modify the sitemap, and sends the final JSON generation and verification to the sitemap management unit. Claim 2 A homepage building system according to claim 1, further comprising a database storing at least one of prompt or prompt template data or sitemap data or content data or layout data. Claim 3 A homepage building system characterized by further including a storage server for storing images in claim 1. Claim 4 A homepage building system according to claim 1, comprising a prompt template lookup unit that, when a prompt is entered, looks up a prompt template corresponding to the entered prompt from a database, wherein the prompt template includes: a role definition item regarding the context background of the prompt or a compliance item regarding obligations to be performed when processing the prompt, a list item regarding the input data of the prompt, a rule item for prompt processing, and a constraint item for prompt processing. Claim 5 A homepage building system according to claim 4, characterized in that the prompt template includes a content creation prompt template; a layout creation prompt template; a sitemap creation prompt template; and a global style prompt template. Claim 6 A homepage building system according to claim 4, further comprising a data replacement unit that replaces prompt data based on the response content received from a prompt inquiry unit, wherein the prompt template includes categorized general word items, and the data replacement unit recognizes the site's basic information or sitemap or content content or global style content, and replaces the general words of the prompt template received from the inquiry request with specific words entered. Claim 7 A website construction system according to claim 1, further comprising a header / footer management unit characterized by managing a header and footer generated based on input basic information, wherein the header is placed in a first area on the website and the footer is placed in a second area different from the first area on the website, wherein the header and footer are managed separately from the generated content, layout, or image, and are implemented so as not to affect the header and footer when the content, layout, or image is changed or modified during website screen conversion. Claim 8 delete Claim 9 It includes a sitemap management unit that builds, modifies, or manages a sitemap by linking with a sitemap generation model based on input basic information; a content management unit that places, modifies, or manages content generated to fit the sitemap by linking with a content generation model based on input prompts; a layout management unit that places, modifies, or manages layouts generated to fit the sitemap or content by linking with a layout generation model based on input prompts; and an image management unit that places images generated to fit the sitemap, content, or layout into a layout by linking with an image generation model based on input prompts. In the content generation model, when a content generation request is transmitted from the content management unit along with a content generation prompt, it analyzes the input and determines the target page for the task, analyzes the user's request-response history and / or checks the content immediately preceding the page name, recognizes prohibited modifications in the basic sitemap structure / values, writes HTML tags for the main section (the hero section of the page) and additional sections representing supplementary information regarding the main section, reviews and applies data processing rules based on the hierarchy (Depth) of the content to create or modify the content, and the final JSON string of the sitemap with added content attributes A website building system characterized by outputting and sending to the content management department. Claim 10 delete Claim 11 It includes a sitemap management unit that builds, modifies, or manages sitemaps by linking with a sitemap generation model based on input basic information; a content management unit that places, modifies, or manages content generated according to the sitemap in the sitemap by linking with a content generation model based on input prompts; a layout management unit that places, modifies, or manages layouts generated according to the sitemap or content in the content by linking with a layout generation model based on input prompts; and an image management unit that places images generated according to the sitemap, content, or layout in the layout by linking with an image generation model based on input prompts. When a layout generation request is transmitted from the layout management unit along with a content generation prompt, the layout generation model primarily generates global styles and secondarily generates page-specific layouts to send back to the layout management unit. When the layout generation model primarily generates global styles, if the request is transmitted from the layout management unit along with a basic global style or a global style generation prompt, the layout generation model analyzes the basic style / request and identifies the targets for creation / modification. If it is a color-gray token or a style related to the main section, it checks for prohibited modifications; if modification / creation is possible, it applies a color priority value to the color of the global style. A homepage building system characterized by implementing, writing final HTML tags, and sending final global styles to the layout management department. Claim 12 It includes a sitemap management unit that builds, modifies, or manages a sitemap by linking with a sitemap generation model based on input basic information; a content management unit that places, modifies, or manages content generated according to the sitemap in the sitemap by linking with a content generation model based on input prompts; a layout management unit that places, modifies, or manages layouts generated according to the sitemap or content in the content by linking with a layout generation model based on input prompts; and an image management unit that places images generated according to the sitemap, content, or layout in the layout by linking with an image generation model based on input prompts. When a layout generation request is transmitted from the layout management unit along with a content generation prompt, the layout generation model primarily generates global styles and secondarily generates page-specific layouts to send back to the layout management unit. When the layout generation model secondarily generates page-specific layouts, the layout generation model analyzes existing responses, styles, and content, prepares main tags, processes the main section which is the hero section, adds images and applies image tag attribute rules when processing the main section, processes general sections below the main section, combines visual elements, and implements visuals through text processing or block pattern combinations. A website building system characterized by creating style tags by applying tag rules to assemble the final HTML, and then outputting the final HTML code to a layout generation model. Claim 13 A website building system characterized in that, in the case where image generation is required for a layout, the image management unit queries the database for layout HTML to receive a response, analyzes the layout HTML to list the images to be generated, and when a layout generation request is transmitted from the layout management unit along with a content generation prompt, the generation model generates an image, converts the generated image into binary or a URL and transmits it to the image management unit, the image management unit saves the binary data as an image and / or generates a URL, and updates the attribute value of the image tag in the HTML code with the generated URL. Claim 14 A website construction system according to claim 1, further comprising a user requirements management unit for managing user requirements, wherein the user requirements management unit is linked with a keyword extraction model, and when requirements are input to the keyword extraction model through the user requirements management unit, the keyword extraction model performs input text preprocessing and analysis, infers the model to pass it through an encoder and generates an embedding vector, generates logits for each label, applies a Sigmoid function to assign probability scores for each label, selects only labels exceeding a threshold to create a result object, and returns the final keyword extraction result to the user requirements management unit. Claim 15 A method for constructing a website using a website construction system utilizing a generation model comprises: a step in which a sitemap management unit of the system receives basic site information entered by a user, queries a sitemap generation prompt template from a database to replace the basic site information, and transmits it to a sitemap generation model to generate sitemap structure data; a step in which a content management unit of the system calls a content generation prompt template based on the generated sitemap structure data, replaces user requirements and sitemap data, and transmits it to a content generation model to generate text content and HTML section structures corresponding to each page; and a step in which a layout management unit of the system calls a layout generation prompt template based on the generated content and sitemap, replaces related data, and transmits it to a layout generation model to generate style and layout HTML code for a webpage. A method for constructing a homepage, characterized in that the image management unit of the above system analyzes the generated layout HTML code to identify locations where image generation is required, and reflects the path (URL) of the image generated through the image generation model into the layout HTML code; and the step of generating the sitemap structure data includes the process of the sitemap generation model analyzing a prompt received from the sitemap management unit to reflect the user's Nth request, applying a home menu rule depending on whether the top level (Depth 1) of the sitemap is 'Home', determining the number of lower levels (Depth 2), and applying a rule to forcibly remove the lower level if there is one, or to modify the URL of the upper level if there are two or more, and finally verifying the total number of menus and whether constraints are satisfied for the generated sitemap data and outputting it in JSON format. Claim 16 delete Claim 17 A method for constructing a website using a website construction system utilizing a generation model comprises: a step in which a sitemap management unit of the system receives basic site information entered by a user, queries a sitemap generation prompt template from a database to replace the basic site information, and transmits it to a sitemap generation model to generate sitemap structure data; a step in which a content management unit of the system calls a content generation prompt template based on the generated sitemap structure data, replaces user requirements and sitemap data, and transmits it to a content generation model to generate text content and HTML section structures corresponding to each page; and a step in which a layout management unit of the system calls a layout generation prompt template based on the generated content and sitemap, replaces related data, and transmits it to a layout generation model to generate style and layout HTML code for a webpage. A method for constructing a homepage characterized by including the step of an image management unit of the above system analyzing the generated layout HTML code to identify locations where image generation is required, and reflecting the path (URL) of the image generated through an image generation model into the layout HTML code, wherein the step of generating the text content and HTML section structure includes the process of the content generation model identifying the first section of the page as a hero section, generating a tag with a hero section class for the corresponding section, and verifying title constraints; and for additional sections, reviewing the hierarchical use and validity of HTML tags and applying rules prohibiting external links, and adding the generated content data as a 'content' attribute to the corresponding page object within the sitemap structure data to output a final JSON string. Claim 18 A method for constructing a homepage according to claim 15 or 17, wherein the step of generating style and layout HTML code comprises: a step of first requesting the generation of a global style to define and store a global style token value including a main color; and a step of secondarily requesting the generation of a layout for a specific page to apply the stored global style rules, and assembling the final HTML code by combining visual elements, adding a grid or flex wrapper, and processing text. Claim 19 A method for constructing a homepage according to claim 15 or 17, wherein the step of reflecting the path (URL) of the image within the layout HTML code comprises: a process of analyzing the layout HTML code generated by the layout management unit to list image tags (img tags); a process of requesting image generation from the image generation model for the number of listed images; a process of storing the generated images in a storage server and generating an accessible URL; and a process of updating the final webpage by updating the source (src) attribute value of the image tag within the layout HTML code to the generated URL. Claim 20 delete Claim 21 delete Claim 22 delete Claim 23 delete Claim 24 delete Claim 25 delete

Images