본문 바로가기

카테고리 없음

서비스를 위한 알고리즘 선택 기준

다양한 이유로 사용 중인 모델/알고리즘을 개선해야 한다. 보통은 환경이 바뀜에 따라서 예측 성능이 저하되거나 조금 더 정확도를 높이고 싶은 욕심에서 모델 개선 작업을 한다. 단순히 에이징 된 모델을 버리고 새로 학습하는 것에서부터 새로운 데이터를 추가하거나 새로운 최신 알고리즘을 적용하는 것까지 알고리즘 개선의 형태도 다양하다. 모델 개선의 가장 큰 목적이 예측 정확도를 높이는 거지만, 섣불리 진행하면 낭패를 볼 수 있다.

학계 연구는 모델의 정확도를 개선하는 것을 주목적으로 한다. 기존 모델보다 정확도가 1%, 아니 단 0.1%만 높여도 논문을 작성해서 발표할 거다. 특히 정확도가 95%이상을 넘긴 분야에선 더더욱 그러하다. 산학 과제가 아닌 이상은 프로덕션 과정을 제대로 고려하지 않는 측면이 있다. 하지만 서비스를 위한 모델/알고리즘은 단지 정확도만으로 결정할 수 없다. 그리고 정확도는 사용하는 데이터에 많이 좌우된다. 실제 산업계에서 만들어지는 데이터가 부재한 학계에서는 공개 데이터를 최대한 활용해서 정확도를 높이는 작업을 해야 하지만, 다양한 출처에서 끊임없이 쏟아지는 데이터를 다루는 산업계에서는 단순히 학계가 검증/제안한 좋은 알고리즘을 그대로 사용할 수는 없는 노릇이다. 그리고 환경이 조금만 바뀌어도 (데이터가 바뀌어도) 알고리즘의 예측 정확도는 5~10% 정도 수시로 변한다. 그래서 어떤 새로운 알고리즘이 state-of-the-art (SOTA) 성능을 기록했다고 해도 실제 서비스에서도 그런 성능을 내리라는 기대는 금물이다.

데이터 과학자로서 알고리즘의 정확도가 매우 중요하지만, 프로덕션을 위한 알고리즘 선택이라면 비즈니스 관점에서 경제성과 서비스 관점에서 속도와 안정성이 우선이다. 물론 심플한 알고리즘의 품질이 일정 수준을 만족할 때 얘기다. 얼핏 보기엔 서비스에서 데이터 과학자는 가장 눈에 띄지 않는 뒤쪽에 위치하는 듯하지만, 실은 여러 집단들 사이에서 커뮤니케이터 역할을 해야할 때가 종종 있다. 그래서 모델/알고리즘 자체를 이해하기에도 쉬워야 할 뿐만 아니라, 모델이 내놓는 결과를 해석하는 것도 직관적일 필요가 있다. 모델이 얼마나 쉬운가, 즉 interpretability가 서비스를 위한 모델 선택에서 중요하다. 지금 기대치의 7~80%의 성능을 내는 알고리즘이 있는데, 이를 다시 85~90% 이상으로 끌어올려야 하는가를 판단할 때 단순히 정확도 개선과 함께 (보다는) 경제성, 속도/안정성, 설명도 등을 함께 고려해야 한다는 의미다. 

보통의 모델 개선 작업은 새로운 데이터를 추가하거나 최신의 알고리즘을 적용하는 거다. 알다시피 노이즈 데이터가 아닌 이상 새로운 데이터를 추가하면 모델의 정확도는 계속 올라가고 또 여러 곳에서 검증한 최신의 SOTA 알고리즘을 적용하면 정확도가 향상된다. 그런데 새로운 데이터의 추가는 데이터의 차원과 양을 증가시켜서 데이터를 처리하고 학습/추론하는데 더 많은 연산과 시간이 필요하다. 그리고 새로운 알고리즘은 더 복잡한 알고리즘과 사실상 동의어다. 즉 정확도를 개선하기 위해선 — 데이터 관점에서건 알고리즘 관점에서건 — 더 많은 공수가 들어간다.

최근 데이터 사이언스의 발전은 하드웨어의 성능 개선과 궤를 같이 했다. 1~20년, 심지어 3~40년 전의 아이디어가 오늘날의 빠른 하드웨어와 만나서 (그리고 빅데이터) 빛을 보고 있는 셈이다. 대표적으로 딥러닝이 그렇다. 그러니 '새로운 컴퓨터 사줄테니 우리도 딥러닝이란 걸 해보자'라고 누군가는 말할 수 있다. 하지만 이게 말처럼 간단하지 않다. 알고리즘의 정확도 개선과 연산 속도와 경제성의 관계가 선형이 아니다. 10%의 정확도 향상을 위해서 속도가 단지 10% 느려지고 10%의 컴퓨터 리소스를 더 추가하면 해결된다면 고민이 없다. 10%를 얻기 위해서 2~3배, 때론 10배의 리소스가 필요하다. 최근에 늘어나는 데이터 양과 알고리즘의 복잡도를 생각하면 10배의 리소스도 어쩌면 매우 낙관적인 수치다. 또 알고리즘이 복잡해지면 속도가 느려질 뿐만 아니라 알 수 없는 장애도 빈번해진다. 모델이 너무 복잡해서 디버깅을 제대로 하지 못하고 그냥 프로그램 종료&재시작이 유일한 해결책인 경우도 있다. 참 난감하다.

