디자인 리뷰에서 제일 자주 나오는 말이에요.

"이거 디자인이랑 다른데요."

그리고 개발자는 이렇게 답해요. "거의 같은데요?"

여기서 공기가 싸해져요. 재밌는 건 둘 다 거짓말을 안 하고 있다는 점이에요. 디자이너 눈엔 다르게 보이고, 개발자 눈엔 같아 보여요. 둘 다 진심이에요.

그럼 뭐가 문제냐면, "다르다"의 기준이 없어요.

취향 싸움처럼 보이지만 아니에요

"이 여백 좀 이상해요" vs "피그마대로 했는데요" — 이 대화는 끝이 안 나요. 양쪽 다 근거가 감각이라서요.

그래서 보통 이렇게 흘러가요. 목소리 큰 쪽이 이기거나, 일정에 쫓겨 그냥 넘어가거나, 개발자가 "그럼 몇 px로 해드릴까요"라고 반쯤 포기한 톤으로 물어요. 셋 다 나쁜 결말이에요. 특히 세 번째는 디자이너를 "픽셀 지적하는 사람"으로 만들어버려요.

20년 하면서 배운 건 이거예요. 이건 취향 문제가 아니라 계약 문제예요. 얼마나 어긋나면 틀린 건지를 아무도 정하지 않았을 뿐이에요.

그래서 숫자로 못 박았어요

hanui 작업하면서 Figma 검증 에이전트를 하나 만들었는데, 거기 이 표가 들어 있어요. 실제 파일(.claude/agents/figma-verifier.md)에 그대로 있는 내용이에요.

속성	허용 오차	초과 시
spacing (padding, margin, gap)	2px	수정
font-size	0px	수정
line-height	2px	수정
border-radius	1px	수정
color (RGB 각 채널)	5	수정
box-shadow	any	수정

이 표가 하는 일은 자동화가 아니에요. 논쟁을 없애는 거예요.

여백이 2px 어긋났다? 넘어가요. 폰트 크기가 1px 다르다? 고쳐요. font-size만 오차 0인 이유는 글자 크기가 어긋나면 줄바꿈이 통째로 달라지기 때문이에요. box-shadow가 any인 건 그림자는 조금만 달라도 재질감이 완전히 달라 보여서고요.

중요한 건 각 숫자가 몇이냐가 아니에요. 팀이 이 표에 한 번 합의했다는 것이 중요해요. 그 뒤로는 "다른데요"가 "3px 초과예요"가 돼요. 감각의 대화가 사실의 대화로 바뀌는 거죠.

진짜 범인은 근삿값 매핑이었어요

같은 파일에 이 규칙도 있어요.

근삿값 매핑 금지 (Figma 15px → Tailwind p-4(16px)로 바꾸지 말 것)

이게 디자이너가 화나는 진짜 이유예요. 그리고 개발자는 자기가 뭘 했는지도 몰라요.

Tailwind를 쓰면 손이 자동으로 p-4, gap-6, rounded-lg로 가요. 스케일에 있는 값이 편하니까요. Figma가 15px이면 16px로, 22px이면 24px로 슬쩍 옮겨 붙여요. 하나하나는 1~2px이라 "거의 같"아요.

문제는 이게 한 화면에 스무 번 일어난다는 것이에요. 개별로는 오차 안이지만, 스무 개가 같은 방향으로 밀리면 화면 전체의 밀도가 달라져요. 디자이너가 "느낌이 다른데 어디가 다른지 못 짚겠다"고 하는 상태가 정확히 이거예요. 어느 한 곳도 안 틀렸는데 전체가 틀린 거죠.

그래서 규칙을 이렇게 뒀어요. 프로젝트 설정에 그 값이 없으면 스케일로 반올림하지 말고 p-[15px]처럼 그냥 그 값을 쓰라고요. 다만 KRDS 토큰과 정확히 맞아떨어지면 토큰을 우선해요. 예쁜 클래스명보다 원본 수치를 지키는 게 먼저예요.

사람이 세지 않게 만들기

기준이 있어도 사람이 눈으로 대조하면 결국 안 해요. 지루하고, 화면 하나에 스무 개씩 나오니까요.

그래서 에이전트가 Figma 노드 데이터와 구현 코드의 스타일 값을 뽑아서 이런 표를 뱉게 했어요.

리뷰 자리에서 이 표를 같이 봐요. 그러면 대화가 이렇게 바뀌어요.

"이거 다른데요" → "padding 4px 초과 1건, 색상 불일치 1건이요"

지적이 아니라 목록이 돼요. 사람이 사람한테 하는 말이 아니라 도구가 뱉은 결과라, 방어할 것도 억울할 것도 없어요. 이게 생각보다 큰 차이예요.

dry-run이 협업 도구였어요

에이전트에 검증만 하고 수정은 안 하는 모드를 넣어뒀어요. 처음엔 안전장치로 만든 건데, 써보니 용도가 달랐어요.

디자이너랑 같이 보는 화면이 되더라고요.

diff 표만 띄워놓고 한 줄씩 넘기면서 "이건 고칠게요", "이건 이유가 있어서 이렇게 뒀어요", "아 그럼 피그마를 고칠게요" 하는 거예요. 마지막 게 핵심이에요. 원본이 틀렸을 가능성이요. 자동 수정만 돌리면 코드가 항상 지고, 디자인 파일의 실수는 영원히 안 드러나요.

그러면 무슨 대화가 남냐면

수치 대화가 사라지면, 남는 게 있어요.

"이 버튼이 여기 있는 게 맞나요?" "이 화면에서 사용자가 제일 먼저 봐야 할 게 뭐예요?" "빈 상태일 때는 뭘 보여주죠?"

이게 원래 디자이너랑 해야 하는 대화예요. 2px 가지고 30분 쓰다가 정작 이런 걸 못 물어보고 스프린트가 끝나는 게, 지난 20년 동안 제일 아까웠던 부분이에요.

디자이너는 픽셀을 지키는 사람이 아니에요. 픽셀을 기계가 지켜주면, 그 사람은 원래 잘하는 일로 돌아가요.

이 방법이 안 통하는 경우

솔직하게 덧붙이면, 전제가 하나 있어요. Figma에 Auto Layout이 잡혀 있고 값이 정리돼 있어야 해요.

수치가 제각각인 파일에서 이걸 돌리면 diff가 200줄 나와요. 그러면 아무도 안 봐요. 이 경우엔 검증 자동화보다 디자인 파일 정리가 먼저예요. 도구가 사람 합의를 대신해주진 않아요. 합의한 걸 지치지 않고 반복해줄 뿐이에요.

정리하면 이래요. 디자이너와의 갈등은 대부분 감각 차이가 아니라 기준 부재예요. 얼마나 어긋나면 틀린 건지 숫자로 합의하고, 그걸 사람이 아니라 도구가 세게 하면, 싸울 일이 거의 안 남아요.

"이거 다른데요"에 "얼마나요?"라고 되물을 수 있으면 이미 절반은 해결된 거예요.

시리즈: 애자일과 프론트엔드

1편: UI 개발자는 디자인을 기다리지 않는다
2편: 스프린트에서 컴포넌트 먼저 만드는 이유
3편: 프론트엔드 추정은 왜 항상 틀릴까
4편: 디자이너와 싸우지 않는 협업법 ← 현재 글
다음 편: PR 리뷰가 병목이 될 때 (예정)

디자이너와 싸우지 않는 협업법

애자일과 프론트엔드 시리즈