Joonyoung Yi

폼은 일시적이지만 클래스는 영원하다, ML에서도

2026-01-27T00:00:00+09:00

AI는 정말 빠르게 발전하고 있습니다. 하루에도 수백 개의 논문이 쏟아지고, 새로운 모델과 아이디어가 등장합니다. 이 모든 걸 잘 따라가시는 분들이 있고, 저는 그분들이 정말 대단하다고 생각합니다. 하지만 솔직히 저는 벅찹니다. 그래서 오히려 그럴수록, 다시 근본으로 돌아가려고 합니다.

폼은 일시적이지만 클래스는 영원하다.

ML에서는 이 말이 더 직접적으로 느껴집니다. 최신 모델을 하나 더 아는 것보다, 왜 그 모델이 나왔는지 설명할 수 있는 편이 훨씬 오래 갑니다. 트렌드는 바뀌어도 가정은 남고, 실수는 대개 그 가정을 놓칠 때 반복되기 때문입니다.

기본 개념에 다시 질문을 던지기

제가 선택한 방법은 ML의 기본 개념들을 다시 공부하는 것입니다. 지금의 ML 발전 방향이 기본 개념들과 일치한다면 왜 일치하는지, 다르다면 어떤 가정이 깨졌기 때문에 다른지를 생각해봅니다. 이상하게 들릴 수도 있지만, 이렇게 다시 복습할 때마다 예전에 놓쳤던 개념들이 새롭게 보입니다. 그리고 그 순간, 최신 ML의 발전 방향도 결국 우리가 과거에 배웠던 몇몇 개념 안에서 움직이는 것처럼 느껴집니다.

예를 들어 bias-variance trade-off를 다시 보면, MSE loss가 편향(bias), 분산(variance), 줄일 수 없는 잡음(irreducible noise)으로 분해된다는 걸 다시 떠올리게 됩니다. 아래 그림은 이 세 성분을 그대로 쌓아 올린 것입니다. 맨 위 검은 선이 세 성분의 합인 전체 test error인데, model capacity가 커질수록 bias 성분은 줄어들고 variance 성분은 커지며, 맨 아래 irreducible noise는 capacity를 아무리 키워도 그대로 남습니다. 그래서 전체 오차가 가장 낮아지는 지점은 그 사이 어딘가에 있습니다.

이 그림을 다시 그려보고 나서 이런 질문들을 스스로에게 던집니다.

분류 문제의 loss도 이와 같은 방식으로 분해할 수 있을까?
scaling law와는 어떤 관계가 있을까?
왜 NLP에서는 irreducible noise가 거의 보이지 않는 것처럼 느껴질까?
몇몇 vision task는 scaling 하더라도 성능이 saturation될 때가 있는데, 이건 irreducible noise 때문일까?

이 중 scaling law 질문은 위 그림을 한 번 더 확장하면 실마리가 보입니다. 위 그림에서 우리가 움직일 수 있는 손잡이는 model capacity 하나뿐이었지만, 실제로 우리 손에는 손잡이가 둘 있습니다. bias는 모델을 키워서 줄이고, variance는 데이터를 늘려서 줄입니다. 아래 그림은 데이터를 2배씩 늘려가며 전체 test error 곡선을 다시 그린 것입니다. 데이터가 많아질수록 variance 성분이 눌려 곡선 전체가 내려가고, 각 곡선의 최저점 (점으로 표시)은 더 큰 capacity 쪽으로 이동합니다. 이 최저점들을 이은 빨간 점선이 scaling law가 말하는 frontier입니다. 모델과 데이터를 함께 키우는 한 test error는 irreducible noise를 향해 계속 내려갑니다.

이런 질문을 하다 보면 단순히 고전적인 ML 개념들의 공식만 기억하는 게 아니라, 그 안의 의미를 이해하게 됩니다.

또 대부분의 ML 모델은 데이터가 i.i.d.(independent and identically distributed)라고 가정합니다. 여기서도 같은 방식으로 질문을 이어갑니다.

왜 우리는 i.i.d.를 가정해야 하지?
이 가정이 깨지면 어떤 일이 일어나지?
내가 지금 회사에서 풀고 있는 문제는 i.i.d. 가정을 잘 지키고 있을까?
만약 안 맞는다면 그걸 어떻게 다뤄야 하지?
LLM의 post-processing 단계에서 다루는 문제들도, 결국 데이터의 분포가 i.i.d. 가정에서 얼마나 벗어나 있는가와 관련이 있지 않을까?

이런 식으로 기본 개념들을 다시 돌아보면, 현대 ML의 발전 방향을 좀 더 높은 추상화 층위에서 사고할 수 있습니다. 새로운 논문이 매일 쏟아져도, 그 원리를 이미 알고 있다면 훨씬 빠르게 이해할 수 있습니다. 저에게 기본기를 공부한다는 건 단순히 과거를 되짚는 일이 아니라, 변화의 방향을 빠르게 이해하는 데 도움을 받는 일입니다. 그래서 빠르게 변하는 시대일수록, 저는 기본에 충실하고 각 발전 방향을 기본 원칙에 대입해 사고하려고 합니다.

도구에서 이론으로

처음 프로그래밍을 배우는 분들께 저는 늘 쉬운 언어부터 시작하시라고 말씀드립니다. Python과 같은 언어로 흥미를 붙인 뒤, 필요할 때 C처럼 저수준 언어를 익히며 내부 동작을 이해하는 편이 훨씬 효율적이라고 생각합니다. 세상엔 배울 것이 너무 많고 우리의 시간은 한정되어 있기 때문입니다.

머신러닝도 크게 다르지 않습니다. 처음엔 자연스럽게 도구 중심으로 ML에 접근하게 됩니다. PyTorch 같은 현대적인 프레임워크를 쓰다 보면 여러 모델을 레고 블록처럼 조립하며 감을 익힐 수 있고, 이런 경험은 실제로 빠른 성장을 도와줍니다. 하지만 현업에서 더 깊은 문제를 해결하려면 이 도구들을 떠받치는 이론적 기반을 이해하고, 그 기반을 실제 업무에 어떻게 적용할지 생각할 수 있어야 합니다. 결국 기본기가 있어야 시행착오를 줄이고, 더 본질적인 질문을 던지게 됩니다.

가장 익숙한 예인 linear regression을 떠올려보면 이를 더 쉽게 이해할 수 있습니다. linear regression은 deep networks의 토대가 되는 모델입니다. 은닉층을 추가하면 deep networks의 가장 기본적인 형태인 multi-layer perceptron이 됩니다. universal approximation theorem에 의해 multi-layer perceptron을 단순한 function approximator로 바라볼 수도 있습니다. 하지만 universal approximation theorem은 얼마나 많은 capacity와 데이터가 필요한지는 말해주지 않습니다. 따라서 deep networks를 단순 function approximator로 추상화해서 이해하는 것과 함께, linear model의 확장임을 이해해야 regularization에 대한 깊은 이해를 갖고 현실에서 더 효율이 좋은 모델을 만들 수 있습니다.

왜 하필 MSE인가

linear regression을 처음 접하면 기본적으로 least square error인 MSE loss를 가정하게 됩니다. 왜 regression 문제에서 MSE loss를 기본으로 쓸까요? 오차항을 Gaussian으로 가정하면 다음과 같은 가능도 모형이 자연스럽게 생깁니다.

$$ p(y \mid x, w) = \mathcal{N}(y; w^\top x, \sigma^2) $$

이 식은 관측값이 평균이 $w^\top x$인 Gaussian에서 나왔다는 뜻입니다. 이 가정 아래 최대우도추정(maximum likelihood estimation)을 하면, 결국 MSE를 최소화하는 문제와 같은 방향으로 갑니다. 그리고 그 가정의 배경에는 중심극한정리(central limit theorem)가 있습니다. 여러 작은 요인의 합으로 오차가 형성된다고 보면 Gaussian 가정은 아주 뜬금없는 출발점이 아닙니다.

linear regression에서의 이런 생각의 흐름을 deep networks에서도 그대로 적용할 수 있다는 것까지 이해하면, deep networks에서 regression 문제를 풀 때 MSE loss를 쓰는 게 자연스러워집니다. 그리고 MSE loss 외에 다른 loss를 쓰려면 충분한 rationale이 필요하다는 것을 이해하게 됩니다. regression에서 성능이 나오지 않을 때 그저 잘되기를 바라면서 다양한 loss를 실험해보는 것은 지양하게 됩니다. 회사에서의 AI는 오늘의 데이터에만 잘 작동하는 것이 아니라 내일과 N일 후의 데이터에서도 잘 동작해야 하기 때문에, marginal한 향상이 있는 방법론보다는 오랫동안 안정적으로 잘 동작하는 방법론을 선택하는 것이 기본입니다.

그렇다면 MAE loss는 언제 합리적일까요? MSE는 조건부 평균을, MAE는 조건부 중앙값을 추정합니다. 이 사실을 수식으로 적으면 다음과 같습니다.

$$ \min_f \mathbb{E}\big[|Y - f(X)|\big] $$

이 목적은 중앙값을 추정하는 방향으로 해석할 수 있습니다. 중앙값이 평균보다 적합한 상황, 예를 들어 heavy-tailed noise나 이상치가 많은 경우라면 MAE가 자연스러운 선택이 됩니다. 이 개념을 이해하면 MAE loss를 일반화해 quantile regression까지도 확장해볼 수 있습니다.

그럼 이걸 알면 현업의 어떤 부분에서 도움을 받을 수 있을까요? 우리는 종종 deep networks에서 불확실성을 모델링해야 할 필요가 있습니다. 이때 quantile regression을 한 가지 방법으로 고려해볼 수 있습니다. 특히 UCB(upper confidence bound)가 필요한 상황에서 아주 간단하게 불확실성을 모델링하고 baseline으로 사용할 수 있게 됩니다. 이런 내용들에 대한 이해가 얕으면, 불확실성을 모델링하기 위해 가장 유명한 Monte Carlo dropout 방법을 일단 시도하게 되고, 현실적으로 overconfident 문제 등 제대로 불확실성이 모델링되지 않는 현상을 경험하면서 시행착오가 늘어납니다.

Ridge regression이 보여주는 연결

ML 연구를 더 잘하려면 근간이 되는 ML 이론을 더 잘 이해해야 합니다. linear regression을 공부하면 자연스럽게 ridge regression을 접하게 됩니다. ridge regression은 vanilla linear regression의 overfitting 문제를 해결하기 위해 등장한 매우 기본적이면서 강력한 방법입니다. loss에 L2 regularization을 추가하는 형태로 쓸 수 있습니다.

$$ \min_w \mathcal{L}_{\mathrm{mle}}(w) + \lambda \Vert w \Vert_2^2 $$

이 식은 데이터에 대한 적합도와 가중치 크기 사이의 균형을 직접 조절한다는 뜻입니다. 해석은 더 있습니다. 각 가중치가 서로 독립이면서 분산이 동일한 Gaussian prior를 따른다고 가정하면, ridge regression을 최대사후추정(maximum a posteriori, MAP) 문제로 해석할 수 있습니다. 이 관점에서는 정규화 항이 단순한 벌점이 아니라, 사전 믿음을 수학적으로 넣은 결과가 됩니다.

이 가정이 존재하기 때문에 ridge regression에서는 input feature들끼리 비슷한 분포가 되게 만드는 정규화가 필요합니다. 입력되는 feature들의 분포가 너무 다르면, 가중치마다 분산이 동일하다는 prior를 주는 것이 좋지 않은 가정이 되기 때문입니다. 이 내용은 deep networks에서도 동일하게 적용되어, tabular learning을 할 때 multi-layer perceptron뿐 아니라 TabPFN, TabTransformer, FT-Transformer 등 최신 tabular learning 모델들에서도 feature 정규화를 기본적으로 채택하고 있습니다. 모델이 새로워져도, 입력 분포를 정리해야 한다는 감각은 오래 바뀌지 않습니다.

ridge regression을 제약식으로 다시 쓰면 이 관계가 더 또렷해집니다. KKT 조건이 성립한다고 가정할 때, 위의 식은 vanilla regression의 목적식에 다음과 같은 제약이 붙는 형태로 해석할 수 있습니다.

$$ \min_w \mathcal{L}_{\mathrm{mle}}(w) \quad \text{s.t.} \quad \Vert w \Vert_2 \le k $$

$\lambda$가 커질수록 가중치는 더 작아지고, model capacity가 줄어들며, 결국 overfitting을 방지하게 됩니다. 이는 분산을 줄여 generalization을 더 잘 달성하기 위한 맥락으로 이해할 수 있습니다. 저는 이 지점을 이해하면 “정규화는 그냥 과적합 방지 장치”라는 말보다 한 단계 더 깊게 볼 수 있다고 생각합니다. 정규화는 실제로 모델이 허용받는 해의 공간을 바꾸는 일입니다.

위와 같이 ridge regression에서 primal-dual 관계를 이해하면 여러 deep networks 논문도 다른 관점으로 이해할 수 있습니다. loss에 여러 항들이 들어가 있으면, KKT 조건이 만족하지 않더라도 각각이 어떤 제약식으로 동작하는지 생각해볼 수 있고, 제약식이 많아지면 많아질수록 하이퍼파라미터 튜닝에 어려움을 겪을 수 있다는 것도 이해할 수 있습니다. 그러면 연구할 때 loss가 다양한 항들로 구성된 논문들은 baseline 등으로 선택할 때 한 번 더 생각하게 됩니다.

마무리

기본기를 공부한다는 것은 과거로 돌아가는 일이 아닙니다. 오히려 새 기법을 더 빨리 이해하기 위해, 그 기법이 기대고 있는 오래된 언어를 다시 익히는 일에 가깝습니다. MSE가 왜 나왔는지, MAE가 언제 맞는지, ridge regression이 왜 MAP로 읽히는지, feature 정규화가 왜 자연스러운지까지 연결해서 보면, 새 논문은 더 이상 완전히 낯선 것이 아닙니다. 어디에서 왔는지 보이기 시작합니다.

현업에서도 이 차이는 작지 않습니다. 사용하는 모델의 바탕에 깔린 원리를 이해해야 더 잘할 수 있고, 그 차이가 실질적인 성과와 속도 차이로 이어집니다. 기본기를 알고 있으면 문제를 만났을 때 먼저 가정을 점검하게 되고, 그 덕분에 시행착오를 줄일 수 있습니다. 무엇이 바뀌었는지보다 무엇이 안 바뀌었는지를 빨리 찾는 편이 더 유리할 때가 많습니다.

HYPERCONNECT AI 조직은 늘 구성원들의 기본기를 탄탄하게 만들기 위해 노력하고 있으며, 기본기가 탄탄한 분들을 찾고 있습니다. ML fundamental을 실질적인 비즈니스 임팩트로 이어가고 싶으신 분들을 열심히 찾고 있습니다!

