Figma Make 로컬 코드로 PR 제출하는 법? 2026 디자이너 작업 흐름

Figma Make의 로컬 코드 기능은 기존 웹 코드 저장소를 열어 화면을 수정하는 작업 흐름입니다. 새 앱을 처음부터 만들거나 서버와 기반 시설을 운영하는 안내는 아닙니다. 현재 공식 도움말은 이 기능을 점진적으로 공개하는 베타로 안내하며, 허용된 계정과 맥용 베타 데스크톱 앱, Git 저장소 접근을 요구합니다. 자격이 자동으로 주어지거나 윈도우 앱만으로 같은 작업을 할 수 있다고 전제하지 마세요.

판단은 간단합니다. 세 항목 중 하나라도 확인되지 않으면 먼저 담당자에게 권한과 환경을 요청하세요. 앱에서 오류가 난다고 곧바로 디자인 변경의 문제라고 볼 수는 없습니다.

먼저 저장소가 무엇인지 확인합니다. 저장소는 웹 프로젝트의 코드와 변경 기록을 보관하는 공간입니다. 엔지니어가 프로젝트에 필요한 설정을 마친 뒤, 로컬에 있는 저장소를 열거나 원격 저장소를 복제해 작업을 시작합니다. 연결 전에는 대상 프로젝트와 수정 범위를 팀과 맞추세요. Figma 로컬 코드 설정 문서는 저장소 준비와 프로젝트 열기 절차를 안내합니다.

플랫폼마다 PR을 만드는 위치가 같지는 않습니다. 공식 안내에서 확인되는 차이는 다음과 같습니다.

GitLab의 용어는 병합 요청이며, GitHub와 Bitbucket에서 흔히 쓰는 pull request와 비슷한 검토 절차입니다. GitLab의 병합 요청 안내와 Bitbucket의 pull request 안내에 따라 해당 플랫폼에서 제출하세요. 세 플랫폼을 모두 앱 안에서 같은 방식으로 처리할 수 있다고 생각하면 안 됩니다.

시작 전에 아래 항목을 체크하세요.

• [ ] 계정에서 Figma Make 로컬 코드 기능을 사용할 수 있습니다.
• [ ] 맥용 베타 데스크톱 앱을 실행하고 로그인할 수 있습니다.
• [ ] 수정할 웹 저장소와 작업 브랜치를 확인했습니다.
• [ ] 저장소를 열거나 복제할 권한이 있습니다.
• [ ] 수정할 화면과 변경 범위를 팀과 합의했습니다.
• [ ] 프로젝트 설정이나 의존성 설치가 필요하면 엔지니어가 준비했습니다.

여기서 말하는 의존성은 프로젝트가 실행될 때 필요한 코드나 도구입니다. 설치나 개발 서버 실행에서 막히면 화면 설명을 반복해서 바꾸기 전에 저장소 권한, 프로젝트 안내, 실행 설정을 확인하세요. 설정 문제와 해결 안내는 설정 과정에서 생길 수 있는 문제를 다룹니다.

주의: 베타 접근은 기능 이용 자격을 뜻할 뿐입니다. 자동으로 코드가 올바르게 바뀌거나 PR이 승인되고 서비스에 반영된다는 보장은 없습니다.

저장소 연결은 보통 두 경로로 시작합니다. 이미 작업 기기에 프로젝트가 있다면 해당 로컬 저장소를 엽니다. 원격 저장소에서 시작해야 한다면 접근 권한을 확인한 뒤 복제합니다. 프로젝트를 연 다음 미리보기를 실행하고, 수정하려는 화면이 실제 대상 코드에서 나온 것인지 확인하세요.

화면이 뜨지 않거나 다른 페이지가 표시되면 아래 순서로 점검합니다.

• 저장소 주소와 프로젝트 폴더가 맞는지 확인합니다.
• 계정에 저장소 접근 권한이 있는지 확인합니다.
• 프로젝트 실행에 필요한 설정과 의존성이 준비됐는지 확인합니다.
• 개발 서버가 실행 중인지, 미리보기가 올바른 주소를 여는지 확인합니다.

이 단계가 통과되기 전에는 디자인 수정 결과를 평가하지 마세요. 잘못된 프로젝트 미리보기는 디자인 변경이 실패한 것처럼 보이게 할 수 있습니다.

