ML Engineer의 2025 이직로그 (1): 이직을 결심한 이유

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

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

2025년도 이제 두 달이 채 남지 않았다. 이직을 준비한지 꼬박 1년이 지난 시점이다.

작년에 추천 ML 분야로 이직을 결심하며 무작정 레포를 하나 파고 공부한 것을 코드로 남기기 시작했다.

https://github.com/bohyunshin/recommender

GitHub - bohyunshin/recommender: ML Models in Recommender System

 

 

본격적으로 개발한 시기가 작년 10월 쯤이다. 1월까지 개발하다가 그 이후로는 끊기는 듯 하지만, 협업 프로젝트에서 개발을 이어오고 있다. 그리고 그 1년 간의 노력과 준비는 원하는 직무로의 이직이라는, 좋은 결과로 마무리 되었다.

 

어느 블로그 글에서 본 적이 있다. 이직이라는 것은, 거주하고 있는 보금 자리를 옮기는 것과 같다고. 이 말에 공감한다. 이직이란, 적응이 끝난 현 직장의 따뜻함과 안정성을 뒤로 하고, 설렘과 두려움이 공존하는 환경으로 도전하는 것이라고 생각한다. 그렇다면 왜 굳이 이직을 하는가? 따뜻하고 안락한 곳을 포기할만한 동기가 있는가? 왜 위험을 감수하려고 하는가?

 

이직을 마무리한 이 시점에서, 이직을 결심한 이유부터 준비 과정, 여러 전형을 거치며 어떤 점들이 부족하다고 느꼈는지, 향후에는 어떻게 자기 개발을 할 것인지에 대해서 회고하는 시간을 가지려고 한다. 그 첫번째로, 내가 이직을 결심한 근원적인 이유를 글로 남기며 생각을 정리해본다.

현 직장에서 무엇을 개발했는가?

필자는 전세계 MAU가 1억명 이상인 서비스를 운영하는 회사에 재직 중이다. 개발자 입장에서 더 없이 좋은 조건의 회사이다. 활성 유저가 많은 만큼, 트래픽이 많이 발생하고 그 과정에서 배울 수 있는 것들이 많을 것이라 생각했다.

 

처음에는 SNS 서비스에서 어뷰저를 탐지하는 팀에 입사를 했다. 개발자로서 첫 커리어였다. 나는 학사/석사 모두 통계학을 전공했고 데이터 분석 및 모델링에 자신이 있었다. 무엇보다 이것들이 재미있었다. 이런 나에게, 실제 유저가 발생시키는 데이터를 분석하고 이를 통해 어뷰저의 패턴을 찾아내어 어뷰징 탐지의 규칙으로 만드는 업무는 정말 즐거웠다. 데이터 분석을 통해 도출한 인사이트가 서비스 유저의 클린한 사용 경험에 기여한다는 생각을 하며 나름 사명감 있게 업무를 했다.

 

하지만 행복은 오래 지속되지 않았다. 회사 내부 전략으로 인해 팀이 속한 프로덕트가 별도의 조직으로 분리 되었고 그 과정에서 어뷰징 탐지라는 업무도 함께 이관 되었다. 사실, 업무 이관은 팀이 속한 상위 조직의 사정, 당시 사내 분위기 등을 종합적으로 고려하여 결정 되었다. 개인적으로는 100% 이해가 되지 않았으나, 회사 내부 사정에 따른 상위 매니저 분들의 의사 결정이라고 이해했다. 그리고 그 결정을 존중했다.

 

이제 팀의 먹거리에 대해서 고민해야하는 시점이 왔다. 기존에 하던 업무가 이관 되었기 때문에 새로운 업무를 찾아야 했다. 팀이 원래 어뷰징 탐지를 했고 팀이 속한 상위 조직의 미션이 플랫폼을 만드는 것이었기 때문에 어뷰징 탐지 플랫폼을 만드는 쪽으로 프로젝트가 셋업 되었다. 어뷰징 탐지 플랫폼이란, 사내에 다양한 서비스를 운영하고 있는 부서들이 어뷰징 탐지에 대한 니즈가 생길 때, 자유롭게 이용할 수 있는 서비스이다. 서비스 유저가 아닌, 사내 임직원들을 대상으로 하는 프로젝트이다. 예를 들어서, 서비스 트래픽 시계열 데이터가 주어질 때, 시계열 모형을 통해서 spike 등의 특이 패턴을 찾고 이를 플랫폼 유저에게 알려주는 형태이다. 개인적으로, 프로젝트의 취지는 아주 좋다고 생각했다. 어느 서비스이든, 어뷰저는 반드시 존재하고 이를 잡아내는 것이 정상적인 유저의 서비스 이탈을 막을 수 있기 때문이다. 하지만, 이 플랫폼을 사용할 의사가 있는 부서를 찾는 것이 쉽지 않았다. 어떻게 보면 영업의 일종이다. 우리가 개발한 어뷰징 탐지 플랫폼의 장점을 어필해야하기 때문이다. 결국, 사내 사용처에 대한 부재로 인해 이 프로젝트는 종료 되었다.

 

