2년차 주니어 개발자의 이직 이야기 3 - 면접에 관하여(시리즈C 스타트업 후기)

배경

밀린 일들을 처리하고 이제서야 적극적인 구직활동을 시작하려던 차에 전혀 생각하지 못한 루트를 통해 시리즈C 스타트업으로부터 면접 제의를 받았다. 이력서를 업데이트한 지 좀 오래된 플랫폼에서 어떻게 찾았는지 HR에서 직접 열람한 후에 이직 제안 레터를 보내왔던 것이다. 포지션 자체가 3년 이상 경력을 요구하기에 내 경력 필터에 걸려서 이전에 전혀 본 적 없는 기업이었으나, 회사에 대해 조금 알아본 후에 어쩌면 정말 좋은 성장의 기회가 될 수도 있다는 생각이 들어 고민 끝에 면접을 다녀오게 되었다. 면접 팁이나 후기를 다루는 글들을 정말 많이 읽어보았고, 나름대로 필요한 내용들을 열심히 준비해갔다. 그러나 면접은 내가 예상했던 것과 전혀 다르게 흘러갔고, 이 경험이 기억에 남아 이 글을 남기게 되었다.

시리즈C 스타트업 분위기

첫인상

스타트업치고는 굉장히 보수적인 문화를 가진 기업이라는 인상을 받았다. 너무나 조용한 오피스 분위기에 움직이는 사람이라고는 회의를 위해 이동하는 사람들뿐이여서 그랬을까? 초기 스타트업들이 모여있는 오피스에서 일해본 경험이 있는 나로서는 약간 숨막히는 느낌이였다. 나중에 면접관들과 대화를 하며 이 기업에 대해 조금 더 알아갈 시간을 갖게 되었는데 알면 알 수록 대기업의 축소판같다는 생각을 하게 되었다.

 

개발방법론

들은 바에 의하면 아무래도 업력이 약 7년 이상 된 회사이기에 시스템과 프로세스가 안정되어있는 편에 속했고, 보수적인 문화를 가지고 있었다. 개발 방법론이 워터폴이였는데 업데이트를 일주일 단위로 하다보니 야간, 주말 상관없이 크런치모드로 쉴틈없이 계속 몰아부치는 방식으로 업무를 수행한다고 했다. 기획이나 설계를 위한 회의에 많은 시간을 할애하는 편이고, 회의를 통해 결정된 사항들에 대해 탑다운으로 업무를 받아 자기주도적으로 일정 산정 후 개발을 해야하는 방식인 것 같았다.

 

인재상

내가 인력충원의 이유를 질문했을 때 면접관들로부터 답변을 들으며 받았던 인상은 결국 부품처럼 크런치모드로 불만없이 함께 달려줄 인력을 찾는다는 것이였다. 물론 나름의 여러가지 이유가 덧붙여지거나 부드러운 방식으로 설명되었지만 마지막에 받은 인상은 그랬다. 그게 꼭 나쁘다는 건 아니고, 대기업 출신들이 많은데다가 보수적인 도메인에서 사업을 벌이는 곳이기에 그런 방식으로 일하는 사람들이 모이는게 성과내기에는 좋을 수도 있겠다는 생각은 들었다. 하지만 내가 생각했던 스타트업의 분위기와는 동떨어져있는 느낌이였다.

 

개발문화

물론 그만큼 실력있는 사람들이 모여있는 곳이였기에(온 국민이 다 알만한 서비스 런칭 경험이 있는 리더들) 갖출 건 다 갖춘 곳이라는 생각이 들었다. 개발자 출신 대표, 실력 있는 팀 리더들, 사수 문화, 코드 리뷰, 스터디 지원, 고급 장비 지원, 자기계발비 지원 등 성장에 목마른 주니어로서는 너무나 좋아보이는 것들이 한데 다 모여있었다. 또한 직접 겪어본 것은 아니나 동료들의 성품, 실력들이 대체로 좋다는 리뷰들이 많이 있었다. 들어가서 적응만 잘 한다면 성장을 안 할 수 없는 환경이라는 생각이 들었다. 

 

주니어로서의 성장에 대한 이야기를 나누는 과정에서 개발 리더가 성장은 개인의 몫임을 여러 번 강조했던 것이 기억에 남는다. 물론 필요한 여건은 다 지원해주고, 시니어들의 지도를 받을 수 있음을 전제한 말이였다. 개발 리더는 자신이 운영하는 팀에 대한 자부심이 있었고, 이전부터 오랜 기간 함께해온 동료들에 대한 신뢰를 드러내어 안정으로 운영되는 조직임을 어필했다. 여기에 다 적을 수는 없지만 대화 중에 개발 리더의 주관을 엿볼 수 있는 대목이 몇 개 있었는데 이를 보며 나도 이런 리더 밑에서 일해보고 싶다는 생각을 오랜만에 했던 것 같다. 물론 여전히 스타트업 치고는 매우 보수적이라는 인상을 지울 수는 없었다.

