실제 콘텐츠를 넣으면 컴포넌트가 작동하지 않는 문제점을 발견하고, 이를 Figma에서 해결하는 방법

레이아웃 버그를 핸드오프(handoff) 후에 찾는 대신, Figma에서 찾기 시작한 경험.

제가 디자인했던 모든 컴포넌트는 파일 내에서 완벽해 보였습니다.

자리 표시자 텍스트 두 줄. 짧은 이름. 소수점 앞에 한 자리 숫자가 있는 가격. 저는 만족스러운 마음으로 그것을 전달했습니다.

그런 다음 실제 콘텐츠가 나타났습니다.

레이블이 번역되면서 버튼 바로 옆으로 흘러나갔습니다. 누군가의 성(surname)이 세 번째 줄로 감겨서 카드의 가격을 밀어냈습니다. 그리고 빈 필드는 아무도 스타일링하지 않았던 간격을 남겼는데, 그 이유는 제 파일에서는 그 필드가 결코 비어있지 않았기 때문입니다.

이것들은 심각한 버그가 아니었습니다. 단지 아무도 찾지 않던 버그들이었을 뿐입니다. 저 자신조차도 마찬가지였습니다.

저의 '과정' (그렇게 부를 수 있다면)
제가 올해 작업했던 디자인 시스템에서, 저는 이런 문제들을 잡아내는 일련의 루틴이 있었습니다. 과정은 다음과 같았습니다:

1. 컴포넌트 스크린샷을 찍는다.
2. ChatGPT에 붙여넣는다 (당시 OpenAI는 시장의 유일한 주요 AI 플레이어였습니다).
3. 엣지 케이스(edge cases)를 코드로 구현하도록 요청한다. 긴 텍스트, 빈 상태(empty states), 이상한 숫자들 같은 것들.
4. 어떤 부분이 깨졌는지 읽어본다.
5. 코드 상에서 고친다.

효과가 있었을까요? 어느 정도는요.

느렸나요? 매우 느렸습니다. 그래서 제가 불안감을 느끼는 컴포넌트에만 이 과정을 적용했습니다. 신뢰한다고 생각했던 컴포넌트들은 검사받지 못했고, 이것이 우스꽝스러웠는데, 사실 그 부분이 깨지는 곳들이었습니다.

그리고 모든 수정 사항은 코드에 반영되었습니다. Figma 파일은 아무것도 모른 채 남겨졌습니다. 몇 주 후, 디자인과 빌드(build)는 하나씩 핫픽스(hotfix)를 거치며 조용히 멀어져 갔습니다.

그래서 저는 검사 과정을 Figma 내부로 옮겼습니다.

이것은 CalibrateDS Figma 플러그인의 Stress Test 모듈에서 나온 것입니다. 처음부터 기능 아이디어로 시작된 것은 아니었습니다. 제가 1단계부터 5단계까지의 과정에 지겨움을 느껴서 시작하게 된 것이죠.

컴포넌트를 선택하고 'Run'을 누르면, 해당 컴포넌트가 샌드박스 페이지에 복사됩니다. 원래의 컴포넌트는 전혀 건드리지 않습니다. 그런 다음 이 사본을 일련의 콘텐츠 케이스를 통해 실행합니다:

• 원래 디자인 그대로의 원본
• +30%로 복사된 버전
• +60%로 복사된 버전
• 두 배로 늘린 복사본
• 끊어지지 않은 긴 단어
• 숫자
• 빈 상태(empty)

각 케이스는 몇 개의 문제를 발견했는지 보고하며, 각 문제는 문제가 발생한 정확한 레이어로 연결됩니다.

제가 예상하지 못했던 숫자

저는 제가 디자인한 여행 앱의 액티비티 카드에 이것을 실행해 보았습니다. 총 42가지 조합이었습니다.

긴 단어 케이스에서 11개의 문제가 발견되었습니다. 괜찮습니다. 저는 그건 예상했습니다. 이메일이나 제품 코드는 줄 바꿈(wrap)되지 않으니까요.

