이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
동아리 앱 프로젝트에서 JavaScript로 개발하다가 undefined 오류가 반복됐습니다. 같은 팀원이 API 응답 형식을 바꿨는데 다른 파일에서 모르고 계속 쓰다가 런타임에서 터지는 패턴이었습니다. 저는 TypeScript로 전환을 제안했고, 처음에는 타입 선언이 낯설어서 설정에만 이틀이 걸렸습니다. 타입 오류가 100개 가까이 나와서 처음엔 포기하고 싶었지만, 하나씩 수정하면서 오히려 로직 오류를 같이 발견하는 경험을 했습니다.
이후 3개월간 런타임 타입 오류가 0건이었습니다. TypeScript는 초기 비용이 있지만 팀에서 같이 쓸수록 가치가 올라가는 도구라는 걸 직접 느꼈습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
팀 프로젝트에서 프론트와 백엔드를 분리 개발하면서 API 응답 구조에 대한 이해가 달라서 생기는 충돌이 반복됐습니다. 저는 공통 타입 정의 파일을 만들어서 두 팀이 같은 인터페이스를 참조하도록 구조를 제안했습니다. 처음에는 백엔드 담당자가 타입 파일 관리가 번거롭다고 했고, 실제로 한 번은 타입 파일 업데이트가 늦어서 혼란이 생겼습니다.
타입 변경 시 PR에 꼭 포함하는 규칙을 만들었더니 이후에는 충돌이 없었습니다. 마지막 3주 동안 API 인터페이스 관련 디버깅 시간이 거의 없었습니다. TypeScript는 팀이 같은 언어로 소통하게 만드는 도구라는 걸 배웠습니다.
학교 과제에서 TypeScript를 처음 쓰면서 제네릭 타입이 뭔지 몰라서 거의 쓰지 않았습니다. 나중에 비슷한 구조의 리스트 컴포넌트를 3개 따로 만들면서 유지보수가 어렵다는 걸 느꼈습니다. 제네릭을 공부하고 나서 하나의 컴포넌트에서 타입 파라미터로 분기하는 방식으로 리팩토링했습니다. 처음에는 제네릭 문법이 헷갈려서 잘못 쓴 경우도 있었고, 빌드 오류 메시지가 길어서 해석하기 어려웠습니다.
결국 3개의 컴포넌트를 1개로 줄이면서 코드 양도 40% 이상 줄었습니다. TypeScript의 타입 시스템은 처음엔 불편하지만 쓸수록 코드 품질을 높여주는 도구라는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 직방 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.