[How AI Lab Works] ML Application Team - Jack & Owen.L 인터뷰

“Your AI Algorithm, All over the World”

하이퍼커넥트®는 설립 초기부터 AI 기술과 인재에 대한 전략적인 투자로 독보적인 영상 기술을 개발해왔으며 현재 세계적인 AI 기술 선도 기업으로서 입지를 확고히 하고 있습니다. 하이퍼커넥트®에서 업계 최고 실력을 갖춘 동료들과 AI 알고리즘의 무한한 가능성을 함께 펼쳐나갈 인재를 찾습니다!

Interviewee
ML Application Team / Leader, Jack(염기훈)

ML Application Team / Machine Learning Software Engineer, Owen.L(이영수)

하이퍼커넥트® AI Lab에서 ML Application Team으로 일하고 있는 Jack과 Owen.L를 만나 이야기를 나눴습니다. 눈썰미가 좋은 분들이라면 연관 시리즈 인터뷰 대상이 Squad인 것과는 달리, 본 페이지 인터뷰는 Team 대상으로 작성된 점을 발견하셨을 텐데요. 다른 Squad와의 차이점을 밝히며, 다른 조직과의 잦은 협업으로 관련 업무 능력이 특히 중시되는 ML Application Team의 일하는 방식에 대해 소개합니다. 

Q. ML Application 팀은 어떤 일을 하는 조직인가요? 다른 스쿼드와의 차이도 궁금합니다.

Owen.L: 쉽게 말하면 AI 조직과 제품 조직 사이의 연결고리 같은 팀이라고 할 수 있어요. 보통 AI 조직에서는 머신러닝을 서비스에 녹이는 백엔드/데이터 엔지니어링을 포함한 구체적인 방법에 대해서 잘 모르고, 제품 조직에서는 AI를 모르는 경우가 많아요. 그 둘 사이를 이어주는 인터페이스를 설계하고 소프트웨어를 작성하는 일을 주로 합니다. ML Engineer가 새로운 머신러닝 모델을 만들고 나면, 해당 모델을 실제 서비스에 적용시키기 위해 API 서버를 개발하여 제공하는 업무가 대표적이라고 할 수 있죠. 이처럼 제품 조직과 AI 조직 사이의 사일로 문제를 해결하고, AI 기술이 실질적으로 서비스에 기여할 수 있도록 돕는 역할을 수행합니다.

아무래도 AI 인터페이스를 제품 조직에 제공하는 게 주요한 역할이다 보니, 주로 백엔드 개발 및 데이터 처리 애플리케이션을 개발하는 경우가 많아요. 하지만 꼭 업무를 백엔드에 한정 지어서 일하지는 않고, AI 기술을 서비스화 하는데 프론트엔드 기술이 필요하다면 프론트엔드 개발을 수행하기도 합니다. 작년에는 AI 조직 내에서 Generative AI 기술을 활용한 신규 프로젝트에 참여했는데요. 당시 해당 프로젝트에 참여한 프론트엔드 엔지니어가 없어서 저희 팀원 중 한 분이 직접 백엔드부터 프론트엔드까지 개발하기도 했습니다.

Jack: 하이퍼커넥트® AI 조직의 ML Engineer들은 스쿼드 형태로 일하고 있습니다. 그런데 저희 ML Software Engineer들은 스쿼드의 일원이 아니라 별도의 기능 조직(팀)으로 존재하는 이유에 대해 궁금해하실 것 같습니다. 이런 구조를 가지게 된 이유는 아무래도 모델을 서비스에 도입하는 관점에서 반복되는 사이클이 존재하거나, 비슷한 엔지니어링 작업이 생기는 경우가 많기 때문이라고 할 수 있어요. 소프트웨어를 개발하다 보면 아무래도 반복된 로직은 계속 생겨나기 마련이고, 이를 잘 추상화 해두며 재활용해야 결국 개발 생산성을 올릴 수 있거든요. 실제로 저희 팀에서는 매우 다양한 머신러닝 모델을 서빙하고 운영하고 있는데, 각 머신러닝 모델을 서빙할 때 필요한 공통 컴포넌트들은 팀 내에서 통합하여 관리하고 있습니다.

