final_FINAL_v3라는 태그가 붙은 Figma 파일을 열었는데, 이름 없는 프레임 30개, 잠겨 있는 배경 레이어, 그리고 무작위 장식용 원과 함께 그룹 안에 중첩된 버튼을 발견했습니다. 이는 생각보다 흔한 일입니다. 이러한 혼돈을 Codex와 같은 AI 코딩 도구에 입력하면, 출력물은 입력값을 그대로 반영합니다. 거대 언어 모델(LLM) 시대에도 "Garbage in, garbage out(쓰레기가 들어가면 쓰레기가 나온다)" 원칙은 여전히 유효합니다.
엉망인 핸드오프의 실체
디자이너는 빠르게 작업합니다. 프레임을 복제하고, 이전 작업물을 그대로 남겨두며, 구조화된 오토 레이아웃(auto-layout) 대신 눈대중으로 정렬하곤 합니다. 결국 기능적인 버튼 옆에 "Frame 3827" 같은 레이어 이름이 놓이게 됩니다. 주요 CTA(Call-to-Action) 버튼이 장식용 그라데이션 블롭(blob)과 같은 그룹에 묶여 있기도 합니다. 디바이스 목업은 실제 인터페이스를 마치 콘텐츠처럼 보이는 외곽 프레임(chrome)으로 감싸고 있습니다. 숨겨진 레이어들은 파일에 그대로 남아 자동 파서(parser)를 혼란스럽게 만들 준비를 하고 있습니다.
Codex를 사용하는 개발자에게 이 문제는 어느 한 쪽의 게으름 때문이 아닙니다. AI는 인간과 같은 패턴 인식 능력이 부족합니다. AI는 레이어 트리를 문자 그대로 읽습니다. 디자이너가 버튼, 헤드라인, 배경 블러를 하나의 평탄화된(flattened) 그룹 안에 넣으면, Codex는 이들을 동일한 구조적 가중치를 가진 형제 요소로 취급합니다. 그 결과, 색상을 검토하기도 전에 구조적으로 망가진 프론트엔드가 만들어집니다.
결과물에 근접하기 위한 워크플로우
단순한 변환기가 아닌 편집자처럼 행동한다면, 엉망인 소스에서도 깨끗한 코드를 뽑아낼 수 있습니다. 목표는 Codex가 정보에 기반한 추측을 할 수 있도록 충분한 컨텍스트를 제공하고, 그 추측이 합리적인 프론트엔드 아키텍처 내에 머물도록 제약을 거는 것입니다.
AI가 보기 전에 모든 것을 추출하세요. Dev Mode를 사용할 수 있다면 활성화하세요. 인스펙트(inspect) 패널에서 가공되지 않은 CSS 속성을 복사하세요. 컬러 변수와 텍스트 스타일을 내보내세요. 이 구조화된 데이터를 프롬프트와 함께 Codex에 입력하세요. 스크린샷은 공간적 진실을 보여주고, 메타데이터는 정확한 hex 코드, 폰트 스택, 행간(line height)을 제공합니다. 어느 하나라도 빠지면 모델은 절반의 정보만 가지고 추측해야 합니다.
프롬프트에서 레이아웃 시스템을 엄격하게 지정하세요. Codex에게 단순히 "이 페이지를 코딩해줘"라고 요청하지 마세요. 무엇을 사용할지 정확히 지시하세요: "네비게이션은 CSS Flexbox로, 대시보드 그리드는 CSS Grid로 구축해줘. 아이콘에 상대적으로 알림 배지를 배치하는 경우가 아니라면 absolute positioning은 사용하지 마." AI 도구는 디자인 파일에서 고정된 x-y 좌표를 직접 파싱하기 때문에 기본적으로 absolute positioning을 사용하는 경향이 있습니다. 명시적인 지침은 이러한 경향을 억제합니다.
스크린샷을 가드레일로 활용하세요. 프레임을 2x 해상도로 내보내세요. 텍스트 컨텍스트와 함께 업로드하세요. Codex가 첫 번째 결과물을 생성하면, 브라우저에서 스크린샷과 나란히 결과물을 띄워놓고 확인하세요. 간격 어긋남, 누락된 테두리, 폰트 두께 불일치 등을 찾아내세요. AI는 대략적인 구도는 정확하게 잡더라도 세부적인 패딩(padding)은 틀리는 경우가 많습니다.
수정을 계획에 넣으세요. 렌더링된 결과물을 시각적 참조 모델과 비교하고 오류를 수동으로 수정하세요. AI는 텍스트 레이블을 이미지 태그로 바꾸거나, 카드를 <article> 또는 <section> 대신 일반적인 div로 감쌀 수 있습니다. 이 검토 단계는 선택이 아닌 필수입니다. 생성된 코드를 실제 프로덕션 코드로 바꾸는 단계이기 때문입니다.
AI가 길을 잃는 지점
주의 깊은 워크플로우를 따르더라도, 특정 유형의 지저분한 패턴은 지속적으로 Codex를 혼란에 빠뜨립니다.
장식적 노이즈(Decorative noise)가 가장 큰 함정입니다. Figma 파일에는 기능적인 인터페이스의 일부가 아닌 배경 글로우, 상태 표시줄 템플릿, 일러스트레이션 아이콘 등이 포함되는 경우가 많습니다. 명확한 레이블이 없으면 AI는 이를 영구적인 DOM 요소로 코딩합니다. 결국 CSS background나 box-shadow로 처리했어야 할 흐릿한 원들을 위해 별도의 div 태그를 만드는 상황이 발생합니다.
평탄화된 계층 구조는 컴포넌트 감지를 방해합니다. 깨끗한 파일에서 카드는 이미지, 제목, 액션 버튼을 포함하는 오토 레이아웃 프레임입니다. 하지만 엉망인 파일에서는 이 세 요소가 루트 레벨에 존재하며, 시각적으로는 정렬되어 있지만 구조적으로는 고립되어 있을 수 있습니다. Codex는 카드의 경계를 완전히 놓치고, 공유된 부모 요소가 없는 평탄한 요소 시퀀스를 출력하게 됩니다.
신호와 노이즈 구분하기
이 초안은 디자인과 AI 생성 코드 사이의 간극을 메울 때 모든 개발자가 직면하는 구체적인 질문을 던집니다.
Figma 메타데이터와 스크린샷 중 무엇을 더 신뢰하시나요?
둘 다 신뢰하되, 용도는 다르게 하세요. 색상, 글꼴 크기, 스페이싱 토큰, 내보낸 에셋과 같은 정확한 값은 Figma 메타데이터를 사용하세요. 구조와 시각적 계층 구조는 스크린샷이 더 유리합니다. 만약 메타데이터에는 레이어가 x: 120, y: 300에 있다고 되어 있지만, 스크린샷에서는 카드 중앙에 배치되어 있다면, 레이아웃은 스크린샷을 믿고 스타일링은 메타데이터를 믿으세요. 스크린샷을 기준점으로 삼고, 인스펙트 패널을 통해 정확한 값을 확인하세요.
UI와 디바이스 프레임을 어떻게 분리하나요?
무엇인가를 내보내기 전에, UI가 아닌 모든 레이어를 숨기세요. 폰 목업이나 데스크톱 크롬을 선택하고 가시성을 끕니다. 파일이 너무 복잡해서 무엇이 템플릿이고 무엇이 콘텐츠인지 구분하기 어렵다면, 여러 화면에서 반복되는 요소를 찾아보세요. 상태 표시줄, 홈 인디케이터, 네비게이션 셸은 보통 동일한 위치에 있습니다. 실제 버튼, 폼, 콘텐츠는 가변적인 중앙 영역에 위치합니다. 모든 화면에서 고정되어 보이는 것은 모두 숨기세요. 그러면 실제 인터페이스만 남게 됩니다.
정리가 잘 안 된 파일에서 컴포넌트 경계를 어떻게 찾나요?
시각적 군집(clustering)을 먼저 찾은 다음, 간격을 통해 확인하세요. 만약 네 개의 요소가 일관된 16px 간격으로 모여 있고 공통된 배경 채우기를 공유한다면, 디자이너가 그룹화하지 않았더라도 하나의 컨테이너에 속할 가능성이 높습니다. Figma 레이어 목록에서 요소들이 연속적으로 쌓여 있는지 확인하세요.