이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트에서 JavaScript로 시작한 React 앱을 TypeScript로 마이그레이션했습니다. 처음에는 타입 에러가 쏟아져서 당황했습니다. any로 막으면 에러가 사라지지만 타입스크립트를 쓰는 의미가 없다고 생각하여 하나씩 타입을 정의했습니다. API 응답 타입을 정의하면서 백엔드 명세와 실제 데이터가 다른 필드가 있다는 것을 발견했습니다. 그때 런타임 오류를 미리 잡아준 순간이었습니다.
타입스크립트가 귀찮은 것이 아니라 실수를 미리 잡아주는 것이라는 것을 직접 느꼈습니다. 이후로는 새 프로젝트를 시작할 때 TypeScript를 처음부터 도입하는 것이 습관이 되었습니다.
졸업 프로젝트에서 React로 대시보드를 만들었는데 컴포넌트가 점점 커지는 문제가 생겼어요. 한 파일이 300줄을 넘어가면서 수정할 때 어디를 건드려야 할지 팀원들이 자주 물었습니다. Atomic Design 개념을 배우고 나서 버튼·인풋 같은 원자 단위부터 분리하기 시작했어요. 작은 컴포넌트로 쪼개니 재사용이 됐고 수정 범위가 명확해졌습니다. TypeScript를 함께 써서 props 타입을 명시하니 어떤 값을 넘겨야 하는지 자동완성으로 보여서 편했어요. TypeScript를 함께 써서 props 타입을 명시하니 어떤 값을 넘겨야 하는지 자동완성으로 보여서 편했어요. 컴포넌트를 쪼개는 것과 타입을 명확히 하는 것이 팀 협업 속도를 높이는 두 축이라는 걸 배웠습니다.
인턴 때 기존 React 프로젝트에 TypeScript를 도입하는 작업에 참여했어요. 기존 파일에 타입을 붙이는 작업이었는데, 코드베이스를 읽으며 props로 어떤 값이 오는지 추적하는 과정이 어려웠습니다. 함수 인자에 타입이 없으면 어떤 값이 들어오는지 실행해봐야만 알 수 있었는데, 타입을 붙이고 나니 바로 보였어요. 팀원이 "이제 처음 보는 컴포넌트도 props만 보면 이해된다"고 했을 때 뿌듯했습니다. TypeScript는 혼자 쓸 때보다 팀이 쓸 때 효과가 크다는 걸 배웠어요. TypeScript는 혼자 쓸 때보다 팀이 쓸 때 효과가 크다는 걸 배웠어요. 코드에 의도가 담기면 리뷰하거나 인수받을 때 이해 시간이 줄어든다는 걸 이 경험에서 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.