Q. 이야기를 들어보니 다양한 팀과 협업을 할 것 같아요. 어떤 팀과 협업하고 있으며, 또 어떤 방식으로 협업하나요? 

Jack: 네 맞습니다. 앞서 Owen이 말씀드린 것처럼 저희는 AI 조직과 제품 조직의 인터페이스 역할을 하고 있기 때문에 정말 다양한 팀들과 협업합니다. 

먼저 ML Engineer들이 속한 각 스쿼드와 가장 긴밀하게 협업하고 있어요. 일단 머신러닝 모델이 있어야 머신러닝 시스템을 구현할 수 있으니까요. 일부 비즈니스 로직을 구현하는 것도 저희의 업무 중 하나입니다. 특별히 언급하고 싶은 점은, 저희 팀은 매우 능동적으로 일한다는 거예요. 일반적으로 머신러닝 애플리케이션 구현이라고 하면 이미 개발된 모델을 받아서 수동적으로 처리하는 역할로 인식될 수 있는데요. 저희는 저희 팀의 역할을 여기에 한정짓지 않고 있어요. 효율적인 머신러닝 시스템 개발을 위해, 때로는 프로젝트 시작 단계에서부터 머신러닝 모델링에 직접적으로 관여하기도 합니다. 예시를 하나 들어볼게요. 저희의 몇몇 머신러닝 시스템은 짧은 시간(ex. 수십 밀리초) 안에 결과를 반환할 수 있어야 해요. 이런 시간 제약 조건을 맞추기 위해, 저희 팀도 적극적으로 모델 구조를 제안하고 ML Engineer들과 협의하고 있어요. 그리고 이렇게 협의된 결과를 전체 머신러닝 시스템 아키텍쳐에 반영해오고 있고요. 

ML Engineer와 함께 머신러닝 애플리케이션의 개발 단계 버전을 완성했다면, 인프라실의 DevOps 팀과 데이터 엔지니어링 팀과의 협업을 통해 프로덕션 레벨로 올리게 됩니다. 예상 트래픽을 고려해 인프라를 설정하고, 필요한 데이터가 원활하게 전달되도록 하죠. 실제로 저희 팀에서 운영하는 마이크로 서비스들은 전사에서도 가장 높은 트래픽을 받고 있는 것들이 많습니다. 안정적이고 효율적으로 시스템을 운영하기 위해 인프라 조직과의 긴밀한 협업이 반드시 필요합니다. 

이 밖에도 제품 조직과도 긴밀하게 협업하고 있어요. 우선 머신러닝 모델을 서비스에 반영하기 위해서 백엔드 팀과의 협업도 필요합니다. 또, 모델이 사용자에게 나가고 사용자의 피드백을 바탕으로 재학습되기에, 사용자 인터페이스를 개발하는 클라이언트 팀과도 협업하고 있죠. 클라이언트 팀과는 주로 사용자가 발생시키는 이벤트를 어떤 방식으로 전달할지에 대해 논의하는 편이에요. 프로덕트 매니저들과는 머신러닝을 이용한 기능 개발에 있어서 요구사항을 구체화 하면서 일하고 있고요. 이처럼 다양한 팀들과의 협업을 통해 머신러닝 시스템을 구현하고 안정적으로 운영하며, 머신러닝 시스템을 활용한 전체 서비스가 원활하게 동작할 수 있도록 지원하고 있습니다. 

Owen.L: 앞서 Jack이 저희가 ML Engineer와의 협업을 할 때 수동적인 역할만 하지 않는다고 언급했는데요. ML Engineer와 협업 시 저희의 역할을 조금 더 구체적으로 말씀드리고 싶어요.

저희 팀은 머신러닝 프로젝트의 시작뿐만 아니라 배포와 실험, 운영에도 많은 역할을 하고 있어요. 머신러닝 모델의 개발 이후에도 A/B Test, Shadow Test 등을 ML Engineer들과 같이 수행하고 있고요. 뿐만 아니라 하이퍼커넥트®는 AI를 활용한 서비스의 기능을 매우 다양하게 운영하고 있는데, 이들을 안정적으로 운영하고 모니터링하는 것도 저희의 역할이라고 할 수 있습니다. 

