ML Engineer의 2025 이직로그 (2): 준비

2025년 11월, 이직에 성공하기까지의 과정을 글로 남겨본다. 이 포스팅은 그 중 두번째 글이다.

• 2025 이직로그 첫번째 글
• 2025 이직로그 세번째 글 

지난 포스팅에는 내가 여태까지 해온 업무를 살펴보고 어느 업무에서 흥미를 느꼈는지 생각해봤다. 이를 통해 나의 커리어 방향성을 세울 수 있었고 이 방향으로 나아가기 위해 이직을 결심한 과정에 대해 서술했다.

 

이 포스팅에서는 이직을 위해 준비한 것들을 기록하고자 한다. 크게 1) 왜 추천 ML 인가? 2) 추천 도메인 공부 및 코딩 3) 알고리즘 연습 4) 서류 및 면접 준비로 나눠서 서술한다.

왜 추천 ML 인가?

이직을 시작할 때부터, 나는 추천 ML을 하고 싶었다. 일단 추천 ML은 알고리즘 자체가 재미있었다. CF, MF, 딥러닝 기반 모델 등 모델이 발전하는 모습이 흥미로웠다. 또한, 추천 ML은 굉장히 범용성이 넓은 ML이라고 생각한다. 어느정도 트래픽이 발생하는 서비스라면 추천 ML을 통해 유저의 리텐션을 높이는 전략을 고민한다. 추천 ML은 foundation model이 나올 가능성이 적은 ML 분야 중 하나라고 생각한다. 예를 들어서, 자연어 ML 분야를 생각해보자. llm이 개발되면서 많은 자연어 모델은 llm api의 zero-shot, 또는 few-shot prompting에 의해 대체 되었다. 물론, 파인 튜닝의 니즈까지 완벽하게 대체하는 llm은 아직 나오지 않았으나, 요즘 성능이 워낙 좋아서 점차 파인 튜닝에 대한 니즈도 사라지지 않을까 싶다. 한 마디로, llm api을 돈 주고 사용하는 것이 가성비가 좋고 결과도 빠르게 낼 수 있다는 인식이 만연하다. 그와 반면에, 추천 ML은 굉장히 domain-specific한 기술이다. 예를 들어서, 중고 거래 플랫폼 당근의 게시글에 추천 알고리즘을 적용한다고 생각해보자. 추천 foundation 모델을 당근 게시글에 적용할 수 있을까? domain과 매우 밀접하게 연관되어 있기 때문에 쉽지 않다고 생각한다. 이와 같이, 각 회사는 추천 알고리즘을 개발하기 위해 각자의 데이터에 맞게 모델을 설계해야할 것이다. 따라서, 추천 ML 엔지니어는 빠른 시일 내에 AI에 의해 대체되기 힘들다고 생각한다.

 

추천 ML이 위의 장점을 가진다고 생각하지만, 당연히 단점도 존재한다. 먼저, 주로 규모가 어느 정도 되는 서비스에서 추천 ML을 고려한다는 것이다. 예를 들어서 이제 막 런칭한 서비스는 추천 ML보다도, 당장 유저를 더 확보할 수 있는 매력적인 피쳐를 개발하는데 힘을 쏟는다. 이러한 이유 때문에, 추천 엔지니어가 갈 수 있는 회사의 폭이 다른 AI 엔지니어에 비해서 좁을 수밖에 없다. 요즘, 거의 모든 회사가 Agent Engineer을 채용하려고 하는 것을 보면 그 차이를 확연하게 알 수 있다. 또한, 추천 알고리즘이 직접적으로 회사에 돈을 벌어준다고 볼 수 있을까? 간접적으로 매출에 기여한다고 추측할 수 있다. 서비스에 오래 머물게 하여, 광고나 기타 커머스 매출에 도움을 줄 수 있다. 그러나 이는 어디까지나 추측이다. 물론, 광고 추천 ML은 회사의 매출과 직결된다. 그러나, B2B 등의 형태로 개발하지 않는 이상, 추천 ML이 직접적으로 회사에 돈을 벌어다주는 경우는 드물다고 생각한다.

 

추천 ML은 위와 같이 장/단점이 분명하다고 생각한다. 하지만 장점만 있는 분야가 어디 있으랴. 나는 공부하면서 가장 흥미를 느끼고 나의 전공과 궁합이 잘 맞으며 실력을 갖출 자신이 있는 분야가 추천 ML 말고 다른게 떠오르지 않았다. 때문에, 추천 ML로 포지션을 정하고 포트폴리오를 준비하기 시작했다.

추천 도메인 공부, 코딩 및 프로젝트

추천 알고리즘을 잘 모르기 때문에 기본 개념에 대한 공부는 필수라고 생각했다. 따라서, 고전 추천 알고리즘부터 딥러닝 기반 알고리즘까지 폭 넓게 공부하고 정리했다.

