Figma 44프레임을 코드와 대조하기

[TripTune](/blog/웹 기술로 만드는 협업형 여행 계획 플랫폼 TripTune 개발)은 2인 팀이라 디자인과 구현 사이에 리뷰 단계가 없습니다. Figma를 보고 제가 짜고, 다르면 제가 고쳐요.

문제는 1년 반쯤 지나니 뭐가 다른지 아무도 모르게 됐다는 겁니다. 화면이 Figma와 조금씩 다른데, 그게 실수인지 중간에 의도적으로 바꾼 건지 구분이 안 갔어요. 커밋 메시지에 "요청 사항 반영"이라고만 적혀 있으면 더 그렇고요.

Figma 44프레임을 코드와 전수 대조해서 리포트로 만들었습니다.

1. 차이를 다 적으면 아무도 안 본다

처음 몇 프레임을 대조하면서 바로 알았습니다. 다른 곳은 무한히 나옵니다. 색이 1 다르고, 여백이 2px 다르고, 폰트 웨이트가 다르고. 이걸 다 적으면 200줄짜리 목록이 되고, 그 목록은 안 읽힙니다.

그리고 그중 상당수는 일부러 바꾼 것이었어요. 회의에서 "이건 좁혀주세요" 해서 바꾼 여백을 "Figma와 다름"이라고 적으면, 그건 리포트가 아니라 노이즈입니다.

그래서 리포트의 첫 일은 차이를 찾는 게 아니라 분류 규칙을 정하는 것이 됐습니다.

비교한 frame 수: 44개

OFF-LIMITS (이미 의도적 조정됨)   21
단일 도형 / 의미 없음              1
REVIEW (실제 비교 대상)           22

절반이 OFF-LIMITS였습니다. 이 분류가 없었으면 리포트가 44건짜리가 되고, 그중 21건은 "고치면 안 되는 것"이었을 거예요. 고쳤으면 회의에서 정한 걸 되돌리는 셈이 됩니다.

디자인 대조에서 진짜 어려운 건 "다르다"를 찾는 게 아니라 "틀렸다"를 가르는 것입니다. 전자는 자동으로 나오고 후자는 맥락이 필요해요.

OFF-LIMITS는 커밋으로 판정했다

맥락은 커밋 히스토리에 있었습니다. 각 영역을 마지막으로 의도해서 만진 커밋을 찾아 표로 붙였어요.

"이 영역은 왜 Figma와 다른가"의 답이 커밋 해시입니다. 리포트를 읽는 사람(반년 뒤의 나)이 근거를 직접 확인할 수 있어요. "의도적입니다"라고만 적으면 못 믿습니다.

Figma frame ID도 같이 적었습니다. 안 적으면 "어느 화면 얘기지"를 매번 다시 찾아야 해요.

2. 우선순위는 "시각적으로 명백한가"로 갈랐다

REVIEW 22건에 HIGH/MEDIUM/LOW를 붙였습니다. 기준은 "사용자가 보면 이상하다고 느끼는가" 였어요. 구현 난이도가 아니라요.

HIGH — 명백한 시각적 결함 4건

1. /MyPage 북마크 카드 라운드가 비대칭
   현재  : border-radius: 10px 0 10px 0   (좌상/우하만)
   Figma : 4면 모두 10px

3. /Schedule 공유 모달 라운드가 비대칭
   현재  : border-radius: 30px 0
   Figma : 4코너 균일

4. /Schedule 공유 모달 화면 정렬 깨짐
   현재  : margin-bottom: 200px  ← 강제로 위쪽에 치우침
   Figma : 화면 정중앙

border-radius: 30px 0이 두 번 나오는 게 눈에 띄었습니다. 이건 30px 0이 "좌상 30px, 나머지 0"이라는 걸 모르고 "30px 라운드, 0 오프셋"쯤으로 읽은 흔적이에요. CSS 단축 속성을 한 번 잘못 이해하면 여러 파일에 같은 모양으로 번집니다.

margin-bottom: 200px도 마찬가지 성격입니다. 모달을 가운데 두려다 안 돼서 마진으로 밀어놓은 거예요. 부모에 justify-content: center가 이미 있는데도요. 창 높이가 바뀌면 그대로 어긋납니다.

