이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
와이어프레임을 코드로 변환할 때 저는 디자이너와 의도를 먼저 확인하는 것을 우선합니다. 단순히 시각적으로 맞추는 것과 인터랙션 흐름을 정확히 구현하는 것은 다르기 때문에, 피그마 주석과 프로토타입을 함께 살피며 모호한 부분을 미리 질문합니다.
그다음은 컴포넌트 단위로 분해하는 작업입니다. 반복 등장하는 UI 패턴을 파악해 재사용 가능한 단위로 추출하면 이후 수정이 훨씬 수월해집니다. 인턴 때 동일한 카드 컴포넌트가 세 화면에 쓰이는 것을 발견하고 공통화한 뒤 props로 변형을 처리해 중복을 크게 줄였습니다.
마지막으로 반응형 분기점 처리를 챙깁니다. 와이어프레임이 데스크톱 기준으로만 그려진 경우가 많아 모바일 축소 시 레이아웃이 깨지는 문제가 자주 발생했습니다. 개발 초기에 분기점을 팀과 합의해두면 나중에 수정 비용을 줄일 수 있었습니다.
와이어프레임을 코드로 변환하면서 색상과 간격 값이 코드 여러 곳에 하드코딩 되어 있었습니다. 디자이너가 브랜드 컬러를 수정하면 열다섯 군데를 따로 바꿔야 하는 상황이 반복됐습니다. CSS 커스텀 프로퍼티로 색상·타이포그래피·간격을 디자인 토큰으로 정의하고, 모든 컴포넌트가 이 토큰만 참조하도록 구조를 바꿨습니다. 이후 브랜드 컬러가 바뀌었을 때 토큰 값 하나만 수정하면 전체에 적용됐고, 디자이너와 피그마 변수 이름을 맞춰두니 커뮤니케이션도 빨라졌습니다. 처음에 토큰 체계를 만드는 데 시간이 걸렸지만 장기적으로 와이어프레임 반영 비용을 줄이는 결이 됐습니다. 디자인 시스템은 컴포넌트 재사용보다 토큰 일관성이 먼저라는 것을 이 경험에서 배웠습니다.
와이어프레임을 빠르게 구현하다 보면 상태를 어디에 둘지 결정하지 않고 일단 전역으로 올리는 패턴이 생겼습니다. 그 결과 간단한 모달 열림/닫힘 상태까지 전역 스토어에 들어갔고, 무관한 컴포넌트가 불필요하게 리렌더링되는 성능 문제가 생겼습니다. 컴포넌트 로컬 상태, 전역 상태(Zustand), 서버 상태(React Query) 세 가지를 명확히 구분하는 기준을 팀에 공유했습니다. 기준은 간단했습니다.
여러 컴포넌트에서 공유되는가, 서버에서 오는 데이터인가에 따라 분류하는 것이었습니다. 리팩터링 후 불필요한 렌더링이 줄고 코드 구조도 명확해졌습니다. 상태 설계는 와이어프레임 변환의 첫 단계이고, 나중에 고치는 비용이 처음에 결정하는 비용보다 항상 큰 결이 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.