https://steady-programming.tistory.com/category/ML%26DL/Recommender%20System

'ML&DL/Recommender System' 카테고리의 글 목록

 

이 블로그 포스팅들을 직접적으로 포트폴리오에 제출하지는 않았다. 어디까지나 '공부'이기 때문이다. 공부한 내용을 포트폴리오에 포함할 수도 있지만, 개인적으로는 코딩하고 실험한 이력을 포함하는게 더 낫다는 생각을 했다. 그렇게 무작정 레포를 생성했다.

https://github.com/bohyunshin/recommender

GitHub - bohyunshin/recommender: ML Models in Recommender System

 

개발자는 코드로 보여줘야 한다. 공부는 했는데 코드는 없다? 이러면 반쪽짜리 공부라고 생각한다. 왜냐하면 내가 지향하는 포지션은 Researcher가 아니라 Engineer이기 때문이다. 아무리 fancy한 알고리즘이더라도 추론 시간 복잡도가 n^3이라면 의미가 없다. 이러한 실질적인 고민은 코딩을 하며 맞닥뜨린다. 따라서 알고리즘을 코딩하는 것이 완전한 공부라고 생각한다. 코딩을 하는 것은, 나의 코딩 스타일을 지원하려는 회사에게 보여주는 장점도 있다. 물론, 나는 코딩을 잘 못한다. 그러나 가독성과 확장성 있는 코딩을 하기 위해 노력한다. 면접관도 나의 코드를 보며 개발 스타일을 파악할 수 있고 이를 통해 나를 더 잘 파악하는데 도움을 줄 수 있다고 생각한다.

 

여기까지는 유명한 데이터에 추천 ML을 적용하기 위한 파이프라인 개발 과정이다. 유명한 데이터라고 하면, movielens, pinterest 등이다. 어떻게 보면, Real 데이터가 아닌, 정제된 데이터이기 때문에 Real 데이터를 마주할 때의 실질적인 고민을 할 수 없다. 즉, 위의 코딩만으로 포트폴리오를 구성하기에는 부족하다고 생각했다. 때문에, 카카오 리뷰 데이터를 활용한 식당 추천 시스템 구축 프로젝트에 참여했다.

https://github.com/lunch-corp

LUNCH

 

정말 내가 애정하는 프로젝트이다. 현재는 레포가 private이기 때문에 org로 링크를 달아뒀다. 마음에 맞는 팀원분들과 문제를 정의하고 문제 해결을 위해 ML 모델을 실험하며 마지막으로 간단하게 직접 구현까지 하고 있다. 2025 모두콘에서 해당 내용을 발표할 예정이다.

https://moducon.modulabs.co.kr/session/10-07

MODUCON 2025 | 모두콘 2025

 

이 협업 프로젝트를 통해 얻은 것은 다음과 같다. 먼저, Real 데이터인 카카오 리뷰 데이터에서 어떻게 추천 시스템을 구축할 것인지 팀원들과 함께 고민했다. one stage 또는 two stage로 설계할지, 각 단계에서 어떤 모델을 선택할지, 리뷰 데이터의 어떤 요소를 뽑을 것인지 등에 대해 논리적인 근거와 함께 생각하려고 했다. 이때, 무지성으로 선택하는 것이 아니라 논리적인 근거가 뒷받침되어서 의사 결정하는 것이 중요하다고 생각한다. 현업의 의사결정 프로세스를 따라가는 것이다. 다음으로, Git을 통해 효율적으로 협업했다는 점이다. 이직을 하면, 어느 회사를 가든 그 회사의 코드는 처음 접한다. 코드는 결국 Git으로 관리된다. 따라서 Git을 얼마나 잘 사용하는지, Git을 통해 협업을 얼마나 잘 하는지 등의 요소가 중요하다고 생각했다. 따라서, 프로젝트에서 내가 먼저 Git을 통한 형상 관리를 제안했으며 여태껏 협업 툴로 사용하고 있다. 마지막으로, 실 서비스까지 생각하여 ML-Ops 아키텍쳐도 구상하고 있다는 점이다. 혼자 프로젝트를 했으면 알고리즘 코딩 및 실험 파이프라인 설계에서 끝났을 것이다. 하지만 협업을 하다보니, 각자 다른 컴포넌트를 개발하고 이를 합쳐서 작은 서비스로 내고자 하는 니즈가 모아졌다. 즉, 이 사이드 프로젝트를 통해서 알고리즘 설계 및 실험, Git 협업, 작은 서비스 런칭까지, ML을 활용한 프로덕트 개발의 한 사이클을 간접적으로 경험할 수 있었다.

 