결국 클래스는 폼보다 오래 갑니다. 모델 이름은 바뀌어도, 가정과 해석과 추론의 습관은 남습니다. 저는 그 습관을 조금 더 천천히, 그러나 더 정확하게 쌓아가려 합니다.

비즈니스 문제를 AI 문제로 정렬하는 방법

2026-01-12T00:00:00+09:00

AI 조직은 비즈니스 문제를 AI 문제로 정렬해서 푸는 조직입니다. AI 문제란 무엇일까요? 우리가 현업에서 정말 다양한 업무들을 하지만, 본질은 효용 함수(또는 손실 함수)를 최적화하는 문제입니다. 명시적이든 암시적이든, 우리는 문제를 최적화 식(optimization form)으로 쓰게 됩니다. ML 알고리즘을 통해 최적화 식의 해(solution)를 찾고, 이 해를 이용해 비즈니스 문제를 풉니다. 결국, AI 조직은 수학적 해를 통해 비즈니스의 해를 찾아가는 조직입니다.

비즈니스 문제는 본질적으로 어렵습니다. 그렇다면 우리는 이런 어려운 문제를 어떻게 풀어야 할까요? 최적화 이론에서는 이런 어려운 문제를 풀기 쉬운 문제로 완화(relaxation)해서 풉니다. 특히, 여러 개의 지역(local) 최솟값에 갇힐 수 있는 비볼록(non-convex) 문제를 볼록(convex) 문제로 바꾸어 해결하는 방법들을 중요하게 다룹니다. 볼록 문제는 지역 해가 곧 전역 해인 아름다운 성질을 가지는 덕분에 우리는 경사 하강(gradient descent) 같은 단순한 방법으로도 전역 최적해를 찾을 수 있습니다. 그래서 최적화 이론에서는 비볼록 문제를 볼록 문제로 바꾸는 변환 과정을 볼록 완화(convex relaxation)라고 부르며, 어려운 문제를 풀 수 있는 형태로 재정의하는 방법 중 하나로 중요하게 다룹니다.

직접적으로 풀기 어려운 비즈니스 문제도, 최적화 이론에서 제시하는 것처럼 풀 수 있는 형태로 완화(relaxation)하면 훨씬 다루기 쉬워집니다. 완화된 문제를 잘 설계하면, 비록 원래의 복잡한 비즈니스 문제를 직접 푸는 것은 아니더라도, 그 해가 원래 문제(original problem)의 해와 충분히 유사한 결과를 만들어낼 수 있습니다. 실제로 AI 조직에서 다루는 문제의 대부분은 의식적으로든 무의식적으로든 이러한 완화된 형태를 띱니다. 예를 들어, 어떤 AI 기능을 개발하기 위해 분류기(classifier)를 만든다고 해봅시다. 우리가 진정으로 개선하고자 하는 것은 특정 비즈니스 지표일 것입니다. 하지만 현실적으로 그 지표를 직접 최적화하기는 어렵기 때문에, 대신 우리는 “분류기를 잘 학습시키는 문제”로 바꾸어 풉니다. 이 분류 문제는 원래의 비즈니스 목표를 근사적으로 대변하는 완화된 문제(relaxed problem)라고 볼 수 있습니다. 결국, AI 조직은 비즈니스 문제를 바로 푸는 대신, 그 문제를 AI 문제로 적절히 완화하고, 그 완화된 문제를 최적화함으로써 비즈니스 임팩트를 만들어내는 조직이라 할 수 있습니다.

Preliminary: Convex Relaxation

원래의 문제를 “잘” 완화한다는 것은 무엇일까요? 이 질문에 대한 좋은 힌트는 convex relaxation에서 찾을 수 있습니다. 우리는 머신러닝을 처음 배울 때 거의 예외 없이 Lasso regression을 접하게 됩니다. 그 이유는 단순합니다. Lasso는 “풀기 어려운 문제를 풀기 쉬운 형태로 바꾸는” convex relaxation의 가장 대표적인 예이기 때문입니다. 우선, 기본이 되는 선형회귀(linear regression)를 생각해봅시다.

$$ \arg\min_{\beta} \| y - X\beta \|_2^2 $$

이 문제는 모든 변수(feature)를 그대로 사용하는 회귀식입니다. 하지만 우리는 종종 모델이 너무 복잡해지는 것을 피하고 싶습니다. 일부 계수($\beta_i$)만 남기고 나머지는 0으로 만들어, sparse한 해를 얻고 싶은 거죠. 그렇게 하려면 다음과 같은 제약식을 추가해야 합니다.

$$ \arg\min_{\beta} \| y - X\beta \|_2^2 \quad \text{s.t. } \|\beta\|_0 \le k $$

여기서 $\|\beta\|_0$은 0이 아닌 계수의 개수를 세는 항으로, “전체 변수 중 최대 $k$개만 사용할 수 있다”는 제약을 뜻합니다. 하지만 이 문제는 모든 feature subset을 탐색해야하는 조합 최적화(combinatorial optimization) 문제이기에 해를 찾는 데 지수적 탐색이 필요합니다. 다시 말해, 현실적으로 풀기 어렵습니다.

그래서 등장한 것이 Lasso regression입니다.

$$ \arg\min_{\beta} \|y - X\beta\|_2^2 + \lambda \|\beta\|_1 $$

Lasso는 원래의 $\ell_0$ 제약 조건을 $\ell_1$ 정규화 항으로 바꾸어, 문제를 볼록하게 만듭니다. 이렇게 하면 경사하강법 같은 간단한 방법으로도 해를 안정적으로 구할 수 있습니다. 이 변환이 바로 convex relaxation입니다. 즉, 원래의 “풀기 어려운” 조합 최적화 비볼록 문제를 “풀기 쉬운” 볼록 문제로 완화한 것입니다.

물론, 두 문제의 해가 항상 동일하지는 않습니다. 하지만, 몇 가지 가정(mutual incoherence condition, restricted isometry property)이 만족되면, Lasso의 해는 원래 문제의 해와 거의 동일하거나 동일하게 일치한다는 것이 증명되어 있습니다. 이런 의미에서, Lasso는 “잘 완화된 문제”의 대표적인 사례입니다. 정리하자면, 아래와 같습니다.

$$ \underbrace{\arg\min_{\beta} \|y - X\beta\|_2^2 \ \text{s.t. } \|\beta\|_0 \le k}_{\text{original problem}} \quad \text{vs.} \quad \underbrace{\arg\min_{\beta} \|y - X\beta\|_2^2 + \lambda \|\beta\|_1}_{\text{relaxed problem}} $$

우리가 Lasso regression 문제를 푼다는 것은 결국 “풀기 어려운 원래 문제를 풀 수 있는 비슷한 문제로 바꾼 뒤 최적화하는 것”입니다. 그리고 몇 가지 가정 아래에서 원래 문제와 완화된 문제의 해가 거의 같습니다.

Convex relaxation에서 우리가 진짜로 주목해야 하는 것은 단순히 문제를 쉽게 바꾸는 기술이 아닙니다. “언제 원래 문제와 완화된 문제를 사실상 같은 것으로 볼 수 있는가”를 이해하는 일입니다. Lasso의 예에서처럼, 우리는 비볼록($\ell_0$) 문제를 볼록($\ell_1$) 문제로 바꾸지만 두 문제의 해가 항상 같지는 않습니다. 두 문제를 동일한 문제로 간주하려면 몇 가지 가정이 필요합니다. 몇몇 가정들이 충족될 때에만 두 문제가 사실 상 동일한 문제로 간주할 수 있습니다.

비즈니스 문제를 AI로 문제로 치환할 때에도 동일하게 적용됩니다. 현실의 비즈니스 문제는 복잡하고, 여러 지표가 얽혀 있어 직접적으로 풀기 어렵습니다. 이런 문제를 AI 문제로 바꾸어 풀기 위해서는 명시적인 가정을 세워야 합니다. 그리고 그 가정이 타당한지를 제품 환경에서의 A/B 테스트로 검증하게 됩니다. 만약 완화된 문제를 잘 풀었는데도 비즈니스 지표가 개선되지 않았다면, 이는 우리가 세운 가정 중 일부가 현실과 맞지 않았다는 뜻입니다. 이때는 가정을 다시 점검하고, 다른 방식으로 문제를 완화해 새롭게 접근해야 합니다.

정리하자면, “잘 완화한다는 것”의 핵심은 세 가지입니다. 첫째, 완화된 문제의 해가 원래 문제의 해와 충분히 유사해야 합니다. 둘째, 두 문제의 유사성을 보장하기 위한 가정들을 명시적으로 세워야 합니다. 셋째, 그 가정들이 현실에서 타당한지 A/B 테스트를 통해 지속적으로 검증해야 합니다. Lasso에서 mutual incoherence condition 같은 가정들이 만족될 때 원래 문제와 완화된 문제의 해가 유사해지듯이, 비즈니스 문제를 AI 문제로 완화할 때도 우리가 세운 가정들이 현실과 부합할 때 비즈니스 임팩트를 만들어낼 수 있습니다.

비즈니스 문제를 어떻게 AI 문제로 완화할까?

이제 실제 사례를 통해 비즈니스 문제를 AI 문제로 완화하는 과정을 구체적으로 살펴보겠습니다. HYPERCONNECT의 과거 시스템에서 사용되었던 접근 방식을 예시로 들어 설명하겠습니다. 아자르에서 AI 기반 추천 시스템을 만들어 사람들을 실시간으로 더 잘 매칭시켜줘야 한다고 해봅시다. 추천 시스템은 유저들을 일정한 주기로 모으고 이 유저들 중에 어떤 유저들끼리 매칭시킬지를 결정합니다. 비즈니스 문제를 AI 문제로 치환해본 경험이 없더라도 대부분의 AI PM 혹은 연구자들은 이런 시스템을 고안할 가능성이 큽니다. 두 유저 사이의 대화 시간을 예측하는 모델을 만들고, 예측 대화 시간이 높은 유저 쌍 순서대로 매칭시켜 줍니다. 그럼 우리가 실제 푸는 문제는 아래와 같은 대화 시간을 예측하는 문제로 바뀌게 됩니다. 즉, 비즈니스 문제를 풀기 위해 대화 시간 예측을 잘 하는 새로운 완화된 문제를 풉니다.

$$ \text{minimize } \sum_{u,p,c \in \mathcal{D}} \mathcal{L}(c, f(u,p)) $$

여기서 $u$는 유저, $p$는 매칭 상대 유저(파트너), $c$는 실제 대화 시간, $f(u,p)$는 유저 $u$와 파트너 $p$의 대화 시간을 예측하는 함수, $\mathcal{L}$은 손실 함수, $\mathcal{D}$는 학습 데이터셋을 의미합니다.

비즈니스에서의 최종 목표는 장기 매출(long-term revenue)의 극대화입니다. 하지만 “장기 매출을 최적화하라”는 문장은 실제로는 너무 복잡하고 애매해서 바로 최대화하기 어렵습니다. 매출은 수많은 요인(사용자 유입, 리텐션, 구매 전환율, 결제 금액, 콘텐츠 품질, 시장 요인 등)이 얽힌 비선형적 결과이기 때문입니다. 우리는 이 거대한 비볼록 문제를 그대로 풀 수 없습니다.

$$ \text{maximize } (\text{long-term-revenue}) $$

장기 매출 최대화 문제는 그대로 풀기 어렵기 때문에, 먼저 지금보다 문제를 조금 더 단순하게 만들 필요가 있습니다. 먼저, 오늘을 day $0$이라고 할 때, 오늘로부터 $N$일 후인 day $N$의 매출을 $\text{revenue}_{N}$이라고 합시다.

$\textbf{Assumption 1.}$ $N$이 충분히 크면, 시스템이 정상 상태(steady state)에 도달하여 day $N$의 매출이 장기 매출을 대표할 수 있다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =\ & \text{maximize } (\text{revenue}_N) \end{aligned} $$

$\textbf{Assumption 1}$을 통해 장기 매출 최대화 문제를 조금 더 쉬운 문제로 완화하였습니다. 하지만, $\text{revenue}_N$은 직접 최적화하는 문제는 아직 어렵습니다. 더 문제를 쉽게 바꿀 필요가 있습니다. 이를 위해 제품 분석에서 표준적으로 사용되는 다음과 같은 방식으로 $\text{revenue}_N$을 분해할 수 있습니다.

$$ \text{revenue}_N = \text{DAU}_N \times \text{PUR}_N \times \text{ARPPU}_N $$

여기서 $\text{DAU}_N$는 $N$일째의 활성 사용자 수(Daily Active Users), $\text{PUR}_N$은 $\text{DAU}_N$ 중 구매자의 비율(Purchase User Rate), $\text{ARPPU}_N$는 $N$일째의 구매자 1인당 매출(Average Revenue Per Paying User)을 의미합니다.

$\textbf{Assumption 2.}$ $\text{DAU}_N$을 변화시켜도 $\text{PUR}_N$과 $\text{ARPPU}_N$이 변하지 않는다.

실제로는 우리의 액션에 따라 $\text{DAU}_N$, $\text{PUR}_N$, $\text{ARPPU}_N$ 세 가지 지표가 모두 변화할 수 있습니다. 하지만, 문제를 단순화하기 위해 모든 요인을 동시에 최적화하기보다는 일부 요인을 고정하고 다른 요인에 집중하는 가정을 세울 수 있습니다. $\textbf{Assumption 2}$ 가정 아래에서 장기 매출 최대화 문제를 아래와 같이 완화할 수 있습니다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =\ & \text{maximize } (\text{revenue}_N) \\ =\ & \text{maximize } (\text{DAU}_N) \end{aligned} $$

하지만 $\text{DAU}_N$을 직접 최대화하는 것도 여전히 어렵습니다. 따라서 추가적인 가정이 필요합니다.

$\textbf{Assumption 3.}$ DAU는 carrying capacity 가설에 의해 $N$이 충분히 클 때, $\text{DAU}_N$을 아래와 같이 표현할 수 있다.

$$ \text{DAU}_N = \frac{\text{inflow}_0}{1 - \text{retention}_0} $$

여기서 $\text{retention}_i$은 day $i$의 활성 유저를 코호트로 잡을 때의 D1 리텐션을 의미하며, $\text{retention}_0$은 오늘 활성화된 유저들의 D1 리텐션, 즉 오늘 활성화된 유저들이 내일도 방문하는 비율을 의미합니다. $\text{inflow}_i$는 day $i$에 유입되는 유저(신규 유저 + 부활 유저)를 의미합니다. 물론, DAU가 위 모형보다 더 복잡한 모형을 따른다고 가정할 수도 있지만, 일단 문제를 더 쉽게하기 위해 매우 간단한 모형을 가정해보기로 합니다.

$\textbf{Assumption 4.}$ $\text{inflow}_0$는 우리가 변경할 수 없다.

