내가 6년차 직장인에 접어 들었을 무렵, 다니는 회사를 나와 이직을 결심하게 되었다. 물론 이 회사를 오래 다닌 건 아니지만, 직장 생활이 길어지면서 내가 어떤 회사를 좋아하고 선호하는지 점점 알게 되었고 지금의 회사도 좋지만, 조금 더 나에게 맞는 회사로 이직하고 싶은 생각이 들었다.

내가 원하는 건 빡세고 내가 만드는 프로젝트가 어느 세계(오타쿠의 세계, 와인의 세계, 등)에서 유명했으면 했다. 이 세 가지를 충족하는 회사는 많지 않아 찾는데 힘들었고, 우연치 않게 내 기준에 충족하여 타겟으로 잡은 회사는 저명한 회사였다.

회사 탐색

회사를 탐색하는 일은 어렵지 않았다. 다양한 경로로 회사들은 항시 개발자를 채용하고 있었고, 나 또한 몇 번의 쉬운 검색으로 회사를 찾을 수 있었다. 내가 활용한 서비스는 아래와 같다.

로켓펀치
유명한 사이트 로켓펀치, 다양한 회사(특히 스타트업)가 채용하는 걸 확인할 수 있다.

잡플래닛
회사 면접 질문 및 난이도를 돈 내고 열람할 수 있다. 물론 나도 참고는 했는데 도움이 되진 않았다.

회사 채용 사이트
평소 관심있던 회사 채용 사이트를 방문해서 직접 신청을 넣었다.

Vue를 사용하는 메이저 회사는 거의 없었으며, 대다수가 React를 선호했다.

이력서 기획

이력서를 작성하기 위해 기획을 진행했다. 기획은 크게 ‘어떤 사람이 볼 건지’, ‘어떤 생각을 갖도록 방향성을 정할 건지’ 두 가지를 중심으로 생각했다.

첫 번째로, ‘어떤 사람이 볼 건지’에 대해서 기획 했을 때 타겟이 두 분류로 되어있었다.

  • 회사 전체가 보는 이력서를 작성할 건가?
  • 회사 내의 지원할 직군 팀원이 보는 이력서를 작성할 건가?

회사 전체가 보는 이력서를 작성하는 건 내가 해당 분야에 대해 뾰족한 점이 없거나, 회사가 소규모일 때 적합하다. 이와 같은 상황은 내가 2년전 게임 업계에서 서비스 업계로 처음 진입할 때 접했다. 하지만 지금은 2년의 시간동안 프론트엔드 쪽에서 일을 해왔고, 공부를 했으니 괜찮은 상황이라고 생각하여 두 번째 안을 고르게 되었다.

두 번째로, ‘회사 내에 지원할 직군 팀원들이 보는 이력서를 기준’으로, ‘해당 팀원들이 어떤 생각을 갖도록 전개할 건지’에 대한 물음은 이미 정해져 있었다. 내 이력서를 보면서 해당 개발자가 ‘같이 한번 일해보고 싶다’ 혹은 ‘관심이 있다’를 느끼게 하고 싶었고, 조금 더 전문 영역으로 들어가면 ‘사용자 중심으로 생각하는 개발자’, ‘애니메이션을 적극 사용하여 사용자가 피로를 덜 느끼게 하는’과 같은 사용자 중심 흐름을 선호하는 개발자임을 생각하게 하고 싶었다.

  • 회사 내의 지원할 직군 팀원이 보는 이력서를 작성
  • 사용자 중심, 애니메이션을 적극 사용하는 프론트엔드 개발자
  • 한번쯤 같이 일하고 싶은, 열정, 관심이 있는

이력서 작성

나의 이력서

이력서 작성을 할 때 필수적인 규칙을 몇 가지 정했다.

  • 웹으로 개발해서 퍼블리싱한다.
  • 한 눈에 내 기술 스택을 확인할 수 있어야 한다.
  • 디자인은 심플하게, 최대한 타이포그래피를 활용

규칙을 정했으니, 이력서 흐름을 생각하여 목차를 작성했다.

  1. 첫 인사
  2. 관심사
  3. 기술 스택
  4. 경력
  5. 대외활동
  6. 강연
  7. 수상

내가 면접관이 되었다고 가정하고 구상했다. 구상해보니 경력을 보고, 기술 스택을 유추하는 행위는 매우 비효율적이라고 생각했다. 그래서 관심사와 기술 스택을 먼저 서술하여 인지한 상태에서 경력을 읽는게 효과적이라 판단하여 배치를 관심사 - 기술 스택 - 경력으로 진행했다.

