우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›토스›프론트엔드›질문 상세
    問
    토토스프론트엔드직무 역량2026년 출제

    React의 렌더링 최적화 방법(useMemo, useCallback, React.memo 등)을 언제 사용하고 언제 사용하지 말아야 하는지 본인의 기준으로 설명해주세요.

    답변 미리보기

    저의 기준은 단순합니다. 프로파일러로 실제 병목을 확인하기 전에는 먼저 최적화하지 않는다는 것입니다. 처음 리액트를 배울 때 모든 컴포넌트에 와 을 붙이는 게…

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

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

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

    問
    01
    렌더링 최적화 기준은 무엇인가?
    렌더링 최적화 방법을 사용할 기준이 답에 있어야 합니다. 없으면 면접관이 '그 기준은 어떻게 정했나요?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    어떤 상황에서 useMemo를 사용할까?
    useMemo를 사용할 상황에 대한 설명이 답에 있어야 합니다. 없으면 면접관이 '다른 예시가 있을까요?'를 추가로 묻는 경우가 많습니다.
    語
    03
    useCallback의 활용 사례는?
    useCallback의 활용 사례가 답에 포함된 흔적이 있어야 합니다. 없으면 면접관이 '왜 그 경우에 선택했나요?'를 자주 묻는 자리가 보입니다.
    本
    04
    React.memo는 언제 필요한가?
    React.memo를 사용할 필요성이 답에 있어야 합니다. 없으면 면접관이 '그 이유는 무엇인가요?'를 추가로 묻는 경우가 흔하게 통합니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    토스 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    실제 병목 확인 후 적용 원칙 중심으로 푸는 결약 110초컴포넌트 구조 분리·상태 범위 최소화 중심으로 푸는 결약 105초코드 분할·가상화 실무 경험 중심으로 푸는 결약 110초
    예시 답변 1
    약 110초

    실제 병목 확인 후 적용 원칙 중심으로 푸는 결

    저의 기준은 단순합니다. 프로파일러로 실제 병목을 확인하기 전에는 먼저 최적화하지 않는다는 것입니다. 처음 리액트를 배울 때 모든 컴포넌트에 와 을 붙이는 게 좋다고 생각했는데, 오히려 의존성 배열 관리가 복잡해지고 코드 가독성만 떨어지는 경험을 했습니다. 지금은 는 계산 비용이 명확하게 큰 연산에만 씁니다. 예를 들어 리스트 필터링이나 정렬을 매 렌더마다 반복하는 경우가 여기 해당합니다. 단순한 덧셈이나 문자열 변환에는 쓰지 않습니다. 은 자식 컴포넌트에 함수를 props로 내려줄 때, 그 자식이 로 감싸져 있는 경우에 의미가 생깁니다. 그렇지 않으면 만 써도 자식은 어차피 재렌더됩니다. 는 props가 자주 바뀌지 않는데 렌더 비용이 높은 컴포넌트에 씁니다. 반대로 props가 자주 바뀌면 얕은 비교 비용만 추가되고 실익이 없습니다. 결국 세 가지 모두 측정 없이 쓰면 복잡도만 높이는 도구라는 게 제 판단 기준입니다.

    이 결의 특징
    프로파일러로 병목을 확인하기 전에는 최적화하지 않는다는 원칙을 세우고, 리스트 필터링처럼 계산 비용이 명확한 경우로 useMemo 적용 기준을 좁힌 흔적이 있습니다. 의존성 배열 관리 복잡도라는 반대급부까지 언급하는 결이 담겨 있습니다.
    이 결이 통하는 자리
    측정 없이 쓰면 복잡도만 높인다는 결론이 구체 실패 경험과 함께 살아 있을 때 통합니다. React.memo와 함수 전달의 조합 조건까지 구분해 설명될 때 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    B
    약 105초

    컴포넌트 구조 분리·상태 범위 최소화 중심으로 푸는 결

    렌더링 최적화를 도구의 문제로 접근하기보다, 컴포넌트 구조를 어떻게 나누느냐의 문제로 먼저 봅니다. 상태가 필요 이상으로 높은 위치에 있으면 하위 트리 전체가 불필요하게 다시 렌더되기 때문에, 상태를 최대한 쓰는 곳 가까이에 배치하는 것이 가장 기본적인 최적화라고 생각합니다. 이 구조적 접근이 먼저 되면 useMemo나 useCallback을 써야 할 상황이 줄어듭니다. 그럼에도 쓰게 되는 경우는 정렬이나 필터링처럼 렌더마다 재계산하기 아까운 연산이 있을 때입니다. 이런 경우 useMemo로 의존성이 바뀔 때만 재계산하도록 명시하면 의도가 코드에 드러나는 효과도 있습니다.

    React.memo는 props 변화 빈도가 낮고 렌더 비용이 높은 컴포넌트에만 씁니다. 모든 컴포넌트에 붙이면 비교 연산 비용이 쌓이고, useCallback 없이 함수를 내려줬을 때 왜 재렌더가 발생하는지 디버깅이 어려워지는 경험도 했습니다. 도구를 쓰기 전에 구조를 먼저 본다는 것이 제 기준입니다.

    이 결의 특징
    도구 선택보다 컴포넌트 구조와 상태 위치를 먼저 보는 순서를 세우고, 상태를 쓰는 곳 가까이 배치하는 원칙으로 최적화 필요 자체를 줄이는 관점을 담은 흔적이 있습니다. useCallback 누락으로 디버깅이 어려웠던 경험이 뒤따르는 결이 보입니다.
    이 결이 통하는 자리
    도구를 쓰기 전에 구조를 먼저 본다는 순서가 명확할 때 통합니다. 렌더 비용과 props 변화 빈도를 나눠 React.memo 적용 여부를 판단하는 기준이 구체적으로 살아 있을 때 설득력이 생기는 결이 보입니다.
    C
    약 110초

    코드 분할·가상화 실무 경험 중심으로 푸는 결

    useMemo·useCallback보다 더 큰 임팩트를 준 것은 코드 분할과 가상화였습니다. 대시보드 페이지를 만들 때 번들 사이즈가 커서 초기 로드가 느려지는 문제가 있었는데, `React.lazy`와 `Suspense`로 무거운 차트 컴포넌트를 분리하고 나서 LCP가 눈에 띄게 줄었습니다. 같은 페이지에서 1,000개 이상의 항목을 렌더하는 리스트가 있었는데, `react-window`로 가상화를 적용하자 스크롤 성능이 완전히 달라졌습니다. 이 두 가지를 경험하고 나서 최적화 작업을 할 때 코드 분할과 가상화부터 검토하게 됐습니다.

    useMemo와 useCallback은 그다음 단계입니다. 실제로 이 둘로 개선되는 경우는 생각보다 많지 않았고, 잘못 쓰면 의존성 관리 때문에 버그가 오히려 늘어나는 경험도 했습니다. 최적화는 측정 후에, 구조적 수단을 먼저 소진한 다음에 하는 것이 맞는 순서라고 봅니다.

    이 결의 특징
    useMemo·useCallback보다 코드 분할과 가상화가 더 큰 임팩트를 줬다는 우선순위를 명확히 하고, react-window 도입으로 스크롤 성능이 달라진 구체 사례를 붙인 흔적이 있습니다. 측정 후 구조적 수단을 먼저 소진한다는 순서가 담겨 있습니다.
    이 결이 통하는 자리
    의존성 관리로 버그가 늘었던 실패까지 인정하며 우선순위를 다시 정리하는 결이 살아 있을 때 통합니다. LCP 개선처럼 수치화된 결과가 함께 나올 때 면접관이 실무 경험으로 읽는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

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

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

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

    壹useMemo를 사용한 경험이 있나요?
    貳React.memo를 사용했을 때의 효과는 무엇이었나요?
    參useCallback을 사용하지 않았다면 어떻게 되었을까요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 토스 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

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

    토스 · 프론트엔드
    React를 사용한 프로젝트에서 가장 어려웠던 점과 이를 어떻게 해결했는지 이야기해 주세요.
    이 질문 보기
    컨트롤나인 · 게임 아트
    레벨 최적화 경험이 있다면, 어떤 방법을 사용했는지 설명해 주세요.
    이 질문 보기
    토스 · 프론트엔드
    브라우저 렌더링 성능을 고려하여 최적화를 진행한 경험이 있다면, 어떤 방법을 사용했는지 설명해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 토스 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기