FE 개발자 면접 준비 (1)

이번 글에서는 최근 면접 대비를 위해 준비했던 예상 질문과 실제 답변을 공유하려고 합니다. 특히 라이프오아시스 지원을 염두에 두고, 제 경험과 생각을 최대한 구체적으로 담았습니다. 사용자 경험(UX) 개선부터 협업 방식, 기술적 난관 해결, 상태관리 도구 선택, 갈등 해결, 그리고 향후 비전까지 폭넓게 다루었으니, 프론트엔드 개발 면접을 준비하는 분들께도 도움이 되길 바랍니다.

예상 질문 및 답변

Q: 라이프오아시스는 사용자 경험을 중요하게 생각하는데, UX 개선을 위해 어떤 접근 방식을 사용하시나요?

A: 네 저는 사용자 중심 프로젝트 그리고 프로젝트를 구현하기 위하여서 가장 많이 사용했던 방법은 바로 사용자들과의 만남이었습니다. 이제 인터뷰를 통하여 보다 한 분 한 분마다 실질적인 사용자의 경험을 물어보는 기회들도 많이 있었고 또한 구글폼이나 아니면 여러가지 설문조사를 진행하여서 다양한 사람들과 연령층 그리고 성별에 대해 사용자들의 경험을 묻는 식으로 조사를 많이 진행하였습니다. 예를 들어 저는 Q-Lapo라는 Lapo 형성과 관계 발전을 도와주는 서비스를 참여한 적이 있었는데요. 해당 서비스에서는 정말 사람들이 Lapo 형성에 있어서 어떠한 어려움을 겪고 있을지에 대한 의문점 그리고 문제 정의를 찾기 위한 가설 검증이라는 과정이 필요했습니다. 그 과정 속에서 저는 구글폼 그리고 인터뷰라는 두 가지 수단을 활용하여서 사용자들이 실제로 겪고 있는 문제점이 어떠한 것인지를 판별하고 또한 이 문제점을 정말 사람들이 정말로 겪고 있는지에 대해서 신청적인 인터뷰를 진행함으로써 사람들이 정말 겪는 문제점을 가지고 IT 서비스를 기획하고 더 구체화 시키려고 했던 경험이 있습니다.

Q: React나 React Native를 활용할 때 협업과 컴포넌트 구조 설계에서 중점적으로 고려하는 점은 무엇인가요?

A: 저는 두 가지 상황으로 나누어진다고 생각합니다. 먼저 타 직군과의 협업 시에는 커뮤니케이션이 있어서 가장 중요하다고 생각합니다. 특히나 각자 직군에 있어서 중요시 생각하는 부분들, 그리고 우리 하나의 팀이 하나의 프로덕트가 추구하고 있는 방향성을 같이 논하고 이 부분에 대해서 언라인하고 있는 부분이 가장 중요하다고 생각합니다. 그렇기 때문에 타 직군과의 협업 속에서는 소통이 제일 중요하다고 생각을 하고 저는 이 소통을 붙잡기 위하여 비동계 커뮤니케이션을 비롯한 여러 가지 연락순환과 상황 공유 등 문서화에도 더 집중하고 있습니다. 또한 같은 개발자, 직군에 있는 사람들과 협업을 할 때 가장 중요한 점은 프로젝트에 대한 개발 프로세스에 대해서 서로 언라인을 하는 부분이라고 생각합니다. 특히나 프로젝트에 대한 컴포넌트 구조나 아키텍스 설기 등의 부분에 있어서 가장 중요하다고 생각하는 부분은 바로 제가 생각했을 때 가장 중요한 점은 이 프로덕트를 구성하기 위한 최선의 구조를 잡는 부분이라고 생각합니다. 사실 제가 엄청나게 많은 경험을 가진 것은 아니지만, 저는 재사용 가능한 컴포넌트를 만들기 위하여 이 부분을 두고 문서화와 설계에 집중했던 경험이 있습니다. 예를 들어서 재사용 가능한 컴포넌트 같은 경우에는 어떤 부분, 예를 들어서 버튼이나 이미지라든지 정말 많이 사용되는 부분들을 구조화시키고 분리시켜서 재사용 가능한 컴포넌트 개발을 고려했던 경험이 있어 이 부분이 가장 고려된다고 생각합니다.

Q: 입사 후 프론트엔드 개발자로서 팀에 어떤 기여를 하고, 어떤 목표를 이루고 싶으신가요?