MEDIUM — 일관성 8건

10. 공유 모달 헤더 정렬 하드코딩
    현재  : margin-left: 37px  /  margin-left: 75%
    Figma : flex space-between

11. 공유 모달 드롭다운 고정 height
    현재  : height: 199px
    Figma : 콘텐츠 높이 (항목 수 따라 가변)

13. "일정나가기" 띄어쓰기
    Figma : "일정 나가기"

10번과 11번은 같은 뿌리입니다. 레이아웃을 관계가 아니라 좌표로 표현한 것이에요. margin-left: 75%는 "오른쪽 끝"을 뜻하려던 건데, 컨테이너 폭이 바뀌면 오른쪽 끝이 아닙니다. height: 199px은 지금 항목 수에서 잰 값이고요.

13번은 사소해 보이지만 그렇지 않았습니다.

LOW — 무시 가능 / 사전 확인 필요

무시 가능 항목은 표로만 남겼습니다. 배지 색 미세 차이, font-weight: 505 같은 비표준값(브라우저가 500으로 반올림), '✕' 텍스트 대 SVG 아이콘 같은 것들이요.

"무시 가능"도 적는 게 중요합니다. 안 적으면 다음 대조 때 또 발견하고 또 판단하게 돼요. 한 번 "무시하기로 했다"고 적어두면 그다음부터는 공짜입니다.

그리고 별도로 ⚠️ 사전 확인 필요 칸을 뒀습니다.

/MyPage LoginModal (src/components/Common/LoginModal.tsx)
  - height 252px → Figma는 230px 정도
  - <ModalOverlay style={{ marginTop: '-93px' }}>  헤더 보정 hack
  - font-weight: 505  비표준값
  - font-family: 'NOto Sans KR'  오타 (대문자 O)
  이유: commit 3d2ad61 범주에 들어가므로 의도 재확인 권장

OFF-LIMITS 커밋의 범주에 걸쳐 있는데 명백히 틀린 것들입니다. 그래서 "고쳐라"도 "두라"도 아니고 "확인하고 정하라"로 뒀어요. 이 칸이 없으면 둘 중 하나로 잘못 분류됩니다.

font-family: NOto Sans KR은 특히 그렇습니다. 대문자 O 오타라 그런 폰트는 존재하지 않고, 브라우저는 조용히 sans-serif로 떨어집니다. 게다가 루트 레이아웃이 next/font로 제대로 적용해둔 Noto Sans KR을 이 선언이 덮어씁니다. 즉 이 모달만 다른 폰트로 그려지고 있고, 4곳에 복붙돼 있어요.

3. 리포트를 코드 위치로 적었다

이게 이 리포트에서 가장 실용적이었던 부분입니다. 항목마다 파일 경로와 선택자를 적었어요.

### 1. /MyPage 북마크 카드 라운드가 비대칭
- **파일**: `src/styles/Mypage.module.css` `.bookmarkCard`
- **현재**: `border-radius: 10px 0 10px 0`
- **Figma**: 4면 모두 10px 라운드
- **수정안**: `border-radius: 10px;`

파일 / 현재 / Figma / 수정안 네 줄 고정입니다.

"수정안"까지 적은 게 결정적이었습니다. 디자인 대조 리포트는 보통 "다르다"에서 끝나는데, 그러면 고칠 때 판단을 다시 해야 합니다. 대조하면서 이미 두 값을 다 보고 있으니, 그 자리에서 답까지 적는 게 제일 쌉니다.

수정안이 확실하지 않으면 그렇게 적었습니다.

- **수정안**: `border-radius: 16px;` (또는 디자인 토큰 확인 후 결정)

리포트는 "무엇이 틀렸나"가 아니라 "무엇을 어디서 어떻게 고치나"까지 적어야 실행됩니다. 앞의 절반만 적힌 리포트는 결국 두 번 조사하게 만들어요.

4. 2.5개월 뒤 — 반영률을 확인해봤다

