제71화 — Elena Park

Elena Park는 면접 시작 3분 만에 Daniel의 질문을 되받아쳤다.

“왜 머신러닝을 하려고 하시죠?”

Daniel은 잠깐 멈췄다.

보통 지원자는 회사가 무엇을 하려는지 묻는다.

Elena는 반대였다.

당신은 왜 이걸 하려 하느냐.

“과학 계산을 더 빠르게 하기 위해서입니다.”

“그건 계산 자원 이야기고요.”

Elena가 말했다.

“머신러닝이 꼭 필요한 이유요.”

Daniel은 의자에 등을 기대었다.

면접실에는 Daniel, 연구책임자, Elena 세 명뿐이었다.

첫 면접은 연구팀이 이미 끝냈다.

오늘이 2차.

Daniel은 이번에 일부러 마지막 단계에만 들어왔다.

Elena의 이력은 특이했다.

계산과학.

통계모델.

과학 데이터 분석.

오픈 데이터.

재현성.

논문 수보다 더 눈에 띈 것은 실패한 결과를 공개한 기록이었다.

Daniel은 그게 마음에 들었다.

“모든 계산을 직접 하면 비쌉니다.”

그가 말했다.

“시뮬레이션 결과를 학습해서 근사할 수 있는 영역이 있습니다.”

Elena가 고개를 끄덕였다.

“그건 맞고.”

“또 실험·시뮬레이션에서 사람이 놓치는 패턴을 찾을 수 있고.”

“그것도.”

“후보를 좁힐 수 있습니다.”

“어떤 후보요?”

Daniel이 웃었다.

“그걸 찾아야죠.”

Elena는 웃지 않았다.

“그럼 너무 넓습니다.”

연구책임자가 눈을 감았다.

Daniel은 오히려 관심이 갔다.

“어떻게 좁혀야 합니까?”

Elena가 노트북을 돌렸다.

Helioxen 계산서비스의 작업시간 예측 프로젝트.

그녀는 이미 공개된 일부 기술자료를 읽고 왔다.

“이건 좋은 문제입니다.”

입력.

메모리.

워크로드.

실행시간.

실패여부.

명확한 목표.

반대로 Daniel이 면접 전에 보낸 ‘과학 연구보조’ 아이디어는 문제가 넓었다.

“‘과학을 가속한다’는 건 제품 설명이지 연구질문이 아닙니다.”

Daniel의 입꼬리가 아주 조금 올라갔다.

“그럼 뭘 먼저 하시겠습니까?”

“실패 예측.”

Daniel이 예상 못 한 답.

“속도 예측보다?”

“네.”

“왜?”

“Elena가 화면을 가리켰다.

Helioxen 서비스 로그.

실행시간보다 더 비싼 일이 있었다.

두 시간 돌고 실패.

다시 설정.

다시 실행.

“작업 시작 전에 실패 가능성을 잡으면 계산을 빠르게 하는 것보다 더 큰 시간을 줄일 수 있습니다.”

Daniel은 바로 이해했다.

A1에서 이미 배운 원칙.

빠른 부품보다 전체 흐름.

“어떻게 예측합니까?”

“먼저 실패를 분류해야죠.”

메모리 부족.

라이브러리 충돌.

입력 오류.

수렴 실패.

하드웨어.

고객 코드.

현재 로그는 원인분류가 일관되지 않았다.

Daniel이 말했다.

“데이터 정제부터.”

“네.”

“얼마나 걸립니까?”

Elena가 Daniel을 봤다.

연구책임자가 작게 웃었다.

Daniel이 말했다.

“이 질문 유명합니까?”

Elena는 처음으로 웃었다.

“면접 전에 들었습니다.”

“누가요?”

“연구팀에서요.”

Daniel은 한숨을 쉬었다.

“좋습니다. 일정은 팀이 정합니다.”

Elena가 고개를 끄덕였다.

“그 답은 괜찮네요.”

면접은 두 시간 가까이 갔다.

중간에 Daniel이 머신러닝 모델 후보를 말했다.