또, 저희는 머신러닝 모델을 활용한 기능들을 개발하는 것에 그치지 않고, ML Engineer들이 더 높은 생산성을 낼 수 있도록 지원하기도 해요. 반복적으로 수행되는 Toil]이 있거나, 머신러닝 모델의 학습 및 배포를 더 편리하게 할 수 있는 아이디어가 있다면 ML Platform 팀과 함께 머신러닝 플랫폼을 만들기도 합니다. 또, 좋은 엔지니어링 사례를 만들어 ML Engineer 조직에 공유하며 엔지니어링 퀄리티를 높이는 데에도 기여하고도 있습니다.

Q. 머신러닝을 서비스화 하면 어떤 것들이 특히 어려울지 와닿지 않는데요. 어려운 부분에 대해 말씀해 주세요.

Owen.L: 보통 연구실이나 또는 서비스화를 많이 고민하지 않는 회사에서 머신러닝을 한다고 하면 사실 이미 정해져 있는 것들이 너무나도 많은 것 같아요. 학습 데이터셋과 평가 데이터셋은 물론이고, 심지어는 어떤 문제를 풀어야 할지가 정해져 있기도 하고요. 하지만, 실제 서비스 레벨로 가면 정해진 게 단 하나도 없는 경우가 대부분이에요. 심지어 어떤 문제를 풀어야 하는지도 불명확한 경우가 많아요. 머신러닝을 서비스화 한다는 말은, 문제 정의부터 데이터 수집, 데이터셋 구축, 모델 개발, 모델 평가, 모델 배포, 시스템 개발, 지표 평가 등 거의 모든 일을 맨 바닥부터 수행해야 한다는 것을 의미합니다. 이 과정에서 필요로 하는 소프트웨어 엔지니어링 업무 역시 나열할 수 없을 정도로 매우 많습니다. 단적으로 데이터 파이프라인만 해도, 데이터 수집부터, 가공, 탈퇴한 사용자의 데이터 삭제까지 처리해야 할 정도로 신경써야 할 부분이 많고요. 

하이퍼커넥트®와 Match Group은 ‘사람과 사람을 연결하는’ 서비스를 운영하고 있어요. 이런 도메인에서의 머신러닝 문제는 다른 회사에서 겪는 문제들과는 또 다른 경우가 많아요. 물론, 다른 회사에서 사용하는 방식을 그대로 사용해도 어느 정도 성과는 나오겠지만, 그렇게 되면 최적이 아닌 방법(sub-optimal solution)으로 문제를 풀게 되는 셈이에요. 우리가 푸는 문제를 잘 정의하고, 해당 문제를 최적/효율적으로 풀 수 있는 머신러닝 시스템을 설계해야 한다는 점이 다른 어려운 점 중 하나라고 강조하고 싶어요.

Jack: Owen이 잘 설명해 주셨는데요. 머신러닝을 서비스화 할 때 어려운 점에 대해서는 이미 많이 알려져 있는 것 같아요. 대표적으로 'Technical Debt in Machine Learning System'이라는 아티클에서 여러 이슈들을 제시하고 있고, 머신러닝을 서비스화 하는 분들이라면 다들 공감하고 있을 거라고 보고요. 저희도 비슷한 어려움을 많이 겪었어요. 머신러닝을 서비스화 할 때 피하기 어려운 부분인 것 같습니다. 

일단 가장 먼저 생각나는 어려운 부분은 머신러닝 시스템으로 높은 트래픽을 처리하는 것이에요. 하이퍼커넥트®는 사용자 수가 방대한 서비스들을 운영하고 있고, 이 서비스들에서 동작하는 머신러닝 시스템을 만들어야 하기 때문에 머신러닝 시스템이 많은 양의 트래픽을 받을 수밖에 없어요. 그리고, 머신러닝 시스템에서 많은 양의 트래픽 처리는 일반적인 백엔드 시스템보다 더 어렵다고 느끼는데요. 왜냐하면 머신러닝 모델의 연산이 오래 걸리는 경우가 많아서, 다른 백엔드 시스템보다 상대적으로 높은 지연 시간이 발생하기 때문이에요. 사용자에게 더 좋은 경험을 제공하기 위해서는 대부분의 경우 모델의 크기가 커져야 하고, 모델의 크기가 커지다보면 연산량이 늘어나 지연 시간이 늘어나는 일이 흔해요. 머신러닝 시스템을 만들 때 이런 트레이드 오프를 고려해서 설계해야 하고, 때로는 엄격한 지연 시간을 맞추기 위해서 추가적인 엔지니어링이 필요해요. 이런 작업은 경험이 쌓여도 아직 어렵게 느껴지는 부분입니다. 