다행히도 선물샵 서비스를 운영하는 부서에서 추천 서비스 개발이 필요하다는 연락을 주셨다. 그에 따라서, 추천 서비스 개발 프로젝트가 셋업 되었다. 이때, 추천 알고리즘 논문을 읽으며 밑바닥에서부터 공부를 했다. 그런데, 생각보다 너무 재미있었다. 누가 시키지도 않았는데 추천 논문을 읽고 위키에 정리했으며 퇴근 후에도 추천 논문에 푹 빠져 있었다. 다른 팀원보다 내가 읽고 정리한 논문의 수가 월등히 많았다. 왜 내가 이렇게 큰 흥미를 느꼈을까? 사실은 나도 잘 모르겠다. 추천 알고리즘이 나의 전공인 통계학과 많이 닮기도 하고 서비스에 붙어서 유저의 경험을 개선할 수 있다고 생각했기 때문인 것 같기도 하다. 아무튼 서비스 준비를 열심히 하고 있었는데 갑자기 연락온 부서에서 우선순위가 밀려서 추후에 필요하면 다시 연락을 주겠다고 했다. 결국, 이 프로젝트는 홀딩 되었다.

 

당시에 chatgpt가 세상에 처음 나오면서 굉장한 반응을 일으키고 있었다. 내가 속한 조직에서는 openai API을 활용해서 Official Account 챗봇을 만들었다. 구독료를 지불하면, 챗봇과 자유롭게 대화하면서 웹 검색, 파일 요약 등 다양한 서비스를 제공하는 형태이다. 기존에 서비스를 이용하던 유저들이 openai 어플을 깔지 않아도 서비스 안에서 AI을 사용할 수 있는 환경을 제공하는 것이 목표였다.

이때부터 유저 데이터에 기반한 모델 학습보다는 openai API을 활용하여 AI 서비스 개발을 하는 쪽으로 팀의 방향이 자연스럽게 설정 되었다. API의 성능이 워낙 좋아서 자연어 모델을 학습하는 것보다 그냥 비용을 지불하고 API을 사용하는 것이 회사 입장에서도 이득이기 때문이다. 개인의 말투를 챗봇이 따라하도록 프롬프트 튜닝을 하고, llm inference 최적화에 대해서 리서치도 했다. 그러나, 실제로 서비스에 적용된 내용은 없었다.

 

다만, 그 와중에 작은 ML 모델을 사용한 프로젝트를 진행했다. Extractive Summarization 개발 프로젝트이다. pdf 요약 API을 제공하고 있었는데, token limit을 채워서 openai API을 호출하다보니 비용 이슈가 발생했다. 비용을 절감하기 위해 1차로 핵심이 되는 문장을 뽑고 (Extractive) 뽑힌 문장으로 요약 (Summarization)하는 알고리즘을 개발하는 것이 목표이다. 이 프로젝트는, 개인적으로 몰입하여 진행한 업무 중 하나로 기억된다. 일단, 핵심이 되는 문장을 뽑기 위해서 문장을 랭킹해야 한다. 이때, 각자 ML 모델을 개발했다. 나는 PageRank, Grasshopper 모델을 개발했다. 나는 이것 이외에 전체적인 코드 아키텍쳐를 및 실험을 설계했다. 이를 통해 다른 팀원 분들의 빠른 실험 결과 도출에 기여했다. 결과적으로 내가 개발한 랭커 모델이 가장 우수한 성능을 보여서 최종 모델로 선택 되었다. 많은 실험을 하고, 결과를 분석하며 ML 모델을 개발한 이유일까. 다른 업무에 비해서 기억에 남는 프로젝트 중 하나이다.

 

llm API의 성능이 워낙 좋다보니, 덩달아 RAG 분야도 주목을 받기 시작했다. 고정된 답변을 제공하는 전통적인 챗봇에 비해 RAG 기술을 사용함으로써 더 정확한 답변을 제공하는, 유연한 챗봇을 개발할 수 있기 때문이다. 이런 흐름에 따라서, 고객센터 챗봇을 개발하는 프로젝트에 참여했다. 사실, 이 프로젝트는 내가 속한 팀이 처음부터 개발한 것이 아니고 개발 중간에 참여했다. 그러다보니, 팀에서 원하지 않은 방향으로 이미 프로젝트가 많이 진행되어 있었고 릴리즈 날짜는 정해져 있었다. 프로젝트에 합류한 후에, 많은 한계 및 문제점에 대해서 지적했으나 픽스된 릴리즈 날짜로 인해서 울며 겨자 먹기로 릴리즈할 수밖에 없었다. 결과는 예상할 수 있듯이 실패. 고객센터 챗봇 서비스는 그렇게 fade out 되었다.

 

