디자이너–개발자 Lottie 핸드오프 규칙 만들기
"이거 규격이 왜 375예요? 240 아니었어요?" — 모션 에셋을 주고받을 때마다 이런 왕복이 반복된다면, 문제는 사람이 아니라 규칙의 부재입니다. 한 번 합의해 두면 매번 아끼게 되는 네 가지 규칙을 제안합니다.
규칙 1 — 규격 표준표를 만든다
쓰임새별 캔버스 규격을 표로 못 박아 두는 것이 시작입니다. 예시:
| 용도 | 캔버스 | fps | 용량 가이드 |
|---|---|---|---|
| 아이콘 모션 | 48×48 | 30 | ≤ 20KB |
| 로딩 인디케이터 | 120×120 | 30 | ≤ 30KB |
| 빈 화면 일러스트 | 240×240 | 30 | ≤ 80KB |
| 온보딩 히어로 | 375×280 | 30 | ≤ 150KB |
숫자 자체보다 "표가 존재한다"는 사실이 중요합니다. 규격 논쟁이 "표 봐주세요" 한마디로 끝납니다.
규칙 2 — 파일 네이밍 컨벤션
{영역}_{용도}_{변형}.json
예)
home_empty_default.json
onboarding_step1_default.json
common_loading_small.json
paywall_success_dark.json네이밍이 일관되면 코드에서 에셋을 참조할 때 오타가 줄고, 뷰어에서 이름순 정렬만 해도 영역별로 깔끔하게 묶입니다.
규칙 3 — 색상 교체 레이어는 이름을 약속한다
다크모드 대응이나 테마 색 교체가 필요한 에셋은, 코드에서 keypath로 레이어를 찾아 색을 바꿉니다. 이때 레이어 이름이 Shape Layer 24면 지옥이 시작됩니다. 교체 대상 레이어는 반드시 약속된 이름을 쓰기로 합의하세요.
primary_fill ← 브랜드 색으로 교체되는 면
primary_stroke ← 브랜드 색으로 교체되는 선
surface_fill ← 배경 면 (라이트/다크 교체)이 약속 하나로 iOS의 ValueProvider, Android의 dynamic properties, 웹의 keypath 코드가 전부 안정됩니다.
규칙 4 — 검수를 프로세스로 만든다
"받으면 일단 열어 본다"를 개인 습관이 아니라 팀 프로세스로 만드세요. 추천 흐름:
- ① 디자이너가 내보내기 전 체크리스트 확인
- ② 전달 전, 에셋 폴더를 Lottie Inspector에 넣고 규격선·배경 전환·용량 셀프 검수
- ③ 개발자는 받은 폴더를 같은 방식으로 30초 훑고 나서 통합 시작
- ④ 최종 확인은 실기기(iOS/Android 각 1대)에서
템플릿 — 그대로 복사해 쓰는 핸드오프 노트
## 모션 에셋 전달 노트
- 파일: home_empty_default.json (24KB)
- 캔버스: 240×240 / 30fps / 2.0s loop
- 색 교체: primary_fill → 브랜드 프라이머리
- 확인 완료: 규격선 ✓ / 다크 배경 ✓ / 용량 가이드 ✓
- 비고: 루프 시작·끝 프레임 동일규칙이 없던 시절에 실제로 벌어진 일
위 규칙들은 머리로 생각해 낸 것이 아니라 전부 한 번씩 데인 뒤에 생겼습니다. 제가 만드는 앱에서 측정 대기 화면에 들어갈 로딩 애니메이션을 받았을 때의 일입니다. 디자이너는 시안 아트보드 기준인 375 규격으로 내보냈고, 저는 코드에서 120 규격을 가정하고 있었습니다. "다시 내보내 주세요" 한 번이면 끝났어야 할 일이 규격 수정 → fps 확인 → 용량 초과 재발견으로 이어지며 왕복 3회가 됐습니다. 왕복 한 번마다 서로의 컨텍스트 전환 비용이 붙으니, 제 기준으로는 실질적으로 이틀이 사라진 셈이었습니다.
더 아찔했던 건 다크모드 사고입니다. 라이트 배경 기준으로 만든 빈 화면 일러스트가 있었는데, 흰색에 가까운 회색 선으로 그려진 부분이 다크 배경에서는 거의 보이지 않았습니다. 문제는 이걸 심사 제출 직전에야 발견했다는 점입니다. 디자이너 화면도 제 시뮬레이터도 라이트모드였기 때문에 중간 단계에서 아무도 걸러내지 못했습니다. 그날 이후 "전달 전 다크 배경에서 한 번 확인"이 규칙 4의 ②에 들어갔고, 배경 전환 확인은 뷰어에서 클릭 한 번이면 끝나는 일이 됐습니다.
돌이켜보면 두 사고 모두 개인의 실수가 아니었습니다. 확인 항목이 사람 머릿속에만 있으면 언젠가는 빠뜨리게 되어 있고, 그 "언젠가"는 꼭 출시 직전에 옵니다.
규칙을 팀에 정착시키는 법
규칙을 만드는 것보다 어려운 건 유지하는 것입니다. 슬랙 스레드에서 합의한 규칙은 제 경험상 2주면 잊힙니다. 실제로 효과를 본 방법은 세 가지였습니다.
- 위키에 박제 — 규격 표준표와 네이밍 컨벤션을 팀 위키의 고정 문서로 올리고, 에셋 관련 질문이 나올 때마다 답변 대신 링크를 겁니다. "표 봐주세요"가 문화가 되려면 표가 항상 같은 자리에 있어야 합니다.
- 온보딩 문서에 포함 — 새로 합류한 디자이너나 개발자가 첫 주에 읽는 문서에 핸드오프 규칙을 넣습니다. 기존 멤버에게 규칙을 "다시" 가르치는 것보다 새 멤버가 처음부터 그 방식으로 시작하게 하는 편이 저항이 훨씬 적습니다.
- 리뷰 단계에서 강제 — 에셋이 저장소에 들어올 때 PR 설명에 위의 핸드오프 노트 템플릿을 붙이는 것을 리뷰 통과 조건으로 삼습니다. 선의에 기대는 규칙은 바쁜 주에 무너지지만, 프로세스에 걸려 있는 규칙은 바쁜 주에도 돌아갑니다.
마지막으로 하나, 규칙은 적을수록 지켜집니다. 저도 처음에는 항목이 열 개가 넘는 문서를 만들었다가 아무도 읽지 않는 것을 보고 위의 네 가지로 줄였습니다. 전부 지켜지는 네 개가 절반만 지켜지는 열 개보다 낫습니다.