학습 앱, 피트니스 트래커, 또는 추천 엔진(Recommendation engine)의 제품 페이지를 아무거나 열어보면, "적응형(adaptive)"이라는 단어가 마케팅 용어로 아주 많이 쓰이고 있는 것을 발견할 수 있을 것입니다. 시스템이 "당신에게 적응합니다." "당신의 수준을 학습합니다." "당신의 경험을 개인화합니다."라고 말이죠.

대부분의 경우, 이는 들리는 것보다 훨씬 작은 의미를 갖습니다. 문제를 맞히면 다음에는 더 어려운 문제를 보여주고, 틀리면 더 쉬운 문제를 보여주는 식입니다. 스스로를 스마트하다고 부르는 수많은 제품의 적응형 엔진(adaptive engine)은 사실 이 전부입니다.

이것이 완전히 틀린 것은 아닙니다. 다만 적응형(adaptive)은 아닙니다. 그것은 휴리스틱(heuristic)입니다. 휴리스틱은 마지막 데이터 포인트(data point)에 반응합니다. 반면 적응형 시스템은 당신에 대한 모델(model)을 유지하고, 새로운 증거가 도착함에 따라 그 모델을 지속적으로 업데이트하며, 단순히 마지막 이벤트가 아니라 그 모델을 사용하여 다음에 어떤 일이 일어날지 결정합니다. 이 차이는 생각보다 훨씬 중요하며, 일단 이를 깨닫고 나면 if-else 패턴이 도처에 널려 있다는 것을 알게 됩니다.

저는 시험 준비 플랫폼을 통해 실제로 이런 방식으로 시스템을 구축했습니다. 이를 성공적으로 구현하는 과정에서 제품 자체보다 더 일반적인 교훈을 얻었습니다. 즉, 어떤 시스템이 '적응형'이라는 단어를 쓸 자격이 있으려면 구조적으로 실제로 무엇이 필요한가에 대한 것입니다.

마지막 이벤트에 반응할 때 발생하는 문제

시험 공부를 하는 사람에게 연습 문제를 제공하는 시스템을 구축한다고 가정해 봅시다. 가장 단순한 접근 방식은 마지막 문제의 정답/오답 여부를 추적하여 그에 따라 분기(branch)하는 것입니다.

이 방식은 몇 가지 구체적인 측면에서 실패합니다. 첫째, 한 단계를 넘어선 기억력이 없습니다. 어려운 문제에서 운 좋게 맞히면 훨씬 더 어려운 문제로 넘어가게 되고, 쉬운 문제에서 부주의한 실수를 하면 실제 수준보다 낮은 단계로 떨어지게 됩니다. 둘째, 확신(confidence)을 표현할 수 없습니다. 시스템이 파악한 당신의 능력이 안정적인지, 아니면 노이즈(noise)에 따라 요동치고 있는지 알 방법이 없습니다. 셋째, 일반화(generalize)가 불가능합니다. 분기 로직(branching logic)이 보통 콘텐츠 유형별로 하드코딩(hard-coded)되어 있기 때문에, 새로운 도메인이 추가될 때마다 매번 별도의 if-else 규칙 세트가 필요합니다.

이 중 그 어느 것도 구현상의 버그(implementation bugs)가 아닙니다. 이것들은 근본적인 모델이 너무 얇기 때문에 발생하는 결과입니다. 즉, 매 단계마다 버려지는 단일 불리언(boolean) 값일 뿐입니다.

진정으로 적응형(adaptive)인 시스템은 그 불리언 값을 어떤 숨겨진 변수(hidden variable)—도메인에 따라 능력(ability), 선호도(preference), 위험 허용치(risk tolerance) 등 무엇이든 될 수 있는—에 대한 지속적이고 계속 업데이트되는 추정치(estimate)로 대체합니다. 그런 다음, 모든 새로운 관찰(observation)을 단순히 분기(branch)를 위한 독립적인 트리거로 취급하는 대신, 추정치를 업데이트하는 증거(evidence)로서 호출하고 처리합니다.

단일 알고리즘이 아닌 세 가지 구성 요소

