ML Engineer의 2025 이직로그 (3): 실전, 앞으로의 계획

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

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

이전 포스팅에서 이직을 결심한 계기, 그리고 준비 과정에 대해서 상세하게 살펴봤다. 이제 실전이다! 어떤 종류의 면접을 봤고 내가 어떤 점을 느꼈는지, 그리고 부족하다고 느낀 점은 무엇이며 앞으로 어떻게 자기 개발을 해나갈 것인지 정리해본다.

내가 경험한 면접 전형

라이브 코딩 테스트

라이브 코딩 테스트는 말 그대로 라이브로 코딩 테스트를 보는 것을 의미한다. 온라인 미팅에서 나의 화면을 공유하고 면접관이 내가 코딩하는 것을 보며 서로 소통하면서 진행된다. 라이브 코딩 테스트를 어떻게 준비하는지에 대해서는 이전 포스트에서 살펴봤으니 이 포스팅에서는 구체적인 회사 이름은 언급하지 않고 내가 느꼈던 인상 위주로 기록하겠다.

 

일단 라이브 코딩 테스트 (이하 줄여서 라코)의 목적을 생각해보자. 일단, 라코는 정답을 맞추는게 1순위는 아니다. 물론, 정답을 맞추면 좋다. 최적의 솔루션을 찾는 것이 이상적인 모습일 것이다. 그러나, 면접관들도 최적의 솔루션을 찾는게 쉽지 않다는 것을 안다. 따라서, 최적의 솔루션을 찾아야한다는 부담과 강박증을 일단 내려 놓자.

최적의 솔루션을 찾는 것보다 라코는 문제에 대한 이해가 부족할 때, 막히는 부분이 있을 때, 문제의 요구 사항이 명확하지 않을 때, 면접자가 면접관과 어떻게 소통하는지를 보는 것이 주요 목적이다. 생각해보면, 라코라는 극한의 상황에서는 면접자가 평소에 하던 행동이 나올 가능성이 크다. 예를 들어서, 소통을 많이 하는 개발자를 생각해보자. 이 개발자는 기획으로부터 요구 사항이 불명확하다면 적극적인 소통을 통해서 이를 명확하게 만들 것이다. 이런 개발자는 라코에서도 문제의 입력 제한이 주어지지 않으면, 최대 입력 크기가 얼마나 되는지 등을 물어보며 요구 사항을 명확하게 맞출 것이다. 문제를 읽고 냅다 코딩하는 것이 아니라, 문제에서 요구하는 것이 정확히 무엇인지, 입력의 제한은 어떻게 되는지 등의 행동이 훨씬 중요한 것이다.

필자는 라코를 4번 응시하며 모든 면접관들이 위와 같이 말하는 것을 들었다. 최적의 솔루션까지 가는 그 과정, 사고하는 과정, 의사소통하는 모습, 이런 것들이 최적의 솔루션을 찾는 것 자체보다 훨씬 중요하다. 라코를 보기 전에, 라코의 목적을 다시 한번 마음에 새기자.

 

라코에서는 무엇보다 내가 어떤 생각을 하고 있는지 면접관에게 알리는 것이 중요하다. 그런 관점에서, 초반에 봤었던 라코에서는 너무 내가 말이 없이 머리속으로 생각만 했었기 때문에 의사 소통이 거의 이루어지지 않았다. 예를 들어서 라코에 할당된 시간이 30분이라고 하자. 내가 그 중에 10분을 머리속으로 생각하는데 쓴다고 생각하면, 면접관은 상대가 어떤 생각을 하는지도 모른채 라코 시간이 1/3이 날라가는 것이다. 코드 주석 형태 또는 말로든, 내가 어떤 생각을 하고 있는지 반드시 알려야 한다. 그래야 잘못된 길로 가고 있으면 교정도 해주고, 힌트도 얻을 수 있다.

 

