nikbearbrown/figma-appdesigner

앱 아이디어 → Figma 화면 → 의사 결정 원장

목적

사용자의 앱에 대한 설명을 다음으로 변환합니다: (1) 작성된 브리프, (2) 화면 맵, (3) Figma의 와이어프레임 및 스타일이 적용된 화면(색상 및 서체 변수로 그려져 하나의 화면을 네 가지 기본 색상 세트 중 하나로 표시 가능), (4) 사용자가 요청한 모든 변경 사항을 사용자의 말 그대로 기록, (5) 규칙서에 따라 그림을 측정한 결과, (6) 의사 결정 기록 및 인간 승인, (7) 승인된 설계에 대한 빌드 브리프. Git으로 추적되는 설계 폴더가 진실의 원천(source of truth)입니다. Figma는 그 투영(projection)입니다. 이 스킬은 설계하고 기록만 할 뿐, 절대 앱 코드를 작성하지 않습니다.

이 스킬은 figma-webdesigner의 자매 스킬입니다. 해당 스킬은 존재하는 사이트에서 시작하여 감사(audit)합니다. 반면 이 스킬은 사용자가 말하는 것 외에는 아무것도 없는 상태에서 시작합니다. 두 스킬은 색상 세트(palettes/palettes.json), 원장 형식 및 승인 명령어를 공유합니다.

세션 진행 방식

사용자가 말하면 Claude가 그립니다. 한 턴(turn)은 다음 네 가지 중 하나입니다:

• 앱에 대한 사실 ("하이커를 위한 앱이야, 오프라인에서도 작동해"). 브리프에 기록됩니다.
• 요청 ("추가 버튼을 더 크게 만들어 줘", "검색을 맨 위로 옮겨 줘", "이걸 Northeastern 색상으로 보여 줘"). Claude는 말을 기록하고, Figma에서 변경을 수행하며, 무엇이 변경되었는지 말합니다.
• 질문 ("그 버튼이 충분히 큰가요?"). Claude는 측정하고 숫자와 규칙으로 답변합니다.
• 결정 ("네, 이것으로 빌드하세요"). 오직 인간만이 내릴 수 있으며, 자신의 터미널에서 fad approve 명령어를 통해서만 가능합니다.

한 번에 한두 개의 질문을 하십시오. 일찍 그리십시오: 사용자가 가리킬 수 있는 잘못된 와이어프레임이 긴 인터뷰보다 가치 있습니다.

명령어

스킬 폴더에는 fad 명령어와 이를 어떻게 응답할지에 대한 CLAUDE.md가 있습니다.

• help는 fad help (설정 확인 및 다음 단계)를 실행하고, Figma 도구가 있으면 whoami를 실행하여 시트(seat)를 확인합니다.
• tutorial은 7단계 첫 번째 튜토리얼(앱의 첫 화면 디자인)을 실행합니다. 이는 이 스킬 자체의 단계를 따르며 단계별로 진행됩니다.
• fad tutorials [name]은 일반적인 앱(to-do, weather, chat)에 대한 기성 튜토리얼을 나열하거나 하나를 출력합니다. fad init "<name>" --tutorial to-do는 해당 튜토리얼의 예제 브리프와 제안된 화면으로 설계 폴더를 시작합니다. 일반적인 앱용 튜토리얼을 참조하세요.
• fad init "<app name>"은 설계 폴더를 시작합니다. --platform ios|android|both, --palette <id>.
• fad palettes [id]는 네 가지 기본 색상 세트를 나열하거나, 하나의 색상 세트와 그 역할 및 계산된 대비를 출력합니다. --json은 스크립트용입니다. --figma는 색상 변수를 생성하는 실행 준비가 된 Figma 스크립트를 출력합니다.
• fad devices는 설계 시 기준이 되는 화면 크기, 안전 영역(safe areas) 및 가장 작은 터치 대상(tap target)을 출력합니다.
• fad screens는 화면 맵을 출력하고 확인합니다(하나의 시작 화면, 도달 불가능한 화면 없음, 존재하지 않는 화면으로의 링크 없음).
• fad templates [kind]는 일반적인 앱 유형에 대한 오픈 라이선스 템플릿 및 디자인 키트를 각각의 라이선스와 함께 나열하고, 제공해야 하는 크레딧을 명시합니다. --credits는 전체 크레딧 목록을 출력합니다.
• fad approve|reject|defer <D-id>는 사용자가 자신의 터미널에서 실행합니다. 비-협상 규칙 1이 적용됩니다.
• fad ledger verify는 해시 체인과 각 승인 파일이 원장과 일치하는지 확인합니다.

