이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Figma 라이브러리를 팀으로 운영하면서 컴포넌트 이름을 바꿨을 때 기존에 쓰던 파일에서 연결이 끊기는 문제가 가장 자주 생겼습니다. 이름 변경이 불가피할 때는 이전 버전을 유지하면서 새 버전과 병행하는 기간을 두고 팀에 공지했고, 그 이후 예고 없는 변경을 줄이는 규칙을 팀에서 합의했습니다.
버전 변경 이력을 라이브러리 페이지 상단에 간략히 남겨두면 팀원이 언제 무엇이 바뀌었는지 추적할 수 있었습니다. 누가 어떤 컴포넌트를 얼마나 쓰는지도 주기적으로 점검하면 쓰이지 않는 컴포넌트를 정리하고 관리 부담을 줄일 수 있습니다. 라이브러리 운영은 기술 작업이 아니라 팀 협업 운영이라는 걸 경험하면서, 규칙 합의와 소통이 가장 중요한 요소라는 걸 배웠습니다.
Figma 라이브러리에서 자주 생긴 문제 중 하나는 같은 목적의 컴포넌트가 서로 다른 이름으로 여러 개 존재하는 것이었습니다. 팀원마다 필요한 컴포넌트를 라이브러리에서 찾지 못하고 새로 만들면서, 기능이 비슷한 버튼이 여러 버전으로 불어난 경우가 있었습니다. 원인은 검색할 때 쓰는 키워드가 달랐기 때문이었습니다. 이후 컴포넌트 명명 규칙을 문서화하고 팀 전체와 공유했습니다. 카테고리/컴포넌트명/상태 구조로 통일했고, 새 컴포넌트를 만들기 전에 검색을 먼저 해보는 것을 팀 규칙으로 정했습니다.
라이브러리는 만드는 사람만큼 찾는 사람의 관점에서 설계해야 한다는 것을 그때 배웠습니다. 명명 규칙 하나가 중복 컴포넌트 문제를 대부분 해결했습니다.
Figma 라이브러리를 운영하면서 가장 긴장됐던 경험은 업데이트를 팀에 공지하지 않고 적용했다가 작업 파일 레이아웃이 깨지는 사고였습니다. 오토 레이아웃 기준을 변경하고 라이브러리에 반영했는데, 팀원들의 작업 파일에 자동으로 반영되면서 여러 화면의 간격이 한꺼번에 틀어졌습니다. 그 화면들을 다시 잡는 데 한 시간 이상이 걸렸습니다. 이후 영향도가 있는 변경은 반드시 사전에 팀에 공지하고, 당일 적용 전에 확인을 받는 절차를 만들었습니다. 라이브러리는 연결된 모든 파일에 영향을 주기 때문에, 변경의 범위를 먼저 파악하는 것이 필수라는 것을 그때 이해했습니다. 관리 도구는 편의를 위한 것인데 사고를 만들지 않으려면 운영 절차가 더 중요합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 PTKOREA UX/UI 디자이너 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.