실제 숨겨진 상태(hidden-state) 추정치를 유지하기로 결정했다면, 시스템에는 함께 작동하는 세 가지 별개의 요소가 필요합니다. "적응형(adaptive)" 부분이 단순히 추정 알고리즘(estimation algorithm)일 뿐이라고 생각하기 쉽습니다. 좋은 통계 모델(statistical model)일 수는 있지만, 추정 그 자체만으로는 주변을 둘러싼 다른 두 가지 요소 없이는 아무것도 할 수 없습니다.

구성 요소 1: 행동으로부터 숨겨진 상태(hidden state) 추정하기. "사용자가 무엇을 했는지"에서

구성 요소 3: 새로운 입력을 계속해서 생성하는 파이프라인. 이것은 사람들이 자주 잊어버리는 부분입니다. 선택할 수 있는 대상(pool)이 고갈된다면 추정(Estimation)과 선택(Selection)은 무용지물입니다. 몇 달 동안 공부하는 학생이나 매일 접속하는 사용자처럼 충분히 오랜 기간 작동하는 적응형 시스템(Adaptive system)은 결국 정적인 콘텐츠 세트(Static content set)를 소진하게 됩니다. 새로운 자료를 생성하고, 그것이 실제로 사용 가능한지 검증하며, 동일한 것이 필요한 다음 사람을 위해 중복해서 재생성하지 않고도 선택할 수 있도록 준비해 두는 방법이 필요합니다.

이 세 가지 중 하나라도 놓치면 시스템은 저하됩니다. 추정이 없다면: 다시 if-else 문으로 돌아가게 됩니다. 선택 전략이 없다면: 사용자에 대한 훌륭한 모델을 가지고 있어도 그것으로 할 수 있는 지능적인 행동이 없습니다. 콘텐츠 파이프라인이 없다면: 콘텐츠가 떨어질 때까지는 아름답게 작동하다가, 콘텐츠가 고갈되면 조용히 적응형(Adaptive) 기능을 멈추고 정적(Static)인 상태가 됩니다.

구성 요소 1의 실제 적용: 문항 반응 이론 (Item Response Theory)

제가 실제로 구축했던 시스템인 적응형 시험 준비 플랫폼을 바탕으로 설명하겠습니다. 추상적인 구성 요소는 실제 문제를 해결하는 모습을 한 번 보고 나면 더 신뢰하기 쉽기 때문입니다.

학생의 답변으로부터 능력을 추정하기 위해, 저는 문항 반응 이론 (Item Response Theory, IRT), 구체적으로는 2모수 로지스틱 (two-parameter logistic, 2PL) 모델을 사용했습니다. 이것은 새로운 기술이 아닙니다. GRE나 GMAT 같은 표준화된 시험의 이면에 있는 것과 동일한 심리측정학적 (psychometric) 프레임워크이지만, 시험을 넘어 범용적으로 적용될 수 있는

능력치 θ (theta)를 가진 학생이 주어진 질문에 정답을 맞힐 확률은 다음과 같습니다:

P(correct | θ) = 1 / (1 + e^(-a(θ - b)))

이것은 로지스틱 곡선 (logistic curve)입니다. 학생의 능력치가 질문의 난이도와 정확히 일치할 때 (θ = b), 정답을 맞힐 확률은 50%가 됩니다. 능력치가 난이도보다 높아지면 확률은 1을 향해 상승하고, 난이도보다 낮아지면 확률은 0을 향해 떨어집니다. 변별도 파라미터 (discrimination parameter)는 그 상승 곡선이 얼마나 가파른지를 제어합니다. 높은 변별도는 곡선이 거의 계단 함수 (step function)에 가깝다는 것을 의미하며, 낮은 변별도는 완만한 경사를 의미합니다.

점수가 매겨진 각 섹션이 끝난 후, 시스템은 θ에 대한 추정치를 업데이트해야 합니다. 단순하면서도 효과적인 접근 방식은 경사 기반 업데이트 (gradient-based update)입니다. 각 답변된 질문에 대해, 현재 θ가 주어졌을 때의 정답 예상 확률을 계산하고, 이를 실제 발생한 결과와 비교한 뒤, 학습률 (learning rate)에 따라 그 놀라움 (surprise)의 방향으로 θ를 살짝 조정합니다.

function updateTheta(theta, answers, items, learningRate = 0.15):
  for each answer:
    expected = probability2PL(theta, item)
...