$\text{inflow}_0$를 우리가 바꿀 수 없다는 추가 가정을 두면, 결국 $\text{DAU}_N$을 최대화하는 문제는 오늘의 D1 리텐션을 높이는 문제로 완화할 수 있습니다. $\textbf{Assumption 1-4}$을 적용하면, 장기 매출 최대화 문제는 리텐션 최대화 문제로 완화됩니다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =\ & ... \\ =\ & \text{maximize } (\text{DAU}_N) \\ =\ & \text{maximize } (\text{retention}_0) \end{aligned} $$

하지만, 리텐션을 최대화하는 문제도 여전히 어렵습니다. 그래서 한 번 더 완화가 필요합니다. 이전 테크 블로그에서 밝혔듯이, 아하 모멘트 프레임워크로 리텐션을 올리는 더 쉬운 1차 지표를 찾을 수 있습니다. 아하 모멘트 프레임워크를 통한 분석을 통해 $\textbf{Assumption 5}$를 찾았다고 가정해봅시다.

$\textbf{Assumption 5.}$ $\text{DAU}_0$ 중에서 $X$분 이상 채팅한 유저의 비율을 올리면 $\text{retention}_0$이 올라간다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =\ & ... \\ =\ & \text{maximize } (\text{retention}_0) \\ =\ & \text{maximize } (\text{DAU}_0 \text{ 중에 } X \text{분 이상 채팅한 유저의 비율}) \end{aligned} $$

아래의 $\textbf{Assumption 6}$을 추가하면, $\text{DAU}_0$ 중에서 $X$분 이상 채팅한 유저의 수를 최대화하는 문제로 장기 매출 최대화 문제를 한번 더 완화할 수 있습니다.

$\textbf{Assumption 6.}$ $\text{DAU}_0$의 수는 우리가 제어할 수 없는 것이다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =\ & ... \\ =\ & \text{maximize } (\text{DAU}_0 \text{ 중에 } X \text{분 이상 채팅한 유저의 비율})\\ =\ & \text{maximize } (\text{DAU}_0 \text{ 중에 } X \text{분 이상 채팅한 유저의 수}) \end{aligned} $$

하지만 $\text{DAU}_0$ 중에서 $X$분 이상 채팅한 유저 수를 직접 최대화하는 것도 여전히 어렵습니다. 이를 더 단순화하기 위해, $\mathcal{U}_i$를 day $i$에 활성화된 유저들의 집합이라고 정의할 때 다음과 같은 가정을 추가로 해볼 수 있습니다.

$\textbf{Assumption 7.}$ $\text{DAU}_0$ 중에서 $X$분 이상 채팅한 유저 수를 최대화하는 문제는 각 유저 $u \in \mathcal{U}_0$에 대해 그날 경험한 총 대화 시간을 최대화하는 문제와 같다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =~& ... \\ =\ & \text{maximize } (\text{DAU}_0 \text{ 중에 } X \text{분 이상 채팅한 유저의 수}) \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}_0} (\text{유저 } u \text{가 그날 경험한 총 대화 시간}) \end{aligned} $$

아자르 추천 시스템은 일정한 주기(틱)로 유저들을 모아 매칭을 수행합니다. 우리가 할 수 있는 것은 유저 $u$의 그날 경험을 제어하는 것이라기 보다는, 한 틱 안에 $N$명이 모여있을 때 그 $N$명의 사람들을 어떻게 매칭시켜줄지를 제어하는 것에 가깝습니다.

$\textbf{Assumption 8.}$ 각 틱은 독립적인 매칭 라운드로 한 틱에서의 매칭 결과가 다른 틱의 매칭에 영향을 주지 않는다.

각 틱이 독립적이라고 가정하면, 임의의 틱 $t$에 대해 그 틱 안의 유저 $u \in \mathcal{U}_0^t$가 경험한 대화 시간을 최대화하는 문제로 완화할 수 있다고 볼 수 있습니다.

$$ \begin{aligned} & \text{maximize } (\text{long-term-revenue}) \\ =~& ... \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}_0} (\text{유저 } u \text{가 그날 경험한 총 대화 시간}) \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}_0^t} (\text{유저 } u \text{가 틱 } t \text{ 안에서 경험한 대화 시간}) \end{aligned} $$

이제 이 최적화 문제를 그래프 이론의 관점에서 재해석해봅시다. 아자르의 매칭 시스템은 각 유저를 정확히 한 명의 피어 유저와 1:1로 매칭시킵니다. 즉, 틱 $t$에 모인 $|\mathcal{U}_0^t|$명의 유저들을 $\lfloor |\mathcal{U}_0^t|/2 \rfloor$개의 쌍으로 나누는 것입니다. 유저 $u$가 피어 $p$와 매칭되면, 유저 $u$가 틱 $t$ 안에서 경험하는 대화 시간은 $u$와 $p$ 간의 대화 시간과 동일합니다. 따라서 전체 대화 시간의 합은 모든 매칭된 쌍 $(u, p)$의 대화 시간의 합과 같습니다. 이를 그래프로 모델링하면 다음과 같습니다:

각 유저 $u \in \mathcal{U}_0^t$를 그래프의 노드로 표현합니다.
임의의 두 유저 $u$와 $p$ 사이에 간선(edge)을 그립니다.
간선의 가중치(weight)는 두 유저가 만났을 때의 대화 시간으로 설정합니다.

이제 “모든 매칭된 쌍의 대화 시간 합을 최대화”하는 문제는, 그래프에서 각 노드가 최대 하나의 간선에만 포함되도록 간선들을 선택하여 선택된 간선들의 가중치 합을 최대화하는 문제가 됩니다. 이것이 바로 최대 가중치 매칭(maximum weight matching) 문제입니다. 최대 가중치 매칭 문제를 최적으로 풀기 위해서 Blossom 알고리즘 등 다양한 방법들이 존재합니다. 하지만, 문제를 더 쉽게 만들기 위해 아래 가정을 추가합니다.

$\textbf{Assumption 9.}$ 탐욕(greedy) 알고리즘을 통해 최대 가중치 매칭 문제를 푼다.

다행히도 $\textbf{Assumption 9}$는 과도하게 강한 가정은 아닙니다. 탐욕 알고리즘이 최적해의 간선 가중치 합의 절반 이상을 보장한다는 것이 이론적으로 증명되어 있기 때문입니다.

마지막으로, 간선 가중치를 정확히 계산하기 위해서는 두 유저가 만났을 때의 대화 시간을 알아야 합니다. 하지만 두 유저가 실제로 만나기 전까지는 이 값을 알 수 없습니다. 따라서 $\mathcal{U}_0^t$의 임의의 두 유저가 만났을 때 얼마나 오래 대화할지 예측하는 문제를 풀어야 합니다. $\textbf{Assumption 9}$에 따라 예측된 대화 시간이 높은 순서대로 탐욕 알고리즘으로 매칭을 수행한다면, 대화 시간 예측기의 예측 오차를 최소화하는 것이 전체 대화 시간 합을 최대화하는 것과 동일한 문제가 됩니다.

$$ \begin{aligned} &\text{maximize } (\text{long-term-revenue}) \\=~& \dots \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}_0^t} (\text{유저 } u \text{가 틱 } t \text{ 안에서 경험한 대화 시간}) \\ =\ & \text{minimize } \sum_{u,p,c \in \mathcal{D}} \mathcal{L}(c, f(u,p)) \end{aligned} $$

결국, 장기 매출 최대화 문제는 굉장히 많은 가정들을 통해 대화 시간 예측기를 만드는 문제로 변화합니다. 이 최종 형태는 많은 AI PM이나 연구자들이 직관적으로 생각하는 접근법과 동일합니다. 하지만 중요한 차이점은, 우리가 어떤 가정들을 통해 이 문제로 도달했는지를 명시적으로 알고 있다는 것입니다. 흔히 추천 시스템에서 “CTR이나 시청 시간 같은 1차 지표를 올리는 것과 비즈니스 임팩트는 큰 관계가 없다”는 지적이 나오곤 하는데요, 이런 현상이 발생하는 이유는 우리가 만든 암시적 가정 중 일부가 현실에서 동작하지 않기 때문입니다. 어떤 가정이 깨졌는지, 그리고 그에 따라 어떻게 문제를 재정의해야 하는지를 이해해야만 비로소 비즈니스 임팩트를 만들어낼 수 있습니다.

그럼, 위에서 도출한 9개의 가정을 바탕으로 아자르에 적용했을 때 결과는 어떻게 됐을까요?

아래 그림에서 볼 수 있 듯 리텐션은 사상 최고치를 기록했습니다. 이 결과를 통해 $\textbf{Assumption 3-9}$는 어느 정도 성립했다고 볼 수 있습니다. 리텐션이 올라갔다는 것은 이 가정들이 현실과 부합했다는 의미이기 때문입니다. 하지만, PUR(Purchase User Rate)이 떨어졌습니다. $\textbf{Assumption 2}$에서는 $\text{DAU}_N$을 변화시켜도 $\text{PUR}_N$이 변하지 않는다고 가정했지만, 실제로는 리텐션을 올리면서 PUR이 함께 변화했습니다.

그럼 이제 어떻게 해야 할까요?

$\textbf{Assumption 2}$가 필요 없도록 문제를 재정의해야 합니다. 이를 위해 장기 매출을 다른 방식으로 분해해보겠습니다. 원래 $\text{DAU}_N \times \text{PUR}_N \times \text{ARPPU}_N$로 분해했던 것을, 이번에는 $\text{purchase-user}_N \times \text{ARPPU}_N$로 분해하겠습니다. 여기서 $\text{purchase-user}_N$는 $N$일차의 일일 구매자 숫자를 의미합니다. 이렇게 분해하면 구매자의 리텐션을 올리는 문제로 접근할 수 있으며, 비슷한 가정들을 적용하면 아래와 같이 장기 매출 최적화 문제를 완화할 수 있습니다.

$$ \begin{aligned} \text{maximize } &(\text{long-term-revenue}) \\ =\ & \text{maximize } (\text{revenue}_N) \\ =\ & \text{maximize } (\text{purchase-user}_N \times \text{ARPPU}_N) \\ =\ & \text{maximize } (\text{purchase-user}_N) \\ =\ & \text{maximize } (\text{purchase-user-retention}_0) \\ =\ & \text{maximize } (\text{purchase-user}_N \text{ 중에 } X \text{분 이상 채팅한 유저의 비율}) \\ =\ & \text{maximize } (\text{purchase-user}_N \text{ 중에 } X \text{분 이상 채팅한 유저의 수}) \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}_{0, \text{purchase-user}}} (\text{유저 } u \text{가 그날 경험한 총 대화 시간}) \\ =\ & \text{maximize } \sum_{u \in \mathcal{U}^{t}_{0, \text{purchase-user}}} (\text{유저 } u \text{가 틱 } t \text{ 안에서 경험한 대화 시간}) \\ =\ & \text{minimize } \sum_{u,p,c \in \mathcal{D}_{\text{purchase-user}}} \mathcal{L}(c, f(u,p)) \end{aligned} $$

이렇게 문제를 재정의하면서, 구매자에 대한 대화 시간 예측기의 성능이 핵심적인 역할을 하게 되었습니다. 비즈니스 목표가 DAU 최대화에서 purchase-user 수 최대화로 전환됨에 따라, 예측 모델의 정확도가 최종 매출에 직접적으로 영향을 미치는 핵심 요인이 되었습니다. 문제를 재정의하여 적용한 결과, 아래 그림과 같이 비즈니스 지표에서 유의미한 개선을 확인할 수 있었습니다. 이 성과는 매치 그룹의 2023 2Q 주주서한에도 공개되었습니다.

현재 추천 모델은 3년여의 시간이 지난만큼 더 강력해졌습니다. 최근 모델에 대한 소개는 다른 블로그 포스트를 통해 소개드릴 예정입니다.

마치며

명시적 가정을 통해 문제를 완화하는 접근법의 가장 큰 장점은 문제가 발생했을 때 디버깅을 용이하게 한다는 것입니다. 이 사례에서는 $\textbf{Assumption 2}$만 깨졌고 이를 보정하여 성과를 낼 수 있었지만, 현실은 이보다 훨씬 복잡합니다.

여러 가정이 동시에 깨지는 경우가 빈번하며, 이때 어떤 가정부터 수정해야 할지 우선순위를 정해야 합니다. 또한 사용자 제품은 마케팅이나 외부 요인으로 인해 본질적으로 비정상성(non-stationary) 분포를 따르기 때문에, 한 번 성립했던 가정이 계속 유효하다고 보장할 수 없습니다. 따라서 원래 잘 작동하던 알고리즘이 갑자기 성능이 저하되는 경우도 발생합니다. 이런 상황에 대비해 기존 가정들이 여전히 유효한지, 가정이 깨졌더라도 원래 문제는 잘 해결되고 있는지를 지속적으로 모니터링하는 시스템이 필요합니다.

가정은 AI 문제에서 일종의 기술 부채입니다. 가정들은 모니터링이 지속적으로 필요할 뿐만 아니라, 추상화에 의한 레이어링을 만들어 최적 솔루션에 도달하기 어렵게 만들기도 하기에 우리는 이를 기술 부채로 바라봐야 합니다. 가정을 제거하면 제거할수록, 우리가 원하는 장기 매출 최적화에 더 가까워지고 더 견고한 시스템을 구축할 수 있습니다. 예를 들어, $\textbf{Assumption 7}$은 매우 강력한 가정이며, 이를 다른 방식으로 완화하면 더 나은 해를 찾을 수 있습니다. 실제로 추천 시스템 분야에서는 강화학습(RL) 등을 활용해 리텐션을 직접적으로 최적화하는 연구가 활발히 진행되고 있으며, 특히 빅테크 기업들에서 이런 방향으로 많은 연구가 이미 공개되어있습니다.

비즈니스 문제를 AI 문제로 치환하는 과정은 본질적으로 ‘무엇을 가정하고’, ‘어떻게 단순화할 것인가’를 결정하는 작업입니다. 모델을 만드는 것 자체는 점점 쉬워지고 있습니다. 진짜 어려운 것은 모델을 만들었을 때 원하는 비즈니스 목표가 달성되지 않았을 때, 왜 달성되지 않았는지를 파악하고 문제를 재정의하는 것입니다. HYPERCONNECT AI는 명시적인 가정을 통해 비즈니스 문제를 AI 문제로 완화하고, 이러한 가정들을 지속적으로 검증하고 관리함으로써 비즈니스 임팩트를 만들어가고 있습니다.

당신의 AI 모델이 비즈니스에 기여하지 못하는 이유

2025-12-11T00:00:00+09:00

최근 몇 년간 AI는 눈부시게 발전해왔다. 하루에도 엄청난 양의 논문이 쏟아지고, 더 큰 모델이 공개되고 있다. 아울러 AI 모델이 학습 과정에서 계산하는 오차 지표인 ‘모델 손실(loss)’은 꾸준히 개선되고 있다.

성능은 올랐는데, 왜 비즈니스는 그대로인가?

그런데 현업에서는 다른 이야기가 종종 들린다. “모델 성능이 좋아졌다고 했는데 매출은 왜 그대로일까요?”, “모델 예측 성능은 개선되었는데 왜 재방문율(retention)은 그대로일까요?”

