16장. 게시와 한계 — Publish, 코드 핸드오프, AI 코드 보안 검토

데모와 출시 사이에는 생각보다 큰 강이 있다

Figma Make를 처음 쓰면 종종 이런 착각이 듭니다. "이 정도면 거의 다 됐는데?" 실제로 그렇습니다. 화면은 살아 있고, 버튼은 눌리고, 흐름도 꽤 그럴듯합니다. 이해관계자에게 보여주기에도 충분하고, 어떤 경우에는 고객 테스트까지 가능해 보입니다.

하지만 여기서 꼭 선을 하나 그어야 합니다. 작동하는 프로토타입과 운영되는 제품은 같은 것이 아닙니다. 전자는 아이디어를 빠르게 검증하기 위한 형태이고, 후자는 장애, 보안, 접근성, 법적 책임, 데이터 처리까지 떠안는 형태입니다. 출시 직전에는 속도보다 책임이 중요합니다. 이 장의 핵심도 바로 그것입니다.

Figma Make의 Publish 기능은 아주 강력합니다. 몇 번의 클릭만으로 결과물을 웹에 올리고, URL을 공유하고, 업데이트하거나 내릴 수도 있습니다.¹ 그래서 더 조심해야 합니다. 올릴 수 있다는 말은 곧, 누군가가 실제로 들어와 보고, 누르고, 믿을 수 있다는 뜻이기 때문입니다.

Publish는 공유가 아니라 공개다

먼저 가장 중요한 구분부터 하겠습니다. Figma Make 파일을 공유하는 것과, Make 결과물을 게시하는 것은 다릅니다.

파일을 공유하면 권한이 있는 사람은 대화 내용, 프롬프트, 작업 맥락까지 볼 수 있습니다. 반면 게시된 웹 앱이나 프로토타입은 공개 웹에 올라가며, 방문자는 결과물만 보지 그 뒤의 대화나 파일 자체에는 접근하지 못합니다.² 이 차이는 작아 보여도 실무에서는 큽니다. 내부 검토 단계에서는 파일 공유가 맞고, 외부 사용자 테스트나 데모 단계에서는 게시 링크가 더 적합한 경우가 많습니다.

게시 자체의 절차는 단순합니다. Make 파일을 열고 오른쪽 위의 Publish를 누른 뒤 제목을 설정하고 게시하면, Figma가 three-random-words.figma.site 같은 공개 URL을 만들어 줍니다. 이후 수정 사항은 자동 반영되지 않고, 다시 Update를 해야 게시본에 적용됩니다. 필요하면 Unpublish로 공개 웹에서 내릴 수도 있고, 나중에 다시 올리면 같은 URL을 재사용합니다.¹

이 단순함이 장점이자 함정입니다. 버튼은 간단하지만, 결정은 간단하지 않습니다.

게시 전에 반드시 잠가야 하는 것들

Publish 창과 Make settings에는 생각보다 중요한 운영 항목이 많이 들어 있습니다. 제목만 넣고 끝내면 안 됩니다.¹

출시 전에는 최소한 다음 항목을 확인해야 합니다.

• Title, Meta description, Language: 제목과 설명은 브라우저 탭, 검색 결과, 소셜 미리보기, 접근성에 영향을 줍니다. 언어 설정은 브라우저 번역과 스크린 리더에도 중요합니다.¹

• Favicon, Social sharing image: 작은 요소 같지만, 외부 공유 시 신뢰감에 큰 차이를 만듭니다.¹

• 검색 노출 여부: 기본적으로 게시된 결과물은 검색 엔진에 잘 드러나지 않지만, 설정에 따라 노출 범위를 바꿀 수 있습니다. 공개 실험인지, 조용한 테스트인지 먼저 정해야 합니다.²

• 접근 범위: Organization·Enterprise 플랜에서는 내부 사용자만 보도록 제한할 수 있습니다. 사내 QA나 제한된 파일럿 테스트에는 이 옵션이 특히 유용합니다.¹

• 폰트 파일: 편집기에서는 멀쩡해 보여도, 게시된 웹에서는 브라우저용 폰트 파일이 없으면 깨질 수 있습니다. Figma는 누락된 웹 폰트를 경고하며, 필요한 경우 WOFF나 WOFF2를 올리라고 안내합니다.¹

이 다섯 가지는 "예쁘게 보이게 하기 위한 설정"이 아닙니다. 사람들이 무엇을 보게 될지, 어디까지 보게 될지, 얼마나 정확하게 보게 될지를 정하는 설정입니다.

링크를 내보내는 순간, 법과 운영이 시작된다