그 외에 대외 활동, 강연, 수상은 관심사와 경력을 뒷받침 해줄 수 있다고 생각했기 때문에 뒷 부분에 추가했다.

기술 스택

기술을 서술할 때의 순서는 웹 프론트엔드 개발자 기준으로 작성했다.

  1. HTML/CSS
  2. JavaScript
  3. SPA Framework (vue, react)
  4. Server
  5. DevOps (Web을 Deploy 하기 위함)
  6. 그 외 (git 등..)

‘프론트엔드 개발자가 원하는 기술이 무엇일까’를 곰곰이 고민해봤다. 개발자를 뽑을 때 React, Vue와 같은 Web Framework를 다루는 능력도 중요하지만, 다양한 상황에 대해 대응하기 위해서 기본 지식이 중요하다고 생각했다. 또한 여러 기업들이 React와 Vue 같은 Web Framework를 많이 사용하고 있지만 그럼에도 불구하고 jQuery나 Vanilla JavaScript 같은 코드는 많이 존재하고 지금도 코딩이 되고 있다. 그래서 HTML/CSS, JavaScript와 같은 기본기를 앞에 배치했다.

기본기 다음으로 SPA Framework를 배치했다. 읽으면서 ‘튼튼한 기본기로 SPA Framework들을 다룰 줄 안다!’으로 자연스럽게 읽혀지길 바라는 생각이었다. 하지만 생각보다 강조가 많이 되지 않은 것 같다. 모노한 전개여서 그런지, 다음 이력서를 제작할 때 핵심 기술을 강조하는 부분을 추가해야 하겠다는 생각이 들었다.

최근, Front-end 개발자는 Server 지식도 충분히 갖고 있어야 된다고 생각한다. 하나의 웹 서비스를 구성하는 요소 가운데 서버는 당연히 빠질 수 없는 요소이며, 이는 SEO, SSR와 같은 유저가 웹을 마주하게 되는 시작점에 대한 중요한 개발을 포함하는 영역이다. 또, 완벽한 서버 구현은 힘들겠지만 프로토타입용으로 웹을 만들 때 잠시 사용되는 역할의 조그마한 서버는 만들 수 있어야한다. 이러한 필요성에 따라, ‘앞에서 웹 개발을 잘할 수 있다’에서 ‘웹 개발 후 웹 배포 및 서버 개발도 할 수 있다’로 좀 더 다듬어 주는 흐름을 구성했다.

DevOps를 구축하면 귀찮은 일을 자동화하여 개발 속도를 향상 시키는데 큰 도움을 준다. 특히나 웹 배포 시나리오는 반복적인 작업을 하는 일종의 노동이다. 자동화를 하지 않으면, AWS console 접속 → ip 확인 → ip에 해당하는 서버 접속 → 서버에서 git fetch → git checkout upstream → pm2 restart 와 같은 반복적인 작업을 하게 된다. 이러한 작업을 크게 덜어주면 작업 효율이 많이 상승하므로 이러한 작업을 할 줄 아는 웹 개발자인 것을 마지막으로 어필했다.

경력

경력은 최근 경력부터 정렬을 했다. 글만 있으니 읽는 사람이 집중하기 힘들다는 생각이 들어 프로젝트마다 Preview를 배치했다. 프로젝트마다 기간, 짧은 설명, 기술 스택, 핵심 작업을 명세했다. 특히 작업에 해당하는 영역은 어떤 효과를 얻었는지 기술을 적용한 이유와 그 기술을 통해 회사의 프로젝트가 어떤 긍정적 영향을 얻었는지 상세하게 적었다. 개발자가 기술을 선택하는 궁극적인 목표는 ‘협업을 위해’, ‘편한 개발을 위해’ 와 같은 팀 시너지를 올려서 회사의 사업이 훌륭하게 돌아가도록 하는 것이니까.

이력서 제출

이력서를 제출 할 때, “회사의 응답이 일주일 내로 오지 않는다면 다음 회사를 넣도록 하자” 라는 규칙을 정하고 움직였다. 이렇게 규칙을 잡은 까닭에 대해 이야기 해보면,

  • 일주일동안 메일을 보지 않는 회사라면 흠..
  • 일주일은 나에게 매우 긴 시간이다.

그래서 규칙을 생각하며 3개의 회사에 지원했다.

  • 토스
  • 라프텔
  • 카카오

토스

