웹사이트와 앱을 한 번의 목표로 만들기

웹사이트 제작이 '코딩'에서 '목표 관리'로 바뀐다

예전에는 웹사이트 하나를 만들려면 일이 여러 조각으로 나뉘었습니다. 누군가는 기획서를 쓰고, 누군가는 와이어프레임을 그리고, 디자이너는 시안을 만들고, 개발자는 HTML과 CSS를 짜고, 백엔드 개발자는 데이터베이스를 붙이고, 마지막에는 배포 담당자가 서버와 도메인을 만졌습니다. 작은 랜딩페이지 하나도 생각보다 많은 손을 거쳤습니다.

Manus식 웹 제작은 출발점이 다릅니다. "이런 코드를 짜줘"보다 "이런 목적의 웹사이트를 만들어줘"가 먼저입니다. Manus는 웹 개발을 리서치, 콘텐츠 작성, 디자인, 프론트엔드, 백엔드, 데이터베이스, 외부 서비스 연동, 배포, 분석까지 하나의 대화형 흐름으로 묶는 방식으로 설명합니다.¹ 그래서 사용자는 세부 기술을 모두 몰라도 됩니다. 중요한 것은 "무엇을 만들 것인가", "누구에게 보여줄 것인가", "방문자가 무엇을 하게 만들 것인가"입니다.

이 장의 핵심은 간단합니다. Manus는 코드를 설명하는 도구에 머물지 않습니다. 작업 안에서 실제 파일을 만들고, 실행 가능한 웹사이트를 구성하고, 미리보기로 확인하게 하며, 배포 가능한 형태까지 밀고 갈 수 있습니다. 즉, Manus에게 웹사이트나 앱을 맡길 때는 개발자에게 기능 명세를 전달하듯 말하되, 마케팅 담당자처럼 전환 목표를 분명히 해야 합니다.

웹사이트를 만드는 일은 이제 "버튼 색을 뭘로 할까?"보다 "이 페이지가 누구의 어떤 행동을 이끌어야 하는가?"로 시작합니다. 이 질문을 잘 잡으면 Manus는 꽤 빠르게 초안을 만들어냅니다. 반대로 목표가 흐리면 결과물도 그럴듯하지만 애매한 페이지가 됩니다.

한 번의 목표는 어떻게 웹사이트가 되는가

Manus에게 웹사이트를 맡길 때 가장 먼저 이해해야 할 점은 "프롬프트 하나로 끝난다"가 "아무렇게나 말해도 된다"는 뜻은 아니라는 것입니다. 한 번의 목표는 짧아도 되지만, 그 안에는 방향이 들어 있어야 합니다.

좋은 웹사이트 요청에는 보통 다음 요소가 들어갑니다.

• 사이트의 목적: 리드 수집, 구매 전환, 예약, 포트폴리오 소개, 내부 업무 관리

• 타깃 사용자: 스타트업 대표, 마케팅 팀장, 채용 담당자, 행사 참가자, 잠재 고객

• 핵심 행동: 이메일 남기기, 데모 신청, 결제, 문의, 자료 다운로드, 회원가입

• 포함할 섹션: hero, 기능, 가격, 후기, FAQ, 문의 폼, 푸터 등

• 디자인 방향: 미니멀, 프리미엄, 친근함, B2B SaaS 느낌, 모바일 우선 등

• 기술 범위: 정적 페이지, 데이터베이스 포함 웹앱, 결제 포함 서비스, 관리자 화면

• 결과물 기준: 실행 가능한 미리보기, 반응형, 배포 가능한 상태, 수정 방법 설명

Manus는 사용자의 요청을 분석한 뒤 개발 계획을 세우고, 사용자가 그 계획을 검토한 다음 빌드에 들어가는 흐름을 제공합니다. 공식 문서에서도 첫 앱을 만드는 흐름을 자연어 요청, 계획 검토, 실시간 빌드, 미리보기 기반 수정으로 설명합니다.¹ 이 흐름을 잘 활용하면 "처음부터 완벽한 프롬프트"를 쓰지 못해도 괜찮습니다. 중요한 것은 초안이 나온 뒤 Manus와 대화하며 방향을 좁히는 것입니다.

실무에서는 이렇게 생각하면 쉽습니다. 첫 프롬프트는 완성품 주문서가 아니라 프로젝트 킥오프 문서입니다. Manus가 초안을 만들면, 그다음부터는 디자이너와 개발자에게 피드백하듯 말하면 됩니다.

첫 화면의 문구가 너무 추상적입니다. 타깃을 초기 B2B SaaS 창업자로 좁히고, '마케팅 실험을 하루 만에 시작한다'는 메시지를 더 강하게 보여주세요. CTA 버튼은 '무료 대기자 명단 등록'으로 바꾸고, hero 영역 바로 아래에 이메일 리드 캡처 폼을 배치해 주세요.

이런 식의 후속 지시가 Manus 웹 제작의 핵심입니다. 한 번에 끝내려 하기보다 "목표 제시 → 초안 확인 → 대화형 수정 → 배포 전 검수"로 접근하면 결과물이 훨씬 안정됩니다.

SaaS 캠페인 랜딩페이지를 한 번에 지시하기

가장 먼저 연습하기 좋은 주제는 SaaS 캠페인용 랜딩페이지입니다. 랜딩페이지는 구조가 비교적 명확하고, 전환 목표도 분명합니다. 방문자가 페이지를 읽고 이메일을 남기거나, 데모를 신청하거나, 결제 페이지로 이동하면 됩니다.

