현실에서 AI로 비즈니스 문제를 풀다보면, X와 Y 두 지표를 동시에 올려야 하는 상황을 흔하게 마주합니다. 실험군은 X 지표에서 100, Y 지표에서 90을 나타냈고, 대조군은 X에서 90, Y에서 100이 관측되었다고 해봅시다. 우리는 실험군을 배포해야 할까요? 말아야 할까요?
지표가 2개인 상황에서 결정하는 문제는 어렵습니다. 우리는 토론을 통해 결정을 내리기도 하고 이 과정에서 가치판단이 개입되기도 합니다. 일종의 기준을 새로 세우기도 하죠. 하지만, vNM 기대효용 이론에 기반해 생각해보면 이 문제는 결국 f(X, Y) ∈ ℝ라는 효용 함수를 정의하고, 함수 f를 최대화하는 문제로 치환됩니다. 우리는 의사결정을 하기 위해 결국 스칼라로 목표를 재정의하고, 재정의된 문제를 풀게 됩니다.
제약조건이 있는 경우도 마찬가지입니다. 예를 들어 Z ≤ K라는 제약이 주어졌다면, 우리는 KKT 조건 아래에서 primal 문제를 dual로 바꾸는 것처럼 결국 또 다른 최적화 함수를 설계해야 합니다. 즉, 제약조건조차 스칼라(f(X, Y, Z) ∈ ℝ)로 목표를 재정의 하는 문제로 환원됩니다.
지표가 2개 이상인 경우 최적화 문제가 어려워집니다. 하지만, 그렇다고 해서 비즈니스를 담당하는 팀에 “지표를 하나로 정리해 주세요”라고 요청하는 것은 적절하지 않습니다. 비즈니스 상황에서는 여러 복잡한 제약사항들을 고려해 지표가 2개 이상인 것이 매우 자연스럽기 때문입니다. 목표를 스칼라로 환원하는 일은 AI 엔지니어의 역할입니다. 새로운 효용 함수 f는 AI 엔지니어가 비 AI 전문가와의 커뮤니케이션을 통해 설계해야 합니다.
효용함수를 설계하는 것은 쉬운 작업이 아닙니다. Hyperconnect AI는 이러한 과정을 통해 복잡한 문제를 스칼라 지표를 목표로 하는 문제로 환원하고, 그것을 최적화해 비즈니스 임팩트를 만들어냅니다.
위키피디아에 따르면 샷건 디버깅은 원인을 정확히 파악하지 않고, 여기저기 고쳐보면서 문제가 해결되기를 바라는 방식을 뜻합니다.
저는 이 방식이 AI 연구에서도 자주 나타나는 실수라고 생각합니다.
모델 성능이 원하는 만큼 나오지 않을 때, 아키텍처를 더 좋은 것으로 바꿔보면 해결되지 않을까 하고 시도하는 경우가 많습니다. 하지만 성능이 안 나오는 이유를 먼저 파악하지 않으면 근본적인 해결이 어렵습니다. 어떤 샘플에서 모델이 실패하는지를 확인해야 문제의 원인을 제대로 짚을 수 있습니다.
데이터 레이블을 더 늘리면 해결될 거라는 기대도 흔합니다. 물론 데이터가 많을수록 보통은 좋아집니다. 하지만 그렇다면 데이터의 일부만 사용했을 때 성능이 실제로 떨어지는지도 함께 확인해야 합니다. 데이터를 10%, 20%, … 100%까지 늘려가며 성능 변화를 보면 이미 성능이 포화 상태인지, 더 늘리면 개선될 여지가 있는지 알 수 있습니다. 의외로 데이터가 수천 개 수준으로 부족하더라도 추가 레이블링이 성능 개선에 거의 영향을 주지 않는 경우도 흔합니다.
학습 도중 NaN이 터졌을 때 gradient clipping이나 learning rate 조절 같은 방법을 바로 쓰는 것도 비슷합니다. 급한 상황에서는 필요할 수 있지만, 결국은 샷건 디버깅에 가깝습니다. 근본적인 원인을 찾는 게 중요합니다. 많은 경우 우리가 설계한 손실 함수에 문제가 있을 때가 많습니다.
저는 ML 모델도 충분히 principled way로 디버깅할 수 있다고 믿습니다. 물론 소프트웨어 디버깅과는 달리 확률적인 성격이 있어서 똑같진 않지만, 원인을 추적하고 검증하는 과정은 똑같이 필요합니다. 샷건 디버깅은 당장은 쉬워 보여도 장기적으로는 오히려 더 느린 길이 될 수 있습니다.
샷건 디버깅을 지양합시다.
‘산탄처방(shotgun treatment)’이라는 말을 들어보셨나요?
의료 분야에서 환자의 병의 원인이 불분명할 때, 가능한 치료를 한꺼번에 시도해보는 방식입니다. 마치 산탄총을 쏘듯 여러 방향으로 동시에 접근하는 것이죠. 급한 상황에서는 이런 방법이 환자를 빠르게 안정시키는 데 도움이 되기도 합니다. 하지만 원인을 정확히 찾아 장기적으로 치료해야 하는 경우라면, 산탄처방은 효과적인 방법이 아니라고 사람들은 말합니다. 무엇이 효과를 냈는지, 혹은 우연히 나아진 것인지 알 수 없기 때문입니다. 저는 이 개념을 수의사인 아내에게서 처음 들었습니다. 흥미로웠던 점은, 이 아이디어가 AI 문제 해결에도 동일하게 적용할 수 있다는 점이었습니다.
저는 KPI(혹은 메트릭)를 최적화하는 과정을 산을 오르는 것에 비유하곤 합니다. AI를 하시는 분들께는 이미 ‘loss landscape’이라는 개념이 익숙하시겠죠. 산의 아래에 있을 때는 어느 방향으로 가도 산을 올라갈 수 있기 때문에, 눈을 감고 아무쪽으로나 가도 성과가 납니다. 이 시기에는 산탄처방식 접근으로도 충분히 성장할 수 있습니다. 하지만 아자르는 출시된 지 10년이 넘은 제품입니다. 눈감고 아무쪽으로나 한 발자국 내딛는다고 해서 더 높이 오르지 않습니다. 이제는 눈을 떠야 합니다. 정상으로 가는 방향이 어딘지, 그리고 우리가 오르려는 산이 맞는지도 봐야 합니다.
이럴 때 A/B 테스팅은 당연히 가장 좋은 방법이지만, A/B 테스트가 어렵다면 의료 분야에서 말하는 ‘치료적 진단(therapeutic diagnosis)’이 좋은 접근이 될 수 있습니다. 가능한 원인을 나열하고, 그중 가장 유력한 하나를 선택해 실험적으로 치료를 시도합니다. 증상이 호전되면 가설이 맞았다고 잠정 결론을 내립니다. 중요한 건, 여러 치료법을 동시에 적용하지 않는 것입니다. 그래야 어떤 방법이 효과를 냈는지 알 수 있습니다. 그리고 우연히 나아진 건 아닌지도 반드시 확인해야 합니다.
AI 문제도 마찬가지입니다. 산탄처방처럼 여러 시도를 동시에 하는 대신, 가설을 세우고 하나씩 검증하며 도메인지식을 쌓아가야 합니다. 처음엔 느려 보여도, 결국 더 빠르고 정확하게 정상에 도달할 수 있다고 믿습니다. Ablation study를 하듯이, principled way로 문제를 풀어야 합니다.
산탄처방은 하지 맙시다. A/B테스트나 치료적 진단처럼 신중하고 원칙적으로 접근합시다.
요즘은 복잡한 모델이 아니면 뭔가 부족해 보일 때가 있습니다. 하지만 선형 모델만으로도 충분히 의미 있는 성과를 낼 수 있습니다. Hyperconnect AI에서는 제품의 다양한 피쳐에서 단순한 선형 모델로도 20~30%의 지표 향상을 이뤄본 경험이 있습니다.
AI가 제품에 기여하는 과정을 보면, 우리가 참여하기 전 이미 만들어져 있는 휴리스틱 로직이 있는 경우가 많습니다. “A 조건을 만족하면 +10, B 조건을 만족하면 -5” 같은 규칙들이죠. 이런 로직은 대부분 PM이나 도메인 전문가의 직관에서 출발합니다.
저희가 처음 해야 할 일은 그 로직이 목표로 하는 1차 지표, 예를 들어 클릭률이나 체류 시간을 명확히 정하고, 그 휴리스틱에서 사용한 피쳐들로 아주 간단한 선형 모델을 학습하는 것입니다.
이 모델의 목적은 휴리스틱의 숫자들을 데이터 기반으로 다시 정렬해주는 일입니다. 직관이 정했던 +10, -5 같은 가중치 값들을 실제 데이터를 통해 찾아내는 거죠. 이 과정은 오래 걸리지 않습니다. Google Colab이나 로컬 노트북에서도 1시간이면 충분히 끝납니다. 간단한 스크립트를 통해 얻은 가중치를 휴리스틱을 실제로 구현한 소프트웨어 엔지니어에게 전달하면 됩니다. 선형 모델은 기존 로직의 틀을 유지한 채 파라미터만 바꾸면 되기 때문에 구현 난이도가 매우 낮습니다. 피쳐 정규화나 간단한 튜닝을 고려해도 일주일이면 충분합니다.
이렇게 간단히 시도해보면, “이 피쳐에 AI를 넣는 것이 정말 중요한가?”를 빠르게 가늠할 수 있습니다. 클릭률이나 체류 시간이 몇 퍼센트 늘어났는지를 보고, 더 큰 모델을 썼을 때 얼마나 더 개선될지, 그리고 그 변화가 매출이나 리텐션에 어떤 영향을 줄지를 가늠해볼 수 있습니다.
딥러닝을 잘한다고 해서 모든 문제를 딥러닝으로 푸는 건 낭비일 때가 많습니다. 문제의 크기에 맞는 모델을 선택하고, 그 문제가 정말 중요한지 다시 평가하고, 중요하다면 그때 리소스를 집중하는 이터레이션이 필요하다고 생각합니다.