라코에서 주어진 문제는 어떤 유형일까? 내가 마주했던 문제는 알고리즘 유형도 있었고 평이한 문제도 있었다. 그런데 어느 경우든, 문제에 대한 최적의 솔루션이 쉽게 생각나지 않는다는 것이다. 필자는 총 4번의 라이브 코딩 테스트를 봤는데 4번 모두 최적의 솔루션이 한번에 떠오르지 않았고 실제로 코딩을 제대로 하지도 못했다. 심지어 4번 중 한번은 이미 리트코드에서 문제를 풀었음에도 불구하고 테스트 케이스를 전부 통과하지 못했다. 이유가 무엇일까? 일단, 긴장이 될 수밖에 없는 환경이다. 혼자 코딩하는 것도 쉽지 않은데 제 3자가, 게다가 면접관이 보는 가운데서 코딩하는 것은 정말 어렵다. 그 상황 자체가 긴장이 된다. 따라서, 최적의 솔루션을 한번에 갈 수 없음을 인정하고 sub-optimal 솔루션을 먼저 빠르게 코딩하는 것도 괜찮은 전략이라고 생각한다. 최적의 솔루션을 한번에 가려고 끙끙거리는 것보다 sub-optimal 솔루션을 코딩하고, 이를 기반으로 면접관과 소통하면서 최적의 솔루션에 가까워지는 전략이다. 일단, 최적의 솔루션이 5분 안에 생각나지 않는다면 더 생각한다고 최적의 솔루션이 생각날 가능성은 거의 없다고 보자. 따라서, sub-optimal 솔루션을 제시하고 시간 복잡도가 n^2이라서 최적의 솔루션이 아니라고 생각한다고 말하면서 면접관과 소통을 해보자. 대부분의 면접관은 대안을 제시해줄 것이다.

 

위에서 서술한 것처럼 내가 응시한 라코는 테스트 케이스를 통해 채점까지 진행한 곳도 있었다. 이 라코를 볼 때는 사실 리트코드에서 풀었던 문제가 나왔기 때문에 무난하게 풀 수 있지 않을까 생각했는데... 테스트 케이스를 전부 통과하지 못했다! 회고해보면.. 마지막에 테스트 케이스를 통과하지 못하고 검토를 할 때 설계한 알고리즘 로직이 당연히 맞을 것이라고 생각했다. 왜 이런 자만한 생각을 했을까? 아마도 이전에 풀었던 문제이기 때문에, 이게 맞을거야! 라는 생각을 가졌던 것 같다. 매우 오만한 생각이었다. 설계한 알고리즘 로직이 틀렸기 때문이다. 100% 복원되는 기억은 적다. 특히, 라코라는 특수한, 긴장되는 상황에서는 더더욱 그렇다. 아무리 내가 자신 있는 로직이라도 '틀릴 수도 있어'라는 의심의 눈초리로 검토하는 것이 중요하다는 교훈을 얻었다.

 

pseudo coding은 지양하자. 라코를 보다보니, 시간은 적게 남은 상태에서 아이디어가 떠올라서 pseudo coding을 한 적이 있었다. 면접관 입장에서, 생각나는 것을 빠르게 코딩한 사람과 psudo 코딩, 다르게 말하면 입코딩을 한 사람, 둘 중에 어느 사람을 선호할까? 당연히 빠르게 코딩한 사람일 것이다. 물론, 시간이 적기 때문에 울며 겨자 먹기로 이거라도 해야 하는 상황이면 어쩔 수 없다. 그러나, 시간이 꽤 남았음에도 입코딩을 하는 것은 좋지 않다고 생각한다. 예를 들어서, 아래와 같은 형식이다.

for i in range(n):
   for j in range(n):
      # nums[i]의 존재를 확인하기
      # nums[j]와 비교
      # result list에 추가

 

급하면 위와 같이 짜도 되긴 하는데, 저렇게 코딩하면 일단 명확하지 않다. 저 로직을 어떻게 구현할 건데? 라는 후속 질문이 반드시 들어온다. 그리고 시간 복잡도를 분석을 할 수가 없다. 입코딩은 라코의 목적을 달성하기 힘든 형태이다.

 

시간 복잡도 및 공간 복잡도는 반드시 분석할 줄 알아야 한다. 사실, 어느 코딩이든 몇 줄만 짜면 코딩은 쉽게 할 수 있다. 그러나 그 코드가 trash 인지, 잘 설계되었는지가 중요하다. ML Engineer 뿐만 아니라 Software Engineer는 코드를 짤 때 scalability을 고려해야한다. 즉, 입력의 크기가 커짐에 따라서 실행 시간, 메모리는 어떻게 변화하는지 코드를 짠 본인은 반드시 알아야 한다는 것이다. 라코에서도 시간 및 공간 복잡도 분석은 반드시 한다. 이때, 정말 주의해야할 점은 코드를 슥 보고 for 문이 두 번 있네~ n^2 이구나! 라고 생각하면 절대로 안 된다는 점이다. for 문을 두번 돌고, 최종 수행하는 작업이 상수 시간인지, 그 코드 라인에서 호출하는 함수가 n의 시간이 소요되는지 등을 면밀하게 분석해야한다. 이런 이유 때문에, 나는 시간 및 공간 복잡도를 분석할 때는 내가 짠 코드를 한줄 한줄 살펴보며 꼼꼼하게 상수 시간 여부를 살펴보는 것을 선호한다. 그리고 이것은 라코를 보며 실수를 했던 것을 보완한 것이다.

 

