AI 앱 빌더용 프롬프트 쓰는 법 (전후 비교 예시 포함)

AI 앱 빌더에 쓰는 좋은 프롬프트는 코드가 아니라 제품을 설명합니다. 누가 쓰는지, 단계별로 무엇을 하는지, 어떤 데이터를 보관하는지, 누가 무엇을 볼 수 있는지를 적습니다. 첫 버전이 만들어진 뒤에는 메시지마다 구체적인 변경 하나를 요청하고, 무엇을 그대로 유지해야 하는지 말하고, 문제는 “X를 했는데, Y를 기대했고, Z가 나왔다”처럼 설명하세요. 이 세 가지 습관만 지켜도 실망스러운 결과의 대부분을 고칠 수 있습니다.

이 가이드의 나머지 부분에서는 이 패턴들을 전후 비교 예시와 함께 자세히 보여 줍니다. 여러분의 상황에 맞게 고쳐 쓰세요.

AI 앱 빌더에 프롬프트를 쓰는 것이 AI와 대화하는 것과 다른 이유

챗 어시스턴트에게 질문하면 모호한 프롬프트는 모호한 답으로 끝나고 여러분은 그냥 넘어갑니다. 하지만 AI 앱 빌더에 프롬프트를 쓰면 결과물은 실행되는 프로그램입니다. 설명에서 빈 부분은 모두 추측으로 채워지고, 그 추측이 코드, 데이터베이스 테이블, 화면이 되어 여러분이 그대로 쓰거나 되돌려야 합니다.

그래서 프롬프트의 목적은 똑똑하게 들리는 것이 아닙니다. 중요한 결정을 우연에 맡기는 일을 줄이는 것입니다. 그러려면 기술 용어가 필요하지 않습니다. 여러분만 아는 것, 즉 사용자, 작업 흐름, 규칙에 대해 구체적으로 말하면 됩니다.

첫 프롬프트에 넣을 내용

아무것도 쓰기 전에 다음 질문에 답하세요. 각 질문은 AI가 추측할 수밖에 없는 빈틈 하나를 메웁니다.

마지막 행은 과소평가되기 쉽습니다. 원하지 않는 것을 말하면, 여러분이 요청한 적 없는 블로그, 가격 페이지, 뉴스레터 신청이 추가되는 것을 막을 수 있습니다.

전후 비교: 첫 프롬프트

전:

우리 헬스장 앱 하나 만들어 줘.

빌더는 모든 것을 추측해야 합니다. 회원인가 직원인가? 수업인가 개인 트레이닝인가? 결제는? 결국 헬스장 웹사이트처럼 보이지만 필요한 것은 하나도 하지 않는 결과물이 나옵니다.

후:

작은 요가 스튜디오를 위한 수업 예약 앱을 만들어 주세요. 회원은 이번 주 수업(이름, 강사, 시간, 남은 자리)을 보고, 자리를 예약하고, 두 시간 전까지 취소할 수 있습니다. 회원은 이메일과 비밀번호로 가입합니다. 스튜디오 사장님은 로그인해서 수업을 추가하고, 예약자를 보고, 출석을 표시합니다. 수업, 회원, 예약은 데이터베이스에 저장해 주세요. 차분하고 밝은 디자인이며 휴대폰에서 잘 동작해야 합니다. 아직 결제는 없습니다.

두 번째 버전도 여전히 짧습니다. 위 표의 질문에 답했을 뿐입니다.

구현이 아니라 동작을 설명하기

어떻게 만들지 설명하기보다 무엇이 일어나야 하는지 설명할 때 더 좋은 결과를 얻는 경우가 많습니다.

전:

예약을 가져오는 useEffect와 수정용 모달 컴포넌트를 추가해 줘.

후:

사장님이 예약을 누르면, 시간을 바꾸거나 취소할 수 있는 패널이 열리게 해 주세요. 변경 사항은 목록에 바로 반영되어야 합니다.

첫 프롬프트는 AI를 특정 기법에 묶어 버리는데, 그것이 앱의 구조에 맞지 않을 수 있습니다. 두 번째 프롬프트는 원하는 결과를 알려 주고, AI가 이미 작성한 코드에 맞는 방법을 고르게 합니다. 여러분이 개발자이고 분명한 선호가 있다면 그것을 말해도 되지만, 결과와 함께 말하세요.

규칙을 구체적으로 말하기

