본문 바로가기
개발자/실무 개발 현장

개발자가 디자이너와 일하면서 겪는 현실

by 나무011 2026. 9. 8.
개발자 현직자 솔직 경험담

개발자가 디자이너와
일하면서 겪는 현실

"이거 왜 시안이랑 다르게 나왔어요?"라는 질문에 제대로 답하지 못했던 날.

입사 초반, 디자이너가 넘겨준 Figma 시안을 그대로 픽셀 단위까지 맞춰서 구현했다고 자부했다. 근데 QA 단계에서 디자이너가 화면을 보더니 이렇게 물었다. "이거 왜 시안이랑 다르게 나왔어요?" 나는 정말 억울했다. 분명 시안 그대로 만들었다고 생각했으니까. 근데 알고 보니 진짜 문제는 픽셀이 아니라, 서로 다른 언어로 대화하고 있었다는 것이었다.

개발자가 디자이너와 일하면서 겪는 현실
개발자가 디자이너와 일하면서 겪는 현실
1년 2개월디자이너와 협업한 기간
23회"시안이랑 다르다" 지적 횟수
4개협업 후 정립한 공통 규칙 수

1. 첫 번째 충돌 — "다르다"의 기준이 서로 달랐다

문제의 화면은 카드 컴포넌트였다. 나는 Figma에서 여백 값을 그대로 픽셀로 옮겼는데, 디자이너 입장에서는 반응형 상태에서의 비율이 다르게 느껴졌다. 나는 "고정값이 같으니 같은 거 아닌가"라고 생각했는데, 디자이너는 "화면 크기별로 비율이 달라 보인다"는 걸 지적하고 있었다.

Figma — 카드 컴포넌트 시안 Comment #14
디자이너 이 카드, 데스크탑에서는 맞는데 태블릿 사이즈에서 이미지 비율이 시안이랑 달라요. 원본 시안 비율 그대로 유지되게 해주실 수 있나요?

이 코멘트를 보고 처음엔 살짝 방어적인 마음이 들었다. "고정 여백은 정확히 맞췄는데"라고 생각했다. 근데 실제로 확인해보니, 나는 고정 px 값으로 여백을 맞췄고, 디자이너는 비율(aspect-ratio) 개념으로 디자인을 생각하고 있었다. 서로 완전히 다른 기준으로 "같다"를 판단하고 있었던 거다.

⚠ 그때 깨달은 것 개발자는 픽셀과 코드 단위로 생각하고, 디자이너는 비율과 시각적 균형으로 생각하는 경우가 많다. "시안대로 만들었다"는 말이 서로에게 완전히 다른 의미일 수 있다는 걸 그때 처음 실감했다.

2. 용어 차이에서 오는 오해들

이후로도 비슷한 오해가 반복됐다. 특히 같은 단어를 다르게 쓰는 경우가 많았다.

디자이너가 말하는 "정렬"
시각적 균형
그리드를 벗어나도 눈에 안정적으로 보이면 "정렬됨"
개발자가 말하는 "정렬"
flex/grid 속성값
코드상 justify-content 등 속성이 명확히 정의된 상태
디자이너 이 버튼 살짝 안 맞아 보이는데, 정렬 좀 맞춰주실 수 있어요?
코드상으로는 center 정렬 되어 있는데, 어느 부분이 안 맞아 보이시나요?
디자이너 아 정확한 center는 맞는데, 아이콘 무게중심 때문에 시각적으로 살짝 오른쪽으로 치우쳐 보여요. 1~2px 정도만 왼쪽으로 옮겨주시면 좋을 것 같아요.

이 대화를 겪고 나서야 "기술적으로 맞는 것"과 "시각적으로 맞아 보이는 것"이 다를 수 있다는 걸 받아들이게 됐다. 처음엔 "코드는 맞는데 왜 자꾸 고치라고 하지"라는 억울함이 있었지만, 최종적으로 사용자가 보는 건 코드가 아니라 화면이라는 당연한 사실을 다시 떠올렸다.

3. 관계가 달라진 계기 — 공통 언어를 만들기 시작하다

반복되는 오해를 줄이기 위해, 팀 차원에서 몇 가지 규칙을 정하기로 했다. 디자이너와 함께 회의를 통해 정리한 내용이다.

