우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›당근마켓›프론트엔드›질문 상세
    問
    당당근마켓프론트엔드경험·이력2026년 출제

    TypeScript와 React를 사용한 프로젝트에서 어떤 기술적 도전을 경험했으며, 이를 어떻게 해결했나요?

    답변 미리보기

    TypeScript와 React를 처음 함께 쓴 프로젝트에서 제네릭 타입 추론이 의도대로 되지 않아 런타임 오류가 반복됐습니다. 컴파일 단계에서 통과한 코드가…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    어떤 기술적 도전이 있었는가?
    TypeScript와 React를 사용한 프로젝트에서 겪은 기술적 도전의 흔적이 답에 있어야 합니다. 없으면 면접관이 '구체적으로 어떤 문제였나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    어떻게 문제를 해결했는가?
    해결 과정에서의 접근 방식이나 사용한 방법론에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '그 방법이 왜 효과적이었나요?' 같은 질문을 던지는 자리가 자주 보입니다.
    語
    03
    프로젝트의 결과는 어땠는가?
    프로젝트 완료 후의 결과나 성과에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '그 결과가 팀이나 프로젝트에 어떤 영향을 미쳤나요?'를 추가로 묻는 경우가 많습니다.
    本
    04
    어떤 기술 스택을 사용했는가?
    TypeScript와 React 외에 사용한 기술 스택이나 도구에 대한 흔적이 답에 있어야 합니다. 없으면 면접관이 '다른 기술은 어떤 것이었나요?'를 추가로 묻는 경우가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    당근마켓 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    타입 에러나 상태 관리 같은 구체적 도전을 문제→해결→성과 흐름으로 서술약 90초Profiler로 렌더링 병목을 시각화하고 useCallback/useMemo로 최적화한 경험약 90초Vitest 도입 시 path alias 불일치 문제를 해결하고 행동 기반 테스트를 적용한 경험약 90초
    TypeScript + React 기술 도전 + 해결 + 결과
    약 90초

    타입 에러나 상태 관리 같은 구체적 도전을 문제→해결→성과 흐름으로 서술

    TypeScript와 React를 처음 함께 쓴 프로젝트에서 제네릭 타입 추론이 의도대로 되지 않아 런타임 오류가 반복됐습니다. 컴파일 단계에서 통과한 코드가 실행 시 터지는 상황이 처음엔 이해가 안 됐는데, 원인은 any 타입을 여러 곳에 쓰면서 타입 안전성이 사실상 비활성화된 것이었습니다. 해결 방법은 any를 전부 찾아 unknown으로 바꾸고 타입 가드를 명시적으로 추가하는 방식이었습니다. React 상태 관리에서는 컴포넌트 간 데이터 흐름이 복잡해지면서 props drilling이 5단계를 넘어가는 상황이 생겼고, Context API로 구조를 리팩토링해서 코드 가독성을 크게 개선했습니다. 기술 스택으로는 Vite, Tailwind CSS, React Query를 함께 사용했는데, React Query 도입 후 캐싱 처리를 별도로 안 해도 되는 편의성이 인상적이었습니다. 이 프로젝트에서 TypeScript를 제대로 쓰려면 처음 타입 설계에 시간을 쓰는 것이 나중 디버깅보다 훨씬 빠르다는 걸 배웠습니다.

    이 결의 특징
    any 타입 남용으로 타입 안전성이 무력화된 원인을 진단하고 unknown과 타입 가드로 해결한 결입니다. props drilling을 Context API로 리팩토링한 추가 개선까지 포함합니다.
    이 결이 통하는 자리
    TypeScript의 실무적 함정 이해를 확인하는 자리에서 통하는 결입니다. 오류 발생만 말하고 근본 원인(any 남용) 진단이 없으면 표면적 수정으로 읽힐 위험이 있습니다.
    렌더링 최적화·Profiler 분석
    약 90초

    Profiler로 렌더링 병목을 시각화하고 useCallback/useMemo로 최적화한 경험

    TypeScript + React 프로젝트에서 컴포넌트 렌더링 최적화로 고생한 경험이 있습니다. 기능을 추가할수록 특정 상태 변경 시 관련 없는 컴포넌트까지 전부 재렌더링되는 문제가 생겼는데, 초반에는 원인이 렌더링인지 API 지연인지 구분도 못 했습니다. React DevTools의 Profiler 탭을 처음 써본 것이 그때였는데, 어느 컴포넌트가 얼마나 자주 렌더링되는지 시각화로 보고 나서야 문제의 윤곽이 잡혔습니다. 원인 중 하나는 부모에서 매번 새로 생성되는 함수를 자식에게 props로 넘기는 패턴이었고, useCallback과 useMemo를 적용해서 불필요한 렌더링을 40% 이상 줄였습니다. TypeScript와의 조합에서는 memo로 감싼 컴포넌트의 props 타입을 명확히 하지 않으면 타입 추론이 제대로 안 되는 경우가 있었는데, 타입 설계가 최적화와 연결된다는 걸 배웠습니다. 기술 스택으로는 Vite와 Tailwind CSS를 함께 사용했습니다. 성능 문제는 느리다는 감각이 있어도 어디가 느린지를 특정하기 전까지는 손댈 곳이 보이지 않는다는 걸 그때 처음 제대로 겪었습니다.

    이 결의 특징
    렌더링 지연의 원인을 특정하지 못하다가 Profiler로 시각화해 문제 윤곽을 잡은 결입니다. useCallback·useMemo로 불필요한 렌더링을 40% 이상 줄인 구체적 성과가 특징입니다.
    이 결이 통하는 자리
    성능 문제의 진단 도구 활용력을 확인하는 자리에서 통하는 결입니다. 최적화했다고만 말하고 진단 도구 사용이 없으면 감으로 수정한 것으로 읽힐 위험이 있습니다.
    테스트 환경 설정·path alias 트러블슈팅
    약 90초

    Vitest 도입 시 path alias 불일치 문제를 해결하고 행동 기반 테스트를 적용한 경험

    TypeScript + React 프로젝트에서 테스트 환경 설정이 예상외로 많은 시간을 잡아먹는 도전이었습니다. Vite 기반 프로젝트에 Vitest를 도입하려고 했는데, TypeScript path alias가 테스트 환경에서 인식되지 않는 문제가 반복됐습니다. 설정 파일이 vite.config.ts와 vitest.config.ts로 분리되면서 alias를 두 곳에서 일관되게 맞춰야 한다는 걸 뒤늦게 알았습니다. 이 과정에서 tsconfig.json의 paths 설정이 빌드 도구와 테스트 러너에 각각 어떻게 연결되는지를 처음으로 제대로 이해했습니다. React 컴포넌트 테스트에서는 @testing-library/react를 사용했는데, 사용자 행동 기반으로 테스트를 쓰는 방식이 처음엔 낯설었지만 컴포넌트 내부 구현이 바뀌어도 테스트가 깨지지 않는다는 장점이 실감났습니다. 기술 스택으로는 Vite, Tailwind CSS, React Query를 함께 사용했습니다. 도구를 추가할 때는 그 도구가 기존 설정 전체에 어떻게 영향을 주는지를 먼저 파악하는 것이 시행착오를 줄이는 방법이라는 걸 배웠습니다.

    이 결의 특징
    path alias가 빌드 도구와 테스트 러너에 각각 다르게 연결됨을 파악해 설정을 일관되게 맞춘 결입니다. 행동 기반 테스트가 구현 변경에도 깨지지 않는다는 장점 체감이 특징입니다.
    이 결이 통하는 자리
    도구 설정의 전체 영향 파악력을 확인하는 자리에서 통하는 결입니다. 설정 문제만 말하고 근본 원인 이해가 없으면 시행착오로만 읽힐 위험이 있습니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹그 도전 과제가 팀원들과의 협업에 어떤 영향을 미쳤나요?
    貳해결 과정에서 어떤 리소스를 활용했나요?
    參만약 그 문제를 다시 겪는다면 어떻게 접근하실 건가요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 당근마켓 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    토스 · 프론트엔드
    TypeScript와 React를 사용한 프로젝트에서의 경험을 구체적으로 이야기해 주세요.
    이 질문 보기
    배달의민족(우아한형제들) · 프론트엔드
    TypeScript와 React를 사용한 프로젝트 경험에 대해 구체적으로 설명해 주세요.
    이 질문 보기
    배달의민족(우아한형제들) · 프론트엔드
    TypeScript와 React를 활용한 프로젝트 경험에 대해 구체적으로 이야기해 주세요.
    이 질문 보기
    마켓컬리 · 프론트엔드
    React와 TypeScript를 사용한 프로젝트에서 경험한 어려움과 그 해결 방법에 대해 이야기해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 당근마켓 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기