A: 사실 저는 개발에 있어서 엄청나게 큰 영향을 가진 사람은 아니라고 생각합니다. 다만 제가 가지고 있는 부분은 보다 좋은 협업을 하기 위한 여러 영향을 가지고 있다고 생각합니다. 특히나 저는 다양한 직군과 함께 모여서 협업하는 것을 즐겨하며, 또한 동일한 직군 내에서는 보다 효율적인 그리고 더 나은 개발 문화를 자리잡기 위하여 이 부분에 대해서 고려하는 것이 저의 큰 영향이라고 생각합니다. 저는 라이프오아시스에 입사 후 가장 이루고 싶은 목표는 정말 라이프오아시스에 가장 녹아들 수 있는 개발자 그리고 구성원이 되고 싶다는 것입니다. 라이프오아시스에서 사용자 중심적인 문제를 가장 크게 고려하는 목표와 비전을 저 또한 크고 달게 받아서 어떻게 보면 저의 향후 목표인 정말 사용자 중심적인 개발을 할 수 있는 그런 개발자가 되기 위하여 여러가지 프로덕트를 접하고 함께 스킬들을 성장해 나가는 과정 속에서 더 이바지하고 싶다는 목표가 있습니다. 감사합니다.

Q: 이전 프로젝트에서 기술적 난관을 겪은 사례와 해결 방법은 무엇인가요?

A: 저는 1년 정도 자바스크립트와 리액트라는 라이브러리를 활용한 웹개발을 진행하였습니다. 하지만 최근 기술 동향을 고려해봤을 때 넥스트JS와 타이프스크립트를 사용하여 개발하는 것이 보다 서버리스라든지 아니면 개발 최적화 부분에 있어서 도움이 된다는 것을 알게 되었습니다. 그래서 저는 이 후킹할 만한 포인트를 가지고 새로운 프로젝트에 접목하여 프로젝트를 진행해보고 싶다는 생각이 들어 넥스트JS와 타이프스크립트를 가지고 프로젝트를 진행하게 되었습니다. 하지만 타이프스크립트 같은 경우에는 타입 분석이라든지 아니면 타입 생성, 인터페이스 생성 등 생각보다 낯설었던 점들이 생각보다 많이 있었습니다. 또한 넥스트JS에 있는 CSR과 SSR 같은 클라이언트와 서버 사이드 렌더링 부분이 저에게는 사실은 좀 어색함과 그리고 큰 어려움으로 다가오기도 했습니다. 하지만 저는 이러한 새로운 것들을 접하고 공부할 때 기술블로거와 같이 무언가를 기록하고 무언가를 참고하는 영향을 갖고 있습니다. 그래서 저는 마주하면서 겪었던 여러 어려움들과 또한 더 성장하기 위하여 참고할 만한 자료들을 많이 찾아보고 이 찾아본 자료들을 바탕으로 저의 언어로, 저의 방식대로 기술블로거에 기록을 남김으로써 제가 부족했던, 제가 처음 낯설었던 부분들에 대해서 난관을 하나씩 잘 이겨냈던 경험이 있습니다.

Q: 상태 관리나 퍼포먼스 최적화를 위해 주로 사용하는 도구와 이유는 무엇인가요?

A: 제가 지금까지 경험해보았던 상태관리 패키지 같은 경우에는 Context API와 그리고 Recoil, 사실 두 가지 상태관리를 사용해보았습니다. 이 상태관리라는 부분에 있어서 정말 몸소 체감해볼 만한 큰 프로젝트에 대한 경험은 없지만 그래도 Pagination과 또한 Context가 유지되는 부분에 있어서 고려하기 위하여 저는 그 두 가지 패키지를 경험해보았는데요. Context API 같은 경우에는 전역적으로 상태관리를 할 수 있다는 점에서 Recoil과 비슷하지만 저는 조금 더 세부적인 그리고 조금 더 자잘자잘한 상태관리를 더욱 사용하고 싶었습니다. 그래서 저는 Recoil에 있는 Atom과 Select를 두 가지를 병합하여 사용하는 방식이 프로젝트에 있어서 보다 세부적인, 조금 더 세밀한 상태관리를 할 수 있다고 생각하게 되어서 이 부분을 고려하여 프로젝트를 진행하였고요. 상태관리를 비롯하여서 프로젝트를 진행하는 부분에 있어서 죄송합니다. 여기까지입니다.

Q: 협업 중 갈등이 발생한 경험과 해결 방법은 무엇인가요?