Manus의 랜딩페이지 빌더 소개 자료는 마케팅 팀이 엔지니어링 의존 없이 브랜드와 전환 목표에 맞춘 페이지를 빠르게 만들 수 있다는 점을 강조합니다. 이메일 리드 캡처 폼, 리드 저장용 데이터베이스, Stripe 결제, 실시간 분석, SEO 최적화, Figma 가져오기, 맞춤 도메인과 자동 SSL 같은 기능도 함께 언급합니다.² 이 말은 랜딩페이지를 단순한 '예쁜 소개 페이지'로만 볼 필요가 없다는 뜻입니다. 제대로 요청하면 리드 수집, 결제, 분석까지 포함한 캠페인 도구로 설계할 수 있습니다.

아래는 그대로 복사해서 바꿔 쓸 수 있는 기본 프롬프트입니다.

B2B SaaS 제품 'FlowDesk'의 캠페인용 고전환 랜딩페이지를 만들어주세요.
대상 고객은 직원 20~200명 규모의 스타트업 운영팀장과 마케팅 팀장입니다. 제품은 반복 보고서 작성, 고객 문의 정리, 내부 업무 요청 추적을 자동화하는 AI 업무 도구입니다.

페이지 목표는 이메일 리드 수집과 데모 신청입니다. hero 섹션에는 명확한 핵심 가치 제안, 짧은 서브카피, '무료 데모 신청' CTA, 이메일 입력 폼을 넣어주세요.

필수 섹션은 다음과 같습니다. hero, 문제 제기, 핵심 가치 제안, 기능 카드 6개, 사용 흐름 3단계, 가격표 3단계, 고객 후기, 보안 신뢰 요소, FAQ, 푸터입니다.

디자인은 현대적인 B2B SaaS 스타일로 해주세요. 흰 배경, 짙은 네이비 텍스트, 파란색 포인트 컬러, 여백이 넓은 카드형 레이아웃을 선호합니다. 모바일에서도 CTA와 이메일 폼이 잘 보여야 합니다.

이메일 리드 캡처 폼은 이름, 회사 이메일, 회사 규모, 관심 기능을 받을 수 있게 만들고, 제출 후 감사 메시지를 보여주세요. 가능하면 리드 데이터를 저장할 수 있는 구조도 함께 설계해 주세요.

SEO를 위해 title, description, 주요 키워드도 제안해 주세요. 완성 후 미리보기에서 확인할 수 있게 실행 가능한 웹사이트 형태로 만들어주세요.

이 프롬프트의 장점은 "예쁜 페이지"가 아니라 "전환을 위한 페이지"를 요청한다는 점입니다. hero 섹션, 기능 카드, 가격표, 후기, FAQ, 푸터는 랜딩페이지의 뼈대입니다. 여기에 CTA와 이메일 리드 캡처 폼이 들어가면 캠페인 실험이 가능해집니다.

특히 "제출 후 감사 메시지"처럼 작은 상호작용을 요청하는 것이 중요합니다. 폼은 모양만 있어서는 안 됩니다. 사용자가 이메일을 입력했을 때 어떤 일이 일어나는지까지 있어야 합니다. 초안 단계에서는 실제 CRM 연동이 아니더라도, 데이터를 저장할 테이블 구조나 추후 연동 포인트를 Manus가 설명하도록 요청해 두면 다음 작업이 쉬워집니다.

브랜드 톤과 전환 목표를 대화로 다듬는 법

랜딩페이지 초안이 나왔다고 바로 광고를 집행하면 안 됩니다. 첫 초안은 '가능성'에 가깝습니다. 실무에서 진짜 중요한 작업은 그다음입니다. Manus와 대화하며 타깃, 메시지, 구조, 디자인, CTA를 계속 조정해야 합니다.

마케팅 팀이나 1인 창업자에게 가장 유용한 흐름은 다음과 같습니다.

• Chat Mode에서 제품 설명, 타깃 고객, 전환 목표를 정리한다.

• 정리된 브리프를 Agent Mode에 넘겨 첫 랜딩페이지를 만든다.

• 미리보기를 보며 문구, 레이아웃, CTA, 폼 항목을 수정한다.

• 광고 채널별로 다른 버전의 hero 문구와 섹션 순서를 실험한다.

• 충분히 만족스러운 초안이 나오면 배포 전 체크리스트를 돌린다.

예를 들어 첫 버전이 너무 기능 중심이라면 이렇게 말합니다.

지금 페이지는 기능 설명이 많고 고객의 고통이 약합니다. 첫 화면에서 '매주 6시간 걸리던 보고서를 10분 만에 끝낸다'는 식으로 시간 절약 가치를 강하게 보여주세요. 기능 섹션보다 문제 제기 섹션을 앞에 두고, 고객이 겪는 반복 업무 스트레스를 더 구체적인 문장으로 바꿔주세요.

타깃을 바꾸고 싶다면 이렇게 지시합니다.

타깃을 스타트업 운영팀장이 아니라 B2B 마케팅 팀장으로 바꿔주세요. 주요 메시지는 '캠페인 리포트 자동화'와 '리드 후속 관리'에 맞춰주세요. 기능 카드도 마케팅 업무 기준으로 다시 작성하고, 가격표의 플랜 이름도 Starter, Growth, Scale로 바꿔주세요.

브랜드 톤을 조정할 때는 추상어만 쓰지 않는 것이 좋습니다. "세련되게"보다 "Notion처럼 차분하지만, Stripe처럼 신뢰감 있게"가 더 낫습니다. "젊게"보다 "20대 소비자 앱처럼 발랄하게, 단 금융 서비스처럼 과장된 표현은 피하기"가 더 좋습니다.