AI로 만든 앱이 가장 자주 틀리는 곳은 업무 규칙입니다. 여러분에게는 너무 당연해서 AI에게는 보이지 않기 때문입니다. 명확하게 적으세요.

• 한도: “회원은 미래 예약을 최대 세 개까지 가질 수 있다.”
• 시간: “수업 시작 두 시간 전에 취소가 마감된다.”
• 예외 상황: “수업이 꽉 찼다면 예약 버튼 대신 대기자 버튼을 보여 준다.”
• 권한: “강사는 자기 수업의 출석만 볼 수 있고, 다른 강사의 수업은 볼 수 없다.”

각각은 한 문장입니다. 이 중 어느 하나라도 빠지면, 앱은 그 규칙을 적용하지 않거나 자기 나름의 규칙을 만들어 버립니다.

첫 버전 이후: 메시지마다 변경 하나

미리보기에서 무언가가 돌아가기 시작하면, 제품 전체를 설명하는 대신 작고 확인할 수 있는 변경을 요청하세요.

전:

디자인이 어긋나 있고, 예약이 제대로 안 되고, 캘린더 보기와 이메일도 원해요.

후 (네 개의 별도 메시지로):

1. 수업의 마지막 자리를 예약하면, 그 수업이 여전히 “1자리 남음”으로 보입니다. “마감”으로 보여 주고 예약 버튼은 숨겨 주세요.
2. 일정 페이지에 주간 보기 캘린더를 추가해 주세요. 하루에 한 열씩. 현재의 목록 보기는 옵션으로 남겨 주세요.
3. 휴대폰에서 수업 카드를 더 조밀하게 해 주세요. 여백을 줄이고, 강사 이름을 시간과 같은 줄에 두세요.
4. 회원이 예약하면 확인 이메일을 보내 주세요.

이 방식이 잘 되는 이유:

• 각 변경이 AI가 한 번에 제대로 해낼 만큼 작습니다.
• 다음으로 넘어가기 전에 각각을 테스트할 수 있습니다.
• 하나가 잘못되어도 다른 것을 잃지 않고 그 단계만 되돌릴 수 있습니다.

무엇을 유지할지 말하기

이미 잘 동작하는 것을 바꿔 달라고 할 때는, 무엇이 바뀌면 안 되는지 AI에게 알려 주세요. 이것이 회귀(예전에는 잘 되던 것이 수정 후에 깨지는 것)를 막는 가장 쉬운 방법입니다.

홈 페이지 히어로 영역을 다시 디자인해 주세요. 제목을 더 크게 하고, 오른쪽에 사진을 넣어 주세요. 내비게이션, 색상, 그리고 히어로 아래의 모든 것은 지금 그대로 유지해 주세요.

데이터에도 같은 원칙이 적용됩니다. “회원에 전화번호 필드를 추가해 주세요. 기존 필드는 삭제하거나 이름을 바꾸지 마세요.”

스크린샷과 정확한 문구 사용하기

“위에 있는 것”처럼 모호한 표현은 헷갈립니다. 대부분의 AI 앱 빌더는 이미지를 받아들이고, 짧은 메모가 붙은 스크린샷이 단락으로 된 설명보다 빠릅니다.

• 스크린샷을 첨부하고 “빨간 원으로 표시된 버튼이 휴대폰에서 메뉴와 겹칩니다”라고 말하세요.
• 오류 메시지는 바꿔 말하지 말고 정확한 문구를 그대로 붙여넣으세요.
• 화면에 보이는 라벨은 정확히 인용하세요. “설정 페이지의 변경 사항 저장 버튼”처럼요.

버그라면 특히 다음 형식을 쓰세요:

예약 페이지에서 내일 예약의 취소를 눌렀습니다. 목록에서 사라질 것으로 기대했습니다. 하지만 아무 일도 없었고, 새로 고침 후에도 예약이 그대로 있습니다. 고치고 취소가 동작하는지 확인해 주세요.

AI로 만든 앱을 디버깅하는 방법은 AI로 만든 앱 디버깅하는 법 가이드에서 더 자세히 다룹니다.

큰 변경은 먼저 계획하기

앱의 많은 부분에 영향을 주는 변경, 예를 들어 사용자 계정이 없던 앱에 계정 추가하기, 결제 추가하기, 데이터 구조 바꾸기 같은 것은 코드를 바꾸기 전에 계획을 요청하세요.

