이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 한국어·영어 두 언어를 지원해야 했는데, 처음에는 컴포넌트 안에 텍스트를 직접 넣었다가 나중에 변경이 너무 어려워졌습니다. react-i18next를 도입하면서 텍스트를 키-값 구조로 분리했고, 언어 파일을 /locales/ko.json, /locales/en.json으로 나눴습니다. 처음 구조를 잡을 때 중첩 키 설계를 잘못해서 키 이름이 중복되는 문제가 생겼고, 전체를 한 번 리팩터링했습니다. 이후로는 기능 단위로 네임스페이스를 나눠서 관리했고, 유지보수가 훨씬 쉬워졌습니다.
i18n 설계에서 초기 네임스페이스 구조를 잘 잡는 게 나중에 가장 큰 차이를 만든다는 걸 그때 배웠습니다.
다국어 지원에서 단순 텍스트 번역보다 날짜, 숫자, 복수형 처리가 더 까다로웠습니다. 영어에서 복수형이 달라지는 케이스를 처음에는 하드코딩으로 처리했다가, 조건이 늘어나면서 코드가 복잡해졌습니다. i18next의 `plural` 기능을 쓰면 언어별 복수 규칙을 자동으로 처리할 수 있다는 걸 알게 됐습니다. 날짜는 Intl.DateTimeFormat으로 로케일에 맞는 형식을 자동 적용했습니다. 처음에는 모든 언어 처리를 직접 구현하려 했는데, 표준 `API`를 활용하는 것이 훨씬 정확하고 유지보수도 쉽다는 걸 배웠습니다.
i18n은 단순 번역이 아니라 언어별 규칙을 시스템으로 처리하는 문제라는 걸 그 경험에서 이해했습니다.
다국어 대응 프로젝트를 직접 운영한 경험은 아직 없지만, 공부하면서 초기 설계 방향이 나중을 결정한다는 걸 배웠습니다. 텍스트를 컴포넌트에 직접 넣으면 나중에 번역 추가가 어려워지는 구조가 됩니다. i18next 같은 라이브러리를 쓰면 키-값으로 분리해서 언어 파일만 교체하는 구조를 만들 수 있습니다. 또한 RTL 언어 지원이 필요할 경우 CSS 레이아웃 방향도 처음부터 고려해야 한다는 걸 알고 있습니다. 아직 실무 경험이 짧아서 시행착오가 있을 수 있지만, 설계 단계에서 언어 확장을 고려해두는 것이 나중에 비용을 줄인다는 원칙은 적용할 수 있다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스뱅크 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.