8장. AI가 잘 읽는 파일의 조건 — 레이어 명명, 자동 레이아웃, 시맨틱 구조의 중요성

이제 파일은 사람만 보는 문서가 아니다

예전의 정돈된 피그마 파일은 주로 사람을 위한 것이었다. 내가 다시 열어봐도 덜 헤매고, 동료가 들어와도 어디가 어디인지 알 수 있고, 개발자에게 넘길 때 설명이 조금 줄어드는 정도였다. 그런데 2026년의 파일 정리는 그보다 훨씬 큰 의미를 가진다. 이제 파일은 동료 디자이너뿐 아니라 AI 에이전트와 코드 생성 도구도 읽는다. 디자이너에서 개발자로 이어지던 핸드오프가, 점점 디자이너에서 에이전트로 이어지는 흐름으로 바뀌고 있기 때문이다.¹

여기서 중요한 사실이 하나 있다. AI는 당신의 화면을 감탄하며 보지 않는다. 버튼이 예쁜지, 카드가 세련됐는지부터 판단하지 않는다. 먼저 보는 것은 구조다. 이름, 계층, 제약, 토큰, 오토 레이아웃, 컴포넌트, 변형, 그리고 그 사이의 관계다.²³

그래서 이 장의 핵심은 단순하다.

정돈된 파일은 협업을 편하게 만드는 수준을 넘어, AI가 의도를 덜 오해하게 만드는 설계다.

AI는 픽셀이 아니라 구조를 읽는다

MCP나 Dev Mode, AI 코딩 에이전트 같은 도구가 피그마 파일을 읽을 때 받는 것은 한 장의 예쁜 스크린샷이 아니다. 그들은 레이어와 프레임 이름, 부모-자식 관계, 오토 레이아웃의 방향과 간격, 적용된 변수와 스타일, 컴포넌트와 변형, 제약 조건 같은 구조화된 정보를 본다.¹³

쉽게 말하면 AI는 캔버스를 그림처럼 보는 것이 아니라, 나무 구조처럼 읽는다. 루트 프레임 아래에 어떤 섹션이 있고, 그 안에 어떤 카드가 있고, 카드 안에는 제목·설명·버튼이 어떤 순서로 들어 있는지 추적한다. 이 구조가 명확하면 HTML도 비교적 자연스럽게 나온다. 반대로 구조가 흐리면 AI는 안전한 길을 택한다. 의미 없는 래퍼를 많이 만들고, 절대 위치를 남발하고, 클래스 이름도 대충 뽑는다. 보기엔 비슷해도 유지보수는 엉망이 된다.³

결국 AI가 생성하는 코드 품질은 모델의 영리함만으로 결정되지 않는다. 파일이 얼마나 읽기 좋은 문장으로 쓰였는지도 똑같이 중요하다.

이름이 곧 힌트다

사람도 Frame 1268을 보면 잠깐 멈춘다. AI도 마찬가지다. 다만 사람은 눈치로 버티지만, AI는 그 이름을 그대로 단서로 삼는다. 그래서 레이어와 프레임 이름은 보이는 모양보다 역할과 의도를 설명해야 한다.²⁴

예를 들어 Rectangle 12보다는 cta-button-background가 낫고, Group 5보다는 pricing-card-content가 낫다. Vector 3보다는 icon-arrow-right가 훨씬 낫다. 좋은 이름은 적어도 두 가지 중 하나를 알려 준다. 이것이 무엇인지, 혹은 무엇을 하는지다.

실무에서는 이름을 지을 때 이런 감각이 유용하다. 누군가 이 레이어 이름만 보고도 대략적인 태그나 컴포넌트 역할을 상상할 수 있어야 한다. header-nav, product-image, form-group, error-message, primary-button 같은 이름은 구조를 읽는 데 도움이 된다. 반면 blue-box, left-text, big-frame처럼 모양이나 위치만 말하는 이름은 화면이 조금만 바뀌어도 금세 거짓말이 된다.

이름 규칙은 팀마다 조금 달라도 된다. kebab-case를 쓰든, 코드베이스에 맞춰 PascalCase를 쓰든 괜찮다. 더 중요한 것은 한 파일 안에서, 더 나아가 한 팀 안에서 일관되게 쓰는 것이다.³⁴ AI에게 가장 나쁜 것은 완벽하지 않은 규칙이 아니라, 규칙이 없는 상태다.

계층은 HTML처럼, 깊이는 얕게

