[바미] Claude와 Figma를 연결하면 화면 디자인부터 웹페이지까지 만들 수 있을까?

들어가기 전에

반려견의 산책 시간과 병원비를 기록하는 웹사이트를 만든다고 가정해보겠습니다.

처음에는 필요한 화면이 많지 않아 보입니다. 회원가입 화면을 만들고, 반려견을 등록하고, 기록을 보여주면 될 것 같습니다.

하지만 화면을 하나씩 만들다 보면 생각보다 정해야 할 것이 많습니다.

• 회원가입은 어떤 순서로 진행할까요?
• 휴대전화와 PC에서는 화면을 어떻게 배치할까요?
• 버튼 색과 글자 크기는 어떻게 맞출까요?
• 나중에 대표 색상을 바꾸면 모든 화면에 한꺼번에 적용할 수 있을까요?
• Figma에서 만든 디자인이 실제 웹사이트에서도 똑같이 보일까요?

AI에게 화면을 만들어 달라고 요청할 수는 있습니다. 다만 화면이 빨리 나왔다고 해서 위의 문제가 모두 해결되는 것은 아닙니다.

가입 화면의 버튼은 초록색인데 대시보드의 버튼은 파란색일 수 있습니다. 겉보기에는 같은 버튼이어도 나중에 하나씩 따로 수정해야 할 수도 있고요.

이번 글은 정진호님의 Claude·Figma 활용 강의 자료를 참고해, AI와 함께 디자인 기준을 정하고 화면을 만든 뒤 웹페이지로 옮기는 과정을 정리했습니다.

Figma나 MCP가 낯선 분도 읽을 수 있도록 도구의 역할부터 설명합니다. 제가 직접 해당 서비스를 만들고 배포한 후기는 아니며, 자료에 나온 실습 내용을 풀어 쓴 글입니다.

Claude와 Figma는 각각 어떤 일을 하나요?

먼저 Figma는 웹사이트나 앱의 화면을 설계할 때 쓰는 도구입니다.

버튼을 어디에 놓을지, 입력창은 얼마나 크게 만들지, 다음 화면으로 어떻게 넘어갈지를 눈으로 보며 정리할 수 있습니다. 집을 짓기 전에 평면도와 내부 구성을 그리는 과정과 비슷합니다.

Claude는 글을 이해하고 작성하는 AI입니다. 강의 실습에서는 파일을 다루고 코드를 작성할 수 있는 Claude Code를 사용합니다.

두 도구를 연결하면 다음과 같은 작업을 할 수 있습니다.

• 서비스에 맞는 디자인 기준을 문서로 정리합니다.
• 정리한 기준으로 Figma 화면을 만듭니다.
• 화면의 색상이나 문구를 수정합니다.
• 디자인을 웹페이지 코드로 옮깁니다.
• 완성된 결과가 처음 정한 기준과 맞는지 확인합니다.

물론 연결했다고 해서 모든 기능을 자유롭게 쓸 수 있는 것은 아닙니다. 실제로 할 수 있는 작업은 연결된 도구의 기능과 파일 권한에 따라 달라집니다.

MCP는 왜 필요한가요?

AI와 채팅만 한다면 화면 구성에 관한 설명은 들을 수 있습니다. 하지만 설명을 들었다고 해서 Figma 파일이 저절로 바뀌지는 않습니다.

AI가 Figma의 정보를 읽거나 수정 작업을 요청하려면 두 프로그램이 서로 정보를 주고받을 방법이 필요합니다.

MCP(Model Context Protocol)는 AI가 외부 도구나 데이터와 연결될 때 사용하는 공통 규약입니다. 프로그램끼리 요청과 응답을 주고받기 위해 정한 약속이라고 볼 수 있습니다. Anthropic의 MCP 소개

예를 들어 다음과 같이 요청할 수 있습니다.

가입 화면에 있는 버튼의 색상을 디자인 기준에 맞게 수정해 주세요.

요청의 뜻은 AI가 파악합니다. Figma에서 어떤 작업을 할 수 있는지는 연결된 도구가 정하며, 실제 변경도 허용된 기능과 권한 안에서 이루어집니다.