게시된 Make 결과물은 공공 웹에서 접근 가능한 주소를 갖습니다. 즉, 디자인 툴 안의 실험이 아니라, 실제 서비스처럼 취급될 가능성이 생깁니다.¹ 이때부터는 디자인 품질만으로는 부족합니다.

특히 세 가지를 꼭 기억해야 합니다.

첫째, 콘텐츠 권리입니다. Figma는 게시 전 사용 권한을 확인하라고 분명히 안내합니다. Make가 제공한 이미지는 Unsplash 기반일 수 있고, 사용자는 자신의 용도에 맞는 권리 검토를 직접 해야 합니다.¹ "AI가 넣어준 이미지니까 써도 되겠지"는 아주 위험한 생각입니다.

둘째, 데이터 책임입니다. 게시한 결과물이 사용자 정보를 수집하거나 업로드를 받거나 방문자 데이터를 다룬다면, 그 데이터의 관리 책임은 팀에 있습니다.¹ 분석 도구를 달았는지, 폼이 있는지, 로그인 흐름이 있는지에 따라 개인정보 이슈는 바로 현실이 됩니다.

셋째, 호스팅과 노출의 착시입니다. Figma Make는 게시 결과물을 AWS에 호스팅하고, 도메인 라우팅은 Cloudflare를 사용합니다.² 이것은 인프라 정보를 알려줄 뿐, 보안과 법적 의무를 대신 져준다는 뜻이 아닙니다. 도구가 대신 호스팅해도, 책임은 여전히 팀에 남습니다.

커스텀 도메인과 분석을 붙이면, 이제부터는 진짜 운영이다

Figma Make는 게시 결과물에 커스텀 도메인을 연결할 수 있습니다. 또 Google Analytics ID를 직접 넣을 수 있고, 필요하면 head와 body에 커스텀 코드를 추가해 다른 분석 도구도 붙일 수 있습니다.¹²

여기서 많은 팀이 한 단계 더 올라갑니다. "좋아, 이제 진짜로 운영해 보자." 바로 이 지점에서 판단을 더 보수적으로 해야 합니다.

커스텀 도메인을 붙인 결과물은 팀 내부에서는 더 그럴듯해 보입니다. 사용자 입장에서는 거의 실제 서비스처럼 느껴집니다. 하지만 겉모습이 운영처럼 보인다고 해서, 운영 준비가 끝난 것은 아닙니다. 분석 스크립트를 넣었다면 쿠키 동의, 개인정보 고지, 데이터 보관 정책까지 따라와야 합니다. Figma도 이 부분의 준수 책임은 사용자에게 있다고 못 박고 있습니다.¹

즉, 도메인과 분석은 기능 추가가 아니라 책임 추가입니다.

좋은 핸드오프는 링크 하나로 끝나지 않는다

Make 산출물을 개발자에게 넘길 때 가장 흔한 실수는 게시 링크 하나만 던지는 것입니다. 링크는 결과를 보여줄 뿐, 의도를 전달하지 못합니다. 핸드오프에는 최소한 다음 정보가 함께 가야 합니다.

• 무엇이 확정안이고 무엇이 실험안인지

• 어떤 부분이 시각 품질의 핵심인지

• 어떤 인터랙션이 필수 동작인지

• 어떤 부분은 아직 가짜 데이터인지

• 어디까지가 Make 산출물의 책임 범위인지

좋은 핸드오프 패키지는 보통 다음처럼 구성됩니다.

1. 게시된 URL

2. 원본 Figma Make 파일 링크

3. 구현 우선순위가 적힌 짧은 메모

4. 디자인 시스템에서 매핑해야 할 컴포넌트 목록

5. 제외 범위와 알려진 한계

6. QA 기준이나 승인 기준

이렇게 넘겨야 개발자는 "보이는 것"뿐 아니라 "왜 이렇게 되어 있는지"까지 이해할 수 있습니다.

특히 성숙한 팀이라면, Make 결과물을 최종 코드 그 자체로 보기보다 실행 가능한 명세서로 다루는 편이 안전합니다. 이때 큰 도움이 되는 것이 Make kit입니다. 팀의 React 디자인 시스템 패키지를 Make에 연결하면, 프로토타입에서도 실제 프로덕션과 같은 컴포넌트를 사용할 수 있어 디자인과 구현 사이의 번역 손실이 크게 줄어듭니다.³ 다시 말해, 더 좋은 핸드오프는 "AI가 새 코드를 잘 써주길 기대하는 것"이 아니라, 기존의 검증된 시스템을 AI가 벗어나지 않게 만드는 것에 가깝습니다.