한 가지 더 꼽아보자면, 머신러닝 시스템을 설계하는 사람이 소프트웨어 엔지니어링과 머신러닝을 모두 잘 이해하고 있어야 한다는 점이 있어요. 엔지니어링을 잘 모르면 견고하면서도 확장 가능한 시스템을 설계하기가 어렵고, 머신러닝을 잘 이해하지 못하면 머신러닝 모델의 성능과 효율성을 최적화 하기가 어렵기 때문이죠. 이 둘을 모두 다 잘 이해해야 좋은 머신러닝 시스템을 설계할 수 있기 때문에 저희 팀은 양쪽 모두에 대한 노력을 지속할 것을 요구받습니다. 백엔드 엔지니어링은 노력을 해도 해도 끝이 없고, 머신러닝은 하루가 다르게 바뀌고 있어서 더 챌린징하다고 느끼는 것 같아요(웃음).

Q. 팀의 기술 스택에 대해 소개해 주세요. 

Jack: 주로 Python과 Kotlin을 사용하고 있어요. 백엔드 프레임워크로는 주로 FastAPI를 이용하고, 스트리밍 데이터 처리 프레임워크는 주로 Apache Flink를 이용합니다. 다만 JVM 생태계를 사용했을 때 더 유리하다고 판단되는 일부 프로젝트의 경우 백엔드에도 Spring으로 작성된 게 있기도 합니다. 마이크로 서비스는 쿠버네티스 위에서 관리되고 있고, 모델을 서빙하는 레이어는 Nvidia Triton을 활용하고 있어요. 또한 Kubeflow, Airflow 등을 통해 배치성 학습, 데이터 파이프라인을 관리하고 있습니다. 여기에 추가적으로 프론트엔드가 필요한 경우 React로도 개발하는 케이스도 종종 발생하고요. 다양한 기술 스택을 다루는 만큼 다양한 언어와 인프라를 빠르게, 잘 습득할 필요가 있는 것 같아요.

Owen.L: 특이한 부분으로는 저희는 회사 내에서도 가장 Python을 헤비하게 사용하고 있는 팀 중 하나인데, 가끔 Python으로 서버를 운영하고 있다고 하면 “Python을 프로덕션에서도 써요?” 라는 얘기를 듣기도 해요. 실상은 저희 팀은 정말 많은 서버를 Python으로 운영하고 있고, 트래픽도 상당히 많이 받고 있지만 아주 안정적으로 운영되고 있습니다. 물론 Python이 성능적으로 문제가 되는 경우도 있긴 하지만, 그럴 때는 다양한 방법으로 성능 튜닝 작업을 수행하면서 비즈니스 요구사항에 맞춰나가는 작업도 하고 있습니다. 더불어 동적 타입 언어의 한계를 극복하기 위해 모든 코드에 typing을 하도록 강제하고, CI 통과를 못하면 PR merge를 못 하게도 하고 있어요. (🔗참고: 고성능 ML 백엔드를 위한 10가지 Python 성능 최적화 팁, May 2023)

Q. 지향하는 개발 문화가 있으신가요?

Jack: 머신러닝 시스템은 일반적인 소프트웨어 시스템과 다르게 불확실성이 높아요. 예를 들어 새로운 머신러닝 시스템을 열심히 구현해도, 막상 실험 데이터를 분석해보면 우리가 원하는 효과가 달성이 안되는 경우가 많습니다. 물론 개선점을 찾아서 고쳐나갈 수도 있겠지만, 때로는 열심히 작성한 코드들이 안타깝게 사라지는 경우를 꽤 많이 경험했어요. 