첫 작업은 범위가 분명한 UI 변경으로 제한합니다. 예를 들어 특정 화면의 문구, 여백, 버튼 모양처럼 담당자가 결과를 쉽게 확인할 수 있는 항목부터 요청합니다. 속성 패널이나 화면 표시, 자연어 설명을 활용하더라도 한 번에 넓은 범위의 수정을 요구하지 않는 편이 검토하기 쉽습니다.

미리보기만 보고 완료 처리하지 마세요. 수정 전후 화면을 비교하고, 실제 코드 변경이 요청한 화면과 관련된 것인지 확인합니다. 색상이나 간격이 달라졌더라도 공통 디자인 규칙을 어겼거나 다른 화면까지 영향을 줬을 수 있습니다. Figma의 Make 작업 흐름 사례는 디자인 작업을 실제 배포 흐름과 연결하는 사례를 다루지만, 팀의 코드 검토를 생략해도 된다는 뜻은 아닙니다.

브랜치는 기존 작업을 직접 덮어쓰지 않고 변경 내용을 분리해 두는 작업 줄기입니다. 커밋은 특정 변경 상태를 기록하는 단위입니다. 제출 전에는 변경 파일과 차이를 검토하고, 프로젝트에서 정한 확인 작업을 실행합니다. 테스트 명령을 모르는 경우 임의로 정하지 말고 팀에 확인하세요.

GitHub에서는 앱에서 PR 생성을 진행할 수 있지만, 요청이 만들어진 뒤에도 팀의 검토가 필요합니다. GitHub의 PR 검토 안내를 참고해 담당자가 제안된 변경을 확인하도록 하세요. GitLab과 Bitbucket은 앞서 설명한 대로 각 웹 플랫폼에서 요청을 마무리합니다.

결정 조건은 다음과 같습니다.

• 계정 자격, 맥용 베타 앱, 저장소 권한이 모두 준비됐다면 기존 웹 프로젝트의 작은 화면 변경부터 진행합니다.
• 권한이 없거나 대상 저장소가 불분명하다면 코드를 수정하지 말고 저장소 담당자에게 확인합니다.
• 목표가 새 앱 개발, 백엔드 작업 또는 기반 시설 변경이라면 이 흐름을 기본 절차로 삼지 말고 엔지니어와 작업 방식을 정합니다.
• PR을 만들었더라도 담당자의 검토와 팀의 배포 절차가 남아 있다면 병합된 것으로 간주하지 않습니다.

윈도우 컴퓨터만 있고 맥용 베타 앱이 필요한 경우, 원격 맥은 해당 앱을 사용할 맥 환경이 필요한 작업에 검토할 수 있습니다. 다만 원격 맥이 Figma 계정의 테스트 권한을 만들어 주거나 저장소 접근 권한을 대신 얻어 주지는 않습니다. 연결 품질과 앱 이용 가능 여부도 실제 환경에서 확인해야 하며, 이 글에서는 MESHLAUNCH의 대표 프로젝트 실측 자료가 제공되지 않아 성능이나 파일 전달 결과를 단정하지 않습니다.

현재 윈도우 환경만으로 진행하면 맥용 앱이 필요한 단계에서 멈출 수 있고, 브라우저의 디자인 편집과 로컬 코드 작업을 혼동하기 쉽습니다. 반대로 맥을 새로 구매하면 간헐적인 테스트 작업에도 기기 비용과 관리가 따라옵니다. 원격 맥은 짧은 기간 맥 앱이 필요한 경우의 대안이 될 수 있지만, 장기간 매일 쓰는 무거운 작업이나 물리 장치 연결이 필요한 환경에는 고정된 로컬 맥이 더 알맞을 수 있습니다.

먼저 테스트 자격과 저장소 권한을 확인하세요. 두 조건이 갖춰졌고 작업에 맥용 베타 앱이 필요하다면 MESHLAUNCH의 맥 미니 대여 가격 안내에서 조건을 살펴보세요. 이용 지역과 신청 조건은 한국 이용 안내에서도 확인할 수 있습니다. 원격 맥은 작업 환경을 제공하는 선택지이지, 자격 승인이나 코드 리뷰를 대신하는 방법은 아닙니다.