피그마 코드 레이어 공개 베타 전환과 캔버스 기반 프로토타입 검토 구조

피그마가 10월 15일 코드 레이어의 공개 베타 전환을 공식 발표했다. 이번 기능 확장은 Figma Design 캔버스 환경 안에서 실제 코드로 동작하는 상호작용 프로토타입을 직접 배치하고 다룰 수 있도록 지원하는 체계다. 회사는 모든 요금제를 이용하는 사용자를 대상으로 기능을 순차 제공한다고 설명했으며, 발표 당일에 모든 계정이 일괄적으로 기능에 접근할 수 있는 방식은 아니다.

코드 레이어는 같은 디자인 파일 안에 여러 작업 버전을 나란히 배치해 실행하거나, 기존 프로토타입을 복제해 다른 대안 방향을 시험하고 그 주변에 주석과 의견을 기록하는 흐름을 지원한다. 별도의 개발 도구나 환경에서 각자 도출한 결과물 링크만 주고받는 전달 방식 대신, 비교해야 할 실제 화면과 그에 대한 팀의 대화를 공통의 캔버스 위에 한데 모으는 작업 방식을 목표로 둔다.

이에 따라 화면이 동작하는 실제 움직임과 반응 역시 정적인 시안과 동일한 캔버스 평면 위에서 검토 대상에 오른다. 앞서 소개되었던 기능을 더 넓은 사용자층에 순차 개방함으로써, 디자이너와 개발자를 비롯한 프로젝트 참여자들이 완성된 화면 링크를 기다리지 않고 중간 과정의 결과물을 실시간으로 함께 확인하며 논의를 진행할 수 있는 기반이 마련되었다.

기존 자산과 가벼운 코드를 출발점으로 삼는 프로토타입 연결

코드 레이어의 작업은 빈 프롬프트 창에서 새로운 화면을 지시하는 방식에만 국한되지 않는다. 기존에 제작해 둔 디자인 프레임을 동작하는 프로토타입으로 전환하거나, GitHub 및 로컬 폴더에 보관된 코드를 불러오고, 크롬 확장 기능을 활용해 실제 웹페이지를 캡처해 캔버스로 들여오는 등 다각적인 출발점을 지원한다.

가져올 수 있는 코드의 범위는 공식 원문에서 지원되는 가벼운 프로토타이핑 코드베이스로 명시되어 있다. 이는 서비스의 전체 복잡도나 어떤 규모의 서비스 코드든 제한 없이 그대로 캔버스에 이식할 수 있다는 의미의 발표는 아니며, 빠른 검토와 화면 동작 확인에 적합한 가벼운 구현물을 중심으로 작동하도록 설계되었음을 보여준다.

피그마가 소개한 실제 고객 적용 사례에서도 이미 보유한 기존 자산을 출발점으로 활용한 흐름이 확인된다. Cox Automotive는 기존에 작성해 두었던 HTML 프로토타입 코드를 캔버스로 가져와 이해관계자들과 함께 새로운 기능을 검토하는 작업에 활용했다. Rocket Money의 디자이너는 기초 화면 컴포넌트를 구성하면서 상호작용과 접근성 요소를 초기 단계부터 논의하기 위해 코드 레이어를 도입했다.

실행 상태의 디자인 추출과 속성 편집 및 코드 반영 체계

공식 기능 안내에 명시된 Extract designs는 실행 중인 프로토타입 화면 전체나 특정 구성 요소를 다시 편집 가능한 디자인 레이어로 추출해 준다. 조작 흐름을 기록하는 방식을 취하면 사용자의 입력 순서에 따라 분기되는 여러 화면이 한꺼번에 캔버스 레이어로 생성되며, 이렇게 수정한 디자인 결과를 다시 코드 레이어로 되돌려 반영할 수 있다.

특히 빈 목록 상태나 로딩 화면, 오류 발생 화면처럼 서비스 실행 중에만 일시적으로 드러나는 장면들도 캔버스 위로 꺼내 정적인 시안과 함께 검토할 수 있다. 코드 편집기 안의 요소 선택 도구는 화면 생성 방식에 맞춰 색상, 여백, 폰트 스타일 등 주요 속성을 즉시 조정할 수 있도록 돕는다.

GitHub 연결 기능은 원본 저장소의 복제본과 브랜치를 기반으로 안전하게 실험을 수행하고, 수정 결과를 풀 리퀘스트로 묶어 원래 저장소에 병합할 수 있도록 안내한다. 이는 캔버스에서 수행한 수정 작업이 운영 중인 실서비스 코드에 직접적이고 자동으로 즉시 반영되는 구조와는 차이가 있다.

