AI 웹빌더로 만든 페이지, 공개 주소까지 가는 법
AI 웹빌더로 만든 소개 페이지가 나만 보이는 이유와, 미리보기를 공개 주소로 바꾸는 배포 단계, 수정 범위를 좁혀 어긋남을 줄이는 방법을 정리했습니다.
3줄 요약
- AI 웹빌더는 긴 프롬프트보다 요청 한 줄과 도구가 되묻는 질문에 조건을 채우는 방식으로 더 정확하게 움직입니다.
- 화면이 완성되는 것과 공개 주소로 남에게 보낼 수 있는 것은 서로 다른 단계이며, 그 주소를 만드는 작업이 배포입니다.
- 수정할 때는 바꿀 화면 요소를 먼저 찍어서 지정하면 지시가 어긋나지 않게 반영됩니다.
롱폼 촬영본을 쌓아 온 크리에이터, 사내 설득용 화면을 빨리 띄워야 하는 마케팅 실무자, 가게 소개 페이지가 급한 스몰비즈 운영자는 모두 비슷한 지점에서 멈춥니다. AI 웹빌더에 몇 줄만 입력해도 그럴듯한 소개 페이지가 뜨는데, 그 화면 주소를 아는 사람이 정작 만든 자신뿐인 경우가 흔합니다. 화면이 완성되는 것과 남이 그 화면을 볼 수 있게 되는 것은 서로 다른 단계이고, 이 둘을 같은 일로 여기면 애써 만든 페이지가 혼자만의 미리보기로 남습니다.
소개 페이지 한 장은 작은 작업처럼 보이지만, 이 장벽에서 막히면 기획과 제작과 배포까지 직접 책임지는 사람에게는 꽤 큰 손실입니다. 한 줄 요청으로 화면을 만드는 법, 수정 요청이 어긋나지 않게 반영되도록 지시하는 법, 완성한 화면을 공개 주소로 바꾸는 배포 단계까지 순서대로 짚어두면 다음에 비슷한 화면이 필요할 때마다 같은 자리에서 막히지 않습니다.
코딩을 몰라도 소개 페이지를 만들 수 있을까요?
코딩을 몰라도 소개 페이지를 만들 수 있습니다. 브라우저의 대화창에 요청을 입력하는 것만으로 화면이 만들어지는 AI 웹빌더가 있기 때문입니다. 진입을 막는 건 대개 코딩 실력이 아니라 설치와 설정 같은 사용 환경이라서, 로그인 후 대화창만 뜨는 도구를 고르면 이 장벽 자체가 사라집니다.
촬영본을 쌓아 채널을 운영하는 크리에이터라면 프로필 링크 모음 대신 소개 페이지 한 장을 따로 두고 싶을 때가 있고, 마케팅 실무자라면 사내 설득용 프로토타입을 빠르게 띄워야 할 때가 있습니다. 스몰비즈 운영자도 가게 소개 페이지를 급하게 만들어야 하는 상황을 자주 마주칩니다. 세 경우 모두 개발자를 따로 구하지 않고 대화형 요청만으로 화면을 완성할 수 있다는 점은 같습니다.
배경에 움직이는 입체 효과를 넣는 것처럼 꽤 복잡해 보이는 디자인 요구도 말로 추가할 수 있습니다. 대화창에 원하는 분위기와 효과를 적으면 화면에 그대로 반영되고, 코드를 직접 다루지 않아도 시각적인 완성도를 끌어올릴 수 있습니다.
이 지점에서 중요한 것은 코딩을 아느냐가 아니라 요청을 어떻게 전달하느냐입니다. 다음 절에서 다루는 요청 방식이 결과물의 품질을 가르는 실질적인 변수입니다.
한 줄짜리 요청으로 충분할까요?
한 줄짜리 요청으로 충분합니다. 다만 요청은 짧게 던지고, 도구가 되묻는 질문 자리에서 조건을 채우는 방식이 한 번에 길게 쓰는 것보다 정확합니다. 자기소개와 경력 같은 큰 틀만 먼저 요청하고, 다크·라이트 모드나 다국어 지원 같은 세부 기능은 되묻기 단계에서 체크해 넣는 식입니다.
짧게 요청한 뒤 되묻는 질문에 답하며 다듬어 가는 방식은 AI 도구를 쓰는 작업 전반에서 반복되는 원리이기도 합니다. OpenAI의 프롬프트 작성 안내서도 프롬프트를 단번에 완성하려 하기보다 결과를 확인하며 점진적으로 다듬는 방식을 다룹니다(OpenAI, Prompt engineering).
이름만 던지고 AI가 알아서 채우게 두는 대신, 기준 문서를 붙이는 법처럼 AI에게 맡길 때 판단 기준을 먼저 좁혀두는 접근은 여러 작업에 공통으로 적용됩니다.
안내 문구가 영어로만 나올 때는 번역기를 쓰거나, 모든 지시사항을 한국어로 알려 달라고 요청에 적어 두면 해결됩니다. 결과물을 받아 보면 임시로 채워진 이름이나 경력이 들어 있는 경우가 흔한데, 대화창에 실제 정보를 알려 주면 그대로 다시 쓰고, 사진도 파일을 끌어다 놓는 것만으로 바로 바뀝니다.
완성된 화면을 왜 저만 볼 수 있을까요?
완성된 화면을 저만 볼 수 있는 이유는 아직 배포 전이기 때문입니다. 배포란 로컬 화면에서만 보이던 결과물에 공개적으로 접근 가능한 고유 주소를 부여해, 그 주소를 아는 누구나 같은 화면을 볼 수 있게 만드는 작업입니다. 화면이 뜬 상태는 혼자 쓰는 미리보기일 뿐이고, 남에게 보내려면 이 작업을 따로 거쳐야 합니다.
이 구분은 AI 웹빌더만의 특수한 규칙이 아니라 소프트웨어 전반이 공유하는 조건이기도 합니다. 한 대의 컴퓨터에서만 열리는 화면은 그 컴퓨터를 쓰는 사람만 접근할 수 있고, 다른 사람이 접근하려면 인터넷에 공개된 주소가 있는 서버로 그 결과물을 옮겨 두어야 합니다.
소개 페이지를 만드는 목적 자체가 남에게 보여 주는 것이라서, 만들어졌다는 것과 보낼 수 있다는 것은 분리해서 생각하는 편이 맞습니다. 화면만 완성해서는 그 목적이 채워지지 않습니다.
AI 도구를 써 본 뒤 결국 남은 게 없다고 느껴진다면, 대체로 이 미리보기 단계에서 멈췄기 때문입니다. 내 화면에서 되는 것과 남에게 보낼 수 있는 것을 나눠서 생각하는 쪽이 실제로 막히는 지점에 더 가깝습니다.
수정할 때마다 결과가 어긋난다면 무엇이 문제일까요?
수정할 때마다 결과가 어긋나는 원인은 대개 바꿀 범위를 말로만 설명했기 때문입니다. 말로만 설명하면 도구가 바꿀 범위를 넓게 짐작해서 엉뚱한 곳까지 바뀌기 쉽습니다. 바꾸고 싶은 화면 요소를 먼저 찍어서 지정한 다음 지시를 내리면, 어디를 바꿔야 하는지가 분명해져 수정이 깔끔하게 반영됩니다.
예를 들어 프로젝트 소개 영역을 찍어 두고 이 섹션을 인스타그램 광고팀에서 할 만한 프로젝트들로 바꿔 달라고 요청하면, 광고 효율 분석 대시보드 같은 항목이 그 자리에 정확하게 들어옵니다. 프롬프트를 길게 쓰는 것보다 범위를 좁히는 조작이 재현하기 쉽고, 도구가 바뀌어도 이 개념은 그대로 남습니다.
요구사항을 한 번에 몰아 전달하지 않고 확인 가능한 단위로 쪼개는 접근은 AI 코딩 도구를 다룰 때도 같은 원리로 작동합니다. 요구서 쪼개는 법도 전체를 한 번에 맡기는 대신 작은 단위로 나눠 확인하는 방식을 다룹니다.
결과를 통째로 받기 전에 기준이나 범위를 먼저 정해 두는 방식은 롱폼 영상을 다루는 자리에서도 같은 역할을 합니다. ENLIT은 촬영본 전체를 하나의 기준으로 알아서 넘기지 않고, 사용자가 정한 분석 필터 기준에 맞춰 쓸 구간을 골라냅니다. 범위를 먼저 좁혀두는 쪽이 결과를 다루기 쉽게 만든다는 점은 화면 수정이나 영상 구간 선별이나 다르지 않습니다.
완성한 페이지를 어떻게 공개 주소로 바꿀까요?
완성한 페이지는 배포 메뉴에서 기본으로 추천된 설정을 그대로 두고 확인 버튼을 몇 번 누르면 공개 주소로 바뀝니다. 그 주소를 받은 사람은 똑같은 페이지를 그대로 보게 됩니다.
절차는 다음과 같습니다.
- 화면 한쪽의 배포 메뉴를 선택합니다
- 기본으로 추천된 설정은 그대로 둡니다
- 생성된 주소를 복사해 전달하면 끝입니다
이 단계에서 비용 안내 화면이 뜨는데, 요금은 시점마다 달라지니 화면에 뜨는 숫자를 본문 주장처럼 받아들이기보다 직접 확인하는 편이 안전합니다.
배포는 개발자들 사이에서도 막상 손대 본 사람은 드문 작업으로 꼽히는데, 몇 번의 클릭으로 끝나는 쪽이 오히려 눈에 띕니다. 완성된 페이지는 휴대폰에서 열어도 레이아웃이 깨지지 않고 그대로 보이므로, 공유하거나 소개 자료로 바로 쓸 수 있는 수준입니다.
이 절차를 밟아 두면 다음에 비슷한 페이지를 만들 때도 같은 메뉴를 거치기만 하면 되므로, 매번 새로 배우지 않아도 됩니다. 반대로 이 단계를 건너뛰면 아무리 완성도 높은 화면도 공유 링크를 요청받는 순간 보여드릴 것이 없는 상태로 남습니다.
화면 문구와 요금, 그대로 믿어도 될까요?
화면 문구와 요금, 되돌리기 범위는 그대로 믿지 않는 편이 안전합니다. 도구 화면에 쓰인 메뉴 이름은 버전이 바뀌면 함께 바뀌고, 요금도 시점마다 달라지며, 이전 버전으로 되돌린 뒤 다시 앞으로 오는 방법은 확인되지 않았습니다.
화면 문구는 아래 한눈에 비교에서 정리한 것처럼 역할로 바꿔 읽는 편이 안전합니다. 되돌린 뒤에는 다시 앞으로 오기 어려워 보이니, 이 기능은 주의해서 쓰는 편이 좋습니다.
요금은 특히 조심해야 합니다. 화면에 뜨는 숫자는 특정 시점의 값이라, 아래 항목을 직접 확인하는 편이 낫습니다.
- 무료 구간에서 만들 수 있는 페이지 개수와 공개 여부 조건
- 유료로 전환했을 때의 실제 결제 금액과 환율 환산 기준
- 결제 안내 화면에 뜨는 비용의 정확한 산정 방식
한꺼번에 뽑힌 화면을 완성본으로 여기지 않고 발행 전에 점검하는 습관은 AI 산출물을 다루는 작업 전반에 적용됩니다. AI 산출물 점검 순서도 자동으로 나온 결과물을 초안으로 다루고 어긋난 항목만 되돌려 보내는 방식을 다룹니다. 화면 문구와 요금도 같은 태도로 다루면 됩니다.
한눈에 비교
| 화면 문구 | 실제 역할 |
|---|---|
| 프리뷰(preview) | 미리보기 창 |
| 엘리먼트 설렉트(element select) | 요소 지정 버튼 |
| 디플로이먼트(deployment) | 배포 메뉴 |
| 리커멘디드 오토 스케일(recommended auto scale) | 기본 추천 설정 |
| 롤백 투 히어(rollback to here) | 이전 버전 복원 |
오늘 바로 적용한다면
- 화면이 완성됐다면 배포 메뉴에서 공개 주소까지 만들었는지 확인합니다
- 수정 요청 전에 바꿀 화면 요소를 먼저 찍어서 지정합니다
- 큰 틀만 짧게 요청하고 세부 조건은 도구가 되묻는 질문에서 채웁니다
- 비용 안내 화면의 숫자는 그대로 믿지 말고 결제 전 직접 확인합니다
- 되돌리기 기능은 다시 앞으로 오는 경로가 확인되지 않았으니 신중하게 씁니다
자주 묻는 질문
소개 페이지를 완성했는데 왜 저만 볼 수 있나요?
화면이 뜬 상태는 아직 배포 전의 미리보기이기 때문입니다. 배포는 그 결과물에 공개적으로 접근 가능한 고유 주소를 부여하는 작업이고, 이 단계를 거쳐야 받은 사람이 같은 화면을 볼 수 있습니다. 배포 메뉴에서 기본 추천 설정을 그대로 두고 확인 버튼만 몇 번 누르면 공개 주소가 만들어집니다.
AI 웹빌더에 요청할 때 프롬프트를 길게 써야 하나요?
길게 쓸 필요는 없습니다. 자기소개와 경력 같은 큰 틀만 짧게 요청하고, 다크 모드나 다국어 지원 같은 세부 조건은 도구가 되묻는 질문 자리에서 채우는 방식이 한 번에 길게 쓰는 것보다 정확합니다. 이 방식은 되묻고 다듬어 가는 일반적인 AI 상호작용 원리와도 맞닿아 있습니다.
수정 요청이 자꾸 엉뚱하게 반영되는 이유는 무엇인가요?
범위를 말로만 설명하면 도구가 바꿀 범위를 넓게 짐작하기 때문입니다. 바꾸고 싶은 화면 요소를 먼저 찍어서 지정한 다음 지시를 내리면 어디를 바꿔야 하는지가 분명해지고, 수정이 그 자리에만 깔끔하게 반영됩니다.