Figma 공식 문서에서도 디자인 정보를 AI에 전달하는 기능과 Figma 화면에 편집 가능한 요소를 만드는 기능을 나누어 설명합니다. Figma MCP 소개

MCP는 화면을 만드는 도구라기보다 AI와 Figma가 서로 정보를 주고받을 수 있도록 이어주는 방식에 가깝습니다.

플러그인, 커넥터, 스킬은 어떻게 다를까요?

연결을 설정하다 보면 플러그인, 커넥터, 스킬이라는 용어가 함께 나옵니다. 셋의 차이는 아래와 같습니다.

구분	설명	PLOG 실습에서 하는 일
플러그인	관련 기능과 설정을 한데 묶은 것	Figma 연결 설정과 작업 방법을 함께 제공
커넥터	Claude와 외부 서비스를 연결하는 통로	Claude와 Figma를 연결
스킬	반복 작업의 순서와 기준을 적어 둔 안내서	디자인을 코드로 옮기는 순서를 안내

자료 속 Figma 플러그인에는 여러 스킬과 커넥터가 함께 들어 있습니다. 공식 설정 안내에도 Figma 플러그인에 MCP 설정과 작업용 스킬이 포함된다고 설명되어 있습니다. Claude Code와 Figma 연결 안내

연결 상태를 확인할 때는 한 가지 주의할 점이 있습니다.

자료에는 현재 작업에서는 Figma를 사용할 수 있지만, 계정의 커넥터 목록에서는 연결되지 않은 것처럼 보이는 사례가 나옵니다. 여기서 세션은 지금 진행 중인 대화나 작업 단위를 뜻합니다.

이럴 때는 화면에 표시된 상태만 보고 설치를 반복하기보다, 실제 요청이 실행되는지 먼저 확인하는 편이 좋습니다.

강의에서는 현재 Figma 사용자 정보를 불러오는 간단한 요청으로 연결을 확인합니다. 큰 작업을 맡기기 전에 조회 요청부터 보내보는 것입니다.

요금제와 이용 좌석, 메뉴 이름, 제공 기능은 달라질 수 있으므로 실제 설정 시점의 공식 안내를 확인해야 합니다.

화면보다 먼저 문서를 만드는 이유

이 글에서는 반려견의 일상과 지출을 기록하는 서비스인 PLOG를 예시로 살펴봅니다.

실습은 Figma에서 화면을 만드는 것으로 시작하지 않습니다. 먼저 PLOG에서 사용할 디자인 기준을 마크다운 파일에 정리합니다.

마크다운은 일반 텍스트에 제목, 목록, 표 같은 구조를 더할 수 있는 문서 형식입니다. 확장자가 .md인 파일이 바로 마크다운 문서입니다.

예를 들면 이렇게 작성할 수 있습니다.

# 반려견 기록 앱 디자인 기준

## 기본 방향
- 기록을 쉽게 입력할 수 있도록 구성합니다.
- 모바일에서도 글자와 버튼을 편하게 확인할 수 있어야 합니다.

## 버튼
- 주요 동작에 사용하는 버튼은 같은 색상을 사용합니다.
- 같은 역할의 버튼에는 같은 모양과 이름을 사용합니다.

## 입력 화면
- 입력창 위에 항목 이름을 표시합니다.
- 잘못 입력했을 때는 이유를 설명합니다.

위 내용은 설명을 위해 간단히 만든 예시이며, 자료에 나온 디자인 시스템 전체를 옮긴 것은 아닙니다.

이렇게 기준을 문서로 남겨두면 새 화면을 만들 때마다 같은 내용을 다시 설명하지 않아도 됩니다. 완성된 화면을 검토할 때도 무엇과 비교해야 할지가 분명해집니다.

다만 마크다운 파일을 만들어 두는 것만으로 AI가 내용을 자동으로 기억하지는 않습니다. 작업을 요청할 때 어떤 문서를 참고해야 하는지도 함께 알려줘야 합니다.

디자인 시스템에는 무엇을 정리할까요?

디자인 시스템은 여러 화면에서 공통으로 사용할 색상, 글자, 버튼, 간격 등의 기준을 모아 둔 규칙입니다.

주로 다음과 같은 내용을 정합니다.

