“이력서에 ‘React 전문가’라고 적어두면 서류 통과율이 확실히 올라가지 않나요?” 개발자 채용 시장에 갓 발을 들였거나 이직을 준비 중인 많은 이들이 던지는 질문이다. 최근 IT 업계 동향을 살펴보면 프런트엔드 개발자 수요가 꾸준히 증가하면서 React, Vue, Angular와 같은 특정 라이브러리나 프레임워크의 이름을 기술 스택 란에 크게 적어 넣는 이력서가 늘고 있다. 실제로 채용 공고의 상당수가 React 경험자를 우대한다고 명시하고 있기 때문에 지원자들이 이 키워드를 강조하는 것은 자연스러운 흐름으로 보인다.
그러나 정작 채용 담당자나 기술 면접관들은 ‘React 전문가’라는 수식어에 대해 상당히 회의적인 시선을 보낸다. 이는 해당 표현이 지원자의 실질적인 역량을 제대로 드러내지 못하기 때문이다. 문제는 지원자가 스스로를 ‘전문가’라고 칭하는 순간, 면접관은 그 수준에 맞는 매우 높은 기준의 질문을 던지기 시작한다는 데 있다. React의 내부 동작 원리, 렌더링 최적화 기법, 상태 관리 라이브러리의 한계점, 서버 사이드 렌더링과의 결합 전략까지 폭넓은 이해를 요구하는 질문들 앞에서 막상 ‘전문가’라는 단어의 무게를 견디지 못하는 지원자들이 적지 않다.
‘React 전문가’라는 표현이 지니는 또 다른 문제점은 기술의 변화 속도를 간과한다는 점이다. 프런트엔드 생태계는 매우 빠르게 진화하며, 작년에 최적화된 방식이 올해는 더 나은 대안으로 대체되기도 한다. 특정 라이브러리의 버전에 얽매인 경험만으로는 새로운 패러다임에 적응하기 어렵다. 결국 중요한 것은 단순히 특정 도구를 오래 사용했다는 사실이 아니라, 문제를 해결하기 위해 그 도구를 어떤 논리로 선택하고 활용했는지에 대한 사고 과정이다. 이력서에 적힌 기술 이름은 단순한 키워드일 뿐, 그 안에 담긴 깊이는 지원자가 스스로 증명해야 하는 몫이다.
기술 스택을 표현할 때는 ‘전문가’와 같은 추상적인 단어보다 프로젝트의 맥락 속에서 자신의 역할을 구체적으로 드러내는 편이 훨씬 효과적이다. 예를 들어 ‘대용량 트래픽 상황에서 React 쿼리를 활용한 데이터 캐싱 전략을 설계하고, 렌더링 성능을 약 30% 개선한 경험이 있다’라는 식의 서술은 단순히 React를 잘 다룬다는 말보다 훨씬 설득력 있다. 특정 기술에 대한 깊이는 단순 사용 경험이 아니라, 그 기술의 한계를 인지하고 이를 돌파하기 위해 시도한 노력에서 드러난다. 채용 담당자는 ‘React 전문가’라는 수식어보다, 지원자가 어떤 문제를 어떻게 해결했는지에 대한 구체적인 서사에 더 주목한다.
이력서에 기술 스택을 나열하는 대신, 깊이 있는 지식을 보여주는 또 다른 전략은 포트폴리오에 스스로에게 던지는 질문 목록을 포함하는 것이다. 이는 마치 기술 면접관이 지원자에게 묻는 핵심 질문들을 미리 정리해 두는 것과 같다. 예를 들어 ‘React에서 불필요한 리렌더링을 방지하기 위해 어떤 메모이제이션 전략을 사용했는가’, ‘컴포넌트의 상태와 서버 데이터를 어떻게 분리하여 관리했는가’, ‘React 18에서 도입된 동시성 기능을 실제 프로젝트에 적용해 본 경험이 있는가’와 같은 질문들이다. 이러한 질문 목록을 포트폴리오에 게재하면 지원자가 해당 기술의 표면적인 사용법만 아는 것이 아니라 내부 동작 원리와 성능 최적화, 최신 트렌드까지 고민해 왔다는 인상을 강하게 심어줄 수 있다.
면접을 준비하는 과정에서도 마찬가지다. ‘React 전문가’라고 스스로 소개하기보다는, 면접관이 던질 법한 까다로운 질문들을 스스로 만들어 보고 답변을 준비하는 과정이 더 실질적인 도움이 된다. 예를 들어 리액트 훅의 규칙을 왜 지켜야 하는지, 가상 DOM이 실제 DOM보다 항상 빠른지, 키(key) 속성을 사용할 때 인덱스를 쓰면 안 되는 이유가 무엇인지와 같은 질문들은 단순히 React 문서를 읽는 것만으로는 답하기 어려운 경우가 많다. 이런 질문에 자신의 경험과 논리로 답변을 구성하는 과정 자체가 진정한 전문가로 가는 길이다.
초보 개발자에게는 ‘전문가’라는 타이틀보다 ‘꾸준히 학습하는 개발자’라는 인상이 더 매력적으로 비칠 수 있다. 첫 프로젝트를 진행할 때는 작은 단위의 기능을 온전히 구현해 보는 것이 중요하며, 그 과정에서 사용한 기술의 작동 방식을 문서로 기록하는 습관이 큰 자산이 된다. 면접관은 완벽한 결과물보다 문제를 탐구하는 태도와 학습 방법을 눈여겨본다. React 외에도 상태 관리, 라우팅, 테스트 도구 등 다양한 주변 생태계에 대한 이해도를 포트폴리오에 자연스럽게 녹여내는 것이 바람직하다.
포트폴리오 피드백을 받을 때는 단순히 ‘이쁘다’, ‘보기 좋다’는 식의 피드백보다 기술적인 깊이를 확인할 수 있는 질문을 적극적으로 요청하는 것이 좋다. 지인이나 커뮤니티에 ‘내 포트폴리오를 보고 React 렌더링 성능 개선에 대한 나의 접근 방식이 합리적인지 의견을 달라’고 요청하는 식이다. 이렇게 구체적인 질문을 던지면 답변을 통해 자신의 포트폴리오가 타인에게 어떻게 비춰지는지, 어떤 부분이 부족한지 객관적으로 파악할 수 있다. 단순 기술 스택 나열을 넘어, 문제 해결 과정과 의사 결정의 근거를 드러내는 포트폴리오는 자연스럽게 ‘전문가’라는 수식어 없이도 채용 담당자를 설득할 수 있다.
결국 개발자의 가치는 특정 라이브러리를 얼마나 오래 썼는가가 아니라, 문제를 정의하고 해결책을 설계하며 협업을 이끌어내는 종합적인 능력에서 나온다. React 전문가라는 수식어는 미래의 기술 변화를 담보하지 못하며, 오히려 지원자의 성장 가능성을 제한적으로 보이게 할 수 있다. 이력서와 포트폴리오는 자신의 현재 모습과 미래의 가능성을 동시에 보여주는 창이다. 기술 스택의 나열을 넘어 학습 과정과 문제 해결 과정을 담아낼 때, 채용 담당자는 그 안에서 진정한 전문가의 면모를 발견하게 될 것이다.