그래서 저희는 더 빠른 배포 주기를 만들기 위해 노력하고 있어요. 최대한 작은 범위로 개발하고, 이를 통해 빠르게 이터레이션을 돌고 있습니다. 몇몇 작은 실험들을 통해 임팩트가 나올 수 있다고 판단되면, 견고하고 확장 가능한 시스템을 구축할 수 있도록 개발 자원을 더 할당하는 프로세스를 채택하고 있어요. 이런 방식을 통해 불필요하게 낭비되는 자원을 줄이고, 머신러닝 시스템으로 임팩트를 최대한 빠른 시간 내에 내고자 노력하고 있습니다.

Owen.L: Jack이 잘 말씀해 주셨지만, 제가 다른 방식으로 한번 더 강조하자면, ‘회사 비즈니스에 기여할 수 있는 코드를 작성하자’가 저희 팀의 개발 문화를 반영하는 핵심 문장이지 않을까 싶어요. 제가 하이퍼커넥트®에 들어온지 만 2년이 넘었는데요, 2년 동안 사라진 프로젝트도 옆에서 많이 보았어요(웃음). 머신러닝 프로젝트가 실험성인 경우가 많다는 것을 더 직접적으로 체감하고 있는 것 같아요. 보기에만 아름답고 실제로 회사에 기여를 하지 못하는 코드를 작성하지 않기 위해 팀 내에서도 챌린지를 많이 하고 있습니다. 어떻게 비즈니스에 기여할 수 있는 코드를 작성할지 고민을 더 많이 하게 되더라고요. 

기본적으로 이러한 철학을 가지고 있지만, 코드 퀄리티를 높게 유지하는 것 역시 너무나도 중요하게 생각합니다. 그런 만큼 팀 내에서 작성하는 모든 코드는 테스트 코드와 함께 작성되고 있으며, 코드 리뷰와 페어 프로그래밍 문화도 오랫동안 지속하고 있어요. 또한 머신러닝 시스템 특성상 복잡한 구조인 경우가 많기에, 문서화 하는 것도 중요하게 여기는 부분입니다. 하이퍼커넥트®에 오시면 방대한 테크스펙과 내부 세미나 자료에 놀라실 수도 있습니다! 

또, 다른 조직의 엔지니어들과의 협업을 통한 지식 교류도 아주 중요하게 생각해요. 아무래도 저희 팀이 머신러닝과 백엔드/데이터 엔지니어링을 포함해 다양한 기술 스택을 넘나들며 개발을 하게 되면 지식이 넓고 앝게 형성되는 문제가 생길 수 있어요. 저희는 이를 경계하며, 기술 동향을 유의깊게 살피고 깊은 지식을 유지하기 위해 노력하는 편입니다. 대표적으로 하이퍼커넥트®에는 ‘백엔드 당’ 이라는 것이 있는데요. 저희는 백엔드 직군이 아니지만 해당 당에서 열리는 백엔드 스터디에 참여하기도 했어요. 이에 그치지 않고 슬랙으로 새로운 기술이나 디자인 패턴에 대해 토론하는 스레드도 자주 열곤 하죠. 실제로 저희 팀에서 개발한 백엔드 시스템은 대부분 이벤트 지향 아키텍처로 설계되고 있고, 헥사고날 아키텍처를 사용하여 확장성 있는 구조를 가지고 있습니다. 더불어 분산 데이터베이스(ScyllaDB), 비동기 API, Change Data Capture(CDC), Avro, GRPC 등 de-facto standard가 되어가고 있는 디자인 패턴이나 기술을 다수 도입하고 있어요. 저는 백엔드 개발 만큼은 저희 팀이 다른 백엔드 엔지니어링팀과 비교해서 결코 뒤쳐지지 않는다고 생각합니다. 팀에서 여러 기술 스택을 다루고 있지만 결코 지식의 폭이 얕지 않고, 오히려 깊은 이해도를 기반으로 개발할 수 있도록 지속적인 발전을 지향하는 문화가 있어요. 

Q. 특히 기억에 남는 프로젝트가 있을까요?