• 어떤 색을 어디에 사용할지
• 제목과 본문의 글자를 얼마나 크게 표시할지
• 버튼과 입력창을 어떤 모양으로 만들지
• 요소 사이의 간격을 얼마나 둘지
• 오류나 완료 상태를 어떻게 보여줄지

회원가입 화면과 대시보드를 따로 만들더라도 사용자에게는 같은 서비스처럼 보여야 합니다. 공통 기준이 없으면 AI가 화면마다 서로 다른 색이나 모양을 선택할 수 있습니다.

강의에서는 디자인 시스템 문서를 만든 다음, 각 요소가 실제로 어떻게 보이는지 확인할 수 있는 HTML 미리보기를 만듭니다. Figma 파일 안에도 같은 내용을 간단히 정리합니다.

HTML은 웹페이지의 구조를 만드는 언어입니다. 여기서는 버튼과 글자 등이 브라우저에서 어떻게 보이는지 확인하는 데 사용합니다.

글로 읽을 때는 괜찮아 보였던 기준도 화면에 적용하면 문제가 보일 수 있습니다. 글자가 너무 작거나, 요소 사이가 답답하거나, 중요한 버튼이 눈에 잘 띄지 않을 수 있습니다.

여러 화면을 만들기 전에 이 단계에서 기준을 다듬어 두면 같은 문제가 반복되는 것을 줄일 수 있습니다.

Figma의 페이지와 프레임은 어떻게 구분하나요?

Figma 파일의 구조도 미리 알아둘 필요가 있습니다.

파일은 디자인 작업 전체를 담는 문서입니다. 파일 안에는 여러 페이지가 있고, 페이지 안에는 각각의 화면을 나타내는 프레임이 있습니다. 프레임 안의 글자, 버튼, 도형 등은 레이어로 구성됩니다.

구성 요소	PLOG 예시
파일	PLOG 전체 디자인
페이지	디자인 시스템, 회원가입, 대시보드
프레임	모바일 정보 입력 화면, PC 정보 입력 화면
레이어	제목, 이름 입력창, 다음 버튼

따라서 Figma에서 ‘회원가입 페이지를 만든다’는 말은 회원가입에 필요한 여러 화면을 하나의 작업 공간에 정리한다는 뜻일 수도 있습니다.

웹사이트의 페이지와 Figma의 페이지를 같은 의미로 생각하면 필요한 화면 수를 잘못 이해할 수 있으므로 둘을 구분해야 합니다.

회원가입도 먼저 흐름을 정해야 합니다

회원가입 화면을 만들어 달라고만 요청하면 어떤 결과가 나올까요?

아이디와 비밀번호를 입력하는 화면 하나만 만들어질 수 있습니다. 이메일 인증이나 약관 동의가 빠질 수도 있고, 모바일 화면만 나올 수도 있습니다.

강의에서는 먼저 가입에 필요한 정보를 정합니다. 아이디, 비밀번호, 이름, 이메일, 전화번호, 동의 항목, 이메일 인증 등이 여기에 포함됩니다.

그다음 사용자가 실제로 진행할 순서에 맞춰 여섯 개 화면으로 나눕니다.

단계	화면	사용자 동작
1	약관 동의	필요한 동의 항목을 확인합니다.
2	정보 입력	가입에 필요한 정보를 입력합니다.
3	이메일 인증 발송 안내	인증번호 발송 안내를 확인합니다.
4	인증번호 입력	이메일로 받은 6자리 숫자를 입력합니다.
5	가입 완료	가입 결과를 확인합니다.
6	환영 화면	서비스를 시작합니다.

모든 서비스가 꼭 이 여섯 단계를 따라야 하는 것은 아닙니다. 실제로는 필요한 정보와 사용자의 불편을 따져 단계를 줄이거나 합칠 수 있습니다.

그래서 화면을 만들기 전에 사용자가 어떤 순서로 움직일지부터 정해야 합니다.

이 흐름은 다른 사람도 참고할 수 있도록 마크다운 문서로 남깁니다. 이후 디자인 시스템 문서와 회원가입 가이드를 함께 사용해 PC와 모바일 화면을 만듭니다.

여섯 단계에 두 가지 화면 크기를 적용하므로 모두 12개 프레임이 만들어집니다. 자료에는 이 작업에 약 15분이 걸린 것으로 나옵니다. 다만 실습 환경에서 나온 기록일 뿐, 모든 환경에서 같은 시간이 걸리거나 실제 회원가입 기능까지 완성됐다는 뜻은 아닙니다.

