피그마 개발자 회의, 꼭 물어야 할 질문 10
핸드오프 회의 끝나고 다시 불려간 날
피그마 화면을 공유받고 개발자분들과 30분 정도 회의를 마친 적이 있습니다. 다 확인했다고 생각하고 자리로 돌아왔는데, 다음 날 슬랙으로 질문이 하나씩 올라오기 시작했습니다. 빈 상태는 어떻게 되나요, 이 버튼은 재사용인가요, 모바일에서는 순서가 바뀌나요.
결국 그 질문들에 답하느라 다시 회의를 잡았고, 스케줄은 반나절 밀렸습니다. 문제는 회의 시간이 부족했던 게 아니라, 회의에서 물어야 할 질문 자체가 준비되어 있지 않았던 것이었습니다.
질문 없는 핸드오프 회의가 사고로 이어지는 이유
핸드오프 회의는 화면을 설명하는 자리가 아니라, 화면에 없는 정보를 채우는 자리입니다. 피그마 파일에는 완성된 상태의 화면만 담겨 있고, 그 화면이 만들어지기까지의 맥락과 예외 상황은 대부분 기획자의 머릿속에만 있습니다.
그래서 회의 전에 질문 목록을 정리해두지 않으면, 개발자는 스스로 판단해서 빈틈을 채우게 됩니다. 그 판단이 기획 의도와 다르면 QA 단계에서 다시 수정 요청이 들어오고, 일정은 그만큼 늘어납니다. 아래 10가지 질문은 그 빈틈을 회의 자리에서 바로 메우기 위한 것입니다.
카테고리별 질문 10가지
디자인 의도 파악
개발자가 목적을 알고 있으면 애매한 케이스가 나왔을 때 스스로 우선순위를 판단할 수 있습니다. 목적을 공유하지 않으면 화면 순서와 배치만 보고 짐작하게 됩니다.
한 화면에 버튼이 여러 개면 개발 순서와 테스트 우선순위가 갈립니다. 어떤 동작이 핵심 플로우인지 먼저 짚어두면 QA 리소스도 그쪽에 먼저 배분됩니다.
컴포넌트·시스템 확인
재사용 여부에 따라 코드 설계 방식이 완전히 달라집니다. 1회성으로 만들었다가 나중에 재사용 요청이 들어오면 리팩터링 비용이 발생합니다.
기본 상태만 그려져 있고 나머지 상태가 빠진 경우가 흔합니다. 회의에서 빠진 상태를 짚어주면 개발 중 임의로 스타일을 정하는 상황을 막을 수 있습니다.
피그마 스타일 이름과 코드의 변수 이름이 다르면 매핑 과정에서 오차가 생깁니다. 동기화 여부를 미리 확인하면 디자인 QA 단계의 색상·간격 이슈를 줄일 수 있습니다.
반응형·예외 처리
데스크톱 화면만 그려져 있고 태블릿·모바일 레이아웃이 없는 경우가 많습니다. 회의 자리에서 최소한 우선순위가 높은 화면만이라도 브레이크포인트별 방향을 합의해두는 것이 좋습니다.
빈 상태, 로딩 상태, 텍스트가 길어질 때의 줄바꿈 처리는 실제 서비스에서 가장 자주 발생하는 케이스입니다. 이 부분이 정의되어 있지 않으면 개발자가 임의로 처리하고 넘어가는 경우가 많습니다.
인터랙션·애니메이션
애니메이션은 정적인 화면에 담기 어려워서 회의에서 말로 설명하고 넘어가는 경우가 많습니다. 프로토타입 링크나 참고 레퍼런스를 함께 공유하면 구현 방향을 맞추기 쉬워집니다.
협업 프로세스
개발이 진행되는 도중에도 디자인은 수정되는 경우가 많습니다. 변경 공유 채널과 방식을 미리 정해두면 최신 버전과 다른 화면으로 개발이 진행되는 상황을 막을 수 있습니다.
QA 담당자와 체크 기준이 명확하지 않으면 완성도 판단이 사람마다 달라집니다. 회의 단계에서 QA 기준을 합의해두면 배포 직전의 되돌리기 작업을 줄일 수 있습니다.
실무 팁 3가지
팁1. 질문지는 회의 전에 먼저 공유한다
회의 당일 즉석에서 질문하면 개발자도 그 자리에서 바로 답하기 어려운 경우가 많습니다. 질문 목록을 하루 전에 공유해두면 필요한 답을 준비해서 회의 시간을 절반으로 줄일 수 있습니다.
팁2. "왜"를 묻는 질문을 하나는 꼭 넣는다
"이거 왜 이렇게 만들었어요"라는 질문이 아니라, "이 흐름을 이렇게 설계한 이유가 있나요"처럼 의도를 묻는 질문입니다. 의도를 한 번 확인해두면 이후 예외 상황에서 개발자가 스스로 판단할 수 있는 기준이 생깁니다.
팁3. 답변은 그 자리에서 피그마 코멘트로 기록한다
회의에서 나온 답을 회의록에만 남기면 나중에 화면과 답변을 다시 매칭하는 데 시간이 걸립니다. 해당 프레임에 바로 코멘트로 남겨두면 누구든 화면만 보고도 맥락을 파악할 수 있습니다.
마무리
- 핸드오프 회의는 화면 설명이 아니라 빈틈을 채우는 자리입니다.
- 의도, 시스템, 예외, 인터랙션, 프로세스 다섯 갈래로 질문을 준비하면 놓치는 부분이 줄어듭니다.
- 질문지 사전 공유와 코멘트 기록만으로도 재작업 요청을 상당히 줄일 수 있습니다.
다음 회의부터는 이 10가지 질문을 체크리스트로 붙여두고 하나씩 확인해보시길 권합니다. 실제로 사용해보신 뒤 빠진 질문이나 팀마다 다르게 겪은 상황이 있다면 댓글로 공유해 주시면 다음 글에서 함께 다뤄보겠습니다.
FAQ
스프린트 단위로 새 화면이 나올 때마다 진행하는 팀이 많습니다. 다만 화면 수가 많지 않다면 스프린트 시작 시점에 한 번으로 묶어 진행해도 무리가 없습니다.
이름 자체를 맞추기보다 매핑 표를 만들어 공유하는 방식이 현실적입니다. 이름 통일은 디자인 시스템 리뉴얼 시점에 별도로 진행하는 것이 일정 부담이 적습니다.
답이 바로 나오지 않는 질문은 회의 중 결론을 내려 하지 말고 담당자와 기한을 정해 별도로 처리하는 편이 낫습니다. 회의는 질문을 확인하는 자리이지, 모든 답을 즉석에서 만드는 자리는 아닙니다.