수정 방향은 아는데 티켓만 쓸 수 있다면
Figma의 가상 박물관 사례에서는 합성 페르소나의 피드백을 통해 대비가 낮은 날짜 선택기와 눈에 잘 띄지 않는 CTA 등이 드러났습니다. 이후 팀 검토에서는 화면 텍스트와 스크린리더 라벨을 일치시키고, 키보드 포커스가 CTA까지 도달하게 하는 요구사항도 구체화됐어요. 문제와 고칠 방향이 이렇게 분명해도 티켓으로 넘기는 순간 구현 순서는 개발 백로그에 달립니다. 작아 보이는 변경일수록 기능 개발과 장애 대응 뒤로 밀리기 쉽고요.
Figma가 공개한 Workflow Lab은 이 대기를 다른 방식으로 바꿉니다. 디자이너가 기존 코드베이스에서 공유 컴포넌트를 찾고, 별도 브랜치에서 수정한 뒤 GitHub PR을 제안합니다. 엔지니어의 검토와 병합 권한은 그대로 유지해요. 구현을 부탁하는 티켓을 검토 가능한 코드 변경으로 바꾸는 흐름입니다.
다만 이 이야기를 실제 고객 성과로 읽으면 안 됩니다. MOSF는 Figma가 설정한 가상 박물관이고, Workflow Lab 역시 샘플 워크플로우입니다. 원문에 등장하는 ‘분기 동안 밀릴 일을 하루 만에 배포했다’는 장면도 표본과 측정법이 공개된 생산성 지표가 아니라 사례 속 서사예요.
한 화면의 색이 아니라 공유 컴포넌트를 고칩니다
이 샘플에서 가져갈 발견은 속도보다 수정 범위입니다. 문제가 된 날짜 선택기는 전시 페이지, 이벤트 캘린더, 회원가입 흐름 세 곳에서 재사용되는 공유 컴포넌트였습니다. 디자이너가 현재 코드의 관계를 확인했기 때문에 한 화면만 고치지 않고 컴포넌트 자체에 변경을 제안할 수 있었습니다.
팀이 검토한 접근성 의도도 구체적이었습니다. 화면 텍스트와 스크린리더 라벨의 일치, 날짜 선택기의 aria-label, CTA까지 이어지는 포커스 순서, 검색 결과가 없을 때 읽어줄 빈 상태 메시지를 확인했습니다. 디자이너가 PR을 제안한 뒤에는 엔지니어가 코드를 검토하고 승인·병합했습니다.
첫 적용 대상은 작고 경계가 분명해야 합니다. 기존 공유 컴포넌트 안에서 해결할 수 있고, 변경 파일과 영향 화면을 리뷰어가 좁은 범위에서 확인할 수 있는 항목이 좋습니다. 라벨, 대비, 포커스 순서, 빈 상태 안내가 후보예요. 상태 관리나 아키텍처를 다시 설계해야 하는 문제는 이 샘플이 보여준 범위를 벗어납니다.
일반 GitHub 푸시와는 다른 클로즈드 베타입니다
기존 저장소를 복제해 브랜치와 PR을 만드는 Make in your local codebase는 제한된 사용자를 위한 무료 클로즈드 베타입니다. 승인 이메일을 받은 Figma 계정, macOS 12 이상을 실행하는 Mac, Mac용 Figma Beta 데스크톱 앱, AI 기능이 활성화된 Figma 조직, 접근 가능한 Git 저장소가 필요합니다. 대기자 명단 등록만으로 참여가 보장되지는 않습니다.
일반 Figma Make의 Push to GitHub는 대체 수단이 아닙니다. 이 기능은 Make가 새로 만든 전용 저장소에 결과를 푸시하며, 사용자가 이미 운영하는 제품 저장소를 선택하거나 브랜치를 관리할 수 없습니다. 기존 저장소를 복제하고 작업 브랜치와 PR을 만드는 흐름은 로컬 코드베이스 베타에 해당합니다.
| 구분 | 일반 Push to GitHub | 로컬 코드베이스 베타 |
|---|---|---|
| 시작점 | Make가 생성한 코드와 전용 저장소 | 접근권이 있는 기존 Git 저장소 |
| Git 작업 | 같은 저장소의 기본 브랜치로 푸시 | 저장소 복제, 로컬 브랜치, 푸시와 PR |
| 필수 조건 | 일반 Make의 계정별 이용 조건 | 승인 계정, macOS 12 이상, Mac용 Beta 앱 등 베타 조건 |
첫 PR은 운영체제와 승인 계정 확인부터 시작합니다
아래 절차는 MOSF의 결과를 재현한다는 보장이 아니라, 현재 공식 문서에 따라 작은 접근성 변경 한 건을 PR까지 보내기 위한 첫 연습입니다. 저장소마다 실행 명령과 환경 변수가 다르므로 설정 검토에는 엔지니어가 참여해야 합니다.
- 승인 이메일을 받은 계정을 확인합니다.
로컬 코드베이스 공식 안내의 대기자 명단 신청 확인과 베타 승인 이메일은 다릅니다. 승인 이메일을 받지 않았다면 대기자 명단에 신청한 뒤 승인을 기다려야 하며, 문서에서 기능을 직접 활성화할 수는 없습니다. - macOS 버전을 확인하고 Figma Beta 앱을 설치합니다.
Mac의 ‘이 Mac에 관하여’에서 macOS 12 이상인지 먼저 확인하세요. 12 미만이면 현재 공식 최소 조건을 충족하지 못하므로 운영체제를 지원 버전으로 올리거나 지원되는 Mac을 준비해야 합니다. 이어 공식 데스크톱 앱 안내에서 macOS용 Beta 설치 파일을 내려받아 설치합니다. Beta 앱을 연 뒤 반드시 승인 이메일을 받은 Figma 계정으로 로그인하세요. 일반 앱과 Beta 앱은 별도 설치물이며, Beta 앱 설치만으로 베타 권한이 생기지는 않습니다. - 조직과 저장소 접근권을 확인합니다.
해당 Figma 조직에서 AI 기능이 활성화됐는지 확인하고, 사용할 GitHub 저장소 URL을 브라우저에서 열어 본인 계정의 접근권을 점검하세요. GitHub 조직 소유 저장소라면 공개·비공개 여부와 관계없이 조직 관리자가 해당 조직에 Figma GitHub 앱을 설치했는지, 설치 범위에 사용할 저장소가 포함됐는지 확인합니다. 별도의 터미널 접근이나 SSH 키를 준비할 필요는 없으며, 최초 브랜치 푸시 또는 PR 생성 때 Make가 표시하는 GitHub 인증을 완료하면 됩니다. - Beta 앱에서 저장소를 복제합니다.
Drafts에서 Make 파일을 만들고 Clone a repository를 선택합니다. 접근 가능한 GitHub HTTPS 저장소 URL과 로컬 저장 폴더를 지정한 뒤 Clone을 실행하세요. 복제가 되지 않으면 본인 계정의 저장소 접근권과 Figma GitHub 앱이 올바른 조직에 연결됐는지부터 확인합니다. - 실행 설정과 필요한 인증값을 엔지니어와 준비합니다.
먼저 Make에서 설정용 새 브랜치를 만들고 전환한 뒤 현재 브랜치 이름을 확인하세요. 실행 설정 추가 요청이 나타나면 Run을 누릅니다. 이미 main에서 설정 파일이 생성됐다면 변경을 유지한 채 설정용 새 브랜치로 옮긴 다음 진행합니다. Make는 저장소 루트의.figma/make아래에setup,install,dev,verify,env파일을 대체로 자동 생성합니다. 각 파일이 저장소의 실제 런타임과 맞는지 확인하고,env에 필수인PORT와FIGMA_MAKE_URL을 설정하세요.
앱이 API 키, 세션 또는 데이터베이스 자격 증명을 요구한다면 저장소의 로컬 개발 문서와 기존 비밀 관리 방식을 먼저 확인해야 합니다. 비밀값은 저장소에 커밋하지 말고 팀이 승인한 방식으로dev프로세스에 전달하세요. 필요한 값이나 로딩 방식이 불명확하면 엔지니어가 설정을 마칠 때까지 다음 단계로 진행하지 않습니다. - 미리보기와 Git 상태를 확인합니다.
의존성 설치, 개발 서버 실행과verify가 성공한 뒤 실제 프로젝트 화면이 Make 미리보기에 로드되는지 확인하세요. 다른 프로젝트가 보이거나 실행되지 않으면 포트 충돌, 대화형 시작 명령, 누락된 환경 변수와 각 설정 파일의 실패 단계를 살펴봅니다. 미리보기가 나타난 뒤에도 백그라운드 빌드가 진행될 수 있으므로 30~60초 기다린 다음, 예상하지 않은 임시·생성 파일이 Git 변경에 대량 포함되지 않았는지 확인하세요. 이 시간은 고정 성능 약속이 아니라 공식 문제 해결 안내의 대기 범위입니다. - 검증된 설정을 원격 main에 반영합니다.
설정용 브랜치에서 검증된.figma/make변경을 커밋하고 해당 브랜치를 푸시한 뒤 main 대상 설정 PR을 엽니다. 엔지니어가 설정 PR을 검토·병합합니다. 이 과정에서 Make가 GitHub 인증을 요구하면 해당 계정으로 인증을 완료하세요. 원격 반영이 끝나면 로컬 main을 최신 상태로 갱신합니다. 설정이 main에 반영돼야 이후 브랜치와 다른 사용자가 같은 실행 환경을 이어받을 수 있습니다. - 갱신한 main에서 접근성 수정용 브랜치를 만듭니다.
최신 main을 기준으로 별도 작업 브랜치를 만들고 전환하세요. 첫 연습은 공유 컴포넌트 안에서 끝나며 변경 파일과 영향 화면을 좁게 검토할 수 있는 항목 하나로 제한합니다. - 수정할 실제 화면을 지정한 뒤 예시 입력을 보냅니다.
미리보기에서 날짜 선택기가 있는 화면을 열고 정확한 경로와 요소 이름을 기록하세요. 아래 두 대괄호를 그 값으로 바꿔 입력합니다. 날짜 선택기가 없다면 실제 존재하는 작은 UI 문제와 해당 경로를 지정하세요. 이 문장은 MOSF에서 실행 결과가 검증된 명령문이 아니라, 공식 사례의 검토 항목을 바탕으로 편집부가 구성한 첫 입력 예시입니다.
미리보기의 [실제 화면 경로]에 있는 [날짜 선택기 이름 또는 위치]를 대상으로 해줘. 지정한 요소를 찾지 못하면 추측해서 수정하지 말고 위치를 확인해줘. 찾은 요소가 다른 화면에서도 재사용되는 공유 컴포넌트인지 먼저 확인해줘. 화면 텍스트와 스크린리더 라벨이 일치하는지, 키보드 포커스가 CTA까지 도달하는지도 점검해줘. 변경 대상 파일과 영향받는 화면을 요약한 뒤 현재 작업 브랜치에 범위가 작은 수정안을 만들어줘.
- 변경 파일과 실제 미리보기를 확인합니다.
현재 브랜치와 생성된 로컬 커밋, 수정 파일을 살펴보고 미리보기에서 영향받는 화면을 여세요. 요청하지 않은 파일까지 바뀌었거나 공유 컴포넌트 밖으로 변경이 번졌다면 PR 전에 범위를 줄입니다. - 작업 브랜치를 푸시하고 PR을 엽니다.
최초 브랜치 푸시나 PR 생성 시 GitHub 인증 화면이 표시되면 인증을 완료하세요. 기업의 제한된 인증 브라우저나 하드웨어 키 때문에 Make 안에서 인증이 끝나지 않으면 조직 관리자와 지원 가능한 인증 경로를 확인해야 합니다.
첫 성공 기준은 자동 배포가 아닙니다. 실제 저장소의 앱이 미리보기에서 실행되고, 별도 브랜치에 의도한 범위의 커밋이 생기며, 변경 파일·영향 화면·접근성 의도를 엔지니어가 검토할 수 있는 GitHub PR이 열린 상태면 충분합니다.
PR은 접근성 검증의 시작점입니다
MOSF 샘플이 실제 키보드 전용 탐색이나 특정 스크린리더, 자동화된 WCAG 검사까지 통과했는지는 공개되지 않았습니다. 코드에 적절한 속성이 들어갔거나 합성 페르소나가 문제를 찾았다는 사실만으로 실제 사용성이 증명되지는 않아요.
병합 조건을 별도로 정하세요. 엔지니어의 코드 리뷰와 기존 CI를 통과한 뒤, 변경 지점을 키보드만으로 조작하고 팀이 지원하는 스크린리더로 읽어보세요. 공유 컴포넌트라면 대표 사용 화면도 함께 확인해야 합니다.
이 방식의 현실적인 가치는 디자이너가 엔지니어를 대체하는 데 있지 않습니다. 디자이너는 의도가 명확한 작은 UI 수정을 실행 가능한 변경으로 제안하고, 엔지니어는 실행 환경과 코드 구조, 품질 기준, 병합 결정을 책임집니다. 접근성 티켓이 오래 밀리는 팀이라면 권한을 한꺼번에 넓히기보다 작은 변경 한 건을 이 경계 안에서 PR까지 보내보세요.
