Skip to content
Fintech AI Lab
Go back

Notes

[소고] 데이터 과학자와 데이터 엔지니어에게 세일즈 기술이 필요한 이유

Read in English

얼마 전 터미널X를 이끄는 뉴욕주민(홍현) 대표가 세일즈팀을 꾸린 과정을 가볍게 적은 글을 읽었다. 터미널X는 운용사들이 내부 데이터와 업무 방식을 AI와 연결해 투자 업무에 쓰도록 돕는 금융 AI 스타트업이다.

내가 이해한 요지는, 세일즈 인원을 뽑을 때 그 사람이 얼마나 큰 조직에서 팔아 봤는지는 별로 중요하지 않았다는 것이다. 스타트업 제품은 새롭고 이름도 덜 알려져 있어서, 큰 회사 간판을 등에 업고 팔던 경험이 그대로 통하지 않는다. 그래서 면접에서 “이 물건을 나에게 팔아 보세요”라고 묻고, 만든 사람보다 더 잘 팔거나 만든 사람조차 사고 싶게 만드는 사람을 찾았다는 이야기였다.

당연한 말 같은데 이상하게 계속 곱씹게 됐다.

직장인은 누구나 뭔가를 판다

학생 때 읽은 책 중에 직장인이라면 기본적으로 세일즈 기술을 갖고 있어야 한다는 내용이 있었다. 제목은 정확히 기억나지 않고, 카네기 이야기가 나오는 부와 성공에 관한 책이었던 것 같다. 그때는 그냥 그런가 보다 하고 넘겼는데, 회사 생활을 할수록 그 말이 자꾸 생각난다.

비슷한 이야기를 다니엘 핑크가 『파는 것이 인간이다(To Sell Is Human)』에서 했다. 미국에서 영업을 직업으로 하는 사람은 9명 중 1명꼴이지만, 나머지 사람들도 일하는 시간의 40% 안팎을 남을 설득하는 데 쓴다는 조사를 소개한다. 핑크는 이걸 돈 대신 시간이나 관심, 노력을 내놓게 만드는 ‘비영업 판매(non-sales selling)‘라고 불렀다. (Wharton)

엔지니어와 데이터 과학자에게도

엔지니어든 데이터 과학자든 이 기술은 꽤 중요하다고 본다. 모델을 잘 만들어도 현업이 써야 의미가 있고, 분석 결과도 결정을 내리는 사람이 받아들여야 뭔가가 바뀐다. 성능이 몇 포인트 오른 모델이라도 그걸 쓸 사람이 왜 바꿔야 하는지 납득하지 못하면 운영에 들어가지 못한다.

여기서 말하는 세일즈는 말재주라기보다 상대 입장에서 생각하는 능력에 가깝다. 쓰는 사람이 뭘 필요로 하고 어디서 불편해하는지에서 출발해야 하는데, 지금까지 같이 일해 본 엔지니어 중에는 실력은 좋은데 이 부분이 약한 사람이 꽤 많았다. 자기가 만들고 싶은 걸 먼저 만들고, 쓸 사람은 나중에 찾는 식이다. 고객 옆에 붙어서 일하는 FDE 같은 직무가 계속 늘어나는 것도 결국 이 간극을 메우려는 시도라고 생각한다.

“이 물건을 나에게 팔아 보세요”를 엔지니어 면접에 옮겨 보면 “지난번에 만든 모델을 그걸 쓸 현업 담당자에게 팔아 보세요” 정도가 되겠다. 기술 설명만 늘어놓는 사람과, 담당자가 매일 하는 일이 어떻게 달라지는지부터 말하는 사람은 꽤 쉽게 구분될 것 같다.

그래도 규모의 경험은 중요하다

다만 데이터 과학자나 엔지니어는 세일즈와 달리, 예전에 어떤 팀에서 어느 정도 규모를 다뤘는지가 꽤 영향을 준다고 본다. 큰 회사에서 기계 부품처럼 정해진 일만 돌렸다면 별 의미가 없겠지만, 대규모 트래픽과 많은 사용자를 상대로 서빙하면서 생기는 문제를 직접 겪어 본 경험은 다른 데서 얻기 어렵다.

GPU 한 대로 모델을 서빙하는 것과, 늘어나는 요청을 감당하려고 스무 대로 늘리는 것은 전혀 다른 일이다. 요청을 어떻게 나눌지, 한 대가 죽으면 어떻게 할지, 새 모델을 어떻게 나눠서 배포하고 문제가 생기면 어떻게 되돌릴지, 비용은 어디서 새는지 같은 문제는 규모가 커져야 비로소 보인다. 데이터 규모도 마찬가지라서, 노트북 메모리에 들어가던 데이터가 분산 처리로 넘어가면 조인 하나, 중복 제거 하나도 다르게 짜야 한다. 데모에서는 멀쩡하던 시스템이 프로덕션에서 무너지는 이유 대부분이 모델 밖에 있다는 것도 이런 경험이 쌓여야 몸으로 알게 된다.

큰 트래픽을 다뤄 본 적이 없다면

반대로 큰 트래픽을 다뤄 본 적이 없다면, 엔드투엔드 경험을 쌓기 좋은 자리에 있다는 뜻이기도 하다. 작은 팀에서는 데이터 수집부터 모델링, 서빙, 모니터링까지 한 사람이 다 맡는 경우가 많다. 큰 조직에서는 그중 한 조각만 하다가 몇 년이 가기도 하니, 전체 흐름을 직접 만들어 본다는 건 큰 장점이다.

그래서 할 수 있는 만큼 엔드투엔드로 끝까지 만들어 보고, 그걸 크게 키우면 어디가 먼저 막힐지는 따로 찾아보면서 메우는 게 현실적이라고 본다. 빅테크 엔지니어링 블로그나 컨퍼런스 발표, 유튜브에 스케일업 과정에서 겪은 문제를 정리한 자료가 꽤 많다. 직접 겪는 것만큼은 아니어도 러닝커브를 상당히 줄여 준다.

상대 입장에서 생각하고 설득하는 기술은 직군을 가리지 않고 필요하고, 데이터 직군은 거기에 규모를 다뤄 본 경험까지 있으면 훨씬 단단해진다. 그 경험이 아직 없다면 작게라도 끝까지 만들어 보고, 키울 때 생길 문제는 남들이 남긴 기록으로 미리 익혀 두면 된다. 어디까지나 개인적인 생각이다.


함께 보면 좋은 글:

참고 자료


Share this post:
Next Post
[FDS] 사기 거래 0.015%를 찾는 방법: 거래 시퀀스 모델, 이상 탐지, 그래프