Figma 캔버스에 들어온 코드와 Specs, 디자인 의도도 살아남을까

Figma 브랜드 자료의 공식 로고를 정보 제공 목적의 사용 지침에 따라 중립적인 여백 위에 변형 없이 표시했습니다. 회사 식별용이며 code layers나 Specs 화면을 보여 주는 이미지는 아닙니다.

가입 화면은 완성돼 보여도 중요한 결정이 보이지 않을 수 있습니다. 초대가 만료되면 어떻게 될까요? 네트워크 오류 뒤 다시 시도할 수 있을까요? 어떤 문구가 승인되었을까요? 작동하는 프로토타입은 일부 질문에 답하지만 설득력 있는 정상 경로 뒤에 문제를 숨길 수도 있습니다.

Figma는 10월 15일 업데이트에서 code layers와 Specs를 오픈 베타로 공개했습니다. Code layers는 작동하는 프로토타입을 디자인 캔버스에 직접 놓습니다. Specs는 의도를 적은 문서가 관련 디자인, 다이어그램과 코드 옆에 머물 공유 공간을 제공합니다. 많은 제품팀에 익숙한 협업 디자인 플랫폼 Figma가 화면을 논의하는 곳을 동작과 요구사항까지 함께 탐색하는 곳으로 넓히고 있습니다. Figma 릴리스 노트.

흥미로운 기능은 이 자료들 사이의 관계라고 봅니다. 화면 하나를 더 생성하는 장점은 시연에서 쉽게 드러나지만, 동작을 팀의 결정과 계속 일치시키는지가 더 유용한 평가 기준입니다. 세 가지 실무 흐름과 서로 다른 제공 상태, 공유 캔버스가 개선할 수 있지만 자동 완료하지는 않는 검토 업무를 살펴보겠습니다.

설명하는 디자인 옆에서 프로토타입을 실행할 수 있습니다

Code layer는 Figma Design 파일 안에서 실행 코드로 작동하는 대화형 프로토타입입니다. 시각적 대안을 비교하는 공간에서 동작도 탐색할 수 있습니다. 주변 디자인을 계속 보면서 “이 상호작용을 상상해 보세요”에서 “두 버전을 써 보세요”로 대화가 바뀝니다.

10월 23일 확인한 code layers 도움말은 디자인 프레임, 프롬프트, 캡처한 웹페이지, 연결된 저장소나 로컬 파일에서 시작하는 방법을 설명합니다. Code layer를 복제해 대안을 나란히 비교할 수도 있습니다. 특정 경로의 접근 가능성은 해당 제공 일정과 저장소 호환성에 따릅니다.

가입 절차를 검토하는 가상의 제품팀을 생각해 보겠습니다. 한 버전은 계정 생성 전에 초대를 확인하고 다른 버전은 정보를 먼저 입력하게 합니다. 정적 프레임에서는 둘 다 그럴듯합니다. 작동하는 프로토타입은 순서, 중단과 초대 확인 실패 때 사용자가 잃는 작업량을 드러냅니다.

장점은 더 구체적인 대화입니다. 엔지니어링에 애플리케이션 전체로 일반화해 달라고 요청하기 전에 제품에 맞는 동작을 결정할 수 있습니다. 프로토타입은 시험 가능한 아이디어 표현이며 최종 인증 구현을 대신하지 않습니다. 방향을 저렴하게 바꿀 수 있을 때 이견을 발견하는 데 가치가 있습니다.

Specs는 설명이 머물 자리를 제공합니다

Figma의 10월 15일 Specs 발표는 Markdown을 캔버스로 가져오고 프레임, 다이어그램과 다른 Figma 콘텐츠 참조를 삽입하는 기능을 설명합니다. 시각적 작업 옆에 결정 이유를 담을 수 있습니다. 이 관계가 분리된 문서에 화면 캡처를 붙이는 것과의 차이입니다.

가입 사례의 명세에는 만료된 초대에서도 입력 정보를 보존해야 한다는 규칙, 문구 책임자와 승인된 오류 상태를 넣을 수 있습니다. “이 화면을 만들어 줘”라는 프롬프트에는 빠지기 쉬운 내용입니다. 디자인이 바뀌면 규칙도 바뀌었는지 가까운 곳에서 확인할 수 있습니다.

