MangCho's Guide

  "피그마 링크 드릴게요 😊" — 이 한 줄이 개발팀에게 얼마나 큰 숙제를 던지는지 아시나요? 링크만 전달했을 때 벌어지는 커뮤니케이션 비용, 핸드오프 미팅을 효과적으로 여는 법, 코멘트 활용 전략, Dev Mode 워크플로우까지 — 실무 경험담으로 정직하게 풀어드릴게요!   처음 핸드오프를 할 때 저는 꽤 뿌듯했어요. 페이지도 잘 정리하고, 컴포넌트도 그럴듯하게 만들었고, Figma 링크 하나를 Slack에 딱 보냈거든요. "다 됐다!" 싶었죠. 😎 그런데 30분도 안 지나서 개발자 채널에서 DM이 왔어요. "이 버튼 hover 상태가 없는데 어떻게 처리해요?", "여기 폰트가 뭐예요?", "모바일 버전은 없나요?" 그때 깨달았어요. 내가 링크를 전달한 게 아니라 질문 리스트를 전달한 것 이었다는 걸요. 좋은 핸드오프는 "파일을 넘기는 것"이 아니라 "파일에 담긴 의도까지 넘기는 것"이에요. 오늘은 그 차이를 만드는 방법들을 솔직하게 풀어볼게요!   링크만 던졌을 때 벌어지는 일들 🌪️ Figma 링크 하나만 전달했을 때 개발자 입장에서 어떤 일이 펼쳐지는지 솔직하게 재현해 볼게요. 실제로 여러 개발자 분들에게 들은 이야기들이에요. 🔍 개발자가 링크를 받고 하는 일 (추정 소요 시간) 파일 열어서 페이지 구조 파악하기 (5~15분) 어느 화면이 현재 스프린트 범위인지 찾기 (5~10분) 컴포넌트 클릭해보며 속성 직접 확인 (10~20분) 모호한 부분 리스트업하고 디자이너에게 질문 정리 (10~15분) 디자이너 답장 기다리기 (30분~수 시간) 답변 받고 다시 구현 시작 (이후부터 실제 작업) 합산하면 첫 번째 코드 한 줄 짜기까지 1~2시간 이 날아...

  "레이어1", "그룹 복사본 3", "버튼-최종2" — 이 파일, 혹시 당신 거 아닌가요? 😅 레이어 이름부터 컴포넌트·페이지 구조까지, 디자이너와 개발자가 같은 언어로 대화할 수 있는 네이밍 컨벤션을 나쁜 예시와 좋은 예시를 직접 대비하며 정리해 드릴게요!   솔직히 고백하자면 저도 한동안 레이어 패널이 "Rectangle 45", "그룹 복사본 2", "Frame 123" 같은 이름들로 가득한 채로 작업했어요. 혼자 쓸 땐 큰 문제 없었거든요. 🙈 근데 개발자에게 파일을 넘기는 순간부터 달라졌어요. "이 레이어가 버튼이에요, 배경이에요?" "이 컴포넌트 이름이랑 코드 이름이 다른데 맞는 거예요?" 질문이 쏟아지더라고요. 네이밍은 단순한 정리 습관이 아니에요. 디자이너·개발자·기획자가 같은 단어로 같은 것을 가리킬 수 있게 해주는 공통 언어 예요. 오늘은 레이어·컴포넌트·페이지 구조 각각의 네이밍 원칙을 나쁜 예시 vs 좋은 예시로 대비해서 보여드릴게요. BEM, Atomic Design 같은 방법론과의 연결까지요!   왜 네이밍이 이렇게 중요한가요? 🤔 나쁜 네이밍이 실무에서 만들어내는 문제는 크게 세 가지예요. 탐색 비용 증가: "이 컴포넌트 어디 있더라?" 하고 레이어 패널을 뒤지는 시간이 쌓이면 하루에 몇십 분이 날아가요. 코드-디자인 불일치: Figma에서 "버튼-블루"인데 코드에선 ButtonPrimary 예요. 신규 입사자가 무엇을 참조해야 할지 몰라요. 인수인계 실패: 작업자가 바뀌면 파일을 처음부터 해석해야 해요. "이게 뭐지?" 시간이 온보딩의 절반을 잡아먹어요. 💡 핵심 원칙 먼저! ...

  "디자인엔 없는데요?" — 개발자가 가장 많이 하는 말이에요. hover, disabled, loading, error, empty, skeleton… 실무에서 디자이너가 자주 빠뜨리는 컴포넌트 상태들, 빠졌을 때 개발에서 벌어지는 일, 그리고 다시는 놓치지 않는 체크리스트까지 한 번에 정리했어요!   디자이너 동료에게서 받은 컴포넌트 파일을 열었는데 버튼이 딱 하나예요. 기본(Default) 상태 하나. 개발자가 "hover는요? disabled는요? 로딩 중엔 어떻게 보여요?" 물어보면 "아 그건 알아서 해주세요~"가 돌아오는 그 상황. 😅 반대로 디자이너 입장에서도 억울해요. 솔직히 처음에 뭘 챙겨야 하는지 아무도 알려주지 않았거든요. 이 글은 디자이너를 탓하려는 게 아니에요. 실무에서 정말 자주 누락되는 상태들이 있고, 그게 빠졌을 때 개발 과정에서 어떤 일이 일어나는지, 그리고 앞으로 어떤 기준으로 체크하면 되는지를 같이 정리해 보려고 해요. 이 글 한 번만 읽으면 "디자인엔 없는데요?"라는 말을 훨씬 덜 들을 수 있을 거예요!   왜 상태(State)가 이렇게 중요한가요? 🤔 UI 컴포넌트는 언제나 딱 한 가지 모습만 가지지 않아요. 같은 버튼이라도 사용자가 마우스를 올리는 순간, 클릭하는 순간, 비활성화된 순간, 로딩 중인 순간에 모두 다르게 보여야 해요. 이 각각의 모습이 바로 "상태(State)"예요. 상태 디자인이 누락됐을 때 벌어지는 일은 크게 세 가지예요. 첫째, 개발자가 임의로 스타일을 만들어 넣어요. 그 결과는 브랜드 가이드와 전혀 다른 UI가 될 수 있어요. 둘째, 개발자가 기획자나 디자이너에게 다시 확인을 요청하면서 피드백 루프가 길어지고 일정이 지연 돼요. 셋째, 그냥 아무 처리도 안 한 채로 배포됐다가 사용자가 이상한 화면을 만나는 최악의 상황이 오기도 해요. ...

  Figma에서 디자인은 예쁘게 뽑았는데, 개발자가 받으면 왜 멘붕이 올까요? Auto Layout 없이 고정 좌표로 찍어놓은 디자인이 개발 단계에서 어떤 참사를 일으키는지, 그리고 CSS Flexbox/Grid와 어떻게 대응되는지 Before/After 예시로 낱낱이 풀어봤어요.   솔직히 고백할게요. 저도 예전에 Figma에서 Auto Layout 없이 디자인한 적이 꽤 있었어요. 프레임 안에 요소를 드래그해서 눈대중으로 배치하고, 간격은 화살표 키로 1px씩 맞추고… 화면에서 보기엔 완벽했거든요. 😅 그런데 그 파일을 넘겨받은 개발자분이 조용히 슬랙으로 보내온 메시지가 아직도 생생해요. "이거… 간격이 위에서는 12px인데 아래에서는 13px이고, 이 버튼은 텍스트가 길어지면 어떻게 되는 건가요?" 그때부터 Auto Layout을 제대로 공부하기 시작했어요.   고정 좌표 배치 vs Auto Layout, 뭐가 다른 건가요? 🤔 가장 근본적인 차이부터 짚어볼게요. Figma에서 요소를 배치하는 방식은 크게 두 가지예요. 구분 고정 좌표 배치 Auto Layout 배치 방식 X, Y 좌표로 절대 위치 지정 방향·간격·패딩 규칙으로 자동 배치 내용 변경 시 다른 요소 수동으로 재배치 필요 자동으로 리플로우 반응형 대응 ...