채용 우대사항에 있는 기술을 써도 회사에 떨어지는 이유

F-Lab : 상위 1% 개발자들의 멘토링

2023-11-05

“커머스에서 재고 처리를 하며 분산락으로 동시성 이슈 처리”

“MSA와 카프카를 적용하여 백엔드 아키텍처 구축”

“헥사고날 아키텍처를 구축하여 컴포넌트별 느슨한 결합 구현”

“nGrinder로 대용량 트래픽 처리에 대한 테스트 진행”

“모노레포와 디자인 시스템 구축으로 생산성 향상”

“Jetpack Compose와 MVVM 패턴으로 어플리케이션 구현”

정말 멋있고 트렌디하고 잘하는 개발자처럼 보이게 되는 마법의 용어들입니다.

하지만 과연 이 사람들과 면접을 보았던 면접관들도 그렇게 생각할까요?

안녕하세요. 개발자 커리어 향상을 위한 상위 1% 개발자들의 멘토링, F-Lab 대표 멘토 Fitz 입니다.

요새 취업/이직을 하시는 분들께 매일같이 듣는 이야기가 “서류에서 자꾸 떨어진다”, “겨우 면접 갔더니 면접에서 자꾸 떨어진다” 입니다.

그 중에서도 “큰 기업에서 원하는 기술스택 다 공부해놨는데 왜 자꾸 떨어지는거냐”라고 어려움을 호소하시는 분들의 비중도 꽤 높습니다.

이런 어려움을 호소하는 분들께 해당 기술에 대한 질문을 해서 답변을 들어보면 떨어질만한 요소들이 많이 보였습니다. 그래서 비슷한 고민을 하시는 분이 어떤 특징을 갖고 있었는지, “멋있어보이기만 하는 기술"만 학습하는 것이 왜 탈락을 자초하는지 이 글에서 설명합니다.

<code class="language-plaintext">[목차]

- 최신 기술을 써봐도 좋은 평가를 못 받는 경우
- 이 기술 쓰면 채용에 우대해준다면서요..
- 내 작은 선택에도 크게 바뀌는 회사의 비용
- 이력서, 면접 컨설팅을 받아도 떨어지는 경우
- 이를 극복하기 위한 방법들

뭔가 이상한데요..? 🤔

와.. 최상단에 보여드린 스펙을 보여드린 면접자들은 참 멋진 스펙을 갖고 있습니다.

“분산 락”을 사용했다니 정말 멋집니다.. 이런 멋있는 이름을 가진 기술을 사용하는 현직자가 얼마나 있을까요..?

하지만 질문을 한번 드려보겠습니다.

“분산 락의 단점”은 무엇인가요?
“분산 락” 이 현대 아키텍처에서 병목이 될만한 지점은 뭐가 있을까요?
그럼 지금 구현하신 부분에서 분산락을 썼을 때 무엇을 얻었고, 무엇을 잃으셨나요? 잃는 것들을 감안하면서까지 어떤 점 때문에 그것을 선택하셨나요?

이 질문은 위에서 언급한 모든 부분에서 연결되는 부분입니다.

헥사고날 아키텍처의 단점은 무엇인가요?
nGrinder로 성능테스트는 했는데 그래서 무슨 문제를 어떻게 발견했고, 어떻게 해결했나요?
모노레포를 사용하면 단점은 무엇인가요?

항상 기술을 사용하면 얻는 것이 있는 반면, 잃는 것도 있습니다.

하지만 취준을 하시는 분들에게 이 부분에 대해 질문을 하면 대부분 답변을 하지 못합니다.

내가 겪고있는 문제를 해결하기 위해 기술을 활용한 것일까요?
아니면 그냥 회사에 잘보이려고 그냥 있어보이는 기술을 쓴 것일까요?

이러한 사람이 회사에 입사하면 어떻게 일할까요?

기술에 매몰되어 실용적인 부분은 등한시하고 일단 “멋있으니까”, “최신기술이니까” 라는 생각에 그 기술을 어떻게든 사용하려고 할까요?
우리의 요구사항에 맞춰 최적의 솔루션을 낼까요?