이 글을 쓰면서 지금 코드를 다시 열어봤습니다. 리포트 작성일이 2026-05-10이고, 확인 시점은 7월 말입니다.

HIGH 4건 중 2건이 남아 있습니다. 반영된 둘은 MyPage 쪽, 안 된 둘은 공유 모달 쪽이에요.

왜 이렇게 갈렸는지는 분명합니다. MyPage는 그 뒤에 다른 작업으로 열어본 파일이고, 공유 모달은 안 열었습니다. 리포트를 보고 고친 게 아니라, 그 파일을 만질 일이 생겼을 때 겸사겸사 고쳐진 거예요.

13번(일정나가기)에서 이게 제일 잘 보입니다. 같은 파일 안에서 세 곳의 표기가 다릅니다.

{ value: 'LEAVE', label: '일정나가기', description: '' },   // 31행 — 사용자에게 보이는 라벨
// 일정 나가기                                                // 211행 — 주석
setAlertMessage('일정 나가기 실패');                          // 224행 — 에러 메시지

주석과 에러 메시지는 나중에 쓰면서 자연스럽게 띄어썼는데, 정작 화면에 보이는 라벨만 안 고쳐졌어요. 리포트에 적힌 그 한 줄이요.

리포트가 실패한 지점

정직하게 말하면 이 리포트는 "만든 것"까지가 성과이고, "반영"은 절반입니다.

무엇이 부족했나:

• 리포트가 문서로만 존재합니다. 이슈로 쪼개지 않았어요. 문서는 열어야 보이고, 안 열면 없는 것과 같습니다.
• 반영 여부를 확인하는 시점을 안 정했습니다. "권장 적용 순서"까지 적어놓고 언제 다시 볼지는 안 적었어요.
• HIGH 4건 정도면 그 자리에서 고쳤어야 합니다. 수정안까지 다 적어놨는데 적용을 안 한 건, 대조와 수정을 분리한 게 과했던 거예요. 분리가 맞는 건 판단이 필요한 MEDIUM 이하였습니다.

Playwright로 메뉴 136종을 훑는 QA 스윕에서도 같은 결론에 닿았습니다. 사유가 붙은 스킵이라도 세지 않으면 늘어난다는 것이요. 여기서는 스킵이 아니라 "미반영"이었을 뿐입니다.

5. 그래도 남은 것

리포트가 절반만 반영됐어도 얻은 게 있습니다.

• OFF-LIMITS 21건이 문서로 고정됐습니다. "이건 왜 Figma와 다른가"를 다시 조사할 일이 없어졌어요. 커밋 해시가 붙어 있으니 근거도 따라갈 수 있고요.
• "무시 가능" 목록이 생겼습니다. 다음 대조에서 같은 걸 또 판단하지 않습니다.
• 미반영 항목이 지금 이 글의 재료가 됐습니다. 리포트가 없었으면 "공유 모달이 좀 위로 치우쳤네" 정도로 지나갔을 거예요.

정리

• 디자인 대조의 본질은 차이 찾기가 아니라 "의도적 조정"과 "결함"을 가르는 일입니다. 44건 중 21건이 건드리면 안 되는 것이었어요.
• "왜 다른가"의 답은 커밋 해시로 답합니다. "의도적입니다"라는 말은 반년 뒤에 못 믿습니다.
• "무시 가능"도 적습니다. 안 적으면 매번 다시 판단하게 됩니다.
• 리포트에 수정안까지 적습니다. 두 값을 보고 있는 그 순간이 답을 적기 제일 싼 시점이에요.
• 판단이 필요 없는 항목은 리포트에 적지 말고 그냥 고칩니다. HIGH 4건을 분리한 게 이번 실패의 원인이었습니다.
• 그리고 — 문서로만 있는 할 일은 파일을 열 일이 생겨야 처리됩니다. 이슈로 쪼개지 않으면 반영률은 "그 파일을 얼마나 자주 만졌나"에 달립니다.

관련 글: [TripTune 프로젝트 회고](/blog/웹 기술로 만드는 협업형 여행 계획 플랫폼 TripTune 개발) · Playwright 메뉴 136종 QA 스윕