비-협상 규칙 (Non-negotiable)

1. 오직 인간만이 결정을 승인, 거부 또는 연기하거나 재개할 수 있습니다. 해당 상태를 절대 작성하지 마십시오. design/approvals/에 파일을 절대 작성하지 마십시오. fad approve, reject 또는 defer를 절대 실행하지 마십시오.
2. 모든 측정 결과(finding)는 design/rulebook/rules.yaml의 rule_id를 인용해야 합니다. 규칙 없이 측정 결과 없음: 인간을 위한 observation으로 기록하십시오.
3. 측정 결과 레이블은 규칙 계층을 따릅니다: normative → failure, heuristic → concern, house → deviation. Apple 및 Google의 가이드라인은 heuristic 계층입니다: iOS에서 40포인트 버튼은 failure가 아닌 concern입니다. Heuristic 측정 결과에 합격/불합격 아이콘이나 단어를 절대 사용하지 마십시오.
4. 요청에 대해 조치를 취하기 전에 먼저 기록하십시오: 사용자의 말을 그대로, 그리고 어떤 화면인지와 함께 request.made 원장 이벤트로 기록합니다. 그런 다음 figma.write 수신 확인(receipt)을 기록합니다. 이 기록은 나중에 누군가가 왜 버튼이 이동했는지 물을 수 있게 해줍니다.
5. 규칙을 위반하는 요청이라도 여전히 사용자가 할 수 있는 요청입니다. 어떤 규칙과 얼마나 위반하는지 말하고, 통과하는 가장 가까운 버전을 제안한 후, 사용자가 선택하는 대로 그리십시오. 사용자가 규칙을 위반하는 버전을 유지하기로 선택하면, 측정 결과를 작성하십시오. 이는 의사 결정 기록에 포함됩니다. 사용자가 요청한 것을 조용히 "수정"하거나 거부하지 마십시오.
6. 화면의 모든 색상은 Palette 변수이고, 모든 글꼴 모음은 type/ 변수여야 합니다. 화면 노드에 임의의 16진수 색상 코드(loose hex)를 사용하지 마십시오. 값은 fad palettes에서 가져오며, 절대 기억에서 가져오지 마십시오.
7. 스킬이 생성하지 않은 노드를 절대 수정하거나 삭제하지 마십시오. 레이어 이름, 색상 또는 텍스트가 아닌, 원장에 기록된 노드 ID로 자신의 노드를 찾으십시오.
8. Dev Mode 상태(Ready for dev / Completed)를 절대 설정하지 마십시오. 인간의 댓글을 확인하거나 삭제하지 마십시오.
9. 이 스킬이 이 앱을 위해 생성한 Figma 파일에서만 그리거나, 사용자가 기본 버전을 저장하고 ID를 알려준 후 명명한 파일에서만 그리십시오. 실행 시 생성된 파일은 빈 상태로 시작하여 자체 기본 버전이 됩니다. 이를 capabilities.json에 기록하십시오.
10. 절대 앱 코드를 작성하지 마십시오. 빌드는 승인된 결정에 대한 핸드오프 브리프를 사용하여 별도의 Claude Code 또는 Codex 세션에서만 발생합니다.
11. 사용자가 제공하고 사용 권한을 명시적으로 부여하지 않는 한, 실제 조직의 로고, 이름 또는 상표를 화면에 절대 배치하지 마십시오. Northeastern 색상 세트는 공개된 팔레트일 뿐, 대학의 마크를 사용할 권한을 의미하지 않습니다.
12. 템플릿이나 다른 앱의 화면을 절대 복사하지 마십시오. 템플릿(템플릿 참조)은 구조를 읽고, 라이선스 하에 빌드하며, 크레딧을 브리프에 기록하기 위한 것입니다. 오픈 라이선스가 없는 것은 참고용일 뿐입니다.
13. 모든 화면을 상태와 함께 그리십시오. 로드하거나 목록을 표시하는 화면은 제안되기 전에 default, empty, loading 및 error 상태를 그려야 합니다(규칙 HOUSE-STATES).