개발자는 왜 개발을 하는건지, 왜 최신 기술이 계속 나오는 것인지, 레거시는 꼭 나쁜 것인지 고민해보시는게 좋습니다.

사용해 본 사람.. 뽑는다면서요..?

항상 신입분들이 갖는 억울함은 이런 것인 것 같습니다.

“지원공고 보니 너희들이 이런 것 사용해 본 사람 우대한다면서..?”

그럼 반대로 회사에서는 이렇게 생각할 수 있을 것 같습니다.

“이 분은 기술을 대할 때 사용하는 것이 전부인가..?”

큰 규모의 IT회사의 채용 공고의 지원자격이나 우대사항을 보면 이런 트렌디한 기술들이 적혀있는 경우가 많습니다. 그리고 그 공고를 보는 많은 개발자들은 이 것을 채용의 척도로 받아들입니다.

그리고 자신이 “트렌디한 기술을 잘 사용한다”를 입증하려고 많은 사이드 프로젝트도 하시고 이론 학습도 하십니다.

하지만 이런 우대사항은 “기본적인 개발 역량”이 뒷받침 됨을 전제로 합니다.

당연한 이야기이지만 트렌디한 기술을 사용해보면 우대사항에 충족이 됩니다. 하지만 충족이 되었음에도 기본적인 개발 역량을 갖춘 사람과 아닌 사람의 채용시 퍼포먼스는 하늘과 땅 차이입니다.

기본기가 탄탄한 사람은 트렌디한 기술을 왜 쓰는지 추론이 가능하기에 자신이 하는 일의 의미를 깊게 알고 진행할 수 있어 더 효율적으로 일을 할 수 있는 반면, 기본기가 부족한 사람은 “이럴 땐 이렇게 한다”라는 패턴만 암기해서 사용하기 때문에 더 좋은 방식이 있음에도 불구하고 외운대로만 일합니다.

면접관은 “우대사항을 충족한다” 를 채용의 척도로 삼는 것이 아닌 “이 사람을 뽑았을 때 우리 회사의 기술 스택에 잘 적응하고 퍼포먼스를 잘 낼 수 있겠다” 를 척도로 삼습니다.

당연하지만 기업에 잘 보이기 위해 기술만 사용해본 사람은 후자의 기준을 충족시키기 어렵다고 판단할 수 밖에 없습니다. 특히 대기업이 아닌 회사 같은 경우는 “빅테크 가려고 최신 기술을 어떻게든 쓰려고 하는 사람” 을 달가워하지 않을 것입니다. 모두가 가고 싶어하는 테크 기업에 지원할 때에도 마찬가지로 팀의 목표를 달성하기보단 “자신의 욕심 때문에 잘못된 의사결정을 일부러 내렸던 사람”은 달가워하지 않을 것입니다.

내 작은 선택에도 크게 좌지우지되는 비용들

왜 이리 많은 것들을 고려하고 고민해야 할까요?

그 이유는 내 작은 코드 하나하나, 기술 선택 하나하나에 큰 비용이 왔다갔다할 수 있기 때문입니다.

기업의 규모가 커질수록 선택에 대한 비용 또한 점점 커지게 됩니다.

규모가 작은 회사에서도 마찬가지입니다. 한정된 자원으로 최대한의 결과물을 만들어내야하기에 개발자는 항상 어려운 책임을 지고 있습니다. 혹한기에도 개발자가 연봉이 높은 직군인 이유가 그런 이유 때문이기도 합니다.

엔지니어링에 대한 지식이 적어 코드의 유지보수성이 떨어진다면 우리는 의도치 않게 회사의 유지보수 비용을 높입니다. 특히 규모가 커질 수록 이 비용은 점점 커집니다. 만약 가독성이 떨어져서 다른 개발자가 코드를 파악하는 시간이 1시간에서 2시간으로 늘어나면 어떻게 될까요?

네카라쿠배 같이 개발자가 수백명 되는 조직에서 일한다고 가정했을 때 그들의 시급으로 한번 계산해보셔도 좋을 것 같습니다. 평균 7000만원이라고 가정하고, 시급으로 계산해서 200명을 곱해보세요. 이것은 작은 소스코드 레벨을 예로 든 것 뿐이고 점점 소스코드가 늘어날 수록 얼마나 커지는지 생각해보시면 대략적으로 왜 유지보수성 좋은 코드를 작성해야하는지 알 수 있으실겁니다.