좋은 파일은 위에서 아래로 읽었을 때 페이지 구조가 자연스럽게 보인다. page > header > nav-list, page > hero-section > hero-content, page > pricing-section > pricing-card처럼 묶여 있으면 사람도 읽기 쉽고 AI도 문맥을 파악하기 쉽다.³

반대로 한 프레임 아래에 50개의 레이어가 평평하게 깔려 있으면 문제가 생긴다. 무엇이 같은 섹션인지, 어떤 텍스트가 어느 카드에 속하는지, 무엇이 배경이고 무엇이 콘텐츠인지 판단하기 어려워진다. 또 너무 깊은 중첩도 좋지 않다. 의미 없는 래퍼가 여섯 겹, 일곱 겹 쌓이면 AI는 그 깊이를 그대로 코드에 옮겨서 div 숲을 만든다.³⁴

경험적으로는 3~4단계 정도가 가장 다루기 좋다. 페이지, 섹션, 블록, 아이템 정도면 대부분 충분하다. 그보다 깊어질 때는 한 단계씩 이렇게 물어보면 된다. 이 래퍼는 정말 의미가 있는가. 정렬을 위해 잠깐 생긴 껍데기인가, 아니면 정보 구조를 설명하는 단위인가.

여기서 또 하나 중요한 점이 있다. 아무 생각 없이 Group을 늘리는 습관이다. Group은 잠깐 묶는 데는 편하지만, 레이아웃 의도까지 잘 전달해 주지는 못한다. 섹션과 컨테이너는 가능하면 프레임으로 만들고, 필요한 곳에는 오토 레이아웃을 부여하는 편이 훨씬 읽기 좋다.

자동 레이아웃은 AI에게 문법이다

오토 레이아웃은 이제 단순한 정렬 기능이 아니다. AI에게는 문법에 가깝다. 가로인지 세로인지, 요소 사이 간격이 얼마인지, 패딩이 얼마나 필요한지, 콘텐츠가 늘어나면 어디가 함께 커져야 하는지 같은 정보를 가장 선명하게 전달하기 때문이다.²³

오토 레이아웃이 없는 프레임을 AI가 읽으면 종종 모든 것을 좌표로 이해한다. 그러면 결과물은 익숙한 악몽이 된다. position: absolute가 곳곳에 붙고, 해상도가 조금만 달라져도 레이아웃이 무너진다.³

반대로 오토 레이아웃이 잘 잡힌 프레임은 Flexbox나 Grid로 번역하기 쉽다. 방향, 정렬, gap, padding이 코드의 구조와 거의 곧바로 연결되기 때문이다.¹²

실무에서는 다음 네 가지만 지켜도 품질이 크게 오른다.

• 정렬된 요소가 둘 이상 있으면 먼저 오토 레이아웃 적용 가능성을 본다.

• gap과 padding을 명시하고, 눈대중 간격을 빈 레이어로 만들지 않는다.

• Hug contents, Fill container, 고정 크기를 의도에 맞게 구분한다.

• 프레임 폭을 실제로 늘리고 줄여 보면서 예상대로 반응하는지 확인한다.²

마지막 항목이 특히 중요하다. AI에게 넘기기 전에 프레임을 직접 흔들어 보는 것이다. 사람이 흔들어서도 깨지는 레이아웃은 AI가 읽어도 대체로 깨진다.

변수, 텍스트 스타일, 컴포넌트는 의미를 잠그는 장치다

앞 장들에서 변수와 컴포넌트를 따로 다뤘다면, 이 장에서는 그것을 다른 각도에서 보자. 변수와 스타일, 컴포넌트는 재사용을 위한 도구이기도 하지만 동시에 AI에게 의미를 고정해 주는 장치다.²⁴

색을 직접 #2563EB로 칠해 두면 AI는 그저 파란색 하나를 본다. 하지만 color/action/primary 같은 변수로 연결되어 있으면, 이것이 브랜드의 대표 동작색이라는 힌트를 받는다. 텍스트도 마찬가지다. 매번 수동으로 16px, 24px, 32px를 흩뿌리는 대신 Heading/H1, Body/Default, Caption 같은 이름 있는 스타일을 쓰면 위계가 분명해진다.³

컴포넌트와 변형은 더 직접적이다. 버튼을 열 개 복제해 둔 파일보다, 하나의 Button 컴포넌트에 variant=primary, state=disabled, size=md 같은 구조가 있는 파일이 훨씬 읽기 쉽다. AI는 여기서 재사용 규칙을 발견하고, 반복되는 코드를 하나의 컴포넌트로 묶어 낼 가능성이 높아진다.²⁴

