결론부터, 저는 이제 숫자로 적어둡니다. 포폴 인터랙션을 '부드럽게'라고만 적어뒀더니 왜 이 속도냐고 물을 때 답이 안 나오더라고요. 취준이라 개발팀에 직접 넘겨본 적은 없지만, 인턴 때 말로 오간 건 뭐든 증빙이 안 됐거든요. duration·easing까지 값으로 박아두면 '왜 이렇게 풀었는지'가 남으니까요. 다들 모션은 어디까지 수치로 정해 넘기시나요?
모션 값, 개발팀엔 숫자로 넘기시나요 말로 넘기시나요?
10.13 01:25조회수 0댓글 9
개발팀에 넘길 때 그 숫자를 누가 검수하는지도 적어두시나요? 저는 제품 쪽이라 모션은 인접 경험으로만 말씀드리는데, 구조가 목업 감리랑 비슷하더라고요. 곡면 R값이나 도색 광택도를 도면에 박아서 넘겨도, 수치만 있으면 현장에서 금형 조건 핑계로 그냥 넘어가거든요. 그래서 저는 값 옆에 '이 수치를 왜 이렇게 잡았는지' 한 줄을 같이 박아둡니다. duration·easing도 숫자만 넘기면 나중에 왜 이 속도냐 물을 때 결국 똑같은 답을 반복하게 되지 않을까요. 말로 오간 건 뭐든 증빙이 안 된다는 말씀엔 저도 겪어서 동의합니다. 다만 숫자까지 적으신 분들은, 그 근거까지 문서에 남기시는지 궁금합니다.
저도 값 옆에 한 줄 같이 박아두는 쪽입니다. 숫자만 남기면 왜 이 속도냐 물을 때 또 말로 때우게 되는데, 말은 뭐든 증빙이 안 되더라고요. 포폴 인터랙션에도 '이건 로딩이라 체감 짧게 가져간다' 식으로 판단 기준을 숫자 옆에 적어두니, 나중에 제가 다시 봐도 왜 이렇게 풀었는지가 남아서요. 취준이라 실제로 개발팀에 넘겨본 적은 없어 조심스러운데, 말씀하신 금형 핑계처럼 현장에서 밀릴 때 그 한 줄이 실제로 버팀목이 되던가요?
버팀목이라기보단 기록으로 남는 쪽입니다. 저는 도색 광택도를 도면에 박아 넘겼는데, 정작 라인에선 금형 조건 때문에 그날 바로 밀렸거든요. 그 자리에서 한 줄이 결정을 뒤집진 못합니다. 다만 왜 이 수치였는지, 누가 바꿨는지가 문서에 남으니까 다음 협의 때 제가 개인 취향이 아니라 기준으로 말할 수 있었습니다. 그 한 줄 없었으면 또 말로 때우다 그냥 넘어갔을 거고요.
정리해서 숫자로 박는다는 결론, 저는 반갑게 읽었어요. 다만 하나 더 보태고 싶은 게 있어요. 값만 남기면 나중에 "왜 300ms에 ease-out인지"가 또 휘발되더라고요. 저는 디지털 프로덕트 쪽이라 모션이 제 주력 영역은 아니지만, 핸드오프에서 분기 누락 크게 겪고 나서 값 옆에 "이 속도로 푼 이유" 한 줄을 로그에 같이 쌓습니다. duration·easing은 재현되는데 의도는 안 남거든요. 취준 포폴이라면 오히려 그 한 줄이 "왜 이렇게 풀었는지"를 증빙해주는 핵심이라고 봐요. 하나 여쭤보고 싶은 게 있어요. 상호님은 그 숫자를 어디다 적어두세요? 프레임 주석인지, 아니면 별도 스펙 문서인지가 나중에 추적되느냐를 가르더라고요 🙂
저는 처음엔 프레임 주석에 박아뒀는데, 시안 갈아엎을 때마다 그 주석이 같이 날아가더라고요. 그래서 지금은 포폴용으로 값이랑 "왜 이 속도로 풀었는지" 한 줄을 별도 문서에 따로 쌓습니다. 취준이라 실제 핸드오프엔 넘겨본 적 없지만, 인턴 때 제 노트에만 남긴 건 결국 아무것도 증빙이 안 됐거든요. 프레임 안에만 두면 꼭 그 꼴 날 것 같아서요. 나린님은 그 로그를 파일에 붙여두세요, 아니면 아예 따로 빼두세요?
저는 아예 따로 빼둡니다. 프레임 안에 박아두면 시안 갈아엎을 때 날아가는 것도 문제지만, 나중에 뭐가 실제로 반영됐는지를 못 쫓겠더라고요. 기획서에서 분기 누락 크게 겪고 나서 생긴 습관인데, 값이랑 "왜 이 속도로 풀었는지"를 날짜랑 릴리즈 버전까지 붙여서 프레임 밖 별도 로그로 쌓습니다. 이렇게 빼두면 포폴용으로만 끝나는 게 아니라 핸드오프에서도 그대로 써먹는 자산이 되더라고요. 노트에만 남긴 건 증빙이 안 된다는 말, 저는 정확히 같은 이유로 프레임 밖으로 꺼냈습니다.
저는 실무에서 개발팀에 넘길 때 duration·easing은 무조건 값으로 박아 넘깁니다. 상호님이 포폴에 '부드럽게'라고만 적었을 때 막혔던 그 지점, 저도 넘겨보면 똑같이 터지거든요. 숫자가 없으면 "왜 이 속도냐"에 답이 안 나오니까요. 다만 하나 더 해두는 게 있어요. 저는 200ms, ease-out 옆에 "이게 어느 상태 전환에 붙는지"를 같이 적어둡니다. 진입이라 빠르게 끝나야 하는 건지, 닫힘이라 여운을 주는 건지를요. 값만 있으면 개발팀이 조용히 자기네 기본 커브로 바꿔도 뭐가 기준이었는지 증명이 안 되더라고요. 모션도 시간이 아니라 상태로 적어두면, 왜 이 값인지가 값이랑 같이 남거든요.
숫자로 남겨두면 '왜 이렇게 풀었는지'가 남는다는 그 한 줄에 저도 모르게 고개를 끄덕였어요. 저는 모션 쪽도 아니고 개발팀에 뭘 넘겨본 적도 없어서 조언드릴 입장은 전혀 아니고요, 그냥 결이 비슷한 일이 떠올라서요. 지난 팝업 때 스티커 색을 '따뜻하게'라고만 적어뒀다가 실물이 화면이랑 달라서 재발주한 적이 있거든요. 그때 '왜 이 색이었는지'를 못 대니까 다시 밀어붙일 근거가 하나도 안 남더라고요ㅠㅠ 그 뒤로 저는 색값이랑 조명 수치는 그냥 로그처럼 박아두는 편이에요. 말로 오간 건 증빙이 안 된다는 말, 진짜 와닿았어요. 근데 모션은 어디까지 숫자로 잡아야 과한 게 아닐지, 그 선이 저는 궁금해지네요!!
취준 단계에서 벌써 값으로 박아두는 습관을 들이셨다니 놀랍네요. 저는 인하우스 프로덕트라 핸드오프 때 duration·easing을 값으로 넘기는데요, 결론부터 말씀드리면 숫자 자체보다 그 숫자를 "무엇에 맞췄는지"를 한 줄 붙여두는 게 나중에 더 효력을 봤어요. 240ms라고만 적으면 반년 뒤 제가 봐도 왜 240인지 기억을 못 하거든요. 대신 "리스트 전환이 끊김으로 안 느껴지는 선"처럼 기준을 적어두면, 개발팀이 성능 때문에 값을 깎아야 할 때 어디까지 양보해도 되는지가 바로 나오더라고요. 숫자는 협상의 시작점이고, 옆에 붙여둔 기준이 깎을 수 있는 범위를 정해주는 셈이죠. 말로 넘기면 이 범위가 통째로 사라집니다.