Figma Code Layers 프로토타입은 어떻게 검수하나요? 2026 디자이너 체크리스트

검수 전에 정해야 할 전달 범위

Figma는 Code Layers를 캔버스 안에서 코드로 구동되는 상호작용 프로토타입을 만드는 기능으로 설명합니다. 공식 안내에 따르면 공개 베타가 순차 제공되고 있으며 GitHub 저장소와 연결하는 작업 흐름도 지원합니다. 다만 베타 제공 상태는 바뀔 수 있고, 캔버스에서 동작한다는 사실은 실제 제품의 품질이나 배포 준비를 보증하지 않습니다.

먼저 이번 검수가 디자인 탐색, 이해관계자 평가, 개발 전달 가운데 무엇을 위한 것인지 합의하세요. 같은 프로토타입도 평가 목적에 따라 통과 기준이 달라집니다.

Figma 코드 프로토타입을 그대로 개발에 넘겨도 될까요? 화면과 상호작용을 논의하는 자료로 전달할 수는 있습니다. 그러나 실제 제품에 적용할 수 있는 코드인지, 접근성이나 보안 요구를 충족하는지, 팀의 코드 검토를 통과했는지는 별도 확인 사항입니다. 개발 담당자가 변경 내용을 검토하고 팀의 절차에 따라 승인하기 전에는 프로토타입을 완성된 제품 코드로 취급하지 마세요.

시각 일치도는 대표 화면과 의도로 판정합니다

정적인 디자인 이미지를 코드로 자동 변환한 뒤 원본과 완전히 일치한다고 가정하면 안 됩니다. 검수 대상은 현재 실행되는 프로토타입의 표현입니다. 대표 화면을 정해 원본 디자인과 나란히 비교하고, 차이가 보이면 위치와 조건을 기록하세요.

화면 전체를 한 번에 평가하기보다 다음 항목을 나누어 살펴보면 수정 요청이 구체적이 됩니다.

• 주요 영역의 배치와 간격이 의도한 시각적 위계에 맞는지 확인합니다.
• 제목, 본문, 버튼의 글꼴 크기와 줄바꿈이 읽기 흐름을 해치지 않는지 봅니다.
• 공통 구성 요소의 모양과 상태가 화면마다 일관적인지 비교합니다.
• 대비가 필요한 텍스트는 WCAG 기준에 맞춰 확인하고, 색상만으로 상태를 전달하지 않는지 살펴봅니다.

차이를 발견하면 “원본과 다름”이라고만 남기지 말고, 어느 화면의 어떤 요소가 어떤 조건에서 달라지는지 적으세요. 수정할 사람과 기대하는 결과를 연결할 수 있어야 합니다.

상호작용은 성공 흐름과 예외 상태를 함께 확인합니다

Figma Code Layers에서 상호작용 상태는 어떻게 확인하나요? 시작 화면에서 주요 작업을 실제로 수행하고, 이동한 화면과 결과가 설계 의도에 맞는지 확인하세요. 한 번의 성공 시연만으로 상호작용 전체가 검증되었다고 판단하지 말고, 제품에서 필요한 빈 상태, 로딩 상태, 오류 상태도 따로 검토합니다.

예를 들어 검색 화면이라면 검색어 입력과 결과 이동뿐 아니라 결과가 없을 때의 안내, 기다리는 동안의 표시, 요청이 실패했을 때의 복구 경로를 구분합니다. 원형에 해당 상태가 없다면 작동한다고 추정하지 말고 “미표현”으로 남겨야 합니다.

간단한 기록 예시는 다음과 같습니다.

화면 또는 흐름:
시작 조건:
기대하는 결과:
실제로 보인 결과:
확인한 브라우저와 창 크기:
미확인 상태:
담당자와 다음 조치:

각 흐름을 따라가며 기대와 실제 결과를 나란히 적으면, 디자인 수정과 기능 구현 요청이 섞이지 않습니다. 프로토타입에서 표현하지 않은 오류 처리를 개발팀이 이미 구현했다고 오해하는 일도 줄일 수 있습니다.

반응형 검수는 실제 목표 크기와 콘텐츠로 진행합니다

반응형 디자인 검수는 특정 화면 크기 하나에서 잘 보이는지 확인하는 작업이 아닙니다. 프로젝트가 지원하려는 창 크기와 콘텐츠 변화 조건을 정하고, 그 조건에서 레이아웃이 어떻게 바뀌는지 살펴보세요. 프로젝트에서 쓰지 않는 기기까지 지원한다고 추측해서 통과 범위를 넓히면 안 됩니다.