공유된 맥락과 올바른 맥락은 다릅니다. 동료와 에이전트가 모두 읽는 문서는 오래된 결정도 효율적으로 퍼뜨릴 수 있습니다. 누군가는 현재 유효한 문장을 정하고, 충돌하는 의견을 해결하며, 미해결 질문을 표시해야 합니다. 자료를 모으면 거리는 줄지만 모순이 저절로 풀리지는 않습니다.

새로운 완성감의 위험도 있습니다. 시각 자료가 포함된 잘 다듬어진 명세는 핵심 요건이 미승인 상태여도 권위 있어 보일 수 있습니다. 결정, 가정과 열린 질문을 작고 명확하게 구분하면 좋습니다. 구현의 기준으로 삼을 문장과 더 논의할 문장을 협업자가 알 수 있습니다.

자체 제작한 개념적 인포그래픽입니다. 디자인, Specs와 code layers는 서로 다른 정보를 담으며, 일치 여부는 여전히 검토해야 합니다.

10월 발표에는 서로 다른 출시 상태가 들어 있습니다

Figma의 업데이트에는 하나의 약속으로 묶기 쉬운 기능이 여럿 있습니다. 10월 15일 출시 정리는 오픈 베타, 비공개 베타와 프리뷰를 구분합니다. 오늘 쓸 수 있는 도구와 더 큰 시스템 비전을 나눠 보면서 제공되는 부분부터 평가할 수 있습니다.

상업적 일정도 중요합니다. 릴리스 노트는 code layer 안의 생성·편집이 2026년 11월 4일까지 유료 요금제에서 무료라고 설명합니다. 기간이 한정된 제안이며 영구 가격 정책이 아닙니다. Code layers는 전체 요금제에 제공되는 것으로 설명되고 Specs는 유료 요금제에 순차 제공됩니다. 베타를 기준으로 팀 예산을 짜기 전에 좌석, 크레딧과 현재 요금제 조건을 확인해야 합니다.

표는 도입 순서로도 유용합니다. 아직 공개되지 않은 관리 경험에 의존하기 전에 프로토타입과 명세를 공유하는 방식이 실제 검토를 개선하는지 시험할 수 있습니다. 각 부분의 역할과 상태를 나누면 출시를 평가하기 쉽습니다.

오류 상태까지 포함해 가입 절차를 시험하세요

첫 실무 용도는 구현 전 동작 검토입니다. 예쁜지만 판단하는 장식적 화면보다 실제 결정이 필요한 흐름을 고릅니다. 검증, 로딩, 실패와 복구가 모두 경험에 영향을 주는 가입은 좋은 예입니다.

다음은 Figma가 문서화한 진입점을 이용하는 평가 제안이며 직접 사용한 결과는 아닙니다.

1. 기존 프레임 하나를 고르고 옆에 사용자 목표를 씁니다. 작동하는 버전을 요청하기 전에 성공, 빈 상태, 로딩과 오류 상태를 나열합니다.
2. 프레임을 선택해 도구 모음의 Code를 누르거나 B를 누른 뒤 Build selection을 사용합니다. 정적 디자인에서 시작하는 문서상의 단계입니다.
3. 초대 검증 실패 시 입력값을 보존하고 명확한 재시도를 제공하는 식의 좁은 동작을 요청합니다. 프롬프트를 선택한 흐름에 연결합니다.
4. Code layer를 복제해 실제로 다른 상호작용을 탐색합니다. 관계없는 두 정상 경로 대신 같은 상황으로 두 실행 버전을 비교합니다.
5. 선택한 동작과 이유를 명세에 기록합니다. 미래 편집자가 놓칠 제약을 설명한다면 거절한 대안도 포함합니다.
6. 검토된 디자인과 요구사항을 기존 구현 절차로 전달합니다. 실제 애플리케이션 환경에서 인증과 데이터 처리를 검증합니다.

중요한 산출물은 팀이 직접 시도한 결과로 뒷받침되는 결정입니다. 프로토타입이 불확실성을 드러냈다면 문서를 완성하려고 규칙을 지어내기보다 미해결 상태를 남기는 편이 좋습니다. 유용한 도구는 열린 질문을 쉽게 보이게 합니다.

디자인 시스템에는 컴포넌트뿐 아니라 지시도 필요합니다

두 번째는 새 화면을 탐색하면서 공통 컴포넌트 시스템을 유지하는 상황입니다. 팀에 이미 승인된 버튼, 간격 규칙, 콘텐츠 패턴과 접근성 기대가 있을 수 있습니다. 에이전트는 보기에는 그럴듯하지만 이런 투자를 조용히 우회하는 대안을 만들어 매력적인 미리보기 뒤에 유지보수 업무를 남길 수 있습니다.