여기에 Code Connect 같은 연결까지 있다면 더 좋지만, 그 이전 단계에서도 이미 차이는 크다. 파일이 스스로 의미를 설명하고 있느냐가 먼저다.

이미지는 한 덩어리로 붙이지 말자

AI가 어려워하는 것 중 하나가 이미지의 역할 분리다. 배경과 피사체가 한 장의 래스터 이미지 안에 뒤엉켜 있으면, 어디까지가 장식이고 어디부터가 콘텐츠인지 정확히 나누기 어렵다.³⁴

실무에서는 배경 이미지는 가능하면 프레임의 Fill로 처리하고, 실제 콘텐츠로 읽혀야 하는 사진이나 일러스트, 아이콘은 별도 레이어로 분리하는 편이 좋다. 예를 들어 히어로 섹션이라면 배경 풍경은 프레임 채우기로 두고, 제품 사진은 product-hero-image 같은 별도 레이어로 두는 식이다.

아이콘도 마찬가지다. UI 아이콘을 PNG로 붙여 넣으면 AI는 그 안에서 구조를 뽑아내기 어렵다. 가능하면 벡터나 아이콘 컴포넌트로 유지하는 편이 낫다. icon-search, icon-menu, icon-check-circle처럼 이름이 붙은 작은 컴포넌트는 코드로 넘어갈 때도 훨씬 깔끔하다.³

한마디로, 이미지는 보기에는 한 장이어도 역할은 한 장이 아닐 수 있다. 그 역할을 분리해 두는 것이 중요하다.

숨긴 레이어도 AI에겐 잡음이 된다

사람은 숨겨 둔 레이어를 어느 정도 무시할 수 있다. 하지만 AI는 파일 안에 존재하는 정보를 꽤 성실하게 읽는다. 그래서 숨긴 레이어, 빈 프레임, 버려진 시안, 화면 바깥에 밀어 둔 임시 요소는 생각보다 큰 잡음이 된다.³

특히 이런 것들이 위험하다. 예전에 쓰던 버튼 복사본, 꺼 둔 배너 시안, 0% 투명도로 남겨 둔 메모, 비어 있는 컨테이너, 화면 밖에 대피시켜 둔 아이콘 묶음이다. 사람 눈에는 "정리 안 한 작업 흔적"이지만, AI에게는 "여전히 존재하는 구조"가 될 수 있다.

그래서 핸드오프 직전에는 꼭 청소 시간이 필요하다. 숨김 처리로 끝내지 말고 정말 필요 없는 것은 삭제한다. 이미 정리된 이름이 부족하다면 Figma의 AI 기반 Rename layers 같은 보조 도구를 활용해 초안을 만들 수 있지만, 최종 검수는 반드시 사람이 해야 한다.⁵

자동 이름 바꾸기는 청소 도우미이지, 판단을 대신하는 팀 리더는 아니다.

반응형 의도는 한 프레임보다 두 프레임이 더 잘 말해 준다

아무리 파일이 잘 정리되어 있어도 데스크톱 시안 한 장만 있으면 AI는 모바일에서 무엇을 포기하고 무엇을 유지해야 하는지 추론해야 한다. 추론은 때때로 훌륭하지만, 제품 출시 일정에서는 종종 비싸다.

그래서 가능하면 최소 두 개의 대표 브레이크포인트를 같이 준비하는 편이 좋다. 예를 들어 homepage-desktop, homepage-mobile처럼 이름을 맞추고, 같은 섹션 구조를 유지한 상태에서 달라지는 배치를 보여 주는 것이다.³

이때 핵심은 화면 수를 늘리는 데 있지 않다. 반응형 의도를 보여 주는 데 있다. 데스크톱에서는 3열 카드 그리드가 모바일에서 1열로 바뀌는지, 상단 내비게이션이 햄버거 메뉴로 접히는지, 카드 안의 정렬이 가로에서 세로로 전환되는지를 드러내야 한다.³

즉, 반응형은 결과물의 개수가 아니라 구조 변화의 규칙이다. AI는 그 규칙을 볼 수 있어야 더 나은 미디어 쿼리와 레이아웃 전환을 만든다.

주석은 픽셀 밖의 의도를 보충한다

아무리 구조가 좋아도 시각만으로는 다 전달되지 않는 정보가 있다. 클릭 범위, 호버 행동, 키보드 포커스, 접근성 요구사항, 로딩 상태에서의 처리 같은 것들이다. 이런 부분은 주석과 애너테이션이 큰 힘을 발휘한다.²⁴

