이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
다양한 국가와 언어를 지원하는 컴포넌트 시스템을 구축할 때 가장 먼저 한 것은 텍스트를 컴포넌트에서 완전히 분리하는 것이었습니다. 하드코딩된 문자열이 컴포넌트 안에 있으면 다국어 처리가 불가능하기 때문에, i18n 라이브러리를 통해 키 기반으로 텍스트를 관리하는 구조를 잡았습니다.
RTL(오른쪽에서 왼쪽) 레이아웃 지원도 고려했습니다. 아랍어·히브리어처럼 텍스트 방향이 다른 언어를 지원할 때, CSS의 direction 속성과 논리적 속성을 사용하면 레이아웃이 자동으로 반전되어 별도 RTL 스타일시트 없이 대응할 수 있었습니다.
컴포넌트 설계 단계에서 문자열 길이 변동에 대한 여유를 확보했습니다. 같은 의미라도 독일어·러시아어가 영어보다 훨씬 길어지기 때문에, 버튼이나 레이블이 텍스트 길이에 맞게 유연하게 늘어나는 구조를 처음부터 적용했습니다.
다국어 지원을 추가한 직후 특정 언어에서만 빈 텍스트가 노출되는 버그가 보고됐습니다. 원인을 추적하니 영어 키가 추가됐는데 한국어 번역 파일에는 해당 키가 없는 상태였습니다. 처음엔 PR 리뷰에서 수동으로 확인했지만, 파일이 많아지면서 누락을 놓치는 경우가 반복됐습니다. 그래서 i18n 번역 파일을 검사하는 스크립트를 직접 작성해서 GitHub Actions에 연결했습니다.
기준 언어 파일의 키와 다른 언어 파일의 키를 비교해서 누락이 있으면 빌드가 실패하도록 만들었습니다. 이후에는 번역 누락이 코드 리뷰 단계에서 자동으로 걸렸고, 배포 후 이 유형의 버그 보고가 완전히 없어졌습니다. 그게 처음 확인됐을 때 자동화의 효과를 실감했습니다.
다국어 번역 파일을 한 번에 모두 로드했더니 초기 번들 크기가 눈에 띄게 커졌습니다. 지원 언어가 5개였는데, 사용자는 한 번에 한 언어만 쓰는데 5개 언어 번역을 모두 다운받게 하는 구조였습니다. 처음엔 큰 문제가 아닐 거라 생각했는데, Lighthouse로 성능 측정을 해보니 번역 파일만 초기 로드에서 380KB를 차지했습니다.
언어별로 청크를 분리하는 동적 임포트를 적용했더니 초기 로드 크기가 95KB까지 줄었습니다. 구현 중에 언어 전환 시 깜빡임이 생겼는데, 로딩 스피너를 언어 파일 로드에도 연결해서 해결했습니다. 수치가 나오니 무엇이 효과가 있었는지 판단하기 쉬웠고, 성능 개선은 측정부터 시작한다는 것을 이때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.