디자인-개발 핸드오프를 줄이는 우리의 흐름

우리 팀은 셋이 전부다. 세 명 모두 코드를 쓰고, 필요하면 디자인도 한다. 역할 경계가 유연한 덕분에 큰 팀처럼 디자이너-개발자 사이의 번역 비용이 발생하지 않는다고 생각했다. 실제로는 달랐다. 한 사람이 Figma에서 만든 컴포넌트를 다른 사람이 코드로 옮길 때, 작은 불일치가 여러 번 수정을 낳았다.

문제의 정체

핸드오프 비용은 “전달”에 있는 게 아니었다. 결정이 기록되지 않는 데 있었다. “이 버튼 색상은 왜 이 값이야?”라는 질문에 Figma 파일을 열어봐도 답이 없었다. 설계한 사람의 머릿속에만 있었다.

우리가 시도한 것들

디자인 토큰을 단일 파일로 관리한다. 색상, 타이포그래피, 간격 값을 CSS 변수나 JSON으로 선언하고, Figma와 코드베이스가 같은 이름을 쓴다. --color-copper: #a87340 같은 변수가 양쪽에 동일하게 존재하면 “코드에 하드코딩된 값”을 찾아 수정하는 일이 줄어든다.

컴포넌트 메모를 Figma에 직접 남긴다. 레이어 옆에 메모로 “hover 시 opacity 0.8, 전환 150ms” 같은 동작 조건을 적어둔다. 구현자가 파일을 열면 의도를 바로 읽을 수 있다. 빠진 상태(로딩, 에러, 빈 화면)를 함께 그려두는 것도 같은 맥락이다.

코드 리뷰에서 디자인 일치 여부를 체크한다. PR 설명에 “이 변경이 영향을 주는 화면의 스크린샷”을 첨부하는 것을 관례로 만들었다. 텍스트만으로는 시각적 불일치를 잡기 어렵다.

아직 해결 안 된 것

컴포넌트가 반응형으로 동작해야 할 때 Figma 상의 여러 프레임과 실제 CSS 브레이크포인트를 어떻게 대응시킬지는 여전히 매번 대화가 필요하다. 규칙을 정해두기 어려운 영역이라 지금은 그냥 말로 합의한다.

요점

핸드오프를 없애는 건 인원이 적다고 저절로 되지 않는다. 결정을 기록하는 습관이 있어야 한다. 도구가 달라도 같은 이름을 쓰고, 시각적 의도를 글로 남기고, 변경 결과를 눈으로 확인하는 루프를 작게라도 갖추는 것이 우리가 찾은 방법이다.

— by mings