라코를 4번정도 봤다. 마지막으로 응시한 라코에서조차 최적의 솔루션을 찾지 못했지만, 면접관과 합이 맞는다는 생각이 들었다. 내가 생각하는 과정을 꼼꼼하게 주석으로 적었기 때문에 면접관이 내가 문제에 대해서 잘 이해하고 있다고 생각하고 곧 바로 코딩을 해도 된다고 했다. 이는 내가 문제의 요구 사항을 잘 이해했고 입력 제한 사항도 철저히 고려하고 있음을 의미했다. 실제로 내가 짠 코드는 최적의 솔루션이 아니었다. 그럼에도 왜 최적의 솔루션이 아니라고 생각하는지 시간 복잡도를 분석하며 설명했다. 또한 이 코드 라인을 수정하면 시간 복잡도를 더 개선할 수 있을 것 같다고 언급했다. 마지막으로, 다른 형태의 sub-optimal 코드를 짤 수 있는지 물어봤을 때, pseudo 코드를 짜지 않고 곧 바로 파이썬 코드를 짰다. 이렇게 라코를 보니까 최적의 솔루션은 짜지 못했지만, 면접관과 충분히 소통이 잘 되고 문제 해결의 직전까지 갔음이 느껴졌다. 

이력서 기반 면접

가장 무난한 형태의 면접이다. 이력서 기반의 질문이 들어오는 형태이다. 준비를 잘 하면 된다. 이력서를 정리하며 내가 했던 의사 결정 과정들이 쭉 나올 것이다. 그러면, 모든 의사 결정에 WHY?을 붙이면 된다. 무지성으로 의사 결정을 하는 사람이 아니라는 것을 보여주면 된다. 사실, 이렇게 왜? 라는 질문을 스스로 하며 더 성장하게 된다. ML 모델에 대해서는, objective function을 칠판에 스스로 적을 수 있을 정도로 빠삭하게 파악하면 된다. 면접을 봤던 한 회사에서 생각보다 디테일하게 모델에 대해서 물어봤었다. 그때 objective function을 100% 파악하지 못하고 있어서 대답을 명확하게 하지 못했다. 함수의 수식 하나하나에 대해서 그 의미를 파악하고, 이 수식이 어떤 역할을 하는지, WHY 사용하는지 본인 스스로 명화하게 대답할 수 있어야 한다. 이렇게 생각해보자. 왜 이 의사 결정을 내렸나? 이 기술은 무엇인가? 이 기술이 왜 필요한가? 이 기술말고 다른 기술은 고려하지 않았는가? 이런 질문을 면접 준비를 하며 스스로에게 해보는 것으로 충분하다고 생각한다.

기초 ML 지식 면접

기초적인 ML 지식에 대해서 물어본다. regression / classification부터 시작하여 ML/DL의 기본인 backpropagation, loss function 등을 물어본다. 사실 더 나아가서는 gradient을 직접 수식으로 도출하는 것까지 나올 수 있다고 생각한다. 다양한 loss function로부터 gradient을 계산하는 과정을 연습해두자. 더 심화하면, attention의 gradient을 계산하는 문제도 나올 수 있다고 생각한다.

시스템 디자인 면접

개인적으로 가장 어려운 면접 전형이었다. 예를 들어, 상품의 이미지를 분류하는 모델을 만들어주세요, 라는 질문을 면접관이 던진다. 그러면 나는 A부터 Z까지 요구 사항을 전부 맞춰야한다.

이때 모델을 바로 설계하는 것보다 요구 사항을 명확하게 해야한다. 왜냐하면, 분류하는 모델을 만들어달라고 했지, 어느 서비스의 어느 데이터를 활용할 것인지는 전혀 주어지지 않기 때문이다. 공감을 위해 기획자가 ML Engineer에게 상품을 분류하는 모델을 만들어주세요! 라고 막연하게 요청했다고 생각해보자 (실제로 이렇게 모호한 요청을 하는 경우는 없다). 개발자 입장에서는 '상품'이 도대체 무엇을 의미하는지, 카테고리 분류인지, 어떤 데이터가 입력으로 들어가는지, 서비스의 어느 지면에 이 모델이 사용되는지 등 맞춰야할게 산더미이다. 나는 시스템 디자인 면접을 보며, 면접관과 요구 사항을 맞추는데 많은 시간을 할애했다. 그만큼 요구 사항이 모호하게 주어지기 때문에 이를 명확하게 하는 것이 중요하며, 면접관은 그 과정에서 이 개발자가 어떻게 소통하는지를 중점적으로 볼 것 같다고 생각한다.

