이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모바일 결제 UI 컴포넌트 설계에서 가장 먼저 한 것은 결제 플로우 전체 흐름을 다이어그램으로 정리하는 것이었습니다. 어떤 화면이 어떤 상태를 갖는지, 에러·로딩·성공 상태 각각의 UI를 미리 정의해두지 않으면 구현 도중 빠진 케이스가 생겼습니다.
컴포넌트 단위 분리에서는 재사용 가능한 단위와 결제 전용 단위를 명확히 구분했습니다. 금액 표시 컴포넌트는 다른 화면에서도 쓸 수 있지만, 카드 등록 폼은 결제 흐름에만 종속돼 있어 분리 기준을 다르게 잡았습니다.
접근성도 함께 고려했습니다. 결제는 실수가 금전 피해로 이어지기 때문에 터치 영역 크기와 오류 메시지 명확성이 특히 중요했습니다. 스크린 리더 라벨을 적절히 달아두면 접근성 향상과 함께 테스트 자동화에서도 요소 선택이 수월해졌습니다.
결제 UI 컴포넌트를 개발할 때 컴포넌트가 실제로 재사용되고 있는지, 접근성 기준을 유지하고 있는지 측정하는 방법을 고민했습니다. Storybook에 컴포넌트를 등록하고 각 컴포넌트의 사용처를 추적하니 같은 기능의 컴포넌트를 팀 내 다른 사람이 중복으로 만들고 있는 것을 발견했습니다. 컴포넌트 카탈로그를 팀 전체가 볼 수 있도록 공유하니 중복 개발이 줄었습니다. 접근성은 axe 도구를 CI에 통합해 빌드 시 자동으로 접근성 위반을 감지하도록 했습니다. 결제 입력 필드에 aria-label이 빠진 경우를 배포 전에 자동으로 잡아낼 수 있었습니다. 디자인 토큰으로 색상·간격·타이포그래피를 변수로 관리하면서 테마가 바뀌어도 모든 컴포넌트가 일관성을 유지하는지 시각적 회귀 테스트로 확인했습니다.
컴포넌트 품질은 초기 설계만큼 지속적으로 검증하는 체계에서 유지된다는 것을 이 경험에서 얻었습니다.
결제 UI에서 카드 번호 입력 필드를 어떻게 구현할지가 일반 입력 폼과 달라야 한다는 것을 처음 설계할 때 인식했습니다. PCI-DSS 요구 사항 때문에 카드 번호가 서비스 앱에 직접 저장되면 안 되므로, 카드 입력 폼을 아이프레임으로 격리해 PG사 도메인에서 렌더링하는 방식을 선택했습니다. 이렇게 하면 서비스 앱 코드가 카드 번호에 절대 접근할 수 없는 구조가 됩니다. 사용자에게 보이는 마스킹(앞 4자리만 표시)도 설계했는데, 실제 카드 번호는 클라이언트 메모리에도 없고 PG사 서버에만 토큰으로 남는 흐름을 다이어그램으로 먼저 정리했습니다. 결제 상태 전환(입력 → 처리 중 → 성공/실패) 각 단계에서 입력 필드가 비활성화되거나 메시지가 바뀌는 흐름도 미리 정의했습니다.
결제 UI는 기능 구현 전에 보안 데이터 흐름을 먼저 설계해야 구현 도중 구조를 바꾸는 비용을 피할 수 있다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.