지원하기 전에 준비한 추천 ML 관련 포트폴리오는 위의 내용이 전부이다. 포트폴리오를 준비하다보면, 완벽한 상태에서 회사에 지원하고 싶은 욕구가 샘솟는다. 그러나 경험상, 그런 완벽한 상태는 오기 힘들다. 아니, 먼 미래에 올 가능성이 높다. 따라서 프로젝트의 완성도가 70% 정도만 되어도 일단 지원을 하자. 100%는 너무 먼 미래이다. 적어도 내 경험상 빨리 지원하는게 좋았다.

알고리즘 연습

코딩 테스트를 준비하기 위해 알고리즘을 연습했다.

 

먼저, 알고리즘에 대한 감을 끌어올리는게 중요했다. 이를 위해 코딩 테스트에서 많이 나오는 알고리즘 유형을 복습했다. Bruteforce / Backtracking / BFS & DFS / DP / Sorting / Binary Search / Implementation 을 포함한다. 백준 및 예전에 취준할 때 사둔 이것이 코딩 테스트다 책을 참고했다.

 

다양한 회사의 코딩 테스트 유형을 조사했는데 리트코드 기반인 회사가 많았다. 바로 리트코드로 넘어갔다. 문제가 굉장히 방대했으나, 여러 유튜브 영상에서는 빅테크에서 자주 나온 문제 위주로 풀라는 조언이 많았다. 한달 결제를 하고 리트코드의 Google, Facebook, Amazon 등의 기출문제를 모조리 풀었다. 문제를 풀다보니, 백준에서 보지 못한 유형도 많이 있었다. 예를 들어서, sliding window, monotonic stack. 물론 내가 백준에서 이 문제를 접하지 못했을 것이다. 이런 새로운 유형들을 접하면 복습을하며 최대한 친숙하게 만들었다.

 

막판에는 새로운 유형을 습득하기보다, 기존의 유형을 반복하며 복습했다. 특히, 리트코드에 양질의 문제를 모아둔 유명한 게시글이 있다.

https://leetcode.com/discuss/post/460599/blind-75-leetcode-questions-by-krishnade-9xev/

 

이 글에 있는 문제를 중점적으로 풀었다.

 

알고리즘의 감을 찾는데 시간이 오래 걸린 점이 아쉽다. 평소에 알고리즘을 꾸준하게 푸는 습관을 들였다면 벼락치기 마냥 알고리즘 문제를 풀지는 않았을 것이다. 하지만, 모든 개발자들이 이것을 알고 있음에도 실천을 못하고 있지 않은가. 올해에는 리트코드 1년치 구독료를 결제하고 다음 이직을 위해 꾸준하게 풀어볼 계획이다.

 

나에게 한가지 벽이었던 것은, 바로 라이브 코딩 테스트이다. 지원한 회사 중 네 곳에서 라이브 코딩 테스트를 봤다. 라이브 코딩 테스트란, 면접관과 실시간으로 코딩하며 문제를 푸는 것을 의미한다. 알고리즘을 혼자 풀기에도 벅찬데 면접관이 지켜보는 가운데서 라이브로 코딩을 해야하다니 ㅋㅋ 태생이 통계학도인 나로서는 정말 난감한 전형이 아닐 수 없었다.

라이브 코딩 테스트에 대한 후기는 다음 글에서 면접 후기와 함께 살펴보도록 하고, 여기서는 라이브 코딩 테스트 준비 방법에 대해서 기록한다. 사실 뾰족한 방법은 없다. 일단 문제를 많이 풀어봐야 한다. 그러나, 그냥 풀면 안 된다고 생각한다. 라이브 코딩 테스트에서 출시된 문제를 보고 솔루션을 한번에 찾아가기는 쉽지 않다. 즉, 막히는 부분이 있으면 면접관에게 이를 설명하고 힌트를 얻어야 한다. 이를 평소에 어떻게 훈련할 수 있을까? 가장 좋은 방법은 지인과 함께 모의 라이브 코딩 테스트를 보는 것이다. 이것이 쉽지 않으면, 평소에 알고리즘 문제를 풀 때 주석으로 생각하는 과정을 기록하는 습관을 들이는 것이 중요하다. 내가 생각만 하거나, 따로 종이에 생각을 정리하는 것은 의미가 없다. 면접관이 내가 무슨 생각을 하고 있는지 모르기 때문이다. 가장 중요한 것은 내가 어떤 생각을 하고 있는지 면접관에게 알리는 것이다. 실제로 어떤 회사와 라이브 코딩 테스트를 보는데 내가 주석을 잘 적으니까 면접관이 문제를 이해했는지 확인할 필요가 없다고 언급하며 바로 다음 단계로 넘어갔다. 이와 같이 면접관과 나의 생각의 싱크를 맞추는 것이 매우 중요하다!

