2022년 하반기 공채 도전기

또… 늦었네?

안녕하세요, 이번에는 2022년 하반기 공채 도전기를 간단히 써보려 합니다. 벌써 2023년 상반기가 절반이나 지난 후에야 2022년 하반기 도전기를 쓰게 되었네요. 후기를 늦게 작성하게 된 가장 큰 이유는 다름이 아니라, 수습 과정이 3개월 있었기 때문입니다. 그리고 수습 기간동안 회사에 적응하면서, 제가 가지고 있던 생각이 많이 변할 것이라는 생각도 있었구요, 합격 직후에 또는 입사 직후에 후기를 작성하게 되면 마음이 들떠서 안그래도 글을 잘 못쓰는 제가 더 의미 없는 글을 쓰게 될 것 같기도 했습니다. 2022년 중순에 2022 mid 공부 회고를 작성한게 정말 며칠전 일만 같은데요, 그 때 글을 간단히 Recap하면서 동시에 제가 채용을 준비하는 과정이 어땠었는지, 또 3개월간 수습 과정동안 업무를 하면서 바뀐 생각까지 다뤄보겠습니다. 언제나처럼 영양가는 없을 것 같지만, 어떤 분들에게 미세하게나마 도움이 될 수 있을까 해서 남겨봅니다.

2022 mid Recap

그 땐

그 당시 느꼈던 감정은 글에 적혀 있듯 시원하게 망했다 라는 것이었습니다. 그리고 아래의 항목들을 꼭 해야한다고 정했었죠.

• Java Spring
• Kotlin
• SQL, DB 설계, JPA
• Effective Java
• Effective Typescript
• Docker, docker-compose, Kubernetes
• MSA
• Apache Kafka

그리고 그 당시 위 부분을 기초라도 하지 못하면 하반기에 IT 대기업 공채에 지원할 때 온전히 준비가 되었다고 보기 어렵다고 생각했습니다.

왜 그렇게 각박했을까?

사실 굉장히 각박한 기준이었던 것 같습니다. 저기에서 Effective Java 책 하나 두고, Spring 강의 두어개만 보더라도 8월부터 채용 시장에서 매력 있는 사람이 되기엔 어려웠을 것 같거든요.

뭐랄까, 조급했던거죠. 그도 그럴게 당시에 6월 중순부터 7월까지 창업을 해보겠다고 매일 친구들과 모여서 굉장히 치열한 시간을 보냈었거든요. 기술, 시장조사, 기획서, 심지어 정말 못생겼지만 디자인까지 정말 열심히 했었던 것 같습니다. 그럼에도 불구하고 시장 조사 결과 우리의 아이템이 경쟁력이 없고, 아이템을 정리하게 되었죠. 저는 그 아이템을 접으면서 한달 반을 쓰레기통에 갖다 버린 것과 같다는 생각을 했었습니다. 물론 많은 것을 배웠고, 다른 세상이 있음을 알게 되었고, 또 내가 하고 싶은 일을 하는 즐거움을 얻을 수는 있었지만 개발자로서의 실력은 한달 반동안 횡보도 아니고 꽤 큰 폭으로 하락했다는 생각이 들었거든요.

하락장을 탈출해야 한다.

개발자로서 폼이 많이 떨어졌다는 생각에, 스스로를 빨리 개발 감각을 키울 수 있는 환경에 밀어넣고 싶었습니다.

친구들과 아이디어를 접기로 한 그 날 바로 1학기 때 인턴을 했던 기업의 채용 공고를 찾아봤습니다. 인턴 마지막 즈음에 리뉴얼하기로 한 서비스의 백엔드 개발자를 채용하고 있더라구요. 그것을 보고 바로 CTO님께 연락을 드렸죠. 그 날이 7월 29일이었습니다.

“혹시 제가 그 포지션에 지원해도 될까요?”

당시 여러 이해관계로 해당 기업에는 12월까지밖에 근무를 할 수 없는 상황이었음에도 불구하고, 감사하게도 다시 팀에 합류하여 프로젝트를 진행하게 되었습니다. 그리고 저는 8월 1일부터 다시 출근을 하게 됩니다.

많이 망가졌는데?

출근을 하면서 다시 VSCode 앞에 앉아 코딩을 하려고 보니, 정말 제대로된 커리어는 시작도 하지 않은 0년차 감자 주제에 꽤 많은 내리막을 걸어내려온 것 같더라구요. 그래서 8월 3일에 퇴근 이후 방에 틀어박혀서 “내가 왜 이것밖에 못하지? 상반기동안 도대체 뭘 한걸까?”라는 생각을 하며 2022년 중반의 회고를 작성해서 올리게 됩니다.