팀에서는 이런 실패를 발판 삼아 RAG 플랫폼을 개발하자는 의견이 모아졌고, 프로젝트로 셋업 되었다. 어뷰징 탐지 플랫폼과 비슷하게 이 프로젝트도 RAG 플랫폼을 개발하는 것이 목적이다. 즉, 사내에 RAG 기술이 필요한 어느 부서이든 가져다 사용할 수 있는 형태로 개발해야 한다. 이전 프로젝트에서 한번에 RAG을 서비스하려다가 실패한 경험을 했기 때문에, 차근차근 개발하기 위해 먼저 검색 시스템부터 철저하게 구축하기로 했다. Indexing - Retrieval - Reranking으로 이어지는 파이프라인을 개발했다. 이 시스템을 임직원들의 문의 사항을 해결해주는 사내 챗봇에 적용했고 여태까지 잘 서비스가 되고 있다. 다만, 이 프로젝트도 회사 전략에 따라서 다른 팀으로 이관 되어서 현재는 운영만 하는 중이다.

 

현재는 최근 메세지 기반으로 유저에게 다양한 서비스를 openai API을 사용하여 개발하고 있다. 메세지 추천, 메세지 톤 변환, 검색 쿼리 추천을 팀에서 담당하고 있으며, 그 중에 나는 검색 쿼리 추천 서비스를 개발하고 있다. 최근에는 프롬프트 튜닝 및 평가의 파이프라인을 설계하고 있다.

어떤 업무가 기억에 남는가?

개인적으로 일은 재미있어야 한다고 생각한다. 앞으로 20년은 더 해야하기 때문이다. 데이터를 분석하고 모델링하는 것이 재미있기 때문에 ML 커리어를 선택했다. 그렇다면, 만 4년에 걸쳐서 업무를 하며 재미있었고 또 기억에 남는 업무는 무엇인가?

 

RAG 플랫폼 개발 프로젝트 > Extractive Summary 개발 프로젝트 > 어뷰징 탐지 업무 > 기프트샵 추천 서비스 설계 PoC

 

애착이 가는 프로젝트는 위의 순서대로이다. 위 프로젝트의 공통 키워드는 ML 및 데이터 분석이다. 그렇다. 나는 ML을 개발할 때, 몰입하여 일을 할 수 있고 더 주체성을 가지고 일을 하는 성향을 가진다. 

Data Scientist or ML Engineer?

나의 정체성은 무엇인가? 데이터 과학자인가, 아니면 ML 엔지니어인가? 솔직히, 내가 해온 업무를 봤을 때, 그 어디에도 속하지 않는다고 생각한다. 둘 중에 ML 엔지니어에 조금은 더 가깝다고 생각한다. 작은 ML이라도, 이 기술을 서비스에 적용하기위해 엔지니어링적으로 고민을 많이 했기 때문이다. 이런 관점에서 (ml - 대문자는 아니고 소문자) Engineer라는 정체성을 가지고 있다.

 

그렇다면, 앞으로 나는 어떤 방향으로 나아가야할까? 사실, 이미 답은 마음 속에 가지고 있다. ML Engineer 커리어를 쭉 가져가고 싶다. ML Engineer 커리어를 가져가기 위해 어떤 역량이 필요할까?

일단, ML Engineer는 알고 있는 ML 지식을 활용해서 비즈니스의 문제를 푸는 능력을 가져야 한다고 생각한다. 아무리 fancy한 ML 지식을 알고 있어도, 비즈니스의 문제를 정의하고 ML을 대입할 수 없으면 아무 소용이 없기 때문이다. 차라리 연구자의 길을 가는 것이 더 나을 수도 있다. 연구자의 길을 폄하하는 것이 아니다. 연구자들을 통해 현업의 엔지니어들은 문제를 풀 수 있는 실마리를 얻기 때문이다. 그러면 비즈니스에서 풀어야 하는 문제는 어떤 형식으로 주어지는가? 만약에 담당하고 있는 서비스가 있다면, 유저들이 생산하는 데이터를 분석하여 문제를 정의할 수 있다. 또는, 담당하는 서비스가 없지만 타부서에서 문제 해결을 위해 상담을 받을 수 있다. 예를 들어서, 타부서에서 개인 정보 처리에 대한 니즈가 있다면, 이를 위한 자연어 처리 모델을 개발한다. 현재 내가 속한 부서에서 위와 같은 업무를 통해 ML을 활용한 문제 해결 역량을 기를 수 있는지 돌아봐야 한다.