토스는 나에게 너무나 매력적인 회사이다. 디자인부터 애니메이션까지 새로운 서비스가 추가될 때마다 항상 내 안에서 큰 인상을 남기고 있었다. 이는 토스 카드 페이지에서 절정을 꽃 피웠는데, 작년부터 토스에 지원해서 한번 일해보고 싶다는 생각이 토스 카드 페이지에서 절정을 맞이했고 그래서 이번 기회에 토스에 이력서를 넣었다. 하지만, 토스는 일주일 간 나에게 연락이 오지 않았다. 그래서 일주일이 넘어가던 때, 다른 회사에 이력서를 넣으면서 토스 리크루트 페이스북 페이지에 메시지를 보냈다. 메시지를 보내자마자 2일 안에 서류 합격했다는 메일이 왔다.

토스 지원하고 아직도 깊게 인상이 남았던 건. 전형을 합격할 때마다 리쿠르트 매니저님께 전화가 오면서 항상 친절하게 응대 해주셨던게 기억에 남는다. 그러면서 토스라는 회사에 꼭 합격하고 싶다는 생각이 들었고 이러한 응대가 중요하구나 라는 생각이 절로 들었다.

라프텔

라프텔은 애니메이션 스트리밍 서비스를 운영하는 회사이다. 몇 년전 부터 애니메이션을 볼 때 사용하던, 관심있게 보던 서비스였다. 로켓펀치를 둘러보던차, 익숙한 라프텔의 아이콘이 보여서 덜컥 지원하게 되었다. 처음에는 로켓펀치를 맹신할 수 없어 회사 홈페이지에서 지원서를 보냈으나 라프텔도 마찬가지로 일주일간 연락이 없어서 로켓펀치로 다시 지원하게 됐다. 로켓펀치로 지원하고 3일정도 지나자 서류 합격했다는 통보가 메일에 있었다.

카카오

카카오는 누구나 알만큼 큰 대기업이다. (중견기업으로 분류되어 있지만 영향력이나 그룹의 크기로 보면 대기업같다.) 주변 카카오를 다니는 지인이 말하는 카카오는 개발자에게 천국같은 곳이었고, 탄력적이고 수평적인 문화가 존재하는 훌륭한 곳이었다. 마침 카카오의 공고 중 프론트엔드 개발자를 구인한다는 공고가 올라와 있어서 지원을 했고, 3일 안에 서류 전형을 합격했다는 연락이 왔다.

세 곳의 서류 전형을 합격한 만큼, 이력서 준비를 빡세게 한 보람이 있었다.

코드 테스트

그런데, 여기서 일이 일어난다. 토스와 라프텔, 카카오를 일주일 단위로 지원을 했으나, 연락이 온 시기는 비슷한 시기였고, 해당 시기에 코드 테스트를 몰아서 보는 현상이 발생했다. 그래서 일주일 동안 세 곳의 코드 테스트를 하느라 잠을 거의 자지 못했다.

라프텔

첫 코드 테스트는 라프텔이었다. 라프텔의 코드 테스트는 정한 날짜, 시간으로부터 48시간 동안 해당 과제를 완성해야했다. 그래서 토요일 주말에 날잡고 코딩테스트를 보았다. 첫 코드 테스트를 보는 것이다 보니, “잘 짜야지~” 하는 마음가짐이 오버하게 만들었고, 간단한 코드 테스트에 프레임워크가 되어버리는 일이 발생했다. (…) 실제로 만들기위해서 48시간의 40시간은 코딩했다. 41시간 정도 될 무렵, 과제를 제출했고 며칠 후 라프텔에서 코드 테스트를 합격했다는 메일이 날라왔다.

카카오

쉴 틈 없이 카카오 코드 테스트 메일이 날라왔고, 조금 휴식을 취한 후 수요일 점심부터 저녁 전까지 카카오 코드 테스트를 봤다. 카카오 코드 테스트의 문제 설명은 전부 영어로 되어 있었고, 영어를 해석 못하는 사람을 일차적으로 거르겠구나 라는 생각을 했다. 코드 테스트는 약 5시간 정도 보았고 마지막 과제에서 코드를 짜는데 막히는 부분이 있어 해당 부분에서 시간을 많이 썻으나, 과제는 다 만들어서 제출했다. 며칠 후, 카카오도 코드 테스트를 합격했다는 메일이 날라왔다.

토스

수요일날 카카오 코드 테스트를 보고, 며칠 후인 토요일날 토스 코드 테스트를 봤다. 토스도 마찬가지로 제한시간동안 개발하는 과제였다. 토스도 40시간 정도 코딩해서 보냈다. 보낼 때가 일요일이었는데, 일주일간 거의 잠도 못자고 작업만 하는 바람에 힘들어서 뻗어버렸다. 며칠 후, 토스에서 코드 테스트에 합격했다는 메일이 날라왔다.