또한, 명확하지 않은 조건이 있다면 면접관에게 자유롭게 질문을 하여 명확하게 만드는 것이 중요하다. 마치, 개발하기 전에 기획자와 요구사항을 맞추는 과정이라고 생각하면 된다. 예를 들어서, 문제에 입력의 크기에 대한 조건이 없다고 생각해보자. 생각을 깊게 하지 않고 n^2의 시간 복잡도를 가지는 알고리즘을 코딩을 먼저 하는 것보다 입력의 크기에 대해서 명확히 질문하고 넘어가는 것이 낫다. 만약에 n이 10^5 등 그 크기가 크다면 nlogn 또는 n의 시간 복잡도로 문제를 풀어야하기 때문이다.

정답이든, 오답이든, 코딩을 한 후에는 시간 및 공간 복잡도를 설명하자. 이때, 대충 코드를 슥 보면 안 된다. 코드라인 하나하나를 살펴보며 여기는 상수 시간이다, 여기는 n^2이다 등으로 설명을 해야한다. 첫 번째 라이브 코딩 테스트에서 내가 짠 코드를 꼼꼼하게 제대로 살펴보지 않아서 틀린 시간 복잡도로 설명을 했다. 면접관 입장에서는 꼼꼼한 개발자를 원할 것이다.

사실 코딩을 잘 하면 위의 노력이 필요 없다. 하지만 나같이 코딩을 잘 못하는 사람은 위의 노력이 필수이다. 특히, 연습할 때 주석에 생각하는 과정을 적는 습관을 꼭 들이자.

서류 및 면접 준비

이력서 및 포트폴리오는 내가 이 프로젝트에서 맡은 역할, 프로젝트의 정량적인 성과, 이 성과에 내가 기여한 점 위주로 간략하게 정리했다. 사실 이력서를 정리하면서도 많은 생각이 들었다. ML Engineer 포지션으로 지원하는데, 업무 상으로 뾰족한 ML 개발 경험이 부족하다고 느껴졌기 때문이다. 이직할 때만 이력서를 작성하는게 아니라, 큰 프로젝트가 끝날 때마다 이력서를 업데이트하는 것이 필요하다고 생각했다. 이를 통해 매년 나의 위치를 객관적으로 파악할 수 있기 때문이다.

 

면접은 이력서/포트폴리오 기반 질문과 ML 기초 질문으로 나눠서 준비했다. 이력서를 통해 나올 수 있는 예상 질문을 전부 정리했다. 특히, 이 알고리즘을 왜 사용했는지, 이 알고리즘이 어떻게 작동했는지 등의 질문을 집중적으로 생각했다. 모든 과정에 왜?를 붙였다. 왜 Two-Stage을 선택했는가? 왜 GNN 모델을 선택했는가? GraphSage는 왜 성능이 안 좋았다고 생각하는가? GCN에서 푸리에 변환은 무엇을 의미하는가? 등, 내가 했던 모든 의사 결정에 대해 왜? 무엇인가? 를 붙이며 예상 답변을 작성했다. ML 기초 질문은 말 그대로 기초적인 지식 위주로 준비했다. 머신러닝 / 딥러닝 / 추천시스템 분야의 기초 질문을 Claude한테 뽑아달라고 했다. 개념을 말로 설명하며 면접에 대비 했다.

마치며

오랜 준비를 하며, 결코 이직이라는게 쉽지 않음을 몸소 깨달았다. 특히 내가 원래 하던 분야가 아니라, 추천 ML이라는 새로운 분야로 포지션을 옮기려는 것이었기 때문에 준비해야할 것들이 더 많았다. 한 가지 첨언하고 싶은 것은, 위의 준비가 전부 끝난 뒤에 지원하면 너무 늦다는 것이다. 추천 ML 프로젝트는 여전히 진행 중이다. 알고리즘은 공부하다보면 끝이 없다. 모든 리트코드 문제를 풀 수 없기 때문이다. 기초 ML 지식도 사실 파다보면 끝도 없이 나온다. 따라서, 어느정도 준비가 되었다고 생각하면 일단 지원하라. 단, 제일 가고 싶은 회사는 가장 나중에 지원해야 한다. 탈락해도 큰 타격이 없는 회사부터 지원하자. 코딩 테스트, 라이브 코딩 테스트, 면접을 보면 볼수록 자신감이 더 생기고 내 이력서에 기반하여 나오는 질문들이 유사함을 알게 된다. 따라서 일단 행동하라. 지원하고, 부딪히며 탈락하면서 배워야한다. 그래야 성장하고 칼을 갈며 다음 회사의 전형을 준비한다. 다음 포스팅에서는 면접 및 코딩 테스트 후기에 대해서 정리하겠다.