디자인 피드백도 구체적이어야 합니다.

현재 페이지가 너무 회색 위주라 약해 보입니다. 배경은 흰색을 유지하되, hero 영역에 부드러운 그라데이션을 추가하고 CTA 버튼은 더 선명한 파란색으로 바꿔주세요. 가격표 카드는 3개를 같은 높이로 맞추고, 추천 플랜에는 'Most Popular' 배지를 넣어주세요. 모바일에서는 가격 카드가 세로로 자연스럽게 쌓이게 해주세요.

Manus를 웹 제작 파트너처럼 쓰려면 피드백을 "내 마음에 안 든다"로 끝내지 말고, "누구에게 어떤 인상을 줘야 하는데 지금은 왜 부족한지"까지 말해야 합니다. 그러면 Manus는 단순히 색만 바꾸는 것이 아니라 구조와 문구를 함께 조정할 수 있습니다.

목적이 다른 사이트는 프롬프트도 달라야 한다

모든 웹사이트가 랜딩페이지는 아닙니다. 부티크 디지털 마케팅 에이전시 사이트, 이벤트 웹사이트, 개인 포트폴리오, 내부 대시보드는 각각 목적이 다릅니다. 목적이 다르면 포함해야 할 섹션, 정보의 우선순위, 디자인 톤, 필요한 기능도 달라집니다.

부티크 디지털 마케팅 에이전시 사이트

에이전시 사이트의 핵심은 신뢰입니다. 방문자는 "이 회사가 우리 브랜드를 맡길 만큼 실력이 있는가?"를 봅니다. 따라서 회사 소개, 서비스, 사례, 프로세스, 고객 후기, 문의 폼이 중요합니다. SEO 콘텐츠까지 고려한다면 블로그나 인사이트 섹션도 필요합니다.

부티크 디지털 마케팅 에이전시 'Northline Studio'의 회사 웹사이트 초안을 만들어주세요.
대상 고객은 월 광고비 1천만 원 이상을 집행하는 D2C 브랜드와 B2B SaaS 스타트업입니다.
사이트 목적은 신뢰 형성과 상담 문의입니다.

포함할 페이지 또는 섹션은 홈, 회사 소개, 서비스, 대표 사례 3개, 작업 프로세스, 고객 후기, 인사이트 글 목록, 문의 폼, 푸터입니다.

서비스는 퍼포먼스 마케팅, 랜딩페이지 개선, CRM 자동화, 콘텐츠 캠페인으로 나눠주세요. 사례 페이지에는 문제, 접근 방식, 실행 내용, 결과 지표, 배운 점을 넣어주세요.

디자인은 작지만 전문적인 전략 컨설팅 회사처럼 보이게 해주세요. 과한 애니메이션보다 여백, 타이포그래피, 사례 카드의 완성도를 우선해 주세요. 문의 폼에는 이름, 회사, 웹사이트, 월 예산, 고민 내용을 받게 해주세요.

이 프롬프트에서 중요한 부분은 "사례 페이지의 구조"입니다. 에이전시 사이트는 예쁜 문구보다 사례가 설득합니다. Manus에게 사례를 단순 카드가 아니라 미니 케이스 스터디처럼 만들라고 하면 훨씬 실무적인 초안이 나옵니다.

이벤트 웹사이트

이벤트 사이트는 참가자가 빠르게 판단할 수 있어야 합니다. 언제, 어디서, 왜 참석해야 하는지, 누가 말하는지, 어떻게 등록하는지가 첫 화면에서 보여야 합니다.

2026년 AI 업무 자동화 컨퍼런스 'Workflow Summit Seoul'의 이벤트 웹사이트를 만들어주세요.
목적은 참가 등록과 스폰서 문의입니다.

첫 화면에는 행사명, 한 줄 소개, 날짜, 장소, 등록 CTA를 명확히 보여주세요. 필수 섹션은 행사 소개, 추천 대상, 연사 카드, 시간표, 티켓 가격, 장소 안내, 스폰서 로고, FAQ, 등록 폼, 푸터입니다.

티켓은 Early Bird, Standard, Team Pass 3종으로 구성하고, 각 티켓의 혜택을 비교할 수 있게 해주세요. 모바일 사용자가 많을 것을 고려해 등록 버튼은 화면 곳곳에 반복 배치해 주세요.

디자인은 테크 컨퍼런스 느낌으로 어두운 배경과 네온 포인트를 사용하되, 본문 가독성은 유지해 주세요.

이벤트 사이트는 CTA 반복이 중요합니다. 방문자는 연사를 보고 등록할 수도 있고, 시간표를 보고 등록할 수도 있고, 가격표를 보고 등록할 수도 있습니다. 그래서 Manus에게 CTA 위치를 여러 곳에 배치하라고 요청해야 합니다.

개인 포트폴리오

포트폴리오 사이트는 "나는 누구인가"보다 "나는 어떤 문제를 해결해 왔는가"를 보여주는 것이 좋습니다. 특히 디자이너, 개발자, 마케터, 데이터 분석가는 프로젝트 설명의 깊이가 중요합니다.

프론트엔드 개발자 겸 제품 디자이너의 개인 포트폴리오 웹사이트를 만들어주세요.
목표는 채용 담당자와 스타트업 창업자가 3분 안에 역량을 파악하고 연락하게 만드는 것입니다.

포함할 섹션은 hero, 핵심 역량, 대표 프로젝트 4개, 프로젝트 상세 설명, 사용 기술, 문제 해결 과정, 오픈소스 활동, 추천사, 이력 요약, 연락 폼입니다.