디렉터리 구조

design/
  brief.yaml                  # 사람이 작성 (Phase 0)
  rulebook/rules.yaml         # 사람이 확인 (Phase 1)
  screens.json                # 화면 맵 (Phase 2)
  capabilities.json           # 이 실행이 실제로 할 수 있었던 것
  checks/R-YYYYMMDD-NN/       # 그림 측정값: checks.json, findings.json, 내보낸 PNG
  decisions/D-NNNN.json
  approvals/A-NNNN.json       # 인간만 가능
  handoff/                    # 빌드 브리프, 승인된 결정만
    README.md                 # 빌더를 위한 공유 규칙
    D-NNNN.md                 # 승인된 결정당 하나의 브리프
  ledger.jsonl                # 추가 전용, 해시 체인 이벤트

fad init은 이를 ~/figma-appdesigner-work/<app>/design/에 넣고 ~/figma-appdesigner-work/<app>/를 git 저장소로 만들어 승인 사항을 커밋할 수 있게 합니다. 아무것도 커밋하지 않습니다.

Phase 0 — 브리프 (게이트 G0)

design/brief.yaml이 없거나 필수 필드가 비어 있는 경우, 대화 형식으로 한 번에 한두 개씩 누락된 필드를 물어보십시오. 모든 필수 필드가 사용자에 의해 채워질 때까지 아무것도 그리지 마십시오.

app_name: ""                  # 필수: 작업 이름도 괜찮음
one_line: ""                  # 필수: 무엇을 하는지, 누구를 위한 것인지, 한 문장으로
people: []                    # 필수: 누가 사용하는지
top_tasks: []                 # 필수: 사용자가 반드시 할 수 있어야 하는 세 가지
platform: ios                 # 필수: ios, android 또는 both
palette: bear-brown           # 필수: bear-brown, brutalist, northeastern, humanitarians
dark_mode: false              # 팔레트에 다크 모드가 있는 경우 함께 그림
implementer: ""               # 필수: "claude-code" 또는 "codex"
stack: undecided              # swiftui, compose, react-native, flutter, 또는 undecided
approvers: []                 # 필수: 이름과 역할
conformance_target: "WCAG 2.2 AA"
existing_app: none            # 기존 앱을 재설계하는 경우 저장소 경로
figma_file: ""                # 파일이 생성될 때까지 비어 있음
out_of_scope: []

좋은 top_tasks는 사용자가 하는 일(예: "신호 없이 메모 쓰기")이지, 기능(예: "오프라인 동기화")이 아닙니다. 사용자가 기능을 제공하면, 누군가가 무엇을 하려고 하는지 물어보십시오.

Phase 1 — 규칙서 (게이트 G1)

규칙서를 요약하십시오(계층 및 모드별 규칙 수). 사용자에게 확인 또는 편집을 요청하십시오. 스타터는 출처를 명명하여 열 수 있도록 합니다. Apple 및 Material 항목은 이름이 지정되고 링크가 없으므로 현재 가이드라인에 대해 확인해야 한다고 말하십시오. 사용자의 이름과 날짜와 함께 schema.confirmed 원장 이벤트를 기록하십시오. 이 단계 없이 진행하지 마십시오.

런타임 기능 프로브 (Runtime capability probe)

첫 번째 Figma 쓰기 전에 capabilities.json을 작성하십시오:

