지원했던 이유

얼어붙은 취업 시장에서 신입에게 요구하는 능력이 높아진 만큼 나에게도 준비의 시간이 필요하다고 느껴졌다. 나름 꾸준히 공부 해왔다고 생각하지만 돌이켜보면 막상 나 “이런거 했어요”, “이런 경험을 해봤어요”, “이런 프로젝트 해봤어요” 어필 할만한게 아직 부족하다고 판단했다. 그래서 작년에는 우테코를 지원해봤지만 탈락을 했었고, 그 이후 캡스톤이라는 나름 규모있는 프로젝트를 해서 많이 성장을 했었다. 뭐 개발적인것 이외에도 리더로써 어떻게 팀을 이끌고 최우수상이라는 결과로 이끌기까지 많이 배웠다. 하지만 아직 갈증을 느꼈다. 나는 정말 잘할 잠재력(ㅋㅋ)이 있는데 이걸 잘 보여줄만한 어떤 것이 없을까? 그렇게 찾아보다가 디자이너와 프로그래머가 같이 서비스를 완성시킨다는 디프만이 이런 갈증을 해소 해줄거라고 생각을 했다. 현직자 분들도 꽤 지원을 하시고 코드들도 잠깐 보기 했지만 퀄리티들이 아주 뛰어났기 때문에 이렇게 좋은 동료가 보장되는 디프만과 함께 한다면 너무 좋을 것 같다는 생각에 제출기한 1시간 전까지 서류를 작성하고 제출을 했다.

서류

서류 항목이 꽤 많았다. 너무 맘에 들었다. 역시 사람을 뽑을 때 엄청 신중하게 뽑으려고 하는구나 느꼈다. 내용자체는 작성할때는 무리가 없었다. 만약 1년전에 나라면 작성을 못했거나 내용이 형편이 없었을것 같지만 나름? 많이 성장했기 때문에 금방금방 적었던것 같다. 질문들을 작성하고, 블로그와 깃허브 주소, 그냥 간단하게 작성해두었던 이력서를 같이 링크로 걸어서 제출을 했다.

결과는…

기대 안하고 있다가 합격이라니 기분은 넘 좋았다ㅏ []

면접

가장 큰 문제는 면접이었다. 이유는 면접 경험이 없었다…. 전혀 감을 잡을 수 없었고 나의 살짝 단점이라면 당황하면 말을 잘 못한다는거다. 아는것도 머리가 하애지고 평소라면 설명이 술술 나올것이 그냥 입이 안떨어진다는 것이다… 그래서 준비기간인 1주일동안 정말 하루도 빠짐없이 예상질문 리스트 정리하고 답변 적어보고 공부하고 gpt랑 가상 면접 연습해보고 정말 노력을 많이 했다. 노션에 정리한 것도 면접 전날까지 2시간만 자면서 계속 읽고 연습하고 공부했다.

[] 드디어 2시30분이 되었고 떨리는 맘으로 입장을 했다. 면접관 분은 2명이고 나랑 또 다른 한분이랑 같이 면접을 진행했다. 총 30분정도 면접을 보았고 10분 인성 면접 15분 기술면접 5분 질문정도로 진행되었고, 번가라가면서 질문을 하고 답하는 식이었다.

분위기를 편하게 해주셔서 딱 인성면접까지는 생각보다 긴장은 되지 않았다. (놀랍게도)

그때!! “자 여기까지 인성면접은 마무리하고 기술면접 시작할게요 우선 성재님한테 먼저 질문하겠습니다.” 이 말을 듣는 순간부터 머리가 하애졌다 ㅜㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ 가장 열심히 준비를 했는데

첫번째 질문은 “RabbiMQ를 사용하셨다고 했는데 유실나는 경우 어떻게 해결하나요?”(정확히 기억은 안나는데 요런 느낌이었다) 아 이거 분명히 예상해서 준비했었는데 진짜 딱 DLQ 이거만 기억나고 진짜 기억이 안났다..

다시 한번 답변을 정리해보자

메시지 유실은 RabbitMQ의 각 단계별로 발생할 수 있습니다. 첫번째로 프로듀서에서 브로커로 메시지 보낼때 유실을 막기위해 publisher confirm 기능을 사용, 이를 통해 브로커까지 메시지가 도착했는지 확인할 수 잇고 실패시 재전송 로직을 추가할 수도 있습니다. 두번째로 메시지와 큐의 영속성 설정을 할 수 있습니다. 브로커가 재시작되더라고 메시지가 유지되도록 설계할 수 있습니다. 셋째로 컨슈머 쪽에서 ack를 보내도록 구성합니다. DLX(Exchange) -> DLQ(Queue)를 설정해서 실패한 메시지를 별도 큐로 옮겨 모니터링이나 분석 및 재처리 할 수 있도록 설계할 수 있습니다.