각 프로젝트 카드는 문제, 역할, 사용 기술, 결과, 배운 점을 포함해야 합니다. 디자인은 미니멀하고 빠르게 로딩되어야 하며, 모바일에서도 프로젝트 카드가 보기 좋아야 합니다. SEO를 위해 이름, 직무, 주요 기술 키워드가 자연스럽게 들어가게 해주세요.

포트폴리오에서 흔한 실수는 이미지 카드만 나열하는 것입니다. Manus에게 "문제, 역할, 결과"를 넣으라고 말하면 포트폴리오가 채용 담당자에게 훨씬 유용해집니다.

내부 대시보드와 업무용 웹앱

대시보드는 랜딩페이지와 완전히 다릅니다. 예쁘게 설득하는 것이 아니라, 데이터를 이해하고 행동하게 만들어야 합니다. 지표, 필터, 표, 차트, 업로드, 권한이 중요합니다.

마케팅 팀을 위한 캠페인 성과 대시보드 웹앱 초안을 만들어주세요.
사용자는 광고 담당자와 팀장입니다.

CSV 파일을 업로드하면 캠페인별 지출, 클릭, 전환, CPA, ROAS를 계산해 보여주는 구조로 만들어주세요. 상단에는 핵심 KPI 카드, 중간에는 날짜별 추이 차트, 하단에는 캠페인별 상세 테이블을 배치해 주세요.

필터는 날짜 범위, 채널, 캠페인명, 목표별로 제공해 주세요. 오류가 있는 CSV가 들어오면 어떤 열이 빠졌는지 알려주는 메시지를 보여주세요.

초기 버전은 샘플 데이터로 작동하게 만들고, 나중에 데이터베이스와 로그인 기능을 붙일 수 있도록 파일 구조와 데이터 모델을 설명해 주세요.

이런 요청은 단순 웹사이트보다 웹앱에 가깝습니다. 따라서 결과물을 볼 때 디자인뿐 아니라 계산 로직, 오류 처리, 데이터 구조를 함께 확인해야 합니다.

초안 생성에서 배포 가능 상태까지의 실제 흐름

Manus가 작업 안에서 웹앱을 만들면, 사용자는 완성된 설명문만 받는 것이 아니라 작업 결과물의 미리보기와 파일 구조를 확인하는 흐름으로 나아갈 수 있습니다. Manus API 문서에는 에이전트가 사이트를 만들면 해당 작업에 웹사이트가 생기고, 게시되면 호스팅된 URL과 버전 이력이 관리된다고 설명되어 있습니다.³

실무 흐름은 다음과 같이 잡으면 좋습니다.

1. 먼저 목표를 충분히 설명한다. 랜딩페이지인지, 웹앱인지, 내부 도구인지 구분한다.

2. Manus가 제안한 계획을 검토한다. 빠진 섹션, 과한 기능, 불필요한 기술을 이 단계에서 조정한다.

3. 첫 빌드를 생성하게 한다. 이때 파일 구조, 주요 컴포넌트, 데이터 흐름을 함께 설명해 달라고 요청한다.

4. 미리보기에서 직접 사용해 본다. 버튼, 폼, 모바일 화면, 오류 메시지를 확인한다.

5. 수정 요청을 작게 나눈다. 문구 수정, 디자인 수정, 기능 수정, 데이터 수정은 한 번에 섞지 않는 것이 좋다.

6. 배포 가능한 상태인지 확인한다. 반응형, SEO, 폼 처리, 개인정보 문구, 오류 처리, 도메인 연결 여부를 점검한다.

7. 최종 배포 또는 공유 링크를 만든다. 팀 검토용이면 공개 범위를 조정하고, 고객용이면 도메인과 SSL을 확인한다.

이 과정에서 중요한 것은 "첫 결과물이 곧 최종 결과물은 아니다"라는 태도입니다. Manus는 빠르게 초안을 만들어 주지만, 비즈니스 판단은 사용자가 해야 합니다. CTA 문구가 우리 브랜드에 맞는지, 가격표가 실제 정책과 맞는지, 고객 후기가 허위처럼 보이지 않는지, 폼에서 받는 개인정보가 과하지 않은지 확인해야 합니다.

배포 단계도 점점 쉬워졌습니다. Manus의 퍼블리싱 문서는 서버 설정이나 배포 파이프라인 없이 Publish로 웹앱을 공개할 수 있고, 필요하면 맞춤 도메인을 연결하며, SSL/HTTPS도 자동으로 처리된다고 설명합니다.⁴ 기술적으로는 복잡한 일이지만, 사용자 경험은 "수정하고 게시한다"에 가까워지는 셈입니다.

팀에서 API로 관리하는 경우에는 조금 더 세밀하게 볼 수 있습니다. 예를 들어 최신 체크포인트를 게시하고, 게시 상태를 확인하고, 버전 이력을 조회하고, 제목이나 공개 범위 같은 메타데이터를 바꿀 수 있습니다.³ 일반 사용자는 이 API를 직접 쓰지 않아도 되지만, "Manus가 만든 사이트에는 버전과 게시 상태라는 개념이 있다"는 점은 알아두면 좋습니다. 수정 전후를 비교하고, 어떤 상태가 실제로 공개되어 있는지 확인하는 습관이 생기기 때문입니다.

기술 스택을 지정할까, Manus에게 맡길까

웹사이트와 앱을 만들 때 자주 나오는 질문이 있습니다. "React로 만들어 달라고 해야 하나요? Node.js를 지정해야 하나요? 그냥 알아서 해달라고 해도 되나요?"