Figma는 10월 업데이트에서 게시된 라이브러리에 guidelines를 추가하고 code sources를 비공개 베타로 도입했습니다. 출시 정리는 에이전트가 따를 패턴과 기존 컴포넌트를 주는 방법으로 이를 설명합니다. 중앙화된 디자인 시스템 프리뷰는 라이브러리, 코드와 지침을 모으는 방향으로 확장하지만, 오늘 누구나 접근할 수 있는 기능으로 보아서는 안 됩니다.

가상의 시험에서는 기존 필드 컴포넌트를 사용해 설정 양식을 만들도록 요청할 수 있습니다. 명세에 필수 컴포넌트, 검증 메시지가 전달할 내용과 핵심 상호작용 규칙을 씁니다. 검토자는 실제로 그 컴포넌트를 재사용했는지 겉모습만 흉내 냈는지 확인합니다.

이 차이는 결과를 바꿉니다. 두 화면이 같아 보여도 하나는 관리되는 컴포넌트의 동작을 상속하고 다른 하나는 관계없는 새 구현을 가질 수 있습니다. 시각적 일관성도 중요하지만 미래 수정이 전파될지는 구현 일관성이 정합니다. 캔버스는 결과 비교에 유용하고 코드는 시스템을 이해하는 검토자가 확인해야 합니다.

지침에도 유지보수 비용이 있습니다. 오래된 라이브러리에서 복사한 규칙이 새 컴포넌트와 충돌하고 긴 문서가 중요한 예외를 가릴 수 있습니다. 날짜 없는 선호의 대규모 모음보다 승인된 구체적 예시와 명확한 책임자가 좋습니다. 사용한 컴포넌트를 에이전트가 설명하게 하면 검토의 출발점이 생깁니다.

MCP는 맥락을 편집기로 가져오고 변경을 돌려보낼 수 있습니다

10월 23일 확인한 Figma MCP 문서는 에이전트가 디자인 맥락을 읽고 네이티브 콘텐츠를 캔버스에 다시 쓰는 방식을 설명합니다. 가장 넓은 기능을 지원하는 경로는 원격 서버입니다. 명세 쓰기에는 원격 서버와 파일 편집 권한이 필요하며 다른 행동은 각각 좌석과 클라이언트 요건이 있습니다.

업무에 돌아오는 경로가 생깁니다. 코딩 에이전트는 요구사항을 받고 구현 중 제약을 발견한 뒤 공유 명세 업데이트를 도울 수 있습니다. 결정과 코드 사이의 연속성이 장점입니다. 발견한 내용이 다른 팀원이 보지 못하는 편집기 채팅에만 남는다면 유용성은 작아집니다.

연결은 권한 질문도 바꿉니다. 프레임을 읽는 도구와 명세를 편집하는 도구는 다른 능력입니다. 업무를 활성화하기 전에 대상 파일, 의도한 행동과 변경 승인자를 정합니다. 편리한 연결 때문에 모든 프로젝트 문서를 기본적으로 수정 가능하게 해서는 안 됩니다.

시험에는 파일 하나와 좁은 요청을 사용합니다. 검토된 명세를 읽고 구현 변경을 제안하며 미해결 질문은 보이는 곳에 남기게 합니다. 다시 쓴 내용을 확인합니다. 목적은 API 호출 성공을 넘어 왕복 과정에서 의미가 유지되는지 평가하는 것입니다.

Payload는 실제 데이터와 책임도 가까이 가져옵니다

세 번째는 행사 목록, 사내 카탈로그, 직원이 갱신할 캠페인 페이지처럼 콘텐츠를 사용하는 작은 앱입니다. 정적 프로토타입은 배치를 보여 주지만 운영 질문은 모두 남길 수 있습니다. 콘텐츠가 매일 바뀌면 편집 절차도 제품의 일부입니다.

10월 15일 릴리스 노트에 따르면 Make는 CMS, 데이터베이스, 미디어, API, 인증과 관리 패널이 포함된 Payload 백엔드를 구성할 수 있으며 Figma가 결과를 호스팅합니다. Payload는 오픈소스 콘텐츠 프레임워크입니다. 이번 업데이트는 화면을 그리거나 프론트엔드를 프롬프트로 만드는 방법 이상의 범위가 됩니다. Figma의 Payload 발표 맥락.