중요한 것은, 이 요구 사항을 맞추는데 너무 많은 시간을 할애하면 안 된다는 것이다. 필자는 여기에 많은 시간을 써서 정작 어떤 모델을 사용하고, 어떤 입력 데이터를 사용할 것인지 등 ML Engineer 역량이 필요한 부분에 대해서는 많이 고민하지 못한 것이 큰 아쉬움으로 남는다.

결국 주어진 시간 내에서, 요구 사항을 맞추고 모델까지 설계하는 것은, 개발 기간이 주어졌을 때 기획자와 소통하고 실제로 개발까지 하는 과정을 의미한다고 생각한다. 시스템 디자인 면접은 이 종합적인 역량을 측정하는 것이다. 연습이 살 길이다! 시스템 디자인 면접 전에 예상되는 질문을 가지고 어떻게 면접관과 논의를 이끌어갈 것인지 시뮬레이션 해보자.

논문 리뷰 면접

내가 가장 자신있는 면접 전형이다. 논문이 주어지고, 발표 자료를 만든다. 그리고 면접에서 관련 질문을 받는다. 이 전형은 면접자가 도메인에 대한 지식이 없어도 입사해서 똘똘하게 업무를 잘 할 수 있는지를 평가한다. 나는 ML Engineer가 필요로 하는 역량 (이전 포스팅에서 살펴봄) 중에 현재로써는 리서치 역량이 가장 자신이 있다. 따라서, 논문 리뷰 면접은 나와 궁합이 가장 잘 맞는 전형이다.

1을 해오라고 했지만 10을 해간다는 마인드로 준비하자. 논문이 주어졌다. 그러면 그 논문의 motivation, previous research, 이 논문이 가지는 우위점, 핵심 아이디어, loss function, 실험 결과 등을 정말 빠삭하게 파악해야 한다. 논문의 모든 수식을 해석하며 이 수식이 왜 나왔을까, 어떻게 전개가 될까, 수학적으로 타당한가, 논문의 용어와 수식이 어떻게 연결이 되는가 등 평소에 내가 하던 것보다 더 꼼꼼하게 리뷰를 한다.

이렇게 꼼꼼하게 리뷰하면, 일단 자신이 생긴다. 면접에서 어떤 질문이 나올지 몰라서 불안해하지 않는다. 면접관보다 내가 이 논문을 더 빠삭하게 파악하고 있다고 확신이 들기 때문에 긴장하지 않는다. 그리고 실제로 질문들도 예상한 범위 내에서 나온다. 만약에, 다른 시각의 질문이 나와도 그 논문에 대해서 이해한 내용이 있기 때문에 어렵지 않게 답할 수 있다.

앞으로의 계획

다양한 유형의 면접을 보며 부족한 점을 정말 많이 느꼈다. 다음 이직 준비를 할 때 고생을 덜하기 위해서 내가 해야할 것들을 정리해봤다.

알고리즘 생활화

정말 중요한 부분이다. 아무리 AI가 코딩을 잘 한다고 해도, 개발자 채용 전형에서 코딩 테스트가 없어지기까지는, 시간이 오래 걸릴 것이라고 생각한다. 그런데 막상 알고리즘을 공부하면 감을 잡는게 너무 힘들다. 이 글을 쓰는 필자도 모든 면접이 끝나고 알고리즘을 놓은지 벌써 2달이 넘었다. 이러니, 그동안 리트코드에서 열심히 풀었던 유형이 잘 기억이 나지 않는다. 면접을 빡세게 준비하고 있었던 시기에는 '감을 잡았다' 라는 느낌이 많이 들었다. 이 느낌이 들기까지 워밍업을 하는데는 워밍업이 꽤 걸린다. 사실 이직 준비는 항상 되어 있어야 한다. 최근의 skt와 크래프톤의 희망 퇴직 소식을 접하면 남 이야기 같지 않기 때문이다. 이런 예상하지 못한 상황에서 바로 이직할 준비가 되어 있다면 얼마나 좋을까? 그 시작점이 알고리즘에 대한 감 유지하기라고 생각한다. 나는 이를 실천하기 위해 리트코드 1년치를 미리 결제하고 꾸준히 풀어볼 계획이다. 물론 매 문제를 풀 때마다 라코에 응시하고 있다는 생각으로 !

꾸준한 논문 읽기

