커피챗이나 면접 자리에서 종종 받는 질문입니다. 제가 늘 드리는 대답은 이렇습니다.
"충분히 가능합니다"
Hyperconnect AI에서는 지금까지 어떤 분야를 해왔는지는 크게 중요하게 보지 않습니다. 그것보다는 지금까지 경험으로 보았을 때, 우리가 회사에서 풀어야 하는 문제를 풀 수 있는 역량이 갖췄는 지를 더 중요하게 봅니다.
더 구체적으로 말씀드리면, Hyperconnect AI는 적어도 한 개의 ML 분야를 깊이있게 파 본 경험이 있는지를 매우 중요하게 봅니다. 아주 좁은 분야라도 깊이 파본 경험은 새로운 분야에 대해서도 깊이 있게 다룰 수 있다는 강력한 신호라고 보기 때문입니다. Hyperconnect AI의 업무 특성 상, 외부에서 누군가 공개한 솔루션으로 해결되지 않는 문제들을 다뤄야 하는 경우가 대부분입니다. 해결하기 버거워보이는 장애물을 만났을 때 그 어려움을 해결해본 경험이 있는지, 해결하기 위해 어떤 시도와 노력을 해보셨는지를 매우 중요하게 보고 있고, 이 경험을 가지신 분들이 회사에 오셔서 좋은 성과를 내시는 경우가 많았습니다.
이런 맥락에서, 박사 과정을 밟은 분들이 상대적으로 유리한 점이 있습니다. 박사 과정은 보통 한 분야를 오랫동안 깊이 파야 하니까요. 하지만 꼭 박사일 필요는 없습니다. Hyperconnect AI에는 박사가 아닌 분들도 많고, 심지어 대학 학위 없이도 탁월한 성과를 내는 경우를 자주 목격했습니다.
저희 Hyperconnect AI에서는 프로덕트 조직과 함께 YoY 매출 30% 개선이라는 큰 성과를 낸 적이 있고, 그 이후로도 여러 비즈니스 성과를 내고 있는데요. 추천을 담당하는 리서쳐 중 단 한 분도 저희 회사 이전에 추천 경험을 갖고 계시지 않습니다. 결국 중요한 건, 후보자께서 다룬 분야가 무엇이었느냐가 아니라 얼마나 깊이 있게 파봤느냐입니다.
연구자 입장에서 가장 중요한 인프라 중 하나는 GPU입니다. 빠른 이터레이션과 대규모 모델 학습을 위해서는 강력하고 안정적인 계산 자원이 필수적이죠. Hyperconnect는 A100, H100을 비롯해 수백 대의 GPU를 on-prem에서 직접 운영하고 있습니다. 저희는 그간의 탄탄한 비즈니스 임팩트를 바탕으로, 계산 자원에 대한 예측에 따라 적절한 투자를 집행해 왔습니다. 뿐만 아니라, GPU가 추가적으로 더 필요할 경우 클라우드에서도 사용할 수 있기 때문에 실제 연구자가 활용할 수 있는 GPU 자원은 더욱 풍부합니다.
저희 Hyperconnect AI의 연구 조직은 1팀으로 구성되어있을 정도로 크지 않기에 연구자 1인당 활용 가능한 계산 자원이 충분히 여유롭습니다. Hyperconnect AI에서는 GPU 활용을 위한 별도 결재 프로세스는 필요하지 않습니다. 연구자는 바로 연구에 몰입할 수 있습니다. 연구자들 간 GPU 수요에 혹시라도 충돌이 생기면 회사 차원의 우선순위를 보고 조정하거나 앞서 말씀드린 대로 클라우드를 사용하는 방향으로 연구자의 생산성을 극대화하기 위한 노력을 아끼지 않고 있습니다.
또한, GPU를 운영하는 ML Platform 팀이 별도로 존재하고 연구자들의 생산성을 높이기 위한 여러 작업들 지원들도 같이 이 팀에서 병행하고 있습니다. 연구에 몰입할 수 있는 환경을 제공하는 것이 저희가 가장 중요하게 생각하는 부분 중 하나고, 연구자의 생산성이 곧 서비스와 기술 경쟁력으로 이어지기 때문입니다.
저희 Hyperconnect AI는 풍부한 계산 자원에서 비즈니스에 임팩을 내는 AI 연구를 하고 싶은 분들을 적극적으로 찾고 있습니다!
하이퍼커넥트 AI에서 ML Research Engineer를 모집할 때 가장 많이 받는 질문 중 하나입니다. 이 질문은 특히 대학원 경험이 있는 분들이 자주 하십니다. 사실 저도 대학원에 가기 전에 비슷한 질문을 했습니다. 연구실에 지원하기 전에 “이 연구실은 논문 작성과 과제의 비중이 몇 대 몇인가요?”라고 선배들에게 물어보곤 했거든요. ‘과제’라는 단어만 ‘엔지니어링’으로 바뀐 것이 지금의 이 질문이라고 생각합니다.
그럼 왜 이런 질문을 할까요?
돌아보면, 저 역시 그렇게 질문했던 이유는 단순했습니다. 과제를 잡일로 치부했기 때문입니다. 대학원을 졸업하려면 논문을 작성해야 하기에 대학원 생활에서 집중해야 하는 일은 논문 작성인데 반해, 과제는 월급을 받기 위해 어쩔 수 없이 해야 하는 일이었고, 내 졸업에 직접 도움이 되지 않는다고 여겼기 때문입니다. 그래서 저 역시도 자연스럽게 과제가 적은 연구실을 선택했고요.
그런데 왜 과제를 하기 싫었을까?
저는 리서쳐라면 누구나 문제를 스스로 정의하고, 그것을 가장 잘 풀 수 있는 방법으로 해결하고 싶어 한다고 생각합니다. 그런데 대학원에서의 기업/국가 과제는 제가 느끼기엔 주어진 문제를 적당히 풀고 넘어가면 되는 경우가 많아 보였습니다. 혹은 문제가 충분히 챌린징하더라도 그 안의 여러 제약 조건들이 잘 납득되지 않아 동기 부여가 쉽지 않아 보이기도 했습니다.
다시 돌아와서, “연구와 엔지니어링의 비중은 몇 대 몇인가요?”라는 질문을 생각해보겠습니다. 저는 이게 right question이 아니라고 생각합니다.
연구와 엔지니어링은 본질적으로 나눌 수 있는 것이 아닙니다. 연구란 곧 문제를 푸는 과정이고, ML Research Engineer의 모든 업무는 문제를 푸는 전 과정입니다. 문제를 풀기 위해 엔지니어링이 필요하다면 엔지니어링을 해야 합니다. 어떤 경우에는 다른 리서처나 소프트웨어 엔지니어에게 맡길 수도 있겠죠. 중요한 것은 상황에 맞게 문제 해결을 위해 가장 필요한 것을 하는 것입니다.
결국 본질은, 문제를 푸는 사람이라면 주어진 순간에 무엇이 문제 해결에 가장 중요하고 효과적인지를 고민하고 실행해야 한다는 것입니다. Hyperconnect AI에서는 문제를 스스로 정의하고 가장 최적의 방식으로 해결하는 역량을 ML Research Engineer의가장 중요한 역량으로 보고 있습니다.
CS 전공이 아니신 분들이 종종 제게 이런 질문을 하곤 합니다. 저 역시 전자과 출신이라 그 고민이 낯설지 않습니다. 실제로 엔지니어링 역량은 저희 회사 내에서도 연구자마다 편차가 크고, 해가 갈수록 면접을 보는 연구자 후보자들의 엔지니어링 역량이 약해지는 것도 관찰하고 있습니다.
하지만 Hyperconnect AI에는 이런 환경을 보완해주는 ML Software Engineer들이 따로 있습니다. 모델 서빙, 데이터 파이프라이닝, 모델 최적화 등을 담당해주시는 직군이며 연구 생산성에 문제가 생기면 도와주시기도 합니다. 제품에 ML을 제대로 쓰다보면 고민할 수 밖에 없는 feature store 등도 MLSE 분들이 만들고 이를 통해 ML Research Engineer들은 생산성을 올립니다.
ML Research Engineer는 엔지니어링을 A-Z로 할 필요가 없습니다. 저는 더 중요한 것은 소프트웨어 엔지니어링 역량을 높이 갖춘 MLSE들과 협업할 수 있을 정도의 엔지니어링 이해도라고 생각합니다. 예를 들어, 추천 모델의 레이턴시가 문제가 된다고 해봅시다. 연구자가 너무 엔지니어링을 모르면 단순히 모델 사이즈를 줄이는 방향과 Quantization 등만 생각하게 됩니다. 하지만, 연구자가 문제를 해결할 수 있을 정도로 엔지니어링을 이해하고 있다면 추천에서는 이미 표준과 같이 되어버린 투타워 구조를 제안하고 오래 걸리는 연산과 빠르게 되는 연산을 나눌 수 있어야 합니다. 이런 수준의 엔지니어링 역량은 연구자에게 반드시 요구됩니다.
시스템 프로그래밍을 깊이 알 필요는 없습니다. 하지만 모델링을 시스템의 제약 조건과 연결 지어 사고할 수 있는 능력은 필수적입니다. 결국, 좋은 성과는 “내가 다 한다”가 아니라 “동료와 함께 문제를 풀 수 있는가”에서 시작합니다. 결론적으로, 엔지니어링 역량에 완벽한 자신이 없어도 괜찮습니다. 협업할 만큼의 이해도와 열린 태도가 있다면 충분히 좋은 성과를 낼 수 있습니다. 저희 팀에도 처음 오실 때는 엔지니어링에 자신이 별로 없으셨지만, 높은 커뮤니케이션 역량과 추상화된 사고로 좋은 성과를 내시는 연구자분들이 많이 계십니다.
Hyperconnect AI 조직에서는 후보자의 논문 실적을 사실상 거의 보지 않습니다. 이 부분이 AI 리서치 포지션을 준비하시는 분들과 가장 큰 간극이라고 생각합니다. 많은 분들이 논문 실적이 중요한 평가 기준일 거라 생각하시지만 실제로는 그렇지 않습니다.
물론 전혀 의미가 없는 것은 아닙니다. 지원자가 어떤 사람인지 알 수 있는 단서가 전혀 없을 때 참고할 순 있습니다. 예를 들어 석사 과정 중 다른 지원자들 대비해서 많은 수의 논문을 썼다면 성실함을 엿볼 수 있고, NeurIPS, ICLR, ICML 같은 학회 논문은 후보자의 이론적 역량을 짐작할 수 있으며, CVPR을 비롯한 몇몇 학회들의 논문이 있다면 후보자가 성능 좋은 모델을 만들 수 있음(SotA를 어떻게든 찍을 수 있음)을 추정할 수 있습니다. 다양한 사람들과 공동 1저자로의 논문 작성 경험이 많다면, 협업의 경험이 많으니 협업을 잘할 것으로 예상해볼 수도 있습니다.
하지만 대학원을 마치고 회사에서 업무 경험이 있으신 분이라면 상황이 달라집니다. 그때부터는 어떤 일을 했는지, 그 일이 회사 비즈니스와 어떻게 연결되는지를 아는지, 만들어내신 솔루션이 정말 최선의 접근이었는지가 더 중요해집니다. 회사에서 논문을 쓴 경험이 있다면, 더 깊이 있게 여쭤보게 됩니다. 논문이 회사 제품에 어떻게 연결이 되는지, 논문 쓰는 과정은 어땠는지 등이 평가 포인트로 추가되고요.
결국 중요한 것은
1. 회사의 비즈니스에 가장 큰 임팩트를 줄 수 있는 문제를 정의할 수 있는지 (여러 문제들 중에 그 문제가 중요함을 설득할 수 있는지)
2. 그 문제를 풀 수 있는 다양한 솔루션들 중에 가장 최선의 솔루션을 디자인할 수 있는지
입니다. 이 두 가지 역량은 꼭 논문으로만 볼 수 있는 건 아닙니다. Kaggle과 같은 AI Competition 수상경력이나 사이드 프로젝트 경험 등으로도 이런 역량들을 엿볼 수 있습니다.
만약 후보자님께서 논문만 가지고 계시다면, 저희는 그 논문에서 푸는 문제를 어떻게 발견했고 진짜 중요한 문제인지를 체크합니다. 그리고 그 문제를 풀 수 있는 다양한 방법들 중에 제시한 방향이 합리적이라고 설득력 있게 이야기할 수 있는지를 봅니다. 이런 능력을 갖고 있으면 회사에서 중요한 비즈니스 문제를 찾고 해결책을 내는 능력을 갖고 있다고 볼 수 있기 때문입니다.
저는 저희 조직에 오고 싶은 분이라면 논문 실적에 신경쓰기보다는 회사에 비즈니스적으로 어떤 기여를 할 수 있는지 고민하시기를 권장드립니다. 본인의 만든 결과물이 회사에 어떤 임팩트를 가져왔는지를 정량적으로 설명할 수 있어야 합니다. 당연히 가정이 많이 들어갈 겁니다. 하지만 결과물을 비즈니스 지표로 치환하는 과정은 반드시 필요합니다.
다시한번 강조하자면, 저희는 논문 실적을 그리 중요하게 보지 않습니다. 스스로 중요한 문제를 찾아내고, 여러 방법을 고민해본 뒤 최선의 방법으로 풀어낸 경험이 있는지입니다. 저희는 그 확률이 높은 분을 뽑고 싶습니다.
제품에 기여하는 AI 조직에서는 연구가 반드시 필요합니다. 특히, 업계를 리딩하는 제품을 운영하는 회사라면 벤치마크할 회사가 없기 때문에 더 깊이 있는 연구가 필요합니다. 비즈니스와 잘 정렬된 문제를 찾았다면 성능을 극한으로 끌어올리기 위해 연구를 해야 하고, 아직 비즈니스와 잘 정렬된 문제를 못찾았다면 비즈니스와 정렬된 문제를 찾기 위해 연구를 하거나 직관을 통해 좋은 문제를 찾아야 합니다. AI 조직이 성숙해질수록 연구의 비중이 늘어나야 합니다. 현재 Hyperconnect AI 조직은 이 관점에서는 꽤 성숙한 조직이라고 판단합니다. 깊이 있게 문제를 풀고 창의적인 솔루션을 내며 비즈니스 임팩트를 내고 싶은 분들을 모시고 있습니다. 연구에 대한 자세한 제 관점이 궁금하시다면, 이 글을 참고해주세요.
탁월한 성과는 탁월한 조직에서 나온다고 믿습니다. 그래서 저는 늘 최고의 인재를 모으는 데 관심이 많습니다.
아쉽게도 채용 프로세스는 너무 짧습니다. 몇 시간 안에 후보자가 우리 팀에 적절한지 아닌지 판단해내야 하죠. 불확실성이 높은 선택일 수 밖에 없고, 따라서 저는 채용 결정을 프리시전과 리콜 관점에서 생각하게 됩니다.
리콜을 올리면 채용이 비교적 쉽습니다. 하지만, 저희 팀은 프리시전을 더 중요하게 여깁니다. 판단하기 애매하면 항상 채용하지 않는 쪽으로 결정해왔습니다. 그렇기에 돌아보면 좋은 분들을 아쉽게 놓쳐왔다고 생각합니다.
하지만, 그럼에도 불구하고 현재 채용 기조를 변경할 생각은 전혀 없습니다.
쉽게 팀에 들어온 사람과 일하고 싶어하는 탁월한 인재는 거의 없습니다. 우리가 리콜을 올리기 위해 바를 낮추면 기존에 팀에 있던 탁월한 인재들의 리텐션에 문제가 생깁니다. 인재밀도가 낮아지고, 낮아진 인재밀도는 의도치 않은 문화를 만듭니다. 좋은 분을 모시는 것보다 기존에 팀에 있는 좋은 분들이 오래 회사에 만족하며 다니시는 것은 더 중요하기에 사람을 채용하는 데 항상 신중하게 됩니다.
당장의 인력 부족으로, 급하단 이유로 프리시전을 희생하지 않습니다. 일이 많으면 현재 어떤 일을 미룰 수 있는지 의사 결정하고 일을 줄입니다. 분명 조직엔 미뤄도 되는 일들이 꽤 있습니다. 매니저는 팀에 부하가 커지면 적극적으로 이런 일들의 우선순위를 낮춰 채용에서 팀이 프리시전을 희생하지 않게 합니다.
저희 조직은 채용 바를 계속 올리고 있습니다. 기존 팀원들이 팀에서 역량이 향상되는 만큼 새로이 들어오는 팀원들도 그에 맞는 역량을 갖춰야 합니다. 저희 면접관들은 입을 모아 말합니다.
지금 내가 면접을 보면 통과할 수 있을까?
좋은 현상입니다. 지속적으로 바가 올라가야 탁월한 인재들로 구성된 팀이 되고, 그래야 탁월한 인재들이 오고 싶어하는 팀이 되는 선순환 구조를 만들 수 있습니다.
Hyperconnect AI는 탁월한 팀원들이 모인 탁월한 조직을 지향합니다. 이 여정에 함께할 분들을 기다리고 있습니다.
당연히 딥러닝을 주로 다룹니다.
그렇지만 Hyperconnect AI에서는 딥러닝이란 표현보다는 머신러닝 이라는 표현을 주로 사용하고 있습니다. 다들 아시는 것처럼 머신러닝이라는 큰 범주 안에 딥러닝이 포함되죠.
저희가 주로 딥러닝을 주로 다루고는 있지만, 리서처라면 필요에 따라서 딥러닝이 아닌 머신러닝 모델들을 다룰 줄 알아야 합니다. 딥러닝은 비싼 도구입니다. 강력하지만 그만큼 비용이 높고, 많은 데이터를 필요로 합니다. 그런데 현실적으로 항상 충분한 데이터가 있는 것은 아니죠. 문제에 따라 딥러닝이 오버엔지니어링일 수도 있습니다.
그래서 중요한 건 ‘딥러닝을 쓰느냐’보다 ‘문제를 어떻게 풀 것이냐’입니다. 상황에 따라 고전적인 머신러닝 모델이나 다른 접근이 딥러닝보다 훨씬 효율적일 수도 있습니다. 때로는 first-order logic 같은 전통적인 AI 기법이 도움이 될 때도 있고요. 적어도 어떤 툴들이 있는지는 알아두고 당장은 다룰줄 모르더라도 필요할 때 배워서 쓸 수 있는 역량은 갖추어 두어야 합니다.
딥러닝만 다룰줄 알면 모든 문제를 딥러닝으로 보고 풀게됩니다. 내가 망치를 들고 있으니 모든 문제가 못으로 보이는거죠. 그러면 안됩니다. 문제와 맥락에 맞는 모델을 구현해서 비즈니스 임팩트를 내는 것이 리서처의 책무입니다.
저희 팀에서는 적어도 하나의 깊이 있는 경험을 하신 분들을 모시고 있습니다. 어떤 문제를 깊이 있게 파본 경험이 있다면 다른 문제에 대해서도 깊이 있게 팔 수 있다고 가정할 수 있다고 생각하기 때문입니다. 하이퍼커넥트는 업계를 리딩하고 있는 제품을 만들고 있습니다. 그러다보니 저희가 참고할 수 있는 회사가 거의 없습니다. 매칭이라는 관점에서는 게임의 매칭 시스템을 조사하고 힌트를 얻기도 하고, 추천시스템이라는 관점에서는 타 회사의 추천 시스템들에 대한 결과들을 엿보면서 저희 시스템을 만들어나가고 있습니다만, 결국 우리 문제는 우리만의 문제이기 때문에 외부 솔루션만 단순히 적용하다보면 분명 한계를 만날 수 밖에 없습니다. 그래서, 문제를 깊이 있게 파서 해결하실 수 있는 분을 찾고 있습니다.
면접 과정 중에 후보자께서 깊이 있는 경험을 했는지는 판단하기 참 어렵습니다. 사람의 시간은 유한하기 때문에 여러 프로젝트들 모두에서 깊이 있는 경험을 해보셨을 가능성은 적기 때문입니다. 하지만, 적어도 하나의 깊이 있는 경험은 필요합니다. 저희는 면접 과정 중에 후보자께서 가장 깊이 있게 고민하고 실행했던 프로젝트에서 어떤 고민을 하고 어떤 공부를 했으며 어떤 의사결정을 하셨는지 듣고 싶어합니다.
조금 더 구체적인 예시를 들어보면서 저희가 생각하는 깊이 있는 경험에 대해서 말씀드려보고자 합니다.
한 때 후보자분들 중에 본인 논문에 LoRA를 쓰신 분들이 굉장히 많았습니다. 그럼 왜 내 논문에서 LoRA를 쓸 수 있는지 일단 설명할 수 있어야 합니다. 이런 설명을 하려면 필연적으로 LoRA 외에도 후속으로 비슷한 역할을 하는 방법들이 꽤 많이 있는데, 이 방법들보다 LoRA를 써야 하는 이유를 설명할 수 있어야 합니다. ‘해봤더니 LoRA가 제일 좋았다’ 도 나쁘진 않은 답변이라고 생각합니다. 하지만, 그럼 왜 내가 풀려는 문제에는 LoRA의 성능이 경험적으로 제일 좋았을지에 대해서도 생각해보았어야 하고 논리적 근거(rationale)가 있어야 합니다.
또, LoRA라는 method의 이름에는 rank라는 단어가 들어갑니다. 그럼 rank가 뭘지도 생각해봤어야 합니다. rank의 정의와 성질을 공부하고 m x n 행렬이 m x k 와 k x n 의 행렬로 decompose 되는 것과 rank가 어떻게 관계되는지도 알아봤어야 합니다. 그럼 low-rank로 우리가 가정하는 것이 얼마나 현실세계에서 합리적인 가정인지 생각해보고, 합리적인 가정이 아니라면 어떤 가정을 넣어야 조금 더 현실적인 가정으로 바뀌는지도 생각해봐야 합니다.
LoRA의 학습 속도가 빠르다고들 합니다. 그럼 왜 빠를까요? 파라미터가 늘어나는데 말이죠. 학습에 사용되는 파라미터는 줄어드니까 빨라지나요? 그럼 어떤 원리로 빨라지나요? low-rank가 아닌 high-rank로 방법론을 적용하면 오히려 계산량이 늘어나는 것 아닌가요? 그럼 계산량이 역전되는 rank k는 어떻게 찾을 수 있나요? LoRA는 파라미터가 늘어나는데 그럼 추론 시에는 더 많은 계산량을 써야 합니다. 그럼 학습 속도 이점을 보기 위해서 추론 시에는 손해를 봐야 하는 상황인 것 아닌가요? 또 이런 질문도 해볼 수 있습니다. rank k는 꼭 아키텍쳐마다 같게 설정해야 하나요? 행렬마다 다르게 설정하고 하이퍼파라미터 튜닝하면 스코어를 더 찍을 수 있지 않을까요?
LoRA가 내가 ML에서 가장 자신 있게 설명할 수 있는 개념이라면, 이런 질문들을 스스로에게 던져보고 답을 찾아보셨어야 한다고 생각합니다. 이게 저희가 생각하는 깊이 있는 경험입니다. 본인이 했던 모든 프로젝트에서 이런 깊이 있는 경험을 하신 분을 찾고 싶지만, 적어도 본인이 진심을 가지고 풀었던 프로젝트에서는 이런 고민을 해봤어야 한다고 생각하고, 면접과정에서 후보자분께 질문을 하다보면 LoRA 케이스에 대해서도 여기 예시로 나온 것 말고도 더 깊이 있는 질문들을 드리게 되는 경우가 흔합니다.
소프트웨어 엔지니어 후보자분들께도 비슷한 질문들을 드리게 됩니다. 만약 이전 회사에서 피쳐스토어를 다뤄봤던 분이고 본인의 가장 깊이있는 프로젝트가 피쳐스토어라면, 피쳐스토어는 왜 필요한지? 없으면 어떤 문제가 생기는지? 그냥 RDB에서 다 처리하면 정말 안되는건지? 만약 피쳐스토어를 직접 내부에서 구축해서 쓰는 조직이었다면 외부 솔루션과는 어떤 차이점들 때문에 내부에서 구축했었어야 했는지? 외부 솔루션들의 구현은 어떤 방식으로 이뤄지고 있고 구축한 방식에서는 어떤 방식을 선택했는지? 혹은 새로운 방식을 만들어내고 구현했는지? 피쳐 스토어가 단순 캐시와는 어떻게 다른지? 캐시를 구성했다면 invalidation과 consistency를 어떻게 보장할지, 트래픽 패턴에 따라 어떤 정책을 써야 하는지? 이런 의사결정을 만약했다면 어떤 방식으로 했을지? 이해관계자(stakeholders)의 합의는 이끌어냈는지? 이끌어 냈다면 대상이 누구고 어떤 방식이었는지?
“적어도 하나의 깊이 있는 경험”이란, 무언가를 많이 해봤다는 뜻이 아닙니다. 단 한 가지라도 문제를 집요하게 파본 경험을 의미합니다. 단순히 잘 동작하게 만들고 끝내는 것이 아니라, ‘왜 그렇게 되는가’를 이해하려는 태도가 필요하고 어떤 부분은 호기심도 많이 필요하다고 생각합니다. 요즘처럼 프레임워크와 도구가 너무 잘 되어 있는 시대에는, 돌려봤다 혹은 다뤄봤다는 경험만으로는 깊이를 말하기는 어렵습니다. 더 잘하고 싶은 사람은 결국 끝없이 고민하게 된다고 믿습니다. “이게 정말 최선일까?”, “다른 방법은 없을까?” 같은 질문을 스스로 던지는 사람과 함께하고 싶습니다. 그 질문이 깊이를 만듭니다.
결론부터 말씀드리면, 네. 쓸 수 있고 실제로 씁니다. 저희는 리서처로 구성된 팀이 크지 않지만, 지금까지 CVPR, ICCV, ECCV, AAAI, EMNLP, NAACL, ICASSP, INTERSPEECH 등 다양한 top-tier 학회에 논문을 발표해 왔습니다. 워크숍 논문까지 포함하면 훨씬 더 많은 연구들이 공개되어 왔고, 여러 차례 best paper로도 선정되었습니다. 실제로 저희 조직에서 논문 지도를 이끌었던 장부루님께서는 고려대 교수로 몇 년전 임명되시기도 하셨습니다.
하지만 저희가 논문을 쓰기 위해 일하는 것은 “절대” 아닙니다. 하이퍼커넥트 AI 조직의 가장 중요한 목표는 회사의 비즈니스에 기여하는 것입니다. 그래서 회사의 성과와 직접적으로 연결되는 중요한 문제를 정의하고 해결합니다. 이 문제들은 해결했을 때 비즈니스 임팩트가 큰 일들입니다. 실제 제품의 성능을 좌우하고, 사용자 경험을 바꾸는 일들인 경우가 많습니다.
이런 문제는 대충 풀 수 없습니다. 중요한 문제이기에 대충 해결하면 결국 얼마 지나지 않아 다시 손봐야 하기 때문입니다. 저희가 5년 전 발표했던 논문 중 일부가 여전히 state-of-the-art로 인용되는 이유도, 그때 문제를 최선의 해결책을 고민하며 제대로 풀었기 때문입니다. 이렇게 깊이 있는 연구를 하다보면 저희의 연구 결과는 top-tier 학회에 제출할 만한 수준이 됩니다. 자세한 내용은 이전에 공개한 테크 블로그를 참고하셔도 좋습니다.
논문화는 연구의 결과이지 목표가 아닙니다. 연구는 문제를 해결하는 과정에서 우리의 지식을 확장해 나가는 일입니다. 따라서 논문 작성은 연구의 아주 일부일 뿐이며, 하이퍼커넥트 AI에서는 이를 KPI로 두지 않습니다. 실제 업무 과정에서 만들어진 기술을 기반으로, 본인이 논문으로 정리하고 싶을 때 자발적으로 진행합니다. 팀원 중 논문을 쓰고 싶은 사람이 없으면 그 시기에는 논문이 나오지 않을 수도 있습니다. 하지만 연구는 계속되고, 그 결과가 언제든 논문이 될 수 있습니다.
하이퍼커넥트 AI는 논문이 목표가 아니라, 비즈니스에 기여하는 것이 목표입니다. 그리고 그 가치를 만들어내는 과정에서 자연스럽게 논문이 따라옵니다.
신규 입사자가 들어오면 꽤 자주 이런 질문을 받습니다. 결론부터 말씀드리면, 시니어의 경우 가능합니다.
제가 6년 전 처음 하이퍼커넥트에 입사했을 때에도 같은 가이드가 존재했습니다. 그리고 현재도 유지되고 있죠. 처음 제가 이 가이드를 받았을 때 들었던 생각은 저도 비슷했습니다. 가능해보이지 않았거든요. 그래서 이 질문을 하시는 분들이 어떤 마음으로 질문하시는 지 저도 나름대로 이해할 수 있습니다.
하지만, 그 질문에 대한 답을 얻기까지 그리 오리걸리지 않았습니다. 우연히도 입사 첫 주 목요일과 금요일 양일동안 저희 AI 조직에서 워크샵을 갔습니다. 리서쳐들끼리 논문읽고 요즘 기술이 어떤 것들이 발전하고 있으니 어떤 일을 1년 동안 하는게 좋을지 이야기하는 시간이었는데요. 그 과정에서 동료 리서쳐들을 보면서 저렇게 하면 논문을 100편 빠른 시간안에 읽을 수 있구나를 많이 느꼈습니다. 놀라웠던 것이 다들 하시더라고요. 심지어 연구실 경험이 없으신 분들도 어렵지 않게 하시는 것을 보고 많은 생각이 들었습니다. 그리고 그 다음부터는 저도 그 기준을 맞추기 위해 노력했고요.
비슷하게, 제 공동 지도 교수님께서는 뉴립스 논문도 1주일이면 충분하단 이야기를 종종 하셨습니다. 그러니까 끝까지 포기하지 말라고 말씀하셨죠. 처음에는 그냥 용기를 북돋아주시기 위한 말씀이라고만 생각했는데, 연구실에서 동료들이 실제로 1주일동안 논문을 꽤 괜찮은 퀄리티로 제출하는 것을 보면서 많은 생각이 들었습니다. 그리고, 하이퍼커넥트에서 저와 같은 교수님께 공동 지도를 받은 팀원이 있었는데 그 팀원과 3일만에 논문 작성해서 제출했었던 적도 있었고요. (물론, 회사 연구를 위해서 모든 작업은 다 해둔 상황이었고 벤치마크 실험과 writing과 같은 논문화 작업만 남은 상황이긴 했었습니다. 그리고, 뉴립스에 당시엔 떨어졌고 몇번 이터레이션 돌다가 다른 venue에 붙었지만요.)
처음 듣기에 어려워보이는 일들도 팀에 좋은 모범이 되는 분들이 많으면 충분히 가능한 일인적이 꽤 많습니다. 논문 100편이라고 하면 너무 많다고 느껴지지만, 논문은 읽다보면 빨라집니다. 그리고 그 배경지식 덕분에 다른 논문들을 더 많이 읽게 되고 시간이 지나면서 논문 읽는데 걸리는 시간은 계속 줄어듭니다. 그래서 평소에도 자주 그리고 많이 읽는게 중요합니다. 그리고 이런 기준을 서로 공유할 수 있는 사람들과 함께해야 합니다.
이렇게 팀에 좋은 모범을 보이고 가능하단 걸 보여주시는 분들이 있으면 해당 역량들이 전체적으로 팀에서 올라갑니다. 사람마다 잘하는 분야는 당연히 다릅니다. 저희는 한 분야에서 우리 팀에 역량을 끌어올려주실 분들을 우선해서 찾고 있고, 서로 자극받으면서 성장하는 조직을 만들기 위해 노력하고 있습니다.