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

3명이 전부인 팀에서 핸드오프 비용이 더 예민하게 느껴지는 이유

HEDVION은 결제·정산·자동화를 직접 운영하는 팀이다. 인원은 셋. 세 명 모두 코드를 쓰고, 필요하면 디자인도 한다. 역할 경계가 유연하다 보니 처음엔 "큰 팀처럼 디자이너-개발자 사이의 번역 비용이 없겠지"라고 생각했다. 실제로는 달랐다. 번역 비용이 없어진 게 아니라 형태가 바뀌었을 뿐이었다. 한 사람이 Figma에서 설계한 컴포넌트를 다른 사람이 코드로 옮기는 과정에서 작은 불일치가 생겼고, "왜 이렇게 됐지?"라는 질문이 반복됐다. 질문 자체보다 더 큰 문제는, 그 질문에 바로 답할 수 있는 기록이 어디에도 없었다는 점이었다.

소규모 팀일수록 이 비용이 더 아프다. 인원이 10명인 팀에서 한 명이 스타일 수정에 묶이면 팀 속도의 10%가 잠깐 멈춘다. 우리는 3명이니, 1명이 같은 일에 묶이면 팀 전체 속도가 33%씩 떨어진다. 이걸 한 달에 서너 번 반복하면 스프린트 하나의 여유가 사라진다. 규모가 작다는 건 "비용이 분산되지 않는다"는 뜻이기도 하다. 핸드오프 문제를 소규모 팀이 더 진지하게 다뤄야 하는 이유가 여기 있다.

결제·정산 UI에서 시각적 불일치는 미관 문제가 아니다

일반 서비스 화면에서 버튼 색상이 조금 달라지거나 hover 전환이 150ms 대신 250ms가 되는 건 대개 큰 문제가 아니다. 그런데 결제 화면에서는 이야기가 다르다. 사람들은 돈이 오가는 화면을 볼 때 훨씬 예민하게 반응한다. Baymard Institute의 체크아웃 UX 연구에 따르면 결제 단계 이탈의 주요 원인 중 하나가 "사이트에 대한 신뢰 부족(lack of trust)"이다. 시각적 일관성은 신뢰를 구성하는 요소 중 하나다. 화면이 "왠지 어색하게 보이는" 것만으로도 사용자는 결제를 망설인다.

정산 대시보드는 구조 자체가 복잡하다. 우리가 운영하는 정산 화면에는 금액 표시, 상태 뱃지(처리중·완료·실패·부분성공), 날짜 필터, CSV 내보내기 버튼 등 수십 개의 UI 요소가 조합된다. 이 요소들이 Figma와 코드 사이에서 조금씩 어긋나면, QA 때마다 "이 글꼴 크기가 왜 다르지?"를 파악하기 위해 두 도구를 나란히 열고 비교하는 작업이 반복된다. 한 번에 20~30분이고, 스프린트에 두세 번 반복되면 하루 가까운 시간이 이 작업으로 사라진다. 게다가 정산 금액 표시가 디자인과 달라 보이면, 사용자 입장에서는 "데이터가 잘못된 건가?"라는 불안으로 이어질 수 있다.

실제 사례: 색상 토큰 이름 하나 차이로 PR이 3번 열렸다

지난 분기 정산 상태 뱃지를 리뉴얼하면서 실제로 겪은 이야기다. Figma 디자인 파일에서 "처리중" 뱃지의 배경색은 #FFF3CD였다. 개발자가 코드로 옮길 때 기존 CSS 변수 --color-warning-light를 그대로 사용했는데, 이 변수값은 #FFF8DC였다. 두 색상의 차이는 육안으로 거의 구분되지 않는다. 첫 번째 PR은 리뷰 없이 머지됐다. 스테이징 환경에서 Figma 파일과 브라우저를 나란히 놓고 비교했을 때 처음으로 불일치가 발견됐다.

두 번째 PR에서 CSS 변수값을 #FFF3CD로 수정했다. 그러나 이 변수를 다른 컴포넌트 두 곳에서도 참조하고 있었다. 수정이 의도치 않은 영향을 줄 수 있어서 세 번째 PR에서 변수를 분기하고 영향 범위를 다시 검토해야 했다. 총 PR 3회, 소요 시간 약 2시간. 원인은 단 하나였다. Figma의 색상 이름과 CSS 변수 이름 사이에 실질적인 연결 규칙이 없었고, 그 불일치가 기록되지 않은 채 누적되어 있었다. 이 경험이 우리를 바꿨다. "도구가 달라도 이름은 같아야 한다"는 원칙을 그 이후 명문화했다.

지금 우리가 쓰는 세 가지 방법

첫 번째: 디자인 토큰을 단일 진실 파일로 관리한다. 색상, 타이포그래피, 간격 값을 tokens.css 하나로 선언하고, Figma의 컬러 스타일 이름도 정확히 같은 이름을 쓴다. --color-status-pending: #FFF3CD처럼 의미 기반 이름으로 정의하면, "이 값이 왜 여기서 하드코딩됐지?"라는 질문 자체가 줄어든다. 새 토큰을 추가할 때 두 도구에 같은 이름으로 등록하는 것을 팀 규칙으로 명문화했다. 현재 우리 프로젝트에는 색상 토큰 약 40개, 간격 토큰 12개가 이 방식으로 관리된다.