학습률은 단순히 던져두는 상수가 아니라 실제적인 설계 결정 사항입니다. 학습률을 너무 높게 설정하면, 단 한 번의 운 좋은 추측이나 부주의한 실수만으로도 추정치가 격하게 요동치게 되어, 모델이 해결하려고 했던 노이즈 문제를 다시 불러들이게 됩니다. 반대로 너무 낮게 설정하면 시스템이 실제 능력치의 변화에 거의 반응하지 않게 되어, 적응 (adapting)한다는 목적 자체를 상실하게 됩니다. 실제로는 0.15 정도의 값이 반응성과 안정성 사이의 균형을 맞추지만, 적절한 값은 업데이트 주기당 얼마나 많은 데이터 포인트(data points)를 얻는지와 그 데이터 포인트들이 얼마나 노이즈가 많은지에 따라 달라집니다.

어떤 도메인에든 적용할 가치가 있는 또 다른 개념은 피셔 정보 (Fisher Information)입니다. 이는 주어진 능력치 추정치에서 특정 질문이 주어졌을 때, 학생이 그 질문에 답함으로써 실제로 당신에게 얼마나 많은 정보를 가르쳐 줄 수 있는지를 알려줍니다.

function fisherInformation(theta, item):
  p = probability2PL(theta, item)
  q = 1 - p
...

이 함수는 $p$가 0.5에 가까울 때, 즉 결과가 가장 불확실한 지점에서 최대화됩니다. 이는 깊이 생각해보면 직관적입니다. 만약 누군가가 질문에 맞힐지 틀릴지를 이미 거의 확실하게 알고 있다면, 그 질문에 답하는 것은 이미 알고 있는 것 외에 새로운 정보를 거의 제공하지 않기 때문입니다. 시스템에 가장 많은 것을 가르쳐주는 질문은 학생이 할 수 있는 능력의 바로 경계선에 위치한 질문들입니다. 최대 신뢰도(maximum confidence)가 아닌 표적 최대 불확실성(target maximum uncertainty)이라는 이 원칙은 시험 범위를 훨씬 넘어 일반화될 수 있습니다. 사용자에 대해 효율적으로 학습하려는 모든 시스템은 이미 확신을 가지고 있는 입력이 아니라, 자신이 가장 불확실해하는 입력을 찾아내야 합니다.

능력 추정치(ability estimate)의 표준 오차(standard error)는 총 누적된 피셔 정보량(Fisher Information)의 제곱근의 역수에 비례합니다. 이를 추적하면 대부분의 단순한(naive) 시스템은 제공할 수 없는 것, 즉 단순한 점 추정치(point estimate)가 아닌 사용자 모델에 대한 신뢰 구간(confidence interval)을 얻을 수 있습니다.

두 번째 구성 요소의 실제 적용: 점진적 난이도 탐색 (progressive difficulty search)

능력 추정치를 확보했다면, 다음 문제는 선택입니다. 학생의 현재 $\theta$가 주어졌을 때, 다음에 무엇을 보여주어야 할까요?

자연스러운 본능은 $\theta$와 최대한 일치하는 콘텐츠를 찾는 것입니다. 하지만 항상 딱 맞는 매칭을 찾을 수 있는 것은 아닙니다. 해당 난이도의 콘텐츠 풀(content pool)이 부족할 수도 있고, 학생이 자료가 적은 특이한 범위에 있을 수도 있습니다. 해결책은 점진적으로 범위를 넓히는 탐색(progressive widening search)입니다. 목표 주변의 좁은 대역(band)에서 시작하여, 해당 대역에 아무것도 없다면 범위를 넓혀가는 방식입니다.