한편 Make의 프리뷰는 디자인 레이어로 복사해 Figma Design으로 가져갈 수 있습니다. 다만 이렇게 가져온 레이어는 원래 Make 파일과 자동으로 다시 연결되지 않고, 자동으로 디자인 시스템에 묶이지도 않습니다.⁴ 이것은 편리한 다리이지만, 양방향 동기화 장치는 아닙니다. 따라서 시안 정리에는 유용해도, 운영 소스로 착각하면 안 됩니다.

Make 산출물은 어디까지 믿어야 할까

냉정하게 말하면, Figma Make는 아주 빠른 도구이지만 아직 모든 프로젝트의 최종 핸드오프 도구라고 보기는 어렵습니다. 여러 실사용 리뷰에서 공통적으로 나오는 평가가 있습니다. 초기 프로토타이핑과 제한된 상호작용에는 강하지만, 복잡한 제품의 개발 핸드오프에는 아직 정리가 많이 필요하다는 점입니다.⁵⁶

대표적인 한계는 이렇습니다.

• 코드 구조가 지저분해질 수 있습니다. 리뷰에 따라서는 시맨틱하지 않은 일반 div 위주로 생성되는 경우가 지적됩니다.⁵

• 복잡한 화면이나 다단계 수정에서는 결과 품질이 흔들릴 수 있습니다.⁶

• 수동으로 만진 결과가 다시 프롬프트를 돌릴 때 일부 덮어써질 수 있습니다.⁶

• 상호작용은 살아 있어도, 실제 비즈니스 로직이나 안정적인 데이터 흐름까지 자동으로 보장되지는 않습니다.²

이 말은 곧, Make를 잘 쓰는 팀은 "어디에 쓰면 이기고, 어디에 쓰면 무너지는지"를 안다는 뜻입니다.

Make가 특히 잘 맞는 경우는 다음과 같습니다.

• 아이디어 검증용 클릭 프로토타입

• 마케팅성 마이크로 사이트

• 컴포넌트 단위의 마이크로 인터랙션 실험

• 이해관계자 합의를 빠르게 끌어내야 하는 초기 화면

반대로 바로 운영에 올리기 조심해야 하는 경우도 분명합니다.

• 결제, 인증, 권한 같은 핵심 흐름

• 상태 관리가 복잡한 제품형 웹앱

• 접근성 요구가 높은 공공·교육·의료 서비스

• 장기적으로 유지보수해야 하는 대규모 프론트엔드

핵심은 이것입니다. Make는 제품을 대신 책임지지 않는다. 팀이 책임질 수 있는 범위까지만 Make를 믿어야 한다.

AI 코드 보안 검토는 선택이 아니라 마지막 관문이다

이제 가장 중요한 이야기를 해보겠습니다. Make 산출물이 코드처럼 보인다고 해서, 검토를 건너뛰면 안 됩니다. 출시 직전의 AI 산출물은 반드시 사람 손을 거쳐야 합니다.

검토 포인트는 적어도 여덟 가지입니다.

1. 의존성 출처 확인

어떤 패키지와 외부 리소스를 쓰는지 먼저 봐야 합니다. Figma Make는 인터넷의 폰트, 코드 패키지, 이미지 같은 제3자 콘텐츠를 사용할 수 있다고 안내합니다.⁴ 그러므로 패키지 라이선스, 외부 CDN 의존성, 사용 권한을 체크해야 합니다.

2. 비밀 정보 노출 여부

API 키, 토큰, 데이터베이스 접속 정보가 클라이언트 코드에 그대로 들어가 있지 않은지 확인해야 합니다. 특히 "일단 데모니까" 하며 브라우저에 비밀 값을 넣는 습관은 나중에 가장 큰 사고가 됩니다.

3. 인증과 권한 분리

화면에서 버튼을 숨겼다고 권한 검사가 끝난 것이 아닙니다. 로그인, 관리자 기능, 결제, 파일 업로드는 반드시 서버 쪽 권한 검사가 있어야 합니다. Make 산출물은 종종 UI 흐름을 그럴듯하게 만들지만, 권한 모델까지 자동으로 안전하게 설계해 주지는 않습니다.

4. 입력값 검증

폼이 있으면 XSS, 인젝션, 잘못된 파일 업로드, 과도한 입력 길이 같은 기본 검토가 필요합니다. AI가 만든 폼은 보기엔 자연스러워도, 경계값 처리까지 꼼꼼하지 않은 경우가 많습니다.

5. 접근성 점검

버튼이 정말 버튼인지, 라벨이 연결되어 있는지, 키보드 포커스가 움직이는지, 모달이 열리고 닫힐 때 포커스가 적절히 관리되는지 확인해야 합니다. 코드가 일반 div 중심으로 생성되면 여기서 바로 문제가 드러납니다.⁵