---

면접 절차

면접 제안 -> HR 전화 인터뷰 및 전형 안내 -> 면접 일자 확정 -> 실무진 및 개발 리더 면접(1차) -> 대표 면접(2차)

내가 생각했던 면접

면접은 1) 지원자의 이전 경험과 기술적 역량이 충분한지, 2) 함께 일하기에 좋은 사람인지를 실제 대화를 나눠보며 판단하는 과정이라고 생각한다. 기본적으로 면접까지 왔다는 것은 서류를 통해 자질이나 역량이 충분하다고 판단하여 지원자를 실제로 보고 더 자세히 들여다보고 싶다는 의미로 이해된다. 면접을 진행하며 지원자를 알아가는 과정에서 고려되는 요소들은 회사나 면접관마다 달라질 수 있지만 결국에는 위의 두 가지로 좁혀지는게 보통이다. 그래서 나는 공고에 있는 여러 가지 정보들을 취합하여 아래와 같은 내용들을 준비해서 갔다.

내가 면접을 위해 준비했던 것

1. 자기소개: 인사, 이전 업무 경험, 성격, 관심사

2. 기반지식: 기술면접을 위한 언어, CS, 프레임워크 관련 지식

3. 회사정보: 회사의 비전, 문화, 비지니스모델, 수행하게될 업무, 기술스택 등

4. 업무경험: 프로젝트 수행 시 가장 잘 했던 일, 문제 해결 경험, 갈등 해결 경험 등

5. 인성면접: 강점과 약점, 좋은 회사에 대한 가치관, 워라밸에 관한 관점 등

실제로 겪었던 면접

1. 실무진 면접(1시간)

예정된 시각보다 늦게 시작되었다. 10년차 이상의 개발 파트별 리더 2명이 참여하여 2:1 면접을 진행했는데, 면접관들은 내 이력서를 면접장에 들어와서야 읽은 것 같았다. 업무강도가 높은 회사라 바빠서 그럴 수도 있고, 그 정도 경력자면 이력서를 훑어보기만 해도 바로 감이 올테니 내심 그럴 수도 있다고 생각은 했다. 하지만 자기 소개도 없이 바로 '지원자가 수행했던 업무경험을 나열하면 듣다가 연관된 질문을 던지겠다'며 면접을 시작한 건 조금 당황스러웠다. 이후에 이어지는 업무관련 질문들도 대체로 모호하여 질문을 여러 번 했음에도 그 의도를 파악하기 어려워 답변에 난항을 겪었다.

 

기억에 남았던 건 내 이력서에 거의 언급된 적 없는 보안과 인증 처리에 대한 질문들이 뜬금없이 꼬리물기 식으로 진행되었다는 점이다. 나는 그쪽 업무를 내 소관으로 부여받은 적이 없어 답변할 수 없는 내용이 제한적임을 여러 번 이야기했음에도 결국에는 계속 관련 내용으로 돌아돌아 계속 질문을 던졌다. 상황에 따라 세션, 토큰, OAuth를 활용한 기본적인 인증/인가를 처리해본 경험 외에 대용량 트래픽 환경에서의 기업 보안을 처리해본 경험이 없던 나로서는 그다지 답변할 수 있는 내용이 없었다.

 

또 한 가지 특이했던 건, 회사에서 실제로 사용될 것으로 기대되는 기술스택, 아키텍쳐, 방법론 관련 질문은 거의 하지 않았다는 것이다. 최소한 기술 면접에서 기대되는 형태의 기반 지식 점검이나, 특정 기술을 사용한 개발 경험 유무를 묻는 질문자체가 없었다. 딱 하나 있긴 했는데 그것조차도 사실 주 기술스택이 아닌 기술에 대한 꼬리물기 질문으로, 그다지 적절하다고 생각되지는 않았다. 내가 이미 기술면접 관련 내용들을 다 숙지하고 왔다고 판단을 한건지, 아니면 애초에 전혀 면접관들의 관심사가 아니었던 건지는 도무지 알 방법이 없었다.

 

