피그마 GitHub 조직 여러 개 연결: 지원 플랜과 저장소 권한 확인

두 조직 연결과 두 저장소 연결을 먼저 구분하세요

아래는 본문의 공식 조건을 실제 작업으로 연결한 편집부 판단표입니다. 계정에서 확인한 결과가 아니므로 자신의 환경에서 조건과 증거를 기록하세요.

이 글의 실무 점검표 CSV 다운로드 — 설정·기대값·실제 결과·증거·후속 작업을 따로 기록하는 빈 양식입니다. 제품 지원 상태나 시험 성공을 증명하는 자료는 아닙니다.

Figma GitHub 조직 여러 개 연결: 지원 플랜 비교

Figma는 2026년 10월 5일 한 플랜에 여러 GitHub 조직 연결을 지원한다고 발표했습니다. 팀마다 GitHub 조직이 다르더라도 공유 디자인 시스템을 한곳에서 관리하는 상황을 위한 변화입니다. 여러 조직을 하나로 병합한다는 의미는 아닙니다. 근거: 10월 5일 공식 릴리스 노트

공식 관리 문서는 GitHub Enterprise Server(GHES)를 지원하지 않는다고 명시합니다. “Figma Enterprise를 쓰니 사내 GitHub Server도 연결된다”고 판단하면 안 됩니다. 플랜 가격과 계약 조건은 구매 시점에 따로 확인하세요. 근거: 플랜별 연결 제한·GHES 지원 범위

조직 연결 수·저장소 수·좌석 조건은 다릅니다

먼저 무엇을 연결하려는지 정하세요. “GitHub 조직 두 개”, “같은 조직의 저장소 두 개”, “라이브러리의 컴포넌트를 코드와 매핑”은 서로 다른 작업입니다. 조직 연결이 끝났다고 모든 저장소가 자동으로 라이브러리에 매핑되지는 않습니다.

Code Connect UI는 Organization·Enterprise의 Dev 또는 Full 좌석에서 사용하며, 발행된 디자인 컴포넌트가 있는 Figma 라이브러리 파일이 필요합니다. GitHub 연결 없이 코드 경로를 직접 입력해 매핑할 수도 있습니다. GitHub 연결은 경로 자동완성·코드 탐색을 더하는 선택 사항입니다. 근거: Code Connect UI 플랜·좌석·라이브러리 조건

라이브러리의 Code Connect UI에서 GitHub에 연결하려면 해당 파일 소유자 또는 조직 관리자여야 합니다. 인증 후 저장소를 선택하고 목록 위의 +로 여러 저장소를 추가할 수 있습니다. 매핑은 코드 구현의 참조를 MCP에 제공하며, 저장소 연결 자체가 완성된 애플리케이션을 생성하는 것은 아닙니다. 근거: 라이브러리 파일 연결·저장소 추가

연결 전에 Figma 관리자와 GitHub 승인 담당자를 확인하세요

Figma GitHub 앱의 팀·조직 연결 관리 작업은 Figma 관리자 권한이 필요합니다. Organization·Enterprise에서는 Admin → Settings → Resources → Figma GitHub app → Connect GitHub에서 설치 흐름을 시작합니다. 연결할 GitHub 조직을 선택하고 요청 권한과 저장소 범위를 검토하세요. 근거: 관리자 연결 경로

GitHub에서는 조직 소유자가 앱을 설치할 수 있습니다. 저장소 관리자의 설치 권한은 앱이 요구하는 권한과 조직 정책에 따라 달라집니다. 앱이 조직 권한이나 Repository administration을 요청하면 저장소 관리자만으로 설치할 수 있는 일반 예외가 적용되지 않습니다. 설치 권한이 없는 구성원은 소유자에게 요청하는 흐름이 될 수 있습니다.

또한 앱 설치와 사용자 인증은 별개입니다. 설치는 조직·저장소에 앱의 접근 범위를 부여하고, 사용자 인증은 앱이 사용자를 대신해 요청할 수 있게 합니다. 로그인에 성공했더라도 대상 조직에 앱이 설치되지 않았거나 저장소가 선택되지 않았다면 충분하지 않습니다. 근거: 설치 역할·승인·사용자 인증 구분

Figma GitHub 앱은 읽기 전용인가요?

읽기 전용 앱으로 간주하면 안 됩니다. Figma의 권한 개요는 Code Connect와 Make가 사용하는 공통 앱의 요청 권한을 설명합니다. Code Connect만 쓰려는 경우에도 설치 화면에서 실제 요청 권한을 확인해야 합니다.

GitHub의 인증 화면에서는 API의 Contents 권한이 Code로 표시됩니다. 위 표의 “개발 중”은 현재 사용자 기능이 모두 제공된다는 뜻이 아닙니다. 사용자 액세스 토큰의 유효 권한은 사용자 접근권과 앱에 부여된 권한의 교집합이며, 앱이 사용자의 권한을 늘려주지는 않습니다. 근거: Figma GitHub 앱 권한 개요

All repositories와 Only select repositories 선택 기준