나는 어떤 문제를 해결하기 위한 알고리즘을 탐구하는 것을 좋아한다. 그 알고리즘이 왜 나왔는지, 어떤 기술을 보완하기 위해 연구되었는지, 선행 기술은 무엇인지, 작동 원리는 무엇인지, 수학 수식은 어떻게 표현 되는지, 시간 복잡도는 무엇인지, 실험 결과는 어떤지, 한계는 무엇인지 탐구하는 것을 사랑한다. 그리고 이것은 내가 잘하는 것 중에 하나이다. ML Engineer는 이러한 리서치 역량도 필수적으로 가져야 한다고 생각한다. 리서치를 하지 못하면 사실 모델을 가져다 쓰는 평범한 개발자와 크게 다르지 않다. 

ML Engineer에서 Engineer라는 용어는 무엇을 의미하는가? ML Engineer는 모델을 설계하고 이 모델을 서비스에 사용하기 위해 엔지니어링 측면도 함께 고려한다. 실용적인 측면도 고려하는 것이다. 가령, 모델 추론의 시간 복잡도는 무엇인지, 입력이 커짐에 따라서 추론 속도가 어떻게 변화하는지, 추론 API을 설계할 때 비동기 프로그래밍은 잘 구현이 되었는지, GPU을 사용한다면 OOM이 발생하지 않도록 설계를 잘했는지 등을 고려해야한다고 생각한다.

사실 이렇게 적어보니, 올 라운더의 성격이 강하게 느껴진다. 비즈니스의 문제를 스스로 정의하고 해결하기 위해 리서치부터 엔지니어링까지, 문제 해결을 위한 전 과정을 함께하는 듯하다. 그런데, 내가 하는 일이 이렇게 비즈니스와 밀접하게 붙어있다면 일을 하는 것이 재미있을 것 같다. 그리고, 앞으로 쭉 10년 넘게 해도 지루하지 않을 것 같다. 적어도 지금은 그렇게 생각한다. (나중에는 어떻게 바뀔지 모름ㅋㅋ)

현 직장에 만족하는가?

내가 원하는 커리어는 ML Engineer이고 내가 생각하기에 필요한 역량을 정리했다. 현 직장을 계속 다닌다면, 내가 생각하는 ML Engineer의 역량을 100% 채울 수 있을까? 1년 전에도, 그리고 글을 적는 지금도 여전히 의문 부호를 가지고 있다. 따라서 이직은 나에게 있어서, 내가 원하는 커리어를 이어나가기 위한 필수 단계로 느껴졌다. 이런 생각을 하니, 현 직장이 더 이상 따뜻하게만은 느껴지지 않았다. 어쩌면 안락한 기분 때문에 내가 정말 원하는 것이 무엇인지 고민하지 않을 수도 있지 않을까.

현 직장에서 무엇을 배웠는가?

현 직장에 코딩을 모르는 통계학도로 입사한 나는, 코딩의 ㅋ은 아는 상태로 성장했다. 지금와서 생각해보면 IT 회사이다보니, 코딩 문화가 다른 회사에 비해 정말 잘 정착이 되어 있다고 생각한다. 이러한 문화에서 개발했기 때문에, 다른 회사에 가서 입사한 팀의 소스 코드는 디버깅을 하며 100% 이해할 자신이 생겼다. 즉, 코드를 작성하는 것 뿐만 아니라 타인의 코드를 읽고 이해하는 능력이 생겼다. 이 능력은 어디 가서 돈 주고도 배울 수 없는, 아주 소중한 자산이라고 생각하며 현 직장에 대해 감사한 마음을 가지고 있다.

또한, 엔지니어링 성격이 강한 업무를 해오며 단순하게 pytorch 모델만 설계할 때는 고려하지 않은 것들을 고민하며 크게 보는 시각이 생겼다. 예를 들어서, 모델 추론 api을 개발할 때, 비동기 프로그래밍으로 구현하지 않으면 api 병목 현상이 일어나서 tps가 떨어질 것이라는 것, 외부 io를 타는 코드에서는 비동기 프로그래밍으로 구현해야 await하는 동안 다른 작업을 concurrent하게 수행할 수 있다는 것, 외부 api 호출을 할 때 retry을 통해서 최대한 결과를 보장하는 것 등 서버 개발자 분들과 일하지 않았으면 쌓이지 않았을 내공이라 생각한다. 내가 리서처의 길이 아닌, ML Engineer의 길을 가고 싶기 때문에, 이런 경험은 나에게 분명 매우 소중한 자산이 될 것이다.

알을 깨고 나올 차례

메타인지가 되었으니, 안락한 알을 깨고 나올 차례이다. 다음 포스팅에서는 알을 깨기 위해 어떤 준비를 했는지 상세하게 살펴보겠다.