기술적인 부분 이외에 질문이 많이 들어왔던 건, 내 나이와 경력에 관련된 것이였다. 타 분야에서 개발로 전향하며 나이에 비해 부족한 경험을 채우기 위해 어떤 노력들을 하고있는지에 대한 질문들을 직, 간접적으로 두 번 정도 던진 것 같다. 이에 대해 현재 수강하는 온라인 강의, 기술 블로그 운영, 코딩 테스트 문제풀기, 원티드 프리온보딩 챌린지 참여 등의 답변을 내놓았다. 이후의 개발 리더 면접에서도 비슷한 질문들을 좀 더 자세하게 한 것으로 보아 지원자가 얼마나 개발에 진심인지를 알아보려는 의도가 담겨있지 않나 싶었다.

 

결론적으로, 도무지 이 면접관들이 어떤 관점으로 나를 바라보고 있는지가 내 입장에서는 거의 드러나지 않아 내 스탠스를 어떻게 정해야 할지 알 수 없는 면접이였다. 그래도 살면서 경험한 다양한 면접들이 있는데 그 어느 유형에도 속하지 않는, 마치 숭늉같은 느낌이랄까. 이게 만약 일종의 전략이라고 한다면 내 준비가 부족했던 탓일 것이다. 1시간 내내 머리속에 물음표가 가득했던 면접이였지만, 그럼에도 불구하고 면접관들의 내공을 엿볼 수 있는 순간들이 있었다. 또한, 선배가 후배에게 알려주듯 면접관들이 툭툭 던져주었던 주제들이 그 자체로 나에게 도움이 많이 되었다고 생각한다. 그래서 시간이 아깝게 느껴지지는 않았다.

 

2. 개발 리더 면접(1시간)

개발 리더와 인사팀 직원, 총 2명과의 인성 면접 및 컬쳐핏 면접을 진행했다. 가벼운 농담이나 사는 얘기로 시작해서 살아온 배경, 가치관, 일에 대한 관점 등을 편한 분위기 속에서 이야기하며 서로를 알아가고자 했던 것 같다. 면접관들은 최대한 빠짐 없이 회사에 관한 정보를 나에게 제시하고자 노력하였고, 내가 만약 면접을 통과하여 입사하게 되었을 때 어떤 모습으로 일하게 될 지를 그려볼 수 있도록 도왔다. 높은 업무강도를 안내하고 그에 대한 관점을 풀어나가는 방식도 이해하기 쉬워 좋았다. 단순히 '일이 많아서 일을 해내야한다'가 아니라 '이런저런 이유와 이런 철학을 가지고 있어 이렇게 운영되고 있다'는 식으로 설명하여 야근을 위한 야근을 하는 회사는 아니라는 인상을 받았다. 면접관들은 친절했고 편한 마음으로 시간을 보냈던 것 같다.

기억에 남는 면접 내용

Q. 백오피스 개발을 하며 보안이나 인증 관련 처리를 주 업무로 수행해본 경험이 있는지?

A. 세션이나 토큰을 이용한 기본적인 인증을 적용해본 경험 정도는 있다. 프로젝트A(외주)에서는 인증 관련 권한을 가진 본사 팀이 따로 있어 내가 건드리면 안 되는 영역이였고, B에서는 Auth0라는 OAuth 구현 서비스를 적용한 바 있으며, C에서는 기본인증과 유저권한 관련 업무 처리 정도를 수행했다.

 

Q. Auth0를 적용한 프로젝트에서 OAuth를 직접 구현한건지?

A. 당시 우선순위는 기능 명세 및 개발에 있었고 Auth0 서비스를 적용했기에 직접 구현할 이유가 없었다. 

 

Q. 만약 사용자와 관리자 API가 함께 있다면 사용자의 접근 제한을 어떤 방식으로 구현할 것인가?

A. (같은 서버에 있다는 가정 하에) IP 접근 제한이나 유저 레벨 부여를 통해 접근 권한을 다르게 하겠다.

Q. 또 다른 방법은 없겠는가?

A. 잘 모르겠다.

-> 다시 생각해봐도 그 의도를 알기 어려운 질문이었다. 애초에 BO에서는 관리자용 권한을 부여할 것이고, 일반적으로 프로젝트 자체가 분리되어있을텐데 일반 사용자들이 관리자 API의 엔드포인트를 어떻게 알아서 접근하고 사용한다는 걸까? 그런 방식으로 만들어지는 케이스가 있는건가?

-> 서비스별로 서버를 분리하여 관리한다고 답변할까도 고민했는데 애초에 질문 자체가 사용자API와 관리자API가 같이 있다는 걸 전제로 하기에 의미가 없는 것 같아 언급하지 않았다.

 