두 번째: Figma 컴포넌트에 동작 조건 메모를 직접 남긴다. 레이어 옆에 "hover: opacity 0.8, transition 150ms ease-out", "에러 상태: border-color --color-danger, 왼쪽에 경고 아이콘 표시" 같은 주석을 달아둔다. 결제·정산 화면은 상태 수가 많다. 로딩, 성공, 실패, 빈 화면, 부분 성공(일부 건은 처리 완료, 일부는 대기중)처럼 자동화 흐름에서 발생하는 엣지 케이스까지 Figma 안에 미리 그려두고 메모를 달아두면, 구현자가 "이 상태는 어떻게 보여야 해?"라고 묻는 왕복이 사라진다. 메모를 쓰는 데 5분이 걸리지 않지만, 그 5분이 나중의 20~30분짜리 질문-답변 왕복을 막는다.

세 번째: PR에 스크린샷 첨부를 관례로 만들었다. PR 설명 템플릿에 "영향받는 화면의 Before / After 스크린샷"을 필수 항목으로 넣었다. 텍스트 코드 diff만으로는 시각적 변화를 파악하기 어렵다. 스크린샷 한 장이 "이거 의도한 거야?"라는 질문을 즉각 해소하거나, 리뷰 단계에서 놓친 불일치를 잡아준다. Playwright 스냅샷, Storybook, 혹은 브라우저 스크린샷 어느 것이든 상관없다. 이 관례를 도입한 이후 병합 후 스타일 수정 PR 빈도가 체감상 절반 이하로 줄었다.

아직 해결 안 된 것: 반응형 브레이크포인트와 Figma 프레임의 간극

깔끔하게 해결하지 못한 영역이 하나 있다. 컴포넌트가 반응형으로 동작해야 할 때, Figma 안에는 "모바일 프레임"과 "데스크톱 프레임"이 따로 존재한다. 그런데 실제 CSS 브레이크포인트는 여러 단계(sm: 640px, md: 768px, lg: 1024px)로 나뉘어 있고, Figma 프레임과 1:1로 대응되지 않는다. 이 간극을 채울 규칙을 아직 정해두지 못해서, "이 컴포넌트는 768px에서 어떻게 접혀야 해?"라는 대화를 구현할 때마다 반복하고 있다.

검토 중인 방법은 Figma 프레임 이름을 layout/375, layout/768, layout/1280처럼 실제 픽셀값과 대응시키고, CSS 브레이크포인트 주석에서 같은 숫자를 참조하게 만드는 것이다. 아직 실행에 옮기지 않았다. 적용 범위가 넓어 실제로 효과가 있을지, 오히려 관리 부담이 늘어날지 판단이 서지 않는다. 이 부분은 솔직하게 "진행 중"이라고 밝힌다. 해결되면 이어서 쓰겠다.

지금 바로 써먹을 수 있는 실행 지침

아래는 팀 규모와 관계없이 지금 바로 도입할 수 있는 항목들이다. 전부 한꺼번에 할 필요 없다. 가장 자주 반복되는 문제부터 하나씩 시작하면 된다.

1. 이름 통일부터 시작하라. CSS 변수 이름과 Figma 컬러 스타일 이름을 지금 당장 맞춰라. 기존 토큰은 점진적으로 이름 변환해도 된다. 새 토큰을 추가할 때만큼은 두 도구에 같은 이름으로 등록하는 것을 팀 규칙으로 만들면 충분하다. --color-danger, --spacing-card-gap처럼 쓰임새가 담긴 이름이 값 기반 이름보다 훨씬 오래 쓸 수 있다.

2. Figma에 "빠진 상태"를 그려라. 현재 디자인 파일에 로딩·에러·빈 화면이 없는 컴포넌트가 있다면, 이번 주 안에 주요 컴포넌트 5개만 추가하라. 결제·정산처럼 상태가 많은 화면일수록 이 작업의 회수 속도가 빠르다. 자동화 흐름에서 실패 케이스가 빠져 있으면 구현자가 직접 설계 결정을 내리게 되고, 그 결정이 기록되지 않은 채 코드에만 남는다.

3. PR 설명에 스크린샷 한 장을 필수로 넣어라. PR 템플릿에 Before / After 스크린샷 섹션을 추가한다. 도구는 무관하다. 스크린샷 하나가 리뷰 시간을 줄이고, 머지 후 수정 PR을 막는다. 처음엔 번거롭게 느껴지지만 두 번째 PR부터 습관이 된다.

4. "왜 이렇게 됐지?"가 반복됐던 지점을 찾아라. 최근 한 달 안에 같은 질문을 두 번 이상 한 지점이 있다면, 그게 지금 당장 기록해야 할 곳이다. Figma 메모든, 코드 주석이든, 짧은 ADR(Architecture Decision Record)이든 형식은 상관없다. 결정이 어딘가에 기록되어 있으면 그것으로 충분하다.

핸드오프를 없애는 건 인원이 적다고 저절로 되지 않는다. 역할이 유연해도 결정이 기록되지 않으면 같은 질문이 반복된다. 도구가 달라도 이름이 같고, 시각적 의도가 글로 남겨져 있으며, 변경 결과를 눈으로 확인하는 루프가 작게라도 돌아가고 있을 때, 팀은 비로소 "핸드오프"가 아니라 "흐름"을 갖게 된다.

— by mings