성능이 떨어지는 것도 마찬가지입니다. 작은 서비스에서 오버 엔지니어링을 하여 쿠버네티스 인프라와 MSA를 도입하면 서버비가 얼마나 늘어나게 될지 계산해보면 됩니다. 성능이 2배 높아지면 필요한 컴퓨팅 파워 또한 절반으로 줄어들기에 서버 유지비는 절반으로 줄어든다고 볼 수 있습니다. (물론 실제론 이렇게 칼같이 바뀌진 않지만요.)

빅테크에서 또한 새로운 기술 하나를 도입하는데에 인프라 비용이 얼마나 들어가는지 계산해보시면 됩니다. 개발자들 몇 명이 몇 시간 동안 들어가는지, 그 시급은 얼마일지, 유지보수하는 비용은 얼마일지 계산해보시면 기술 선택 하나만으로도 어느 정도의 임팩트가 있는지 나올겁니다.

이력서, 면접 컨설팅까지도 받았는데 떨어져요.

요새 사실상 좋은 회사에 지원하기 전에 이력서나 면접 태도에 대해 컨설팅을 받고 지원하는 것이 트렌드로 자리잡힌 것 같습니다.

하지만 이력서, 면접은 현재까지의 모든 것들을 “정리”하는 것이지 소설을 잘 써서 점수를 따는 “입시”가 아닙니다. 애초에 내가 개발을 잘하지 않으면 개발 문화가 좋은 회사에 합격할 수 없습니다. 즉 위에서 말씀드린 것처럼 멋있어보이는 기술을 써보고, 컨설팅을 받아 이에 대한 포장을 잘 해서 간다는 것은 어려운 일입니다.

미래에 내 사수가 될 면접관은 나보다 훨씬 개발을 많이하고 깊게 한 사람일텐데 내가 포장한 것을 알지 못할까요? 오히려 이걸 찾아내지 못한다면 그런 사람을 사수로 믿고 내 미래를 맡길 수 있을까요?

상향 이직이 아니라 계속 수평 이직을 하는 이유는 내가 경력을 쌓는 동안 평소에 “의도적인 수련”을 하지 않았기 때문입니다. 사수가 없더라도 성장할 수 있습니다. 다만 그 방법을 모르는 것일 뿐입니다.

내 개발 실력의 부재가 큰 원인이며, “개발 실력이 없으면 포장을 하더라도 한계가 있을 수 밖에 없다” 가 결론입니다.

물론 면접관의 검증 능력이 부족하다면 컨설팅 받은 면접 방식으로 입사도 가능할 수도 있습니다. 하지만 점점 더 좋은 회사에 지원할 수록 이 방법은 먹히지 않을 겁니다.

이력서 피드백은 쓸모가 없는 것인가요?

전혀 아닙니다. 아무리 실력이 좋아도 어필을 잘 못하시는 분들이 계십니다.

세일즈 또한 역량의 영역 중 하나이기에 이를 보완하기 위해 내 결과물을 잘 정리하고 어필하는 법을 피드백 받는 것은 정말 중요합니다.

하지만 많은 사람들이 이력서를 “정리”의 개념으로 보지 않고, 취업이나 이직을 할 때 이력서에 모든 것을 의존하려하는 것이 문제입니다.

내 경험은 평소에 쌓아놓되, 그것을 정리하는 것을 돕는 역할은 꼭 필요하며 이력서 피드백은 정말 필요한 교육 중에 하나입니다. (교육의 목적이 아니라 대신 써주거나 첨삭해주는 것은 당장 도움이 될 순 있지만 장기적으로 세일즈 능력을 기르는데엔 크게 도움이 되지 않을 수 있습니다)

평소에 기본기를 학습해야합니다.

많은 개발자 분들이 잘하시는 분들과 자신을 비교하며 절망하시는 모습을 자주 보았습니다.