이런 간극은 회사에서 만든 AI 모델이 비즈니스 목표와 제대로 정렬(alignment)되지 않은 데서 비롯된다.

대형언어 모델(LLM)의 발전 사례는 정렬이라는 개념을 직관적으로 보여준다. 지난 2020년 처음 공개된 GPT-3는 기술적 지표(모델 손실) 기준으로 매우 우수한 모델이었지만 대중의 반응은 제한적이었다. 반면 2년 뒤 공개된 GPT-3.5 기반의 ChatGPT는 전 세계적인 반응을 이끌어냈다.

‘어떤 방향으로 정렬되었는가’가 제품 임팩트를 좌우한다

GPT-3.5의 정확한 스펙은 공개되지 않았지만, 많은 연구자들은 두 모델의 차이를 만든 결정적 요인으로 정렬을 꼽는다. GPT-3가 단순히 문장을 이어 쓰는 능력 자체에 집중했다면, ChatGPT는 사용자의 의도에 맞춰 대화하고 무례한 표현을 거르며, 이해하기 쉬운 응답을 제공하도록 정렬되었다. 즉, 모델의 정교함보다 그 능력을 어떤 방향으로 정렬했는가가 제품 임팩트를 결정지은 사례다.

정렬의 개념은 기업의 모든 AI 모델에 적용된다. 가령 ‘재방문율’을 핵심 지표로 삼은 숏폼 영상 서비스를 생각해보자. 흔히 저지르는 실수는 ‘시청 시간’ 예측에만 몰두하는 것이다. 시청 시간이 길어질 것으로 예측되는 영상을 우선 노출하면 당장은 지표가 좋아 보인다. 하지만 여기엔 함정이 있다. 모델은 시청 시간을 늘리기 위해 내용을 질질 끌거나 자극적인 낚시성 콘텐츠만 골라 추천할 수도 있다. 결과적으로 사용자는 피로감을 느끼고 오히려 앱을 떠나게 된다. 예측 모델은 똑똑해졌는데 비즈니스는 망가지는 역설이다. ‘시청 시간 예측’이라는 기술적 목표와 ‘재방문율’이라는 비즈니스 목표가 정렬되지 않은 탓이다.

실제로 추천 시스템이 풀어야 하는 핵심 질문은 “이 콘텐츠를 지금 이 유저에게 노출하면 재방문율이 어떻게 변할까?”에 가깝다. 이를 제대로 예측하려면, 인과 추론이나 강화학습 같이 난이도가 높은 AI 기술을 필요로 하지만, 모델이 이 방향으로 정렬될수록 비즈니스 임팩트는 훨씬 더 선명하게 나타난다.

비즈니스 성장을 만드는 AI 모델의 조건

결국 핵심은 이렇다. AI 모델이 비즈니스에 기여하지 못하는 원인은 예측력이 부족해서라기보다는, 모델이 향하고 있는 방향이 비즈니스 목표와 충분히 정렬되지 않았기 때문인 경우가 많다. 정렬이 부족했던 GPT-3는 연구자 중심 모델에 머물러 임팩트가 제한적이었던 것처럼, 회사에서의 AI 모델도 비즈니스 지표와 정렬되지 않은 상태에서는 아무리 모델 손실을 낮춰도 비즈니스 임팩트는 제한적일 수밖에 없다.

따라서 회사의 AI 모델이 기대한 만큼의 비즈니스 성과를 내지 못하고 있다면, 먼저 확인해야 할 것은 모델의 정교함이 아니라 비즈니스 목표와의 정렬 상태다. 정렬이 갖춰진 이후의 성능 개선은 학계의 최신 도구를 빌려 해결할 수 있지만, 우리 비즈니스의 목표와 맥락에 맞게 모델을 정렬하는 것은 오직 그 기업만이 풀 수 있는 고유의 숙제다. AI 시대가 빠르게 변화할수록 중요한 것은, 우리의 AI 모델이 현재 어떤 목표를 향해 학습되고 있는지를 지속적으로 명확히 하는 일이다. 정렬이 우선이며, 그 위에서 이뤄지는 성능 개선만이 더 효율적인 비즈니스 성장을 가능하게 한다.

HYPERCONNECT AI가 만드는 팀

2025-11-01T00:00:00+09:00

벡터

저는 사람의 능력을 일종의 벡터로 봅니다. 누구나 잘하는 게 있으면 못하는 것도 있습니다. 그건 저도 마찬가지입니다. 능력은 벡터이기 때문에 누가 역량이 더 좋다 나쁘다 이야기 하는 것은 어렵습니다. 벡터는 대소 비교가 불가능하기 때문입니다.

하지만 성과는 스칼라입니다. 개인과 팀의 성과는 비즈니스 임팩트로 치환해서 스칼라 값으로 만들어낼 수 있고 결국 이는 대소 비교가 가능하다는 것을 의미합니다.

저는 팀 매니징을 이렇게 봅니다. 팀의 역량도 개인의 역량과 마찬가지로 벡터로 보고, 회사에서 우리 팀에 요구하는 역량도 같은 차원의 벡터로 표현할 수 있다고 간주합니다. 둘의 내적이 비즈니스 임팩트가 된다고 생각하고 이를 더 키울 방법을 고민하는 것이 매니징이라고 봅니다.

매니징에서 해야하는 것은 두 개 뿐입니다. (1) 회사에서 우리 팀에 요구하는 역량 벡터를 잘 추산하는 것 (2) 팀원이 N명일 때, 각 팀원의 역량을 표현하는 N개의 벡터를 입력으로 받고 출력이 팀의 역량 벡터가 되는 함수 f를 디자인 하는 것

(1)은 실제 비즈니스 임팩트와 내가 생각하는 내적이 다르면 다를 수록 왜 다른지 생각하고 회사에서 요구하는 역량 벡터를 수정합니다. 많은 이터레이션이 필요하고 급격히 변화하는 AI 산업 트렌드와 채용 시장 변화에 따라 요구하는 역량 벡터는 계속해서 수정이 필요합니다.

(2) 개개인의 역량을 팀의 역량으로 치환하는 함수 f를 설계하는 일 역시 중요합니다. 함수 f는 단순한 sum operator일 수도 있고, max operator일 수도 있습니다. 그리고 둘도 아닌 임의의 함수일 수도 있습니다. 팀의 리더가 어떤 함수를 설계하느냐에 따라 팀의 결과가 달라집니다. 팀원들과의 1:1 주기, 팀원들의 자리 배치, 프로젝트 별 인력 구성 등 아주 사소한 것들도 함수 f를 변화하게 만듭니다.

제 경험 중 하나는, 새로운 구성원이 팀에 없는 능력을 가졌을 때 f의 출력이 크게 변화한다는 점이었습니다. 팀의 부족한 역량을 채워주기 때문이기도 하지만, 서로가 서로를 더 존중할 수 있기 때문이기도 합니다. 서로가 서로보다 적어도 하나의 능력은 더 뛰어나다면, 굳이 따로 노력하지 않아도 자연스럽게 서로를 존중하게 됩니다. 그래서 저희는 언제나 우리가 아직 갖고 있지 않은 능력을 가진 분을 우대해서 찾고 있습니다.

연차는 중요하지 않습니다

“저는 이제 N년차니까 이 정도는 해야 하죠.”
“아직 N년차밖에 안 돼서 이런 건 좀 이르죠.”

이런 말을 자주 듣습니다. 저는 이런 말을 들을 때마다 조금 불편합니다.

저는 연차가 설명할 수 있는 것이 제한적이라고 생각합니다. 지난 몇 년간 채용을 활발히 진행하면서 면접과 커피챗 등으로 정말 많은 분들을 만나보았습니다. 그 과정에서 이 생각은 더 확고해졌습니다. 같은 연차라도 성장의 방향과 깊이는 전혀 달랐습니다. 어떤 것을 추구하고, 얼마나 주도적으로 성장하며, 그 결과로 어떤 임팩트를 만들어왔는지가 훨씬 더 중요했습니다. 제가 느끼기에 연차는 그저 숫자일 뿐이었습니다.

연차가 정말 중요했다면, 97년생인 Alexandr Wang이 Meta의 AI 책임자가 될 수 있었을까요? 20살로 알려진 Diego Pasini가 Grok의 리더 중 한 명으로 임명될 수 있었을까요?

저는 커리어를 결정짓는 건 연차라는 단순한 숫자가 아니라, 얼마나 비즈니스 임팩트를 낼 수 있는 사람으로 성장했는가라고 생각합니다. 우리가 흔히 말하는 커리어 개발이라는 것도, 결국은 비즈니스 임팩트를 얼마나 잘 낼 수 있을지를 가늠하기 위한 프록시에 가깝습니다. 그런 점에서 N년차에는 무엇을 해야 한다는 통념이 꼭 나쁜 것은 아닐 수도 있습니다. 적어도 하나의 방향을 제시해주니까요. 하지만 그것이 유일한 길은 아닙니다. 그리고 현재 유효한 길이 앞으로도 통할 거라는 보장은 없습니다. AI 툴로 생산성이 폭발하는 시대에 다른 기준을 세워야할 수도 있습니다.

얼마나 비즈니스 임팩트를 낼 수 있는 사람으로 성장했는가?

이 질문에 대한 답이 커리어의 본질이라고 생각합니다. 그래서 HYPERCONNECT AI에서는 실제로 비즈니스 임팩트를 내본 사람, 임팩트를 내기 위해 필요한 근본적인 하드 스킬을 갖춘 사람, 그리고 짧은 시간 안에 압축 성장을 이룬 사람을 주목하게 됩니다. 여러 번 임팩트를 만들어본 사람은 앞으로도 그럴 가능성이 높습니다. 또, 하드 스킬이 탄탄한 분은 더 빠르게 임팩트를 내는 경향이 있습니다. AI 업무에서 어떤 기술 스택을 써봤는지는 상대적으로 중요하지 않다고 생각합니다. AI 분야는 빠르게 발전하기 때문에 저희가 필요로 하는 기술 스택을 경험해본 사람이 많지 않습니다. 경험해봤다고 하더라도 1–2년 후에면 해당 기술 스택이 중요하지 않아지는 경우도 흔합니다. 중요한 것은 변화하는 기술 환경 속에서도 빠르게 적응하고 결과를 만들어낼 수 있는지, 즉 근본적인 엔지니어링/리서치 실력을 갖추었는가입니다. 또, 짧은 시간 안에 많이 성장한 사람은 앞으로도 빠르게 성장할 가능성이 높다고 볼 수 있습니다.

HYPERCONNECT AI는 연차와 관계없이 훌륭한 커리어를 이어나가고 계신 분들을 찾습니다. 본인의 커리어를 스스로 설계하고, 어떻게 하면 더 나아질 수 있을지를 고민하며 움직이는 분들입니다. 저희 조직에서는 시니어 여부를 연차가 아닌 비즈니스 임팩트를 내는 역량으로 판단합니다. 그래서, 연차가 적지만 시니어로 인정받는 분들이 꽤 있습니다. 연차를 뛰어넘어 성장하고, 실력으로 인정받는 문화를 만들어가고 있습니다.

창업가 출신

저희 AI 조직엔 특별한 점이 있습니다. 창업가 출신이 많습니다. 네 명 중 한 명꼴로 직접 회사를 만들어본 경험이 있죠. 물론, 원래 힘든 창업인 만큼 제대로 된 exit을 한 분은 아쉽게도 없습니다. (저를 포함해서요.)

그럼에도 저는 창업 경험을 가진 분들을 가치 있게 생각합니다. 하드 스킬이 더 뛰어나냐고 하면 꼭 그렇지만은 않습니다. 그래서 기술 면접을 보면 부족한 부분이 드러날 때도 있습니다.

하지만 이들에게는 다른 특별함이 있습니다. 바로 극한의 오너십입니다. 본인이 어떤 제품을 처음부터 끝까지 책임져본 경험이 있고, 그 경험이 습관처럼 몸에 각인되어 있습니다.

이 오너십은 각자 다른 방식으로 드러납니다. 더 나은 의사결정을 하기 위해 끊임없이 회고하고 배우는 분들이 있고, 더 빠르게 실행하기 위해 쉼 없이 계발하는 분들도 있습니다. 때로는 두 가지를 모두 추구하는 놀라운 분들도 계십니다. 각자의 방식으로 더 성장하고 싶어하십니다.

물론 창업 경험이 없다고 해서 오너십이 부족하다는 뜻은 너무나 당연히 아닙니다. 다만 오너십을 가진 사람들은 또 다른 오너십을 가진 사람들을 만들고, 그것이 팀의 문화가 된다는 것을 경험합니다. 그래서 팀이 움직이는 힘이 됩니다.

저희 팀은 성공하면 함께 기뻐하고, 실패하면 모두가 자기 일처럼 아파합니다. 그리고 어떻게 하면 더 잘할 수 있을지 치열하게 고민하고 토론합니다. 저는 이런 문화를 가진 저희 조직이 자랑스럽고, 이런 분들과 함께할 수 있다는 것이 늘 감사하고 행운이라고 생각합니다. 스스로 결정하고 책임져본 경험이 남긴 태도는 값집니다.

저는 창업 경험이 있는 더 많은 분들과 함께하고 싶습니다. 혹시 창업 경험을 가진 분들 중 새로운 도전을 고민하고 계시다면, 꼭 이야기 나눠보고 싶습니다.

AI 문제를 풀 때 논문을 최소 100편 읽어야 합니다

2025-10-16T00:00:00+09:00

논문을 읽지 않으면 AI 문제를 제대로 정의할 수 없다

문제를 풀 때 가장 중요한 건 ‘문제 정의’입니다. 우리가 문제를 잘 정의했다면 이미 절반은 푼 것이나 다름없습니다. 그래서 빠르게 해결책을 찾는 것보다, 충분한 시간을 들여 문제를 제대로 정의하는 것이 오히려 전체 속도를 높이는 일입니다. AI 연구에서도 마찬가지입니다. 문제 정의가 명확하지 않으면, 이후의 모델링이나 실험은 길을 잃습니다.

문제 정의를 잘하기 위해서는 논문을 반드시 읽어야 합니다. 한두 편이 아니라, 넓고 다양하게 읽어야 합니다. 단순히 관련 연구를 나열하기 위해서가 아니라, 우리의 문제를 더 깊이 이해하고 제약조건을 구체화하기 위해서입니다.