Q. DB설계를 하여 테이블을 생성해본 경험이 있다면 그 과정을 설명하시오

A. 기획 논의 -> 테이블 설계 및 동료확인 -> 테이블 생성

Q. 좀 더 자세하게 말해달라

A. 맥락을 지정해주면 좋겠다

Q. 외래키나 인덱싱 적용 처럼 테이블 생성 과정에서 했던 일들을 나열해달라

A. 주 키나 외래 키는 당연히 적용했고, 필요에 따라 캐스케이드나 트리거를 설정해본 경험은 있다.

Q. 인덱스는?

A. 읽기가 좀 느리거나 할 때 적용여부를 확인한 적은 있지만 설계 단계에서 직접 적용해본 경험은 없다.

Q. 이전에 DB와 관련된 교육을 들은 경험이 있는가?

A. 학부 DB수업, 국비학원 오라클 DB수업, 코딩테스트 SQL문 풀이 등

Q. 오라클 DB를 공부하며 인덱스를 학습하고 적용해본 경험이 없는가?

A. 개념적으로 인덱스가 있다는 건 알았지만 내 손으로 직접 적용할 일이 없었다.

Q. 그렇다면 수행했던 프로젝트들에도 인덱싱 처리가 되어있지 않다는 건지?

A. 대부분 처리되어있다.

-> 어떤 부분을 보려고 하는 건지 이해가 잘 되지 않았던 질문이다. 기술적인걸 보고싶은 거라면 기술 자체를 집어서 구체적으로 물어보면 될텐데, 질문 내용은 과정에 관한 것이어서 어느 장단에 맞춰 답변을 해야할지 알 수 없었다.

-> 테이블 설계 후 정규화라던지 인덱싱이라던지 좀 더 구체적인 절차를 숙지해야겠다

 

Q. 비동기 처리 경험이 있는지?

A. 프론트 파트에서 비동기 호출을 통한 업무 수행 경험이 있다. 주로 Axios를 통해 REST API를 호출하고 콜백함수를 작성하는 식으로 작업했다. 콜백 뎁스가 너무 깊어지는 걸 방지하기 위해 상황에 따라 async, await 키워드를 활용했다.

Q. 프론트는 리액트로 작업한 것인가?

A. 바닐라와 JQuery로 작업했다.

Q. 프론트를 프레임워크 없이 작업했으면 DOM에 무리가 많이 갔을텐데 성능상의 문제는 없었나?

A. 최대한 필요한 만큼만 부분적으로 갈아끼우는 식으로 구현하려고 했다. 이미 세팅되어 중간에 투입된 프로젝트로 리액트를 뒤늦게 적용할 수 없었다.

Q. 백엔드에서의 비동기처리 경험은 없는가?

A. A라는 서비스에서 컨텐츠 대량 업로드 기능 구현 시, 하나의 API에서 비동기적으로 프레임워크 내의 다른 API를 여러 번 호출하게끔 처리했던 경험은 있다.

Q. 그때 비동기 처리는 어떻게 했는가?

A. 메서드들이 async 함수들로 모듈에 export되어 사용되었는데 이를 비동기적으로 호출하여 사용했다.

Q. 모듈로 export하여 사용했다는게 잘 이해가 되지 않는다.

A. ExpressJS 상에서 비지니스 로직을 담은 메서드들을 export키워드를 사용해 내보내고, 필요할 때 import하여 사용했다는 의미이다.

Q. 아 ExpressJS를 말한 거였나. 혹시 Spring에서는 없는가?

A. 없다.

-> 스프링과 노드는 근본적으로 요청에 대한 처리 방식이 다르다. 스프링을 염두에 두고 질문했던 내용인 것 같은데 대화 흐름상 자연스럽게 노드 기준으로 답변하다보니 핀트가 맞지 않았다. 그것과는 별개로 스프링에서의 비동기 처리, 그리고 WebFlux에 관한 공부가 필요할 것 같다.

 

Q. 비지니스 로직과 SQL문을 개선하여 6초 -> 1초 이하로 성능을 개선했던 경험이 있다고 했는데 어떤 건지 설명해달라

A. 불필요한 중복 호출, 데이터 가공이 들어가있는 비지니스 로직을 개선했다. 또한 SQL문도 불필요한 데이터를 조인해서 가져오게끔 작성되어 있어 이 부분을 개선했다. 

Q. 아무리 그래도 요즘같은 성능에 어떻게 기존에 6초나 걸렸는지 이해가 되지 않는다. 문제가 되는 부분을 자세히 설명해줄 수 있는가?