하지만 이는 정말 잘못된 행동입니다. 왜냐면 “남의 결과”와 “자신의 과정”을 비교하고 있기 때문입니다.

잘하시는 분들은 어떻게든 개발에 투자한 시간이 깁니다. 케이스 바이 케이스가 정말 많기에 모두 설명하긴 어렵지만, 어떤 분들은 중학생때 게임을 너무 좋아해서 게임용 컴퓨터를 조립하는 과정을 통해 컴퓨터에 대한 이해도가 높아졌을 수도 있고요. 어떤 분은 코딩을 너무 좋아해서 하루종일 뭔가를 뚝딱뚝딱 만드느라 하루에 남들의 2배가 넘는 시간을 코딩에 쏟았을 수도 있습니다.

경력이 실력에 비례하지 않는다라는 것은 맞지만, 의식적이던 무의식적이던 이렇게 절대적인 시간을 투자한 것은 실력에 반영이 될 수 밖에 없습니다.

이 글을 보시는 대상자 분들도 이러한 감정을 느낀적이 있으실 것 같은데요, 다른 사람의 결과와 내 과정을 비교하지 않으시면 좋겠습니다. 여러분들은 성장하는 단계이고 꾸준함을 통해 충분히 시간을 투자하면 성장할 수 있습니다.

방법도 함께 알려드리자면 내가 사용하는 언어, 프레임워크 혹은 더 나아가서 컴퓨터에 대한 이해도를 높여야 합니다.

객체지향과 데이터 정합성에 대한 이해도와 같은 기본기가 있어야 MSA를 더 잘할 수 있습니다. 또한 MSA가 꼭 필요한지, 필요없는지 또한 판단할 수 있습니다. 모노레포를 하기 전에는 패키지 매니저와 모듈 의존성 등에 대한 이해도를 높여야합니다.

트렌디한 기술은 기본기를 바탕으로 탄생합니다. 멘티들에게 자주 하는 이야기가 있습니다.

“자바 병렬 프로그래밍” 이라는 책은 2008년에 출판되었습니다. 이 곳에서는 Blocking / Non-Blocking에 대한 이야기가 나오는데요, Webflux가 들어있는 Spring5는 2017년에 릴리즈 되었습니다. 아직 국내에 완전 대중적으로 자리잡히지도 않았고요.

만약 2008년에 이 책을 읽었다면 10년 이상의 기간동안 우려먹을 수 있는 정말 가성비 좋은 지식이 될 것입니다.

이처럼 트렌디한 기술은 자주 바뀌는 반면, 기본기는 잘 바뀌지 않습니다.

처음 학습하기가 귀찮고 어려울 뿐, 개발자 커리어에서는 가성비가 매우 좋은 학습입니다. 기본기는 꼭 평소에 꾸준히 하셔야합니다.

하루에 30분씩 학습하는 습관을 들여놓는다는 가정 하에 (30분 * 365일 * 5년)을 해보세요. 엄청난 양을 학습하실 수 있으실겁니다. 꾸준함은 엄청난 차이를 만들어내며 경력에 비례하는 실력을 만들어드릴겁니다.

얕게 해도 됩니다.

이 글을 전반적으로 읽었을 때 “트렌디한 것 하지말고 기본기나 열심히 해라” 라고 들릴 수도 있습니다. 하지만 그런 의도로 작성한 글이 아닙니다.

트렌드를 파악하고 이해하고 있는 것 또한 개발자의 덕목이기에 사이드 프로젝트를 하면서 꾸준히 새로운 트렌드를 파악하는 것도 정말 중요합니다.

사이드 프로젝트를 할 때 깊게 해야한다는 부담 때문에 시작 자체를 못하는 경우가 많은데 그러한 부담은 갖지 않으셔도 됩니다. 얕게라도 자유롭게 적용해보세요. 기본기 학습과 병행한다면 이해도 또한 점점 깊어질겁니다.

하지만 면접에서 “잘했다”라는 뉘앙스로 어필하시면 안됩니다. “개발에 관심이 있어서 다양한 기술 써보는 것을 좋아하는데 그 일환이다” 라는 식으로 말하시는게 낫습니다. 실제로 그러셨을거고요.