규칙 1
여백은 고정값 대신 디자인 토큰(spacing-sm, spacing-md 등) 단위로 통일해서 서로 같은 이름으로 부르기로 함.
규칙 2
반응형 레이아웃은 Figma에 데스크탑/태블릿/모바일 세 가지 프레임을 모두 포함해서 전달받기로 함.
규칙 3
"정렬이 안 맞아 보인다" 같은 시각적 피드백은 스크린샷에 직접 표시해서 전달하기로 함.
규칙 4
기술적 제약(성능, 접근성 등)으로 시안과 다르게 구현해야 할 경우, 이유를 먼저 설명하고 대안을 함께 제시하기로 함.

이 규칙을 적용한 이후로 "시안이랑 다르다"는 지적 자체가 눈에 띄게 줄었다. 단순히 규칙 때문이 아니라, 서로가 어떤 기준으로 판단하는지 이해하게 되면서 애초에 오해가 생길 여지가 줄어든 거였다.

// 규칙 1 적용 후 - 디자인 토큰으로 여백 통일 const spacing = { sm: "8px", // 디자이너: "spacing-sm"으로 지칭 md: "16px", // 개발자: 코드에서도 동일한 이름 사용 }; // Before: 각자 다른 방식으로 이해 // gap: 16px (개발자) ↔ "카드 사이 여백" (디자이너, 모호함) // After: 공통 용어로 소통 // gap: spacing.md (양쪽 모두 "spacing-md"로 지칭)
협업 초반 — "시안과 다름" 지적 빈도9 / 10
 
공통 규칙 도입 후 3개월 — 지적 빈도4 / 10
 
1년 후 — 지적 빈도1.5 / 10
 

4. 지금은 디자이너가 오히려 가장 편한 협업 파트너

1년이 지난 지금은 디자이너와의 협업이 오히려 가장 매끄러운 관계가 됐다. 서로 다른 방식으로 생각한다는 걸 인정하고 나니, 오히려 서로가 놓친 부분을 채워주는 관계로 바뀌었다. 최근에는 디자이너가 먼저 "이 인터랙션, 기술적으로 구현 가능한지부터 여쭤보고 시안 잡을게요"라고 먼저 확인해주는 경우도 늘었다.

💡 지금 돌아보며 하고 싶은 말 디자이너와의 갈등은 대부분 실력이나 태도의 문제가 아니라, 같은 단어를 다르게 쓰고 있다는 걸 몰라서 생기는 경우가 많았다. 초반에 서로의 용어와 판단 기준을 맞춰보는 시간을 가지면, 이후 협업이 훨씬 부드러워진다.
1년 2개월 후 결론

처음엔 디자이너의 피드백이 "트집 잡는 것"처럼 느껴졌던 순간도 있었다. 하지만 결국 같은 목표(사용자가 보는 화면)를 서로 다른 언어로 이야기하고 있었을 뿐이라는 걸 깨닫고 나서, 협업은 완전히 다른 국면으로 접어들었다.

"코드는 맞았지만, 화면은 아니었다. 그 차이를 이해하는 게 진짜 협업의 시작이었다."
2026년 현재 Figma와 코드 에디터 간의 디자인 토큰 동기화 도구들이 점점 늘고 있어서, 여백이나 색상 값의 불일치 문제는 예전보다 기술적으로 줄어드는 추세라는 이야기를 자주 듣는다. 다만 시각적 판단이나 커뮤니케이션 방식의 차이는 도구만으로 해결되지 않는 영역이므로, 팀 차원의 공통 언어를 만드는 노력은 여전히 중요하다고 생각한다.

결론

디자이너와의 협업에서 겪은 마찰은 대부분 실력 부족이 아니라, 서로 다른 기준으로 "맞다"를 판단하고 있어서 생긴 문제였다. 픽셀과 비율, 코드값과 시각적 균형이라는 서로 다른 언어를 이해하고 공통의 기준을 만들어가면서, 협업은 오히려 가장 편안한 관계로 바뀌었다. 디자이너와의 협업에서 비슷한 답답함을 느끼고 있다면, 서로의 판단 기준부터 맞춰보는 대화를 먼저 시도해보길 권하고 싶다.

여러분은 어떤 협업 경험이 있으신가요?

디자이너와 협업하며 겪은 오해나, 관계가 좋아진 계기가 있다면 댓글로 공유해주세요. 지금 비슷한 답답함을 느끼고 있는 다른 개발자분들께 큰 도움이 될 것 같습니다.


소개 및 문의 · 개인정보처리방침 · 면책조항

© 2026 나무핀