그리고 이 시점에 본격적으로 채용을 준비(취준)하기 시작했습니다.

취준 시작

새 마음, 새 전략

당시 제게는 스스로 포트폴리오라 칭할 수 있는 Java Spring으로 진행한 프로젝트가 정말 1개도 없었습니다.

하지만 인턴 때 프로젝트에서 TDD를 수행했고 Spring을 논할 때 빠지지 않는 개념인 DI와 IoC를 비슷하게 적용하는 NestJs를 활용하였습니다.

하반기 채용에서 자소서 작성, 면접 준비를 제외하곤 기간이 그다지 많이 남지 않았다고 생각했기 때문에 익숙하지 않은 Spring을 활용해서 프로젝트를 진행하는 것이 아니라 내가 익숙한 언어(TypeScript)와 프레임워크(NestJs)를 활용하여 스스로의 컨셉(구조와 설계에 관심이 많은 개발자)를 증명할 수 있는 프로젝트를 해야겠다고 생각했습니다. 그리고 이미 저는 처음부터 쌓아올려야 하는 리뉴얼 프로젝트라는 과제를 가지고 있었구요. 이 프로젝트에서 제가 할 수 있는 최선의 설계와 구조를 적용해야겠다고 생각했습니다.

시작부터 쉽지는 않았던 환경

생각보다 프로젝트를 진행할 때 맘편히 개발에만 집중하기엔 쉽지 않은 환경이었습니다. 기획자 역할을 해주신 분은 기존 서비스 기획 경험이 없으셨고, 제가 맡은 프로젝트 이외에도 회사는 다양한 이해관계 사이에서 처리해야 할 업무가 많이 있는 상황이었습니다.

그리고 저는 마지막 학기도 병행하여 전공 과목 2개를 수강하고 있었고, 각기 개인 프로젝트 1개와 팀 프로젝트 1개를 가지고 있어 생각보다 시간적 여유가 많이 없었습니다.

하지만 2022 mid 회고에서 깜짝 놀란 후 롤을 삭제한게 꽤 도움이 됐던걸까요, 9시 ~ 12시 회사 업무, 13시 ~ 15시 수업, 15시 ~ 19시 회사 업무, 20시 ~ 01시(혹은 02시) 취업 준비의 루틴을 최대한 지켜가며 낼 수 있는 시간 만큼 CS 공부나 코딩 테스트 준비에 집중했습니다.

코테잘못하는사람

으쯜스읎즈…

코딩테스트를 치는 전형과 코딩테스트를 치지 않는 전형들을 가리지 않고 지원했었는데요, 놀랍게도 코딩테스트를 치는 전형에는 전부 광탈해버렸습니다. 원래부터 코딩테스트에 능한 편도 아니었거니와, 회사에서 작성하는 코드와 코딩 테스트에서 작성하는 코드의 결(?)이 다른 부분 때문에 어쩔 수 없다고 생각했습니다. (물론 굉장히 속상했습니다) 그래도 코딩 테스트를 진행하지 않는 전형들에는 합격해서 면접을 볼 수 있는 기회를 가지게 되었습니다.

데브매칭?

기업들의 코테가 어느정도 마무리되던 시점에 데브 매칭에도 도전해보라는 권유를 받았습니다. 당시에 데브 매칭에서 보기 드물게 신입 대상으로 전형을 진행하는 매력적인 기업들이 있어서 지원을 하게 되었습니다. 데브매칭을 주관하는 기업이 프로그래머스이니만큼, 코딩테스트를 역시 진행하게 되는데 충분히 다 풀 수있는 문제들임에도 불구하고 바보같이 1번을 완전히 풀지 못했습니다.. 그럼에도 운 좋게 한 기업에서 면접 기회를 가지게 되었습니다.

불이야(면접 준비)

나름 순조로운 면접 준비

처음에는 제가 준비할 수 있는 모든 내용을 최대한 꼼꼼하게 준비하자고 생각했었습니다.

CS, 프로젝트, 각종 개발 지식 등 인터넷 등지에서 최대한 많은 질문을 긁어 모으고, 동기들 그리고 오픈 카톡방에서 스터디를 찾아서 스터디를 진행했었습니다.

스터디를 진행할 때는 대체로 공통적인 질문을 정해두고, 모의 면접을 하는 형태로 진행을 했었는데 각자 공부한 부분이 다르다 보니 다양한 시각에서 다양한 질문을 다시 모으는 데에 큰 도움이 되었던 것 같습니다. 자신이 아는 지식을 말로 정리해서 하는 연습은 물론이구요.

