Figma Specs가 나왔습니다, AI에게 화면보다 먼저 전달할 결정은 무엇일까요?

핵심 요약 (TL;DR)

마음에 드는 화면을 AI에게 보여 주어도, 그 화면에서 어떤 일이 일어나야 하는지까지 모두 전달되지는 않습니다. Figma는 10월 15일 캔버스에서 Markdown 문서와 디자인 맥락을 함께 다루는 Specs를 발표했습니다.[1] 첫 웹앱을 만드는 분에게 중요한 변화는 문서를 꾸미는 기능보다, 화면 옆에 결정의 이유와 미해결 질문을 남길 자리가 생겼다는 점입니다.

Specs는 어떤 맥락을 함께 전달하나요?

공식 발표에 따르면 기존 .md 파일을 캔버스로 끌어와 spec으로 만들고, 프레임이나 FigJam 다이어그램 같은 요소를 문서에 포함할 수 있습니다. 코딩 에이전트는 Figma MCP 서버를 통해 spec과 연결된 맥락을 읽을 수 있다고 설명합니다.[1] 텍스트와 시각 자료를 별도로 복사하던 작업을 함께 다루려는 방향입니다.

제공 조건은 구분해서 보셔야 합니다. Specs는 웹·데스크톱·모바일에서 유료 플랜 대상으로 공개 베타 배포를 시작한다고 안내됐습니다.[1][2] 발표를 읽었다고 내 계정에서 즉시 사용할 수 있다는 뜻은 아닙니다. 이번 글은 공식 발표를 대조한 안내이며, 실제 계정에서 기능을 실행한 후기는 아닙니다.

첫 앱의 문서에는 어떤 결정을 적으면 좋을까요?

예를 들어 작은 행사 신청 페이지를 만든다면 화면 이미지 옆에 ‘신청이 끝난 상태’를 문장으로 적어 보세요. 제출 버튼을 눌렀을 때 무엇을 저장하는지, 실패하면 입력을 남기는지, 중복 제출은 어떻게 알리는지를 정합니다. 아직 결정하지 않은 항목은 빈칸 대신 질문으로 남기세요. 이는 Specs의 자동 기능 설명이 아니라 요구사항을 정리하는 실습 제안입니다.

예쁜 완료 화면과 실제 접수 완료를 구분하는 것도 중요합니다. “완료 문구가 보인다”만 적기보다 “시험 신청 내용이 저장되고 다시 확인된다”처럼 사람이 확인할 행동을 적어 두세요. 고객 자료를 넣기 전에는 가짜 이름과 연락처로 연습하도록 별도 조건을 남기는 편이 좋겠습니다.

AI가 문서를 고쳐 주면 합의도 자동으로 끝날까요?

Figma는 에이전트가 Specs의 댓글을 읽고 답하거나 수정 제안을 만드는 협업 흐름을 소개합니다.[1] 다만 제안이 생성됐다는 것과 팀이 그 제안을 채택했다는 것은 다릅니다. ‘접수 취소를 허용할 것인가’처럼 운영 방식이 바뀌는 질문은 사람이 결정한 뒤 구현 요청에 반영하세요.

혼자 만드는 앱이라도 같은 원칙을 적용할 수 있습니다. 확정한 조건과 남은 질문은 구분해 기록하세요.

화면을 바꾼 뒤 문서도 다시 봐야 할까요?

공식 소개에는 구현이 진행되는 동안 MCP로 원래 spec을 갱신했다는 사내 개발 사례가 나옵니다.[1] 이를 참고해 수정이 끝날 때 화면과 요구사항을 함께 대조하는 절차를 두시면 좋겠습니다. 버튼 이름만 바꾼 것인지, 실제 동작 조건까지 바꾼 것인지 확인하고 그 차이를 기록하세요.

배포 전에는 확정된 조건을 시험 목록으로 다시 읽어 보세요. 문서에 적힌 기능이 화면에 있다는 사실과 그 기능이 끝까지 동작한다는 사실을 따로 확인합니다. 문서를 AI에게 전달하는 연결점이 편해져도, 완료를 판단할 기준은 여러분이 남겨 두셔야 합니다.

FAQ: 무료 플랜에서도 바로 쓸 수 있나요?

이번 발표의 Specs 제공 범위는 유료 플랜 공개 베타입니다.[1][2] 같은 날 발표된 다른 기능의 제공 범위와 섞지 말고, 계정에서 실제 접근 가능 여부를 확인하세요.

FAQ: 시작하려면 반드시 Figma로 옮겨야 하나요?

그럴 필요는 없습니다. 현재 쓰는 문서에 화면, 기대 동작, 미결정 질문을 함께 적는 것부터 시작해 보세요. 먼저 작업 기준을 정리하고, 협업 과정에서 그 맥락을 옮기는 불편이 생길 때 새 도구를 검토하시길 권합니다.

출처
[1] https://www.figma.com/blog/introducing-figma-specs/
[2] https://www.figma.com/blog/build-by-design/
관찰: 2026-10-16 KST