보기에는 같은 색인데 왜 함께 바뀌지 않을까요?

화면을 만든 다음에는 보기 좋은지만 확인할 것이 아니라, 나중에 수정하기 쉬운 구조인지도 살펴봐야 합니다.

전체 색상을 바꾸기 전에는 각 요소에 색상 값이 직접 입력되어 있는지 확인합니다. 이렇게 값을 코드나 요소에 바로 입력해 둔 상태를 하드코딩이라고 합니다.

예를 들어 여러 버튼이 모두 같은 초록색이라고 가정해보겠습니다.

한쪽은 버튼마다 초록색 값을 직접 입력했고, 다른 쪽은 모든 버튼이 ‘대표 색상’이라는 공통 스타일을 사용하고 있습니다.

처음에는 똑같이 보이지만 대표 색상을 노란색으로 바꾸면 차이가 드러납니다.

색상 관리 방식	색상을 바꿀 때
요소마다 값을 직접 입력	바꿔야 할 요소를 찾아 하나씩 수정해야 합니다.
공통 스타일에 연결	연결된 요소에 변경 내용이 함께 적용됩니다.

자료의 검토 결과에서도 입력창 테두리와 그림자, 일부 강조 글자에 공통 스타일과 연결되지 않은 값이 발견됩니다.

이런 요소는 겉보기에는 같은 색이어도 대표 색상을 바꿀 때 그대로 남을 수 있습니다. 그래서 직접 입력된 값을 찾아 공통 스타일에 연결하는 작업이 필요합니다.

점검을 마친 뒤에는 전체 색상을 레몬 노랑 계열로 바꿨다가 다시 원래 초록색으로 되돌립니다.

색상을 바꿔보는 이유는 공통 기준이 여러 화면에 제대로 연결되어 있는지 확인하기 위해서입니다.

디자인을 코드로 옮길 때는 한 화면부터 확인합니다

Figma에 화면이 만들어졌다면 이제 브라우저에서 볼 수 있는 웹페이지로 옮길 차례입니다.

코드로 옮길 때도 모든 화면을 한꺼번에 변환하지 않습니다. PC용 정보 입력 화면 하나를 먼저 HTML로 만든 뒤 디자인 기준과 비교합니다.

비교해보니 다음과 같은 차이가 발견됩니다.

• 모서리의 둥근 정도가 기준과 다릅니다.
• 정해진 배경색이 아닌 다른 색을 사용했습니다.
• 필요한 테두리가 빠져 있습니다.
• 버튼 글자의 굵기가 기준과 다릅니다.
• 본문의 줄 간격이 적용되지 않았습니다.

자료의 검토표에는 모서리를 18px로 정했지만 실제 화면에는 14px로 적용된 사례도 나옵니다. px는 화면의 크기를 나타낼 때 사용하는 픽셀 단위입니다.

이 정도 차이는 잠깐 봐서는 놓치기 쉽습니다. 하지만 기준이 문서로 정리되어 있으면 어디를 어떻게 고쳐야 하는지 정확히 짚을 수 있습니다.

수정을 요청할 때도 ‘조금 더 예쁘게 해 주세요’라고 말하기보다 다음처럼 기준과 확인할 항목을 함께 적는 편이 명확합니다.

디자인 시스템 문서와 현재 화면을 비교해 주세요. 색상, 글자 크기, 간격, 모서리와 테두리가 다른 부분을 표로 정리하고 수정해 주세요.

위 요청문은 자료의 검토 과정을 바탕으로 다시 작성한 예시입니다.

수정한 화면은 PC와 모바일 크기에서 다시 확인한 뒤 나머지 화면으로 작업 범위를 넓힙니다. 실제 작업에서도 AI의 완료 보고만 믿기보다 브라우저에서 직접 확인해야 합니다.

반응형 화면은 PC와 모바일 두 장을 만드는 것과 다릅니다

반응형 웹은 화면의 폭에 따라 배치와 크기가 달라지는 웹페이지입니다.

PC에서는 여러 정보를 가로로 보여주고, 휴대전화에서는 세로로 쌓아 보여주는 방식이 대표적입니다.

