14장. 좋은 프롬프트의 4요소 — Role, Structure, Style, Constraint
14장. 좋은 프롬프트의 4요소 — Role, Structure, Style, Constraint
Figma Make를 처음 쓰는 사람은 대개 이렇게 말합니다. "같은 도구인데 왜 어떤 사람 결과물은 바로 쓸 만하고, 내 결과물은 묘하게 어설프지?"
답은 생각보다 단순합니다. 차이는 손재주보다 프롬프트 구조에서 납니다. 이제 프롬프트는 '느낌 좋은 문장'이 아니라, 결과 품질을 좌우하는 설계 문서에 가깝습니다. Make는 친절한 비서처럼 보이지만, 실제로는 아주 문자 그대로 일하는 도구입니다. 애매하게 말하면 애매하게 만들고, 구조적으로 말하면 구조적으로 만듭니다.12
그래서 이 장에서는 좋은 프롬프트를 네 가지 축으로 정리해 보려 합니다. Role, Structure, Style, Constraint. 이 네 가지만 제대로 잡으면 프롬프트는 감이 아니라 재현 가능한 디자인 스킬이 됩니다.
간단히 말해 이렇습니다.
Role은 "누구의 관점으로 만들 것인가"를 정합니다.
Structure는 "무엇을 어떤 구조로 만들 것인가"를 정합니다.
Style은 "어떤 분위기와 시스템을 따라야 하는가"를 정합니다.
Constraint는 "무엇을 절대 넘으면 안 되는가"를 정합니다.
이 네 가지가 빠진 프롬프트는 대개 그럴듯하지만 모호합니다. 반대로 네 가지가 또렷하면 결과는 덜 화려해 보여도 훨씬 쓸 만합니다.
프롬프트는 주문이 아니라 브리프다
"대시보드 하나 만들어줘."
이건 프롬프트처럼 보이지만, 사실상 소원에 가깝습니다. 사용자는 누구인지, 어떤 데이터를 봐야 하는지, 모바일인지 데스크톱인지, 차트를 보여줘야 하는지 표를 보여줘야 하는지, 브랜드 톤은 어떤지 전부 비어 있습니다. Make는 그 빈칸을 자기식으로 메우게 되고, 그 순간부터 결과는 흔들립니다.
반대로 좋은 프롬프트는 짧아도 브리프처럼 읽힙니다. 해야 할 일, 맥락, 필요한 요소, 기대 행동, 제약이 분명합니다. Figma도 첫 프롬프트에 목적과 구조, 핵심 요소, 행동, 제약을 충분히 담을수록 수정 루프가 줄어든다고 권합니다.2 또 지나치게 공손하거나 장황한 표현보다, 직접적이고 명확한 표현이 더 효율적이라고 설명합니다.3
즉, 좋은 프롬프트는 예쁜 문장이 아니라 의도를 압축한 설계문입니다.
Role — AI에게 직무와 관점을 준다
첫 번째 요소는 Role입니다. 여기서 말하는 Role은 단순히 "너는 디자이너야" 수준이 아닙니다. 어떤 문제를, 누구를 위해, 어떤 기준으로 풀어야 하는지를 알려 주는 장치입니다.
예를 들어 "헬스케어 앱 만들어줘"와 "중장년 사용자를 위한 복약 관리 앱을 설계하는 시니어 모바일 프로덕트 디자이너처럼 작업해줘"는 완전히 다릅니다. 두 번째 문장은 이미 중요한 판단 기준을 몇 개 품고 있습니다. 사용자의 디지털 숙련도가 높지 않을 수 있고, 텍스트 가독성이 중요하며, 행동 유도는 단순해야 하고, 실수 비용이 큰 서비스라는 점이 자연스럽게 따라옵니다.
Role이 좋은 프롬프트는 AI가 '예쁜 화면'을 만드는 대신 '적절한 화면'을 만들게 합니다.
예를 들어 이런 식입니다.
잘 안 되는 예: 생산성 앱 화면 만들어줘.
더 좋은 예: 스타트업 운영팀이 매일 사용하는 태스크 관리 도구를 설계하는 B2B 프로덕트 디자이너의 관점으로 작업해줘. 빠른 스캔, 명확한 상태 구분, 테이블과 필터 중심의 작업 효율을 우선해줘.
이 차이는 작지 않습니다. 첫 문장은 테마를 던진 것이고, 두 번째 문장은 판단 기준을 준 것입니다.
Role을 쓸 때는 다음 세 가지를 함께 붙이면 좋습니다.
직무 관점: 시니어 프로덕트 디자이너, UX 라이터, 데이터 중심 서비스 디자이너 등
도메인 맥락: 핀테크, 교육, 커머스, 백오피스, 헬스케어 등
사용자 관점: 초보 사용자, 현장 관리자, 자주 쓰는 파워 유저, 다국어 사용자 등
Role이 강하면 Make는 덜 꾸미고 더 판단합니다. 바로 그 점이 중요합니다.
Structure — 화면을 설명하지 말고 조립하라
두 번째 요소는 Structure입니다. 많은 사람이 여기서 가장 많이 실패합니다. 무슨 앱인지 설명은 길게 쓰는데, 정작 화면이 어떻게 구성되어야 하는지는 흐릿하게 적기 때문입니다.
좋은 Structure는 화면을 '느낌'이 아니라 '부품과 관계'로 설명합니다. Figma의 공식 가이드는 명확하고 직접적으로 말하라고 권하며, 원하는 최종 결과를 구체적으로 설명할수록 모델이 엉뚱한 기능을 지어낼 가능성이 줄어든다고 설명합니다.1
Structure에는 보통 다음이 들어갑니다.
무엇을 만들지: 랜딩 페이지인지, 설정 화면인지, 대시보드인지
어떤 섹션이 필요한지: 헤더, 필터 바, 카드, 표, CTA, 푸터 등
무엇이 어떻게 동작하는지: 클릭 시 열림, 탭 전환, 검색, 정렬, 입력 검증 등
어떤 상태를 포함해야 하는지: 비어 있음, 로딩, 오류, 성공, 읽기 전용 등
출력 범위가 어디까지인지: 한 화면인지, 멀티스텝 플로우인지, 데스크톱 우선인지
예를 들어 "세련된 재무 대시보드"보다 아래처럼 쓰는 편이 훨씬 강합니다.
데스크톱 우선의 재무 대시보드를 만들어줘. 상단에는 날짜 범위 선택과 다운로드 액션이 있는 헤더를 두고, 그 아래에는 핵심 지표 카드 4개를 한 줄로 배치해줘. 다음 섹션에는 수입/지출 추세 라인 차트와 카테고리별 지출 도넛 차트를 두고, 하단에는 최근 거래 테이블을 배치해줘. 테이블은 검색, 상태 필터, 정렬을 지원하고, 빈 상태와 로딩 상태를 포함해줘.
이 문장에는 이미 IA가 들어 있고, 상태도 들어 있고, 인터랙션도 들어 있습니다. Make는 이렇게 생긴 문장을 좋아합니다.
구조를 더 안정적으로 만들고 싶다면, 첫 프롬프트에 모든 것을 한 번에 넣되 결과를 한 번에 완성하려 하지 않는 태도가 중요합니다. Figma는 큰 프로젝트를 작은 단계로 쪼개고, 후속 수정은 작은 범위로 나누어 요청하는 편이 더 안정적이라고 권합니다.2
쉽게 말해, 첫 프롬프트는 청사진, 후속 프롬프트는 정밀 공정입니다.
Style — 취향을 말하지 말고 기준을 말하라
세 번째 요소는 Style입니다. 여기서 많은 사람이 "미니멀하게", "세련되게", "애플처럼" 같은 표현을 씁니다. 나쁜 표현은 아니지만, 그것만으로는 충분하지 않습니다. Style은 취향 고백이 아니라 시각적 기준의 전달이어야 합니다.
좋은 Style은 크게 두 갈래입니다. 하나는 디자인 시스템 기준, 다른 하나는 표현 톤 기준입니다.
디자인 시스템 기준에는 이런 것이 들어갑니다.
어떤 라이브러리나 컴포넌트를 써야 하는가
토큰, 변수, 간격 체계를 따라야 하는가
버튼, 카드, 입력창이 어떤 성격이어야 하는가
기존 Figma 프레임이나 컴포넌트를 참조해야 하는가
표현 톤 기준에는 이런 것이 들어갑니다.
차분함, 실용성, 장난기, 프리미엄, 따뜻함 같은 인상
타이포 밀도와 여백 감각
라운드 코너, 그림자, 대비, 시각적 무게감
참고 브랜드나 레퍼런스의 분위기
여기서 중요한 팁이 하나 있습니다. 이미지나 스크린샷을 첨부하는 것보다, 가능하면 Figma 프레임이나 컴포넌트 자체를 맥락으로 주는 편이 낫다는 점입니다. 이미지보다 구조화된 디자인 데이터가 더 많은 정보를 전달하기 때문입니다.3 또한 공식 문서는 예시를 함께 주면 결과가 더 가까워질 수 있다고 설명하지만, 이미지가 정확한 색상값까지 읽는 것은 아니라는 점도 함께 말합니다.1
즉, Style은 "이런 느낌으로"보다 "이 기준을 따라"에 가깝게 써야 합니다.
예를 들면 이런 식입니다.
우리 디자인 시스템의 카드, 버튼, 입력 패턴을 우선 사용해줘. 전체 톤은 엔터프라이즈 B2B 제품답게 차분하고 밀도 있게 유지하고, 장식적인 일러스트나 과한 그라디언트는 쓰지 마. 간격은 넉넉하되 정보 밀도는 유지해줘. 타이포는 제목보다 본문 가독성을 우선해줘.
이건 Style이면서 동시에 판단 기준입니다. Make가 엇나갈 여지를 줄여 줍니다.
Constraint — 결과 품질은 금지 조항에서 갈린다
네 번째 요소는 Constraint입니다. 개인적으로 가장 중요한 축입니다. Role이 방향을 주고, Structure가 뼈대를 세우고, Style이 표정을 만든다면, Constraint는 사고를 막습니다.
좋은 Constraint는 "무엇을 할지"보다 "무엇을 하지 말아야 하는지"를 분명히 합니다. Figma의 프롬프트 가이드도 명확한 지시가 모델의 불필요한 추측을 줄인다고 설명합니다.1 실제 팀에서는 이 원칙이 더 강하게 작동합니다. 보수적으로 변경하고, 불명확하면 발명하지 말고, 기존 디자인을 함부로 재설계하지 말라는 식의 가이드라인이 결과를 안정시킵니다.4
Constraint에는 보통 이런 것들이 들어갑니다.
플랫폼 제약: 모바일 우선, 데스크톱 전용, 반응형 필요 여부
시스템 제약: 기존 컴포넌트만 사용, 새 토큰 금지, 네비게이션 구조 유지
경험 제약: 한 화면에 주요 액션은 하나, 오류 상태 필수, 접근성 고려
비즈니스 제약: 역할별 권한 구분, 민감 정보 입력 금지, 법무 문구 생략 금지
수정 제약: 이 섹션만 바꾸고 나머지는 유지, 레이아웃은 유지하고 콘텐츠만 변경
특히 민감 정보는 프롬프트에 직접 넣지 않는 것이 중요합니다. Figma는 API 키, 주소, 개인 정보, 식별 번호 같은 민감한 데이터는 AI 채팅에 넣지 말고, 필요하다면 사용자가 입력할 수 있는 UI를 생성하게 하라고 안내합니다.1
Constraint가 약하면 결과는 화려하지만 위험합니다. Constraint가 강하면 결과는 조금 심심해 보여도 실무에서 살아남습니다.
네 요소를 한 줄로 묶는 법
이제 Role, Structure, Style, Constraint를 한데 묶어 봅시다. 이 네 가지는 따로 놀면 체크리스트지만, 함께 쓰면 강력한 프롬프트가 됩니다.
아래 템플릿은 Figma Make에서 가장 무난하게 잘 통하는 형태입니다.
Role: 당신은 [어떤 직무/도메인]의 관점으로 작업한다. 주요 사용자는 [누구]다.
Structure: [무엇]을 만든다. 화면에는 [섹션/요소]가 포함되어야 하며, [행동/상태]를 지원해야 한다.
Style: [디자인 시스템/컴포넌트/시각 톤]을 따른다. [참고 프레임/브랜드/표현 방식]을 반영한다.
Constraint: [플랫폼/접근성/비즈니스/금지 사항]을 지킨다. 명확히 요청되지 않은 기능은 추가하지 않는다.
겉으로 보기엔 단순하지만, 이 구조에는 실무에서 필요한 거의 모든 축이 들어 있습니다.
실전 예시 — 한 줄 프롬프트를 네 축 프롬프트로 바꾸기
먼저 나쁜 예를 보겠습니다.
반려동물 병원 예약 앱 만들어줘. 귀엽고 편하게.
완전히 틀린 말은 아닙니다. 하지만 Make 입장에서는 빈칸이 너무 많습니다.
이제 같은 요청을 네 축으로 다시 써 보겠습니다.
당신은 초보 보호자도 쉽게 쓸 수 있는 모바일 헬스케어 서비스를 설계하는 시니어 프로덕트 디자이너다. 주요 사용자는 동물병원 예약 경험이 많지 않은 반려동물 보호자다.
iOS/Android 공용 모바일 예약 앱의 홈 화면과 예약 플로우 첫 단계를 만들어줘. 홈 화면에는 오늘 가능한 병원 목록, 진료 과목 필터, 반려동물 프로필 스위처, 긴급 상담 CTA를 포함해줘. 예약 시작 화면에는 날짜 선택, 시간대 선택, 병원 정보 요약, 비용 안내를 포함해줘. 병원이 없을 때의 빈 상태와 예약 가능 시간이 없을 때의 상태도 포함해줘.
전체 스타일은 따뜻하고 안심되는 톤으로, 과하게 장난스럽지 않게 구성해줘. 둥근 모서리와 부드러운 대비를 사용하되, 본문 가독성을 우선해줘. 첨부한 카드 컴포넌트와 버튼 스타일을 최대한 따른다.
새 네비게이션 구조를 발명하지 말고, 한 화면에 하나의 주요 CTA만 강조해줘. 의료 정보처럼 보일 수 있는 과장된 그래픽은 쓰지 말고, 개인정보나 실제 결제 정보 입력 필드는 만들지 마.
이 프롬프트는 길어졌지만, 실제로는 재작업 시간을 줄입니다. 첫 결과가 더 좋아지기 때문입니다.2
첫 프롬프트는 길게, 수정 프롬프트는 짧게
초보자는 자주 반대로 합니다. 첫 프롬프트는 너무 짧고, 수정 프롬프트는 길고 복잡합니다. 그러면 이미 비뚤어진 결과 위에 지시가 계속 덧칠됩니다.
보통은 이렇게 가는 편이 낫습니다.
첫 프롬프트에서는 Role, Structure, Style, Constraint를 충분히 준다.
두 번째부터는 한 번에 한 가지씩 바꾼다.
선택한 요소를 기준으로 수정 범위를 좁힌다.
지켜야 할 것과 바꿀 것을 함께 말한다.
예를 들어 후속 프롬프트는 이렇게 짧아져야 합니다.
상단 병원 카드 레이아웃은 유지하고, 카드 내부의 정보 위계를 더 분명하게 만들어줘. 병원명과 진료 가능 시간을 우선 노출하고, 리뷰 점수는 보조 정보로 내려줘. 색상과 전체 간격 체계는 그대로 유지해.
이런 식의 수정은 잘 먹힙니다. 구조가 이미 있으니, 이제는 정밀한 방향 조정만 하면 되기 때문입니다. 실제 사례를 다룬 글들도 초기에는 구조화된 입력이 중요하고, 기반이 생긴 뒤에는 짧고 표적이 분명한 수정 프롬프트가 더 잘 작동한다고 설명합니다.5
프롬프트가 자주 실패하는 이유
Figma Make에서 결과가 애매하게 나오는 데는 대체로 비슷한 이유가 있습니다.
역할이 없다: 누구를 위한 화면인지 몰라서 안전하고 평범한 결과가 나온다.
구조가 없다: 섹션, 상태, 행동이 비어 있어 와이어프레임 수준에서 멈춘다.
스타일 기준이 없다: 예쁘긴 한데 우리 제품 같지 않다.
제약이 없다: 멋대로 기능을 추가하거나, 불필요한 재설계를 해 버린다.
범위가 너무 크다: 한 번에 앱 전체를 만들려다 중간중간 품질이 무너진다.2
입력이 너무 예의 바르다: 사람에겐 친절하지만 모델에겐 노이즈가 된다.3
이미지에만 의존한다: 보기엔 비슷해도 구조와 토큰 정보가 빠져 결과가 불안정해진다.13
이 목록을 보면 알 수 있습니다. 실패는 대개 모델이 멍청해서가 아니라, 지시가 설계되지 않았기 때문에 생깁니다.
팀에서는 프롬프트를 개인 비법이 아니라 자산으로 관리해야 한다
프롬프트가 재현 가능한 스킬이라면, 팀에서는 당연히 자산으로 관리해야 합니다. 잘 되는 프롬프트를 누군가 머릿속에만 넣어 두면 매번 같은 시행착오를 반복합니다.
그래서 실무에서는 다음처럼 운영하면 좋습니다.
잘 먹힌 첫 프롬프트를 템플릿으로 저장한다.
도메인별 Role 문장을 미리 만들어 둔다.
디자인 시스템용 Style 문장을 공용으로 관리한다.
금지 사항과 비즈니스 규칙을 Constraint 블록으로 표준화한다.
특히 팀의 디자인 시스템이 분명할수록 Constraint와 Style은 문장 몇 줄로도 강력해집니다. "기존 라이브러리만 사용", "새 토큰 생성 금지", "권한이 불분명하면 추측하지 말 것" 같은 문장은 놀라울 만큼 많은 오류를 예방합니다.4
한마디로, 좋은 프롬프트는 개인의 말솜씨가 아니라 팀의 운영 체계가 될 수 있습니다.
바로 써먹는 4요소 체크리스트
프롬프트를 보내기 전에 아래 네 질문만 확인해 보세요.
Role: 이 화면을 어떤 직무와 어떤 사용자 관점에서 만들라고 했는가?
Structure: 필요한 섹션, 상태, 행동, 범위를 분명히 썼는가?
Style: 우리 시스템, 참고 프레임, 시각 톤을 충분히 전달했는가?
Constraint: 하지 말아야 할 일과 지켜야 할 규칙을 분명히 적었는가?
이 네 질문에 선명하게 답할 수 있다면, 이미 프롬프트의 절반은 성공입니다.
프롬프트는 결국 디자인 판단을 언어로 옮기는 기술이다
좋은 프롬프트를 쓴다는 것은 말을 그럴듯하게 하는 일이 아닙니다. 머릿속의 디자인 판단을 도구가 이해할 수 있는 문장으로 바꾸는 일입니다.
Role은 관점을 주고, Structure는 조립 순서를 주고, Style은 닮아야 할 기준을 주고, Constraint는 실수를 막습니다. 이 네 가지가 합쳐질 때 Make는 비로소 '알아서 만들어 주는 도구'가 아니라, '내 판단을 증폭하는 도구'가 됩니다.
이제 중요한 것은 감이 아닙니다. 반복 가능한 문법입니다.
다음 장에서는 이 문법을 실제 작업 흐름에 연결해 보겠습니다. 이미 만든 Figma 디자인을 Make로 가져오고, 한 번에 완성하려 하지 않고 점진적으로 정교화하는 방법을 살펴볼 차례입니다.
참고
28 ways to build with Figma Make
3Cooking with constraints: A designer's framework for better AI prompts
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.