A: 제가 가장 기억에 남는 팀 프로젝트 내에서의 갈등은 바로 같은 직군과의 협업이었습니다. 저희는 개발해야 하는 페이지 중에서 각자 맡아야 하는 부분들을 나누어서 진행을 한 적이 있었습니다. 그 중에서 개발을 진행하고 이 부분에 대해서 병합하는 과정 속에서 충돌되는 부분들이 상당히 많았습니다. 이 부분에 대해서 저희끼리 사전에 커밋컨벤션과 그리고 PR을 날렸을 때 머지않은 부분에 대해서 논의를 하고 함께 온라인을 진행을 하였지만 사실상 리드 개발자가 개입해야 하는 부분들이 생각했던 것보다 그 이상으로 있었습니다. 그래서 의사 결정을 해야 하는 부분이라든지 아니면 병합 시 컴플릭트가 발생했을 때 이 부분을 어떻게 해결할지에 대해서 그 부분에 대한 가이드라인 혹은 예방 대비책이 없었던 상황이었습니다. 그 결과 저희는 이 상황 속에서 최종 머지 관리자라는 부분을 세워서 리드 개발자가 해당 코드 리뷰에 대한 간단한 코멘트를 남기고 이 부분에 있어서 팀원들과 함께 코드 리뷰를 하는 과정을 통하여 정말 우리 서비스를 구현하는 과정 속에서 해당 방식이 우리가 추구하고자 하는 개발 방식과 맞는지를 고려하여 이 부분을 협업으로 도출했던 적이 있습니다. 저는 이를 통하여서 같은 직구 내에서 발생할 수 있는 부분에 대해서 어려움들 속에서는 충분히 소통과 그리고 함께 온라인 할 수 있는 부분은 같이 맞추고 이 부분을 지켜나가면서 개발하는 것이 중요한 부분이라는 것을 크게 배울 수 있었습니다.

Q: 개발자로서 보완해야 할 약점이나 개선하고 싶은 부분은 무엇인가요?

A: 제가 더 성장해야 할 역량은 바로 개발 방식에 대한 학습이라고 생각합니다. 사실 저는 애자일 방식에 어울리는 적합한 개발 방식을 사용해왔습니다. 그래서 저는 보다 작은 기능들을 빠르게 구현하고 빠르게 완성시키는 개발 학습을 진행해왔는데 그 결과 MVP 완성과 혹은 주어진 시간 안에 완성을 해야 하다 보니 더 효과적인 아키텍트 설계와 더욱 효과적인 컴포넌트 설계 등 부족한 점들이 많다는 것을 배우게 되었습니다. 이러한 부분은 새로운 프로젝트를 많이 경험하는 것보다는 리팩토링과 혹은 리엔지니어링 과정을 통하여 기존의 서비스를 분석하고 이렇게 하면 기존의 코드와 기존의 설계를 더욱 개선시킬 수 있는지에 대해서 고민하는 과정이 필요하다고 생각합니다. 저는 이러한 부분을 더 보완하여서 단순히 완성과 배포할 수 있는 부분에 대해서 고려하는 것이 아닌 앞으로의 유지 보수성과 다른 사람들과 협업 없이 더 고려할 수 있는 부분을 고민해보면서 개발하는 것이 저에게 더욱 채우고 마주해야 할 부분이라고 생각합니다.

Q: 마감 기한이 촉박할 때 예상치 못한 문제가 발생하면 어떻게 대응하나요?

A: 저는 가장 먼저 가져야 할 자세는 바로 팀원 모두와의 공유라고 생각합니다. 사실 시간이 다가올수록 정말 그 데드라인이 임박할수록 당황하고 그리고 그러한 부분을 빨리 해결하고 싶은 마음에 할 수 있다라는 생각만 갖고 부담감을 짊어진 적이 있었습니다. 그 결과 결국에 공유되지 않았던 점들로 인하여 팀원들과의 사기저하나 혹은 프로젝트 완성도를 조금 낮추는 결과를 마주하곤 했습니다. 저는 팀원들과 가장 이 부분을 공유하고 앞으로 어떠한 부분, 어떠한 점들까지 개선하고 혹은 구현할 수 있을지 조치할 수 있는지에 대해서 논의하는 것이 팀원 그리고 프로젝트 완성에 있어서 제일 차선책이라고 생각합니다. 앞으로 저는 이러한 부분에 대한 상황을 고려했을 때도 지금까지 가져온 자세처럼 상황을 보다 빠르게 공유하고 앞으로의 방법에 대해서 논의하고 이 부분을 유지할 수 있는 자세를 라이프워시스에서도 이뤄보고 싶습니다.

