Treasure Hunt Engine에 대한 비현실적인 기대치

우리가 실제로 해결하고 있었던 문제
실제로 우리는 사용자 경험을 희생하지 않으면서 사용자의 참여를 유지해야 하는 복잡한 문제를 해결하는 과제를 맡았습니다. 우리가 사용할 수 있는 자원은 한정되어 있었고, 우리 팀은 AI에 대한 친숙도가 제각각인 숙련된 엔지니어들로 구성되어 있었습니다. 분명했던 점은 낮은 지연 시간 (latency)과 신뢰성 (reliability)이라는 제약 조건 하에서 독특한 퍼즐을 생성할 수 있는 시스템이 필요하다는 것이었습니다. 이를 달성하기 위해 우리는 인터넷을 뒤져 기성 AI 솔루션들을 찾아보기 시작했습니다. 우리는 대규모로 퍼즐을 생성할 수 있는 최첨단 AI 엔진을 통합해야 한다는 말을 들었습니다. 우리가 깨닫지 못했던 점은 이것이 비현실적인 기대와 잘못된 아키텍처 (architecture) 결정이라는 토끼굴로 우리를 이끌 것이라는 사실이었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리는 인기 있는 대규모 언어 모델 (LLM)을 시스템에 통합하는 것부터 시작했습니다. 우리는 이것이 매력적인 퍼즐을 자동으로 생성하는 문제를 해결해 줄 것이라고 생각했습니다. 하지만 우리가 빠르게 발견한 것은 출력이 매력적이지 않을 뿐만 아니라 종종 터무니없다는 것이었습니다. 우리는 20%가 넘는 환각 (hallucination) 비율을 목격했는데, 이는 우리의 신뢰성 요구 사항을 고려할 때 받아들일 수 없는 수준이었습니다. 우리는 모델을 미세 조정 (tweak)하기 위해 우리의 특정 사용 사례에 맞게 매개변수 (parameters)와 하이퍼파라미터 (hyperparameters)를 조정해 보았습니다. 그러나 이는 더 많은 문제를 야기했습니다. 모델이 동일한 퍼즐을 반복적으로 생성하는 출력의 진동 (oscillations) 현상이 나타나기 시작했습니다. 우리는 우리가 진전을 이루고 있다고 생각했지만, 실제로는 과적합 (overfitting)이라는 근본적인 문제를 가리고 있었을 뿐이었습니다.

아키텍처 결정
우리가 한 걸음 물러나 아키텍처를 재평가하고 나서야 비로소 실질적인 진전을 보이기 시작했습니다. 우리는 LLM이 문제의 해결책이 아니라 오히려 문제의 증상이라는 것을 깨달았습니다. 우리에게 필요했던 것은 퍼즐 생성 문제의 미묘한 차이를 고려할 수 있는 더 견고한 아키텍처였습니다. 우리는 규칙 기반 생성 (rule-based generation)과 축소된 버전의 LLM을 결합한 하이브리드 접근 방식 (hybrid approach)을 구현하기로 결정했습니다.

이 결정은 매우 큰 성과를 거두었습니다. 환각 (hallucination) 발생률은 5% 미만으로 떨어졌고, 참여도 지표 (engagement metrics)는 크게 상승했습니다. 하지만 무엇보다 중요한 것은, AI 시스템에서 아키텍처 (architecture)의 중요성에 대한 값진 교훈을 얻었다는 점입니다.

수치 데이터가 말해주는 것: 수정된 시스템을 배포한 후, 주요 지표에서 상당한 개선을 확인했습니다. 참여율 (engagement rates)은 25% 증가했고, 퍼즐 생성률 (puzzle generation rate)은 30% 상승했습니다. 더 중요한 것은, 사용자들이 퍼즐이 단순히 몰입감이 있을 뿐만 아니라 도전적이고 재미있다고 언급하며 전반적인 경험이 크게 개선되었다고 보고했다는 점입니다. 실제 수치 측면에서, 우리 시스템은 200ms 미만의 지연 시간 (latency)으로 분당 평균 500개의 퍼즐을 생성했습니다. 이는 우리가 목표로 했던 5초의 지연 시간과는 거리가 멀었지만, 기존의 LLM 기반 접근 방식에서 나타났던 30초의 지연 시간에 비하면 상당한 개선이었습니다.

다르게 했을 점: Treasure Hunt Engine에서의 경험을 되돌아보면, 몇 가지 다르게 하고 싶은 점들이 있습니다. 첫째, 처음부터 AI 통합 (AI integration)에 대해 더 미묘하고 세밀한 (nuanced) 접근 방식을 취했을 것입니다. 우리의 구체적인 사용 사례 (use case)와 요구 사항을 이해하는 데 시간을 할애함으로써, 과도한 약속을 하고 결과물은 그에 미치지 못하는 함정을 피할 수 있었을 것입니다. 둘째, 아키텍처 결정 (architecture decisions)을 평가하는 데 더 많은 시간을 투자했을 것입니다. 시스템 설계 (system design)에 대해 더 사려 깊은 접근 방식을 취했다면, 진동 (oscillations)과 환각 (hallucination) 발생률의 함정을 피할 수 있었을 것입니다. 마지막으로, 처음부터 테스트와 검증 (testing and validation)을 우선시했을 것입니다. 만약 우리가 테스트와 검증에 더 엄격한 접근 방식을 취했다면, 우리의 기존 LLM 기반 접근 방식은 문제가 발생한 첫 징후에서 바로 거부되었을 것입니다.