암튼 제대로 답변을 못하고 잘 모르겠다라고 하고 넘어갔다.

그 다음 질문은 “ec2가 읽기권한으로 되어있었다고 했는데 좀 자세히 설명해 주실수 있나요?” 이 질문은 잘 대답했다.

AWS 계정이 개인 계정이 아니라 회사측 계정이라서 권한(role)이 제한이 되어있었습니다. 별도의 ec2를 만들거나 삭제하는 권한이 없어 서버를 배포할 수 없었고 단순히 읽기 권한만 있어 기존에 있었던 ec2를 보는 방법만 있었습니다.

그 다음 질문은 “혹시 캐싱 전략에 대해서 설명해주실 수 있나요?” 아 이 질문은 진짜 대답할 수 있었는데 못했다. 진짜 전날인가 Redis관련 강의 보면서 학습했던 부분인데 전혀 예상하지 못했던 질문이어서 좀 당황을 했고 이미 첫번째 질문 대답을 잘 못하기도 했고, 같이 면접 보는 지원자 분이 너무 말을 잘하시고 대답도 다 하셔서 기세가 많이 꺾여있었다 ㅋㅋㅋㅋㅋ 암튼 다시 답을 작성해보자면

캐싱전략은 정확한 용어는 잘 기억이 안나지만 읽기 작업에 최적화 되어있는 전략과 쓰기 작업에 최적화 되어있는 전략이 있습니다. 읽기 전략에 최적화 되어있는 전략은 우선 사용자가 요청을 하면 먼저 캐시에 해당 요청한 데이터가 있는지 확인하고 없다면 DB를 조회 후 캐시를 재설정 및 결과로 반환을 합니다. 하지만 단점이라면 DB의 데이터와 캐시의 데이터가 다를 수 있다는 점입니다. 따라서 주기적으로 동기화를 시켜주는 것이 필요합니다. 다음은 쓰기 작업에 최적화 되어있는 전략입니다. 캐시를 in-memory DB로 활용하는 방법입니다. 사용자가 데이터를 쓰면 캐시에 저장을 했다가 한번에 DB에 추가하는 방식입니다. 또 다른 방법은 데이터를 DB와 Redis 모두에 저장하는 방법으로 일관성을 유지할 수 있다는 장점이 있고 아까 말했던 읽기에 최적화 되어있는 전략과 같이 사용되는 형태입니다.

그 다음 질문은 “elasticsearch를 사용했다고 하셨는데 어떤건지 설명해주실 수 있나요?” 이 질문은 예상치 못했던 질문이라 많이 당황을 했다. elasticsearch… 알고 보니 이력서에 적혀있던 내용이었다. 사실 elasticsearch를 사용했던 이유도 elasticsearch의 내장 knn 모델이 있어서 임베딩한 데이터들을 추천해주는 기능을 손쉽게 만들 수 있기 때문에 겸사겸사 검색 엔진용으로 별 생각 없이 사용했던 건데 이걸 물어볼 줄이야… 정말 최악의 답변을 했다. 잘 모르고 사용했다… 한번 답을 간단히 작성해본다면

elasticsearch는 대량의 구조화된 데이터와 비정형 데이터를 빠르게 검색하거나 분석할 수 있는 시스템입니다. Lucene 기반으로 동작하며 데이터를 Restful api를 통해 색인하고 검색할 수 있습니다. 데이터를 document 단위로 저장하며, 각각은 json 형식으로 구성되어있습니다. 이 문서들은 index안에 저장되며, 인덱스는 다시 하나 이상의 샤드로 나위어 클러스터 전체에 분산 저장됩니다. 이런 구조 때문에 대량의 데이터를 다루는 환경에서도 빠른 응답속도를 유지할 수 있고 수평 확장에도 용이합니다.

암튼 면접 후기는 그냥 망했다!~ 이다 ㅋㅋㅋㅋ 너무 아쉽긴하다 준비를 많이 했지만 준비한 만큼 다 보여주지 못해서 너무 아쉬웠다. 아무래도 두명이서 같이 진행하다보니 질문 할 수 있는 가지수가 적기도 했고 다른사람의 답변 길이에도 영향이 있었던것 같다. 하지만 좋은 경험을 했다. 비록 비대면 면접이긴 했으나 면접을 준비하면서 내가 어떤 부분이 많이 부족했고, 또 다시 공부를 하면서 얻을 수 있었던 귀중한 시간이었기 때문에 다음에 또 이런 기회가 있다면 더 열심히 잘 준비할 수 있을 것 같다.

(속닥속닥)떨어지겠지만 붙었으면 좋겠다 []