예를 들어 새로운 분류기를 만들기 위해 외주로 데이터를 레이블링했는데, 생각보다 잘못된 레이블(noisy label)이 많았다고 가정해보겠습니다. 이때 논문을 읽지 않았다면 단순히 “레이블이 깨끗하지 않다”는 문제로만 인식했을 겁니다. 하지만 여러 논문을 읽다 보면 다양한 접근을 발견하게 됩니다. 어떤 논문은 여러 명에게 같은 데이터를 맡겨 데이터셋을 정제하라고 제안합니다. 그럼 우리는 “추가 레이블링 예산이 가능한가?”를 따져봐야 합니다. 또 다른 논문은 “수백 개의 클린한 데이터만 있어도 학습에 문제가 없다”고 말합니다. 그렇다면 “그 정도의 클린 데이터를 우리가 직접 모을 수 있을까?”라는 현실적인 질문을 던지게 되죠. 어떤 연구는 아예 외주 레이블링의 품질 저하 원인을 분석하기도 합니다. 이런 논문들을 읽으며 우리는 “우리도 같은 문제가 있는 건 아닐까?”를 점검해볼 수 있게 됩니다.

이처럼 논문을 읽는 것은 우리의 제약조건을 구체적으로 인식하고 문제를 더 정확하게 정의하기 위한 과정입니다. 좋은 문제 정의는 ‘무엇을 할 수 있고 할 수 없는가’를 명확히 아는 데서 시작됩니다. 논문을 다양하게 읽음으로써 우리가 풀고자 하는 문제의 제약 조건을 더 구체화해나갈 수 있고 이를 통해 더 좋은 문제 정의를 할 수 있습니다. 문제가 잘 정의되면 솔루션은 비교적 쉽게 찾아낼 수 있습니다.

논문을 읽지 않으면 AI 문제를 빠르게 풀 수 없다

어떤 연구자들은 논문을 충분히 읽지 않고, 일단 내 아이디어부터 구현합니다. “이렇게 하면 되지 않을까?” 하고 시도해보죠. 이렇게 해서 문제가 풀릴 수도 있지만, 대부분은 기대만큼의 결과를 얻지 못합니다. 그래서 또 다른 아이디어를 내어 시도하고, 여러 번의 이터레이션을 거치며 괜찮은 방향을 찾아냅니다. 이런 방식이 문제를 해결하지 못할 때도 많지만, 운이 좋아서 해결이 되더라도 나중에 돌아보면 이미 누군가 그 방법을 논문으로 공개해둔 경우가 정말 많습니다. 결국 우리는 시간을 낭비한 셈이죠. 논문만 미리 찾아봤다면 훨씬 더 빨리 그 지점까지 도달할 수 있었을 겁니다.

HYPERCONNECT AI에서는 관련 논문들을 가능한 한 폭넓게 찾아봅니다. NeurIPS, ICLR, ICML, CVPR 같은 top-tier 컨퍼런스 논문들을 우선 보지만, workshop이나 arXiv도 가리지 않고 검토합니다. top-tier 논문은 우리의 제약조건과 일치하는 경우가 많지 않지만, workshop 논문에서는 의외로 비슷한 제약과 방향을 가진 시도들을 자주 발견합니다. 그렇게 폭넓게 읽다 보면 시행착오의 폭이 확실히 줄어듭니다.

AI 조직 안에서 논문을 읽는 건 분명한 ‘일’로 간주되어야 합니다. 이미 누군가 겪은 시행착오의 기록을 통해, 우리 팀의 시행착오를 줄이는 가장 빠른 방법이니까요. 머신러닝은 비싼 기술입니다. 비싼 만큼 시행착오를 줄여야 이터레이션이 개선되고, 우리가 원하는 지점에 더 빠르게 다다를 수 있습니다.

어떤 논문을 선택해야 할까?

논문을 충분히 다양하게 검토했다면 어떤 논문을 선택해 구현할지 결정해야 합니다. 이때 많은 연구자분들이 SotA에 주목합니다. 하지만 SotA 모델들은 수많은 학습 트릭이 포함된 경우가 많고 하이퍼파라미터에 민감하며, 벤치마크 데이터에서는 잘 작동하더라도 회사의 데이터셋에서는 재현성이 낮은 경우가 적지 않습니다.

그래서 “좋은” strong baseline을 선정하는 것이 중요합니다. strong baseline을 잘 선정해야 이후 시행착오를 줄여 프로젝트의 성공 가능성을 의미 있게 높일 수 있습니다. 좋은 strong baseline은 아래와 같은 특징을 가지는 경우가 많습니다.

1/ 좋은 strong baseline은 다양한 데이터에서 일관된 성과를 보입니다. 여러 논문들의 실험 파트에서 반복적으로 등장하고, 각기 다른 방식으로 성능을 리포트하면서도 일관되게 준수한 결과를 보여주는 모델들이 있습니다. 논문마다 결과가 조금씩 다르더라도 평균적으로 안정적인 성능을 보인다면, 이런 모델이 좋은 strong baseline이 될 가능성이 높습니다.

2/ 성능이 비슷하다면 복잡도가 낮고 유지보수가 쉬운 모델을 strong baseline으로 택하는 것이 좋습니다. 오컴의 면도날처럼 단순한 모델이 오히려 여러 데이터에서 잘 작동할 가능성이 높습니다. 반대로 복잡한 모델은 하이퍼파라미터 튜닝에 많은 시간을 요구하고, 안정적으로 재현하기 어려워 리스크가 있습니다.

3/ 논문을 다양하게 읽다 보면 비슷한 계열의 아이디어들이 보이고 그중 여러 논문의 뿌리가 되는 논문이 있습니다. 같은 갈래에 속하는 여러 논문들이 뿌리가 되는 논문과의 차이를 설명하려고 애쓰는 경우가 많다면, 그건 좋은 strong baseline일 가능성이 큽니다. 그리고, 이런 논문들이 간단한 경우도 많습니다.

4/ 또 좋은 strong baseline은 코드가 공개되어있는 경우가 많습니다. 재현성에 대한 자신감이 있기 때문에 코드를 공개한 경우가 많을 것이고 해당 코드를 돌려봄으로써 시행착오를 줄일 수 있습니다. 생각보다 논문에 명시되지 않았던 학습 트릭이 들어있는 경우를 발견하는 경우도 흔합니다.

물론 우리가 찾은 논문들 중에 위 기준을 모두 만족하는 논문이 없을 수도 있습니다. 하지만, 우리는 찾은 여러 연구들 중에 시행착오를 가장 줄일 확률이 높은 논문을 우선적으로 선정해서 성능을 확인해야 합니다.

우리가 정한 strong baseline이 충분히 좋은 결과를 보여준다면 정말 행복한 상황입니다. 하지만, 대부분의 경우 우리의 기대치에 못미치는 경우가 많습니다. 그럴 땐 strong baseline의 어떤 점 때문에 성능이 부족한지를 찾고 strong baseline을 어떻게 변형하고 개선할지 고민해야 합니다. strong baseline을 설정하는 과정은 그런 의미에서 실험의 끝이 아니라 시작점에 가깝습니다.

결국 strong baseline을 세운다는 건 단순히 비교 기준을 만드는 일이 아닙니다. 이후의 모든 연구와 개선이 쌓일 수 있는 토대를 다지는 일입니다. 좋은 연구는 단단한 출발점에서 시작됩니다.

AI 문제를 풀기 전에 관련 논문을 100편 읽어야 합니다

논문을 읽어야 문제를 잘 정의할 수 있고, 논문을 읽어야 시행착오를 줄여 목표를 더 빠르게 달성할 수 있습니다. 이렇게 논문 읽기는 AI 연구에 있어 중요합니다.

HYPERCONNECT AI에서는 “새로운 문제를 시작할 때 저는 최소 100편의 논문을 조사해야 한다”는 원칙을 가지고 일하고 있습니다. 과하다고 생각하실 수도 있지만, 실제로는 그 정도를 봐야 다양한 솔루션을 검토할 수 있습니다. 100편을 보지 않았다는 것은 보통은 충분히 다양한 분야의 논문을 검토하지 않은 경우가 많습니다. 인접 분야를 포함해 이 문제를 풀기 위한 충분한 검토를 하기 위해서는 최소 100편의 연구를 봐야 합니다.

문제 정의에서의 논문 읽기의 중요성을 역설했 듯, 100편을 모두 꼼꼼히 읽어야 한다는 이야기는 아닙니다. 문제 정의를 할 때에는 다양한 논문을 빠르게 훑는 것이 중요합니다. 초록과 결론 기여부분을 집중적으로 보고 전체적으로 논문을 스키밍하면서 연구들을 본인만의 방식으로 그룹화합니다. 서베이 논문을 읽으면서 여러 논문들을 한번에 파악할 수도 있고, 요즘은 ChatGPT나 Gemini 에 탑재돼있는 연구 기능을 활용해 다양한 논문들의 갈래를 파악하는 것도 도움이 됩니다. 그렇게 논문들을 리스트업하고 주요 논문들에 나와있는 관련 연구(related works)들을 살펴보면서 다른 논문들에 대해서 조금 더 객관적으로 바라보기도 합니다.

수백편 정도가 아니라 읽어야 할 논문이 수천편 정도로 너무 많다고 생각이 들면, 문제 정의를 조금 더 좁게할 필요가 있습니다. 읽어야 할 논문이 너무 많은 경우는 정의한 문제가 너무 넓은 경우가 많고, 문제 정의가 제대로 안돼있을 가능성이 큽니다. 여러 논문들을 빠르게 스키밍하면서 우리의 제약조건을 제대로 파악하는 과정이 필요합니다.

문제 정의와 솔루션 선택을 포함해 논문은 최소 100편 이상 조사되어야 합니다. 아직까지 논문 읽기는 연구자들이 해야 하는 고유한 역할로 생각하고 있습니다. 시니어 연구자들에게는 2–3일 내에 끝마칠 것은 주니어 연구자의 경우에는 5일 안에 끝마칠 것을 가이드하고 있습니다.

논문 읽는 것이 습관화된 조직이 AI를 잘하는 조직이다

논문을 꾸준히 읽는 조직은 문제를 더 잘 풉니다. 각 연구자들이 더 많은 분야의 논문을 이해하고 있을수록, 새로운 논문을 읽는 속도가 빨라지고 문제를 푸는 속도도 빨라집니다. 또, 서로가 다른 배경지식을 가진 연구자들끼리 서로 연구에 대한 피드백을 주고받으면 조직의 문제 풀이 능력은 더 향상됩니다. 하지만, 이런 문화를 유지하는 것은 쉽지 않습니다. 연구자 본인은 스스로 충분히 논문을 탐색했다고 생각할 때가 많다고 느낍니다. 충분히 읽었다고 생각이 들 때 더 읽어야 합니다. 충분히 많은 옵션들을 검토하고 그 중에 최선의 옵션이 무엇인지 생각하는 조직이 되어야 합니다.

왜 AI 추천인가?

2025-10-13T00:00:00+09:00

새로운 시장을 키워 나가기 위해서는 마케팅, 제품, AI 로직 등 여러 요소가 하나의 팀처럼 유기적으로 움직여야 합니다. 그중에서도 AI 기반 추천 시스템은 새로운 시장을 침투(penetration)하는 데 있어 인프라와 같은 핵심 역할을 담당합니다.

랜덤 추천은 제품을 성장시킬 수 없습니다.

작은 사고 실험을 해보겠습니다.

예를 들어 A 국가 사용자가 전체의 90%, B 국가는 10%인 상황을 가정해봅시다. 두 집단은 언어와 문화가 다르며, 컨텐츠나 상품의 취향 또한 완전히 다릅니다. 그런데 추천이 완전히 랜덤이라면, B 국가 사용자는 대부분 A 국가에서 인기 있는 컨텐츠만 보게 됩니다. 흥미를 느끼지 못하고 금세 떠나버리겠죠. 결국 제품에는 A 국가 사용자만 남게 되고, 신규 시장 확장은 불가능해집니다.

그럼 국가별로 컨텐츠 풀(pool)을 나누면 되지 않을까?

좋은 사용자 경험은 단순히 국가로 결정되지 않습니다. 언어, 관심사, 행동 패턴 등 수많은 요인이 얽혀 있습니다. 이런 맥락에서 AI 추천 시스템의 고도화는 선택이 아니라 필수입니다. 서비스 내에서 비율이 크지 않은 사용자에게도 좋은 경험을 주는 시스템만이, 결국 새로운 시장을 개척하고 이를 통해 제품을 성장시킬 수 있습니다.

휴리스틱 추천의 문제점

위에서 이야기한 것처럼, 랜덤 추천으로는 다양성을 확보할 수 없습니다. 다수를 구성하는 유저 그룹에게만 유리하고 소수의 유저 그룹은 계속 패널티를 받습니다. 그래서 대부분의 추천 시스템은 처음엔 휴리스틱 방식을 택합니다. 랜덤 추천은 답이 아니니까요.

휴리스틱은 사람이 직접 규칙을 만들어 추천에 반영하는 방식입니다. 예를 들어,
- 같은 국가의 컨텐츠라면 +10점
- 컨텐츠가 좋아요를 10개 이상이면 +1점
- 컨텐츠의 클릭률이 2% 이상이면 +2점
이처럼 단순하고 빠르게 시작할 수 있습니다. Google이 공개한 rules-of-ml에서도 휴리스틱을 두려워하지 말라고 조언하듯, 초기에 제품을 개선하기에 유리합니다.

하지만 규칙이 쌓이고 수정되면서 시스템은 점점 복잡해집니다. 그리고 한 지표를 개선하려 추가한 규칙이 다른 지표를 악화시키는 문제가 발생합니다. 예를 들어, 업로드된 지 일주일이 안 된 컨텐츠의 노출을 늘리기 위해 +3점을 주는 규칙을 추가했다고 가정해봅시다. 이 경우, 좋아요 수나 클릭률이 떨어질 가능성이 높습니다. 결과적으로 보정 규칙이 계속 추가되며, 시스템은 점점 관리하기 어려워집니다.

또한 추천에 고려해야 하는 인자는 너무나도 많고 서로 얽혀 있습니다. 현재 휴리스틱으로 구선된 추천의 문제를 진단하고 어떤 인자를 부스팅하면, 상관관계가 있는 다른 인자들도 함께 영향을 받습니다. 추천에 반영해야 하는 인자가 n개라면 우리가 고려해야 하는 조합은 n이 증가함에 따라 지수적으로 증가(O(exp(n)))합니다. 사람이 이 모든 조합을 고려하는 것은 불가능에 가깝습니다.

하지만, AI 추천은 입력과 출력만 관리하면 되기 때문에 복잡도를 선형적으로(O(n)) 관리할 수 있습니다. 모델의 입력에 새로운 인자를 추가하거나 학습에 사용되는 손실 함수를 변경하는 방식으로 주로 개선이 이뤄지기 때문에, 시스템의 확장성과 유지보수가 훨씬 용이합니다.