이렇게 코드 테스트를 보면서 계속 성장했던 거 같다. 혼자 헤커톤을 세 탕 뛰는 느낌이었고 확실히 웹 프레임워크를 다루는 실력이 점점 늘어나는 걸 느꼈다. 그런데, 다음번에 지원할 때는 2주 간격으로 지원해야겠다는 생각이 들었다. 타이트하게 코드 테스트를 준비하니 심적으로 압박도 되었고 적어도 휴식을 위해 일주일이라는 텀은 있어야 할 거 같았다.

기술 면접 준비

기술 면접을 준비하기 위해서 노션에 질문을 정리했다.

기술 면접 준비는 회사에 서류와 코드 테스트에 합격하고 나서 준비하지 않았다. 그 이유는 코드 테스트를 합격하고 기술 면접을 보는 시간이 매우 짧을 걸 예상하고 있었고, 웹 개발자로 전향하고 어느정도 시간이 흐르지 않아서 기본적인 웹 개발 질문을 할거라 생각했다. 그렇기에 많은 시간이 필요하다 느껴, 두 달 전부터 시작했다.

두 달 동안 많은 걸 공부하고 부족한 점을 보완해서 글을 작성했다. 모르는 부분이 있으면 근처 지인에게 물어보기도 하고, 나름 준비를 열심히 했다는 생각에 고양되어 있었다.

기술 면접

결론만 말하면 라프텔과 토스 둘 다 면접에서 떨어졌고, 카카오는 내가 면접을 캔슬했다.

라프텔 면접

라프텔 면접에서 인상 깊었던 점은 상세한 코드 피드백과 ‘어떻게 합리적인 생각을 하는가’ 두 가지가 기억에 많이 남는다. 처음 회사에 들어와서 면접을 기다리는 동안, ‘어떻게 합리적인 생각을 하는가’에 대한 질문을 하나 면접관님이 던지셨다. 던지신 그 질문은 내가 여태까지 마주했던 질문의 유형과 전혀 다른 처음 보는 유형의 질문이었다. (나중에 찾아보니 컨설턴트 면접 시 많이 물어보는 질문의 유형이라고 한다) 기다리면서 곰곰이 질문에 대한 답을 생각해봤다. 질문에 들어가서 생각한 대답을 드렸고, 면접관님께서는 질문에 대한 피드백과 이 질문의 의도를 이야기 해주셨다. 그 후 면접이 시작되면서 상세하게 내가 짠 코드를 리뷰 해주셨고, 대다수의 질문은 React 관련 질문이었고, 부가적으로 기본적인 알고리즘 능력 라이브코딩 테스트를 봤다.

면접 질문을 보면서 “준비를 열심히 하셨구나” 생각이 들 정도의 퀄리티 있는 면접이라고 느꼇다. 하지만 떨어짐을 직감했고 면접을 진행하면서 React 관련 질문과 라이브 코딩에서 내 자신도 용납하지 못할 정도로 많은 부분을 답변을 못했으며 라이브 코딩도 재대로 풀지 못했다.

면접이 끝나고 React 개발자를 뽑는데 React 관련 지식을 공부하지 않았던 게 가장 큰 패착이라 생각했다. 라이브 코딩을 할 거라는 생각을 전혀 못해서 당황 하다가 제대로 못 본 것도 한 몫 했던 것 같다.

라이브 코딩을 보면서 안절부절하는 나를 보셨는지, 면접관님께서 “이런 상황에서는 당황할 수 있으니 먼저 키보드에서 손을 때고 머리속에서 정리를 한 후에 코딩을 하는게 좋을 것 같다” 라는 말을 하셨다. 지금 생각해보면 훌륭한 피드백이라 생각한다. 라프텔 면접을 보고 지금까지 약 1달이라는 시간 동안 생각을 정리하고 코딩에 들어가는 훈련을 통해 성장했음을 느낀다. 라프텔 면접에서 많은 걸 경험했다.

라프텔 면접에서 느낀 점

  • 다양한 질문에 대한 생각을 하게 됨 (한정된 시야에서 조금 트인 느낌)
  • 해당 직군에 대한 기술을 많이 물어보니 당연히 해당 기술을 공부해야 한다, React 개발자라고 한다면 React 기본 지식 정도는 알고 가야 한다.
  • 먼저 키보드에 손이 가서 코딩하는 게 별로 좋지 못하다. 생각을 정리하고 코드를 작성해보자.
  • 기본적인 웹 개발 지식은 스킵하고, React와 같은 실무 지식을 많이 물어본다.

토스 면접