기본 중에 기본이다. 새로 입사하는 포지션이 추천 ML을 다루기 때문에 공부량이 어마어마하다. 따라서 꾸준하게 논문을 읽으며 SoTA을 따라가고자 한다. 이에 더해서, 강화학습도 시간이 날 때마다 공부하여 llm쪽 트렌드도 팔로우만 하고 싶다. 워낙 llm 기반 기술이 많이 나오고 이쪽이 핫하다보니, llm 기술을 놓으면 안 된다는 생각이 자꾸 들기 때문이다.

Side Project: 모델 설계

지금도 잘하고 있는 부분이다. 추천 모델, gnn 모델, ctr/cvr 모델의 페이퍼를 읽고 프로그래밍까지 하여 벤치마크 데이터셋에 대해서 결과를 비교해볼 것이다. 면접을 보며, 단순히 실험을 설계하는 것보다는 실험 결과에 대한 해석이 중요함을 깨달았다. 코딩을 하며 이 부분도 함께 챙기고 틈날 때마다 블로그에 기록해두자.

Side Project: 실 데이터 활용

모두연에서 쩝쩝 프로젝트를 하며 다른 사람들과 협업하는 프로젝트의 소중함을 정말 많이 느꼈다. 혼자 모델을 설계하고 실험하는 것보다 협업하여 코드를 짜며 배우는 것도 정말 많았다. 또한 편협한 시각에서 자유로워져서 더 넓은 시야로 아키텍쳐를 설계할 수 있었다. 그리고 실 데이터는 사실 생각보다 많이 더럽기 때문에 벤치마크 데이터셋을 다루는 것보다 더 재미있다. 면접을 보며 면접관들도 내가 개인적으로 진행한 프로젝트보다 협업 프로젝트에 더 관심을 가졌다. 따라서, 쩝쩝 프로젝트가 마무리 되어도 나는 어디선가 또 다른 사이드 프로젝트를 진행할 것이다. 이렇게 포트폴리오를 계속 채워나갈 것이다.

시간이 된다면.. C 공부?

예전부터 C 언어에 대한 동경이 있었다. 얼마나 어렵길래 악명이 높은 걸까? 파이썬에 비해서 얼마나 빠른 것일까? 이런 궁금증들이 항상 있었다. 또한, 내가 이직할 직무가 모델의 latency가 매우 중요하기 때문에 파이썬을 사용하지 않을 수도 있다. 이런 상황들이 맞물려서, 시간이 된다면 C 공부를 해보고 싶어졌다. C, C++, Cuda? 사실 잘은 모르지만 한번 시도는 해보고 싶은 영역이다. 그리고 엔지니어의 길을 가기로 했으면 파이썬 이외의 다른 언어도 능통해야하지 않을까 싶다.

마무리

이 글을 쓰는 2025년 11월, IT 빙하기라 해도 과언이 아니다. skt, 크래프톤은 대규모 희망 퇴직을 권고했다. 열려있는 ML 포지션도 많지 않다. 채용을 동결하는 회사도 꽤 많다. 애초에 신입은 거의 뽑지를 않는다. 코로나 시기였던 2022년에 비해서 확실히 채용 시장이 좋지 않음을 피부로 느끼고 있다. 이 가운데에 이직에 성공한 것은, 개인적인 능력보다는 운이 더 크게 작용했다고 생각한다. 그러나 그 운은, 내가 지난 1년간 추천 ML 포지션이라는 명확한 목표를 준비했기 때문에 나에게 온 것이라고 확신한다. 운칠기삼, 진인사대천명. 내가 좋아하는 말이다. 일단 내가 할 수 있는 것들을 최선을 다해서 하자. 그리고 운이 나에게 오기를 기다리자. 운이 온다면 땡큐다. 운이 오지 않는다면, 슬프겠지만 그것대로 배우는 것은 있다. 최선을 다해 준비하면서, 면접을 떨어지면서 분명히 부족한 점을 깨달았기 때문이다. 이제 다음 운을 위해서 또 준비하면 된다.

 

정말 운이 좋게도 이번 이직은 좋게 마무리 할 수 있어서 감사할 따름이다. 다음 이직도 분명히 몇년 뒤에 하게 될 것이다. 그러나 일단 위에서 선언한 계획을 실행하는데 집중해보자. 여태까지 해왔던 것처럼 진득하게 앉아서 목표한 바를 하나씩 클리어하다보면 또 다른 이직이라는 운이 나에게 찾아올 것이라 확신한다. 시장이 많이 좋지 않은데 IT 엔지니어들 모두 빠이팅이다!