이것은 아무도 촬영하지 않는 고된 과정입니다. 데모는 스크린샷에서 끝나지만, 업무는 약 일주일 후, 당신이 자리에 없어도 다른 사람이 열 수 있는 Figma 파일로 마무리됩니다.

또한 이곳은 전체 작업의 약 40%가 머무는 곳이며, 대부분의 AI 보조 디자인이 조용히 실패하는 지점이기도 합니다. 화면이 나빠서가 아니라, 그 안에 있는 그 어떤 것도 다룰 수 없기 때문입니다.

임포트(Import)는 이름을 파괴합니다

생성된 마크업(Markup)을 Figma로 가져오면 모든 것이 프레임 안의 프레임 안의 프레임 형태로 들어오며, 이름은 아무런 의미가 없게 됩니다. 구조는 살아남지만, 의미는 사라집니다.

이 시점에서의 본능은 캔버스에 있는 것부터 컴포넌트화(Componentising)를 시작하는 것입니다. 화면에서 버튼을 찾아 컴포넌트로 만들고 다음으로 넘어가는 식이죠. 그러지 마세요. 그 트리(Tree) 구조는 렌더링 결과물(Rendering artefact)일 뿐입니다. 그것으로부터 라이브러리를 구축하면 그 안에 포함된 모든 우연한 오류까지 물려받게 됩니다. 컴포넌트로 승격된 래퍼 div(Wrapper divs), 마스터(Masters)에 박혀버린 레이아웃 컨테이너, 세 개의 서로 다른 화면에 나타났다는 이유로 세 가지 다른 방식으로 모델링된 동일한 요소들 같은 것 말입니다.

소스 마크업(Source markup)이 바로 명세서(Specification)입니다. 그것은 각 요소가 무엇인지 알고 있습니다. 따라서 첫 번째 단계는 그것을 읽고 무엇이 존재해야 하며 무엇이라 불려야 하는지에 대한 기록을 생성하는 것입니다. 그다음 그 기록에 따라 이름을 변경하고, 그다음에 컴포넌트화하십시오. 이름을 먼저 바꾸고, 컴포넌트화는 두 번째로 하세요. 이 두 순서를 뒤바꾸는 것은 이 단계에서 발생하는 그 어떤 순서 오류보다 더 큰 비용을 초래합니다.

화면보다 라이브러리가 우선입니다

마스터(Masters)는 화면 내부에서 수확하는 것이 아니라, 깨끗한 라이브러리 섹션에서 구축되어야 합니다.

그 차이는 컴포넌트 내부에 최종적으로 무엇이 남느냐에서 나타납니다. 화면에서 수확한 마스터들은 주변 환경을 그대로 가지고 옵니다. 화면에 속해 있던 패딩 래퍼(Padding wrapper), 데모 라벨, 어두운 캔버스에서 보이게 하기 위해 존재했던 배경 같은 것들 말이죠. 그러한 요소들은 모든 인스턴스(Instance)로 전달되며, 6개월 후 누군가는 왜 모든 카드에 8픽셀의 유령 패딩(Phantom padding)이 붙어 있는지 묻게 될 것입니다.

동일한 구조를 가진 요소들은 별개의 컴포넌트로 남겨지는 대신 하나의 베리언트 세트 (variant set)로 그룹화됩니다. 하나의 세트 대신 다섯 개의 서로 관련 없는 컴포넌트로 들어오는 버튼은 제가 여기서 겪는 가장 흔한 오류이며, 이 시점에서 반드시 수정되어야 합니다. 왜냐하면 이후의 모든 작업이 이를 참조하기 때문입니다.

마스터(Master)에서 바인딩하기

색상 (Colour), 유형 (Type), 고도 (Elevation), 효과 (Effects) — 이들은 마스터에서 바인딩되며, 컴포넌트 외부에 존재하는 느슨한 레이어들은 별도로 처리됩니다.

당연해 보이지만 끊임없이 깨지는 두 가지 규칙이 있습니다. 첫째, 바인딩 (binding)은 스타일 속성 (style property)만 변경해야 하며, 크기, 위치, 레이아웃 동작 (layout behaviour) 또는 제약 조건 (constraints)을 방해해서는 안 됩니다. 둘째, 가장 가까운 값으로 스냅 (snapping)하지 마십시오. 모든 것을 고쳐주겠다고 제안하는 체크 도구는 추측을 제안하는 것입니다. 시각적으로 가장 가까운 값에 안착하는 추측이야말로, 아무도 선택하지 않은 의미가 시스템에 조용히 스며드는 바로 그 방식입니다. 체크 도구는 문제를 찾는 용도로만 사용하십시오. 수정은 직접 결정해야 합니다.

스와핑(Swapping)은 실제 콘텐츠를 잡아먹습니다

화면 레이어가 인스턴스 (instances)로 스와핑될 때, 오버라이드 (overrides)에는 실제 카피(copy) — 즉, 실제 이름, 실제 가격, 누군가가 작성한 실제 텍스트가 포함되어 있습니다.

주의 없이 대량 스와핑 (bulk swap)을 실행하면 이 모든 것이 마스터의 플레이스홀더 (placeholder) 콘텐츠로 교체되며, 나중에야 화면에서 이를 발견하게 됩니다. 이는 전체 단계에서 가장 비용이 많이 드는 작은 실수입니다. 왜냐하면 그 피해가 소리 없이 분산되어 있으며, 운 좋게 적절한 화면을 확인했을 때만 보이기 때문입니다.