정답은 목적에 따라 다릅니다. 비개발자이거나 빠른 검증이 목표라면 Manus에게 기술 스택 선택을 맡기는 편이 좋습니다. 반대로 이미 회사에서 사용하는 스택이 있거나, 나중에 개발팀이 이어받아야 한다면 처음부터 지정하는 편이 안전합니다.

기술을 잘 모른다면 이렇게 요청하면 됩니다.

저는 개발자가 아닙니다. 이 프로젝트의 목표에 맞는 기술 스택을 Manus가 선택해 주세요. 단, 선택 이유를 쉽게 설명하고, 나중에 개발자가 이어받을 수 있도록 파일 구조와 실행 방법을 정리해 주세요. 가능하면 유지보수가 쉬운 구조를 우선해 주세요.

개발팀이 있는 조직이라면 이렇게 말하는 것이 좋습니다.

우리 팀은 React와 Node.js를 사용합니다. 프론트엔드는 React 기반으로, 스타일은 Tailwind CSS 느낌의 유틸리티 클래스를 사용해 주세요. 백엔드가 필요한 경우 Node.js API 구조로 설계하고, 데이터 모델과 API 엔드포인트를 별도 문서로 정리해 주세요. 실제 배포 전 환경변수로 분리해야 할 값도 목록으로 알려주세요.

Python 기반 데이터 앱이 필요하다면 이렇게 요청할 수 있습니다.

CSV와 Excel 파일을 분석하는 내부 대시보드가 필요합니다. Python으로 데이터 처리 로직을 구성하고, 웹 화면에서는 업로드, 필터, 차트, 다운로드 기능을 제공해 주세요. 샘플 데이터로 먼저 작동하게 만들고, 데이터 처리 함수는 나중에 교체하기 쉽게 분리해 주세요.

핵심은 "스택 이름"보다 "나중에 누가 어떻게 유지할 것인가"입니다. 한 번 쓰고 버릴 캠페인 페이지라면 빠른 제작이 우선입니다. 고객 데이터와 결제가 들어가는 서비스라면 구조, 보안, 로그, 테스트, 배포 전략이 중요합니다.

정적 랜딩페이지와 풀스택 웹앱은 요청 방식이 다르다

많은 사용자가 랜딩페이지와 웹앱을 같은 방식으로 요청합니다. 하지만 둘은 완전히 다릅니다.

정적 랜딩페이지는 주로 정보를 보여주고 행동을 유도합니다. 구조는 비교적 단순합니다. hero, 기능, 가격, 후기, FAQ, 문의 폼 정도면 충분합니다. 데이터베이스가 없어도 되고, 결제나 로그인도 필요 없을 수 있습니다. 빠르게 만들고 빠르게 실험하는 데 적합합니다.

풀스택 웹앱은 사용자가 로그인하고, 데이터를 만들고, 수정하고, 저장하고, 결제하고, 관리자 화면에서 관리하는 서비스입니다. 여기에는 프론트엔드뿐 아니라 백엔드, 데이터베이스, 인증, 권한, 오류 처리, 보안, 배포 전략이 들어갑니다.

정적 랜딩페이지 요청은 이렇게 간단하게 시작할 수 있습니다.

신제품 대기자 모집용 정적 랜딩페이지를 만들어주세요. 별도 로그인이나 데이터베이스는 필요 없습니다. 이메일 입력 폼은 우선 화면 동작만 구현하고, 제출 시 '등록되었습니다' 메시지를 보여주세요. 페이지는 빠르게 로딩되어야 하고, 모바일 최적화를 우선해 주세요.

반면 풀스택 웹앱은 이렇게 요청해야 합니다.

소규모 학원용 수강생 관리 웹앱 MVP를 만들어주세요.
사용자 역할은 관리자와 강사입니다. 관리자는 수강생을 등록하고, 반을 만들고, 출석과 결제 상태를 확인할 수 있어야 합니다. 강사는 본인 반의 출석만 체크할 수 있어야 합니다.

필요한 화면은 로그인, 대시보드, 수강생 목록, 수강생 상세, 반 관리, 출석 체크, 결제 상태 관리, 관리자 설정입니다.

먼저 샘플 데이터로 작동하는 초안을 만들고, 데이터 모델, API 목록, 권한 규칙, 추후 실제 인증과 데이터베이스 연결 시 필요한 작업을 문서로 정리해 주세요. 보안상 실제 개인정보는 샘플 데이터만 사용해 주세요.

이 프롬프트에는 "역할", "화면", "데이터", "권한", "보안", "단계적 구현"이 들어 있습니다. 풀스택 웹앱은 이 정도로 말해야 Manus가 단순 화면 목업이 아니라 실제 작동 구조를 고민합니다.

결제가 필요한 경우에도 신중해야 합니다. Manus 랜딩페이지 기능 소개에는 Stripe 통합을 통한 체크아웃 흐름과 구독 제공이 언급되어 있습니다.² 하지만 실제 고객에게 돈을 받는 순간부터는 테스트 결제, 환불 정책, 세금계산서, 개인정보 처리방침, 이용약관, 결제 실패 처리까지 확인해야 합니다. 그러므로 첫 요청은 "실결제"보다 "테스트 모드 기반 결제 흐름 초안"으로 시작하는 편이 안전합니다.

Stripe 테스트 모드를 가정한 결제 흐름 초안을 만들어주세요. 실제 결제 키나 비밀값은 코드에 넣지 말고 환경변수로 분리해야 할 항목을 알려주세요. 결제 성공, 결제 실패, 구독 취소, 영수증 안내 화면까지 포함해 주세요.

이렇게 요청하면 Manus가 만든 결과물을 비즈니스적으로 검토하기 쉬워집니다.