마지막으로, 휴리스틱은 개선해도 제자리걸음인 경우가 많습니다. A/B 테스트를 반복하며 더 나은 규칙을 찾아도 실질적인 개선은 일어나지 않는 경우가 많습니다. 환경이 바뀌면 휴리스틱으로 만든 규칙의 효과는 금세 사라질 수 있기 때문입니다. 예를 들어, 여름에 만든 휴리스틱이 겨울에는 잘 작동하지 않을 수 있습니다. 마케팅으로 유저 연령이 낮아지거나 트래픽 패턴, 사용자 구성, 시즌별 행동이 달라지면 변화된 유저 분포에 최적화된 규칙이 바뀌고 이를 반영해 다시 규칙을 만들어야 합니다. 결국 휴리스틱은 ‘끊임없이 손이 닿아야 유지되는 시스템’이 되어, 담당자가 바뀌거나 관심이 줄면 금세 낙후됩니다. 겉으론 계속 개선되는 것처럼 보여도, 실제로는 시스템만 복잡해지고 근본적인 개선은 일어나지 않을 가능성이 큽니다.

물론 AI 추천도 한계가 있을 수 있지만, 본질적으로는 다릅니다. 모델은 주기적으로 학습(continuous training)되며 타깃 지표를 향해 업데이트되기 때문에, 환경이 변해도 점진적으로 적응합니다. 복잡한 구조가 아니어도 괜찮습니다. 단일 지표를 학습하는 간단한 모델조차 휴리스틱보다 일관된 방향으로 목표에 수렴하고, 변화에도 유연하게 대응합니다. 결국 차이는 ‘지속성’입니다. 휴리스틱은 사람이 떠나면 금세 낙후되지만, 모델은 데이터 변화에 따라 스스로 갱신됩니다.

그래서 저희는 “휴리스틱을 최소화하고, 모델만을 사용해서 추천하자”는 방향으로 전환하고 있습니다. 완벽하다고는 할 수 없지만, 분명 더 나은 길이라고 믿습니다. 사람이 만드는 규칙 대신, 데이터로부터 직접 규칙을 배우는 모델을 사용하는 것이 결국 더 단순하고, 더 강한 시스템을 만든다고 생각합니다.

AI 추천이 실패하는 이유

“AI 추천을 써봤는데 잘 안 되더라”는 말을 종종 듣습니다. 대부분의 실패는 기술의 문제가 아니라, 추천 시스템의 명확한 목표가 없는 것에서 비롯됩니다. 즉, 추천 시스템이 개선해야 하는 단일한 지표가 없기 때문인 경우가 많습니다. 이건, AI 추천이 성공하기 힘든 상황입니다.

어떤 지표가 제일 중요한지 모르기 때문에 시행착오를 겪으면서 지표를 하나씩 추가하고, 결국 수십개의 지표를 모니터링하게 됩니다. 그리고 각 지표들을 모두 중요하게 봅니다. 하지만, 모든 지표가 중요하다고 하면, 사실상 어떤 지표도 중요하지 않게 됩니다. 어느 정도 추천 시스템이 성숙해지면, 개선을 위해서 수정할 때마다 분명 어떤 지표는 떨어지고 어떤 지표는 올라갑니다. 그럼 수십개의 지표를 깔아두고 의사결정권자들이 판단을 하죠. 새 알고리즘에서 이 지표들은 올라가고 저 지표들은 내려갔는데, 이 지표들이 내려가는 것에 비해서 저 지표들이 올라간 것이 더 이득이라고 판단하니까 새 알고리즘을 배포하자는 결정을 내리곤합니다. 이런 방식은 지표의 문제가 아니라 가치 판단의 문제가 되는 경우가 많습니다. 이런 상황에서는 AI 추천이 휴리스틱 추천보다 나아지기 어렵습니다. 나아진다는 것의 정의가 제대로 되지 았기 때문이죠. 어떤 시스템을 개선하려면 지표가 한 개여야 합니다. 여러 지표를 함께 고려해야 한다면, 이를 묶어 새로운 합성 지표를 설계해야 합니다.

그럼 어떻게 해야 할까요?

많은 추천 시스템의 목표는 리텐션을 최대화 하는 것입니다. 물론 서비스 특성에 따라 리텐션이 설명하지 못하는 다른 지표들도 같이 봐야 하는 경우들이 있습니다. 하지만 좋은 추천은 “제품에 남고 싶은 경험”으로 프록시 되기에 리텐션이 가장 중요합니다.

아자르에서는 ‘아하 모먼트(Aha Moment)’ 프레임워크를 통해 리텐션에 가장 큰 영향을 미치는 1차 지표를 찾아냈고, 해당 지표를 집중적으로 부스팅하여 리텐션을 꾸준히 개선해왔습니다. 운이 좋게도 이 1차 지표가 리텐션과 강한 인과관계를 가지는 지표였습니다.

하지만 어느 순간, 이 지표만을 극단적으로 부스팅하면 다른 지표들이 떨어지면서 리텐션이 오히려 오르지 않는 현상을 발견했습니다. 우리가 찾았던 1차 지표가 리텐션에 가장 큰 기여를 하고 있는 것이 맞지만, 다른 지표들도 유의미하게 영향을 준다는 것을 발견했습니다.

이 문제를 해결하려면 결국, “이 유저에게 이 컨텐츠를 노출했을 때 리텐션이 얼마나 상승할 것인가?” 를 직접 모델링해야 합니다. 즉, 추천 점수를 리텐션 uplift에 연결(pegging)해야 하며, 이는 인과 추론이나 오프라인 강화 학습을 활용해 가능합니다. 이렇게 직접적으로 리텐션 업리프트를 예측하는 알고리즘을 만드는 것은 휴리스틱으로는 절대 달성할 수 없습니다.

마치며

이런 방향으로의 전환은 단순한 기술 혁신이 아니라, 서비스가 성장하는 방식을 바꾸는 일입니다. 그리고 이 노력의 결과로 HYPERCONNECT의 아자르가 아시아를 넘어 유럽에서도 빠르게 성장하고 있습니다. 3개월 단위로 두 자릿수 성장을 기록하며, 새로운 시장에서 의미 있는 변화를 만들어가고 있습니다. 뿐만 아니라, 추천 시스템의 개선이 YoY로 매출을 30% 성장시키기도 했습니다.

HYPERCONNECT AI는 사람이 만든 규칙이 아닌, 데이터가 스스로 배우는 세상을 만들고 있습니다. 이 여정에 함께하고 싶은 분들을 기다리고 있습니다.

AI 문제 해결의 원칙

2025-10-13T00:00:00+09:00

어떻게 AI 문제를 풀어야 하는가?

현실에서 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로 디버깅할 수 있다고 믿습니다. 물론 소프트웨어 디버깅과는 달리 확률적인 성격이 있어서 똑같진 않지만, 원인을 추적하고 검증하는 과정은 똑같이 필요합니다. 샷건 디버깅은 당장은 쉬워 보여도 장기적으로는 오히려 더 느린 길이 될 수 있습니다.

샷건 디버깅을 지양합시다.

No Shotgun Treatment

