이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
동아리 프로젝트에서 팀원 4명이 코드 스타일이 달라서 PR마다 스타일 관련 댓글이 절반이었습니다. ESLint와 Prettier를 같이 설정하기로 했는데, 처음에는 규칙 충돌로 저장할 때마다 코드가 이상하게 변하는 문제가 발생했습니다. eslint-config-prettier로 충돌하는 규칙을 꺼야 한다는 것을 이틀 만에 알아냈습니다. pre-commit 훅까지 연결하여 린트 실패 시 커밋이 되지 않도록 했으나, 팀원 한 명이 자꾸 우회 방법을 찾아서 갈등이 생겼습니다. 강제가 아니라 팀이 왜 이 도구를 쓰는지 공감해야 작동한다는 것을 배웠습니다. 현재는 린터 규칙을 선정할 때 팀원 의견을 먼저 듣는 방식으로 변경되었습니다.
개인 프로젝트가 커지면서 CRA 기반 빌드 시간이 40초가 넘어갔어요. 핫 리로딩도 느려서 작은 변경사항 하나 확인하는 데 답답했어요. Vite로 마이그레이션한다는 글을 보고 시도했는데, 절대 경로 alias 설정과 환경 변수 형식이 달라서 처음에 빌드가 깨졌어요. 이틀 동안 삽질해서 마이그레이션을 완료했고, 빌드 시간이 40초에서 6초로 줄었어요. HMR이 빨라지니까 개발 흐름이 끊기지 않았어요. 근데 플러그인 생태계가 CRA보다 얇아서 일부 기능은 직접 설정해야 했어요. 이 경험으로 도구 마이그레이션은 성능 이득과 세팅 비용을 같이 따져봐야 한다는 걸 배웠어요.
졸업 프로젝트에서 웹앱과 관리자 앱이 동시에 있었는데, 공통 유틸 함수와 타입 정의가 각각에 복붙되어 있었어요. 한 쪽을 수정하면 다른 쪽도 같이 바꿔야 해서 실수가 자주 났어요. pnpm workspace로 모노레포를 시도했는데, 경로 설정과 tsconfig 상속 구조를 잘못 짜서 처음엔 타입 에러가 20개 넘게 났어요. 이틀 반 만에 겨우 빌드를 성공시켰지만, 그 이후론 어느 쪽 수정이든 공통 패키지 한 군데만 고치면 됐어요. 실패하면서 설정한 구조가 오히려 더 오래 기억에 남는다는 걸 느꼈고, 개발 환경 개선은 단기 고통이 있더라도 장기 생산성을 높이면 가치 있다고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.