특히 다음 같은 내용은 짧게라도 남겨 두면 좋다.

• 카드 전체가 클릭 대상인지, 안의 버튼만 클릭 대상인지

• 포커스 시 어떤 요소가 먼저 선택되어야 하는지

• 메뉴 버튼에 aria-expanded 같은 접근성 상태가 필요한지

이런 메모는 사람 개발자에게도 도움이 되지만, AI 에이전트가 코드를 만들 때 기능적 의도를 덜 놓치게 해 준다. 디자인은 보이는 것만으로 완성되지 않는다. 행동 규칙까지 함께 있어야 더 정확히 구현된다.

실무용 점검표: AI에게 넘기기 전 10분

복잡한 원칙도 결국은 점검 습관으로 바뀌어야 오래 간다. 실무에서는 핸드오프 전에 아래 항목만 빠르게 봐도 큰 사고를 많이 줄일 수 있다.²⁴

• 의미 없는 이름인 Frame, Group, Vector, Rectangle가 주요 레이어에 남아 있지 않은가

• 페이지 구조가 섹션 단위로 묶여 있는가

• 정렬된 프레임에 오토 레이아웃이 적용되어 있는가

• gap, padding, 정렬 방향이 명시되어 있는가

• 반복 요소가 컴포넌트와 변형으로 정리되어 있는가

• 색, 간격, 반경, 타이포가 가능한 한 변수와 스타일에 연결되어 있는가

• 배경 이미지와 콘텐츠 이미지가 분리되어 있는가

• 숨겨진 레이어, 빈 프레임, 구버전 시안이 제거되었는가

• 데스크톱과 모바일처럼 대표 브레이크포인트가 준비되어 있는가

• 시각만으로 알기 어려운 상호작용과 접근성 규칙에 주석이 있는가

이 목록을 보면 대단한 비밀은 없다. 결국 좋은 파일 습관의 다른 이름일 뿐이다. 다만 차이가 있다면, 이제 이 습관은 팀 예절이 아니라 AI 정확도의 핵심 변수라는 점이다.

같은 화면도 구조에 따라 전혀 다른 결과를 낳는다

예를 들어 결제 페이지를 만든다고 해 보자. 정리가 안 된 파일은 대개 이런 식이다. 메인 프레임 아래에 텍스트와 박스와 아이콘이 줄줄이 놓여 있고, 카드처럼 보이는 묶음은 사실 Group 몇 개로만 엮여 있다. 버튼도 화면마다 조금씩 다른 복사본이다. 이런 파일을 읽은 AI는 대체로 비슷한 모양의 코드는 만들 수 있어도, 재사용 가능한 구조까지는 잘 못 간다.

반대로 구조가 좋은 파일은 보통 이렇게 읽힌다. checkout-page-desktop 아래에 order-summary-section, payment-method-section, billing-form, primary-action-bar가 있고, 각 섹션은 다시 summary-card, form-group, field-label, text-input, pay-button처럼 의미 있는 단위로 나뉜다. 버튼은 Button 컴포넌트의 인스턴스이고, 간격과 색은 변수에 연결되어 있으며, 모바일 프레임도 나란히 준비되어 있다.

겉으로는 둘 다 비슷한 결제 화면이다. 하지만 AI 입장에서는 완전히 다른 문제다. 하나는 픽셀 맞추기 퀴즈이고, 다른 하나는 구조 읽기 시험이다. 당연히 두 번째가 훨씬 잘 풀린다.

기억해야 할 한 문장

정돈된 파일은 예쁜 파일이 아니라, 의도가 손실 없이 전달되는 파일이다.

사람끼리 일할 때도 그랬지만, AI와 함께 일하는 시대에는 이 원칙이 훨씬 더 중요해졌다. 레이어 이름 하나, 오토 레이아웃 하나, 쓸모없는 숨김 레이어 하나가 사소해 보일 수 있다. 하지만 그런 사소한 것들이 쌓여서 결국 코드의 품질, 핸드오프의 속도, 수정 비용, 그리고 팀의 신뢰를 결정한다.

이제 파일 위생은 정리벽의 문제가 아니다. 출시 속도를 좌우하는 설계 역량이다.

참고

¹How to structure Figma files for MCP and AI-powered code generation

²Structure your Figma file for better code

³10 Golden Rules for Organizing Figma Files That AI Agents Can Actually Read

⁴Figma File Best Practices - Dev Guides

⁵Figma AI in 2026: Everything it can do — and what it still can't