6. 성능 확인

불필요하게 큰 이미지, 중복 로드되는 폰트, 과한 자바스크립트, 느린 초기 렌더링은 데모에서는 숨겨져 있다가 실제 배포에서 문제가 됩니다. 게시 후 휴대폰에서 직접 열어 보는 습관이 필요합니다.

7. 로그와 분석 검토

분석 스크립트가 붙어 있다면 무엇을 수집하는지, 개인 식별 가능 정보가 섞이지 않는지, 동의 배너가 필요한지 검토해야 합니다.¹

8. 유지보수 가능성

폴더 구조, 컴포넌트 분리, 이름 체계, 테스트 가능성까지 봐야 합니다. 당장 돌아간다고 끝이 아닙니다. 다음 주의 수정 요청을 견딜 수 있어야 실제 코드입니다.

이 여덟 가지를 거치지 않은 AI 산출물은, 빠를 수는 있어도 믿을 수는 없습니다.

출시 직전, 팀이 실제로 쓰는 마지막 게이트

실무에서는 복잡한 원칙보다 간단한 게이트가 더 잘 먹힙니다. 저는 Make 산출물을 출시 직전에 아래 순서로 통과시키길 권합니다.

1. 목적 재확인: 이것이 데모인지, 파일럿인지, 실제 운영인지 먼저 구분한다.

2. 게시 범위 결정: 공개 웹, 내부 전용, 비공개 테스트 중 하나를 고른다.¹

3. 운영 설정 점검: 제목, 설명, 언어, 폰트, 도메인, 분석, 검색 노출을 확인한다.¹²

4. 핸드오프 패키지 작성: 링크만 보내지 말고 의도·제한·우선순위를 함께 넘긴다.

5. 코드 검토: 프론트엔드 엔지니어가 구조, 시맨틱, 성능, 보안을 본다.

6. 도메인 책임 검토: 법무, 개인정보, 브랜드, 접근성 요구사항을 체크한다.

7. 최종 결정: 바로 Publish할지, Update만 할지, Unpublish하고 저장해 둘지 결정한다.¹

이 흐름은 느려 보이지만, 실제로는 가장 빠른 길입니다. 왜냐하면 사고 후에 되돌리는 비용이, 출시 전에 한 번 더 검토하는 비용보다 훨씬 크기 때문입니다.

언제 Make를 그대로 내보내고, 언제 레포지토리로 옮겨야 할까

현실적인 기준도 하나 남겨 두겠습니다.

Make에서 바로 게시해도 비교적 안전한 경우가 있습니다. 수명이 짧은 캠페인 페이지, 내부 테스트용 앱, 단일 기능 데모, 핵심 데이터가 없는 마이크로 사이트가 여기에 가깝습니다. 이때도 검토는 필요하지만, 운영 복잡도가 상대적으로 낮습니다.

반대로 반드시 팀의 실제 코드베이스로 옮겨야 하는 경우도 있습니다. 인증, 결제, 관리자 권한, 고객 데이터, 규제 준수, 장기 유지보수가 붙는 순간입니다. 이때 Make는 최종 결과물이 아니라, 구현 품질을 높여 주는 출발점이 되어야 합니다.

좋은 팀은 Make를 두려워하지도 않고, 맹신하지도 않습니다. 빠르게 만들고, 냉정하게 검토하고, 책임질 수 있는 형태로만 출시합니다.

결국 마지막 한 줄은 사람이 쓴다

Figma Make는 핸드오프를 훨씬 짧게 만들었습니다. 어떤 경우에는 화면과 코드 사이의 거리를 거의 없애 보이게도 합니다. 하지만 거리가 짧아졌다고 해서 판단이 사라진 것은 아닙니다.

오히려 2026년의 디자인-개발 협업에서 가장 값비싼 역량은 이것입니다. 무엇을 AI에게 맡기고, 무엇을 사람이 끝까지 책임질지 결정하는 능력 말입니다.

출시 직전에는 멋진 데모보다 믿을 수 있는 판단이 더 중요합니다. Make 산출물은 빠른 출발선이 될 수 있습니다. 그러나 결승선을 통과시키는 마지막 승인 버튼은, 여전히 사람 손으로 눌러야 합니다.

참고

¹Publish, update, or unpublish a Figma Make file

²Figma Make FAQs

³Use your design system package in Make kits

⁴Explore Figma Make

⁵Is Figma Make ready for dev-handoff?

⁶We Tried Figma Make: Pricing, Features, Detailed Review