원문에서는 서로 다른 버전에서 장점을 모아 결합하는 시나리오도 설명한다. 하나의 시안에서 레이아웃을 취하고 다른 시안에서 세부 상호작용을 선택한 뒤 에이전트에게 새 버전으로 통합하도록 요청하는 방식이다. 이와 함께 모바일 앱 환경에서 코드 레이어를 미러링하여 실제 모바일 기기에서의 반응을 검증하는 방법도 안내되었다.

나란히 놓은 두 안에서 무엇을 같게 둘 것인가

비교할 시제품을 복제해 두는 것과 비교 조건을 맞추는 것은 다른 일이다. 한쪽은 빈 목록, 다른 쪽은 항목이 가득 찬 화면이라면 배치와 데이터의 차이가 섞인다. 코드 레이어가 버전을 나란히 실행하게 하는 기능을 실제 논의에 쓰려면 같은 입력을 넣고 다른 반응이 어디서 나오는지 볼 수 있어야 한다.

동작하는 코드에서 특정 상태를 디자인 레이어로 추출하는 과정은 그 순간의 장면을 붙잡는 일이다. 다시 실행할 때의 데이터·로그인·외부 서비스 상태까지 자동으로 같아진다는 뜻은 아니다. 실행 가능한 안, 추출한 상태, 원래 저장소에 제출할 변경을 구별하면 캔버스에서 합의한 내용이 개발 검토에서 무엇으로 이어져야 하는지 분명해진다.

Checkout.com의 적용 사례는 서비스의 전체 흐름 화면들을 캔버스로 한꺼번에 꺼내어 시각적으로 다듬은 뒤, 그 결과를 다시 동작 프로토타입으로 반영해 나간 과정을 보여준다. 이 과정에서 핵심은 단순히 생성 도구의 속도를 높이는 것이 아니라, 팀 구성원 모두가 직접 눈으로 볼 수 있는 검토 대상을 투명하게 펼쳐 놓는 데 있다.

작동하는 프로토타입이 눈앞에 나타났다는 사실 자체로 협의가 완료되는 것은 아니며, 나란히 놓인 화면들을 세부적으로 비교하고 수정을 결정한 이유를 설명하며 합의를 도출하는 과정이 뒤따른다. 코드를 직접 작성하지 못하는 팀원도 같은 파일에 들어와 흐름을 눌러보고 주석을 달 수 있어 실험에 참여하는 인원의 범위가 확장된다.

결국 가벼운 프로토타입 코드와 실제 서비스 운영 코드가 맡은 역할의 차이는 유지되지만, 코드 레이어는 양자 사이의 간극을 줄이고 빠른 피드백 순환을 만드는 검토 도구로 기능한다. 이번 공개 베타 확대의 실질적인 의미 역시 더 많은 팀이 이러한 디자인과 코드 간의 왕복 과정을 직접 시도하고 검증할 수 있게 되었다는 점에 있다.

ARCH.B 의견

서로 다른 프로토타입 버전을 번갈아 띄워 확인하는 기존 방식은 이전 화면의 디테일과 동작 감각을 기억에 의존해 비교해야 하는 한계를 안고 있었다. 두 가지 이상의 동작 시안을 한 캔버스 평면에 나란히 두고 동시에 실행할 수 있게 되면 버튼 클릭 시의 반응, 화면 간 전환 효과, 대화형 응답 속도와 타이밍의 차이를 같은 자리에서 직관적으로 검증할 수 있다.

특히 기본 디자인 시안 단계에서는 보기 좋은 이상적인 상태만 그려지고 빈 데이터 목록이나 네트워크 지연, 오류 발생 화면 같은 예외 상태는 뒤로 밀리기 쉽다. 실행 흐름 도중 나타나는 이러한 비정상 상태 화면들을 디자인 레이어로 추출해 나란히 배치할 수 있다면, 실제 결함이 발생했을 때 사용자가 어떤 안내를 받고 어디로 복귀해야 하는지를 구현 단계 이전부터 구체적으로 논의할 수 있다.

다만 이 협업 방식은 지원되는 가벼운 프로토타이핑 코드베이스라는 명확한 조건 위에서만 유효하게 작동한다. 복잡한 비즈니스 로직이나 보안 제약이 얽힌 엔터프라이즈급 운영 코드를 그대로 캔버스에 올려 구동하는 용도가 아니며, GitHub 브랜치와 풀 리퀘스트를 거치는 구조인 만큼 캔버스에서 변경된 내용이 실제 제품의 아키텍처 및 품질 기준을 충족하는지는 개발팀의 별도 검증이 반드시 필요하다.