하지만 원본, 즉 제가 전혀 변경하지 않은 버전에서도 이미 5개가 있었습니다.

다섯 개. 아무것도 늘리기 전부터 말입니다.

이 부분이 저에게 깊은 인상을 남겼습니다. 저는 스트레스 케이스가 무언가를 망가뜨릴 것이라고 생각했습니다. 제 '완성된' 컴포넌트 자체가 이미 망가져 있다는 것은 생각지 못했거든요.

왜 이렇게 지루한 케이스들일까요?
케이스들이 왜 더 과격하지 않은지 궁금하실 수도 있습니다. 400자 이름은 어디에 있나요? 이모지로만 구성된 사용자 이름은요?

솔직히 말해서, 실제로 배포되는 것은 지루한 것들이기 때문입니다.

• +30%는 콘텐츠가 번역되거나 작가가 구절을 하나 더 추가할 때 발생하는 경우와 비슷합니다.
• 두 배로 늘린 버전은 계획했던 것보다 많은 내용을 작성하는 사용자에게 해당됩니다.
• 긴 단어는 이메일 주소, URL, 제품 코드 같은 경우입니다.
• 숫자는 자릿수가 증가하는 가격이나 수량을 의미합니다.
• 빈 상태(empty)는 모두가 잊는 상태입니다.

[

](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fksh3gbby6sriiem6vbzx.png

이것들은 엣지 케이스(edge cases)가 아닙니다. 평범한 일상입니다.

만약 더 기이한 경우를 원한다면, 자신만의 AI 키를 연결할 수 있습니다. 그러면 프로필 카드에 긴 실명이나 가격에 다른 통화 형식 등 해당 컴포넌트에 맞는 콘텐츠 인식 케이스(content-aware cases)를 작성해 줄 것입니다. 이 부분은 선택 사항입니다. 내장된 케이스들은 어떤 AI 도움 없이 실행됩니다.

제가 지금 결과로 하는 일
저는 이슈 개수를 실패한 테스트처럼 취급합니다.

Figma에서 컴포넌트를 수정합니다 (보통 고정 높이로 설정된 텍스트 상자, 누락된 최소 또는 최대 너비, 혹은 채우기(fill) 대신 감싸야 하는 오토 레이아웃 크기 조정 문제입니다). 다시 실행합니다. 그때서야 개발팀에 전달합니다.

수정 사항은 이제 코드뿐만 아니라 디자인 자체에 존재하게 됩니다. 따라서 파일과 빌드가 서서히 멀어지는 것이 아니라 같은 궤도에 머무르게 됩니다.

이것이 실제 환경에서 개발자가 테스트하는 것을 대체할까요? 아닙니다. 단지 명백한 오류들이, 누군가 결코 유지하지 못했을 레이아웃을 기반으로 코드를 작성하기 전에, 가장 빠르게 고칠 수 있는 사람에게 의해 포착된다는 의미일 뿐입니다.

하나의 컴포넌트에 적용해 보세요

제가 여러분께 도전 과제를 드립니다. 가장 신뢰하는 컴포넌트를 하나 골라보세요. 카드, 리스트 행(list row), 긴 레이블 옵션이 있는 버튼 등이 될 수 있습니다. 위에서 제시한 케이스들을 손으로 또는 플러그인을 사용하여 실행해 보고, 원본 디자인에서 몇 개가 깨지는지 세어보세요.

여러분의 숫자를 정말 알고 싶습니다.

또한 제가 사용하는 정확한 체크리스트를 짧은 Markdown 파일로 만들어 드렸으니, 빌드하는 동안 Claude나 Cursor에 붙여넣어 AI가 코드 상에서도 동일한 케이스들을 확인하게 할 수 있습니다. 제 사이트 deepadalja.com/resources에서 무료로 다운로드할 수 있습니다.

CalibrateDS는 Figma에서 무료이며 로컬로 실행됩니다. Figma 커뮤니티에서 CalibrateDS를 검색하거나, calibrateds.deepadalja.com에서 더 많은 정보를 읽어보세요.