Safari에서 반응형 레이아웃을 점검할 때는 WebKit의 Safari 반응형 디자인 모드 안내도 참고할 수 있습니다. 하지만 도구에서 설정한 크기와 실제 사용자 환경은 같은 검증 결과가 아닙니다. 화면이 잘리는지, 글자가 예상과 다르게 줄바꿈되는지, 주요 버튼이 가려지는지 실제 목표 환경에서 확인하고 그 결과만 기록하세요.

저장소 변경은 검토자와 승인 절차까지 추적합니다

GitHub에 연결한 뒤 코드 변경은 어떻게 확인하나요? Figma의 Git 작업 흐름 안내에 따라 저장소 연결과 변경 전달 방식을 먼저 확인한 다음, 대상 브랜치와 변경된 파일을 살펴보세요. 저장소가 연결되어 있거나 변경 요청을 만들 수 있다는 사실은 변경 내용이 팀의 검토를 통과했다는 뜻이 아닙니다.

검수할 때는 변경 전후 차이와 변경 목적이 서로 맞는지 확인합니다. GitHub의 커밋 비교 안내를 참고하면 비교 대상 사이에 무엇이 달라졌는지 확인할 수 있습니다. 팀이 변경 요청 검토를 사용한다면 Pull Request 검토 절차에 따라 담당자가 의견을 남기고 승인하는 흐름을 따르세요.

보호된 브랜치가 설정된 저장소라면 브랜치 보호 규칙도 확인해야 합니다. 팀 규칙상 검토나 승인이 필요한데 이를 거치지 않았다면, 디자이너가 미리보기를 확인했더라도 개발 완료로 처리하지 마세요.

브라우저 확인 결과는 확인한 환경에 한정합니다

프로젝트에서 지원하는 브라우저를 먼저 확인하고, 그 목록을 기준으로 우선순위를 정하세요. Windows에서 확인한 브라우저의 결과를 Safari에도 그대로 적용할 수는 없습니다. 반대로 Safari 사용자가 대상이 아니라면 Mac에서 확인하지 않았다는 이유만으로 검수가 부족하다고 볼 필요도 없습니다.

Safari 웹 검수를 위해 Mac이 필요한가요? Safari 동작이 납품 기준에 포함된다면 Safari가 실행되는 환경에서 확인해야 합니다. 현재 사용할 수 있는 Mac이 없다면, 검수 담당자나 개발팀에 실제 Safari 확인을 요청하거나 Mac 환경에서 다시 점검하는 일정을 잡으세요. 확인하지 않은 브라우저는 통과가 아니라 미확인으로 기록합니다.

사용 가능한 Mac 환경과 접속 방식을 검토해야 한다면 NodeMini의 원격 Mac 서비스 안내에서 이용 방식과 제공 정보를 먼저 확인할 수 있습니다. 브라우저별 결과를 기록할 때는 화면 캡처만 모으기보다, 해당 캡처가 어떤 흐름과 창 크기에서 나온 것인지 함께 남겨야 합니다. 원격 화면으로 접속해 확인하는 경우에도 화면 전송의 지연이나 선명도는 브라우저 자체의 렌더링 결과와 별개의 요소입니다. 원격 화면이 부드럽게 보인다고 호환성이 검증된 것은 아니며, 화면 전송이 불편하다고 곧바로 웹페이지의 동작이 잘못되었다고 단정할 수도 없습니다.

결국 Figma Code Layers 프로토타입은 상호작용과 디자인 방향을 빠르게 논의하는 데 유용하지만, 캔버스 미리보기만으로 실제 제품의 검수가 끝나지는 않습니다. 확인한 화면과 상태, 저장소 변경, 브라우저를 구분해 기록하고, Safari 검수가 납품 조건일 때만 해당 환경을 추가하세요.

Windows에서 만든 디자인을 브라우저 미리보기나 캡처만으로 마무리하면 Safari의 실제 표시를 확인하지 못하고, 개발팀과 환경 차이를 두고 다시 확인하는 일이 생길 수 있습니다. 반면 Mac을 바로 구매하면 Safari 점검이 드문 프로젝트에서도 기기와 관리 부담이 남습니다. Mac에서 직접 검사해야 하는 일정이 정해져 있지만 사용할 기기가 없다면, NodeMini의 원격 Mac 이용 방식을 살펴보고 필요한 기간에 맞는지 판단할 수 있습니다. 원격 화면의 체감은 네트워크와 접속 환경에 따라 달라지므로, 실제 납품 전에는 목표 브라우저에서 직접 확인한 결과를 기준으로 삼으세요.