Elena는 세 번 잘랐다.

“데이터 수가 부족합니다.”

“그건 라벨이 너무 불안정합니다.”

“그건 결과를 맞혀도 이유를 설명 못 합니다.”

Daniel이 물었다.

“설명 가능해야 합니까?”

“운영에 쓸 거면요.”

“과학 연구라면?”

“더더욱.”

“왜?”

Elena가 잠깐 생각했다.

“과학자는 예측값보다 왜 그런지 알고 싶어하니까요.”

“항상은 아니죠.”

“맞습니다.”

Elena는 고개를 끄덕였다.

“그래도 모델이 맞았다는 이유로 과학적 설명이 생기는 건 아닙니다.”

Daniel은 그 말을 적었다.

Prediction ≠ explanation.

또 하나의 경계.

의료에서: 추천 ≠ 임상판단.

과학에서: 예측 ≠ 설명.

“오픈 사이언스 쪽 활동이 많으시네요.”

Daniel이 물었다.

“네.”

“회사 들어와도 계속 공개하고 싶습니까?”

“가능하면.”

“경쟁사가 볼 수 있습니다.”

“검증도 해줍니다.”

“우리 돈으로 한 연구인데.”

“틀린 연구를 독점하는 것보다 낫죠.”

연구책임자가 고개를 숙였다.

웃음을 참는 것 같았다.

Daniel은 오히려 진지했다.

“그럼 전부 공개?”

“아뇨.”

Elena가 말했다.

“고객 데이터, 제품 구현, 보안, 독점 기술까지 열자는 건 아닙니다.”

“그럼.”

“공통 벤치마크. 방법론. 재현 가능한 과학결과. 실패결과.”

Daniel이 물었다.

“실패도?”

“특히.”

“왜?”

“성공만 보면 어떤 방법이 진짜 좋은지 모릅니다.”

Daniel은 A1 포스트모템을 떠올렸다.

회사 안에서 배운 실패공개.

Elena는 그걸 과학 밖에서도 당연하게 생각하는 사람 같았다.

면접 마지막.

Daniel이 물었다.

“왜 Helioxen입니까?”

이번에는 Elena가 잠깐 멈췄다.

“아직 결정 안 했는데요.”

Daniel이 웃었다.

“지원했잖아요.”

“면접은 서로 보는 거죠.”

정확했다.

“그럼 현재 점수는?”

“점수 싫어하신다던데.”

Daniel이 미나를 떠올렸다.

“요즘 그렇습니다.”

Elena가 웃었다.

“좋은 점.”

손가락 하나.

“계산 인프라가 실제로 있습니다.”

둘.

“실패한 A1을 숨기지 않았습니다.”

셋.

“제품팀과 연구팀을 분리했습니다.”

“나쁜 점은?”

“대표님이 너무 많이 아는 척합니다.”

연구책임자가 이번엔 대놓고 웃었다.

Daniel도 잠깐 말이 없었다.

“제가요?”

“네.”

“어떤 부분.”

“면접 중에 제가 설명하려는 걸 세 번 먼저 결론내셨습니다.”

Daniel은 기억했다.

맞다.

모델.

데이터.

과학 방향.

자기가 미래를 알고 있다는 사실이 습관으로 튀어나온다.

“고치겠습니다.”

Elena가 그를 봤다.

“그 말도 자주 하신다던데.”

이번에는 셋 다 웃었다.

며칠 뒤 연구책임자가 말했다.

“Elena, 합류 의사 있습니다.”

Daniel이 물었다.

“조건은?”

“연구 공개정책 명문화.”

“연봉?”

“그것도.”

“또?”

“대표님이 연구주제 직접 바꾸지 않는다는 조건.”

Daniel이 멈췄다.

“그런 조건을 계약에 넣습니까?”

“정확히는 연구책임자 승인 없는 직접변경 금지.”

Daniel은 이선을 찾았다.

이선은 한마디 했다.

“좋은 사람 같은데.”

“왜요?”

