이 글은 개인 기록 목적으로 작성되었으며, 정확하지 않은 부분이 있을 수 있음을
알립니다!
😔 후기
스스로 공부해온 시간과 쌓아온 프로젝트 경험에 대해 진지하게 돌아볼 수 있는
기회였다. 면접은 면접관 2분과 지원자 2명으로 온라인으로 진행되었으며
공통 면접 10분, 기술 면접 20분 내외로 총 1시간동안 이뤄졌다.
나름, 자바 & 스프링과 백엔드 개발자로써 일하기 위해 필요한 CS 지식들을 갖추고
있었다고 생각했으나 막상 면접 질문을 받아보니 명확히 답변할 정도로 공부가 되지
않았다는 인상이 강했다. 또한 CI/CD 구축, 인증/인가와 관련된 경험이 없다보니
해당 키워드와 관련된 상식이 전무하다는 판단이 들었다. 이 실패를 스스로의 위치를
다시 확인하고 목표를 향한 로드맵을 다시 구성해볼 수 있는 기회를 삼으려 한다. 💪
공통 질문
진행하셨던 프로젝트의 커뮤니케이션 방식에 대해 설명해주세요
프로젝트를 기간내에 완수하는 것에 중점을 두되, 팀원들과 활발히 소통하며
생산성을 증진시키는 방향으로 진행하려 노력했다는 점을 어필하려 노력했다.
자소서에 본인의 경험을 바탕으로 프로젝트 진행시 팀원과 어떻게 소통하는지
묻는 문항에 관하여 적재적소의 친밀감과 진중함 이라는 캐치프레이즈를 바탕으로
답변을 하였기 때문에 단순 무식하게 개인 작업에만 몰두하는 스타일이 아닌,
(활발한 소통, 솔직한 피드백) 🔄 생산성 향상 이라는 선순환 구조를 알고 활용할
줄 안다는 부분을 부각시키는 방향으로 답변을 했다.
팀 배치시 학생분들과 개발자가 섞일 경우, 팀원들의 생활 패턴이 달라 소통에
어려움이 있거나, 적극도가 다를 수 있을 텐데 이런 문제 상황 발생시 어떻게
극복할 수 있을지?
프로젝트를 진행하며 노션과 같은 도구를 적극 활용하여 동기, 비동기적 소통을
전부 경험해봤다는 부분을 먼저 말하였다. 앞서 받았던 소통 방식 질문의 연장선으로
비슷한 맥락에서 답변을 드렸던 것 같다.
기술 질문
안전한 메서드란?
서버의 상태를 변하지 않게 하는 메서드를 설명할 때 해당 용어가 등장한다는 식으로
얼버무려 답변을 드렸던 것 같다. 개념을 알고는 있었으나 해당 질문을 면접이 난항을
겪는 도중에 받았다보니 명확히 답변을 하지 못했다.
안전한 메서드
안전한 메서드란 HTTP 요청의 결과로 서버의 어떤 작용도 없음을 의미하며,
GET,HEAD등이 메서드가 안전하다고 볼 수 있다. 안전한 메서드의 목적은
서버에 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는
애플리케이션을 만들 수 있게 하기 위함이다.
PUT과 PATCH의 차이
PUT은 데이터를 온전히 교체할 때 사용되고 PATCH는 부분적으로 수정할 때
사용된다고 답변드렸다.
더불어, 프로젝트에서 데이터를 업데이트하는 API를 다 PUT 이용하여 구성하였는데
왜 그렇게 설계하였는지에 관해서도 질문을 하셔서 데이터를 온전히 교체하는 방식으로
UPDATE를 구현하였기 때문에 PUT을 사용했다고 답변을 드렸던 것 같다.
참고 : PUT과 PATCH의 차이
(RESTful)API 설계에 있어서 가장 중요하게 고려하는 것?
URL에 동사가 들어가면 안되고... 자원을 표현할 수 있는 명사 등으로만 구성되어야
한다는 식으로 답변을 드렸는데 결론적으로 너무 횡설수설하며 답변을 했다.
참고 : RESTful API design
JDBC Template를 사용할 때와 JPA를 사용할 때의 차이
JDBC는 개발자가 쿼리를 문자열 형태로 직접 작성하여야 되고 JPA는 ORM 프레임워크가
쿼리를 알아서 생성해준다는 부분에서 차이가 있다는 점을 말씀드렸다.
JDBC를 사용하면 OOP 적으로 코드를 구성하는 것이 어렵고 중복 코드가 발생할 수 있다는
한계점이 존재하는데 이 부분을 부연하여 말하지 못해 해당 질문에서 감점 요인이 있지
않았나 돌이켜 보면 생각이 든다..
로그인 기능을구현함에 있어 세션을 사용하고, 세션을 단순히 서버의 인메모리에
저장하는 방식을 사용했는데 이런 구조에서 발생할 수 있는 문제점과 그에 대한
해결책은?
프로젝트에서 로그인 기능을 단순히 세션에 사용자가 로그인시 고유한 UID를 부여하여
저장하고, 해당 세션을 서버의 인메모리에 둔 상태로 인가를 수행하는 한계점이 명확한
방식으로 구현하였는데, 아니나 다를까 이 부분과 관련하여 질문이 들어왔다.
서버의 인메모리에 해당 데이터를 저장하기 때문에 사용자 수가 증가할 경우 서버에
부하가 발생하여 서비스 전체가 다운될 리스크가 존재한다는 점을 말씀드렸다.
따라서 해당 한계를 scale-out 방식으로 극복하고 로드 밸런서를 통해 부하를
분산하는 방식으로 해결할 수 있을 것 같다고 답변드렸다.
서버의 인메모리에 세션을 저장하는 구조에서 한 서버에 부하가 집중되는 것을
방지하기 위해 로드밸런서를 사용할 수 있을 것 같다고 말씀해주셨는데, 만약
A라는 서버가 특정 유저의 세션 정보를 저장한 상태에서 해당 유저의 요청을
로드밸런서가 B 서버로 전달할 경우 문제가 발생할 수 있지 않는지? 이런
문제는 어떻게 해결할 수 있을지?
앞선 질문의 꼬리 질문으로 들어왔다. 인증/인가와 관련된 공부가 아예 전무하다 보니
로드밸런서를 내부적으로 커스텀하여 특정 요청이 특정 서버로만 갈 수 있게 조정하는
방식으로 해결할 수 있을 것 같다고 말씀드렸다. (정말 말도 안되는 답변이었다..)
git-flow란 무엇인지?
feature, hotfix 등으로 작업 분류별로 브랜치를
세분화하여 협업을 용이하게 하는 브랜치 전략의 한 종류라고 답변드렸다.
github-flow와 git-flow의 차이가 무엇인지?
github-flow가 git-flow에 비해 사용되는 브랜치의 종류가 훨씬 단순화되어
있다고 미약하게 답변드렸다.
참고 : 브랜치 전략의 차이