의료나 자율주행, 군수와 같이 정확도 개선이 매우 크리티컬한 영역도 있다. 하지만 일반 대중들을 위한 인터넷 서비스를 위한 알고리즘이라면 일정 수준을 초과하는 정확도가 큰 의미가 없을 수 있다. 일반 서비스에서 모델의 정확도를 10% 개선했다고 해서 사용자들의 사용성이나 만족이 10% 올라가는 것이 아니다. (보통은 그에 못 미친다.) 만에 하나 10% 이상의 사용성이 개선됐다손 치더라도 이를 통해서 매출/이익이 10% 이상 바로 증가하리라 기대하기 어렵다. (비선형적이라 그 이상도 아주 가끔 나올 수는 있지만 대게는 그보다 적다.) 실제 광고의 pCTR을 계산하는 모델의 정확도를 5% 정도 높이는 작업을 진행해서 CTR을 다소 올렸지만 실제 매출은 이전과 별반 차이가 없었던 적도 있다. 그래서 사용자들이 더 관심 가질 광고를 노출해줬거니 정도로 만족했다. 예측 모델의 수준이 낮을 때는 모델 개선이 수익으로 연결되지만 그 이상에선 그렇지 않다. 그냥 자기만족이거나 연말에 인사고과를 위한 뽐내기 이상의 사업적 이득이 별로 없다. (물론 그럼에도 속도와 경제성을 잡으면서 정확도를 개선하는 것은 데이터 과학자로서 자존심 문제다.)

그리고 새로운 모델을 적용할 때 늘 고민되는 포인트 중 하나는 모델의 interpretability다. 간단한 Decision tree나 선형 알고리즘을 사용하면 결과를 쉽게 해석할 수 있다. 어떤 피쳐가 어느만큼 결과에 영향을 줬는지 확인할 수 있고, 만약 문제가 발생하더라도 어느 부분에 이상이 있는지 바로 디버깅도 가능하다. 그런데 딥러닝을 비롯한 복잡한 앙상블 알고리즘들은 성능은 좋은데 내부 확인이 어려운 블랙박스다. 당장은 성능이 좋아서 사용하지만 예외 상황에 직면했을 때 해결할 방법이 없다. 성능이 다소 떨어지더라도 간단한 모델을 사용하는 이유는 결과를 해석하는 데도 쉽지만, 대내외적으로 — 특히 비전공자들에게 — 사용한 방법론을 설명하기가 쉽다. (때론 너무 쉽고 간단한 모델을 사용해서 오히려 일을 제대로 안 한 것처럼 비치는 부작용 없는 것도 아니다. 그래서 오히려 모델을 정확히 이해도 못하면서 그저 최신의 SOTA 기술을 빠르게 구현해서 적용한 사람들이 인정받는 게 현실이다. 장기적으로 문제가 된다.) 대안으로 복잡한 모델을 구축한 후에 모델에 사용된 피쳐가 결과에 어떤 영향을 주는지 확인하는 포스트-분석 방식이 등장했다. 어쨌든 너무 폼만 잡지 말고 문제, 상황, 데이터에 맞는 가급적 간단한 모델을 선택해서 빠른 연산과 적은 리소스, 그리고 해석의 용이함을 얻었으면 좋겠다. Occam’s razor는 모델 선택에서 기본이다.

100%의 정확성을 얻는 것은 데이터 과학자들에게 이루지 못할 꿈일 거다. 정확성이 높은 알고리즘을 개발하는 것은 매우 중요하다. 하지만 경제적인 측면과 실제 서비스 운영 측면을 고려하지 않은, 즉 프로덕션이 어려운 알고리즘을 무턱대고 사용하는 건 피했으면 한다. 프로덕션을 고려하지 않고 그냥 이것저것 시도해보는 것도 필요하지만, 어쨌든 선택의 시간에는 프로덕션 여부가 최우선이다. 그리고 비전공자들과 함께 일할 때는 더더욱 모델 선택에 신경쓰야 한다. 때로는 경영진에게 방법론을 설명해야 할 때도 있고 때로는 기획이나 영업에 설명할 때도 있다. 그들은 광고주나 협력업체를 찾아다니며 우리 상품을 설명해야 하는 경우도 있다. … 그냥 ‘AI 기반으로 랭킹 해요’라고 설명하는 게 가장 나을까? 흠… 마음 한 켠에는 늘 더 정확한 알고리즘을 개발하고 말테야라는 욕심이 늘 도사리고 있지만, 지금 내 서비스에 가장 적합한 것이 무엇인가를 먼저 고민해야 한다.

감당할 수 없다면 간단하게 시작해서 간단하게 끝내라. 예측 모델이 없는 것과 있는 것 사이에는 간극이 크지만 (최적화된) 간단한 모델과 (최적화 안된) 복잡한 모델 사이의 (정확도 면에서) 간극은 별로 없다. 하지만 부수적으로 — 특히 서비스를 운영하면서 — 투입되는 리소스에는 차이가 많다. 여담으로 복잡한 걸 만들어놓고 튀어버리면 — 자기는 마치 최정예 전문가인양 명성을 얻지만— 남은 사람들이 감당하기 어렵다. 회사 생활하다 보면 이런 경우를 꽤 자주 만난다.

반응형