Google Stitch, Figma, Design View를 개발 작업에 연결하기

디자인이 중요한 프로젝트라면 처음부터 Manus에게 전부 맡길 수도 있지만, 별도의 디자인 도구로 UI/UX 초안을 만든 뒤 Manus에 구현을 맡기는 방식도 좋습니다. 예를 들어 Google Stitch 같은 AI 디자인 도구로 화면 컨셉을 만들고, 그 결과를 Manus의 개발 작업에 연결하는 식입니다. 실제로 Google Stitch와 Manus를 함께 사용해 디자인과 개발을 분리하고 빠르게 랜딩페이지를 만든 사례도 소개된 바 있습니다.⁶

공식 랜딩페이지 빌더 자료에서도 Figma 프레임 링크를 가져와 기능적인 코드로 전환하는 흐름이 언급됩니다.² 이 접근은 특히 팀 작업에서 유용합니다. 디자이너는 Figma나 Stitch에서 시각적 방향을 잡고, Manus는 그 디자인을 바탕으로 실행 가능한 페이지를 구성합니다.

디자인 초안을 Manus에 넘길 때는 단순히 "이 이미지처럼 만들어줘"라고 하지 말고, 구현 기준을 함께 적어야 합니다.

첨부한 UI 초안을 기준으로 랜딩페이지를 구현해 주세요.
시각적 우선순위는 hero 영역의 타이포그래피, CTA 버튼, 카드형 기능 섹션입니다.
픽셀 단위로 완전히 같을 필요는 없지만, 전체 분위기와 여백, 색상 대비, 섹션 순서는 유지해 주세요.
모바일에서는 hero 이미지가 너무 커지지 않게 하고, CTA와 이메일 입력 폼이 첫 화면 안에 보이도록 조정해 주세요.
구현 후 디자인 초안과 달라진 부분을 목록으로 설명해 주세요.

이 요청의 장점은 "동일하게"와 "알아서" 사이의 균형을 잡는다는 점입니다. AI에게 픽셀 완전 복제를 맡기면 작은 차이에 집착하다가 전체 사용성이 나빠질 수 있습니다. 반대로 너무 자유롭게 맡기면 브랜드 방향이 흐려질 수 있습니다. 그래서 유지해야 할 요소와 조정 가능한 요소를 나누어 말하는 것이 좋습니다.

Design View에서 만든 이미지나 시각 자료를 웹사이트에 활용할 때도 마찬가지입니다. 지난 장에서 만든 배너, 제품 목업, 팀 피드백용 주석 이미지는 랜딩페이지의 hero 이미지나 기능 설명 이미지로 이어질 수 있습니다. 이미지 작업과 웹 개발 작업을 따로 보지 말고, 하나의 캠페인 산출물로 연결해 보세요.

모바일 앱 아이디어를 자연어로 개발하기

Manus 1.6에서는 모바일 애플리케이션 개발도 주요 기능으로 소개되었습니다. 원하는 앱을 설명하면 Manus가 엔드 투 엔드 개발 프로세스를 처리할 수 있다는 설명입니다.⁵ 여기서 말하는 핵심은 "앱 아이디어를 화면 목록으로만 끝내지 말라"는 것입니다. 모바일 앱은 화면보다 흐름이 중요합니다.

좋은 모바일 앱 요청에는 보통 다음이 들어갑니다.

• 앱의 목적과 핵심 사용자

• 첫 실행부터 목표 달성까지의 사용자 흐름

• 필요한 화면 목록과 각 화면의 역할

• 저장해야 할 데이터 모델

• 외부 API 또는 나중에 연결할 서비스

• 오류 상황과 빈 상태 화면

• 테스트 방법과 배포 준비 체크리스트

예를 들어 동네 청소 서비스 예약 앱을 만든다고 해봅시다. 단순히 "청소 예약 앱 만들어줘"라고 하면 너무 넓습니다. 아래처럼 요청하면 훨씬 좋은 초안이 나옵니다.

지역 청소 서비스 업체를 위한 모바일 앱 MVP를 만들어주세요.
사용자는 청소를 예약하려는 고객입니다. 업체 관리자는 이번 버전에서는 별도 앱이 아니라 관리자용 웹 화면으로만 가정합니다.

고객 앱의 주요 흐름은 온보딩 → 서비스 선택 → 주소 입력 → 날짜와 시간 선택 → 추가 요청 입력 → 가격 확인 → 예약 완료입니다.

필요한 화면은 시작 화면, 서비스 선택, 주소 입력, 일정 선택, 예약 요약, 예약 완료, 내 예약 목록, 예약 상세, 고객센터입니다.

데이터 모델은 사용자, 예약, 서비스 종류, 주소, 결제 상태, 요청 메모로 나눠 설계해 주세요. 실제 결제는 아직 붙이지 말고 결제 예정 상태만 표시해 주세요.

UI는 신뢰감 있고 깔끔한 생활 서비스 느낌으로 만들어주세요. 큰 버튼, 쉬운 문장, 모바일 한 손 조작을 고려해 주세요.

먼저 작동 가능한 프로토타입을 만들고, 이후 실제 배포를 위해 필요한 API, 인증, 결제, 알림, 개인정보 처리 체크리스트를 정리해 주세요.

이런 프롬프트는 Manus에게 앱의 "이야기"를 줍니다. 사용자가 어떤 순서로 움직이는지 알려주기 때문에 화면 간 연결이 자연스러워집니다. 웹에서 소개된 실전 사례들에서도 Manus 1.6 Max가 비개발자를 위해 예약 흐름이 있는 모바일 앱, 게임, 웹사이트, 리서치 결과물을 빠르게 만들 수 있다는 점이 반복적으로 언급됩니다.⁵