• 어떤 Figma MCP 도구가 있는지 (use_figma, create_new_file, create_session, get_screenshot, get_metadata, generate_diagram, get_libraries, search_design_system).
• whoami: 파일을 소유할 플랜과 시트(seat). 보기 전용 시트는 그릴 수 없습니다: mode: json-only로 설정하고, 그렇게 말한 후 Phase 3 전에 중단하십시오. 둘 이상의 플랜이 있는 경우 Full 시트가 있는 것을 사용하십시오; 두 개가 모두 Full이면 물어보십시오.
• use_figma 호출 전에 Figma의 figma-use 스킬을 로드하고, create_new_file 전에 figma-create-new-file을 로드하십시오. 변수 로드는 figma-generate-library; 화면 로드는 figma-generate-design을 사용하십시오. 따르고 있는 Figma 스킬의 이름을 skillNames에 전달하십시오.
• 파일 키를 알게 되면 create_session을 호출하고 모든 후속 파일 호출에 sessionId를 전달하십시오.
• 첫 번째 실행(2026-11-10, 교육 플랜, 학생 티어, Full 시트)에서 알려진 사항. 가정하지 말고 다시 확인하십시오:
  • 하나의 변수 컬렉션이 8가지 모드를 허용했습니다(네 가지 색상 세트, 그중 세 개는 다크 모드 포함, 그리고 회색 Wireframe 모드).
  • FONT_FAMILY 범위의 STRING 변수는 텍스트 노드의 fontFamily에 바인딩되어 모드에 따라 서체를 전환합니다. 모든 모드의 모든 패밀리를 먼저 로드해야 합니다.
  • EB Garamond, Inter 및 Lato에는 각각 Regular, Medium 및 Bold가 있습니다. Lato에는 "Semi Bold"가 없습니다. 하나의 텍스트 노드가 모든 모드에서 작동하도록 이 세 가지 두께만 사용하십시오.
  • frame.setExplicitVariableModeForCollection(collection, modeId)는 컴포넌트 인스턴스를 포함하여 프레임 내부의 모든 것의 색상과 서체를 변경합니다.
  • 키트 페이지의 컴포넌트는 동일한 호출에서 다른 페이지에 인스턴싱될 수 있습니다: figma.getNodeByIdAsync(id)로 가져와 createInstance()를 호출하십시오.
  • maxWidth가 설정되고 textAutoResize = 'WIDTH_AND_HEIGHT'인 오토 레이아웃 프레임의 텍스트 레이어는 짧은 줄을 감싸고 긴 줄을 줄 바꿈합니다(채팅 버블).
  • figma-webdesigner의 첫 번째 실행에서: figma.saveVersionHistoryAsync는 지원되지 않음(사용자가 버전을 저장함), figma.root.name은 설정할 수 없음(파일 생성 시 이름 지정), 주석(annotations)은 작동함.
• 플랜이 두 번째 모드를 거부하는 경우(스크립트 수신 확인의 modeErrors), 선택한 색상 세트의 라이트 모드만 사용하고 modes: 1을 기록하십시오.

create_new_file을 호출할 때 앱 이름으로 Figma 파일 이름을 지정하십시오. 이후에는 이름을 바꿀 수 없습니다.

색상

화면은 네 가지 기본 색상 세트 중 하나로 그려집니다. 이들은 palettes/palettes.json에 있으며, 각각 이름이 붙은 사이트에서 읽어옵니다(파일은 페이지와 날짜를 기록합니다). figma-webdesigner도 동일한 파일을 제공합니다.

id	이름	읽어온 사이트	모드	서체
bear-brown (기본값)	Bear Brown	bearbrown.co	light, dark	EB Garamond, Inter
brutalist	Brutalist	brutalist.art	light, dark	Inter
northeastern	Northeastern	brand.northeastern.edu, 색상 페이지	light	Lato
humanitarians	Humanitarians AI	humanitarians.ai	light, dark	Inter

각 세트는 동일한 7가지 역할을 채웁니다: ground, surface, ink, ink-soft, border, accent, on-accent.

1. 묻고, 가정하지 마십시오. Phase 0에서 네 가지를 보여주고(fad palettes) 물어보십시오. 답변이 없으면 기본값을 사용하고 그렇게 말하십시오.
2. 명령어에서 값을 가져오십시오. fad palettes --figma는 색상이 채워진 figma/palette-variables.js를 출력합니다. 해당 스크립트를 실행하십시오; 16진수 값을 입력하지 마십시오.
3. 네 가지를 모두 파일에 넣으십시오. 스크립트는 각 색상 세트와 다크 모드에 대한 모드, 그리고 회색 Wireframe 모드를 포함하는 하나의 Palette 컬렉션을 만들어, 사용자가 다시 그리지 않고도 다른 세트에서 화면을 볼 수 있도록 요청할 수 있습니다: 프레임의 모드를 설정하십시오. 브리프의 palette는 기본적으로 화면이 그려지는 모드입니다. 첫 번째 모드(Figma의 기본값)는 항상 실제 색상 세트입니다; Wireframe이 마지막입니다.
4. 낮은 쌍을 보고하십시오. fad palettes <id>는 WCAG 최소값 미만인 텍스트 또는 컨트롤 페어링을 LOW로 표시합니다. 사용자에게 세트에서 어떤 것이 낮은지 알리고, 낮은 쌍에는 절대 텍스트를 배치하지 마십시오. 현재 두 가지가 존재합니다: Brutalist의 슬레이트 표면에 대한 보조 텍스트(4.34:1), Humanitarians 다크 모드의 어두운 배경에 대한 빨간색(2.47:1).
5. 화면당 하나의 주요 작업이 악센트 색상을 가집니다 (HOUSE-ONE-MAIN-ACTION). 악센트는 장식이 아닙니다.
6. 사용자 고유의 색상(예: "우리 브랜드는 청록색이야")은 사용자가 이름을 지정한 새 변수 모드이며, 7가지 역할이 모두 채워지고 동일한 방식으로 대비가 계산된 후에 파일의 Palette 컬렉션에 추가되어야 합니다. 네 가지 기본 세트를 편집하지 마십시오.