Figma에 PC용과 모바일용 화면을 만들었다고 해서 그 사이의 모든 화면 크기에서도 웹페이지가 잘 보이는 것은 아닙니다. 실제 브라우저의 폭을 바꿔가며 확인해야 합니다.

우선 다음 항목부터 확인합니다.

• 글자가 입력창이나 버튼 밖으로 넘어가지 않는지
• 작은 화면에서 가로 스크롤이 생기지 않는지
• 버튼이 누르기 어려울 정도로 작지 않은지
• 오류 안내가 다른 요소에 가려지지 않는지
• 다음 단계로 이동하거나 이전 단계로 돌아갈 수 있는지

위 항목은 자료의 PC·모바일 확인 과정을 실제 작업에 적용할 수 있도록 정리한 예시입니다.

대시보드도 기능을 먼저 정리합니다

대시보드는 주요 정보를 한눈에 확인하고 자주 쓰는 기능으로 이동하는 첫 화면입니다.

자료의 PLOG 대시보드에는 네 가지 주요 기능이 들어갑니다.

1. 반려동물을 등록합니다.
2. 사료, 간식, 장난감, 병원비 등의 지출을 기록합니다.
3. 산책, 놀이, 진료, 수면 등의 일상을 기록합니다.
4. 비용과 활동 시간을 통계로 확인합니다.

대시보드도 화면부터 만들지 않습니다. 모바일과 PC에서 어떤 기능과 정보를 보여줄지 먼저 마크다운 문서로 정리합니다. 가이드를 확인한 뒤 Figma 화면을 만들고, HTML로 옮겨 회원가입 화면과 연결합니다.

이렇게 하면 기능이 늘어나더라도 처음에 정한 디자인 기준을 그대로 이어갈 수 있습니다.

웹페이지를 배포하면 실제 앱도 완성된 것일까요?

배포는 완성된 결과물을 다른 사람이 접속할 수 있는 서버에 올리는 과정입니다.

자료에는 HTML 화면을 서로 연결해 서버에 올리는 단계가 나옵니다. 그다음 별도의 참고 단계에서 PHP와 MySQL을 이용해 실제 기능을 구현합니다.

PHP는 서버에서 요청을 처리하는 프로그래밍 언어이고, MySQL은 정보를 저장하고 불러오는 데이터베이스입니다.

둘을 구분해야 하는 이유는 화면이 보이는 것과 기능이 실제로 동작하는 것이 다른 문제이기 때문입니다.

화면에 보이는 요소	실제로 필요한 기능
회원가입 입력창	입력 내용을 확인하고 계정 정보를 저장합니다.
이메일 인증번호 화면	이메일을 보내고 입력한 번호가 맞는지 확인합니다.
반려견 등록 버튼	등록한 정보를 저장하고 다시 보여줍니다.
가계부 화면	기록을 추가·수정·삭제하고 합계를 계산합니다.
통계 화면	저장된 기록을 바탕으로 결과를 계산합니다.

자료 마지막에는 앱과 데이터베이스 화면도 나옵니다. 다만 공개 슬라이드만으로는 서버 구현과 테스트의 모든 과정을 확인하기 어렵습니다.

따라서 HTML 화면을 만드는 단계와 데이터가 실제로 저장되는 앱을 구현하는 단계는 나누어 볼 필요가 있습니다. ‘배포해 줘’라는 짧은 요청도 무엇을 어디에 배포할지, 서버 환경이 준비되어 있는지에 따라 결과가 달라집니다.

AI에게 맡기기 전에 사람이 정해야 할 것

자료의 작업 순서를 보면 모든 판단을 AI에 한꺼번에 맡기지 않습니다. 사람이 먼저 기준을 정해 문서로 남기고, 나온 결과를 확인한 뒤 다음 단계로 넘어갑니다.

처음이라면 아래 질문부터 정리해보면 됩니다.

• 누가 사용하는 서비스인가요?
• 사용자가 가장 먼저 해야 하는 일은 무엇인가요?
• 이번에 만들 화면은 어디까지인가요?
• 모든 화면이 함께 지켜야 할 규칙은 무엇인가요?
• 디자인만 필요한가요, 실제 데이터 저장까지 필요한가요?
• 어떤 상태가 되면 작업이 끝났다고 볼 수 있나요?

