이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
새 기술을 익힐 때 직접 작은 프로젝트를 만들어보는 것이 먼저라고 생각합니다. 문서만 읽으면 이해한 것 같지만 실제 코드를 짜면 빠진 부분이 바로 드러납니다. 팀 공유는 배운 내용을 설명하기 위해 한 번 더 정리하는 과정이라 개인 학습에도 도움이 됩니다. 인턴십에서 GraphQL을 도입하면서 15분짜리 테크톡을 진행했는데, "REST와 뭐가 다른가"라는 질문에 제대로 답하려다 보니 차이점이 훨씬 명확하게 정리됐습니다. 공유 후에는 팀원들이 직접 써보고 싶다는 피드백을 주면서 같이 탐색하는 분위기가 만들어졌습니다. 기술 공유는 내가 잘 알아서 가르치는 게 아니라 함께 배워가는 과정이라고 봅니다.
새 기술을 익히고 나서 팀 위키에 초안을 먼저 올리는 방식을 스스로 정했습니다. 발표 자료를 만드는 건 부담이 크지만, 읽으면서 정리한 내용을 그대로 노트로 공유하면 학습과 공유가 한 번에 됩니다. 캡스톤 프로젝트에서 Next.js App Router를 처음 도입했을 때, 팀원 3명에게 설명할 시간을 따로 잡기 어려워서 "배운 순서대로 쓴 입문 노트"를 Notion에 올렸습니다. 처음엔 틀린 부분이 있어서 팀원이 코멘트로 수정해줬는데, 그 과정에서 제가 놓쳤던 개념이 자연스럽게 채워졌습니다. 최종적으로는 팀원 2명이 그 문서를 참고해 독립적으로 서버 컴포넌트를 구현했고, 저는 피드백으로 문서 정확도가 높아졌다는 걸 확인했습니다. 완성된 문서보다 함께 고치는 초안이 더 오래 쓰인다는 걸 그때 알았습니다.
팀 내에서 격주로 30분짜리 기술 스터디를 직접 열어본 적이 있습니다. 매번 발표자를 정하는 방식은 부담이 컸고, 돌아가면서 한 주제씩 코드 예시를 들고 오는 방식으로 바꿨더니 참여 분위기가 달라졌습니다. 학부 동아리에서 React를 팀 전체에 처음 도입하는 과제를 맡았을 때, 4주에 걸쳐 스터디를 진행했습니다. 참여한 팀원 5명 중 3명이 실제 프로젝트 PR에서 배운 훅 패턴을 직접 사용했는데, 저는 코드 리뷰를 통해 이걸 하나씩 확인했습니다. 처음엔 참여율 같은 숫자가 의미 없다고 생각했는데, 코드에 얼마나 녹아드는지를 추적하니 다음 스터디 주제도 더 잘 고를 수 있었습니다. 공유의 성과는 PR 리뷰 수로 재는 게 가장 실용적이라고 지금도 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.