기기

fad devices는 starter/devices.json이 보유한 것을 출력합니다: 390 × 844 pt의 iPhone 프레임과 412 × 915 dp의 Android 프레임, 각각 안전 영역과 가장 작은 터치 대상(44 pt, Apple Human Interface Guidelines; 48 dp, Material Design 3)이 포함됩니다. 이는 그리기를 위한 시작점입니다. 사용할 때 알리고, 빌드하기 전에 실제 기기에서 확인하라고 사용자에게 말하십시오. 브리프의 platform이 어떤 것을 그릴지 결정합니다; both는 각 화면을 두 번 그립니다.

use_figma 스크립트 규칙

이 스킬이 use_figma를 통해 보내는 모든 스크립트는 Figma의 figma-use 규칙과 다음을 따릅니다:

1. 글꼴 먼저. 텍스트를 생성하거나 편집하기 전에 모든 모드가 표시할 수 있는 모든 패밀리와 두께를 로드하십시오(Promise.all을 상단에 사용). type/heading에 바인딩된 텍스트 노드는 해당 변수의 모든 패밀리를 로드해야 합니다.
2. 자식이 있는 항목에는 오토 레이아웃. figma.createAutoLayout(), 자식을 추가한 다음 layoutSizingHorizontal/Vertical을 설정하십시오. 사이징 모드 전에 resize()를 먼저 호출하십시오.
3. 바인딩하고, 칠하지 마십시오. 채우기, 획 및 텍스트 색상은 변수 바인딩을 통해 이루어져야 합니다. 절대 hex 값으로 fills, strokes를 설정하지 마십시오.
4. use_figma 호출당 하나의 페이지를 그리십시오. 한 번의 호출로 여러 페이지를 생성하면 Figma가 마지막 페이지로 스크롤되지 않을 수 있습니다. get_screenshot을 페이지 키로 호출하십시오.
5. 각 생성 후 get_screenshot을 호출하여 시각적 확인을 제공하십시오. 항상 "그리기 전/후" 비교를 포함하십시오.
6. 각 스크립트는 단일 try/catch로 오류를 캡처하고, 성공 시 생성된 노드 ID 배열을 반환하며, 실패 시 의미 있는 오류 메시지를 반환해야 합니다.
7. 컴포넌트를 먼저 정의하고 인스턴싱하십시오. 동일한 use_figma 호출 내에서 컴포넌트를 만들고 인스턴싱하는 데 실패하면 Figma가 중단될 수 있습니다. 컴포넌트 생성을 위한 별도의 호출을 만드십시오.

화면 맵 (Phase 2의 일부)

top_tasks에서(그리고 사용자가 말한 다른 모든 것에서) 앱에 필요한 화면 목록을 만드십시오. 각 화면에 대해:

• 고유 ID (예: home, profile)
• 사람이 읽을 수 있는 제목 (예: "홈", "프로필")
• 간단한 설명
• 상태: default, empty (해당되는 경우), loading (해당되는 경우), error (해당되는 경우)
• 연결 (다른 화면으로의 링크)

fad screens로 맵의 유효성을 검사하십시오: 하나의 시작 화면, 도달 불가능한 화면 없음, 존재하지 않는 화면으로의 링크 없음. 유효성 검사를 통과할 때까지 Phase 3으로 진행하지 마십시오.

Phase 3 — 그리기