따라서 다음과 같이 하십시오: 먼저 대표 화면 하나를 선택하여, 전후 상태를 직접 눈으로 확인하십시오. 그다음 나머지를 진행하십시오. 매번 말입니다. 배치 (batch) 작업이 바로 앞에 있고 에이전트 (agent)가 자신감 있게 들릴 때, 파일럿 테스트를 하는 것이 낭비처럼 느껴질 수 있습니다. 하지만 그 자신감이 바로 신호입니다. 에이전트는 한 개의 올바른 결과물을 만들었든 백 개의 잘못된 결과물을 만들었든 동일하게 보고하기 때문입니다.

MCP가 제 역할을 하는 곳

어떤 컴포넌트 구조는 스크립트로 작성된 빌드 (scripted build)가 형성할 수 있는 것보다 더 복잡합니다. 중첩된 베리언트 (nested variants), 상호작용하는 상태 (states), 그리고 무엇이 내부에 포함되어야 하고 무엇이 그렇지 않은지에 대한 판단이 필요한 구조들이 그러합니다.

에이전트 연결 (agent connection)을 통해 Figma를 직접 제어하는 것이 가치를 발휘하는 지점이 바로 여기입니다. 실제 상태 (states)를 가진 컴포넌트를 구축한 다음, 이를 화면에 교체해 넣는 방식입니다. 사람이 형태를 결정하고, 도구는 반복 작업을 수행합니다.

다만, 이 방식이 결과물을 직접 확인하지는 못한다는 점이 있습니다. 도구는 명령이 실행되었다고 보고할 뿐, 화면이 제대로 보이는지는 보고하지 않습니다. 따라서 루프는 동일하게 유지됩니다: 도구가 구축하면, 사람이 확인하고, 다시 반복합니다.

그다음 모드를 전환하세요

이 모든 과정이 완료되었다고 판단하기 전에, 테마를 전환하여 이미 승인했던 버전과 비교해 보십시오.

만약 Figma가 틀렸고 소스 (source)가 맞다면, 바인딩 (binding)이 잘못된 것입니다. 바인딩을 수정하십시오. 만약 둘 다 틀렸다면, 문제는 시스템 자체의 상류 (upstream) 단계에 있는 것이므로, 그곳에서 문제를 수정하고 변경 사항을 앞으로 가져와야 합니다. 절대로 해서는 안 될 일은 Figma 파일만 패치하는 것입니다. 그렇게 하면 서로 일치하지 않는 두 개의 진실의 원천 (sources of truth)을 갖게 되며, 누군가 파일을 다시 빌드할 때까지 파일이 모든 논쟁에서 승리하게 될 것입니다.

솔직히, 이것이 가져다주는 이점

제대로 수행한다면, 이는 수동 마무리 작업의 약 70~80%를 제거해 줍니다. 100%는 아닙니다. 오류가 있을 것이고, 수동으로 수정하는 단계가 있을 것입니다. 단 한 번의 클릭으로 완벽한 파일을 만들어준다고 약속하는 사람은 아직 제품을 출시해 본 적이 없는 사람입니다.

하지만 프로젝트에서 가장 흥미롭지 않은 작업의 70~80%를 줄여준다는 것은 실제적인 수치이며, 이는 단순히 예쁜 스크린샷에서 끝나는 워크플로우와 핸드오프 (handoff)까지 이어지는 워크플로우 사이의 차이를 만듭니다.

이것이 해결하지 못하는 것

무엇이 컴포넌트가 되어야 하는지는 결정하지 못합니다. 그것은 무엇이 반복될지 무엇이 반복되지 않을지에 대한 판단이며, 증거가 나타나기 전에 내려지는 판단입니다. 저 역시 생소한 제품 유형에 대해서는 여전히 판단을 틀리곤 합니다.

그리고 개발자가 실제로 파일을 열어보기 전까지는 "개발자가 즉시 시작할 수 있다"라는 주장보다 "핸드오프 준비 완료"라는 표현이 더 안전한 주장입니다. 저는 전자의 표현을 쓰는 법을 배웠습니다.

실제 프로젝트 하나에 기록된 전체 과정

저는 하나의 프로젝트를 통해 — 브리프 (brief), 구조와 흐름 (structure and flows), 생성된 화면 (generated screens), 잠긴 토큰 시스템 (locked token system), 실제 컴포넌트와 변수 (variables)가 적용된 Figma, 클릭 가능한 프로토타입 (clickable prototype), 개발자 핸드오프 (developer handoff) — 그리고 그 과정에서의 오류들까지 포함하여, 처음부터 끝까지의 전체 경로를 기록했습니다:

Claude AI UI/UX: 브리프부터 Figma까지의 전체 워크플로우 (Complete Workflow from Brief to Figma) — 실제 프로젝트 하나에서 브리프부터 Figma 핸드오프까지 이어지는 동일한 경로를 다룹니다.

만약 대량 교체 (bulk swap) 과정에서도 실제 콘텐츠를 유지할 수 있는 신뢰할 만한 방법을 찾으셨다면, 꼭 알려주시기 바랍니다. 그 부분은 여전히 제 시간을 많이 잡아먹고 있습니다.