A. 하나의 상품을 생성하는 과정에서 필수 데이터로 요구되는 카테고리 정보 등의 몇몇 데이터의 정합성을 검증하는 과정에서 이미 검증이 끝난 데이터들을 다시 반복문으로 순회하는 문제가 있었다. 또한 정합성 검증에 필요한 데이터를 가져오는 과정에서 필요한 부분만 호출하지 않고 기존에 다른 용도로 만들어져 더 복잡한쿼리를 사용한 문제가 있었다. 이런 점들을 제거하고 개선하여 호출시간을 단축했다. 다만 전반적으로 로직을 갈아엎는 과정에서 해결된 문제라 한 가지 원인을 집어서 말하기가 어려운 문제라고 생각한다.

Q. 이 문제를 어떻게 감지했는가?

A. 먼저, 눈에 보이는 속도에 문제가 있어 전체 소요 시간을 측정했다. 또한 로그에 남는 쿼리문을 보고 해당 기능이 원래 의도대로 동작하고 있지 않음을 알게되었다.

 

Q. 위와 같은 맥락에서 만약 SQL문과 비즈니스 로직에 문제가 없는 상태에서 API 하나를 호출하는데 시간이 오래 걸린다면, 어떻게 개선하겠는가?

A. 우선 쿼리 개선이 가능한지를 먼저 파악하여 최소한의 데이터만 가져오는 게 맞는지를 파악할 것이다. 또한 너무 복잡한 쿼리가 문제가 된다면 쪼개서 테이블을 호출하는 방식으로 바꿀 것 같다.

Q. 그래도 개선이 안 된다면?

A. API가 하나의 거대한 로직을 수행한다면 그 로직을 분리하여 작은 API들로 만들어서 뒤에서 처리될 때는 순차적으로 처리되지만 프론트에서 보이는 화면에는 진행이 되는 것처럼 보이게끔 처리할 것이다. 

-> DB로 해결되지 않는 문제라면 스케일업이나 스케일아웃을 이야기했어도 괜찮았을 것 같다. 또한 읽기가 많은 테이블이라면 인덱싱 적용을 말할 수도 있었을 듯하다.

---

앞으로 개선할 것들

몇 가지 면접을 보며 보완할 점들을 발견하여 적어본다.

 

1. 이번 면접처럼 문제의 맥락을 먼저 던져주지 않는 경우가 더러 있을 수도 있으므로, 처음부터 전체 그림을 그린 채로 특정한 상황을 설정하여 문제에 대한 답변을 제시할 수 있도록 준비하는 게 좀 더 안전할 것같다.
2. 시니어들과 면접을 볼 경우 단편적인 지식 전달보다는 고민하면서 개발한 흔적을 업무 경험과 함께 적절하게 제시하는 것이 더 중요한 듯하다. 당연한 얘기이나 그들이 확인하고 싶어하는 건 문제해결능력이므로.

3. 실무 관련된 내용은 경험으로만 답변할 수 있는 경우들이 있다. 검색으로 나오는 지식에는 한계가 있다.

4. 한계 극복, 잘한 점 등을 질문 받았을 때에는 웬만하면 기술적인 도전과 해결을 말하는 것이 좋은 것 같다.

5. 마찬가지로 현재 하고 있는 일이나 관심사 등을 물어볼 때에도 가급적 개발 관련 이슈를 답하는 것이 좋다.

6. 깊이 있는 기술 이해도가 필요하다. 얕으면 금방 드러난다.

총평

면접관들이 제시한 질문의 의도가 잘 파악되지 않아 핀트를 맞추기 어려운 면접이였다. 그러나 그것과는 별개로 받았던 질문들로부터 파생되는 여러 가지 아이디어들이 많은 방향을 제시해주었기에 귀한 시간이였다고 생각된다. 또한 내 지식의 얕음도 알게되어 어떤 식으로 공부해나가야 할지 조금 더 감을 잡게되었다. 반대로 생각해보면, 면접관들이 모호하게 질문을 던졌다고 하더라도 내가 더 깊은 지식을 갖고있었더라면 나의 프레임워크에 면접관들을 끌어들일 수도 있었을 것이다. 이렇게 생각하고나니 너무나 해야할 게 많고 또 어디서부터 시작해야 할지 감이 잡히지 않아 막막하다. 그럼에도 남는 의문 한 가지는 이게 정말 나같은 저연차의 주니어에게 적합한 면접 질문들이였냐는 것이다.

면접 결과

불합격(근무일 기준 6일 소요)