‘산탄처방(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를 넣는 것이 정말 중요한가?”를 빠르게 가늠할 수 있습니다. 클릭률이나 체류 시간이 몇 퍼센트 늘어났는지를 보고, 더 큰 모델을 썼을 때 얼마나 더 개선될지, 그리고 그 변화가 매출이나 리텐션에 어떤 영향을 줄지를 가늠해볼 수 있습니다.

딥러닝을 잘한다고 해서 모든 문제를 딥러닝으로 푸는 건 낭비일 때가 많습니다. 문제의 크기에 맞는 모델을 선택하고, 그 문제가 정말 중요한지 다시 평가하고, 중요하다면 그때 리소스를 집중하는 이터레이션이 필요하다고 생각합니다.

AI 추천을 잘하려면 UI 도 알아야 합니다

2025-10-12T00:00:00+09:00

혹시 알고 계셨나요?

인스타그램 앱의 첫 번째 탭(홈)과 두 번째 탭(탐색)은 스크롤 방식이 다릅니다.

홈 탭은 손가락을 움직이는 만큼 화면이 따라 내려가지만, 탐색 탭(상세 게시글 누른 후)은 스크롤 후 손을 떼면 자동으로 특정 게시물이 화면 상단에 맞춰지도록 동작합니다. 직접 해보시면 두 탭의 차이를 확실히 느낄 수 있습니다.

홈 탭 (왼쪽): 손가락을 따라 관성으로 자유롭게 흐릅니다
탐색 탭 (오른쪽): 스크롤하면 아래 게시물이 이어지고, 손을 떼면 상단에 맞춰 정렬됩니다

영상 출처: Page Flows의 Instagram iOS 화면 녹화 (홈: 2022년 5월 버전, 탐색: 2019년 11월 버전)

체류시간을 정확히 재기 위한 UI

왜 이런 차이가 있을까요?

전 이런 UI가 추천 알고리즘을 고도화 하기 위한 전략이라고 봅니다. 추천 시스템의 발전 과정에서 중요한 전환점 중 하나는 사용자의 체류시간을 핵심 시그널 중 하나로 활용하기 시작했다는 점입니다. 특정 콘텐츠에서 얼마나 오래 머무르는가는 단순 클릭보다 유저에 대한 훨씬 많은 이해를 제공합니다. 구매나 좋아요 같은 액션은 드물게 발생하고 사람마다 발생 빈도가 달라 최적화하기 어렵지만, 시간은 누구나에게 꽤 공평하기에 체류시간은 모든 사용자에게서 일관되게 얻을 수 있는 신호입니다.

체류시간을 정확히 측정하려면 사용자가 화면 속 여러 콘텐츠 중 무엇을 보고 있는지 알아야 합니다. 이를 통해 좋아하는 콘텐츠뿐 아니라 관심이 없는 콘텐츠도 식별할 수 있습니다. 하지만 전통적인 그리드나 리스트 뷰에서는 사용자가 선택하지 않은 이유를 알기 어렵습니다. 더 좋은 것이 있어서 클릭하지 않은 것인지, 아예 관심이 없어서 클릭하지 않은 것인지 구분하기 힘듭니다. 이 한계를 극복하기 위해 한 번에 하나의 콘텐츠만 보여주고 체류시간을 정확히 잼으로써 추천 알고리즘의 성능을 높이는 방식이 제안되었습니다. 그리고 여러 숏폼 영상들은 정확하게 이 UI를 채택함으로써 유저가 원하는 영상을 빠르면 3분 이내에 알아내고 있습니다.

같은 추천 모델이라도 UI에 따라 학습에 쓸 수 있는 피드백의 질이 달라진다

모델을 넘어 제품 설계까지

이런 UI는 틱톡을 운영하는 바이트댄스가 처음 제안했다고 알려져있습니다. 이 사례로 볼 때, AI가 큰 임팩트를 내기 위해서는 단순히 모델만 신경쓰면 되는 것이 아니라 UI까지 고민해 제품과 유기적으로 연결되어야 합니다. 틱톡은 AI를 이해하는 사람이 제품 설계 단계부터 깊이 관여했기에 성공할 수 있었다고 보고 있습니다. 따라서, 큰 임팩트를 내기 위해서 연구자는 단순히 모델링에만 머무르지 않고, 제품 설계와 의사결정 과정에도 참여할 수 있어야 합니다.

학계에서도 비슷한 시도들을 쉽게 관찰할 수 있습니다. 추천 시스템을 연구해본 분들이라면 MovieLens 데이터셋을 아실 겁니다. 정말 많은 추천 연구들에 벤치마크 데이터로 사용되고 있죠. 이 데이터 셋은 미네소타 대학 GroupLens 연구진이 만들었는데요, GroupLens 연구진은 추천 AI 연구 뿐만 아니라 HCI 연구도 활발하게 진행하고 있습니다. 단순히 모델 개선에 그치지 않고 사용자 경험을 더 좋게 하려면 어떤 UI를 통해 유저에게 제공해야 하는가까지 고민합니다.

AI로 제품에 큰 임팩트를 내려면 알고리즘만이 아니라 제품 자체에도 깊은 관심이 필요합니다. 우리 제품뿐만 아니라 경쟁사 서비스, 나아가 IT 생태계 전반에 대한 호기심과 이해가 뒷받침되어야 합니다. 저는 이것이 좋은 AI 연구자 혹은 AI PM이 갖추어야 할 중요한 태도라고 생각합니다.

정렬(alignment)과 스케일링(scaling)

2025-10-09T00:00:00+09:00

저는 조직의 AI 업무를 크게 두 가지로 봅니다. 바로 정렬과 스케일링입니다. 이런 관점은 LLM에만 국한되는 이야기가 아닙니다. 저는 추천 업무에서도, Trust & Safety 업무에서도 똑같이 정렬과 스케일링의 관점으로 접근합니다.

정렬이란, 우리가 만드는 모델이 실제 비즈니스 지표와 연결되게 만드는 과정을 의미합니다. 추천 시스템을 이야기할 때, 클릭률 예측기의 loss를 줄여도 비즈니스 지표인 리텐션이 개선되지 않는다고 말하는 사람들이 많습니다. 그럴 수 있습니다. 클릭률 예측기의 loss가 줄어드는 것과 리텐션이 올라가는 것이 정렬되지 않았기 때문입니다. 리텐션을 올리고 싶다면 어떤 loss 함수를 설계해야 하는지 깊이있게 고민해야 합니다. 저희는 이를 정렬 과정이라고 부릅니다. 저희 과거 테크 블로그를 보시면 3년 전에 primitive한 방식으로 정렬을 시도했던 흔적을 확인하실 수 있고, 저희가 5년 전에 CVPR에 냈던 논문에서도 비슷한 시도를 확인하실 수 있습니다.

정렬이 제대로 되었다면 그 다음 단계는 스케일링입니다. 모델의 loss는 (몇 가지 가정 아래) 크게 세 가지 요소로 나눌 수 있습니다: bias, variance, 그리고 irreducible error 입니다. 데이터 사이즈를 키우면 variance를 줄일 수 있고, 모델 사이즈를 키우면 bias를 줄일 수 있습니다. irreducible error는 더 많은 feature를 모델의 입력에 포함시켜 줄일 수 있습니다. 데이터와 모델 사이즈를 키우고 더 많은 feature를 모델의 입력에 포함시키는 것을 우리는 스케일링이라고 부릅니다. 모델이 잘 정렬되었다면 스케일링이 직접적으로 비즈니스 임팩트로 직결됩니다.

물론 정렬은 매우 어려운 과정입니다. 저는 제품에 기여하는 AI 연구에서 가장 어려운 점이 정렬이라고 생각합니다. 스케일링은 외부 연구들에서 힌트를 많이 얻을 수 있지만, 정렬은 그렇지 못한 경우가 많습니다. 회사마다 다른 제품을 다루기에 다른 제약 조건이 생깁니다. 제약 조건 때문에 문제가 어려워지기도 하고 때론 쉬워지기도 합니다. 정렬 문제는 오롯이 그 회사가 풀어야 하기에 어렵습니다.

예를 들면, 추천 업무에서의 HYPERCONNECT AI의 목표는 추천 모델의 출력이 “이 유저에게 이 아이템을 추천했을 때 회사의 장기 매출이 얼마나 늘어날지”가 되도록 정렬하는 것입니다. 이렇게만 된다면 우리가 모델의 loss를 N% 개선할 때마다 장기 매출이 M% 증가하는 구조를 만들 수 있습니다. 하지만, 이 방향으로의 정렬은 강화학습 혹은 인과 추론이 필요한데 탐색(exploration)이 충분히 되어야 하면서도 제품의 현재 비즈니스 지표에 영향을 최대한 주지 않아야 하기에 쉽지는 않습니다.

AI 조직이 비즈니스 성과를 내려면 결국 정렬에서 스케일링으로 이어지는 구조를 만들어야 합니다. HYPERCONNECT AI 조직은 저희 조직이 만들고 운영하는 수십 개의 모델들을 더 잘 정렬하고, 잘 정렬된 모델은 스케일링하는 데 집중하고 있습니다.

머신 러닝 모델의 정렬(alignment)

머신 러닝 모델은 본 것만 잘합니다.

모델은 학습 과정에서 본 것만 잘합니다. 보지 못한 걸 못하는 건 당연한 일이고, 만약 본 적 없는 것을 잘한다면 오히려 신기한 일입니다. (요즘은 emergent abilities라는 용어도 있죠.) 그래서 모델이 학습하지 않은 데이터를 추론에 쓸 때는 반드시 주의가 필요합니다. 제품에서의 AI 연구에서 이 부분이 자주 간과되곤 합니다.

웹에서 수집한 데이터로 학습된 모델이 있다고 가정해봅시다.

이 모델이 우리 서비스에서 그대로 잘 동작할까요?

하나에 베팅해야 한다면, “아니다”에 베팅하는 게 맞습니다. 결국 우리 서비스에 가장 잘 맞는 모델은 우리 서비스에서 수집된 데이터로 학습한 모델입니다. 물론 서비스 데이터가 없을 때 외부 데이터를 초반에 활용하는 건 자연스러운 일이지만요.

다른 예시들도 많습니다. PNG로만 학습된 모델이 JPG로 압축된 이미지를 받으면 성능이 떨어집니다. 포맷이 달라지면 반드시 신경 써야 합니다. 프로필 이미지로 학습된 모델을 화상 채팅에 그대로 쓴다면 동작하지 않는다고 가정해야 합니다. 운이 좋아서 잘 되면 다행이지만요. 또, Imbalanced 데이터에서 binary classification 문제를 푼다고 해봅시다. 이 경우에 몇몇 연구자들은 무조건 업샘플링이나 다운샘플링을 하기도 합니다. 하지만 우리가 추론해야 하는 상황과 올리고자 하는 지표를 고려하면, 오히려 원래 분포 그대로 학습하는 것이 더 나을 때도 있습니다.

추천 문제는 이 문제가 더 심합니다. short-form 영상 추천에서 시청 시간을 예측해 가장 오래 볼 영상을 딱 하나 추천하는 문제를 푼다고 해봅시다. 우리가 가진 데이터는 추천으로 노출된 영상에 대해서만 수집된 것입니다. 하지만 추론은 전체 영상에 대해서 합니다. 이 괴리를 줄이려면 이상적으로는 랜덤으로 추천한 데이터로만 학습한 모델을 써야 하지만, 현실적으로는 쉽지 않습니다. 랜덤 추천으로 인해 추천 품질이 극도로 떨어질 수 있기 때문입니다. 그래서 결국 학습과 추론 분포 차이를 줄이는 다양한 방법을 고민해야 하고, 만약 어렵다면 최소한 그 차이를 체크해야 합니다.

학습과 추론의 분포가 다르면 모델이 제대로 동작하지 않을 수 있다는 가정을 항상 가져야 합니다. 모든 상황에서 완벽히 맞출 수는 없지만, 그 차이를 의식하고 적어도 모니터링해야 합니다.

정렬(alignment)되지 않은 모델은 제품에 사용하지 않습니다.

비지도 학습(unsupervised learning)이나 자기지도학습(self-supervised learning)은 매력적으로 보입니다. 레이블이나 목표를 따로 주지 않아도 데이터 속 패턴을 스스로 찾아내고, 우리가 원하는 태스크를 수행하는 것이 신기하기도 하고 때로는 효율적으로 느껴지기도 하니까요.

하지만 HYPERCONNECT AI에서는 목표에 정렬(alignment)되지 않은 모델은 제품에 사용하지 않는다는 원칙을 가지고 있습니다.

그 이유는 단순합니다. 모델이 우리가 정의한 목표로 학습되지 않았다면, 겉보기엔 잘 작동하는 것 같아도 실제로는 엉뚱한 방향으로 갈 수 있기 때문입니다.

모델을 목표에 정렬시키는 가장 확실한 방법은 supervision을 주는 것입니다. 지도 학습(supervised learning)은 입력과 출력이 명확히 짝지어져 있어서, 모델이 우리가 원하는 방향으로 학습되도록 직접 제어할 수 있습니다.

예를 들어 어떤 아이템의 상세 페이지 하단에 ‘유사한 아이템’을 추천한다고 해봅시다. 많은 엔지니어/PM들은 이런 시도를 할 가능성이 높습니다. 협업 필터링(collaborative filtering)이나 다른 추천 알고리즘으로 아이템 임베딩을 만든 뒤, 코사인 유사도가 높은 아이템을 노출하는 로직을 짤겁니다. 하지만, 이 방법은 우리가 기대한 ‘비슷한 아이템’이 잘 나오지 않는 경우가 많습니다.

이유는 명확합니다. 우리가 진짜로 원하는 건 ‘비슷한 아이템’이 아니라 ‘유저가 다음으로 클릭할 가능성이 높은 아이템’인 경우가 많기 때문입니다. 하지만, 이 목표가 모델에 명확히 주어지지 않았던 거죠. HYPERCONNECT AI에서는 이런 경우 “모델을 목표에 어떻게 정렬할 수 있을까?”를 먼저 고민합니다.

그럼 “아직 기능을 출시하지도 않았는데 어떻게 지도학습을 하냐”는 질문이 나올 수 있습니다. 하지만 데이터가 없다고 해서 목표 정렬을 만들 수 없는 건 아닙니다. 우리가 원하는 입력과 출력을 명확히 정의하고, 그에 맞는 데이터를 만들면 됩니다. 유저가 입력해준 데이터 없어도 직접 엔지니어/PM들이 데이터를 레이블링해서 지도 학습을 할 수 있습니다. 이렇게 만들어진 모델이 충분히 좋지 않다고 판단하면, 필요한 데이터를 더 만들어주면 됩니다. 이렇게 하면 기능을 출시하기 전이라도 꽤 괜찮은 모델을 만들 수 있습니다.

HYPERCONNECT AI는 모델에 목표를 주지 않은 채 무작정 튜닝하는 데 시간을 쓰기보다는, 목표를 명확히 정의하고 정렬 구조를 설계하는 데 더 많은 시간을 씁니다. 이것이 우리가 추구하는 principled approach입니다.

이 원칙은 LLM을 사용할 때도 동일하게 적용됩니다. LLM은 우리가 달성하려는 목표로 학습된 모델이 아니기 때문에, 우리의 목표에 맞는 프롬프트를 작성하는 것이 정렬을 시도하는 간단한 방법 중 하나입니다. 프롬프트를 짜고 우리가 원하는 입력에 대해 괜찮은 출력이 나오는지를 확인하기 보다는, 현실적으로 가능한 입력과 그에 대응하는 출력을 미리 정해두고, 프롬프트를 이에 맞게 변경하는 방식으로 일하는 것이 principled approach입니다.

결국 중요한 건 같습니다. 모델은 본 것만 잘합니다. 우리가 명확히 보여주지 않은 목표는 스스로 찾지 못합니다. 그래서 HYPERCONNECT AI는 언제나 모델이 정렬되어 사용될 수 있도록 ML 시스템을 설계합니다.

실험이 우리를 자유케 하리라: HYPERCONNECT AI의 A/B 테스트

2025-10-09T00:00:00+09:00

A/B 테스트가 없이는 ‘개선’을 측정할 수 없다

AI 조직에서는 매일, 그리고 매주 새로운 모델이 만들어집니다. 하지만 새로운 모델이 정말 더 좋은 모델일까요?

많은 AI 연구자들은 오프라인 메트릭의 향상으로 모델의 성능을 판단합니다. 하지만 이는 충분하지 않습니다. 오프라인에서 성능이 향상된 모델이 실제 서비스에 올라갔을 때 오히려 지표가 떨어지는 경우도 적지 않습니다. 그 이유는 명확합니다. 모델을 배포하는 순간 데이터의 분포가 바뀌기 때문입니다. 오프라인에서는 유리했던 환경이, 온라인에서는 전혀 다르게 작용할 수 있습니다. 결국 온라인에서 실제로 지표가 좋아지지 않는다면, 아무리 오프라인에서 잘 작동하더라도 그것은 좋은 모델이라 할 수 없습니다.

그렇다면 온라인에서는 어떻게 ‘좋아졌다’를 검증할 수 있을까요? 가장 단순한 방법은 시계열을 관찰하는 것입니다. 모델을 배포한 뒤 리텐션이나 매출 같은 주요 지표의 변화를 시간에 따라 추적하는 것이죠(예시). 하지만 이 방식은 해석이 어렵습니다. 지표의 변화가 모델 때문인지, 아니면 트래픽 변동, 마케팅, 계절성, 신규 유입 등 외부 요인 때문인지 구분하기 어렵기 때문입니다. 아주 큰 변화가 있었다면 시계열만으로도 구분할 수 있지만, 대부분의 경우 그렇지 않습니다.

이 문제를 해결하는 가장 확실한 방법이 A/B 테스트입니다. 모델의 변경(처치, treatment) 외에도 결과에 영향을 줄 수 있는 수많은 요인들인 혼란 변수(confounder)를 통제하기 위한 실험 설계죠. A/B 테스트는 모델의 변경이 실제로 어떤 변화를 일으켰는지를 명확히 구분해줍니다.

A/B 테스트는 단순히 “이 모델이 좋은가 나쁜가”를 가르는 절차가 아닙니다. 어떤 요인이 지표를 바꿨는지를 해부하고, 거기서 얻은 통찰을 다음 개선으로 연결하기 위한 방법입니다. 모델을 더 잘 만드는 기술적인 방법은 다양하지만, A/B 테스트는 그 변화의 ‘진짜 이유’를 찾아내는 과정입니다. 실험을 통해 쌓인 데이터와 도메인 지식이 결국 더 나은 모델을 만듭니다.

마이크로소프트 등 여러 연구에서도 이런 도메인 지식의 축적을 매우 중요하게 다룹니다. A/B 테스트로부터 얻은 학습이 쌓이면, 어느 순간 큰 성장을 만들어내는 전환점이 온다는 여러 보고가 있습니다. A/B 테스트의 교과서 격인 하마책에서도 이런 사례들을 다루고 있죠. 저희도 비슷한 경험을 하고 있습니다. 그런 성장은 ‘운 좋은 한방’이 아니라, 수많은 실험과 검증이 만들어낸 누적된 결과입니다. “무엇이 변화를 만들었는가”를 명확히 구분해, 가설의 신뢰도를 점진적으로 높여가는 것이 중요합니다.

A/B 테스트는 결국 우리가 진실에 더 가까워지도록 돕는 도구입니다.

실험은 빠르게, 위험은 작게: 쉐도우 테스트와 1% A/B 테스트

새로운 모델을 만들었을 때 가장 먼저 떠오르는 질문은 “이걸 바로 A/B 테스트해도 될까?”입니다. 특히 사용자에게 직접적인 영향을 미치는 AI 시스템이라면, 검증은 반드시 신중해야 합니다. 문제의 중요도가 높을수록 실험의 리스크도 커집니다. 아무리 좋은 아이디어라도 실제 환경에서는 의도와 다르게 작동할 수 있고, 그 결과가 사용자 경험을 크게 해칠 수도 있습니다.

그래서 저희는 A/B 테스트에 들어가기 전에 항상 쉐도우 테스트부터 시작합니다. 쉐도우 테스트는 유저에게는 전혀 영향을 주지 않고, ‘그림자 속에서’ 새로운 모델을 검증하는 방식입니다. 프로덕션과 동일한 트래픽을 새로운 모델에도 흘려보내어 결과를 비교하는 것이죠. 이렇게 하면 사용자에게는 아무런 변화가 없지만, 우리는 두 모델의 추론 결과를 동시에 기록해 성능을 확인할 수 있습니다. 이 방식의 가장 큰 장점은 리스크가 없다는 점입니다. 유저 경험을 전혀 해치지 않으면서도 버그나 문제를 조기에 발견할 수 있습니다. 오프라인 평가와 비교했을 때 메트릭이 일관되게 개선되는지 확인하는 과정으로, 만약 여기서 차이가 크다면 A/B 테스트로 넘어가기 전에 엔지니어링이나 모델 자체에 문제가 없는지를 먼저 점검해야 합니다.

쉐도우 테스트에서 개선 신호가 명확히 확인되면, 그다음 단계로 1% A/B 테스트를 진행합니다. 전체 트래픽의 약 1%만 새로운 모델에 노출해 안정성과 성능을 함께 검증하는 단계입니다. 이 테스트에서는 “확실히 좋아졌다”를 증명하기보다는 “명확히 나쁘지 않다”를 확인하는 데 초점을 둡니다. 모델이 안전하게 동작한다고 판단되면 트래픽을 5%, 20%, 50%로 점진적으로 확장하면서 지표의 변화를 관찰합니다. 이런 과정을 거치면 사용자 경험을 크게 해치지 않으면서도, 새로운 모델이 실제로 긍정적인 변화를 만들어내는지를 빠르고 안정적으로 검증할 수 있습니다. 구조적으로 카나리 테스트와 유사하지만, 단순한 안정성 검증을 넘어 지표가 실제로 나빠지지 않는지를 함께 관찰한다는 점에서 조금 다릅니다.

실험은 언제나 리스크를 동반하지만, 실험을 미루면 배움의 기회를 잃습니다. 쉐도우 테스트와 1% A/B 테스트는 그 사이에서 균형을 잡아줍니다. 빠르게 시도하고, 안전하게 실패하며, 다시 배우는 구조를 만들어줍니다. 저희는 이 과정을 통해 꽤 과감한 실험도 두려워하지 않고 진행할 수 있습니다. 빠르게 움직이되, 무모하지 않게 움직이는 것. 그것이 저희 AI 조직이 실험을 대하는 방식입니다.

A/B 테스트를 제대로 설계한다는 것

A/B 테스트는 모델이 실제로 가치를 주는지를 검증하는 가장 강력한 방법입니다. 하지만 잘못 설계된 실험은 오히려 혼란을 만듭니다. 데이터를 기반으로 올바른 의사결정을 하려면, 실험 자체를 신뢰할 수 있어야 합니다. 그래서 저희는 모델을 개선할 때만큼이나, 실험을 설계할 때에도 신중함을 유지하려 합니다.

A/B 테스트 전에 A/A 테스트는 필수입니다. A/A 테스트는 A/B 테스트가 올바르게 작동하는지 확인하는, 말 그대로 ‘실험의 실험’입니다. 실험군과 대조군에 완전히 동일한 모델과 환경을 배포한 뒤, 양쪽의 주요 지표 분포가 통계적으로 유사한지를 검증합니다. 평균 전환율, 세션 길이, 클릭률 등 핵심 지표를 비교했을 때 유의미한 차이가 없어야 합니다. 만약 A/A 테스트에서조차 실험군이 대조군보다 특정 지표가 일관되게 높게 나타난다면, 플랫폼의 랜덤 배정 로직이나 트래픽 분할 방식에 편향이 있을 가능성이 높습니다. 혹은 표본 크기가 너무 작아 유의성을 검정하기 어려운 경우일 수도 있습니다. 이런 검증을 건너뛰면 이후의 모든 A/B 테스트 결과를 신뢰하기 어렵습니다.

실험군과 대조군의 독립성도 매우 중요합니다. 한쪽의 변화가 다른 쪽에 영향을 미치면 결과가 왜곡됩니다. 서비스의 특성상 완전한 독립을 보장하기 어려운 경우가 종종 있지만, 설계 단계에서 그 영향을 최소화해야 합니다. 실험 단위를 사용자 단위로 잡을지, 세션 단위로 잡을지, 혹은 지역 단위로 잡을지를 명확히 정의하는 것도 이런 이유에서입니다.

Carry-over effect도 주의해야 합니다. 예를 들어 유저 아이디를 단순히 홀짝으로 나눠 홀수 유저 아이디를 실험군, 짝수 유저 아이디를 대조군으로 설정한다고 해봅시다. 그리고 다음 실험도 동일한 방식으로 실험군과 대조군을 할당한다고 해봅시다. 이렇게 하면 다음 실험에서도 같은 사용자가 동일한 그룹에 반복 배정될 수 있습니다. 이전 실험의 잔여 효과가 다음 실험 결과에 섞이게 되는 것이죠. 이런 문제를 해결하기 위해서는 유저 아이디에 해시 함수를 적용해 매 실험이 독립되도록 설계합니다. 이렇게 하면 실험마다 다른 분포로 유저가 배정되어, 이전 실험의 영향을 최소화할 수 있습니다. 이런 편향은 A/A 테스트 단계에서 미리 감지할 수도 있습니다.

실험은 충분히 긴 시간 동안 유지되어야 합니다. 하루이틀의 결과만 보고 결론을 내리면, 새 모델을 처음 본 사용자들이 일시적으로 반응한 효과를 개선으로 착각할 수 있습니다. 또, A/B 테스트는 특정 기간 동안 혼란 변수(confounder)를 통제할 뿐, 그 결과가 다른 시기에도 동일하게 재현된다는 보장은 없습니다. 따라서 최소 일주일 이상 실험을 유지하며, 평일과 주말이 모두 포함된 데이터를 관찰하는 것이 좋습니다. 물론 이런다고 모든 문제가 해결되는 것은 아닙니다. 예를 들어 긴 추석 연휴 기간에 얻은 결과가 추석 이후에도 그대로 유지되리란 보장은 없습니다.

실험 기간과 트래픽 비율은 사전에 명확히 정해야 합니다. “원하는 결과가 나왔을 때 실험을 멈추는 것”은 흔한 실수지만, 이는 p-hacking으로 간주됩니다. 표본 수를 늘려가며 원하는 결과가 나올 때 실험을 종료하면, 우연한 결과를 ‘유의미한 발견’으로 착각할 수 있습니다. 실험 시작 전에 몇 퍼센트의 트래픽을 얼마나 오랜 기간 관찰할지를 정해두는 이유가 바로 여기에 있습니다. 실험의 기대 개선 폭을 설정하면 필요한 샘플 크기가 계산되고, 그에 따라 실험 기간과 노출 비율, 타깃 세그먼트를 결정할 수 있습니다.

검정 방식을 중간에 바꾸는 것도 절대 피해야 합니다. 예를 들어 처음에는 t-test를 사용하다가, p-value가 기대한 수준으로 나오지 않자 다른 검정(예: odds ratio test, Welch test 등)을 반복 적용하는 방식은 타당하지 않습니다. 이런 접근은 “결과가 잘 나올 때까지 시도한다”는 것과 다르지 않으며, 결국 p-value의 의미를 무너뜨립니다. 하나의 실험에서는 하나의 검정 방식을 고정하고, 그 결과를 있는 그대로 해석해야 합니다.

한 번의 실험에서 너무 많은 요인을 동시에 바꾸는 것도 피해야 합니다. 여러 개선안을 한꺼번에 적용하면, 어떤 변화가 결과를 만들었는지 알 수 없습니다. 실험의 본질은 “변화의 원인을 분리하는 것”이기 때문에, 단일 변수를 다루는 것이 원칙입니다. A/B 테스트의 목적은 좋은 모델을 한 번 선택하는 데 있지 않습니다. 어떤 처치가 어떤 결과를 만들어내는지를 학습하고, 매 실험마다 지식을 쌓는 것이 진짜 목적입니다.

A/B 테스트는 결국 “데이터로부터 진실을 드러내는 과정”입니다. 숫자 그 자체보다, 그 숫자를 신뢰할 수 있는 실험을 만드는 일이 더 중요합니다. 그리고 여기서 언급한 주의사항 외에도 실험이 실패하거나 왜곡되는 이유는 훨씬 더 많습니다. 저희는 더 나은 모델을 만드는 만큼, 더 나은 실험을 설계하기 위해서도 계속 고민하고 있습니다.

실험을 더 많이 그리고 안전하게: 중첩 실험(Overlapping Experiments)을 두려워할 필요는 없습니다

Q. 한 번에 한개의 A/B 테스트만 해야 하지 않나요?

HYPERCONNECT가 매치 그룹에 인수되기 전에 입사해, 회사에 벌써 6년째 재직하면서 여러 데이터/PM 직군 분들과 협업해왔습니다. 이 과정에서 종종 A/B 테스트를 한번에 하나만 해야 한다고 주장하시는 분들을 종종 만나왔습니다. 그 분들의 레셔널이 무엇인지 잘 알지만, 저는 항상 동시에 여러 실험을 돌려야 한다고 주장해왔습니다. 특히, 아자르 같이 MAU가 큰 서비스에서는 더더욱 동시에 여러 실험들을 돌려야 합니다.

우리는 더 많은 실험을 통해 더 유저를 잘 이해할 수 있습니다. 유저를 더 잘 이해해야 유저에게 더 좋은 경험을 줄 수 있고 이게 장기 매출로 이어집니다. 더 많은 실험을 하기 위해, 동시에 여러 실험이 돌아가는 중첩 실험은 필수적입니다.

이 논문은 Google이 중첩 실험을 어떻게 하고 있는지를 말한 2010년 논문입니다. UI Layer, Search Layer, Ads Layer와 같이 독립일 것으로 추정되는 요소들끼리 Layering을 잘하면 되고, 이렇게 Layering을 잘하고나서 실험 수가 폭발적으로 증가했다고 합니다. 너무나 당연하게도 Google 뿐만 아니라, Microsoft, Booking.com도 여러 중첩 실험을 진행하고 있습니다. 이 외 다른 회사들의 사례도 충분히 쉽게 찾을 수 있습니다.

왜 많은 빅테크 회사들은 중첩 실험을 열심히 할까요?

사실 중첩 실험을 할 때 각 실험끼리 독립이라는 가정이 깨지면, 당연히 실험에 문제가 생깁니다. 한번에 실험을 하나만 돌려야 한다고 주장하시는 분들이 보통 이 점을 지적하십니다. 이론적으로 옳은 지적입니다. 하지만, Microsoft, Google, Statsig를 포함해 많은 회사들에서 실무적으로 중첩되는 대부분의 A/B 테스트는 서로 영향을 주지 않는다고 관찰되어왔습니다. 즉, 독립이란 거죠.

하지만, 당연히 여러 실험들이 항상 서로 독립인 것은 당연히 아닙니다. 독립이 아닌 경우에는 실험 해석에 문제가 당연히 생깁니다. 그렇다고 중첩 실험을 하지 않는 것은 답이 아닙니다. 실험 수를 줄이게 되면, 우리는 실험을 더 많이 할 수록 더 많은 지식을 쌓을 수 있고 제품에 대한 이해를 넓힐 수 있는데 이 기회를 날리게 되는 것이기에 다른 방향의 접근이 필요합니다.

중첩 실험을 하면서 실험끼리 독립이 아닌 경우를 체크하기 위해 Google, Bing 등 여러 회사는 모니터링 시스템을 구축했습니다. 독립 여부를 판단하는 모니터링 알고리즘은 각기 다르지만요. 혹은 Tencent는 독립을 좀 더 잘 보장할 수 있는 assignment 방법론을 운영한다고 발표하기도 했습니다.

이 외에도 중첩 실험을 할 때 주의해야 할 점은 몇 가지 더 있습니다. A/B 테스트의 교과서로 불리는 하마 책에도 중첩 실험의 기본 원칙과 주의점이 소개되어있습니다. 각 회사의 상황에 맞는 best practice는 각자의 상황에서 연구될 필요가 있습니다. 하지만, 실무적으로 중첩 실험을 두려워할 이유는 없습니다. 아주 극단적으로 “모니터링 없이 중첩 실험하기 vs 한 유저에게 단 하나의 실험만 하기” 둘 중 하나 선택하라면 저는 망설이지 않고 전자를 택할겁니다.

HYPERCONNECT AI는 이와 같은 철학으로 실험 환경을 발전시켜 왔습니다. 저희는 “빠른 실험”과 “안전한 실험”을 동시에 가능하게 하는 플랫폼을 직접 구축했습니다. 실험 설정과 리뷰에 걸리던 시간을 97% 단축한 프레임워크를 통해, 누구나 빠르게 실험을 제안하고 결과를 검증할 수 있게 되었습니다. 실험이 중첩되고 복잡해질수록 각 실험이 충돌 가능성이 높아지지만, 그 위험을 줄이는 건 실험을 멈추는 게 아니라 실험과 실험 플랫폼을 더 잘 설계하는 것이라고 믿습니다.

실험 결과를 해석한다는 것

A/B 테스트의 결과를 해석하는 일은 단순히 숫자를 비교하는 것보다 훨씬 어렵습니다. 같은 실험이라도 세그먼트에 따라 전혀 다른 결과가 나올 수 있고, 평균값만 보고 판단하면 오히려 잘못된 결론을 내릴 수 있습니다. 저희는 실험 결과를 볼 때 항상 “어디에서 차이가 생겼는가”를 먼저 확인합니다. 특정 국가나 OS, 혹은 성별에서 기대와 다른 방향으로 움직였다면, 그 이유를 데이터로 검증하고 새로운 가설을 세웁니다. 실험이 모든 사용자 그룹에 고르게 작동하지 않는다면, 그 결과를 단순히 ‘실패’로 보지 않고, 개선의 단서를 찾는 기회로 봅니다.

무엇보다 중요한 것은 불확실성을 감으로 판단하지 않는 일입니다. 지표의 평균값이 조금 높거나 낮아졌다고 해서 곧바로 개선이라고 결론 내릴 수는 없습니다. 지표의 분산(variance)과 표본의 크기를 함께 봐야 그 차이가 우연인지, 실제 변화인지 알 수 있습니다. 데이터는 언제나 불확실성을 동반합니다. 그렇기 때문에 실험 결과를 신뢰하기 위해서는 그 불확실성을 정량적으로 확인해야 합니다. 단순히 숫자를 비교하기보다, 지표의 “분포”와 변동성을 함께 이해하는 것이 훨씬 중요합니다.

많은 분들이 “p-value가 낮으니 개선됐다”고 말하지만, p-value는 단지 관측된 차이가 우연일 가능성을 보여줄 뿐입니다. p-value가 낮다고 해서 반드시 의미 있는 개선이라고 볼 수는 없습니다. 효과 크기, 분산, 그리고 장기적인 추세를 함께 살펴야 합니다. 특히 효과의 크기가 미미하다면, p-value가 낮아도 그 실험은 실질적인 가치가 없을 수 있습니다. 이런 경우에는 A/A 테스트 결과를 함께 참고하는 것이 큰 도움이 됩니다.

실험에서 자주 마주치는 상황이 있습니다. 어떤 지표는 올랐지만, 다른 지표는 오히려 떨어지는 경우입니다. 예를 들어 1차 지표(클릭률 혹은 전환율)는 개선되었지만, 최종적으로 우리가 올리고자 하는 핵심 지표(리텐션이나 매출)는 변화가 없을 때가 있습니다. 이런 경우엔 단순히 결과를 좋다 나쁘다로 판단하지 않고, 퍼널(funnel) 단계별로 어디에서 변화가 일어났는지를 추적합니다. 그 이유에 대한 가설을 세우고, 이를 확인하기 위한 다음 실험을 설계합니다.

결국 실험 결과를 분석한다는 것은 숫자 뒤의 맥락을 읽는 일입니다. 단순히 승패를 판단하는 것이 아니라, 왜 그런 결과가 나왔는지를 탐구하는 과정입니다. 저희는 모델의 개선뿐 아니라, 그 개선이 사용자 경험과 서비스 목표에 어떤 영향을 주는지를 꾸준히 관찰합니다. 실험은 데이터를 해석하는 도구이자, 우리가 세상을 더 정직하게 이해하기 위한 방법이라고 믿습니다.

실험을 문화로 만든다는 것

HYPERCONNECT AI 조직은 실험을 하나의 문화로 보고 있습니다. 모델을 개선하는 일은 결국 세상을 관찰하는 일이라고 믿기 때문입니다. 실험이 성공하든 실패하든, 그 안에서 배우는 것이 진짜 진전이라고 생각합니다. 실패한 실험도 낭비가 아니라, 다음 시도를 위한 단서가 됩니다.

A/B 테스트는 단순히 더 나은 모델을 선택하기 위한 절차가 아닙니다. 우리가 더 나은 제품을 만들고, 더 좋은 사용자 경험을 제공하기 위한 과정입니다. 실험을 통해 우리는 “이게 정말 더 나은가?”를 데이터로 확인하고, 그 답을 기반으로 다음 개선을 이어갑니다.

AI가 서비스의 중심이 되어갈수록, 실험은 기술 검증을 넘어 조직의 태도가 되어야 한다고 생각합니다. 좋은 모델을 만드는 것보다 중요한 것은, 그 모델이 세상에서 실제로 어떻게 작동하는지를 끝까지 관찰하는 일입니다. 데이터를 통해 진실을 확인하고, 그 배움을 다음 도전으로 이어가는 것. 그것이 저희가 AI를 다루는 방식입니다.

저희는 더 나은 모델을 만드는 것보다, 더 정확한 세상을 이해하는 데에 가치를 둡니다. 실체적 진실에 다가가는 일. 그것이 결국 더 나은 기술을, 그리고 더 나은 제품을 만들어준다고 믿습니다.