Q: 5년 후 프론트엔드 개발자로서의 목표와 현재 노력은 무엇인가요?

A: 저는 5년 후에 보다 기록을 넘어서 기록을 실질적으로 사람들한테 공유할 수 있는 사람이 되고 싶습니다. 저는 현재 기술 블로그를 작성함으로써 제가 개발을 하면서 겪었던 어려움과 기본 지식들을 기록하는 습관을 가지고 있습니다. 이 부분은 저와 같이 쥬니어 개발자 혹은 개발자를 희망하는 사람들에게 가장 쉽게 가질 수 있는 첫 단계라고 생각합니다. 그러면서 제가 정보 공유와 같이 기존의 시니어분들이나 아니면 5년차, 10년차 분들이 경험하셨던 바들을 정리하고 이 부분을 가지고 실질적으로 프로젝트에 경험해보았던 적이 사실 저는 큰 효과를 거두고 여러 도움을 받았던 적이 있습니다. 이러한 경험을 저는 5년 후 정말 개발자를 꿈꾸는 사람들 혹은 쥬니어 개발자분들에게 제 경험을 실질적으로 사람들한테 세션을 통해서 공유하거나 아니면 이러한 자리를 마련하여서 사람들과 함께 성장해 나갈 수 있는 뭔가 페이퍼로드 할 수 있는 그런 개발자가 되는 것이 저는 5년 후 제가 꿈꾸는 개발자의 모습입니다. 감사합니다.

피드백

광일님의 답변 전반을 보면, 실제 경험을 구체적으로 풀어내는 능력이 뛰어납니다. 특히 사용자 경험 개선과 관련해서는 단순한 기술 이야기가 아니라, 인터뷰·설문조사·가설 검증 같은 구체적인 접근 방식을 사례와 함께 설명해 주셔서 설득력이 컸습니다. 협업 부분에서도 타 직군과의 소통, 개발자 간 구조 설계 등 협업 포인트를 명확히 구분해 준 점이 좋았고, 재사용 가능한 컴포넌트 설계 경험을 언급하며 실무 이해도를 드러낸 부분도 인상적이었습니다.

다만, 답변 흐름에서 결론이 뒤에 나오는 경우가 많아, 면접에서는 핵심을 먼저 던지고 뒤에 구체적인 사례를 붙이는 구조로 하면 더 깔끔하게 들릴 것 같습니다. 예를 들어 “저는 사용자 리서치 기반으로 UX를 개선합니다”라고 먼저 말한 뒤, Q-Lapo 프로젝트 이야기를 덧붙이는 식입니다.

또한, 각 경험에서 ‘어떤 변화를 만들었는지’에 대한 성과 부분이 조금 더 보강되면 좋겠습니다. 예를 들어 갈등 해결 경험에서는 프로세스 개선 이야기가 잘 나왔지만, 그로 인해 코드 품질이 얼마나 안정화됐는지나 일정 지연이 얼마나 줄었는지를 간단히 언급하면 완성도가 올라갑니다. 기술적 난관 해결에서도 배운 점을 한 문장으로 명확히 정리해 주면 인상에 오래 남습니다.

입사 후 목표와 5년 후 비전은 회사의 비전과 잘 연결되어 있지만, 목표 달성을 위한 구체적 계획과 단계별 실행 방안이 조금 더 명확하면 좋겠습니다. 예를 들어 “입사 6개월 내 상태관리 구조를 표준화하겠다”처럼 시기·성과를 제시하면 실현 가능성이 더 크게 느껴집니다.

종합적으로, 광일님은 사례 중심의 설득력 있는 답변을 할 수 있는 강점이 뚜렷합니다. 다만 면접에서는 결론부터 말하는 구조, 성과 지표 제시, 그리고 목표의 구체성을 조금 더 보강하면, 지금보다 훨씬 더 전문적이고 신뢰감 있는 인상을 줄 수 있을 것입니다.

질문 하나하나를 준비하면서 제 경험을 다시 돌아보고, 단순한 기술 구현을 넘어 ‘왜’와 ‘어떻게’를 설명하는 것이 얼마나 중요한지 깨달을 수 있었습니다. 면접에서는 결론을 먼저 말하고 사례를 덧붙이는 구조, 그리고 성과나 변화 지표를 함께 제시하는 것이 설득력을 높여준다는 점도 다시 확인했습니다.

이 글이 비슷한 직무를 준비하는 분들께 실질적인 참고 자료가 되었으면 합니다. 앞으로도 경험과 배움을 기록하고 공유하는 개발자가 되겠습니다.