양쪽에 화재 발생

그런데 10월 15일, 카페에서 전날 진행한 면접을 복기하며 다음 면접 준비를 하던 중에 갑자기 카카오톡이 잘 안되기 시작합니다. 이후 점점 더 많은 서비스들이 장애가 나기 시작하더니, 급기야 카카오의 대부분의 서비스가 사용 불가능해집니다.

당시 저는 슬랙을 켜며 그래도 슬랙은 잘 되네, 회사 업무 있으면 여기로 오겠다 싶었는데, 정말 무서운 타이밍에 CTO님께 도움 요청이 옵니다. 결국 일종의 리소스 배분 문제, 그리고 외주사의 문제로 회사에 SI 업무 로드가 갑자기 커지기 시작했습니다. 그리고 제 워취밸(Work-취준 Balance)에도 불이 나버립니다.

챙길 수 있는 것만 챙기자

시간적인 여유가 확 줄어들다 보니, 강제적으로 선택과 집중을 해야 했습니다.

첫 면접 경험에서 저는 생각보다 CS, 특히 OS 지식에 대해서 질문을 적게 받았었습니다. 다양한 이유가 있겠지만, 제 자소서의 구조가 CS 질문을 하기보단 프로젝트 관련 질문을 하는 것이 더 자연스러운 자소서였고 동시에 Catch Phrase에도 숲을 보는 주니어 백엔드 개발자라고 써 두었기 때문인 것 같았습니다.

이후에도 맹목적인 CS 스피드 퀴즈 형태의 면접을 하게 될 가능성은 낮다고 생각했고, 프로젝트 관련 내용에 집중해서 면접을 준비하기 시작했습니다. 그리고 가장 자신 있는 TDD와 프로젝트에 적용한 디자인 패턴 부분을 최대한 강조해서 면접 때 말씀드렸습니다. 물론 이런 확증 편향이 먹힌 면접이 있는가 하면, 아예 예상치 못한 방향으로 흘러가서 흐지부지가 돼버린 면접도 있었습니다.

어쩌면 면접은

면접 전형들을 모두 종료한 이후 느낀 점은 내가 더 나은 사람이 될 수도 있겠지만, 사람 대 사람으로 진행하는 것이다 보니 모든 상황적 요소를 압도할 수 있는 지식과 경험이 있는 것이 아니라면 운의 요소가 크게 작용한다는 점이었습니다. 면접관님들 별로 스타일이 모두 다르고, 현업에서 중시하는 부분도 다르며, 그에 따라 지원자에게 궁금한 점도 다르기 때문에 어쩔 수 없는 부분이라고 생각합니다. 조금 더 개인적인 요소까지 가미되면 사실 면접을 보는 시간에 따라 당연하게도 면접관님의 컨디션이 달라지게 되니 사실 인간이라면 하루 종일 모든 지원자에 대해 객관적 판단을 하는 것은 불가능할 것입니다. 그저 면접관으로써 최선의 노력을 해주시는거죠.

그래서 어떻게 됐나요?

제가 면접을 본 기업이 총 세 군데였습니다. 그 중 가장 면접이 늦게 잡혀 있던 곳을 제외하고, 나머지는 마지막 면접 전에 모두 탈락을 했구요.
사실상 마음을 비우고 그냥 나 이런사람이오, 부족하면 인정 또 인정입니다. 라는 마인드로 마지막 면접을 봤습니다.
그리고 진짜 운명의 장난인지, 정말 정말 감사하게도 마지막 하나 남은 기업의 면접에서 합격하게 되어 해당 기업에서 서버 개발자로 현재 일하고 있습니다.

3개월이 지나서 드는 생각은?

언어는 죄가 없다. 하지만

저는 이전 회사에서 진행한 SI 프로젝트에 긴급 투입되어 개발한 경험 이외에는 JVM 언어 기반으로 서버를 구성한 경험이 없었습니다. SI 프로젝트마저도 구조에 제가 관여하기보단 최대한 적은 변경으로 요구사항을 달성하는, 일종의 코드 젠가를 했을 뿐이었죠. 하지만 저는 언어는 그저 언어라는 생각을 가지고 있던 사람이었기 때문에 처음 백엔드 개발을 시작할 때에도 그리고 약간 응용을 해서 프로젝트에 적용하기 시작할 때에도 TypeScript, node 기반으로 학습을 하고 또 활용을 했었습니다.