중요한 것은 “회사에 어필하기 위해 트렌디한 기술을 써보는 것은 티가 날 수 밖에 없다" 라는 것이고, 항상 진심으로 기술에 관심을 갖고 적용해보는 것이 더 진정성있게 성장하는 방법입니다.

주니어인데 시니어가 보기엔 항상 실력이 부족할 수 밖에 없습니다. 그럼에도 자신의 성장 가능성을 어필할 수 있는건 탄탄한 기본기와 더불어 기술에 대한 진정성있는 관심, 그리고 다양한 시도를 해보며 경험을 쌓는 실행력입니다.

그럼 저는 어떻게 해야할까요?

여태까지 드린 내용을 바탕으로 가볍게 정리해보겠습니다.

꾸준히 기본기 학습하기

지금 이 글을 다 읽는 바로 서점 사이트에 들어가 내가 쓰는 언어와 프레임워크에 대한 가장 두꺼운 책, CS 책을 구매하세요.

당장은 읽어도 다 까먹을 수도 있습니다. 하지만 머리 속 어딘가에는 남아있다가 다른 개념을 공부할때 갑자기 튀어나올 겁니다. 막막하셔도 일단 책을 읽으시면서 생각의 재료를 쌓아보세요. 전공자의 힘은 학점을 따기 위해 억지로 CS를 공부하며 쌓인 컴퓨터에 대한 이해도에서 나옵니다.

사이드 프로젝트 하기

꾸준히 새로운 기술을 익히고 사이드 프로젝트에 적용해보세요. 보통 공식 웹사이트의 튜토리얼을 보면 기본적인 개념과 사용법을 알 수 있습니다. 그것을 봄과 동시에 샘플코드도 같이 검색해보시면서 적용해보세요. (영어로 검색해야 결과가 많이 나옵니다)

기술 편식하지 않기

“나는 백엔드 개발자니까 백엔드로만 프로젝트 해야해” 라는 생각을 하시는 분들이 많지만, 오히려 그렇지 않습니다. 다양한 분야를 경험해야 시야가 넓어지기에 “개발” 자체에 대한 이해도가 높아집니다.

프론트엔드, 백엔드, 딥러닝, 모바일 등 다양한 분야를 얕게라도 공부해서 프로젝트를 해보세요. 모든 분야를 깊게할 순 없습니다. 얕게 하셔도 되니 가볍게라도 해보시고 내 주력 분야를 깊게 하시면 됩니다.

기술을 선택할 땐 항상 사용하는 이유를 고민해보기

특정 기술을 선택하면 어떤 것을 얻게되는지, 어떤 것을 잃게되는지 파악해보며 트레이드오프를 계속 고려해보세요. 현업에서 선택하는게 아니라면 새로운 기술 학습, 트렌드 파악과 같은 것도 선택의 이유가 될 수 있습니다.

잘하는 사람을 찾아 피드백 받기

사람은 사람으로 성장합니다. 결국 여러분들이 가고 싶어하는 “배울 수 있는 회사”도 잘하는 사람이 1명 이상 있기에 “배울 수 있는 회사”라고 불리는 것이고요.

링크드인, 커리어리, 대외동아리, 모각코 모임 등 커뮤니티에는 잘하는 사람들이 정말 많습니다. 이런 곳들을 계속 찾아다니며 잘하는 분들이 올리시는 글도 보고, 궁금한건 질문도 하시고 커피타임도 요청해서 피드백도 받아보시면서 외부의 시선에서 피드백을 많이 받아보세요. 회사를 많이 지원하고 면접을 많이 보는 것도 내가 무엇을 모르는지 피드백을 받을 수 있는 방법 중 하나입니다.

커피타임의 경우엔 거절당할 확률이 높지만 거절을 두려워하지 마세요. 거절 당해도 손해보는 것은 없습니다.

(나중에 이런 문화가 확산되어서 열정있는 주니어들 뿐 아니라 준비성 없는 주니어들까지도 커피타임 요청하는 빈도가 높아지면 시니어 개발자들도 이런 커피타임에 대한 거부감이 높아질 수 있으니 그런 정서가 확산되기 전에 미리 시도해보세요)