이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 팀 내 프론트엔드 개발을 혼자 담당했습니다. React와 TypeScript로 서비스를 구성했고, 백엔드는 팀원이 맡아서 API 연동 방식을 직접 설계하고 합의했습니다. 처음에 컴포넌트를 기능별로 나누지 않고 페이지 단위로만 짰다가, 기능이 늘어나면서 코드가 뒤엉키는 문제를 겪었습니다. 중간에 공통 컴포넌트를 분리하고 상태 관리를 Zustand로 정리했는데, 리팩토링에 이틀 가까이 걸렸습니다. 그 이후론 기능 추가 속도가 눈에 띄게 빨라졌고, 팀원이 UI 버그를 제보할 때도 원인 파악이 훨씬 빨라졌습니다. 최종 발표에서 로딩 속도 개선을 지표로 보여줬는데, 이미지 lazy loading과 코드 스플리팅 적용 후 초기 렌더링 시간이 2.8초에서 1.2초로 줄었습니다. 설계 실수를 직접 고쳐본 경험이 지금 코드 구조를 먼저 생각하는 습관으로 남아 있습니다.
프론트엔드 개발 경험으로, 서비스 초기 로딩 속도가 느리다는 피드백을 받고 성능 병목을 직접 찾아 개선한 것이 기억에 남습니다. 서비스가 커지면서 번들 크기가 늘어났고, 사용자가 처음 페이지를 열 때 느리다는 것이 수치로도 확인됐습니다. 프론트엔드 주도 경험으로는 Chrome DevTools와 Lighthouse를 활용해 어느 리소스가 로딩을 막는지 먼저 파악했습니다. 이미지 최적화, 불필요한 라이브러리 제거, 코드 스플리팅 도입 순서로 개선 작업을 진행했습니다. 성능 최적화 결과로는 First Contentful Paint 기준으로 약 40% 단축됐고, Lighthouse 성능 점수가 유의미하게 올랐습니다. 협업 방식으로는 백엔드 팀과 CDN 캐싱 전략도 함께 논의해서 프론트엔드 단독 최적화보다 더 큰 효과를 얻었습니다.
프론트엔드 성능은 코드 품질이 아니라 사용자 경험에 직접 연결되는 지표라는 것을 그 경험으로 확인했습니다.
프론트엔드 개발 경험으로, 팀 내에 통일된 코드 컨벤션과 컴포넌트 구조가 없어서 프로젝트마다 스타일이 다른 문제를 직접 해결한 것이 기억에 남습니다. 팀원이 늘어나면서 코드 리뷰에서 같은 이슈가 반복됐고, 기준이 필요하다는 공감이 생겼습니다. 프론트엔드 주도 경험으로는 ESLint·Prettier 설정을 팀 공통으로 정리하고, 자주 쓰이는 공통 컴포넌트를 패턴화해서 문서화했습니다. 팀원들이 참고할 수 있도록 스타일 가이드를 짧게 정리해서 공유했습니다. 기술 표준화 결과로는 코드 리뷰에서 스타일 관련 코멘트가 크게 줄었고, 새로운 팀원이 합류했을 때 적응 속도도 빨라졌습니다. 협업 방식으로는 강제로 적용하기보다 팀원의 의견을 받아 수정하는 방식으로 진행했고, 그것이 실제 사용률을 높이는 데 중요했습니다.
기술 표준은 만드는 것보다 팀이 자연스럽게 쓰게 만드는 것이 더 어렵다는 것을 그 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.