달고나 5. 데이터 문제 해결 프로세스
Practice: Data Problem Solving Cycle
이전 글은 다소 즉흥적이었다. 데이터 과학자는 상황과 문제에 맞게 사고와 반응이 유연해야 함을 강조한 것이지, 일반적인 절차나 방법론이 없다는 의미는 아니다. 이글에 관심 있는 독자들이라면 이미 그런 명시적 또는 암묵적 방법론에 관한 여러 글들을 봤을 것이고 또 완전히 같진 않지만 유사한 형태/방식으로 자신의 임무를 수행하고 있다고 짐작한다. 그럼에도 이 글을 다시 적는 이유는 모두가 데이터 과학에 익숙한 것도 아니고, 또 나만의 관점에서 이걸 정리하는 게 의미가 있기 때문이다.
iF카카오2018 발표자료에 러프하게 그렸던 그림을 가져왔다. 막상 그림을 가져온 뒤 글을 적으려니 어쩌면 오해를 줄 수 있을 듯해서 좀 막막하다. 이전 글에서 데이터 과학자는 문제를 정의하고 방법을 찾는 이로 묘사했기 때문에 Research 부분이 가장 중요해 보인다. 한편으론 가장 일상의 데이터 과학자의 모습은 끊임없이 조건과 환경을 바꿔가면서 가설을 세우고 검증하는 거다. 그러면 실험 과정이 가장 중요한 건가? 그림에서도 오프라인과 온라인으로 나눠서 굳이 2개를 넣은 것도 실험이 가장 중요하기 때문일까? 그런데 데이터 과학의 존재 이유는 단순히 논문을 쓰는 것을 넘어서 실제 제품과 서비스를 만드는 것이기 때문에 실용성, 즉 프로덕션이 가장 중요해 보인다. 결론은 어느 하나 빠짐없이 다 중요하다. ㅎㅎ 그리고 새로운 서비스/프로젝트보다 이미 운영 중인 서비스를 개선하는 것을 가정했다.
좀 더 자세히 적어보자.
연구 (Research)는 문제를 발견하고 해결책을 찾아서 구현하는 전 과정을 의미한다. 개념적으론 실험 과정을 리서치의 하부에 두고, 리서치와 프로덕션으로 크게 구분하는 게 맞을 듯하다. (그래서 아래에 다시 그렸다.ㅎㅎ) 모든 개선은 문제를 발견하는 데서 시작한다. 상시 모니터링, 내부 QA, 외부 C/S, 또는 더 좋은 서비스를 만들겠다는 기획/개발자들의 고집에서 문제가 설정된다. 때론 문제를 재정의할 필요도 있다. 문제가 정의되면 이젠 이를 해결하기 위해 필요한 데이터를 정리하고 어디서 어떻게 수급할지도 정해야 하다. 동시에 비슷한 문제에 사용된 방법론이나 알고리즘을 조사하는 것도 병행한다. 문제를 보는 순간 어떤 데이터에 어떤 알고리즘을 적용할지를 바로 결정할 수 있도록 다양한 경험을 쌓아야 한다.
실험 (Experiment)은 데이터 과학자에게 일상이다. 간단한 하이퍼-파라미터 값을 조정하는 것에서부터 완전히 새로운 시스템 (새로운 문제 & 알고리즘 포함)을 적용하는 데까지 매 순간 실험은 진행된다. 특정 문제를 해결하기 위해서 새로운 알고리즘을 적용했는데, 기존의 다른 부분과 간섭 또는 충돌을 일으키는 경우도 잦기 때문에 프로덕션 전에 꼼꼼한 테스트는 필수다. 예를 들어, 하나의 데이터 칼럼의 스케일만 바꿨을 뿐인데, 다른 모듈에서 해당 데이터를 이미 사용하고 있어 대형 사고가 터지기도 한다. (일단 상호 의존성이 없다는 가정 하에) 실험은 보통 오프라인과 온라인, 두 단계로 진행된다. 오프라인 실험은 기존의 로그를 사용한다. MSE, LogLoss, RIG 등의 평가 메트릭을 이용한 모델 자체의 적합도 확인과 클릭률이나 광고 매출 등의 현실적 지표를 이용한 시뮬레이션이 대표적이다. 히스토리컬 데이터 (로그)를 이용한 오프라인 테스트는 새로운 알고리즘의 성능을 어느 정도 가늠할 수는 있지만, 실제 환경에서 얼마나 좋은 성능을 내는지를 절대적으로 확인할 수는 없다. 그래서 만족할만한 오프라인 테스트가 이뤄지면 그제서야 온라인 테스트를 진행한다. 온라인 테스트는 운영 중인 서비스의 일부 트래픽에 적용하기 때문에 프로토타입이 아닌 실 서비스용 코드로 최적화될 필요가 있다. 그렇기에 오프라인 테스트에서 가능한 많은 부분을 꼼꼼히 체크해야 한다. 온라인 테스트는 흔히 버킷 (Bucket) 테스트 또는 A/B 테스트라 부르는데, 다음 글에서 자세히 다루겠다. 오프라인 테스트든 온라인 테스트든 새로운 설정이 만족스럽지 못하면 다시 문제 정의나 알고리즘 탐색의 과정으로 돌아가야 한다.
프로덕션 (Production)은 새로운 설정을 실 서비스에 적용하는 거다. 온라인 A/B 테스트에서 테스트 버킷은 처음에는 5~10%로 설정해서 차츰 50%까지 늘려서 비교한다. 이 말은 실험을 위한 프로토타이핑 구현이 서비스용과 큰 차이가 없다는 뜻이고, 예외적인 경우를 제하면 바로 실 서비스에 배포해도 큰 문제가 없다. 그런데, 온/오프라인 테스트에서 만족할만한 성능 (모델 적합도, 매출 상승 등)을 확인했더라도 느린 속도나 잦은 장애 발생과 같은 심각한 문제가 있다면 프로덕션을 진행할 수 없다. 어떤 알고리즘을 선택할 것인가? 에 관한 글도 계획 중인데, 정확도가 일정 수준에 이른 서비스라면 속도를 희생하면서 정확도를 조금 더 개선하려는 것은 오히려 자책골을 넣는 것일 수도 있다. 학계에선 논문이나 보고서 등의 연구 성과를 위해서 정확도를 단 0.1%라도 개선하는 게 중요하지만, 서비스에선 정확하지만 느린 것보다 준수한 정확도의 빠른 알고리즘이 더 현실적이다. 서버를 추가함으로써 속도를 맞출 수 있지만 경제성이나 운영 이슈 등이 따른다. '인생은 B와 D 사이의 C다’는 말이 있듯 데이터 과학자의 삶도 (검증과) 선택의 연속이다.
그림을 새로 그렸는데 이도 별로 만족스럽지 못하다. 데이터 과학에서 표준화된 프랙티스가 존재하지 않을지도 모른다는 반증일 수도 있다.
데이터 과학자로 성공하려면 어느 정도 우직함이 필요하다. 물론 당신이 천재라면 굳이 이런 허접한 글을 읽고 있을 리가 없을 테니… 경험이 중요하다. 다양한 문제를 접하는 것도 중요하고 그래서 다양한 데이터를 접하는 것도 중요하고 그리고 다양한 알고리즘을 접하는 것도 중요하다. 표준화된 프로세스는 없다.
===
이번 글은 많이 부실해서 미안하네요. 보통 글을 적고 싶어 지면 처음부터 끝까지 생각나는 대로 단번에 적곤 하는데 이번은 여느 때와는 다르게 글을 적는 게 많이 망설였다. 그럼에도 글을 적은 이유는 내가 이해한 것을 나의 방식으로 표현하는 게 중요하기 때문이다. 다음에 인터뷰에 관한 글도 적겠지만, 인터뷰를 계속 들어가 보면 어떤 개념을 제대로 이해해서 자신의 언어로 설명하는 지원자를 만난 적이 없는 것 같다. 지식을 내재화하지 못하고 그저 기술자들만 양산되는 듯하다. 단기적으로 인력 수급은 되겠지만 장기적으로 비전이 없다.