ranges = [
  [theta - 0.8, theta + 0.8],    // 이상적인 범위 (ideal range)
  [theta - 1.5, theta + 1.5],    // 확장 (widen)
...

이 방식은 이상적인 매칭이 존재하지 않을 때도 시스템이 완전히 실패하는 대신 점진적으로 성능이 저하되도록 보장하며, 학생이 거의 항상 잘 조정된(well-calibrated) 자료를 볼 수 있게 합니다. 이는 단순한 패턴이지만, 유한한 콘텐츠 풀이라는 실제 제약 조건 하에서 원칙적으로만 적응형인 시스템과 실제로 적응형인 시스템을 구분 짓는 디테일입니다.

실전에서의 세 번째 구성 요소: Write-through 캐싱을 통한 온디맨드(On-demand) 생성

이 부분은 가장 건너뛰기 쉽지만, 건너뛰었을 때 가장 큰 비용이 발생하는 지점입니다. 정적인 콘텐츠 뱅크(Static content bank)는 아무리 규모가 크더라도 결국 바닥이 납니다. 콘텐츠가 고갈되는 현상은 요란하게 실패하지 않습니다. 대신 조용히 실패합니다. 사용자는 반복되는 자료를 보기 시작하고, 근본적인 기술을 익히는 대신 정답을 암기하게 되며, 시스템의 정교하게 조정된 선택 로직(Selection logic)은 점점 더 얇아지고 노후화된 풀(Pool)을 대상으로 작동하기 시작합니다.

해결책은 방대한 정적 뱅크를 미리 구축하는 대신, 필요할 때(On demand) 새로운 콘텐츠를 생성하고 재사용을 위해 캐싱(Caching)하는 것입니다. 흐름은 다음과 같습니다:

1. 선택(Selection) 시와 동일한 점진적 확장(Progressive-widening) 로직을 사용하여, 목표 난이도 대역의 캐시를 확인합니다.
2. 캐시 미스(Cache miss)가 발생하면, 생성 모델(Generation model)을 호출합니다. 저의 경우, 목표 난이도와 콘텐츠 유형을 전달하여 대규모 언어 모델(Large Language Model, LLM)을 호출합니다.
3. 출력을 신뢰하기 전에 엄격한 스키마(Schema)에 따라 검증합니다.
4. 구조적 검증을 넘어 품질 휴리스틱(Quality heuristics)을 실행합니다: 이것이 단순히 형태만 올바른 콘텐츠가 아니라, 실제로 좋은 콘텐츠인가?
5. 요청자에게 반환하기 전에 데이터베이스에 삽입합니다: Write-behind가 아닌 Write-through 방식을 사용합니다.
6. 특정 사용자가 이 콘텐츠를 확인했음을 기록하여, 해당 사용자에게 중복되지 않도록 합니다.

function getOrGenerate(...):
  cached = getFromCache(...)
  if cached: return cached
...

검증 단계는 생각보다 훨씬 중요합니다. 생성 모델은 기본적으로 신뢰할 수 없습니다. 구조적으로 잘못된 출력, 미묘하게 틀린 콘텐츠, 또는 형태는 올바르지만 품질이 낮은 출력 모두 시스템에 진입하기 전에 포착되어야 합니다. 경계(Boundary)에서 확인되는 콘텐츠 유형별 판별된 유니온(Discriminated union) 스키마는 구조적 문제를 잡아냅니다. 별도의 품질 휴리스틱, 그럴듯한 오답(Plausible distractors), 명확한 정답, 그리고 콘텐츠의 실제 난이도와 실제로 일치하는 난이도 등급은 스키마 검증은 통과했지만 여전히 품질이 낮은 문제들을 잡아냅니다.

Write-through caching(쓰기 통과 캐싱), 특히 반환한 후가 아니라 반환하기 전에 삽입하는 방식은 특정 범주의 버그를 완전히 제거하는 디테일입니다. 이를 통해 데이터베이스는 즉시 단일 진실 공급원 (Single Source of Truth)이 되며, 해당 난이도 수준의 다음 사용자는 또 다른 생성 호출 (Generation call)을 트리거하는 대신 캐시 히트 (Cache hit)를 얻게 됩니다. 또한 나중에 잘못될 수 있는 별도의 캐시 무효화 (Cache-invalidation) 로직도 필요하지 않습니다. 이에 따른 비용은 새로 생성된 항목당 약 하나의 데이터베이스 삽입 (Insert) 지연 시간(Latency) 정도입니다. 실제로 이는 수십 밀리초 (ms) 단위이며, 중복된 생성 호출 비용에 비하면 무시할 수 있는 수준입니다.

왜 세 가지 구성 요소가 서로를 보완해야 하는가

이 세 가지 구성 요소를 하나의 시스템이 아닌 별개의 기능으로 구축할 경우 놓치기 쉬운 부분이 있습니다. 이들은 각각의 출력이 다음 요소의 입력으로 이어지는 루프 (Loop) 형태로 연결되었을 때에만 진정한 적응성 (Adaptivity)을 만들어냅니다.