Figma Make 로컬 코드를 Windows에서 다뤄야 한다면, 이번 주에는 먼저 웹 버전으로 원형을 만들고 검토한 뒤 대표 저장소 하나만 원격 Mac에서 확인하는 순서가 안전합니다. 원형 링크와 댓글만 필요하면 Windows 웹 브라우저를 선택하고, 로컬 코드 편집이나 병합 요청까지 필요하면 Mac 데스크톱 환경을 준비해야 합니다.
이 글은 Windows를 주력으로 쓰는 제품 디자이너, 디자인 엔지니어, 자유 계약자와 소규모 팀을 위한 판단 기준입니다. 원형 제작과 실제 코드 저장소 작업을 같은 기능으로 오해하지 않도록 역할별로 나눕니다.
업데이트 기준: 2026년 9월 21일. 플랫폼과 기능 범위는 Figma Make 공식 제품 안내, 공식 로컬 코드 발표, 관련 도움말을 기준으로 확인했습니다. 베타 접근 권한과 팀 저장소 권한은 계정마다 다를 수 있습니다.
먼저 나눠야 할 두 가지 작업
Figma Make에는 브라우저에서 진행하는 인터랙티브 원형 작업과 로컬 코드 환경으로 이어지는 작업이 있습니다. 디자인 맥락을 넣어 화면을 만들고 동작을 검토하는 일은 웹 브라우저에서 진행할 수 있습니다. 공식 안내도 Figma Make를 디자인 맥락에서 인터랙티브 원형을 생성하고 편집하는 기능으로 설명합니다.
반면 로컬 코드 편집은 별도 경계가 있습니다. 2026년 5월 28일 공식 발표는 로컬 코드 편집, 주석, 채팅, 병합 요청 생성을 Mac 베타 데스크톱 앱의 첫 지원 대상으로 설명했습니다. 이후 다른 플랫폼으로 확대할 계획이 언급되었지만, 이것을 Windows 정식 지원으로 해석하면 안 됩니다.
Figma Make의 로컬 코드 설정 안내에서도 저장소와 개발 환경을 연결하는 별도 절차를 다룹니다. 따라서 “Figma가 Windows 브라우저에서 열린다”와 “Windows에서 로컬 저장소를 완전하게 편집한다”는 서로 다른 판단입니다.
이번 주에 확인할 항목은 다음과 같습니다.
- 원형 링크만 전달하면 되는가
- 팀 검토용 댓글과 디자인 결정 기록이 필요한가
- 실제 저장소 파일을 열고 수정해야 하는가
- 변경 사항을 검토 요청 또는 병합 요청으로 넘겨야 하는가
- 베타 앱과 저장소 권한을 실제 계정에서 사용할 수 있는가
웹 버전과 Mac 환경의 책임 범위
웹 브라우저가 충분한 제품 디자이너
페이지 생성, 화면 전환, 컴포넌트 맥락 확인, 팀 댓글이 주된 업무라면 Windows 웹 브라우저가 우선입니다. 이 경우 결과물은 공유 가능한 원형 링크나 검토 기록입니다. 로컬 저장소에 파일을 쓰는 일이 없으므로 Mac을 추가해도 핵심 산출물이 달라지지 않습니다.
Figma Make의 댓글 기능은 공식 댓글 도움말에서 별도로 안내됩니다. 댓글을 보고 수정 방향을 정하는 역할과 실제 코드를 관리하는 역할은 분리할 수 있습니다.
다음 조건이면 원격 Mac을 먼저 선택하지 않아도 됩니다.
- 원형 링크가 최종 납품물입니다.
- 개발자가 코드를 별도 환경에서 관리합니다.
- 로컬 저장소를 열거나 인증할 필요가 없습니다.
- 디자인 검토와 댓글 동기화만 필요합니다.
이 흐름에서 원격 Mac을 추가하면 로그인 단계, 원격 연결, 파일 위치 확인이라는 관리 항목만 늘어날 수 있습니다. 디자인 검토가 목적이라면 웹 버전이 더 단순합니다.
로컬 코드까지 책임지는 디자인 엔지니어
디자인을 코드로 넘기는 역할이라면 판단이 달라집니다. Figma Make 안의 코드 화면은 실제 팀 저장소와 같지 않습니다. 실제 저장소에는 브랜치, 인증, 패키지, 환경 변수, 검사 도구와 배포 규칙이 연결됩니다.
Mac 데스크톱 앱을 사용하더라도 다음 조건을 각각 확인해야 합니다.
- 베타 앱에 접근할 수 있는 계정인가
- 팀 저장소를 읽고 수정할 권한이 있는가
- 로컬 개발 도구가 해당 프로젝트와 맞는가
- 변경 내용을 검토 요청으로 보낼 수 있는가
- 팀의 병합 규칙과 배포 절차를 따를 수 있는가
Figma Make 로컬 코드의 기본 사용법은 기능 사용과 설정 조건을 구분해 설명합니다. 또 설정 문제와 해결 방법은 연결 과정에서 생길 수 있는 문제를 별도로 다룹니다.
Windows 브라우저는 이 과정의 디자인 토론에 참여할 수 있습니다. 그러나 브라우저 접속만으로 로컬 저장소 편집, 변경 제출, 병합 요청까지 보장된다고 보면 안 됩니다.
역할별 선택 기준
1. 원형 링크가 필요한 경우
선택은 Windows 웹 브라우저입니다.
이 경우 검수할 것은 화면 생성과 동작입니다. 컴포넌트 맥락이 원하는 결과에 반영되는지, 팀원이 링크를 열 수 있는지, 댓글이 작업 결정으로 남는지를 확인합니다. 코드를 직접 전달할 책임이 없다면 Mac 환경은 필수가 아닙니다.
2. 원형과 디자인 검토를 반복하는 경우
선택은 웹 버전 중심의 이중 흐름입니다.
디자이너는 Windows에서 원형과 댓글을 관리합니다. 개발 담당자는 별도 개발 환경에서 구현합니다. 이때 Figma Make의 결과를 최종 코드로 간주하지 말고, 화면 규칙과 상호작용 의도를 전달하는 참고 자료로 취급해야 합니다.
3. 편집 가능한 코드를 직접 확인하는 경우
선택은 Mac 데스크톱 환경 검증입니다.
Mac을 직접 보유하지 않았다면 원격 Mac으로 대표 프로젝트를 먼저 확인할 수 있습니다. 원격 Mac은 물리적으로 같은 책상에 있는 개발 기기가 아닙니다. 연결 지연, 세션 종료, 인증 만료, 클립보드와 파일 이동 제한이 작업에 영향을 줄 수 있습니다.
원격 Mac의 디자인 작업과 파일 권한 기준을 먼저 확인하고, 저장소의 민감한 파일을 원격 환경에 둘 수 있는지 팀 규칙을 점검해야 합니다.
4. 병합 요청까지 책임지는 경우
선택은 Mac 환경과 팀 개발 절차의 동시 검증입니다.
Figma Make의 로컬 코드 흐름에서 병합 요청 생성이 가능하더라도, 실제 병합은 팀 권한과 검토 규칙에 달려 있습니다. 승인자가 없는 개인 저장소와 보호된 팀 저장소는 결과가 다릅니다. 코드가 생성되었다는 사실도 품질 검사와 배포 가능성을 의미하지 않습니다.
경험상 주의할 점: 베타 기능의 표시 여부, 저장소 인증, 팀 권한은 같은 조직 안에서도 계정별로 다를 수 있습니다. 한 사람의 성공 사례를 모든 디자이너의 사용 가능 조건으로 확대하지 않는 편이 안전합니다.
자유 계약자와 소규모 팀의 운영 분기
며칠짜리 원형 프로젝트
원형과 검토 링크가 납품물이라면 Windows 웹 버전으로 시작합니다. 프로젝트가 끝난 뒤에도 코드를 관리하지 않는다면 원격 Mac을 유지할 이유가 약합니다.
이때 계약서에는 원형 링크, 화면 범위, 댓글 반영 범위를 명확히 적는 것이 좋습니다. “코드 제공”이 포함되어 있다면 웹 원형과 실제 저장소 변경을 별도 산출물로 나눠야 합니다.
몇 주 동안 반복되는 개발 협업
매주 원형을 수정하고 개발자가 저장소와 대조한다면 대표 프로젝트 하나를 정해 원격 Mac을 시험합니다. 다음 순서로 확인합니다.
- Windows 브라우저에서 디자인 맥락을 넣고 원형을 만듭니다.
- 팀원이 원형 링크와 댓글을 확인합니다.
- 원격 Mac에서 베타 데스크톱 앱 접근 여부를 확인합니다.
- 테스트 저장소를 연결하고 읽기 권한부터 검증합니다.
- 작은 변경을 만들어 실제 파일에 반영되는지 확인합니다.
- 주석과 채팅이 팀 검토 흐름에 남는지 확인합니다.
- 변경 제출과 병합 요청 생성 단계에서 권한 오류를 확인합니다.
- 세션을 끊었다가 다시 연결해 파일 상태와 인증 상태를 재검토합니다.
이 절차에서 한 단계라도 막히면 “Figma Make가 Windows에서 된다”가 아니라 “원형 단계까지만 된다”라고 기록해야 합니다.
장기적으로 저장소를 관리하는 팀
매일 코드 저장소를 열고 로컬 도구를 실행해야 한다면 원격 Mac만으로 장기 운영을 결정하지 않는 편이 좋습니다. 파일 책임, 계정 보안, 연결 안정성, 개발 도구 설치, 팀의 물리적 접근 정책을 함께 검토해야 합니다.
소규모 팀이 단기 프로젝트를 검증할 때는 Mac 미니 대여 비용 안내에서 가능한 운영 방식을 확인할 수 있습니다. 다만 장기간 고정 작업량이 있고 물리 장치나 지속적인 로컬 개발 환경이 필요하다면 직접 보유하는 Mac과 비교해야 합니다.
이달의 선택 체크리스트
아래 항목을 순서대로 체크하면 플랫폼 이름보다 최종 산출물에 맞춰 결정할 수 있습니다.
-
[ ] 최종 결과가 원형 링크인가
→ Windows 웹 버전부터 사용합니다. -
[ ] 최종 결과가 검토 가능한 디자인과 댓글 기록인가
→ 웹 버전으로 협업하고 코드 책임은 개발 환경과 분리합니다. -
[ ] 실제 코드 파일을 읽고 수정해야 하는가
→ Mac 데스크톱 앱의 베타 접근과 저장소 권한을 확인합니다. -
[ ] 변경 사항을 팀 검토 요청이나 병합 요청으로 보내야 하는가
→ 원격 Mac에서 대표 저장소 하나로 전체 흐름을 검증합니다. -
[ ] 매일 로컬 도구와 저장소를 관리하는가
→ 원격 Mac을 임시 검증 수단으로 보고 고정 Mac 환경도 비교합니다. -
[ ] 계정이 베타 대상인지 확실하지 않은가
→ 구매나 장기 계약 전에 실제 계정으로 기능 표시부터 확인합니다.
판단을 한 줄로 줄이면 다음과 같습니다.
- 원형 링크: Windows 웹 버전
- 검토용 디자인: Windows 웹 버전 중심
- 편집 가능한 코드: Mac 데스크톱 환경 검증
- 병합 요청: Mac 베타, 저장소 권한, 팀 절차를 함께 확인
자주 묻는 판단의 경계
FAQ에서 설명한 것처럼 Windows 브라우저는 원형 제작과 협업에 적합합니다. 로컬 코드 작업은 Mac 베타 데스크톱 앱과 저장소 조건을 별도로 확인해야 합니다. 베타 기능은 모든 계정에 자동으로 열리는 기능이 아니며, 원격 Mac도 팀 권한이나 코드 품질 검사를 대신하지 않습니다.
현재 Windows 웹 브라우저 방식의 단점은 분명합니다. 로컬 저장소에 직접 연결하기 어렵고, 데스크톱 베타 기능과 화면이 같다고 보장할 수 없으며, 코드 인증과 개발 도구를 한곳에서 관리하기 어렵습니다. 반대로 원격 Mac을 빌리면 장비를 바로 구매하지 않고 대표 프로젝트를 검증할 수 있고, Windows에서 접근할 수 없는 Mac 기반 작업 흐름을 시험할 수 있습니다.
따라서 이번 주에는 원형만 필요한 프로젝트를 웹 버전으로 끝내고, 로컬 코드가 납품 범위에 들어간 대표 프로젝트 하나만 MESHLAUNCH의 원격 Mac에서 검증하는 방식이 합리적입니다. 검증 뒤에도 매일 코드 저장소를 관리한다면 고정 Mac을 평가하고, 간헐적인 작업이라면 단기 원격 환경을 유지하는 편이 부담이 적습니다. 시작 전에는 MESHLAUNCH의 Mac 원격 사용 환경에서 파일, 권한, 연결 방식을 함께 확인하시기 바랍니다.