Jack: 아자르 매칭 추천 시스템이 가장 기억에 남는 프로젝트이자, 가장 애정하는 프로젝트라 할 수 있을 것 같네요. 아자르는 1:1로 실시간 영상 채팅을 하는 서비스인데, 사실 예전에는 사용자를 매칭하는 알고리즘이 휴리스틱 기반으로 작동하고 있었어요. 그러다 최근에 저희 팀과 다른 ML Engineer들이 협업해서 아자르 매칭 알고리즘을 머신러닝 모델 기반의 추천 시스템으로 개선하는 작업을 진행했고, 좋은 성과를 보였어요. 실제 해당 프로젝트의 성과가 Match Group의 주주서한에 공개되기도 했구요!

머신러닝 기반의 아자르 매칭 시스템이 좋은 성과를 냈긴 했지만, 사실 그 도입 과정이 쉽지만은 않았습니다. 시스템에서의 응답 시간을 맞출 수 없다면, 머신러닝 모델이 아무리 좋아도 서비스에 도입할 수 없었거든요. 당시 저희 팀에서는 시스템 상 제약 조건들을 해결하기 위해 많은 실험을 진행하고 설계를 바꾸는 등 다방면으로 노력했어요. 제품 조직의 백엔드 엔지니어 및 SRE분들과도 수많은 토론을 거듭하고, ML Engineer들과도 논의를 통해 방법을 찾아 애썼습니다. 수많은 튜닝 과정과 로드테스트를 거친 후, 마침내 그 목표를 달성했던 순간이 가장 기억에 남습니다. (웃음)

Owen.L: 작년에 시작했던 프로젝트로 ‘Feature Store for ML’라는게 있습니다. 추천시스템에서 데이터를 더 쉽게 다룰 수 있게 해주는 플랫폼으로, DEVIEW 2023에서 연사로 선정되어 발표를 하기도 했어요! 피쳐 스토어는 ML Engineer들과 긴밀히 협업하면서 ‘추천 모델에서 한 개의 피쳐(feature)를 추가하는데 드는 엔지니어링 코스트가 너무 크다’는 문제를 바탕으로 시작했던 프로젝트인데요. 사내 사용 사례를 철저히 분석하며 만든 결과 지금은 AI 조직 전체에서 사용할 정도로 회사에서 매우 중요한 플랫폼이 되었어요. 피쳐 스토어는 이미 오픈소스로도 많이 나오고 있는 컴포넌트인데, 개발하기 전 다양한 오픈소스를 조사했던 기억이 아직 선하네요. 오픈소스 조사를 많이 했지만 당시엔 저희의 요구사항을 만족하는 오픈소스가 없어서 결국 직접 개발했는데, 지금은 매우 다양한 곳에서 사용하고 있으며 실제 트래픽도 사내에서 가장 높은 서비스 중 하나가 되어서 뿌듯한 감정입니다. (🔗참고: DEVIEW 2023: 실시간 추천 시스템을 위한 Feature Store 구현기 Feb, 2023) 

피쳐 스토어는 다량의 트래픽을 받을 뿐만 아니라 다량의 데이터까지 저장이 필요한 서비스였기에, 생각보다 챙길 게 매우 많은 프로젝트였어요. 실제로도 프로젝트를 진행하는 과정에서 DevOps팀과 협업하며 데이터베이스 선정부터 각종 인프라 세팅까지 긴밀히 협업하기도 하는 등 엔지니어링적으로도 꼼꼼히 대응했습니다. 이 프로젝트에서 특히 잘했다고 생각하는 부분은, 플랫폼만 만드는 것으로 끝나지 않고 실제 연동까지 챙기기 위해 노력한 점이에요. 프로젝트 초반에는 개발에 쓸 시간을 줄이고 일단 연동을 가장 중요한 목표를 가져갔어요. 이후에 연동되는 서비스들이 많아지고 나서야, 이후에 GitOps와 같은 기술을 도입하여 수동으로 운영하고 있던 부분 상당수를 자동화 했습니다. 향후 이 플랫폼을 더 잘 운영하기 위해 ML Platform팀과 협업해 개선해나가고 있습니다. 문제 정의, 효율적인 시스템 설계, 고객을 확보하기 위한 노력과, 마지막 자동화까지 지연없이 일이 착착 진행된 프로젝트여서 기억에 특히 더 남네요!