GitHub 앱 설치 시 전체 저장소 또는 선택한 저장소에 접근을 부여할 수 있습니다. 여러 조직 연결도 조직별 설치와 저장소 선택을 없애지는 않습니다. 먼저 필요한 디자인 시스템 저장소만 선정하고, 새 조직을 연결할 때마다 설치 범위를 확인하는 방식이 관리하기 쉽습니다.

아래는 편집부가 제안하는 검토표입니다. 기능 활성화를 확인한 결과가 아니라 설치 범위를 정리하기 위한 빈 기준입니다.

비공개 저장소가 목록에 없다고 바로 전체 저장소 접근으로 바꾸지 마세요. 잘못된 GitHub 계정, 조직 설치 누락, 선택 범위 누락, 사용자 접근권을 순서대로 확인하면 불필요하게 접근 범위를 넓히지 않고 원인을 찾을 수 있습니다.

Figma Make와 Code Connect 연결 설명이 다를 때

확인일 기준 Make 도움말에는 “여러 GitHub 계정·조직 연결 불가”라는 기존 문장이 남아 있습니다. 반면 10월 5일 릴리스 노트와 관리자 연결 문서는 Organization·Enterprise의 다중 연결을 명시합니다. 다중 조직 지원은 최신 발표와 관리자 문서를 기준으로 설명하되, Make에서 실제 선택 가능한 대상은 관리자 화면과 지원팀에 확인해야 합니다. 문서 불일치만으로 모든 Make 동작이 변경됐다고 단정하지 않습니다.

Make 문서는 기존 저장소로의 임의 push나 양방향 동기화를 지원한다고 설명하지 않습니다. Make가 생성한 저장소에 한 방향으로 push하며, GitHub에서 고친 코드는 Make에 반영되지 않고 다음 push에서 덮어써질 수 있다고 안내합니다. Code Connect의 기존 저장소 코드 참조와 같은 기능으로 취급하지 마세요. 근거: Make 문서의 연결 설명·push 제한

두 번째 조직이 연결되지 않을 때 점검 순서

1. 현재 Figma 플랜: 연결을 시도하는 팀·조직의 플랜을 확인합니다. 개인이 다른 곳에서 유료 좌석을 쓰는 사실과 이 플랜의 연결 자격은 구분합니다.
2. 목적과 역할: 관리자 연결 작업인지 라이브러리의 Code Connect 작업인지 정하고, 필요한 역할·좌석을 확인합니다.
3. 로그인 계정: 대상 GitHub 조직에 속한 계정으로 로그인했는지 확인합니다.
4. 앱 설치 승인: 대상 조직의 설치가 완료됐는지, 소유자 승인 요청이 남아 있는지 확인합니다.
5. 저장소 선택: 설치 범위에 대상 저장소가 있는지, 사용자가 그 저장소에 접근 가능한지 확인합니다.
6. 연결 결과: 조직 연결 완료와 라이브러리에서 저장소를 선택한 결과를 따로 기록합니다.
7. 오류 증거: 발생 시간, 플랜, 수행 단계, 오류 문구를 남겨 지원팀에 전달합니다. 토큰이나 비공개 코드 전체를 첨부하지 않습니다.

위 순서는 공식 조건을 실무 점검으로 정리한 편집부 제안입니다. 계정의 실제 연결 상태를 확인하지 않았다면 성공으로 기록하지 말고 미확인으로 남기세요. 연결을 해제하기 전에는 기존 라이브러리와 Make 작업에 미칠 영향을 먼저 정리하는 것이 좋습니다.

자주 묻는 질문

Professional에서도 GitHub 저장소를 여러 개 연결할 수 있나요?

조직·계정 연결 개수와 제품별 저장소 사용 조건을 분리해야 합니다. Professional의 조직·계정 연결은 한 개이고, Code Connect UI에는 Organization·Enterprise 및 Dev·Full 좌석 조건이 있습니다. “같은 조직의 저장소 여러 개”라는 설명만으로 Professional의 Code Connect 사용을 판단하지 마세요.

디자인 시스템을 여러 GitHub 조직과 연결하면 무엇이 좋아지나요?

예를 들어 웹과 모바일 구현을 서로 다른 조직에서 관리할 때 연결 대상을 각각 등록하고, 디자인 라이브러리의 컴포넌트와 코드 참조를 정리할 수 있습니다. 이 예시는 활용 시나리오이며 고객 사례나 직접 사용 성과를 주장하지 않습니다.

연결하면 GitHub 권한이 없는 동료도 모든 코드를 볼 수 있나요?

연결 개수 확대는 접근권을 일괄 부여한다는 뜻이 아닙니다. 앱 설치 범위와 사용자 접근권을 확인하고, 라이브러리·MCP에 전달되는 코드 참조를 공유할 때도 조직의 정보 공유 기준을 검토하세요.

이 글의 확인일은 2026년 10월 9일입니다. 플랜 제한, 요청 권한과 Make 문서의 정합성이 바뀌면 연결된 공식 자료를 다시 대조해야 합니다. 개발 자동화까지 이어갈 때는 GitHub Actions PR 검증 가이드에서 별도의 테스트·권한 경계를 확인하세요.