아무것도 바꾸기 전에 팀 계정을 어떻게 추가할지 설명해 주세요. 어떤 새 테이블이 필요하고, 어떤 페이지가 바뀌며, 기존 사용자에게는 무슨 일이 일어나는지 알려 주세요. 아직 코드는 수정하지 마세요.

계획을 읽으세요. 무언가를 잘못 이해했다면, 완성된 기능을 고치는 것보다 문단 하나를 고치는 편이 훨씬 저렴합니다. 많은 빌더에는 이를 위한 전용 모드가 있고, Mythex에서는 Build, Ask와 함께 Plan 모드가 그 역할을 합니다.

피해야 할 것

API 키에 대해: 결제나 이메일 서비스가 필요하다면, 키는 프롬프트가 아니라 프로젝트의 비밀 값에 넣으세요. 이 개념이 낯설다면 환경 변수와 비밀 값이란 무엇인가를 참고하세요.

재사용할 수 있는 프롬프트 템플릿

대괄호 부분을 바꿔서 사용하세요.

새 앱:

[누구]를 위한 [앱 종류]를 만들어 주세요. 그들은 [주요 흐름을 단계별로]. [두 번째 유형의 사용자]는 로그인해서 [하는 일]을 합니다. [데이터]를 데이터베이스에 저장해 주세요. [디자인 느낌]. [나중에 할 것]은 빼 주세요.

새 기능:

[페이지]에 [기능]을 추가해 주세요. [사용자]가 [행동]을 하면 [일어나야 할 일]이 일어나야 합니다. [누가] 만 [행동]할 수 있어요. [기존 요소]는 그대로 유지해 주세요.

디자인 변경:

[페이지]에서 [특정 요소]를 [구체적인 변경]으로 바꿔 주세요. [유지할 것]은 그대로 두세요. 휴대폰 너비 화면에서 제대로 보이는지 확인해 주세요.

버그:

[페이지]에서 [단계]를 했습니다. [기대한 결과]를 기대했습니다. 하지만 [실제 결과와 정확한 오류 문구]가 나왔습니다. 고치고 흐름이 동작하는지 확인해 주세요.

변경 없이 질문만:

코드는 바꾸지 마세요. [앱의 일부분]이 어떻게 동작하는지, 그리고 [데이터]가 어디에 저장되는지 설명해 주세요.

더 긴 명세서 쓰기

규모가 큰 프로젝트라면, 먼저 한 페이지짜리 브리프를 쓰고 첫 프롬프트로 붙여넣는 것이 도움이 됩니다. 사용자, 핵심 흐름, 데이터, 규칙, 그리고 범위 밖 항목을 담으세요. AI의 도움을 받아 초안을 만들 수도 있습니다. 방법은 AI로 제품 요구사항 문서 쓰기에서 다룹니다. 다만 첫 빌드 요청은 핵심 흐름으로만 제한하고, 나머지는 단계별로 추가하세요.

Mythex에서 프롬프트 쓰기

위의 모든 내용은 Mythex에서도 동작합니다. 도움이 되는 몇 가지 세부 사항:

• Build, Plan, Ask 모드. 크거나 위험한 변경에는 Plan을, 수정 없이 설명만 듣고 싶을 때는 Ask를 쓰세요.
• 체크포인트. 변경이 성공할 때마다 Mythex가 체크포인트를 저장하고, 응답의 이 시점으로 되돌리기를 누르면 프로젝트가 되돌아갑니다. 이전 메시지를 수정해서 다시 보내면, 그 지점부터 다른 프롬프트를 시도할 수도 있습니다.
• 비밀 값 카드. 에이전트에게 API 키가 필요하면 채팅의 카드를 통해 물어보고, 값은 여러분의 메시지에 적히지 않고 프로젝트 비밀 값으로 저장됩니다.
• 이미지. 스크린샷이나 목업을 첨부하면 에이전트가 그것을 보고 작업합니다.

문서에는 효과적인 프롬프트에 대한 짧은 페이지와, 다시 만들지 않고 반복하기에 대한 페이지가 있습니다. 처음부터 시작한다면 AI로 앱 만드는 법이 전체 프로젝트를 단계별로 안내하고, AI로 보기 좋은 앱 디자인하는 법에서는 화면을 다듬는 프롬프트를 다룹니다.

자주 묻는 질문