이 내용을 문서로 남겨두면 AI에게 요청하기도 쉽고, 결과가 제대로 나왔는지 판단하기도 수월합니다.

자주 놓치는 부분

연결되면 모든 작업이 가능하다고 생각합니다

자료에는 파일 이름 변경 요청이 도구의 제약으로 처리되지 않은 사례가 나옵니다. 연결에 성공한 것과 필요한 기능을 모두 사용할 수 있는 것은 별개의 문제입니다. 실제로 필요한 작업이 지원되는지는 하나씩 확인해야 합니다.

문서를 만들었으니 결과도 기준을 따를 것이라고 생각합니다

디자인 시스템을 전달해도 생성된 화면이나 코드가 모든 규칙을 정확히 따르지는 않을 수 있습니다. 결과를 기준 문서와 다시 비교해야 합니다.

예쁘게 보이면 수정하기도 쉬울 것이라고 생각합니다

같은 색을 사용한 것처럼 보이는 요소도 내부에는 서로 다른 값이 들어 있을 수 있습니다. 공통 스타일을 바꿨을 때 관련 요소가 함께 바뀌는지 확인해야 합니다.

화면이 넘어가면 회원가입이 구현되었다고 생각합니다

버튼을 눌러 다음 화면으로 넘어가는 것과 계정 정보를 저장하고 인증하는 것은 다른 기능입니다. 디자인 확인과 기능 테스트를 나누어 진행해야 합니다.

중간 정리

전체 작업 순서는 아래와 같습니다.

단계	결과물	확인할 점
기획	필요한 기능과 사용자 흐름	무엇을 만들 것인가요?
기준 정리	디자인 시스템 문서	화면들이 어떤 규칙을 함께 지켜야 하나요?
화면 가이드	단계별 제작 문서	어떤 화면과 요소가 필요한가요?
Figma 제작	편집할 수 있는 디자인	기준에 맞고 수정하기 쉬운가요?
HTML 생성	브라우저에서 보는 화면	디자인과 실제 화면이 일치하나요?
검토와 수정	확인을 마친 화면과 코드	다른 크기와 상태에서도 잘 보이나요?
기능 구현·배포	실제로 사용할 수 있는 서비스	데이터 저장과 주요 기능까지 동작하나요?

각 단계에서 만든 문서는 다음 작업을 설명할 때도 쓰이고, 완성된 결과를 검토할 때도 쓰입니다.

마치며

Claude와 Figma를 연결하면 디자인을 만들고 코드로 옮기는 과정에서 반복되는 작업을 줄일 수 있습니다. 하지만 화면을 빨리 만드는 것만으로 서비스가 완성되는 것은 아닙니다.

이 자료에서 핵심은 디자인 시스템과 화면 제작 가이드를 먼저 만들고, 완성된 결과를 그 문서와 계속 비교한다는 점입니다.

공통 색상이 모든 화면에 제대로 적용되는지 확인하고, 한 화면만 먼저 코드로 옮겨 차이를 수정한 뒤 나머지 화면으로 범위를 넓힙니다. 화면을 만드는 일과 실제 기능을 구현하는 일도 따로 확인합니다.

처음에는 서비스 전체보다 화면 하나로 이 과정을 경험해보는 편이 낫습니다. 같은 기준을 전달했을 때 어떤 결과가 나오는지, 어느 부분에서 수정이 필요한지 직접 확인할 수 있기 때문입니다.

AI에게 맡기는 일이 많아질수록 무엇을 만들지 설명하는 문서와 결과를 판단할 기준도 더 분명해야 합니다. 이 두 가지가 잘 갖춰져 있으면 처음 만드는 속도뿐 아니라 나중에 수정하고 기능을 확장하는 과정도 한결 수월해집니다.

참고 자료

• Anthropic - Introducing the Model Context Protocol
• Figma - MCP 서버 소개
• Figma - Claude Code와 MCP 연결 설정

본문의 요청문 일부와 검토 항목은 설명을 위해 다시 구성했습니다. 약 15분이라는 작업 시간과 완료 보고는 원자료에 나온 사례이며 별도로 재현하지 않았습니다.