Figma Code Layers Beta, 작동하는 프로토타입에 공동 탐색 기능 추가
Figma는 code layers beta가 이제 전체 사용자의 100%에게 제공되며, 팀이 이미 디자인을 검토하는 캔버스에서 바로 작동하는 프로토타입을 활용할 수 있다고 밝혔다. 실행 중인 코드를 기반으로 하는 인터랙티브 프로토타입인 code layers는 디자이너가 외형과 함께 동작을 비교할 수 있는 공유 공간을 제공한다. 이번 변화는 익숙한 워크플로에 압박을 가한다. 다른 곳에서 실험을 구축한 뒤, 모두가 평가할 수 있도록 링크를 다시 가져오는 방식이다.
이번 발표는 완전히 새로운 출시라기보다 더 폭넓은 제공에 관한 내용이다. Figma의 11월 4일 워크플로 게시물은 전체 배포를 설명하며, 문서에는 최초 오픈 베타 날짜가 2026년 10월 15일로 명시되어 있다. 이 차이는 중요하다. 즉각적인 질문이 접근성에서 유용성으로 옮겨갔기 때문이다. 이제 팀은 공유 캔버스가 디자인과 구현 사이의 또 다른 경로를 정당화할 만큼 의사결정을 개선하는지 평가할 수 있다.
Framer는 이미 캔버스에서 코드 컴포넌트를 제공하므로, 시각적 작업 공간 안에서 실행 중인 코드를 다루는 일 자체가 새로운 것은 아니다. Figma의 제안은 협업적 탐색에 초점을 맞춘다. 구현을 확정하기 전에 대안을 보존하고, 외형을 편집하며, 아이디어를 결합하는 것이다. 핵심 긴장은 프로토타입을 더 쉽게 논의할 수 있게 만드는 것과 그 기반 변경 사항을 출시 가능한 상태로 만드는 것 사이에 있다.
Figma Code Layers Beta, 공유 검토 영역 확대
의미 있는 변화는 작동하는 실험이 주변 디자인과 같은 검토 공간의 일부가 될 수 있다는 점이다.
Figma는 code layers workflow에서 코드를 가져오고, 대안을 생성하며, 추출한 디자인을 다듬고, 탐색 결과를 결합하는 과정을 설명한다. 디자인 파일 내부의 대화형 AI 어시스턴트인 Figma agent는 이러한 변경을 수행하는 데 도움을 준다. 이 게시물은 디자이너가 기존 지도 경험과 함께 배송 주소 선택 방식을 탐색하는 Pickup이라는 가상의 마켓플레이스를 제시한다.
가상의 사례는 결과를 입증하지 않고도 워크플로를 설명할 수 있다. Pickup은 Figma가 의도한 순서를 이해하는 데 유용하지만, 독립적으로 측정된 배포 사례로 오해해서는 안 된다. 이번 발표는 모든 팀이 개발 주기를 단축하거나 더 나은 인터페이스를 만들 것이라고 결론 내릴 근거를 제공하지 않는다.
그럼에도 실험의 배치는 검토자가 논의할 수 있는 내용을 바꾼다. 스크린샷은 특정 시점의 외형을 포착한다. 작동하는 프로토타입에서는 누군가 상호작용을 테스트하고, 주변 디자인으로 돌아가며, 더 넓은 시각적 맥락을 잃지 않고 다른 방향과 비교할 수 있다.
주소 선택기를 두고 의견이 갈리는 검토 상황을 생각해 보자. 보기 좋은 레이아웃은 누군가 위치를 선택한 뒤의 어색한 전환을 감출 수 있다. 반대로 시각적으로 평범한 대안이 과업을 더 명확하게 만들 수도 있다. 동작을 외형 옆에 배치하면 논의에 더 직접적인 근거가 생긴다.
그렇다고 피드백이 자동으로 더 정확해지는 것은 아니다. 검토자는 무엇을 테스트했는지 식별하고, 그 차이가 왜 중요한지 설명해야 한다. 아무도 목적을 표시하지 않는다면, 작동하는 대안으로 가득한 캔버스는 프로토타입 링크로 가득한 폴더만큼 혼란스러워질 수 있다.
기회는 실험과 함께 질문을 계속 보이게 하는 데 있다. 한 변형은 사람들이 진입 지점을 이해하는지 시험할 수 있다. 다른 변형은 확인 전에 어느 정도의 정보가 필요한지 시험할 수 있다. 두 프로토타입이 비슷한 화면을 포함하더라도, 이는 서로 다른 제품 질문이다.
이 구분은 생성된 결과물이 곧 의사결정이 되는 것을 막는 데도 도움이 된다. 에이전트는 그럴듯한 대안을 제시할 수 있지만, 어느 대안이 사용자에게 가장 적합한지는 확정하지 못한다. 팀은 평가 기준을 선택하고 부족한 근거를 식별할 책임을 계속 진다.
따라서 배포를 평가하는 독자에게 제공 범위는 출발점이다. 더 중요한 질문은 공유 공간이 이견을 해결하기 쉽게 만드는지다. 모두가 대안을 볼 수 있어도 아무도 선택 이유를 설명할 수 없다면, 워크플로는 옮겨갔을 뿐 더 큰 책임성을 갖게 된 것은 아니다.
Figma code layers beta는 이 질문을 더 넓은 사용자층에게 현실적인 과제로 만든다. 팀은 회사의 워크플로 시연을 검증해야 할 제안으로 다루면서 협업 모델을 직접 평가할 수 있다.
디자이너와 개발자는 더 이른 시점에 정렬 결정을 내려야 한다
공유 프로토타입은 방향을 바꾸는 비용이 아직 비교적 낮은 시점에 일부 구현 논의를 앞당긴다.
Figma의 code layers documentation은 디자인, 프롬프트, 웹페이지 또는 연결된 코드에서 시작하는 방식을 설명한다. 또한 편집 가능한 디자인 레이어를 추출하고, 해당 변경 사항을 code layer로 다시 보내는 기능도 지원한다. 문서는 code layers가 모든 리포지토리에서 작동하지는 않는다고 주의한다.
마지막 제한 사항은 누가 압박을 받는지 정의하는 데 도움이 된다. 디자이너는 상호작용을 구체화할 또 하나의 방법을 얻지만, 개발자는 그 실험이 실제 제품을 얼마나 충실히 반영하는지 판단해야 한다. 제품 관리자는 설득력 있는 시연과 합의된 구현 범위를 구분해야 한다.
더 이른 개발자 참여는 숨겨진 의존성을 드러낼 때 가치가 있다. 프로토타입은 사용자 행동 뒤에 즉각적인 응답이 일어나는 것처럼 보일 수 있다. 실제 제품은 서비스를 기다리거나, 권한을 확인하거나, 로컬에서 사용할 수 없는 정보를 처리해야 할 수 있다.
이는 Figma 기능의 문서화된 실패 사례가 아니라 예시적인 엔지니어링 우려 사항이다. 작동하는 인터페이스가 모든 구현 질문에 답할 수 없는 이유를 설명한다. 프로토타입은 누군가 실험 안에서 경험할 수 있는 것을 보여주는 반면, 프로덕션 검토는 조직이 안정적으로 지원할 수 있는 것을 확립한다.
압박은 검토 프로세스 자체에도 미친다. 디자이너가 작동하는 대안을 회의에 가져올 수 있다면, 더 큰 명확성을 요구하는 모호한 요청은 유지되기 어려워진다. 참가자는 상호작용을 가리키고 어느 부분이 불확실성을 만드는지 설명할 수 있다.
한편 개발자는 같은 논의를 통해 시각적 결정과 아키텍처적 결정을 분리할 수 있다. 버튼 레이블은 즉시 채택할 준비가 되었을 수 있다. 새로운 요청 순서는 더 광범위한 기술 변경을 요구할 수 있다. 이러한 판단을 구분해 두면 유망한 인터페이스가 비현실적인 납기 약속을 떠안는 일을 막을 수 있다.
따라서 Figma agent prototyping은 책임을 바꾸기보다 협업의 시점을 바꾼다. 디자이너는 여전히 디자인 판단을 맡는다. 엔지니어는 여전히 구현을 평가한다. 제품 리더는 제안된 경험이 가치 있는 문제를 해결하는지 계속 결정한다.
참여에 관한 질문도 있다. 프로토타입을 생성하는 사람만 이를 평가하는 방법을 안다면 공유 작업 공간의 가치는 크지 않다. 검토자는 매번 설명을 곁들인 안내를 받지 않아도 관련 동작을 탐색할 수 있을 만큼의 맥락이 필요하다.
조직에 유용한 도입 신호는 검토 후 더 명확한 결정이 내려지는 것이다. 성공적인 세션은 선호하는 방향, 해결되지 않은 가정, 출시 전 필요한 작업을 식별해야 한다. 더 많은 대안을 만드는 일은 그러한 대안이 의사결정을 개선할 때만 유용하다.
기존 워크플로는 실험과 공동 평가를 분리하기 때문에 압박을 받는다. Figma의 접근 방식은 이 활동들을 더 가깝게 가져온다. 이러한 근접성이 재작업을 줄이는지는 각 팀이 자체 프로젝트를 통해 확인해야 할 문제로 남아 있다.
에이전트는 시각적 탐색과 실행 중인 동작을 연결한다
Figma 제안에서 가장 강력한 부분은 주변 논의를 떠나지 않고 동작과 시각적 세부 사항 사이를 오갈 수 있다는 능력이다.
분석적으로 보면 이는 피드백 루프다. 팀은 상호작용을 시도하고, 디자인 문제를 발견하며, 관련 외형을 수정하고, 업데이트된 동작을 평가한다. 핵심은 각 수정이 그 수정을 촉발한 질문과 계속 연결되도록 하는 것이다.
이 구분은 인터페이스 품질이 국소적인 세부 사항과 더 넓은 흐름을 모두 포함하기 때문에 중요하다. 여백은 행동이 가능한 것처럼 보이는지에 영향을 줄 수 있다. 문구는 누군가 선택한 뒤 무엇을 기대하는지 바꿀 수 있다. 전환은 시각적으로 균형 잡힌 화면이 잘못된 시점에 정보를 요구한다는 점을 드러낼 수 있다.
이러한 관심사 사이를 오가는 지점에서 검토는 자주 정확성을 잃는다. 대화는 관찰 가능한 문제에서 시작하지만, 이후 스타일에 대한 일반적인 선호로 바뀐다. 작동하는 경험을 시각적 탐색 가까이에 두면 참가자는 원래의 근거로 돌아갈 방법을 얻는다.
Figma의 고객 자료는 이 해석을 어느 정도 뒷받침한다. customer prototype examples는 Checkout.com 디자이너 Kris Murphy가 화면을 추출해 함께 살펴본 뒤, 시각적 편집 내용을 프로토타입으로 다시 가져간 사례를 설명한다. 같은 모음은 Superside의 Leonardo Rica가 인터랙티브 카드 콘셉트를 탐색할 때 정밀한 측정값과 모션 세부 사항을 제공한 사례도 소개한다.
이는 독립적인 비교가 아니라 Figma가 게시한 실명 고객 사례다. 사람들이 이 기능을 어떻게 사용하고 있는지 보여주지만, 전형적인 결과를 입증하지는 않는다. 여기서 유용한 공통점은 구체성이다. 누군가 무엇을 점검하거나 수정해야 하는지 알 때 워크플로는 더 의미 있어진다.
예를 들어 결제 상호작용을 평가하는 팀은 문구에 대한 불확실성과 탐색에 대한 불확실성을 분리할 수 있다. 둘을 동시에 수정하면 결과가 왜 더 좋아졌는지 이해하기 어려워진다. 비교를 보존하면 논의를 테스트 중인 결정에 집중시키는 데 도움이 될 수 있다.
이는 비교가 주는 분석적 이점이지, Figma가 자동으로 통제된 실험을 수행한다는 주장은 아니다. 팀은 여전히 조건을 충분히 일관되게 유지해야 한다. 서로 다른 샘플 콘텐츠나 누락된 상태는 관련 없는 이유로 한 대안이 더 강해 보이게 할 수 있다.
같은 주의는 탐색 결과를 결합할 때도 적용된다. 매력적인 기능을 함께 가져온다고 해서 결과가 일관성을 유지하는 것은 아니다. 개별적으로 타당한 선택도 탐색, 용어 또는 다음에 일어날 일에 대한 기대를 공유할 때 충돌할 수 있다.
따라서 결합된 프로토타입은 별도의 검토가 필요하다. 구성 요소가 이전에 승인을 받았다는 이유만으로 수용할 것이 아니라, 완전한 경험으로서 평가해야 한다. 더 빠른 생성에도 불구하고 디자인 판단이 핵심으로 남는 지점이다.
Figma agent prototyping은 에이전트가 구체적인 조사를 지원할 때 가장 유용하다. 특정 상호작용을 탐색해 달라는 요청은 팀에 평가 가능한 결과를 남긴다. 전반적으로 더 나은 경험을 요청하면 평가의 너무 많은 부분이 명시되지 않은 채 남는다.
실질적인 함의는 공유 캔버스 탐색이 명확한 의도에 의존한다는 것이다. 실행 중인 코드는 동작을 점검할 수 있게 한다. 어떤 동작이 살아남아야 하는지는 결정하지 않는다.
캔버스 위의 코드는 이미 경쟁 영역이다
캔버스 기반 코드가 이미 다른 곳에 존재하기 때문에, Figma의 경쟁 논거는 팀 검토의 연속성에 기반한다.
Framer의 code components는 JavaScript 라이브러리로 작성된 재사용 가능한 인터페이스 요소인 React 컴포넌트로, 캔버스와 미리보기, 게시된 사이트에서 렌더링된다. 문서는 시각적 속성 제어와 컴포넌트 공유도 설명한다.
이는 제품들을 서로 대체 가능한 것으로 만들지 않으면서도 관련된 역사적 기준점을 제시한다. 웹사이트 빌더를 확장하는 컴포넌트와 제품 디자인 파일 안에서 탐색하는 프로토타입은 목적이 일부 겹치지만 서로 다른 용도를 가진다. 그 가치는 팀이 무엇을 제공하려는지에 따라 달라진다.
공개 웹사이트를 구축하는 팀은 시각적 편집과 최종 사이트 간의 관계를 우선시할 수 있다. 애플리케이션 변경을 탐색하는 제품 팀은 대안, 주변 화면, 그리고 선택한 방향을 설명하는 논의를 더 중시할 수 있다.
어느 요구사항이 본질적으로 더 고급인 것은 아니다. 이들은 서로 다른 종착점을 나타낸다. 도구를 코드 생성 가능 여부만으로 비교하면, 생성 이후 이어지는 작업과 참여해야 하는 사람들을 간과하게 된다.
이로써 Figma의 포지셔닝은 더 명확해진다. Figma의 기회는 공유 디자인 파일을 작동하는 아이디어를 검토하기에 유용한 공간으로 만드는 데 있다. 문제는 그 공간이 코드를 가져오는 수고를 상쇄할 만큼 충분한 맥락을 보존하는지다.
별도의 코딩 환경 역시 인터페이스를 탐색하는 효과적인 공간이 될 수 있다. 엔지니어는 프로젝트 관례와 개발 검증 절차가 이미 마련된 곳에서 실험하는 편을 선호할 수 있다. 디자이너는 자신의 디자인 워크스페이스에서 제공되는 더 넓은 시각적 개요를 선호할 수 있다.
이러한 선호가 시각 도구와 코드 도구 사이의 인위적인 경쟁으로 번져서는 안 된다. 실무적인 쟁점은 특정 결정을 어디에서 명확하게 내릴 수 있는가다. 같은 프로젝트의 서로 다른 단계에서 서로 다른 환경을 사용하는 것은 충분히 합리적이다.
주된 경쟁 상대는 여전히 파편화된 탐색이다. 이러한 파편화는 프로토타입, 주변 디자인, 피드백, 근거를 연결하기 어려워질 때 나타난다. 애플리케이션 전환은 하나의 증상일 뿐이다. 하나의 애플리케이션 안에서도 작업은 단절될 수 있다.
따라서 줄어든 도구 전환 횟수만 세는 것은 불완전한 평가가 된다. 한 팀은 이동 횟수가 줄어드는 대신 현재 버전을 확인하는 데 더 많은 시간을 쓸 수 있다. 다른 팀은 별도 도구를 유지하면서도 근거와 결정 사이의 명확한 연결을 유지할 수 있다.
Figma의 사례가 설명하는 코드 레이어는 공간적인 답을 제시한다. 대안과 논의를 함께 배치하는 것이다. 관계가 눈에 보일 때 공간적 근접성은 도움이 된다. 확장되는 캔버스가 그 관계를 모호하게 만들면 도움이 덜 된다.
그러므로 경쟁 압력은 생성만큼이나 검토 품질과 관련이 있다. Figma는 프로토타입을 내부에서 실행할 수 있을 때 기존 협업 환경이 더 유용해진다는 점을 보여줘야 한다. 경쟁 접근법은 아이디어에서 정당화된 구현 결정으로 이어지는 더 명확한 경로를 팀에 제공하는 곳이라면 여전히 설득력을 가진다.
작동하는 프로토타입에도 코드와 접근 권한 검토가 필요하다
공유 파일 안에서 실행되는 프로토타입은 구현과 가시성 모두에 대한 검토 의무를 만든다.
Figma의 Git integration 문서는 저장소 복제, 브랜치, 풀 리퀘스트와 병합 전 검토를 위해 제출되는 제안 변경 사항을 설명한다. 또한 파일 뷰어는 코드 레이어의 미리보기와 미리보기 소스를 볼 수 있다고 설명한다. 파일 편집자는 해당 GitHub 권한이 없어도 기본 저장소 코드에 접근할 수 있다.
비공개 프로젝트를 가져오기 전에 이 가시성 모델에 주목할 필요가 있다. 관련 대상은 디자인 파일에 접근할 수 있는 그룹이다. 팀은 그 대상이 도입되는 코드의 의도된 대상과 일치하는지 평가해야 한다.
이는 문서화된 접근 특성이며, 보안 사고의 증거는 아니다. 실질적 중요성은 저장소와 공유 방식에 따라 달라진다. 독점 코드를 다루는 조직은 가져오기를 일상적인 디자인 작업으로 취급하기 전에 그 방식을 이해해야 한다.
구현 측면에는 별도의 경계가 있다. Figma는 저장소 검토로 돌아가는 경로를 문서화하지만, 그 경로가 존재한다고 해서 생성된 변경 사항이 올바르다는 뜻은 아니다. 제안된 변경 사항은 여전히 프로젝트 요구사항에 따라 평가되어야 한다.
주소 선택 기능의 경우, 검토자는 사용할 수 없는 위치를 어떻게 처리하는지 또는 요청 실패 후에도 확인 절차가 명확하게 유지되는지를 물을 수 있다. 이는 예시적인 검토 질문이다. 목적은 실험에서 설득력 있어 보이는 동작과 실제 조건에서 신뢰할 수 있는 동작을 구분하는 데 있다.
접근성에도 같은 구분이 필요하다. 인터페이스는 포인터 없이 조작하기 어렵더라도 설득력 있어 보일 수 있다. 키보드 동작, 포커스 순서, 이해하기 쉬운 피드백은 시각적 완성도만으로 추론하지 말고 직접 평가해야 한다.
프로토타입 코드와 기존 프로젝트 관례의 관계도 중요하다. 국지적인 변경은 합리적으로 보이면서도 다른 곳에서 유지하기 어려운 패턴을 도입할 수 있다. 프로토타입이 의도한 동작을 명확히 보여주더라도 맥락 속에서 변경 사항을 검토하는 일은 여전히 필요하다.
따라서 회의적인 관점은 구체적이다. 더 쉬운 시연은 성급한 확신을 부추길 수 있다. 이해관계자는 작동하는 화면을 남은 작업이 미미하다는 증거로 해석할 수 있다. 실험이 중요한 의존성을 해결하지 못한 경우에는 언제든 그 해석에 이의를 제기해야 한다.
유용한 검토는 어떤 동작이 구현되었는지, 어떤 동작이 시뮬레이션되었는지, 어떤 가정이 아직 검증되지 않았는지를 식별해야 한다. 이렇게 하면 프로토타입이 의도치 않은 약속이 되는 것을 막으면서도 그 가치를 유지할 수 있다.
의사결정 기록은 회의 후에도 이러한 구분을 보존하는 데 도움이 된다. 대안을 비교하는 팀은 관련 기술 문서와 함께 검색 가능한 지식 베이스에 근거를 보관할 수 있다. 중요한 정보는 방향이 왜 바뀌었는지와 무엇을 여전히 검증해야 하는지다.
따라서 Figma code layers beta는 엔지니어링 검토에 도달하는 제안 변경 사항의 품질로 평가되어야 한다. 더 이해하기 쉬운 프로토타입은 유용하다. 명시적인 가정과 검토 가능한 구현이 수반된 프로토타입은 더 강력한 결과다.
도입, 수정 충실도, 탐색 경제성을 살펴보라
다음 근거는 팀이 더 명확한 결론에 도달하고, 의도한 변경을 보존하며, 초기 실험 이후에도 워크플로를 지속하는지를 보여줘야 한다.
첫 번째 신호는 실제 프로젝트에서 반복되는 협업 사용이다. 앞으로 몇 달 동안 더 강력한 근거는 팀원이 대안을 비교하고 선택한 방향을 구현 검토로 이어가는 사례를 포함할 것이다. 반복 사용은 캔버스가 지속적인 조정 문제를 해결한다는 Figma의 주장을 뒷받침할 것이다.
인상적인 시연 모음은 더 약한 근거가 된다. 시연은 워크플로가 매력적인 결과를 낼 수 있음을 입증한다. 하지만 프로젝트 제약이 까다로워질 때 팀이 그 워크플로로 돌아오는지에 대해서는 알려주는 바가 적다.
이 구분은 도입 사례를 평가하는 구매자의 판단을 이끌어야 한다. 어떤 결정이 더 명확해졌는지, 누가 참여했는지, 프로토타입 검토 후 어떤 일이 일어났는지를 물어야 한다. 이러한 세부 정보는 실험이 더 빨라졌다는 일반적인 주장보다 더 유용하다.
두 번째 신호는 수정 충실도다. 즉, 작업이 시각 편집과 코드 사이를 오갈 때 변경 사항이 의도한 모양과 동작을 보존하는지다. 이는 공개된 Figma 벤치마크가 아니라 제안된 평가 기준이다. 제품 약속의 핵심 메커니즘을 다룬다.
수정 작업이 제한적이었다는 증거는 그 약속을 강화할 것이다. 관련 없는 변경, 누락된 세부 사항, 어려운 조정에 대한 반복적인 보고는 이를 약화할 것이다. 어느 결과든 프로젝트 복잡성과 시도된 변경 사항에 대한 맥락이 필요하다.
세 번째 신호는 실제 크레딧 소비 상황에서 지속되는 탐색이다. Figma의 AI credit rules에 따르면 코드 레이어 요청은 가변적인 크레딧을 소비한다. 회사는 또한 AI 작업 실행 전에는 정확한 소비량을 예측할 수 없다고 말한다.
따라서 완전한 검토 주기가 관련 있는 평가 단위다. 대안을 생성하고, 다듬고, 수정하는 일은 모두 사용할 수 있는 결론에 도달하는 과정의 일부다. 첫 번째 출력만 평가하면 그 밖의 노력은 보이지 않게 된다.
지속적인 사용은 팀이 필요한 자원을 들일 만한 가치가 있다고 판단한다는 점을 시사할 것이다. 초기 시험 후 비교를 포기하는 양상은 반복 가능성에 대한 의문을 제기할 것이다. 어느 결론도 출시 발표만으로는 확정할 수 없다.
이러한 신호는 전망을 관찰 가능한 결과에 연결해 둔다. Figma는 공유 디자인 환경 안에서 작동하는 탐색을 가능하게 했다. 남은 질문은 주변 프로세스가 팀이 계속 사용할 만큼 충분히 명확해지는지다.
다음 검토에서는 이미 이견을 낳는 상호작용을 선택하고 평가 질문을 명시적으로 유지하라. 동일한 사용자 작업을 기준으로 대안을 비교하고, 선택한 방향의 근거를 보존하며, 엔지니어링 팀이 검증해야 할 가정을 식별하라. 검토자에게 작동하는 비교가 판단을 바꾸었는지, 아니면 단지 발표를 더 흥미롭게 만들었는지 물어보라. سپس 제안된 변경 사항을 구현 검토까지 추적하면서 그 과정에서 필요한 수정 사항을 기록하라. Figma code layers beta를 팀이 의사결정을 내리는 방식을 살펴볼 기회로 활용하라. 참여자가 트레이드오프를 이해하는 데 도움이 되고 개발자에게 더 명확하고 검토 가능한 제안을 남기는 경우에만 워크플로를 유지하라.