하지만 만약 이 글을 보고 있는 분이 Spring을 공부하고 프로젝트 하나를 진행할 수 있는 여유가 있는 분이라면 저는 국내 기준으로는 특히 IT 대기업 기준으로는 JVM 기반 언어를 학습하는 것을 강하게 추천드리고 싶습니다. 면접관 분들께서도 대부분 업무를 JVM 기반으로 수행하시기 때문에, 면접 질문에 있어 의미 있는 질문을 받을 확률이 높고 그것에 대한 올바른 답변이 긍정적 인상으로 연결될 확률이 높기 때문입니다. 다른 언어나 프레임워크 기반은 면접관분들에게도 생소한 경우가 있기 때문에, 오히려 판단에 있어 애매한 인상을 남기는 상황이 연출될 수 있습니다.

MSA? 오히려 OOP

저는 취준을 하던 시기에 굉장히 MSA에 집착했었습니다. 대부분의 큰 기업들은 이미 MSA 환경에서 서비스를 개발하고 있기 때문에 그것에 대해서 꼭 알아야 한다는 생각이 컸기 때문입니다. 하지만 이런 아키텍처에 대한 내용은 경험에 근거한 기반 지식 없이는 빠르게 이해하기 어렵습니다. 해당 상황과 문제를 받아들이기 어렵기 때문입니다. 그래서 MSA에 대해 너무 깊게 이해하려고 하지 말고, 차라리 OOP나 디자인 패턴에 집중하시는 것을 추천드리고 싶습니다.

제가 최근 느끼고 있는 제 가장 큰 문제는 실무에서 필요한 요구사항을 깔끔하고 가독성 좋은 코드로 풀어내는 것을 굉장히 어려워한다는 점입니다. 과연 신입 개발자에게 유지보수 가능한 서비스를 개발함에 있어 복잡한 요구사항을 간결하고 읽기 쉬운 코드로 작성하는 능력이 중요할까요 아니면 거시적인 아키텍처를 이해하고 더 나은 구조를 생각해내는 능력이 중요할까요? 3달전의 저는 후자가 더 중요하다고 생각했었던 것 같은데요, 요즘은 전자가 더 중요한 것 같습니다.

높은 트래픽, 깊은 고민

이전에 개발하던 서비스는 트래픽이 높지 않았기 떄문에 동시성에 관한 부분에서 이슈를 겪은 적도 없고 DB에 풀스캔이 일어난다고 해도 참을 만한 수준의 로딩 시간이 걸리는 작은 서비스였습니다. 그렇기 때문에 문제가 일어나고 있음에도 깨닫지 못하는 경우가 종종 있었습니다. 그보다 정말 시시각각 변하는 요구사항을 유연하게 받아들이기 위한 구조에 집중했었습니다.

하지만 지금은 개발하는 서비스는 트래픽도 높고, 사용자도 굉장히 많기 때문에 고려해야 할 부분이 배로 많습니다. 동시에 개발자가 개발을 하는 만큼 기획자 분들도 아이디어를 많이 떠올리시기 때문에 그것에 유연하게 대응할 수 있는 고민도 역시 이어서 해야합니다. 이를 위해 고민을 하고 결정을 하는 데에 더 많은 시간을 쏟게 되고, 이 과정에서 어느 정도 자신만의 해법 그리고 은탄환은 없다는 깨달음을 갖게 됩니다.

따라서 지금 공부를 시작하시는 분들, 아니면 트래픽이 높지 않은 서비스를 개발하시고 계신 분들도 만약 이 서비스에 엄청 높은 트래픽이 쏠리면 어떤 문제가 생길까에 대한 고민을 종종 해보시면 좋을 것 같습니다. Stress Testing을 위한 도구를 사용해보셔도 좋고, 그게 아니라면 간단하게 node에서 fetch 명령어를 비동기로 반복해서 쏘는 것 만으로도 꽤나 의미있는 TPS를 만들 수 있습니다. 그 부분에 대한 고민 그리고 그것에 대한 자신만의 해법, 또한 그 해법을 설명하는 글(블로그)이 있으면 긍정적인 요소가 될 것 같습니다.

줄이며

역시가 역시라고, 별로 맛이 없는 글을 또 써버린 것 같습니다. 이정도면 일기장에 쓰는게 🥲🥲…
그래서 제 블로그를 슥 돌아봤는데, 개발에 관련된 정보가 정말 없고 진짜 일기장에 가까운 블로그인 것 같았습니다. 맨날천날 회고나 쓰고 계획만 세우는… 그래서 얘가 뭘 하는건지 알맹이는 전혀 없는…
앞으로는 개발과 관련된 정보와 지식도 열심히 작성해보려 합니다.
올해는 의미있는 포스팅으로 찾아뵙도록 하겠습니다. 감사합니다.

끝.