“벌써 너부터 막잖아.”

Daniel은 한숨을 쉬었다.

결국 동의했다.

Elena Park.

Helioxen Advanced Compute Research Group.

Senior Research Scientist.

첫날 그녀가 연구팀 화이트보드에 쓴 문장은 짧았다.

What would prove us wrong?

Daniel은 그 문장을 봤다.

자기가 2006년 거래일지에 썼던 질문과 같았다.

그런데 이제 그 질문을 자신에게 던질 사람이 하나 더 생겼다.

그 점이 마음에 들었다.

조금 불편할 정도로.

Elena의 첫 출근일에는 작은 문제가 하나 있었다.

연구실 자리를 정하는 문제.

Daniel은 창가 쪽 넓은 책상을 준비해뒀다.

Elena는 들어오자마자 물었다.

“실패 로그 보는 팀이 어디 있죠?”

“저쪽.”

“그럼 거기 앉겠습니다.”

“여기가 더 조용한데.”

“그래서요?”

Daniel은 잠깐 할 말을 잃었다.

연구실 중앙.

운영팀과 가까운 자리.

사람이 지나다니고 전화소리도 들렸다.

Elena는 거길 골랐다.

“왜요?”

Daniel이 물었다.

“제가 모델 만들다가 현장을 잊을까 봐요.”

“현장 로그만 보면 되잖아요.”

“로그에 안 적히는 게 더 많습니다.”

그 말은 의료 프로젝트에서도 배운 내용이었다.

Daniel은 더 말하지 않았다.

첫 주 동안 Elena는 코드보다 사람을 더 많이 만났다.

지원팀.

운영팀.

제품팀.

고객담당.

Daniel이 물었다.

“모델 언제 시작합니까?”

Elena가 말했다.

“이미 시작했습니다.”

“인터뷰가요?”

“실패 정의를 알아야죠.”

지원팀 직원은 이렇게 말했다.

“고객이 화내면 실패.”

운영팀은 달랐다.

“재실행이 필요하면 실패.”

제품팀은 말했다.

“결과가 틀리면 실패.”

고객담당은 말했다.

“약속시간 넘기면 실패.”

Elena는 같은 ‘실패’라는 단어가 부서마다 다른 뜻이라는 걸 보여줬다.

Daniel이 말했다.

“그럼 하나로 정의해야겠네요.”

Elena가 고개를 저었다.

“아니요.”

“왜?”

“여러 종류가 있는 겁니다.”

기술 실패.

운영 실패.

서비스 실패.

고객 경험 실패.

하나로 합치면 편하지만 원인을 잃는다.

Daniel은 잠시 생각했다.

A1.

기술적으로 성공.

사업적으로 실패.

같은 구조.

Elena가 말했다.

“모델 목표부터 하나씩 정해야 합니다.”

첫 프로젝트는 기술 실패예측.

서비스 지연은 별도.

Daniel은 그게 마음에 들었다.

큰 문제를 잘게 자르는 방식.

Elena의 첫 주 마지막 날, Daniel은 연구실을 지나가다가 그녀 화면을 봤다.

코드는 거의 없었다.

데이터 사전.

실패분류.

예시.

“한 주 동안 이거 했습니까?”

Elena가 Daniel을 봤다.

“대표님이 싫어할 줄 알았습니다.”

“조금.”

Daniel이 솔직하게 말했다.

“근데 필요한 건 압니다.”

Elena가 웃었다.

“그러면 많이 고치셨네요.”

“다들 왜 그 말을 합니까?”

“아마 다들 같은 과거의 대표님을 들었나 보죠.”

Daniel도 웃었다.

그날 그는 연구실에서 나가다가 다시 화이트보드를 봤다.

`What would prove us wrong?`

그 아래 Elena가 한 줄을 더 써놨다.

Before modeling, define what failure means.

Daniel은 그 문장을 사진으로 찍었다.

회사도.

의료도.

연구도.

실패를 정확히 정의하지 않으면 성공했다는 말도 아무 의미가 없었다.