토스 면접일짜를 잡기까지 너무나 친절한 리크루터의 응대가 좋았다. 서류테스트, 코딩테스트, 면접일짜 확정까지의 일련의 일을 깔끔하게 처리해주셨고, 이런 경험은 카카오나 네이버 같은 대기업보다 훨씬 좋았던 기억이다. 토스에서 말하는 ‘인재 유치는 스피드전’ 이라는게 무엇인지 감이 확 왔다.

토스 면접은 세 분의 면접관이 들어오셨고 저녁 7시 30분쯤부터 시작했다. 처음은 코딩 테스트의 코드 리뷰로 시작했다. 면접을 보시는 개발자분들이 내 코드를 여러모로 많이 보셨다는 걸 느꼈다. 그 중에 몇 가지를 꼽는다면

  • 왜 상태를 Store가 아니라 container에 명세하셨나요?
  • 아이템 데이터를 가져올 때 전체를 다 갖고오시네요? 왜 id로 가져오지 않았나요?
  • 변수명을 왜 저렇게 지으셨나요?
  • Atomic Design에서 template을 어떤 용도로 사용하셨나요? 왜 vue에서는 Atomic Design 적용이 어려울까요?
  • 왜 TypeScript 적용을 안하셨나요?

설계의 미숙함이나 API 데이터포맷까지 확인했다는 점에서 얼마나 신중하게 뽑는지를 알 수 있었고, 코드 리뷰가 어느정도 끝나고 라이브 코딩으로 넘어갔다.

라이브 코딩은 자료구조 관련해서 알고 있는가를 검증 하려는 것 같아보이는 문제였다. 라이브 코딩이 끝나고 대략 1시간 30분 정도 시간이 지나있었다.

토스 면접에서 느낀 점

  • 코드 리뷰를 높은 수준으로 받았다. 회사의 코드리뷰 문화를 엿볼 수 있었고 내부적으로 빡세게 진행한다고 느꼇다.
  • 모든 코드에는 논리가 있어야 함을 느꼈다. 내가 조금 놓친 부분에 대해서 이야기를 듣길 원했다.
  • TypeScript를 적용했다면 더 높은 피드백을 받을 수 있을 것 같았다. 내부적으로 TypeScript를 적극적으로 사용함을 느꼈다.
  • 토스도 라이브코딩 테스트를 보았는데 라이브코딩 하면서 당황하는 것 좀 고쳐야겠다.
  • 전반적으로 빡센 인터뷰였다.

카카오 면접 진행 취소

라프텔과 토스 면접을 보면서 나에게 무엇이 부족할까 곰곰이 고민했다. 그래서 알고리즘이 문제인가?를 생각하고 있었다. 그러던 중, 카카오 면접 후기를 보았는데 카카오는 2차 면접에서 매우 빡세게 알고리즘을 질문한다고 했다. 그러면서 2차 면접에 떨어지면 1년간 지원을 못한다는 이야기가 문득 기억나서 원격 인터뷰 단계에서 취소한다고 카카오에 메일로 전달했다.

알고리즘을 조금 더 확실하게 공부하고 지원 해야겠다는 생각과 함께 면접 진행을 취소했고, 전반적으로 나에게 부족한 기술을 조금 더 공부하기로 했다.

면접 그 후

다양한 회사 면접의 경험은 나에게 큰 양분이 되었고, 부족한 점을 정리하게 되었다.

React.js + TypeScript

React.js를 메인스택으로 가져오기 위해 회사 메인 프로젝트와 사이드 프로젝트 그리고 리뉴얼 할 이력서 페이지를 React로 변경했다. 하루 10시간 이상을 React코드와 마주했으며 다양한 환경에 대해 구축을 해보고 나름대로 장점과 단점을 구별해봤다.

웹을 개발할 때 모든 환경에서 TypeScript를 적극적으로 활용하였다.

라이브코딩

알고리즘 및 라이브코딩에 익숙해지기 위해서 알고리즘 학원을 다니기 시작했다.

하지만 다닌지 약 한달이 되는 시간 동안, 나에게 알고리즘은 문제가 아니라는 걸 판단했다. 그 이유는 내가 문제를 푸는 속도나 알고리즘 답안을 내는 걸 보면 괜찮은 수준이라는 걸 확인했기 때문이다.

그래서 라이브코딩은 경험을 좀 더 많이 쌓는게 옳바르다고 생각했다.

끝으로

아직 이직의 꿈을 꾸고있다. 나와 최고로 맞는 회사를 찾기 위해서 정처없이 여행을 하는 중이고 머지않아 찾을 수 있을거라는 생각이 든다.