Q. ML Software Engineer는 어떻게 하면 될 수 있나요? 두 분은 어떤 커리어를 밟아오셨나요?

Owen.L: ML Software Engineer라는 포지션이 존재하는 회사가 국내외를 통틀어 많지 않은 것 같아요. 어떤 회사에서는 ML Engineer라는 포지션이 비슷한 업무를 수행하는 것 같기도 하지만, 해당 포지션은 저희만큼 백엔드를 포함한 소프트웨어 엔지니어링 스킬을 그렇게 깊게 요구하는 것 같지는 않습니다. 애초에 포지션 자체가 생소하기 때문에, ML Software Engineer라는 포지션이 되기 위해 별도의 노력은 필요 없다고 생각해요. 저희도 함께 하는 분을 모실 때 가장 많이 보는 것이 ‘러닝 커브가 가파른지’, ‘문제 해결 능력이 좋은지’입니다. 여기에 더해 아무래도 저희가 AI 조직 내에서 소프트웨어 엔지니어링, 그 중에서도 백엔드 개발을 많이 하니 머신러닝에 대한 이해도와 백엔드 개발 경험이 있으신 분들은 더 선호하기는 하고요.

저도 처음부터 ML Software Engineer라는 포지션을 목표로 공부해 왔던 건 아닙니다, 그 전에는 백엔드와 프론트엔드를 가리지 않고 소프트웨어 엔지니어링 스킬을 익혀왔어요. 저는 개발을 초등학교 때부터 시작했었는데요. 당시 저에게 프로그래밍은 원하는 것을 만들기 위한 (문제 해결을 위한) 수단일 뿐이었고, 백엔드냐 프론트엔드냐는 가리지 않았던 것 같습니다. 이런 백그라운드를 가지고 있어서인지, ML Software Engineer 라는 포지션이 잘 맞는 것 같아요. 다양한 기술 스택을 가리지 않고 습득해야 하고, 또 동시 매번 새로운 문제를 정의하고 해결해야 하는 일에 매력을 느끼며 재미있게 임하고 있습니다. 

Jack: 저는 다소 독특한 경로를 거쳐 ML Software Engineer가 된 케이스인데, 2016년 하이퍼커넥트®에 데이터 엔지니어로 합류한 꽤 초기 시절의 멤버였습니다. 그 당시 데이터 인프라 구축에 많이 참여하면서, 이 데이터를 활용해 비즈니스에 직접적인 영향을 미치고 싶은 마음이 컸어요. 당시 기회가 있어 아자르의 매칭(추천) 알고리즘을 만드는 팀에서 백엔드 엔지니어로 일하게 되었구요. 그렇게 몇 년간 아자르의 추천 알고리즘을 만들고 실험해왔죠. 알고리즘을 개발하면서 배워나가다 보니 깨닫게 된게 있어요. 바로 문제를 제대로 풀기 위해서는 결국 머신러닝 모델을 사용해야 한다는 점이에요. 짬짬히 AI 기술을 습득해 나갔고 이후 회사가 성장해 사내 AI 조직이 신설되었을 때 다시 기회를 잡아 현재 AI 조직에 합류했습니다. 지금은 제가 짰던 휴리스틱 알고리즘들을 머신러닝 모델로 교체하는 일을 하고 있어요(웃음). 이러한 과정을 통해 ML Software Engineer로 성장할 수 있었습니다.

글로벌 서비스에 머신러닝 시스템을 같이 만들어 갈 동료를 찾습니다!

📢하이퍼커넥트® AI/ML 직군 집중 채용!

[Your Algorithm, All over the World]
🌐 AI를 통해 실제 서비스의 성장과 비즈니스 임팩트를 만들고 싶다면,
🗺️ 풍부한 트래픽과 데이터를 기반으로 글로벌 유저의 사용자 경험을 혁신하고 싶다면,
👍탑티어 AI/ML 학회에 논문을 주기적으로 출판하는 국내 최상위 수준의 AI 조직에서 일하고 싶다면,

👉지금 바로 지원하기: https://career.hyperconnect.com/jobs
채용 공고에서 상세 내용을 확인해 주세요.