AI 앱 빌더 프롬프트 잘 쓰는 법 (Before/After 예시 포함)

같은 AI 앱 빌더를 한 시간씩 쓰는 두 사람을 지켜보세요. 한 명은 작동하는 앱을 손에 쥐고, 다른 한 명은 엉망진창인 결과와 "AI 코딩은 과대평가"라는 의견을 갖게 됩니다. 도구는 같았습니다. 프롬프트가 달랐습니다.

앱 빌더에 프롬프트를 쓰는 것은 챗봇에 프롬프트를 쓰는 것과 다른 기술입니다. 질문을 던지는 게 아니라, 여러분이 말한 것과 말하지 않은 것을 바탕으로 수십 개의 결정을 내릴 에이전트에게 작업 지시서를 주는 일입니다. 실제로 통하는 방법을 Before/After 예시와 함께 정리했습니다.

첫 프롬프트: 결정은 앞에, 구현은 생략

시작 프롬프트가 프로젝트의 토대를 결정합니다. 여러분이 비워 둔 모든 빈칸을 에이전트가 추측으로 채우는데, 좋은 에이전트는 합리적으로 추측하긴 하지만 모든 추측은 여러분의 의도와 맞을지 모를 동전 던지기입니다.

Before:

피트니스 앱 만들어 줘.

After:

웨이트 트레이닝하는 사람용 운동 기록 앱을 만들어 줘. 데이터: 운동 세션에는 날짜가 있고, 각 세션에는 운동 이름, 세트, 횟수, 무게가 있는 기록들이 있어. 화면: (1) 빠른 입력이 되는 오늘의 기록, (2) 주 단위로 묶인 히스토리, (3) 운동별 성장 차트. 사용자는 한 명, 로그인 불필요. 다크하고 미니멀한 디자인.

"After" 버전은 타깃, 데이터 모델, 화면, 인증 범위, 시각적 방향을 결정합니다. 나중에 바꾸려면 비싼 다섯 가지 결정이죠. 포함하지 않은 것도 눈여겨보세요. 기술 스택도, 데이터베이스 선택도, 컴포넌트 라이브러리도 없습니다. 좋은 플랫폼은 그런 결정을 프롬프트보다 잘 내리며, 어설프게 아는 기술 용어로 브리프를 어지럽히면 오히려 해가 됩니다 (플랫폼이 Postgres 중심으로 만들어져 있는데 "MongoDB 써 줘"라고 하면 마찰만 생깁니다).

일관되게 통하는 구조:

1. 무엇인지 한 문장으로, 타깃과 함께.
2. 데이터를 평범한 명사와 필드로.
3. 화면을 번호를 붙여서.
4. 명시적 제외 사항. "로그인 없음", "결제 없음". 제외 사항은 에이전트가 친절하게 지어낼 뻔한 스코프를 미리 차단합니다.

반복 프롬프트: 변경 하나, 위치 지정

첫 빌드 이후 프롬프트의 성격이 바뀝니다. 설계에서 수술로. 두 가지 규칙이 대부분의 일을 합니다.

메시지당 변경 하나. 묶음 요청은 한 덩어리로 실패합니다. 다섯 개 중 하나가 잘못 나오면, 나머지 네 개를 피해 가며 다시 프롬프트를 써야 합니다.

모든 변경에 위치를 지정하세요.

Before:

날짜가 이상해 보여.

After:

히스토리 페이지에서 주 헤더가 "Week 32"라고 나와. 대신 "8월 4일 – 8월 10일"처럼 날짜 범위를 보여 줘.

화면 이름을 부르고, 잘못된 텍스트를 인용하고, 올바른 텍스트를 설명하세요. 에이전트가 헤매는 대신 정확한 지점을 찾습니다. 잘못된 추측이 줄고, 크레딧도 줄어듭니다.

구현이 아니라 결과를 설명하기

개발자처럼 말하고 싶은 유혹이 들 겁니다. 실제 개발자가 아니라면 참으세요.

Before:

마운트 시 다시 fetch하는 useEffect를 추가하고 리스트 렌더링을 메모이제이션해 줘.

After:

지출을 추가하고 대시보드로 돌아오면, 새로고침하기 전까지 합계가 이전 숫자로 나와. 최신 값이 보여야 해.

첫 번째 버전은 에이전트를 여러분의 진단에 묶어 버리는데, 그 진단이 틀렸을 수 있습니다. 두 번째는 여러분이 확신하는 것, 즉 실제 결함을 알려 주고 원인은 에이전트가 찾게 합니다. 증상은 사용자의 확신으로 설명하고, 진단은 코드를 읽을 수 있는 쪽에 맡기세요.

레퍼런스를 쓰세요. 형용사를 이깁니다

"모던하고 깔끔하게"는 아무 의미가 없습니다. 2010년 이후 모든 디자인이 그렇게 주장해 왔으니까요. 레퍼런스는 자릿수가 다른 정보량을 전달합니다.

가격 섹션을 Linear의 가격 페이지처럼 만들어 줘. 넉넉한 여백, 얇은 테두리, 포인트 컬러 하나.

더 좋은 건 스크린샷 첨부입니다. 마음에 드는 앱, 손으로 그린 스케치, 지금 설명하려는 그 깨진 레이아웃의 스크린샷. 이미지 첨부를 받는 플랫폼(Massvai가 그렇습니다)은 시각적 모호함을 산문보다 그림에서 훨씬 빠르게 해소합니다. 한 줄 설명이 붙은 버그 스크린샷이야말로 존재하는 프롬프트 형식 중 가장 가치가 높습니다.

잘못 흘러갈 때: 구덩이 파기를 멈추세요

가장 비싼 프롬프트 실수는 나쁜 프롬프트가 아닙니다. 근본적으로 어긋난 방향을 네 번째 연속으로 땜질하려는 시도입니다.

같은 수정을 두 번 시도해서 안 됐다면 전략을 바꾸세요.

• 롤백하세요. 엉망이 되기 전의 체크포인트를 복원하고(Massvai는 모든 생성을 스냅샷으로 남깁니다) 다른 설명으로 다시 접근하세요. 뒤로 가는 건 손해처럼 느껴지지만, 대개 앞으로 가는 가장 빠른 길입니다.
• 시야를 넓히세요. 수정 방법을 다시 설명하는 대신 목표를 설명하세요. "필터 드롭다운에 대한 이전 지시는 잊어 줘. 내가 사용자에게 시키고 싶은 건 이거야: …" 에이전트는 누적된 땜질 지시보다 새로운 목표를 훨씬 잘 다룹니다.

치트 시트

특별한 비법은 하나도 없습니다. 사람 외주 개발자에게라도 갖춰야 할 그 명료함일 뿐입니다. 다만 이 외주 개발자는 꼼꼼히 읽고, 디테일에 절대 짜증 내지 않으며, 몇 초 만에 작업을 시작합니다. 그에 걸맞은 브리프를 주세요.