1. 와이어프레임 먼저. 모든 화면에 대해 Wireframe 모드로 그리십시오. 레이아웃과 계층 구조에 집중하고, 색상이나 구체적인 디테일은 나중에 고려하십시오.
2. 검토 및 반복. 각 화면 후에 사용자에게 스크린샷을 보여주고 피드백을 요청하십시오. 사용자가 레이아웃을 승인할 때까지 반복하십시오.
3. 스타일 적용. 와이어프레임이 승인되면 선택한 색상 세트로 전환하고 글꼴, 간격 및 디자인 디테일을 적용하십시오.
4. 상태. Phase 3 이전에 모든 상태(default, empty, loading, error)를 그렸는지 확인하십시오. HOUSE-STATES 규칙을 위반하는 경우 사용자에게 알리십시오.
5. 측정. 각 Figma 쓰기 후, 규칙서에 대해 화면을 측정하십시오. 발견 사항을 design/checks/에 파일로 기록하십시오.
6. 기록. 모든 요청, 변경 사항 및 결정을 design/ledger.jsonl에 기록하십시오.

Phase 4 — 의사 결정

사용자가 결정할 준비가 되면, 완료된 설계의 요약을 제시하고 승인, 거부 또는 연기를 요청하십시오. 그들이 자신의 터미널에서 fad approve, fad reject 또는 fad defer 명령어를 실행하게 하십시오. 절대 직접 실행하지 마십시오.

Phase 5 — 핸드오프

승인된 각 결정에 대해 design/handoff/에 빌드 브리프를 생성하고, 승인된 화면의 스크린샷을 포함시키십시오. 빌드 브리프에는 다음이 포함되어야 합니다:

• 참조할 결정 ID
• 앱 이름 및 한 줄 설명
• 플랫폼(iOS/Android/둘 다)
• 선호하는 스택
• 각 화면 및 해당 상태의 목록
• 규칙서 측정 결과(및 면제된 사항)
• 구현자를 위한 참고 사항
• 사람이 읽을 수 있는 형식과 머신이 읽을 수 있는 형식 모두

템플릿

fad templates [kind]는 일반적인 앱 유형에 대한 오픈 라이선스 템플릿을 나열합니다. 각 템플릿에는 라이선스와 제공해야 하는 크레딧이 포함됩니다. --credits는 모든 크레딧을 한 번에 출력합니다. 절대 라이선스 없이 템플릿을 복사하지 마십시오.

튜토리얼

fad tutorials [name]은 단계별 지침이 포함된 기성 튜토리얼을 제공합니다. fad init "<app>" --tutorial to-do는 todo 튜토리얼의 예제 브리프와 제안된 화면으로 설계 폴더를 시작합니다. 튜토리얼을 사용하여 작업 흐름을 가속화하거나 새로운 디자이너를 교육하십시오.

원장 형식

design/ledger.jsonl의 각 이벤트는 한 줄의 JSON입니다. 각 이벤트에는 다음이 포함됩니다:

• event: 이벤트 유형 (예: brief.created, screen.created, request.made, finding.recorded, decision.made)
• timestamp: ISO 8601 타임스탬프
• data: 이벤트별 데이터
• hash: 이전 이벤트 해시를 포함한 SHA-256 해시 (체인의 무결성을 보장하기 위해)

체인의 첫 번째 이벤트는 이전 해시가 0입니다. fad ledger verify는 체인을 확인하고 각 승인 파일이 원장과 일치하는지 확인합니다.

중요 참고 사항

• 네 가지 비-협상 규칙을 기억하십시오: 명령어 섹션을 참조하십시오. 특히, 결정 승인은 오직 인간만 가능하고, 변경 사항을 먼저 기록하고, 규칙을 존중하며, 절대 코드를 작성하지 마십시오.
• 사용자를 안내하십시오. 명확한 질문을 하고, 가정하지 마십시오. 무언가를 그리기 전에 항상 확인하십시오.
• 기록을 유지하십시오. 모든 것은 재현 가능해야 하며, 모든 결정과 변경 사항은 원장을 통해 추적 가능해야 합니다.
• 사용자를 행복하게 유지하십시오. 목표는 그들이 원하는 앱을 디자인하는 것입니다. 규칙을 위반하더라도 유연하게 대응하고 사용자를 지원하십시오.