고급 사용자는 여기에 API 설계까지 요청할 수 있습니다.

위 모바일 앱에 필요한 API 명세를 함께 작성해 주세요. 각 API는 목적, 요청 파라미터, 응답 예시, 오류 코드, 권한 필요 여부를 포함해 주세요. 실제 구현은 샘플 데이터 기반으로 시작하되, 나중에 서버와 연결하기 쉽도록 서비스 레이어를 분리해 주세요.

오류 수정도 자연어로 이어갈 수 있습니다.

예약 완료 버튼을 누르면 화면이 멈춥니다. 관련 로그를 확인하고 원인을 추정한 뒤, 최소한의 코드 변경으로 수정해 주세요. 수정한 파일과 변경 이유를 설명하고, 같은 문제가 다시 생기지 않도록 간단한 테스트 방법도 알려주세요.

이런 디버깅 지시는 "다시 만들어줘"보다 훨씬 안전합니다. 전체를 갈아엎지 않고 문제 범위를 좁히게 만들기 때문입니다.

웹앱을 만들 때 꼭 넣어야 할 검수 요청

Manus가 만든 웹사이트나 앱은 빠르게 볼 수 있다는 장점이 있지만, 빠르게 만들어졌다고 바로 공개해도 된다는 뜻은 아닙니다. 배포 전에는 반드시 검수 요청을 넣어야 합니다.

아래 프롬프트는 거의 모든 웹사이트와 앱에 붙여 쓸 수 있습니다.

배포 전 검수를 해주세요.
다음 관점에서 문제를 찾아 표로 정리해 주세요.

1. 모바일 반응형 문제

2. CTA와 전환 흐름 문제

3. 폼 입력과 오류 메시지 문제

4. SEO title, description, heading 구조 문제

5. 접근성 문제

6. 성능과 로딩 속도 문제

7. 개인정보나 보안상 주의할 점

8. 실제 배포 전에 사람이 확인해야 할 항목

각 문제는 심각도, 발견 위치, 수정 제안, 바로 수정 가능 여부로 나눠 주세요. 바로 수정 가능한 항목은 먼저 고쳐 주세요.

특히 폼과 데이터가 있는 앱이라면 추가 검수가 필요합니다.

이 앱에서 사용자가 입력하는 데이터가 어디로 이동하고 어디에 저장되는지 설명해 주세요. 개인정보로 볼 수 있는 항목을 표시하고, 실제 서비스 전 개인정보 처리방침과 동의 문구가 필요한 지점을 알려주세요. 코드 안에 노출되면 안 되는 키나 비밀값이 있는지도 확인해 주세요.

관리자 화면이나 결제 기능이 있다면 권한 검수도 해야 합니다.

관리자 권한이 필요한 화면과 일반 사용자가 접근 가능한 화면을 구분해 주세요. 현재 구현에서 권한 확인이 빠진 부분이 있는지 점검하고, 실제 운영 전에 보강해야 할 인증과 접근 제어 항목을 정리해 주세요.

검수 요청은 크레딧이 아깝지 않은 작업입니다. 오히려 이 단계를 생략하면 더 큰 비용이 생깁니다. 잘못된 가격표가 공개되거나, 작동하지 않는 폼으로 광고비를 태우거나, 민감한 데이터가 노출되는 상황을 막아주기 때문입니다.

실전 흐름: 90분 안에 SaaS 랜딩페이지 실험하기

이제 하나의 실전 흐름으로 묶어보겠습니다. 목표는 90분 안에 SaaS 아이디어의 랜딩페이지를 만들고, 팀원에게 공유할 수 있는 상태까지 가는 것입니다.

첫 10분은 브리프 작성에 씁니다. 제품 이름, 타깃, 문제, 해결책, 전환 목표, 가격 가설을 정리합니다. 이 단계에서는 Chat Mode를 써도 좋습니다.

아래 제품 아이디어를 바탕으로 랜딩페이지 제작용 브리프를 정리해 주세요. 타깃 고객, 핵심 문제, 가치 제안, 섹션 구성, CTA, 리드 폼 항목, 브랜드 톤을 표로 만들어 주세요. 아직 모호한 부분은 질문으로 따로 정리해 주세요.

다음 30분은 Agent Mode에서 첫 페이지를 만듭니다. 이때는 앞에서 만든 브리프를 붙여넣고, 실행 가능한 웹사이트 형태로 만들어 달라고 합니다. Manus가 계획을 제시하면 빠진 부분을 확인한 뒤 빌드를 진행합니다.

그다음 20분은 미리보기를 보며 전환 흐름을 점검합니다. 첫 화면에서 제품이 이해되는지, CTA가 눈에 띄는지, 가격표가 설득력 있는지, 모바일에서 폼이 잘 보이는지 확인합니다. 마음에 들지 않는 부분은 한 번에 모두 고치려 하지 말고, 문구 → 구조 → 디자인 → 기능 순서로 나누어 수정합니다.

이후 20분은 변형 버전을 만듭니다. 예를 들어 같은 제품이라도 타깃을 창업자용, 마케팅 팀장용, 운영팀장용으로 나눠 hero 문구를 바꿀 수 있습니다.

현재 랜딩페이지를 유지하되 hero 문구와 문제 제기 섹션만 세 가지 버전으로 만들어 주세요.
A안은 스타트업 대표용, B안은 마케팅 팀장용, C안은 운영팀장용입니다.
각 버전의 핵심 메시지, CTA 문구, 예상 장단점을 비교해 주세요.