행사 목록에서는 콘텐츠 담당자가 누군가에게 하드코딩된 카드를 수정해 달라고 하는 대신 관리 화면에서 항목을 갱신할 수 있는 것이 눈에 띄는 장점입니다. 실제 필드 길이, 없는 이미지와 초안 항목을 디자인 논의에 포함할 수 있습니다. 잘 다듬어진 가짜 데이터가 숨기기 쉬운 일상 조건입니다.

편리함과 함께 운영 책임도 커집니다. 누가 게시할 수 있는지, 공개 필드는 무엇인지, 실수한 삭제를 어떻게 복구할지, 접근권한이 바뀌면 어떻게 할지 정해야 합니다. 생성된 백엔드는 결정을 구현할 자리를 주지만 조직을 대신해 결정하지는 않습니다. 실제 제출을 받기 전에 해당 앱의 호스팅과 데이터 조건을 검토해야 합니다.

자체 제작한 인포그래픽입니다. 프로토타입에서 운영으로 이동하면 구현과 운영 결정이 추가됩니다. 단계는 평가 기준이며 측정된 제품 보장이 아닙니다.

탐색이 빨라지면 결정하지 않은 선택도 쌓일 수 있습니다

주요 이점은 더 많은 사람이 구체적인 산출물로 동작을 논의한다는 점입니다. 디자이너는 작동하는 대안을 비교하고, 제품 관리자는 의도를 붙이며, 엔지니어는 제약이 출시 직전의 문제로 바뀌기 전에 지적할 수 있습니다. 같은 속도가 상태를 아무도 기억하지 못하는 수많은 변형을 만들 수도 있습니다.

변형마다 질문이 있는 실험으로 다룹니다. “이 오류 뒤 입력 정보를 보존하면 혼란이 줄어드는가”는 검토할 대상을 줍니다. “다섯 버전 더 생성”도 탐색에 유용할 수 있지만 나중에 무엇을 배웠는지 결정해야 합니다. 그렇지 않으면 캔버스가 내려지지 않은 선택의 대기실이 됩니다.

팀의 유용한 측정값은 구현까지 넘어간 미해결 결정의 수입니다. 평범한 변경 몇 개에서 개발자가 더 명확한 동작, 덜 모순된 참조, 결정 책임자에게 돌아갈 확실한 경로를 받았는지 살펴봅니다. 명세 유지 시간도 확인합니다. 공유 맥락은 업무 전체의 모호함을 줄일 때 가치가 있습니다.

기대할 방향은 작지만 강합니다. 디자인, 문서화된 이유와 실행 동작을 더 쉽게 일치시키는 것입니다. 베타 품질, 저장소 제한과 요금제 조건은 팀별 결과에 영향을 줍니다. 생성에서 운영으로 넘어가는 사이, 불필요한 재작업이 시작되는 빠진 대화를 다룬다는 점에서 방향은 기대할 만합니다.

캔버스는 결정이 계속 보이는 장소가 될 수 있습니다

Code layers는 아이디어를 시험하기 쉽게 하고 Specs는 의도한 의미를 이어 가기 쉽게 합니다. 함께 사용하면 설득력 있는 화면 캡처 이상을 다음 협업자에게 남기고, 만들어지는 대상 곁에 디자인의 이유를 둘 수 있습니다.

유용한 완료 기준은 구현에서도 유지되는 합의입니다. 흐름 하나로 시작해 불확실한 동작을 드러내고 결정을 작업에 연결하세요. 답하지 못한 질문이 줄어든 상태로 운영에 도달한다면 새 캔버스는 프로토타입 하나를 더 만드는 것보다 가치 있는 일을 하는 것입니다.

---

출처

• Figma 제품 릴리스 노트, Config India 발표, 2026년 10월 15일. 10월 23일 확인.
• Build by design: 새로운 제작 방식을 위한 새 업무 흐름, 2026년 10월 15일.
• Figma Design의 code layers, 2026년 10월 23일 확인.
• Specs 소개: 매체로서의 Markdown, 2026년 10월 15일.
• Figma MCP 서버 문서, 2026년 10월 23일 확인.
• Figma 상표·브랜드 자료, 2026년 10월 23일 확인.

기술적 결정의 근거를 남기세요

출처 링크와 직접 검토한 기술 메모를 별도 작업 공간에 보관하려는 독자에게 Telli.sh도 하나의 선택지입니다. 메모 작업 공간 열기.