마지막 10분은 공유 준비입니다. 배포하거나 팀 검토 링크를 만들고, 검수표를 함께 요청합니다. 배포가 가능하다면 도메인 연결은 나중에 하더라도 우선 공유 가능한 URL로 팀 피드백을 받을 수 있습니다. Manus의 웹사이트 관리 구조에서는 게시된 사이트의 URL과 버전 상태를 확인하는 개념이 있으므로, 어떤 버전이 공유되었는지 기록해 두는 습관이 좋습니다.³

이 90분 실험의 목적은 완벽한 사이트가 아닙니다. 광고를 태울 수 있을 만큼 명확한 메시지인지, 고객에게 보여줄 수 있을 만큼 그럴듯한 형태인지, 팀이 같은 그림을 보고 토론할 수 있는지를 확인하는 것입니다.

프로덕션으로 가기 전, Manus 결과물을 현실적으로 보기

여기서 균형을 잡아야 합니다. Manus는 놀라울 만큼 빠르게 웹사이트와 앱 초안을 만들 수 있습니다. 공식 문서와 제품 소개에서도 빌드, 데이터베이스, 배포, 분석, 결제 같은 넓은 범위를 다룹니다.¹ 하지만 "빠른 프로토타입"과 "실제 고객이 쓰는 프로덕션 서비스"는 다릅니다.

특히 사용자 계정, 결제, 개인정보, 회사 내부 데이터, 고객 데이터가 들어가는 앱은 반드시 사람이 검토해야 합니다. 외부의 Manus 앱 프로덕션 이전 가이드에서도 AI가 만든 앱은 UI와 기본 데이터 모델은 재사용할 수 있어도, 실제 인증, 데이터 접근 제어, 환경변수 관리, 오류 처리, CI/CD와 운영 인프라는 별도로 점검하거나 재구성해야 한다고 지적합니다.⁷

실제 공개 전에는 최소한 다음 항목을 확인해야 합니다.

• 인증: 로그인, 세션, 비밀번호, OAuth, 역할별 권한이 안전하게 설계되었는가

• 데이터베이스: 사용자별 데이터 분리, 접근 제어, 백업, 삭제 정책이 있는가

• 비밀값: API 키, 결제 키, 데이터베이스 주소가 코드에 노출되지 않았는가

• 결제: 테스트 모드와 실결제가 분리되어 있고, 실패·환불·구독 취소 흐름이 있는가

• 개인정보: 수집 항목, 동의 문구, 보관 기간, 처리방침이 준비되었는가

• 오류 처리: 네트워크 실패, 잘못된 입력, 서버 오류를 사용자에게 안전하게 안내하는가

• 모니터링: 장애, 로그, 성능, 보안 이벤트를 확인할 방법이 있는가

• 배포: 도메인, SSL, 버전 관리, 롤백 계획이 준비되었는가

이 체크리스트는 Manus를 못 믿으라는 뜻이 아닙니다. 오히려 Manus를 제대로 쓰기 위한 안전장치입니다. Manus로 초안을 만들고, 사용자 반응을 확인하고, 내부 검증을 거친 뒤, 중요한 서비스는 개발자나 보안 담당자와 함께 프로덕션 기준으로 다듬는 것이 가장 현실적인 전략입니다.

Manus에게 웹사이트를 맡길 때의 최종 공식

이 장에서 다룬 내용을 하나의 공식으로 정리하면 이렇습니다.

목표 + 타깃 + 전환 행동 + 필수 섹션 + 디자인 톤 + 기술 범위 + 검수 기준

이 일곱 가지가 들어가면 Manus는 훨씬 안정적으로 움직입니다. 반대로 "멋진 웹사이트 만들어줘"라고만 하면 Manus는 일반적인 결과를 냅니다. 일반적인 결과는 나쁘지 않지만, 비즈니스를 움직이기에는 약합니다.

웹사이트와 앱을 Manus로 만들 때의 진짜 장점은 코드를 몰라도 된다는 데서 끝나지 않습니다. 더 큰 장점은 실험 속도입니다. 마케팅 팀은 캠페인 페이지를 하루 만에 만들 수 있고, 1인 창업자는 제품 아이디어를 고객에게 보여줄 수 있으며, 디자이너는 정적인 시안을 작동하는 화면으로 바꿀 수 있고, 기획자는 내부 도구의 초안을 직접 만들어 팀과 논의할 수 있습니다.

다만 속도가 빨라질수록 판단의 책임은 더 중요해집니다. 어떤 메시지를 내보낼지, 어떤 데이터를 받을지, 어떤 기능을 실제 운영에 연결할지, 어떤 버전을 공개할지는 여전히 사람의 몫입니다. Manus는 손을 빠르게 만들어 주지만, 방향을 정하는 나침반은 사용자가 쥐고 있어야 합니다.

이제부터 웹사이트 제작을 "개발자에게 부탁해야 하는 일"로만 보지 않아도 됩니다. 작은 캠페인, 포트폴리오, 이벤트 사이트, 내부 대시보드, 모바일 앱 초안은 목표만 분명하면 Manus와 함께 충분히 시작할 수 있습니다. 먼저 작게 만들고, 미리보고, 고치고, 공유하고, 검증하세요. 그다음에야 비로소 진짜 제품으로 키울지 결정하면 됩니다.

참고

¹Manus Website Builder Getting Started

²Manus Landing Page Builder

³Manus API Website Documentation

⁴Manus Website Builder Publishing

⁵Manus 1.6 Max Release

⁶Your $0 Design Agency: Build a Stunning Landing Page Using Google Stitch and Manus

⁷Built with Manus? Here's How to Ship a Production-Ready App